如何使用 LLM-as-a-Judge 自動評估 AI Agent 輸出結果

一個代理人可以通過所有決定性測試，卻仍然給出糟糕的答案。客服代理人可以呼叫正確的訂單查詢工具，檢索正確的政策，然後在其回覆中省略退款視窗。工具斷言通過，但並未檢查最終答案是否準確、完整且有用。

LLM-as-a-judge 評估填補了這個空白。第二個模型根據你用簡單語言撰寫的標準審查候選代理的輸出，並返回分數。這為你提供了一種可重複的方法來測試具有多種有效表述的開放式回覆。

LLM-as-a-judge 是什麼

你執行一個候選代理，然後將其輸出及任何相關工具結果交給評審。評審根據你編寫的評分規準對這些證據進行評分。如果分數低於你設定的閾值，評估失敗。

評審是一個與其他模型呼叫相同的模型。它閱讀文本，應用你的標準，並返回一個數字。將該數字視為在固定設定下取得的測量值，而非真實值。

評審模型 vs 候選模型

• 候選模型是待測系統。它回答使用者、呼叫工具，並輸出你關心的內容。
• 評審是獨立的模型。它不解決原始任務。它僅評分候選已完成的工作。

盡量將這兩個角色放在不同的模型上。在 2023 年的論文 “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” 中，鄭等人指出自我提升、位置和冗長偏差。評審可能偏好它自己生成的答案、顯示在首選位置的答案，或更長的答案，無論其質量如何。

只將可見回覆和評審所需的工具結果提供給評審。若評審能看到候選的隱藏推理，評分將不再獨立。

評分規準 vs 完全匹配 vs 人工審核

完全匹配檢查字串或結構化欄位是否與固定值一致。當且僅當只有一個值正確時使用。

在完全匹配與完整評分規準之間，有一個確定性內容檢查，斷言必須出現指定短語。在 Ori Eval 中，這是 run.toMention()。當答案必須包含特定術語但周圍措辭自由時適用。

評分規準是一組簡短的規則，人工可應用。 “引用 14 天退款視窗且不編造例外” 是評分規準。 “聽起來有幫助” 則不是。

人工審核者設定質量標準，但個人無法評分大型評估集的每一次執行，且兩位審核者可能對同一輸出得出不同結論。評審是可重複的替身，你可將其與少量人工標記集合進行比對。

逐點、逐對以及基於參考的評分

LLM 評審可用於三種評估模式：

本指南使用逐點評分，因為每一次執行要麼符合所需標準，要麼低於標準。對於逐對評估，對兩種答案順序進行評分以偵測位置偏差。基於參考的評估適用於參考包含回答必須保留的事實，而非必須複製的措辭。

何時使用 LLM 評審

當需求明確但沒有單一精確輸出時，使用 LLM 評審。範例：

• 以事實為基礎的回覆。 檢查最終答案是否使用檢索到的資料，且不引入未經證實的主張。
• 依照指示執行。 驗證回覆是否符合要求，例如引用政策、詢問缺失資訊或避免執行某操作。
• 完整性。 確認代理人是否涵蓋多部分請求的每一項。
• 語氣。 評估回覆是否符合已定義的支援、法律或品牌語調。
• 工具使用結果。 判斷代理人是否正確使用工具結果，經由確定性測試確認哪些工具已執行。

當結果可直接驗證時，使用 LLM 判斷者並不合適。請使用 JSON 結構的 schema 驗證器、算術計算器以及單元測試來檢查工具引數與副作用。必須始終阻止的規則應保持確定性。判斷者可以審核最終回覆的品質，但不應該是關鍵政策的唯一執行層。

工具呼叫測試可能會斷言代理人只呼叫了 lookup_order 一次，且未經批准從未呼叫 issue_refund。判斷者接著評分代理人最終答案是否準確說明瞭發生了什麼。如果你仍需建立執行層，請從我們的 工具呼叫指南 開始。

使用 Ori Eval 評分代理人

Ori Eval 對你自己的提示與代理行為進行評估。評估是使用 Bun 測試執行器執行的 TypeScript 檔案。Ori 為一次執行解析一個 harness 與一個模型，並在該執行期間保持不變，故提示無法在執行中改變配置。模型比較檔案仍可為每個候選模型啟動獨立執行。

最快的起始方式是透過你的編碼代理。以下指令供代理執行，而非你貼到終端機。請要求代理執行，然後依照其輸出指示進行：

curl -fsSL https://openrouter.ai/skills/spawn-ori-eval

spawn-ori-eval 功能會安裝 Ori，確保你已登入，詢問你想評估的內容，撰寫評估檔，執行候選模型，並推薦一個，附上分數、時間與成本等資訊。它在臨時目錄執行，因此不會將評估檔新增至你的專案。若你想保留檔案於專案或檢查評估的每個部分，請使用以下手動步驟。

Ori 的 setupJudge() 功能會在其自身模型上建立一個獨立的評分代理，而 autoEvals() 則根據你的標準評分候選執行。以下範例測試一個回答退款問題的支援代理。它假設你現有的 Ori harness 能夠連線至支援代理及其工具。

