Evals (模型評估) 解析：從人工審查到自動化評測的演進

原始來源與檔名：2026-05-21T093221+0800-Evals, explained.md

NAPKIN | 餐巾紙

餐巾紙公式

Effective Eval System = Human Review (Baseline/Intuition) + Code-based Eval (Deterministic checks) + LLM-as-a-Judge (Semantic checks, Calibrated)

公式說明：建立一個有用的 AI 評估系統不能一步登天。必須先透過人工審查找出錯誤模式，再將能用程式碼檢查的 (如 JSON 格式、長度) 寫成 Code Eval，最後把需要語意理解的 (如語氣、相關性) 交給經過人工校準的 LLM Judge。

一句話

不要一開始就盲目追求自動化或設定模糊的「品質分數」。優秀的 Eval 系統始於你親自閱讀輸出、定義具體的 Pass/Fail 標準，最後才是寫程式與呼叫 LLM 來幫你把這些測試自動化。

餐巾紙草圖

[ Eval Evolution Path ]

Phase 1: Manual Review (Eyeballing)
  -> Discover "Oh, it hallucinates dates."
Phase 2: Define specific failure mode
  -> "Date must match input text."
Phase 3: Automate (Code or LLM)
  -> Code: Regex check for date format.
  -> LLM Judge: "Is the date factually consistent with the reference?" (Pass/Fail)

ROUND 1: SKELETON | 骨架掃描

「這篇文章在說什麼」

• 核心問題: 在開發 AI 應用時，如何系統化地判斷「模型這次的輸出是不是好的」？如果無法自動評估，就無法放心部署更新 (無法形成 CI/CD 閉環)。
• 核心答案: 介紹 Offline Evaluation (離線評估) 在 AI 工程循環中的地位。將評估分為三種方法：人工評估、程式碼評估、LLM 裁判，並強烈建議「先人工、再自動化」，且評估標準越具體 (如 Pass/Fail) 越好。
• 論證結構: 評估在 AI 開發循環的定位 -> 評估機制的演化 (手動->定義錯誤->自動化) -> 詳解三種評估方法 (Manual, Code, LLM) -> 解釋有參考 (Reference-based) 與無參考 (Reference-free) 的差異 -> 實務建議 (何時建 Eval、該評估什麼)。

章節骨架

1. AI Engineering Loop: 評估 (Eval) 是連接開發實驗與正式發布的橋樑。
2. 演化路徑: 人工審查 -> 找出特定錯誤模式 -> 建立專用自動評估器。
3. 三種評估方法:
   • Manual: 建立直覺、產生 Ground Truth (黃金標準)。
   • Code-based: 快速、便宜、具決定性 (如 JSON 格式)，但不懂語意。
   • LLM-as-a-judge: 評估語意、語氣，但需要校準且可能與主模型有共同盲點。
4. Reference 依賴: 說明需要標準答案 (Reference-based) 與不需要標準答案 (Reference-free) 評估器的適用場景。
5. 實務指南:
   • 只有反覆出現的錯誤才值得寫成 Evaluator。
   • 偏好使用二元評分 (Pass/Fail) 而非 1-5 分的模糊量表。
   • 成熟系統會混合使用三種方法。

ROUND 2: DISSECTION | 血肉解剖

「憑什麼這麼說」

論證鏈

AI 的輸出是非決定性的 (Non-deterministic) --> 傳統軟體的 Unit Test 無法直接套用 --> 必須建立專屬的 Eval 系統 --> 如果一開始就用 LLM-as-a-judge 評分，容易因為標準模糊而導致 Eval 系統本身毫無參考價值 --> 因此必須從人工閱讀開始，定義出精確的錯誤模式 (Failure Modes) --> 最終將具體的規則轉化為 Code 或校準過的 LLM Judge，實現自動化防護網。

關鍵證據

