作者：@eddiedzhou、@mr_cheu、@MatZhao、@CosmicPegasis19、@manav_ai
Jev 是一個用來做「類型化決策」的模型。你給它上下文，加上一組固定的問題與選項，它回傳的是選擇、分數和機率，而不是一段文字。這是一個「系統一（System One）」模型！
但分類並不新鮮，結構化輸出、小模型，或是直接從 logits 讀取機率也都不算新東西。這段歷史，多少解釋了大家對 Jev 兩極化的反應……
懷疑者說得確實有道理，但 Jev 在這個生態系裡也有它的一席之地。要真正理解這一點，我們得先把整個解決方案的光譜攤開來看。
還有哪些替代方案？
當系統需要一個標籤、分數或「是／否」的答案時，有四種合理的做法：
做法
為什麼用它
代價
通用型 LLM
零樣本、彈性高，還能順便產出論點或解釋。透過推論時的運算（reasoning），甚至可以說具備「更高的智慧」。
為了一個小決策，卻要付出自迴歸模型的延遲與成本
開放的零樣本分類器
便宜、可本地部署、好控制
品質不穩定；你得自己負責挑模型跟架服務
微調過的分類器
對於標籤品質好、流量穩定的任務，通常是最可靠的選擇
要收集資料、訓練、部署、處理漂移，而且分類體系比較難改
Jev
在乾淨的託管 API 背後，提供零樣本的彈性
品質依任務而定、不會產生文字、依賴供應商
Jev 的價值在於：團隊可以隨時換問題和選項，不用重新收集訓練資料，也不用費心把模型服務架好。這種好處誰都該買單。「我們自己也能做」這句話，套在大多數基礎設施產品上都成立。
各種開源重現也讓「這很新穎」的說法冷靜了不少。用 Qwen 和 SGLang、DiffusionGemma 和 vLLM，以及 Kev 做出的實作，已經能還原它大部分的 API 或模型樣貌。
n=764 時，Jev 85.7%，Kev-8B 79.6%
Parallel 的外部測試同樣發現，Jev 在重排序（reranking）上很有競爭力，不過在兩個分類任務中，專用模型還是贏了。
我們在 Glean 看到的結果
接下來就是個實際問題了：Jev 這種「零樣本彈性＋託管推論」的組合，到底什麼時候真的會比別的方案強？我們在 Glean 測了四個有明確邊界的決策場景，這些場景本來就有基準線，可以直接比較真實的企業級品質。因為多數基準線都是 LLM 系統，所以在這些實驗裡，我們預期成本和延遲會有兩個數量級的改善。結果從「明顯比線上差」到「比 LLM router 更快又更準」都有。
查詢分類
查詢分類是把請求對應到下游系統使用的寬泛任務類別。這對 Jev 來說是個很自然的場景：雖然每次請求的標籤空間是已知的，但分類體系的變動速度，往往快過微調模型重新訓練的速度。
這個實驗主要看 Jev 跟我們線上基準預測（LLM 系統）的一致率。我們預期也確實觀察到，Jev 在離線吞吐量上有大幅加速，所以用一致率當作品質的簡單代理指標。我們也拿 Laya（一個開放權重的決策模型）以及微調過的 Laya 當基準。這個微調在本地跑幾個小時就完成，模型也夠小，開發者的機器就能跑起來。
實驗
寬泛任務一致率
效能
Jev 零樣本
66.8%
~
12 分鐘（並行數 4
）
Laya 原版
35.9%
~
90 秒（本地開發機）
微調版 Laya
74.5%
~
90 秒（本地開發機）
作為一個免訓練、開箱即用的便利模型，Jev 明顯勝過原版 Laya；但不意外地，微調讓 Laya 脫胎換骨，尤其是搭配這樣的效能數字。代價就是要花力氣弄出好標籤、把訓練流程架起來。當任務是新的，或標籤還在一直變的時候，Jev 大概還是比較香。
模型路由：專家轉移
模型路由跟查詢分類是相關問題。在這裡，我們把它定義成「專家轉移」——由系統決定該交給哪位專家／模型來處理請求。目前我們的線上基準是在 Agent 循環裡，直接請 LLM 原生做出這個決定。這很適合測試 Jev 能不能用有界決策取代生成式呼叫，但有一個重要的技術限制：如果不轉移，Jev 會嚴格地多一次呼叫。而線上基準在不轉移的情況下，可以用同一次 LLM 呼叫直接開始工具呼叫的工作。
我們用了簡化版的線上路由（只有 3 位專家），把 751 筆可比對的黃金資料集跑過更新後的 Jev router，將它選的路線跟現有 prompt-based router（傳統 LLM）比較，並以黃金標籤計算準確率。
我們另外挑出 40 筆原本真的做了專家轉移呼叫的資料（樣本較小），比較同一批資料的呼叫延遲。
每筆資料的中位數加速是 8.1 倍。這是目前內部最強的 Jev 成果之一：在這個有界路由任務上，Jev 既更準，也快得多。差距大到讓我們覺得，那些沒走專家路由的請求所付出的「阻塞」稅，可能是值得的。提醒一下，這仍是離線黃金資料集的比較，延遲樣本也只有 40 筆正轉移，所以還有很多風險要排除、很多測試要做！
重排序
這是 Glean 的老本行！下面的線上基準是 Glean 現有搜尋堆疊排出的順序。這個實驗請 Jev 重新排列最多 50 筆結果。
我們試了四種用 Jev 類型化輸出來表達相關性的方式：
形式
如何表達相關性
逐點 Noul
對每一筆結果問一個獨立的「是否相關」是非題，再按「是」的機率排序。
共享狀態 Noul
把整組候選結果當成共享上下文給 Jev，然後對每一筆問一樣的是非題。
分數
請 Jev 給每個候選結果打一個數字的相關性分數。
選擇
把所有候選結果當成同一個決策裡的選項，再按得出的機率排序。
我們在內部 evalset 上跑，使用者無法存取所有標準答案，所以絕對數字不能代表線上排序表現——但相對差異值得看。
Jev 的「選擇」形式最強。在 4,855 筆蒐集的搜尋查詢配對對照中，去掉以線上順序打破平手的機制後，結果如下：
Jev Choice 每次查詢大約花 $0.00044，離線測試 p50 延遲 0.195 秒。但在平均一次查詢的 41 個候選結果中，它會對其中約 37 個給出一模一樣的分數。用線上順序來打破這些平手，Recall@6 從 40.2% 升到 44.3%，這讓未修正的結果看起來比 Jev 本身分數應有的水準更好。一如往常，這裡有很多但書，但方向很清楚：Jev 是個便宜又有效率的基準線，而不是 Glean 線上排序器的替代品。
引用支持度判斷
引用判斷要回答兩個相關問題：需要證據的主張有沒有足夠的引用（引用召回率），以及被引用的來源是不是真的支持它所對應的主張（引用精確率）。乍看之下，因為輸出／標籤空間是有界的（跟多數 judge 設定類似），這似乎是 Jev 的絕佳場景。但評分標準其實很複雜，可能要把好幾個主張拆開來看；加上 Jev 不會產出我們常用來做錯誤分析的推理過程，所以在品質和可用性上都有些風險。
我們用一段真實的 1,448 字線上評估回應來測試 Jev，固定回應內容與引用證據。我們比較了它在精確率與召回率上的整體表現，對照對象是不開 reasoning 的 GPT-5.6 Luna，以及開 xhigh reasoning 的版本。為了降低變異，每個 judge 都跑了三次。
Judge
原始量測每次回應時間
原始量測每次回應成本
Jev
6.6 秒
$
0.014
GPT-5.6 Luna，無 reasoning
81.3–85.5 秒
$
0.030–
$
0.047
GPT-5.6 Luna，
xhigh
227.4–259.7 秒
$
0.047–
$
0.060
注意這裡的時間只是方向性參考，不是端到端：Jev 回報的是客戶端連續 wall time，Luna 那幾列則是把模型呼叫時間加總。成本包含實際觀察到的快取。
我們也比對了同樣 28 個段落的一致性。所謂「改變」是指 judge 在三次相同輸入的執行中，至少有一次改變了「該段落引用是否充足」的判定。成對分歧則是在三組執行配對中，逐一比對每個段落，所以每個 judge 共 84 次比較。
Judge
召回率判定改變的段落數
成對召回率分歧數
Jev
28 個中的 1 個 (3.6%)
84 次中的 2 次 (2.4%)
GPT-5.6 Luna，無 reasoning
28 個中的 7 個 (25.0%)
84 次中的 15 次 (17.9%)
GPT-5.6 Luna，
xhigh
28 個中的 5 個 (17.9%)
84 次中的 10 次 (11.9%)
Jev 唯一改變的，是某一段落算不算「需要引用」；它的原始召回率類別並沒有變。因此在段落層級的引用覆蓋判定上，Jev 比兩種 Luna 設定都更容易重現。
我們不會因此斷言 Jev 是更準確的 judge（各系統採用的支持標準和計分分母不同，我們也沒時間做獨立人工標註）。但即使開了 xhigh reasoning（Luna 的模型時間大約變成三倍），它的一致性還是比 Jev 低。這個結果支持：Jev 是一種快速、便宜、且相對可重現的方式，適合用來落實範圍明確的引用政策。
實驗結論與實務指南
在某些情況下，Jev 是很低摩擦的選擇，同時取代傳統 LLM 與微調分類器。當基準線已經很強（重排序），或小模型很容易微調（查詢分類）時，優勢就沒那麼明顯。有些任務看得出品質更好（模型路由），也有些顯示出更好的一致性與穩定性（引用 judge）。在我們最重要的幾個工作負載中，它確實如預期地在成本和延遲上贏過傳統 LLM。
以上結果給了很好的方向指引，而在 Glean，我們對 Jev 非常期待。再補上幾步（主要是資料落地、SLA 保證這類上線準備）之後，我們打算把 Jev 推進其中幾個使用情境。此外，Jev 也會在本週的內部黑客松扮演重要角色，我們很期待分享更多成果！
最後給一些通則建議——如果輸出選項可以事先列出來，就拿 Jev 跑跑基準。如果任務和標籤很穩定、量又大，也一起測測微調分類器。如果這次呼叫需要產生查詢、解釋或其他動態文字，那就繼續留著生成式模型。工具呼叫就是個好例子：Jev 可以幫忙挑工具，但 Glean 多數工具還是需要動態產生的參數（例如搜尋查詢）。
Jev 並沒有改變「分類器早就存在」這件事。它只是讓一個好用的零樣本分類器變得更好上手。這本身就是個扎實的產品，就算它不是每個 AI 系統的全新基石。
