Jev 與 LLM-as-a-Judge 評估模型效能對比

大多數團隊會把代理的輸出交給 LLM，請它寫下判決來評分。這種模式稱為 LLM-as-a-judge，因為效果足夠好而已成為預設。TypeSafe 的決策模型 Jev 也能評分同樣的輸出，但其方式不同，改變了你能對結果做什麼。本篇說明兩者差異，指出在哪些測量中發揮關鍵作用，並說明在不同評分標準下應選擇哪一種判決者。

假設你已瞭解 LLM-as-a-judge 是什麼。若未了解，請先閱讀 LLM-as-a-Judge: Score AI Agent Outputs Automatically。

TL;DR

LLM 判決者會寫下判決。Jev 則為一個輸入式問題提供機率。當評分標準為封閉式且證據已包含於請求中時，Jev 的準確度與 LLM 判決者相符。Jev 的機率更佳校準，成本是 LLM 判決者的 1/5，延遲是 1/10。若評分標準為開放式且需要閱讀整篇文章，LLM 判決者的結果更貼近專家評分。

• 使用 Jev 於封閉式標準且有證據時，例如答案有來源支援、符合政策或符合參考。若需要閾值或路由規則，或需要快速且低成本的判決者以納入請求流程，也可使用 Jev。
• 使用 LLM 判決者 於開放式評分標準、長上下文檢查（例如摘要一致性檢查），以及當有人需要閱讀答案失敗原因時。
• 皆不使用 若程式能準確檢查該標準。若決策具有重大影響且新穎，應由人工處理。

文章其餘部分將說明數字來源及兩種判決者行為的原因。

兩種不同的答案

LLM 判決者是一種生成模型。你給它評分標準和輸出，模型會寫出文字。若要求 JSON，則寫出 JSON；若要求信心數值，則寫出數值。判決書的每一部分，包括信心，都由模型產生的文字。數值是寫出的，而非測量得到的。

Jev 是一種決策模型。你不會請它寫任何東西。你向它提出固定問題，並給定固定答案集合，模型會回傳每個答案的機率。問題有三種形式：

兩個請求看起來相似。以下是同一個忠實度評分標準，分別以兩種方式詢問。

// LLM judge: a prompt, and a verdict parsed out of the text that comes back.
const verdict = await chat.chat.send({
  chatRequest: {
    model: '~openai/gpt-luna-latest',
    temperature: 0,
    responseFormat: { type: 'json_object' },
    messages: [
      { role: 'system', content: `Grade the answer. acceptable = ${RUBRIC_TRUE} unacceptable = ${RUBRIC_FALSE} Reply with JSON: {"acceptable": true|false, "confidence": 0 to 1}` },
      { role: 'user', content: `knowledge: ${knowledge}\n\nquestion: ${question}\n\nanswer: ${answer}` },
    ],
  },
});
// -> {"acceptable": false, "confidence": 1}

// Jev: a typed question over the same state, and a probability back.
const decision = await decisions.alpha.decisions.create({
  decisionsRequest: {
    model: 'typesafe/jev-1.13',
    state: { knowledge, question, answer },
    questions: {
      acceptable: {
        type: 'noul',
        instructions: 'Does answer directly answer question using only facts that knowledge states?',
        criteria: { true: RUBRIC_TRUE, false: RUBRIC_FALSE },
      },
    },
  },
});
// -> answers.acceptable.noul === 0.01

LLM 判決者的 1 是它寫出的數字。Jev 的 0.01 則是關於頻率的主張：在許多類似答案中，大約 1% 應該被視為可接受。此主張可被驗證。若成立，你可以設定閾值，將不確定的中間值交給人工處理，並推估錯誤率。若不成立，機率僅為裝飾。完整的請求與回應格式可見於 Decisions API reference 與 TypeSafe SDK guide。

我們如何比較它們

我們於 2026-09-21 透過 OpenRouter 在兩個公開資料集上跑兩種判決者。整個測試共耗費 $0.041。

忠實度集合。 我們從 QA 分割的 HaluEval (Li et al., 2023) 中挑選 50 行，每行包含一段短文、一個問題、一個正確答案和一個虛構答案，總共 100 答案。我們請 Devin（執行此實驗的編碼代理）審查每一項與其段落，刪除六行錯亂或模糊的資料，並將八個虛構答案重新標記為可接受，因為段落支援它們。剩下 88 個專案：52 個可接受，36 個不可接受。這是一個封閉的評分規則。證據已掌握，問題在於答案是否遵守它。

摘要集合。 我們從 SummEval (Fabbri et al., 2021) 取得 10 篇新聞文章，每篇都有 5 篇機器生成的摘要。人類專家將每個摘要的連貫度（閱讀是否流暢）和一致性（是否遵守文章事實）評為 1 至 5 分。這是一個更困難、更開放的評分規則，針對更長的文本。

Judges. Jev 以 typesafe/jev-1.13 執行，解析為 typesafe/jev-1.13-20260917。LLM 判斷者以 ~openai/gpt-luna-latest 執行，解析為 openai/gpt-5.6-luna，並輸出 temperature: 0 及 JSON。兩位評審都得到相同的評分標準文字，因此任何差異皆來自模型而非措辭。

