我的知識庫

AI · 2026-08-15

閱讀時間約 12 分鐘

昨天談可觀測性,把代理的黑盒子攤成一棵可重播的 span 樹,回答「它到底怎麼一步步走到這裡」。但重播只給你看清過程,不會告訴你這條路走得好不好——追蹤是眼睛,評估(evaluation)才是判準。今天談代理的評估與評測:怎麼把「好不好」變成一個能自動跑、能回歸(regression)、能擋住上線的分數,而不是每次改完 prompt 都靠人肉試個五六次「感覺還行」。2026 年的現況是,57% 的組織已經有代理在生產環境,而阻擋部署的頭號障礙就是「品質」——評估正是把品質從玄學變成工程的那一關。

📖 學

為什麼只看最終答案會騙你

大多數人評估代理的方式,停在一個 held-out 測試集加上「最終答案對不對」的 pass/fail。這在單輪問答時代夠用,但對代理是危險的。代理的最終答案可能碰巧正確,過程卻一團糟:多繞了三個工具、重複呼叫同一個 API、中途走進死路又僥倖爬出來。反過來,答案錯了,你也不知道是規劃錯、選錯工具、還是工具本身回了壞資料——最終答案是一個把所有資訊壓成一個位元的有損函式。

有一篇 2026 的研究把這種現象命名為「僥倖通過問題(lucky pass problem)」:SWE-Agent 在程式修復基準上「通過」了測試,細看軌跡卻發現它的修改其實沒對準真正的缺陷,只是恰好讓測試變綠。這說明一件事:通過率(pass rate)本身可能是被污染的指標。你需要看的不是終點,而是整條路徑。

三層評估:結果、軌跡、系統

2026 業界大致收斂出把三層評估都當「一等公民」的做法,而不是拿最終答案打發。

第一層是結果評估(outcome eval):任務有沒有達成、答案對不對、有沒有滿足使用者的隱藏目標。這層最接近業務價值,但如前面所說,單看它會漏掉過程。

第二層是軌跡評估(trajectory eval),也是代理評估真正的核心。它評的是「為了得出結論所走過的一連串決策」:呼叫了哪些工具、傳的參數對不對(tool-call correctness)、有沒有多餘或不安全的中間步驟、有沒有陷入迴圈(looping)、遇到錯誤能不能復原(recovery)。軌跡評估又分兩種——**有參考(reference-based)**的做「軌跡比對」,把實際步驟序列跟一條標準答案軌跡對齊評分;**無參考(reference-free)**的則不需要標準軌跡,直接判斷這條路徑本身合不合理。

第三層是系統指標(system metrics):延遲、每次任務的 token 成本、吞吐。這層跟昨天的可觀測性直接接上——span 層級的 token 用量,既是觀測資料,也是評估指標。

LLM-as-judge:好用,但要知道它的毛病

當「對不對」沒有簡單的字串比對可判(例如「這段回答有沒有依據」「這個工具選得合不合理」),主流解法是 LLM-as-judge:再叫一個模型當裁判來打分。LangSmith、Braintrust、Phoenix、DeepEval 都把它當預設評分器。它的好處是能評自然語言品質、能評整條執行路徑,而且用 LLM 當裁判時不一定要提供標準軌跡。

但它有幾個必須正視的偏誤,否則分數會騙你:長度偏誤(傾向給長答案高分)、位置偏誤(A/B 比較時受選項順序影響)、自我偏好偏誤(裁判偏袒和自己同源的模型)、以及非決定性(同一份輸入,兩次打分不一定一致)。加上一次判斷就是一次完整模型呼叫,太貴,不適合掛在每一個生產回合上。務實做法是:離線、抽樣地跑 LLM-as-judge,並且先用人工標註校準過裁判,再拿它去規模化。

Agent-as-a-Judge:讓裁判自己去查證

LLM-as-judge 的裁判只看文字,判不了「這個工具回傳的數字到底對不對」這種需要查證的問題。2026 冒出的新一代做法是 Agent-as-a-Judge:裁判本身是一個完整的代理,能多步推理、能呼叫工具、能主動去環境裡取得可驗證的證據,再對受評代理的整條推理軌跡打分,而不只是看最後輸出。

有一個叫 AJ-Bench 的基準專門評這種裁判代理,橫跨搜尋、資料系統、圖形介面三個領域,收了 155 個任務、516 條標註軌跡,用來測「用代理評代理」到底靠不靠譜。這個方向仍在早期,但它補上了純文字裁判的盲點:當正確性需要跟真實世界對照,裁判也得能動手查。

