AI Engineer Europe 2026 · 工作坊 · 2026-05-14 · 124 分
替 agent 寫評估的完整流程
Ship Real Agents: Hands-On Evals for Agentic Applications · Laurie Voss，Arize
Laurie Voss 帶學員用 Phoenix 替一個財務分析 agent 做 tracing，再依序寫 code eval、LLM 評審、golden set 與 experiment，示範怎麼靠評估改進 agent。
概要
- 先讀 trace 再寫 evalLaurie 強調要先讀真實輸出、定義「好」的標準，再決定測什麼。Apple 那筆是 agent 想把報告寫進檔案才失敗，只看最終輸出看不出來。
- 三種 eval 疊著用code eval 快又便宜，LLM 評審懂語意但會出錯，人工最準卻不能擴大。Laurie 用 Swiss cheese 模型說明，每一層都有洞，疊起來才擋得住。
- 選對內建 eval同一批 13 筆資料，correctness 全數未過，因為評審模型不知道目前日期；faithfulness 則 13 筆全過。自訂的 actionability eval 才抓到報告缺買賣建議。
- 評審本身要被驗證把評審當分類器，用人工標註的 golden data set 比對，看 precision 與 recall；Laurie 也提醒位置、長度、自信與自我偏好等偏誤，並以人與人的一致性為基準。
- 用 experiment 爬坡把失敗的 trace 做成 data set，依評審的解釋改 prompt，再只對失敗集重跑。六筆原本失敗的在示範中全部轉對。
- 投入多少看用途Laurie 說 12 到 20 個樣本能看出方向，要做出貨決定則以 200 到 400 個為目標；優先順序是資料品質、prompt、模型選擇，最後才是超參數。
原話
▶ 09:50“Whereas if you have a suite of evals, you can just run a regression and know whether or not it is safe to upgrade.”
有一整套 eval，跑一次 regression 就知道升級模型安不安全
▶ 1:03:09“Choosing the right eval can matter more than tuning your evals.”
選對 eval，比調校 eval 更重要
▶ 1:15:51“An eval that you haven't validated is just a fancy way of being wrong at scale.”
沒驗證過的 eval，只是大規模出錯的花俏做法
▶ 1:21:15“it is the encoded judgement of the people who know your domain the best.”
golden set 不只是測試資料，而是最懂領域的人的判斷經過編碼
▶ 1:45:03“Nobody has your evals but you.”
除了你，沒有人擁有你的 eval
延伸
- Laurie 說人工標註大約一半的時間會出錯，因為整天只做測試的人很容易疲勞漏看，所以人力主要拿來建 golden set。
- 人與人之間的一致性（inter-rater reliability）常只有 0.2 到 0.3，所以 Laurie 說評審和你的一致性能到 0.4 就很好了。
- CoreBench 的細節：Opus 起初只拿 42%，問題之一是 eval 要求答案 96.12，模型答 96.124991 就被判錯；修好 eval 後分數跳到 95%。
- 成本標準化準確率的算例：準確率 92%、每次 $0.02 的 agent，可能比 95%、每次 $0.15 的更划算。
章節
點時碼直接跳到原片的那一段。
- 開場與議程Laurie Voss 自我介紹，說明這場 workshop 的路線：從 tracing 到三種 eval、meta-evaluation，最後是 data set 與 experiment。
- eval 是什麼、為何要Laurie 把 eval 當成測試，trace 當成 log，span 是 trace 的組成單位；只靠憑感覺測試，換 prompt 或換模型時抓不到退步。
- 三種 eval 的分工code eval 快、便宜、可重現但容易脆；LLM 當評審懂語意但貴又不穩；人工最準卻不能擴大，三者要一起用。
- agent 的連鎖失敗agent 會走多條路徑，一步走偏後面全錯；多 agent 還要檢查路由與交接。eval 也不能規定太死，否則 agent 找到更聰明的路就會誤判。
- capability 與 regressioncapability eval 是給 agent 爬的坡，滿分後就轉成 regression eval；LLM 評審多給一欄解釋，讓人知道該改什麼。
- Phoenix 與 agent 設定介紹 Phoenix 與 OpenTelemetry、OpenInference，兩行 register 程式碼就能自動收集 trace；現場穿插幾位學員的設定問題。
- 財務分析 agent 與 trace示範用 Claude Agent SDK 寫的兩階段財務分析 agent（研究、寫報告），跑 Tesla 後在 Phoenix 裡看每個 span 的輸入輸出。
- 測試查詢與需求定義跑 12 組不同 ticker 與焦點的查詢，刻意放進比較分析與未上市公司；寫 eval 前先讀 trace、寫下「好報告」的標準，沒有真實資料就用合成資料。
- 讀 trace 找失敗Apple 那筆因為 agent 想把報告寫進檔案而失敗，多筆重複出現；NVIDIA 報告沒給買賣建議；Rivian 的數字可疑，要查來源。
- 失敗分類與優先序把失敗歸成幾類，用嚴重程度乘以頻率排優先；再用 Swiss cheese 模型說明為何要把多層防線疊在一起。
- 第一個 code eval用 regex 檢查報告有沒有提到該公司的 ticker，13 筆中 11 筆通過；沒過的包括 Amazon 那筆通篇只寫 AWS。
- 內建 correctness evalLLM 評審由評審模型、prompt 模板、資料三部分組成；correctness 跑出 0 比 13，因為評審模型不知道目前日期，這個內建 eval 不適用。
- faithfulness eval把第一階段的研究輸出當作 context，檢查報告有沒有只根據研究內容寫；結果 13 筆全過，同樣是內建 eval，訊號卻完全不同。
- 自訂 rubric 的五要素好的 rubric 包含評審角色、明確標準、清楚標示的資料、有標籤的範例，以及受限的輸出；分數量表效果差，二元或三分類較好。
- 跑 actionability 評審用 ClassificationEvaluator 把 rubric 變成評審，結果有不少報告被判為不可執行，成了適合爬坡的 capability eval；也可依延遲、token、成本篩選。
- 把 eval 當程式碼管prompt 版本要留存並用已知答案驗證；不要寫一個包山包海的評審，要一個維度一個；也要分清楚 guardrail 與 North Star 指標。
- meta-evaluation 與黃金集把評審當分類器，拿人工標註當基準；建 golden data set 時標準要具體、有參考答案、兩個方向都測，並切出沒看過的資料防過擬合。
- precision、recall 與偏誤用垃圾郵件說明 precision 與 recall 的取捨，示範算出評審的數字（樣本太小不能當真）；列出位置、長度、自信與自我偏好四種評審偏誤。
- 以人為基準評審應與人比一致性，而非追求完美；失敗要讓人覺得公平，並以 Opus 在 CoreBench 的例子說明問題可能出在 eval。
- data set 與 experiment把失敗的 trace 加進 data set，依評審解釋修改研究與寫作 prompt，再只對失敗集跑 experiment，六筆失敗全部轉對。
- closed loop 與樣本數提到讓 Claude Code 用 eval 回饋自動改 app 的 closed-loop；再用信賴區間的算例說明要幾個樣本才夠下出貨決定。
- 優先順序與 eval 先行impact hierarchy 依序是資料品質、prompt、模型選擇、超參數；談 eval-driven development、讓非工程角色參與，以及 data flywheel。
- 進階技巧與收尾建議簡介線上監控、分層選模型與成本標準化準確率、pairwise 評估、pass@k；最後建議從讀 trace 與寫一個 code eval 開始。
- Q&A：成本與評審設計聽眾問 eval 在哪裡執行，Laurie 說 Phoenix 在 client 端跑再回傳伺服器；問評估成本怎麼控制，答案是 regression eval 砍掉八成仍有代表性，該花錢的是 capability eval；問自訂評審要不要拆成多個，則要看利害關係人怎麼定義「正確」。
- Q&A：迭代與全量重跑建議一次只爬一個 capability eval，其餘留作 regression；改完 rubric 先用小的失敗集做 experiment，快出貨時再跑全量。
- Q&A：closed-loop 優化有聽眾問自動優化的走向；Laurie 說這是目前的前沿，還很難做起來，所以這場沒有示範。
名詞
- Arize Phoenix
- Arize 的開源 AI 可觀測性平台，收集 trace、儲存 eval，並提供介面與 experiment 功能
- Phoenix Cloud
- Phoenix 的雲端版，這場 workshop 用它免安裝收 trace
- trace / span
- trace 記錄 AI 應用執行時的每一步，span 是其中一步，例如一次 LLM 呼叫或工具呼叫
- OpenInference
- 建在 OpenTelemetry 上的延伸，補上 prompt、completion、token 數、模型等 LLM 專屬欄位
- Claude Agent SDK
- 這場示範 agent 使用的簡單 agent 框架，agent 用 Claude Haiku，評審用 Sonnet
- LLM as a judge
- 用第二個 LLM 依 rubric 評分另一個 LLM 的輸出，會附上解釋
- rubric
- 評審用的規則，本質上就是一份 prompt
- golden data set
- 由人標註的已知答案集，用來檢查評審準不準
- capability eval / regression eval
- 前者是 agent 還做不好、要爬的坡；後者是已經通過、要確保不退步的測試
- meta-evaluation
- 檢驗評審本身是否可信，做法是和人工標註比對
- Swiss cheese model
- 把每層防線看成有洞的起司片，疊起來洞就對不上
- pass@k
- 衡量 k 次嘗試中至少成功一次；pass^k 則要求 k 次都成功
