對應原題（Common ‧ Evaluation and Observability）
- How do you build an eval set when there is no labelled ground truth and experts are expensive?
— Asked at: Cohere, HarveyHarvey 是法律 AI，專家（律師）時薪極高——這題問的不是「怎麼標註」，是「怎麼在標註預算極小的情況下仍然能評估」。
🎯 什麼情境該想到我
當你「想做評估，但一想到要標幾千筆資料就放棄了」的時候。
★ 這題最重要的翻轉：很多評估根本不需要 ground truth。 先窮盡免費的，再花錢。
⚙️ 怎麼用
★ Step 0：先問「評估什麼」，不是「怎麼標」
大量有價值的性質是可以程式驗證的，完全不需要標註：
| 可驗證的屬性 | 怎麼測 |
|---|---|
| 輸出符合 schema / 格式 | JSON Schema、正則 |
| 引用的 span 真的存在於來源 | 字串比對（見 權限感知檢索與引用歸因） |
| 答案沒有超出提供的上下文 | NLI entailment |
| 該拒答的有沒有拒答 | 關鍵字 + 分類器 |
| 有沒有洩漏 PII | 偵測器 |
| 延遲、成本、token 數 | 直接量 |
| 程式碼能不能跑、測試過不過 | 執行（見 GRPO 與 RLVR） |
★ 行為測試：不需要答案，只需要「關係」
（思路源自 NLP 的 CheckList 式行為測試。）你不知道正確答案，但你知道答案之間該有什麼關係：
| 測試類型 | 設計 | 不需要知道 |
|---|---|---|
| 不變性測試 | 把問題改寫（同義詞、語序、加無關寒暄）→ 答案語意應該不變 | 正確答案是什麼 |
| 方向性測試 | 加入否定或反轉條件 → 答案應該跟著反轉 | 正確答案是什麼 |
| 一致性測試 | 同一問題問 5 次 → 答案應該一致 | 正確答案是什麼 |
| 單調性測試 | 提供更多相關上下文 → 正確率不該下降 | 正確答案是什麼 |
| 對照測試 | 上下文中刪掉答案 → 應該改口說不知道 | 正確答案是什麼 |
★ 最後一項是 RAG 系統最有價值的免標註測試：
把包含答案的段落抽掉，看它會不會誠實說「找不到」。
這一個測試就能量出幻覺傾向，而且完全不需要任何標註。
分層策略：成本由低到高
| 層 | 來源 | 成本 | 品質 |
|---|---|---|---|
| 1. 免費訊號 | 真實日誌的隱式回饋：追問＝不滿、複製＝滿意、換個問法重問＝失敗、放棄＝失敗 | 0 | 有偏誤但量大 |
| 2. ★ 既有的金礦 | 已解決的工單、FAQ、內部文件的 Q&A 區、既有的程式碼測試、稽核紀錄 | 0 | ★ 高——先找這個 |
| 3. 合成 | LLM 反向生成（從文件生問題）；見 RAG 評估與營運 | 低 | 中，會太像原文 |
| 4. 弱監督 | LLM 裁判 + 多裁判一致性過濾 | 低 | 中（見 LLM-as-Judge） |
| 5. ★ 主動學習 | 只標「模型不確定 / 裁判互相不一致 / 商業影響最大」的樣本 | 中 | 高 |
| 6. 專家標註 | 人工 | 極高 | 最高 |
★ 第 2 層最常被忽略。
「已解決的工單」就是一組現成的（問題 → 正確答案 → 專家認證）配對，而且反映真實的查詢分布。
面試時先講這一條，比直接跳到「用 GPT 生合成資料」有說服力得多。
★ 專家很貴時：把專家放在對的位置（Harvey 的場景）
| ❌ 浪費專家 | ✅ 善用專家 |
|---|---|
| 讓專家從零寫標準答案 | ★ 讓專家審核模型產出——審核比創作快 5–10 倍 |
| 讓專家打 1–5 分 | ★ 讓專家做 pairwise 比較——更快、更一致（見 LLM-as-Judge） |
| 專家標隨機抽樣 | ★ 專家只標難例（模型不確定、裁判不一致）與校準集 |
| 專家標一次就結束 | ★ 建立迴圈 |
專家迴圈：
專家標 150 筆（校準集）
↓
訓練／校準一個 LLM 裁判，算 kappa 直到達標
↓
裁判跑全量（幾千筆）
↓
抽樣 + 挑出裁判低信心的，回送專家
↓
更新校準集，重新驗證裁判
這樣專家的每一小時都在提升整個評估系統的品質，而不是多標 20 筆。
★ 評估集必須包含的樣本類型（最常漏的）
| 類型 | 為什麼必要 |
|---|---|
| 無答案的問題 | ★ 沒有它，評估會獎勵「永遠給出答案」——也就是獎勵幻覺 |
| 前提錯誤的問題 | 「你們什麼時候取消了退費政策？」（其實沒取消）。測模型會不會順著錯誤前提編 |
| 邊界與長尾 | 罕見但重要的案例 |
| 對抗性輸入 | 注入嘗試、越獄嘗試（見 提示注入與分層防禦） |
| ★ 真實分布的樣本 | 精心設計的題目會讓分數虛高。一定要有一部分直接從真實日誌抽 |
| 回歸案例 | ★ 每一次線上事故都該變成一個永久的測試案例 |
規模：比想像中小
100–300 個好樣本 > 10,000 個爛樣本。
真正該問的是統計檢定力：「我想偵測 5% 的改善，需要多少樣本？」
粗略地說，要偵測的效果量越小，需要的樣本越多；pairwise 比較比絕對評分省樣本。
分成三組：
| 組 | 用途 | 規則 |
|---|---|---|
| 開發集 | 調 prompt、調參數 | 可以一直看 |
| ★ Holdout | 最終驗收 | 絕不用來調參，否則會過擬合 |
| 校準集 | 驗證裁判 | 人工標註，定期重用 |
⚠️ 注意 / 什麼時候不適用
- ★ 合成資料會系統性地高估表現。LLM 生成的問題太像文件用詞、太規範、沒有真實使用者的錯字與模糊。一定要混入真實日誌樣本。
- 隱式回饋有嚴重偏誤。沉默不代表滿意；追問可能是因為有興趣。當趨勢訊號用，不要當 ground truth。
- 評估集會過期。產品變了、語料變了、使用者變了 → 舊評估集失去代表性。要定期更新並記錄版本。
- 不要拿公開 benchmark 當主要評估（見 Benchmark 污染與分數失真）。
- 標註指引比標註者更重要。含糊的指引會產生互相矛盾的標註。先標 20 筆、對答案、修指引，再開始大規模標。
- 先量人類之間的一致性。如果專家彼此只有 65% 一致，那就是你的天花板，別再追求 90%。
🧪 我實際套用的紀錄
- 2026-09-20：從面試題庫展開。待辦：下個專案先找「已解決的工單／既有 FAQ」當免費 ground truth。
🔗 相關
- LLM-as-Judge —— 弱監督的主力，以及怎麼驗證它
- RAG 評估與營運 —— 反向生成與分層評估
- 幻覺偵測 —— 對照測試的延伸
- 上線閘門與線上評估 —— 評估集怎麼變成 CI gate
- Benchmark 污染與分數失真 —— 為什麼不能靠公開基準
- 工具-AI系統評估 —— 決策層