Agent 怎麼做 Eval?從離線評測到線上灰度的可靠性驗證方法

半年前我們接手一個 agent 專案,前一版是靠「工程師自己聊幾句、覺得順就上線」驗收的。上線第三週,財務部門那邊回報:同一個報表查詢問題,agent 有時給對數字,有時把上一季當本季,還有一次連續呼叫了 11 次工具、燒掉一分半鐘才回一句「我不確定」。沒有人說得出它到底哪裡壞了。因為根本沒有可以回歸的測試集。

這就是我們今天要拆的事:AI agent eval 評測,不是玄學,而是把「好不好用」拆成一組可以量、可以回歸、可以在每次改 prompt 或換模型後重跑的數字。

先講定義:Agent Eval 是什麼

Agent eval,是針對「會自己規劃、呼叫工具、多步執行」的 AI agent,用一組固定測試案例去量測它在任務成功率、工具使用正確率、成本與延遲等維度上的表現,並讓這組量測可重複回歸。關鍵字是「可回歸」——你今天量的分數,下週改完 code 要能一模一樣地再量一次,分數升了還是降了,一翻兩瞪眼。

一般聊天模型的 eval 看單輪回答對不對就夠了。Agent 不行。Agent 會走一條軌跡(trajectory):讀問題、決定叫哪個工具、看回傳、再決定下一步。中間任何一步歪掉,最後答案都可能錯,而且錯得很難追。所以 agent 的評測要同時看「結果對不對」和「過程做了什麼」。

四個必量的指標

我們給客戶做的第一件事,永遠是把模糊的「準確率」拆成幾條各自獨立的線。混在一起你永遠不知道該修哪。

這四條要分開看的理由很實際。我們遇過任務成功率有 88% 看起來還行,但工具正確率只有 62%——它是靠模型「猜」把答案兜對的,換一批新問題立刻崩。也遇過成功率很高,但 P95 延遲 40 秒,使用者早就關掉視窗了。單看一個數字會騙你。

延遲和成本一定要放進 eval,不能等上線才發現。一個會自己決定要不要多叫幾次工具的 agent,成本是浮動的。我們習慣同時記錄每個案例的 token 用量和工具呼叫次數,把「那 5% 燒最兇的案例」揪出來單獨看,通常問題就藏在那。

離線評測:先建一個會回歸的測試集

離線 eval 就是準備一批固定的輸入,連同「正確答案」或「正確軌跡」,離線跑一遍打分。它便宜、快、可重複,是所有改動的第一道關卡。

建測試集有三個我們踩過雷的原則。第一,案例要從真實 log 撈,不要自己憑空編漂亮題目——真實使用者會打錯字、會問模稜兩可的東西、會一次問三件事,這些才是 agent 真正會死的地方。第二,一定要放進「陷阱案例」:資料庫查不到、使用者故意問超出範圍、工具回傳空值。好的 agent 要會說「我做不到」,而不是硬掰。第三,每修好一個線上 bug,就把那個案例補進測試集,讓它變成永久的回歸守門員。這是測試集會越養越值錢的關鍵。

打分方式,能用程式判的就別用人判。數字、SQL 結果、API 是否被正確呼叫,這些直接寫斷言(assertion)。真的需要判斷語氣、完整性這種主觀項,才用 LLM 當裁判(LLM-as-judge),但要清楚它本身也會錯,得先拿人工標註對過一輪,確認裁判本身可信。

線上灰度:離線過關不等於上線安全

離線分數再漂亮,都只是實驗室數據。真實流量永遠有你想不到的輸入。所以我們從不「離線通過就全量上線」,而是走灰度(canary):先放 5% 流量給新版本,線上盯三組訊號——任務成功的代理指標(例如使用者有沒有追問、有沒有轉人工)、延遲與成本、以及錯誤率。跟舊版並排比,穩住了再往 20%、50% 推。

線上還要記軌跡。每一次真實對話的完整步驟都留存,一方面出事能回放追根因,另一方面這些就是下一批測試集的原料。離線和線上不是兩件事,是一個閉環:線上撈案例 → 補進離線測試集 → 改完回歸 → 灰度放量 → 再撈案例。

回到開頭那個燒 11 次工具的 agent。我們做的不是重寫,是先花兩天把它過去的對話 log 整理成 120 個回歸案例,量出來工具正確率只有 71%、P95 延遲 38 秒。修完再量,成功率從 74% 拉到 93%,延遲砍到 9 秒。整個過程沒有一次「我覺得這樣比較好」,每個決定背後都有一個會回歸的數字撐著。

我們在 Tenten 做 agentic 工作流導入時,evaluation 不是上線前補的作業,是第一天就跟客戶一起建的資產。因為 demo 那天大家都會點頭,但真正扛得住生產線的,是那組你敢每天重跑的測試集。