昨天談上下文工程,讓 agent 更會分配注意力;但「更會用注意力」只是假設,真正要回答的是:它到底做得好不好？這就是評估(evals)的問題。評估不是專案收尾才補的一份報告,而是你每改一次 prompt、換一次模型、加一個工具時,拿來判斷「這一改是變好還是變壞」的量尺。沒有這把尺,你所有的優化都只是憑感覺。今天把 LLM 與 agent 的評估講清楚:為何準確率不夠、離線基準與線上評估的差別、用模型當評審(LLM-as-a-judge)的做法與偏誤、針對 agent 的軌跡評估,以及最容易踩的坑。
📖 學
傳統準確率為什麼不夠用。 分類任務有標準答案,一句話對錯分明,算 accuracy 很自然。但生成式任務沒有唯一正解:同一個問題,「台北今天會下雨,建議帶傘」和「根據氣象預報,降雨機率高,外出宜備雨具」都是好答案,字面卻完全不同。這時 BLEU、ROUGE 這類比對字面重疊的指標會嚴重低估,因為它們懲罰「說法不同但意思對」的回答。更麻煩的是,我們真正在意的往往是「有沒有幫上忙」「有沒有依據」「語氣合不合場合」這類無法用單一數字表達的品質。所以現代評估的第一步,是先想清楚「這個任務的『好』到底指什麼」,再去挑量法,而不是反過來拿現成指標硬套。
離線基準 vs 線上評估。 兩者回答不同問題。離線基準(benchmark)是在固定的測試資料集上跑,例如常見的 MMLU、GSM8K、或你自己整理的黃金資料集,好處是可重現、可比較、可以在 CI 裡自動跑;缺點是資料集會過時,而且可能早已被灌進訓練資料(所謂 benchmark 汙染),分數漂亮不代表真實表現好。線上評估則是拿真實流量來看,例如 A/B 測試比較兩個版本的使用者滿意度、任務完成率、重試率、對話輪數,好處是貼近真實,缺點是慢、有噪音、且要等使用者。實務上兩者要搭配:離線基準當「上線前的迴歸測試門檻」,線上評估當「上線後的真相來源」,離線通過只是拿到出場資格,不是保證。
LLM-as-a-judge:用模型當評審。 既然人工評分貴又慢,就讓另一個強模型來打分。做法通常是給評審模型三樣東西:題目、待評的回答、一份評分準則(rubric),請它依準則逐項打分並給理由。它的好處是快、便宜、可規模化,且和人類偏好的整體相關性相當高——MT-Bench 那篇奠基論文就顯示 GPT-4 這類評審與人類判斷的一致率能超過八成。但它有系統性偏誤,務必知道:位置偏誤(成對比較時偏好排在前面或後面的那個,和內容無關)、長度偏誤(偏好較長、看起來較完整的回答,即使沒更好,實測長度偏好幅度明顯高於人類)、以及自我偏好(評審模型偏袒和自己風格相近、甚至自己家族產出的回答)。緩解方式包括:成對比較時把兩個答案的順序對調各跑一次取平均以抵消位置偏誤、在 rubric 裡明確要求「不因長度加分」、以及盡量用與受測模型不同家族的評審。
一個具體的 rubric 範例會長這樣。假設任務是「客服回覆」,評審 prompt 裡可以放五條、每條 0–2 分:(1)正確性:資訊有無錯誤;(2)完整性:有沒有回答到使用者真正的問題;(3)依據:關鍵說法有沒有引用知識庫來源;(4)語氣:是否禮貌、符合品牌口吻;(5)安全:有無亂承諾或洩漏不該說的內容。滿分 10 分,並要求評審「先逐條寫一句理由,再給分」——強迫它先說理由能明顯減少隨口亂給分。
針對 agent 的軌跡評估。 評估 agent 和評估單次 LLM 呼叫是不同問題。agent 會產生一條軌跡(trajectory):一連串推理、工具呼叫、中間結果,最後才給出答案。所以除了看「最終答案對不對」,還要看過程。常見有三個層次的量法:任務完成率(session 級:整段對話有沒有達成使用者目標)、工具呼叫正確率(是不是選對工具、參數對不對、該叫的時候有沒有叫)、以及軌跡品質(有沒有繞遠路、重複呼叫、無效步驟)。任務成功率的算法很直白:準備 100 個有明確成功條件的測試任務(例如「幫我把這張發票的金額填進試算表 B2」,成功條件是 B2 等於正確金額),跑完後數有幾個達標,成功率就是達標數除以 100。工具呼叫可以用「和黃金軌跡比對」的方式評:預先標好每個任務理想的工具序列,再比對實際序列的重疊。
黃金資料集、人工標註與迴歸測試。 evals 的基礎是一份高品質的黃金資料集(golden set):一批有代表性的輸入,配上人工確認過的期望輸出或成功條件。它不用大,50–200 筆用心標的,常比幾千筆隨便抓的更有用。建好之後,每次改動都拿它重跑,分數掉了就擋下——這就是迴歸測試,防止你「修好 A 卻弄壞 B」。黃金資料集要定期補進線上真實遇到的難例(edge cases),否則會慢慢和真實分布脫節。
下面這張表整理三種評估手段的取捨:
| 手段 | 速度/成本 | 客觀性 | 適用時機 |
|---|---|---|---|
| 人工標註 | 慢、貴 | 最高(但有主觀) | 建黃金集、校準判準 |
| LLM-as-judge | 快、便宜 | 中(有偏誤) | 大量離線與線上評分 |
| 程式化檢查 | 最快、幾乎免費 | 最高(限可判定項) | 格式、數值、工具參數等硬指標 |
常見陷阱。 第一,拿訓練/開發集當測試集,分數虛高;測試集要嚴格隔離。第二,只看平均分,忽略分布——平均 8 分可能藏著一批 2 分的災難案例,要看最差的那群。第三,rubric 寫得模糊,不同批次評分無法比較;rubric 要具體到「什麼情況扣分」。第四,只評最終答案不評軌跡,結果 agent 靠運氣猜對、過程一團亂,換個題目就崩。第五,evals 本身沒被驗證——你得先確認「LLM 評審的打分和人類標註相關」,再信任它的分數,否則是拿一把沒校準的尺在量。
🧠 記
- 生成式任務沒有唯一正解,字面比對(BLEU/ROUGE)會低估「說法不同但意思對」的答案;先定義「好」再挑量法。
- 離線基準可重現、適合當 CI 迴歸門檻,但會過時、會被汙染;線上評估貼近真實但慢且有噪音,兩者要搭配。
- LLM-as-a-judge 快又便宜、與人類整體相關性高,但有位置偏誤、長度偏誤、自我偏好三大系統偏誤。
- 緩解偏誤:成對比較對調順序取平均、rubric 明令不因長度加分、用不同家族模型當評審、要求先給理由再給分。
- agent 要做軌跡評估,分三層:任務完成率、工具呼叫正確率、軌跡品質;不能只看最終答案。
- 黃金資料集不用大,50–200 筆用心標的即可,要定期補線上難例,配迴歸測試防止改壞。
- 最容易忘的一步:先驗證你的 evals 本身可信(評審分數要和人類標註相關),再拿它下決策。
✍️ 實踐
挑一個你自己每天在用的 AI 任務(例如「把郵件整理成待辦」「幫程式碼寫 commit message」「翻譯段落」),今天做完這件事:先寫出 5 條評分 rubric,每條標明 0–2 分的判準(例如翻譯任務:忠實度、流暢度、術語一致、語氣、無漏譯),總分 10 分。接著準備 5 個真實輸入當迷你黃金集,用兩個不同模型各跑一遍,再用第三個模型當評審依 rubric 逐條打分並寫理由。比對兩個模型的平均分與最差案例,並人工抽看兩三筆評審給的理由對不對——如果評審的理由你不認同,就回頭修 rubric。這一輪下來,你會第一次擁有「這個任務該用哪個模型」的量化依據,而不是憑印象。
🔗 延伸學習
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., 2023) — LLM-as-a-judge 的奠基論文,含位置/長度/自我偏好偏誤分析。
- How to evaluate your agent with trajectory evaluations — LangChain Docs — 軌跡評估的實作說明。
- LLM Agent Evaluation Metrics in 2026: Tool Calling, Task Completion, Trace-Based Evals — Confident AI — agent 評估指標的完整整理。
- Agent Trajectory Evaluations — Arize AX Docs — trace 與 session 層級評估的做法。
💬 問 AI
我想為我常用的一個 AI 任務建立評估機制,請幫我:
1. 我的任務是「（填入你的任務，例如把會議記錄整理成待辦清單）」，請幫我設計一份 5 條、每條 0–2 分的評分 rubric，並標明每條在什麼情況扣分。
2. 說明我該用 LLM-as-a-judge 還是程式化檢查來評每一條,以及為什麼。
3. 提醒我這個任務用 LLM 評審時最可能遇到哪些偏誤,以及具體怎麼緩解。
4. 給我一個最小可行的迴歸測試流程:黃金集要幾筆、多久重跑一次、分數掉多少該擋下。