AI Engineer Europe 2026 · 演講 · 2026-05-27 · 19 分
評估成熟度的四個階段
The maturity phases of running evals · Phil Hetzel，Braintrust
Braintrust 的 Phil Hetzel 把團隊做 agent evals 的過程拆成四個階段，從憑感覺起步、人工標註，到 LLM judge、tool call 與外部系統，講每一關會碰到什麼。
概要
- evals 的目的是 agent 品質Phil 說做 evals 是為了確認 agent 面對真實使用者時符合預期，擋的是聲譽、成本、合規與法律風險，也能用來看每次調整改善了多少。
- 從失敗模式切入evals 不是 unit tests，不用把所有可能出錯的地方都測一遍，因為那是無限的；先由自己或領域專家指出 agent 的失敗模式，再圍繞它們寫 eval。
- 起步可以靠感覺，但要留紀錄Phil 認為一開始 vibe check 沒問題，只是要請人對輸出給讚或倒讚，並寫下理由，把專家腦中的判斷抽出來，之後才能擴展成 LLM judge。
- 把正式環境當作測試資料Phil 建議把 production 或 UAT 的 traces 收進資料集，讓 eval 像重跑一次 production，並形成「抓 trace、找問題、回到離線重跑」的循環。
- 接上外部系統後，評估對象變成整條 trace要看 agent 的每一步，也要處理離線時不能真的對系統做新增修改刪除的問題，Phil 說這件事目前還沒有完全解決。
原話
▶ 05:08“Sometimes they can be directional.”
有時候結果只要看得出方向就夠了
▶ 06:50“It's not wrong to just get started with vibes.”
憑感覺起步並不算錯
▶ 11:44“Think about evals like rerunning production”
把 evals 想成重跑一次 production
延伸
- Phil 說 LLM 不會因為披上法袍就比較可信，judge 的輸出也要評估；Q&A 裡又補充，judge 的輸出是離散的，所以可以替它建一份 ground truth 資料集。
- 能用程式判斷的失敗，Phil 舉的例子是 tool call 次數太多或 token 用太多，碰到就直接讓 eval 失敗。
章節
點時碼直接跳到原片的那一段。
- 開場與議程午餐後的場次只有 18 分鐘，Phil 說明會把重點放在 agent evals 的成熟度層級，偏理論而不是產品。
- Phil 的背景Phil 在 Braintrust 帶 solutions engineering，之前做過 12 年顧問，先是 KPMG，再是 Slalom，在那裡帶全球的 Databricks 業務單位；是先當過這家公司的使用者才加入的。
- Braintrust 是什麼Braintrust 定位成 agent quality 公司，靠 evals 與 observability 兩條線：前者在上線前建立信心，後者在上線後維持信心。
- 為什麼要做 evalsevals 一切為了 agent quality，防的是聲譽、成本、合規與法律風險，同時也能量出每次調整的進步幅度。
- evals 的基本觀念evals 不是 unit tests，要從失敗模式切入；結果可以只是方向性的，一個 eval 由 task、資料集與評分函式三部分組成。
- 四個成熟階段客戶大致會走過四個階段，更像連續光譜而不是明確分級；agent 越複雜，失敗路徑越多，就會一路往後走。
- 起步：先憑感覺Phil 認為從 vibes 開始比什麼都不做好，唯一的建議是同時留下紀錄。
- 人工標註與理由拿約 10 個範例輸入跑過 agent，請專家對每個輸出給讚或倒讚，並要求寫下理由，把領域知識從專家腦中取出來。
- 歸納失敗模式與 LLM judge理由可以丟給 Cursor、Claude Code 或 Codex 整理出失敗模式；規模化時用 LLM judge，能用程式判斷的就寫成確定性規則。
- 把 production 當測試資料資料集要收 production 或 UAT 的 traces，evals 要像重跑 production，Braintrust 內部把這個循環叫作 flywheel。
- 第二層：加入 tool callagent 開始接外部系統，工具分成取資料與 CRUD 兩類，要評估的不再只是最終輸出，而是整條 trace。
- 離線評估的難題離線跑 eval 時外部系統的狀態已經變了，也不能覆寫正式資料，Phil 說這問題還沒有完全解決。
- 目前的做法可以用 mock API 近似真實環境，把系統狀態塞進 trace，或對向量資料庫下指定時間點的版本查詢。
- 接下來的方向Phil 點出兩個正在出現的做法：大規模 topic modeling 自動找 production 的失敗模式，以及用 Claude Code 搭配 eval 供應商的 CLI 自動化。
- Q&A：主觀的任務怎麼評有聽眾問主觀性高的情況，Phil 建議擁抱 LLM judge，但也要評估 judge 本身，讓它和人的判斷一致。
名詞
- Braintrust
- Phil 任職的公司，自稱是 agent quality 公司，主要做 evals 與 observability
- agent quality
- 這場的核心目標，指 agent 面對真實使用者時是否符合預期
- eval 的三要素
- task（被測的 agent 或 prompt）、資料集、評分函式，Phil 用這三樣描述一個 eval
- failure modes
- agent 會出錯的具體類型，Phil 主張 evals 要先從這些切入
- LLM as judge
- 用 LLM 評估另一個 LLM 的輸出，Phil 提醒 judge 本身也要被評估
- traces
- agent 運作過程的紀錄，有 tool call 之後評估對象就是整條 trace
- flywheel
- Braintrust 內部的說法：抓 production traces、找出問題、帶回離線重跑 eval、再改進 agent
- CRUD-based tools
- 對資料庫或外部系統做新增、讀取、更新、刪除的工具，Phil 把它和取資料的工具分開談