對於每一次判斷，我們記錄了裁決、機率、延遲以及回覆中的 usage.cost。對於 LLM 判斷者，我們將「可接受加信心」轉換為可接受的機率，讓兩位評審都使用相同的 0 到 1 範圍。

一致率為平手

在 88 個忠實度專案中，Jev 與標籤一致 84 次，LLM 判斷者一致 83 次。兩者精準度皆為 0.98。兩次失誤是兩位評審都錯誤的同一專案，且標籤均不正確。當兩位評審在同一專案上與你意見不合時，請檢查你的標籤。

若僅看準確率，兩者無法區分。準確率是錯誤的視角，因為它只關注評審落在 0.5 之上或之下，並將 0.51 與 0.99 視為相同。

校準才是兩者的分歧所在

為了檢視機率是否有意義，我們採用兩種觀點。Brier 分數是評審給予的機率與真實 0 或 1 標籤之間的均方誤差，因此在 90% 確信錯誤的評審會比 60% 確信錯誤的評審受到更大懲罰。可靠度表將案例按評審給予的機率分組，並報告這些案例實際上可接受的比例。

Jev 的 Brier 分數為 0.043，LLM 判斷者為 0.054。可靠度表說明瞭原因。

jev:  bin 0.0-0.2: n=34 mean_p=0.04 observed=0.03
      bin 0.2-0.4: n=1  mean_p=0.34 observed=1.00
      bin 0.4-0.6: n=4  mean_p=0.48 observed=0.50
      bin 0.6-0.8: n=7  mean_p=0.74 observed=1.00
      bin 0.8-1.0: n=42 mean_p=0.93 observed=0.98
llm:  bin 0.0-0.2: n=39 mean_p=0.01 observed=0.10
      bin 0.8-1.0: n=49 mean_p=0.99 observed=0.98

Jev 將四個案例放在 0.4 到 0.6 之間，正確率為 50%，這正是 0.5 應該達到的。其評分高於 0.8 的案例，98% 時可接受。LLM 判斷者則沒有中間值。在 88 個案例中，其置信度僅有六個取值（0.82、0.84、0.87、0.98、0.99 和 1），因此每個案例都落在接近 0 或接近 1，且接近 0 的案例只有 10% 可接受。它對錯誤的確信度與對其他情況相同。

實際上，這就是可被路由的評審與只能閱讀的評審之間的差別。Jev 的 88 個案例中，有 7 個落在 0.3 到 0.7 之間，這些正是值得送給人工審核的案例。LLM 判斷者沒有提供此類案例。

成本與延遲相差 5 倍與 10 倍

Jev 每千次判斷成本 $0.021，平均回應時間 171 毫秒。LLM 判斷器每千次成本 $0.114，耗時 1,662 毫秒。若每晚評估 1,000 個專案，成本差距約為每年 $34，這不重要。若判斷器位於請求路徑內並在回答前阻塞回應，延遲差距就非常重要，這也是 Jev 適合作為生產中的閘道，而 LLM 判斷器則適合作為離線評分器的原因。

兩個判斷器都抵抗了經典偏差，Jev 稍微更好

《MT-Bench paper》發現 LLM 判斷器存在兩個常見偏差。他們偏好先顯示的答案，且偏好兩個答案中較長的那一個。這兩項偏差測試成本低，因此我們測試了兩者。

位置。我們對每個判斷器展示相同的兩個答案兩次，第二次以相反順序，涵蓋所有 36 對一可接受與一不可接受答案。對 Jev 來說，這是每個槽位一個標準的選擇題。兩個判斷器在順序翻轉時都未改變選擇。兩者在 72 個排序中正確 70 次，且在兩種順序中都錯過相同的一對，說明錯誤在於標籤而非位置。如果你自己執行此測試，請在最難的對子上進行，兩個答案質量相近，因為位置偏差在此才顯現。選擇標準僅在一個答案可接受、另一個不可接受時才有意義。若兩者都可接受，請將每個標準寫成比較（更具體、更有依據、離問題更近）而非標籤，否則 Jev 沒有合適的選項。

冗長度。我們將每個不可接受的答案加上兩句真實句子，句子從其原始段落複製。加長後的答案仍然錯誤，但平均字數從 69 增至 376。僅保留加長後仍錯誤的對子，因為在少數情況下…

Padding 推動了 Jev。它對錯誤答案可接受的平均機率從 0.08 提升至 0.12，而那個超過 0.5 的案例原本就已經在 0.48。LLM 判斷者翻轉了三個案例，且每個案例都從堅定拒絕轉為堅定接受。這種模式與校準表中的相同。當 Jev 不確定時，它會說出來；當 LLM 判斷者錯誤時，它會堅定地表達錯誤。

LLM 判斷者勝出的地方

