能不能量化「這次改動到底有沒有變好」，是「玩 AI」和「把 AI 放進 production」的分水嶺。 單元測試驗證「這段程式碼對不對」；eval 驗證「這個 AI 功能的輸出品質好不好」——後者是機率性、多維度、沒有單一 ground truth 的問題，這正是它需要一套獨立方法論的原因。這是所有 AI 技能的第三塊地基（另兩塊是 Context Engineering 與 委任溝通術）。
核心方法（Anthropic 官方，一手）
出自 Demystifying evals for AI agents：
- 從 20–50 個「真實失敗案例」起步，不要等湊到幾百個才動手。「每次系統改動的效果通常明顯，大 effect size 讓小樣本就夠用。」
- 任務品質判準：好的任務是「兩個領域專家會獨立得出相同 pass/fail 判定」——描述不清的任務本身就是 eval 失敗的來源。
- 每個任務要有 reference solution（證明題目可解、也驗證 grader 沒寫錯）。
- 雙面測試：同時測「該做時有沒有做」與「不該做時有沒有亂做」。只測前者，會訓出一個「什麼都要搜尋」的 agent。
- 先懷疑 eval，再懷疑模型：Opus 4.5 在 CORE-Bench 因僵化評分把「96.12」判錯、加上題目規格含糊，修掉評分 bug 後分數從 42% 跳到 95%——不是模型變強，是評測有缺陷。
Best practices
- 三層驗證（Hamel Husain）：Level 1 unit tests（快、每次 commit 跑）→ Level 2 human & model eval（需 trace logging + 低摩擦看資料工具）→ Level 3 A/B（保留給成熟產品）。成本 L3 > L2 > L1，執行頻率反過來。
- 把「好」拆成獨立維度（Braintrust）：客服回覆要同時正確、有同理心、簡潔、合規——四個維度各自打分，避免優化語氣時悄悄犧牲正確性。原則是 one dimension per scorer。
- 移除看資料的所有摩擦：真實案例 Rechat/Lucy 靠純 prompt engineering 撞牆（像打地鼠、無法量化、prompt 越補越腫），自建內嵌 trace/篩選/可編輯輸出的評測工具才突破。
- Regression eval 維持近 100% 通過率（「這 agent 還處理得了它以前處理得了的事嗎？」）；能力評測衝到高檔後「畢業」轉成 regression suite。
- 通過率是產品決策，不是技術目標——100% 通過率不是必要目標。
LLM-as-judge：設計與校準
- 判斷「一致率」別迷信單一數字：常被引用的「GPT-4 judge 與人類一致率 85%、高於人類彼此的 81%」高度領域依賴——飲食營養領域只有 68%、心理健康只有 64%。用自己的 100–300 筆人工標註樣本重測再決定要不要信任。
- Anthropic 官方 judge 設計：給 judge「不知道」的退路；每維度獨立評分；給結構化 rubric；判斷要根基於真實來源；設計 partial credit（找出問題並驗證身份但沒退成款，明顯優於一開場就失敗）。
- 五種 judge 偏誤（position / verbosity / self-preference / format / calibration drift）都要用校準集測、翻轉率 >5% 即有偏誤；重大決策改用跨模型家族的三 judge ensemble；judge 絕不能與被評對象是同一個模型。
- Agentic/多輪評測：評軌跡（工具序列、重試）而非只評最終答案，但別死板檢查工具順序——「agent 常找到 eval 設計者沒預期的有效解法」。對面向使用者的產品用 pass^k（k 次全成功）而非 pass@k。
工具
- Braintrust（eval 為核心，原生 GitHub Action 可在 PR 上跑 eval、分數低於門檻擋 merge）、LangSmith（trace 為核心，LangChain 生態整合最深）、promptfoo（開源，唯一把安全紅隊測試與效能評測綁一起）、OpenAI Evals（將於 2026-11-30 關閉，改用 “Datasets”）。
主張 vs 可佐證
- 可佐證：Anthropic 官方方法（20–50 起步、雙面測試、CORE-Bench 42→95%）；Rechat 自建工具真實案例；offline 分數提升但 A/B 業務變差的案例（offline 只是相關，不是因果）。
- 主張／需領域限定：85% 一致率（有 64–68% 反例）；五種偏誤的量化效應（單一來源 futureagi，方法合理但未經第三方驗證）。
- 需注意立場：Braintrust vs LangSmith 選型建議多出自 Braintrust 自己。
- 陷阱：Goodhart’s Law——指標變成目標就不再可靠；LLM 輔助人工標註會提高標註者自信卻不加速、還引入定錨偏誤。
Eval 是 Spec-Driven 的驗收自動化、也是 AI-Native 產品 迭代的引擎（eval-driven development）。它與 測試生成 的差別：測試驗程式碼對錯，eval 驗機率性輸出的品質。改 prompt/context 後用它量化見 Context Engineering。