基準:別只信單一數字

評代理的公開基準各有側重,值得記住幾個代表:τ-bench / τ²-bench 用一個帶著隱藏目標的模擬使用者,測代理在真實領域裡的「工具—代理—使用者」互動;SWE-bench 測真實 GitHub issue 的程式修復;AgentBench 做跨環境的綜合能力評測;AgentLens 這類則專攻「production-like 的完整軌跡審查」,把使用者請求、代理訊息、工具呼叫、檔案編輯、驗證嘗試、復原行為、最終答案與最終倉庫狀態一起看。核心心法是:公開基準會被過擬合、單一通過率會被僥倖污染,真正能守住品質的,是你針對自己場景蒐集的軌跡資料集,加上分層評估。

工具生態

想動手,選型和昨天的觀測工具高度重疊(很多是同一批):LangSmith(和 LangGraph 生態最契合,原生支援軌跡評估,搭配開源的 agentevals 套件)、Braintrust(以評估為核心的計分)、OpenAI Evals(MIT 授權、以 registry 組織測項)、Arize Phoenix(建在 OpenTelemetry 上、能評函式呼叫)、DeepEval(pytest 風格、寫起來像單元測試)、Ragas(專攻 RAG、無參考評估)。選型關鍵不是功能表長短,而是能不能同時吃下「結果 + 軌跡 + 系統」三層,並讓評估能像測試一樣進 CI。

🧠 記

  • 追蹤是眼睛,評估是判準:可觀測性問「怎麼走到這裡」,評估問「走得好不好」,兩者互補、常共用同一批工具。
  • 只看最終答案會遇到僥倖通過問題:通過率本身可能被污染,對的答案可能過程很糟,錯的答案看不出錯在哪。
  • 三層評估都要當一等公民:結果(outcome)、軌跡(trajectory)、系統(system),其中軌跡評估是代理評估的核心。
  • 軌跡評估分有參考(軌跡比對)與無參考;要抓的是工具呼叫正確性、迴圈、冗餘步驟、錯誤復原。
  • LLM-as-judge 好用但有長度/位置/自我偏好偏誤且非決定性、又貴——要離線抽樣、先用人工標註校準;需要查證時升級到 Agent-as-a-Judge。

✍️ 實踐

  1. 先建一個小而真的軌跡資料集:從昨天接好的追蹤後端,撈 20–50 條真實 trace(含成功與失敗),標上「這條走得好不好」與失敗原因。這就是你的評估地基,比任何公開基準都貼近你的場景。
  2. 把評估寫成能進 CI 的測試:用 agentevals 或 DeepEval,先加確定性檢查(必須呼叫某工具、不得重複呼叫、步數上限),再對「答得好不好」這類主觀項掛 LLM-as-judge。每次改 prompt 或換模型就跑一次,擋住回歸。
  3. 校準你的 LLM 裁判:拿人工標好的一小批當黃金集,量裁判和人類的一致率;不到標準就先修裁判的評分準則(rubric),別急著相信分數。同時注意長度與位置偏誤(比較題記得洗牌選項順序)。
  4. 分層看,別只盯通過率:每次實驗同時報結果分、軌跡分、以及 span 層級的 token 成本與延遲——確認你不是用「多花三倍 token、多繞五個工具」換來那一點點通過率。

🔗 延伸學習

💬 問 AI

我想把 AI 代理的「評估與評測(agent evaluation)」做成能上線的工程,而不是每次改完 prompt 靠人肉試。請幫我:
1. 用一個具體例子解釋「只看最終答案 / 通過率」為什麼會騙人,
   包含「僥倖通過(lucky pass)」是什麼、為什麼答案對了過程還是可能壞掉。
2. 說明結果(outcome)、軌跡(trajectory)、系統(system)三層評估各自評什麼,
   以及軌跡評估裡「有參考(軌跡比對)」與「無參考」的差別和適用時機。
3. 解釋 LLM-as-judge 的長度/位置/自我偏好偏誤與非決定性問題,
   我該怎麼用人工標註校準裁判、為什麼要離線抽樣而不是每個回合都判;
   以及什麼情況該升級到 Agent-as-a-Judge。
4. 給我一個從現有追蹤資料撈軌跡、建小型評估資料集、
   用 agentevals 或 DeepEval 把評估寫進 CI 的實作步驟(含確定性檢查與 LLM 評分的分工)。
請用繁體中文、台灣用語,盡量給機制與實例,不要只講抽象概念。

反向連結