情況改變，當判斷者需要閱讀整篇文章時。對於 50 篇 SummEval 摘要，Jev 每個標準都得到一個分數問題，五個等級以標準形式列出；LLM 判斷者則得到相同的五級描述並回傳 1 到 5 的整數。我們將兩者與專家平均值進行 Spearman 相關係數比較，1.0 表示排名完全一致。

連貫性呈平手。一致性，當你在尋找幻覺時關心的標準，則明顯是 LLM 判斷者的勝利。我們的猜測是，檢查一致性意味著逐項檢視摘要並尋找文章對每一項的支援。這對生成模型來說是一個自然的逐步流程，而 Jev 必須在大約 1,000 個 token 的狀態上一次性完成。

Jev 在這裡並非無用。兩位評審都捕捉到所有三個摘要，專家在一致性評分低於4的摘要上，並且在另外47個摘要上沒有誤報，因此 Jev 仍可作為粗略的通過/失敗閘道。但若你想要一個跟隨專家判斷的排名，LLM 評審的訊號更好。Jev 的成本為每千份摘要 $0.043，延遲 168 毫秒，而 LLM 評審則為每千份摘要 $0.261，延遲 2,902 毫秒，因而你為該訊號支付了約 6 倍費用。Jev 在此的成本是其忠實度成本的兩倍，因為每個請求攜帶約兩倍的輸入 token，整篇文章加上兩個 Score 問題，而不是一段短文和一個 Noul。

還有兩種情況適合使用生成式評審，我們未進行基準測試，因為沒有可比對的標準。

• 開放式評分標準。 若問題是「這是一個好答案嗎？」且沒有書面標準，你需要生成式評審。Jev 需要將標準明確寫出，若你無法寫下來，就無法使用 Jev。
• 書面說明。 若審稿人需要了解答案失敗的原因，LLM 評審的推理即為輸出。Jev 只告訴你它的確定程度，除此之外不提供其他資訊。

哪位評審適用於哪種評分標準

LLM 評審有三種替代方案：程式碼中的確定性檢查、Jev 問題，或人工。每項標準選擇一種，而非每個專案選擇一種。

Jev verified cascade cookbook 在生產環境中顯示中間行。 一個廉價模型草擬答案，Jev 問題驗證它，任何在不確定區間內的專案都會被上報。 gate tool calls with Jev cookbook 將相同概念應用於代理的工具呼叫。

設定自己的閾值

我們的資料顯示了權衡的形狀。要設定生產閾值，您需要在自己的資料上進行相同的測量。

1. 標記 50 至 100 個代表您將在生產中執行的專案，並以書面定義什麼算作可接受。
2. 將每一個送給兩位評審，並記錄機率、延遲及 usage.cost。
3. 建立可靠性表格並忽略準確度線。將接受閾值設為您可接受的最低分箱，將介於此與拒絕閾值之間的所有專案送交人員或 LLM 評審。
4. 每當評分標準或模型版本變更時重新執行表格。每個 Decisions 響應中的 model 欄位會告訴您是哪個版本回覆。

Jev model page 提供最新價格與限制，TypeSafe SDK guide 提供完整的 Decisions API 形態，LLM-as-a-judge post 則說明如何最初撰寫評分標準。

如果 Jev 是你第一次接觸，什麼是 Jev？ 會說明這個模型以及它的三種問題型別，Jev 與 LLM 則探討決策模型何時會取代生成式呼叫。為了在另一個任務上進行第二次準確度測試，Jev 在分類上是否與前沿模型同樣準確？ 將 Jev 與 Claude Opus 5 在 Banking77 上做比較。Jev 檔案中心 列出了 OpenRouter 上所有 Jev 指南與料理書。

常見問題

Jev 是一個已校準的評分模型嗎？

Jev 在每一次判斷時都會回傳一個機率，在我們的 88 項忠實度資料集上，這些機率都相當準確。Brier 分數為 0.043，且當 Jev 的機率高於 0.8 時，答案被接受的比例為 98%。校準取決於你正在測量的具體任務，因此在選擇閾值前，請先在自己的標籤上進行測試。

LLM 作為評分者的替代方案有哪些？

當程式能夠決定答案時，使用決定式檢查。對於任何重要或新穎的情況，請讓人員參與。對於封閉評分規則且機率有用的情況，使用像 Jev 這樣的決策模型。大多數生產流程結合了三者。對於開放評分規則且需要書面說明的情況，保留生成式評分者。

什麼時候我還應該使用 LLM 作為評分者，而不是 Jev？

當評分規則是開放式且無法寫下標準時，或者評分需要書面說明，或判斷需要逐步處理長文本時，請使用 LLM 評分者。對於 SummEval 摘要的事實一致性，LLM 評分者與專家分數的相關係為 0.72，而 Jev 為 0.47。

我如何為自己的評估校準 Jev？

標記 50 到 100 個專案，透過 Decisions API 將每個專案以 Noul 或 Score 題型送給 Jev，並記錄每個回應的機率、延遲與使用成本。計算與你標籤的同意度和 Brier 分數，建立按機率區間分組的可靠度表，並從表中選擇閾值。