在《MIB 星際戰警 2》中，J 探員到一間看似普通的郵局拜訪 K。他打開一台信件分揀機，發現裡面藏著一個外星人，正飛快地分類信件。
這是個荒謬的小場景，但也給了我們一個思考 AI 的實用角度。
在「收到某樣東西」和「對它採取行動」之間，通常還有一個小決定要做：這該歸到哪一類？
只要一開始就把這個決定做對，系統的其他部分就能走上正確的路徑。
我在開發 AI 軟體時，常常想起那個小外星人。
應用程式可能會收到帳單問題、錯誤回報、產品照片，以及預約產品展示的請求。每一種都需要不同的處理方式。但我們最後往往會要求同一個大型語言模型去檢查所有內容，並判斷接下來該怎麼做。這樣既不高效，也不划算。
因此我認為，專用模型會在 AI 的未來扮演更重要的角色。舉例來說，Jev 就是為軟體能直接執行的結構化決策而打造的。Coinbase 則針對其 Onramp 服務中的詐欺偵測，特別調整了 Qwen3.5-9B。每個模型都專注於一項明確定義的工作，而且成果可以被衡量。
https://x.com/brian_armstrong/status/2109412046244913643
我正在打造這個分類層
熟悉的請求可以直接進入既定流程。需要更多推理的請求，就交給另一個模型。語意模糊的則會被標記出來，要求澄清或人工審核。
潛在的節省效益，來自於只給每個請求它真正需要的運算量。接著我們必須衡量：這個分類器做出的正確決定是否夠多，足以證明它的存在價值。
我們的起點是 CludeMem。當時我們想釐清 AI 應該記住什麼、應該檢索什麼，以及哪些東西在不必要地消耗 token。長期的偏好設定、臨時的指令，以及尚未解決的問題，都該有不同的處理方式。但在做出這些決定之前，我們需要先對資訊進行分類。
這就成了更廣泛分類層的構想來源。同樣的步驟可以用來分類客服請求、路由文件，或決定該由哪位專家處理某項任務。
GIF
隨著越來越多專用模型出現，應用程式必須決定哪些輸入值得它們關注。這正是我們在打造的部分：把收到的內容分類、在本地處理熟悉的情況，再把較難的交給合適的模型或審核流程。
介紹一下 Clude Cat（Cat 代表 categorisation，也就是分類 😉）
在儲存記憶、檢索文件、呼叫工具或產生回應之前，通常都得先決定我們面對的是哪一種資訊。
這類決定無所不在。
想像有人寫信給一家軟體公司：
「我要去哪裡下載發票？」
AI Agent 可以讀取訊息、檢查可用工具、推敲客戶意圖，然後決定去找發票。
更直接的流程可能是這樣：
訊息 → 帳務文件請求 → 帳號驗證 → 取得發票。
回覆依然可以由語言模型撰寫，但最初的路由決定可以在本地完成。
現在換個訊息：
「我被重複扣款、帳號被鎖，而且我想取消。」
如果自信滿滿地把這段話丟進單一的發票流程，只會製造更多工作。這裡有好幾個問題要解決，正確的回應可能需要進一步澄清，或直接轉給真人。
分類器必須有權限說出：「我無法可靠地歸類這個。」
這是產品不可或缺的一部分。一個總是自信地把請求送錯地方的系統，為了修正錯誤所付出的代價，會完全抵銷掉它在速度上的優勢。
對客戶而言，好處是減少等待、少重複說明。
對開發者而言，這是一個明確的決定，可以檢查、測試和修改。他們能看到選定的類別、模型版本、處理時間，以及系統是否拒絕做出決定。
在底層，文字實作從一個稱為編碼器（encoder）的小型預訓練模型開始。
它會把訊息轉換成一組數字，用來表示訊息意義的各個面向。開發者把這種表示法稱為嵌入（embedding）。
「我的發票在哪裡？」和「我需要一份帳單副本」用了不同的字詞，但它們的數值表示可能足夠相似，讓系統認出這是同一類請求。
分類層會利用這些表示法，為開發者定義好的類別打分數。
我們實作了兩種方法。一種是把收到的訊息與每個類別的範例做比較；另一種則是從標註好的範例中學習類別之間的界線。
在擬合（fitted）方法中，我們固定編碼器，只訓練它上方一個較小的決策層。這樣就不必為每個應用程式重新訓練基礎模型。
開發者仍然需要定義類別的意義，並把它們連接到有用的動作上。分類器不可能自己憑空發明公司的部門、退款政策或帳號權限。
它也需要一套接受策略。
得分最高的類別可能依然不匹配。兩個類別的分數可能幾乎相同。一個陌生的請求也可能長得像某個熟悉的類別。
我們目前的本地分數並不是校準過的機率。0.92 分並不自動代表「有 92% 的機率正確」。
我們必須測試當這些分數主導決策時會發生什麼事。
因此輸出會區分三種情況：已接受的類別、需要審核的請求，以及技術性失敗。逾時、取消和模型錯誤也都需要可預測的處理方式。
這就是圍繞著分類器的工程。它決定了其他應用程式能否安全且一致地使用這個結果。
我們用 770 個銀行業請求做了一項實驗，看看這種方法能否減少生成式模型的運算量。
第一種設定把所有請求都送到本地運行的 Qwen2.5 7B 模型進行分類。
第二種則先用我們的本地分類器，只把無法判定的請求送給 Qwen。
結果如下：
- Qwen 的呼叫次數從 770 次降到 227 次。
- 正確分類的數量從 535 個增加到 642 個。
- 整體輸入的準確率從 69.5% 提升到 83.4%。
- 總查詢時間從 299.7 秒降到 87.7 秒。
本地階段省下了 543 次 Qwen 呼叫，減幅達 70.5%。
快取功能保持開啟，而且直接做法是在組合做法之前執行的。時間數據不包含環境設置和暖機。我們只測量分類本身，沒有產生最終的客戶回覆，也沒有付錢給模型供應商。
這些數字只描述這套特定設定。它們不能證明我們優於所有 LLM，也不能保證客戶一定能省下成本。
在另一項後續實驗中，我們用擬合過的本地分類器測試了 24 種旅遊與職場情境意圖。
在 720 個請求中，它在本地接受了 688 個。其中 681 個正確，7 個錯誤，剩下 32 個留待審核。
這給了我們兩項不同的指標：
- 覆蓋率：它在本地處理了 95.6% 的請求。
- 接受精確度：在它接受的決定中，有 99.0% 是正確的。
兩者都必須一起看。一個分類器只要只接受少數簡單的請求，就能刷出驚人的精確度。
我們也測試了 100,000 個應該落在支援類別之外的陌生輸入，它的準確率超過 94%。
認出系統「不知道什麼」，依然是這項工作的一部分。
速度也需要同樣嚴謹的態度。在另一項 CPU 暖機測試中，完整的銀行分類器在 M4 Max 上的中位數處理時間約為每次請求 1.8 毫秒。這包含了 tokenization、嵌入和評分。
但不包含下載模型和啟動的時間。這是分類的測量值，不是解決使用者完整請求所需的時間。它也不能代表手機或一般筆電會有同樣的效能。
Jev 之所以和這個討論有關，是因為它已經在處理類似的一類決策。
TypeSafe 把 Jev 定位為用於有限範圍判斷的模型，包括在提供的選項中做選擇，以及把請求路由給一般程式碼、專用模型或真人。\Jev 的意圖路由文件\
我認為 Jev 的角色是一條可選的升級路徑，專門處理本地分類器無法可靠解決的請求。
我們正在打造的架構很直覺：
傳入請求 → 本地分類 → 熟悉的請求走既定路徑；不確定的請求轉給 Jev、其他模型或人工審核。
就算沒有 Jev，同一個本地分類階段也能把無法判定的請求交回應用程式現有的 LLM、澄清步驟或審核流程。
類別、接受門檻和備援機制都由開發者掌控。他們可以把本地分類器導入現有工作流程，並衡量它能接手哪些決定。
目前 Jev 的整合是以影子模式運行，在五大主題上比較決策差異，但不改變應用程式的行為。下一步是測試選擇性升級是否能改善整體流程。上面提到的 Qwen 結果並不是 Jev 的基準測試。
這正是我們需要衡量的：減少不必要的模型呼叫、加快熟悉請求的處理速度，並為需要更多關注的案例提供一條明確的路徑。
我們也開始把同樣的做法延伸到圖片。
想像一家企業收到一張收據、一張錯誤截圖和一張產品照片。每一種都需要不同的處理路徑。
收據可以送去收據擷取流程。截圖可以進入客服流程。產品照片可以進入商品目錄流程。不確定的圖片則送去審核。
分類器負責挑選目的地。至於讀取消費總額、診斷錯誤和辨識產品細節，仍然是各自獨立的任務。
我們的實驗性圖片實作使用預訓練的 CLIP 編碼器來產生圖片的數值表示。
在一項小型診斷測試中，一個擬合過的研究候選模型正確分類了 20 張食品照片中的 19 張。它也把 30 張豆葉圖片全部送去審核。
唯一的錯誤是把一個瓶身上的營養標示和條碼分類成了收據。
你應該看出問題了。兩者都可能包含密集的文字、數字和矩形排版。我們需要用範例來教會模型分辨應用程式真正在意的界線。
這個樣本太狹窄，不足以作為正式的產品宣稱。標籤是從資料集推導出來的，而非獨立判定，而且測試中並沒有新的收據或截圖範例。公開 demo 使用的是另一套基準模型，所以不應把擬合候選模型的結果歸功於它。
圖片處理也比文字分類更吃資源。在 M4 Max 上，暖機後的中位數處理時間在 Node 中約 36 毫秒，在 Chromium 中約 197 毫秒。瀏覽器首先需要大約 85 MiB 的模型資源，再加上執行環境。
本地執行依然有成本。下載大小、記憶體、啟動時間和裝置效能，都必須納入評估。
我心目中的產品，是嵌入現有應用程式中，負責決定下一步該怎麼做的元件。
開發者定義類別、提供代表性範例、連接目的地，並決定分類不確定時該如何處理。
第一次部署應該只是觀察現有流程，而不改變任何結果。接著我們可以在讓分類器接管路由之前，先比較它建議的決策與實際驗證的結果。
我們必須像檢視被拒絕的請求一樣，仔細檢視被接受卻做錯的案例。否則，一個自信滿滿的錯誤決定，就會躲在那個讓人安心的分數背後消失無蹤。
訓練、校準和測試也需要各自的資料。訓練負責教會類別；校準負責挑選接受規則；受保護的測試則用來檢驗凍結後的結果。
一旦某個測試錯誤影響了下一版模型，那個範例就變成了開發資料。下一次評估就需要全新的測試集。
郵件分揀機裡的那個小外星人，讓人們很容易想像這份工作。但要打造出真正有用的版本，就得搞清楚它究竟能處理哪些輸入、什麼時候該求助，以及犯錯的代價有多高。
下一步是建立一個具代表性的工作流程，搭配獨立標註的標籤，並記錄每一個結果。我們需要衡量有多少請求走本地路線、多少轉給其他模型、多少出了錯，以及在計入這些錯誤之後，整個應用程式是否真的變更快或更便宜。
是時候擴大規模，給這個本地模型打點強心針了。