1. 安裝 Ori 並登入

安裝 Ori CLI，然後進行一次認證：

curl -fsSL https://openrouter.ai/labs/ori/install.sh | bash
ori login

Ori 以 Bun 執行評估檔。如果未安裝 Bun，ori eval 會請求安裝許可。在 CI 或其他非互動環境，指令會停止並顯示如何安裝 Bun。你的應用程式不需要是 TypeScript 專案。

2. 定義一個可觀測的品質需求

從你曾見過或想要避免的失敗開始。以此為例，代理必須引用 14 天退款期限，且不得編造政策例外。

此標準比「給予有幫助的答案」更嚴格，因為任何人都能應用它而不必猜測什麼算是有幫助。它同時列出所需證據與失敗條件。

3. 建立評估

建立 evals/support/refund-quality.eval.ts：

import { test } from 'bun:test';
import { setupAgent, setupJudge } from 'ori/eval';

const agent = setupAgent();
const judge = setupJudge({ minScore: 0.8 });

test('explains the refund policy accurately', async () => {
  const run = await agent.run('Can I refund a digital order that I placed 10 days ago?');

  run.tool('lookup_refund_policy').toBeCalled();
  run.toComplete();

  await judge.autoEvals({
    criteria:
      'States the 14-day refund window, answers the question directly, and does not invent exceptions.',
    run,
  });
});

此測試使用兩層評估。run.tool() 與 run.toComplete() 斷言檢查可觀測行為，autoEvals() 評分完成回覆的意義。minScore 設定最低通過分數。此處的 0.8 為起始值。請根據您自己的標記回覆進行校準，可靠性部分將在下方說明。

setupJudge() 以其自身模型評分，與正在測試的模型分開。若要使用不同模型評分，將您自己的代理傳遞給 setupJudge()。Ori Eval 檔案 顯示呼叫方式。

4. 執行評估

從專案目錄執行測試：

ori eval --report eval-report.md

Ori 在目前目錄下尋找 *.eval.ts 檔案，使用 bun test 執行，並以 bun test 的退出碼結束，因此失敗的評估會使指令失敗。--report 標誌會寫入 Markdown 報告，您可與其他測試輸出一起審閱。

LLM 評估會傳送實際模型請求。請將它們放在單獨的 CI 任務中，手動、排程或發布前執行，而不是加入每一次單元測試。將 OPENROUTER_API_KEY 存為倉庫機密。設定該變數後，Ori 在 CI 中不需要 ori login。在 CI 中執行評估 節點包含完整的 GitHub Actions 範例。

比較相同代理在不同模型中的表現

一旦逐點評估可用，您可以將其應用於多個候選模型。執行時保持標準與評審不變。將 { model } 傳遞給 setupAgent() 以選擇該次執行的模型，故以下每次迭代都會使用其自身模型對同一標準與評審進行評估。

import { test } from 'bun:test';
import { candidateModels, setupAgent, setupJudge } from 'ori/eval';

const judge = setupJudge({ minScore: 0.8 });

const candidates = await candidateModels({
  limit: 5,
  maxPromptPrice: 0.000005,
});

for (const model of candidates) {
  test(`refund policy response on ${model}`, async () => {
    const run = await setupAgent({ model }).run(
      'Can I refund a digital order that I placed 10 days ago?',
    );

    await judge.autoEvals({
      criteria:
        'States the 14-day refund window, answers the question directly, and does not invent exceptions.',
      run,
    });
  });
}

candidateModels() 會從我們的即時目錄返回模型程式碼，因而每個都會被放入測試名稱與 setupAgent({ model })。您可依提示或完成價格、上下文長度、所需引數、輸入模態、品質指標，以及模型是否即將過期來過濾候選。價格按 token 計算，因此 maxPromptPrice: 0.000005 為每百萬輸入 token 最高五美元。

動態選擇對發現模型很有用。對於回歸測試，明確命名候選模型，避免目錄變更時測試比較不同集合；並使用 assertModelIsLive(slug) 以便若模型離開目錄，評估會以明確訊息失敗。將候選、評審、測試架構、評分標準、模型引數與測試資料與每個結果一起記錄。

確保評審可靠

將評審與已被人員標記的範例做比對。未完成此步驟前，其分數尚未驗證。此節其餘部分會隨設定變更保持此檢查有效。

以可觀測證據為基礎撰寫標準

用評審能在回覆中定位的需求取代廣泛的品質標籤。

• 弱。「回覆正確且有幫助。」
• 更佳。「回覆說明 14 天退款期限，使用檢索到的訂單日期，且不宣稱退款已經發出。」

在需要診斷失敗時，將不相關維度分開。單一分數涵蓋準確性、語氣、完整性與格式，能告訴您品質下降，但不說明原因。