1. 二元評分優於 1-5 分量表 (Binary > Scaled): 這是極具實戰價值的洞察。要求 LLM 給出 1-5 分往往會產生嚴重的分數飄移 (Drift)，因為 3 分和 4 分的界線在語言模型中極其模糊。強迫定義明確的 Pass/Fail，能逼迫開發者把評估標準寫得非常具體。
2. LLM Judge 的共同盲點 (Shared Blind Spots): 作者警告，如果你用 GPT-4o 產生內容，又用 GPT-4o 來當裁判，它們可能會對同一種幻覺或語氣偏好產生共鳴，導致「自我感覺良好」。因此需要人工標籤 (Human Labels) 來校準。
3. Reference-free 的價值: 雖然多數測試需要標準答案，但無參考評估器 (如：檢查輸出是否有害、是否符合特定語氣) 可以直接部署到生產環境 (Live Traffic) 即時監控，這延伸了 Eval 系統的使用壽命。

隱形假設與邊界

• 隱形假設:
  • 開發團隊擁有足夠的真實數據 (Dataset) 與人力來進行初期的 Manual Review，並建立具代表性的 Ground Truth 資料庫。
• 邊界條件:
  • 文章針對的是文字輸出的 LLM 應用。如果是生成圖像、聲音或高度複雜的程式碼庫 (如上一篇 Goal Engineering 提到的專案層級修改)，單一的 Eval 方法可能不足以涵蓋，需要結合編譯器與終端測試。

ROUND 3: SOUL | 靈魂提取

「還能怎麼用」

• 知識連接: Evals 是落實《Goal Engineering》中「深度測試 (Depth Tests)」的底層機制。當你在 Rider 裡寫下 lifecycle_fail_truncates_suffix 這樣的測試名時，你就是在定義一個 Binary Pass/Fail 的 Code-based Evaluator。
• 行動觸發: 檢視你目前 AI 專案的測試方法。把那些寫著「評估這個回答有多好 (1-10分)」的 prompt 砍掉。把它換成 3 個具體的 Yes/No 問題：「是否有引用來源？」、「是否超過 500 字？」、「是否包含髒話？」。

AI 系統的自動化測試架構 (Architectural Deep Dive)

前言

如果說 TDD (測試驅動開發) 是現代軟體工程的基石，那麼 Evals (評估系統) 就是 LLM 應用開發的 CI/CD 防護網。在非決定性 (Non-deterministic) 的模型面前，如何建立高信賴度的測試架構，是區分玩具專案與企業級應用的分水嶺。

核心架構洞察

1. 測試左移 (Shift-Left Testing) 與資料飛輪

文章描述的 AI Engineering Loop，本質上是一種持續整合 (Continuous Integration) 的架構。

• Dataset 是一切的基礎：沒有穩定的資料集，Eval 就是在對空氣揮拳。人工審查的最終目的，是產出高質量的 Test Fixtures (測試治具)。
• 當這些 Eval 腳本 (Code or LLM Judge) 被整合進 Pipeline 時，我們就能在每次修改 Prompt 或更換底層模型 (如從 Claude 3.5 換到 GPT-4o) 時，瞬間知道系統的退化 (Regression) 情況。

2. 評估器的職責分離 (Separation of Concerns in Evals)

優秀的系統架構不依賴單一組件。作者將 Eval 拆分為 Code-based 與 LLM-based，這非常符合軟體架構的職責分離原則。

• Code-based Eval (Deterministic Logic)：像 Regex、JSON Schema Validator。它們非常便宜、快速 (O(1) 級別的延遲)，應該放在測試鏈條的最前端 (Fail Fast)。
• LLM-as-a-judge (Semantic Logic)：像相關性分析、語氣判斷。成本高、有延遲，應該作為深層的斷言 (Deep Assertions) 使用。
• 將兩者混合使用，既保證了結構的正確性，也兼顧了語意的品質。

3. 校準與對齊 (Calibration as System Tuning)

這篇文章點出了一個常見盲區：LLM Judge 本身也只是一段程式碼，它也可能會有 Bug (幻覺/偏見)。

• 在機器學習系統中，我們不能盲目相信 Metric。
• 必須定期將 LLM Judge 的給分與 Human Baseline 進行比對 (例如計算 F1 Score 或 Cohen’s kappa)。這個「校準」過程，就如同在分散式系統中校準時間戳一樣，是保證測量工具準確性的必要維護工作。

總結

Eval 不是一個外加的工具，它是 AI 應用的定義檔。你怎麼衡量它，它就會長成什麼樣子。摒棄模糊的分數量表，建立具體、二元、可測試的失敗模式 (Failure Modes)，是駕馭 LLM 的關鍵工程能力。