Ori 匯出一個 startingCriteria 物件，其中包含可編輯的 accuracy、completeness、instructionFollowing、safety、structuredOutput 與 toneAndVoice 評分標準。將其中一項傳遞給 judge.autoEvals() 作為 criteria 值。將它們視為基礎以進行專化。『使用檢索到的訂單狀態，且不在批准前承諾退款』比一般準確性標準更能告訴評審。

以人員標記的範例校準評審

建立一個包含明確通過、明確失敗與邊緣案例的小型資料集，來自真實代理互動。請負責品質的同仁先對其打分，然後將評審的決策與這些標籤進行比較。

當評審模型不同意時，檢查原因。評分標準可能不夠明確，範例可能暴露缺失的評分條件，或評審模型本身不適合。每當更換評審、標準或評估資料時，都要重複此校準。

將標記好的問答對放入 JSON 檔案，並以 test.each 來驅動它們：

import supportPairs from './support-pairs.json';

test.each(supportPairs)('answers: $question', async ({ question, mustMention }) => {
  const run = await agent.run(question);
  run.toMention(mustMention);
  run.toComplete();
});

保持評估盲測

只給評審模型應用標準所需的資訊。即原始任務、可見答案、相關工具輸出，以及任何可信的參考資料。移除候選模型名稱及其他可能影響評分的訊號。

對於成對評估，將答案位置互換，重複執行比較兩次。若結果改變，請再次檢查結果，而非強行決定勝者。

控制變更並考慮變異

將完整的評分標準與測試資料存入版本控制。將候選模型與評審模型的 slug、測試工具版本、路由設定與生成引數與評分一起記錄。

這樣可以追蹤變更，但並不保證模型輸出為確定性。靠近閾值的微小分數波動可能是正常變異。若在代表性測試集上多次下降，則更有力地證明回歸。

保護生產資料

來自使用者的真實資料比自行創造的提示更適合作為測試案例。在將生產追蹤加入評估資料集前，請先移除個人或敏感資料，並審核相關模型與供應商的資料政策。我們的 資料收集檔案 說明瞭我們的日誌控制與如何處理請求元資料。

管理評估成本

LLM 評審會在每一次評估中加入模型請求，故成本會隨測試案例數、候選模型數及評分維度的增加而上升。

您可以透過以下方式控制成本：

• 在每次提交時執行確定性檢查，並在排程或釋出前執行 LLM 評估。
• 取樣代表性生產追蹤，而非對每一次互動都進行評分。
• 使用一次聚焦的評審呼叫，而非多次重疊的評分標準。
• 在例行回歸檢查時測試較小的候選集合。
• 只傳遞評審模型需要的上下文以套用評分標準。

評審模型不必是可用的最大模型。它需要一致地遵循詳細的評分指示。使用我們的 模型目錄 來比較目前的功能與價格，而不是將固定價格複製進評估。

下一步

先從一個實際失敗案例開始，撰寫另一位審查者可套用的評分條件，並將評審模型測試於人工標記的範例。Ori Eval 指南說明評估檔案格式、candidateModels()、setupJudge()、--baseline 比較，以及在 CI 中執行評估的方式。

對於需要校準機率而非書面結論的封閉條件（例如主張是否有來源支援），決策模型可取代評審呼叫。Jev vs LLM-as-a-Judge 在相同任務上同時測量兩者，並顯示各自的表現。

常見問題

LLM-as-a-judge 是什麼？

LLM-as-a-judge 指使用一個語言模型來評估另一系統的輸出是否符合書面標準。候選模型產生答案，另一個評審模型則對其進行打分。

如何自動評分 AI 代理的輸出？

將代理執行於測試提示，並擷取其答案與相關工具追蹤。將這些證據送給具備特定評分標準的評審模型，然後儲存分數；若分數低於您以人工審查範例校準的閾值，即判定評估失敗。

LLM 作為評審的評估準確度如何？

準確度取決於評審模型、評分標準、任務以及測試資料。LLM 評審能以實用的比例與人類偏好達成一致，但同時也會顯示偏差與輸出變異。於依賴評審進行發布決策前，請先在您自己的人工標註範例上測量一致度。

同一個 LLM 能否評審自己的輸出？

可以，但模型可能偏好自己的風格或重複相同的盲點。盡量使用獨立的評審模型；若必須使用同一模型，請將評審請求分開、隱藏不必要的候選內容，並將分數與人工標籤進行驗證。

什麼樣的評分標準能成為好的 LLM 評審？

好的評分標準會列出可觀察的證據、定義失敗條件，並提供足夠的背景資訊，使評審能夠與具備知識的審閱者作出相同判斷。將「be helpful」替換為具體要求，例如「說明 14 天期限且不編造例外」。

我應該使用逐點還是逐對 LLM 評估？

當每一次代理執行都必須達到固定品質標準時，使用逐點評估。若要比較兩個模型或提示版本，則使用逐對評估。對於逐對測試，請倒轉答案順序以檢查位置是否影響結果。

何時應避免將 LLM 作為評審？

當程式碼能準確決定結果時，請避免使用 LLM。架構、計算、工具引數、許可權以及關鍵執行規則應使用決定性檢查。將評審用於那些檢查無法衡量的語義品質。