對應原題（Common ‧ Evaluation and Observability）
- Design an LLM-as-judge evaluation. What are its known biases and how do you correct for them?
— Asked at: Perplexity主要參考：Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023)——
系統性量測了位置偏誤、冗長偏誤與自我偏好。
🎯 什麼情境該想到我
當你「要評估開放式輸出，但沒有標準答案、人類評估又太貴」的時候。
★ 這題的重點全在後半句：偏誤。 只講「用 GPT 當裁判」而不講偏誤與校正，是直接扣分的答案。
⚙️ 怎麼用
三種形式（可靠度差很多）
| 形式 | 做什麼 | 可靠度 | 適用 |
|---|---|---|---|
| Pointwise | 對單一回答打 1–5 分 | ⚠️ 最差——分數會壓縮、跨批次不可比 | 快速篩選、粗略監控 |
| ★ Pairwise | 「A 和 B 哪個好？」 | ✅ 最高 | A/B 比較、回歸測試 |
| Reference-based | 對照參考答案評分 | ✅ 高（如果有參考答案） | 有 ground truth 時 |
★ 理由和 RLHF 全流程 的偏好資料設計完全相同：
絕對評分不穩定，相對比較穩定。 不只人類如此，模型也如此。
→ 能用 pairwise 就別用 pointwise。
★ 六種已知偏誤與對策（題目的核心）
| # | 偏誤 | 症狀 | 對策 |
|---|---|---|---|
| 1 | 位置偏誤 Position bias | 系統性偏好第一個（或第二個）呈現的答案 | ★ 兩個順序都跑一次，只採信兩次一致的結果；不一致就判平手。 （這會讓成本變兩倍，但這是唯一可靠的解法） |
| 2 | 冗長偏誤 Verbosity bias | 長答案得分高，即使沒有更多資訊 | rubric 明確寫「長度不是優點，冗贅要扣分」；統計上做長度校正；必要時控制兩邊長度相近 |
| 3 | 自我偏好 Self-enhancement | 裁判偏好自己或同家族模型的輸出 | ★ 裁判不要和被評估模型同家族；用多個不同家族的裁判投票 |
| 4 | 格式偏誤 | 偏好有 bullet、標題、粗體的答案 | rubric 明確說「格式不計分，只看內容」；或統一格式後再比 |
| 5 | 權威偏誤 | 偏好語氣肯定的答案，即使它是錯的 | rubric 要求「先查核事實正確性，再看表達」；事實類問題改用可驗證的檢查 |
| 6 | 分數壓縮 | pointwise 時大量落在 7–8 分，區分度接近 0 | 改用 pairwise；或用離散等級 + 明確錨點（每一級都給例子） |
還有一個更根本的限制：
裁判自己也會幻覺。 它在專業領域（法律、醫療、特定程式庫）的事實判斷不比被評估的模型可靠。
→ 事實正確性能用程式驗證就別用裁判（見 GRPO 與 RLVR 的同一個原則）。
設計一個可用的裁判
你是一位嚴格的評審。比較兩個回答，判斷哪個更好。
【評分標準】（依重要性排序）
1. 事實正確性 —— 有無與提供資料矛盾的陳述
2. 完整性 —— 有無遺漏問題中被明確問到的部分
3. 相關性 —— 有無答非所問或補充無關內容
4. 清晰度 —— 表達是否易懂
【明確不計分的項目】
- 回答長度（冗贅要扣分，不是加分）
- 排版格式（bullet、標題、粗體一律不計分）
- 語氣的自信程度
【輸出格式】
先逐項比較並說明理由，最後一行輸出：
VERDICT: A | B | TIE
五個要點：
- ★ 明確的 rubric —— 「評估品質」是無效的指令。要列出具體維度與優先序
- ★ 明確寫出「不計分的項目」 —— 這是直接對抗偏誤 2、4、5 的最便宜手段
- 先理由後判決（CoT） —— 提升一致性，代價是 token 成本
- temperature = 0 —— 降低隨機性（但注意它不保證可重現，見 取樣與解碼策略）
- 加 few-shot 錨點 —— 給 2–3 個「這種算好／這種算差」的範例校準尺度
★ 最重要的一步：驗證裁判本身
沒有驗證過的裁判，它的分數只是另一個模型的意見。
① 人工標註 100–200 個樣本（pairwise 最省力）
② 讓裁判跑同一批
③ 算一致性：
- Cohen's kappa（類別一致性，扣除隨機一致）
- 與人類的勝率相關係數
④ 一致性不夠 → 改 rubric → 回到 ②
⑤ ★ 一致性達標後，這個裁判才可以拿來跑大規模評估
同時要量「人類之間的一致性」當上界 —— 如果兩個人類標註者只有 70% 一致，裁判達到 68% 就已經接近人類水準，不必再追。
這個驗證要定期重跑：換模型、換 prompt、換領域都可能讓裁判失準。
⚠️ 注意 / 什麼時候不適用
- ★ 裁判分數不可跨版本比較。換了裁判模型、改了 rubric，歷史分數就作廢。要保留一組固定的錨點樣本做校準。
- 不要用被評估模型的同家族當裁判（自我偏好）。也不要用它評估自己的輸出。
- 高風險決策不能只靠裁判。醫療、法律、金融的最終驗收要有人。
- 裁判會把「同意使用者」當成好（諂媚偏誤的變形）。評估拒答與糾錯能力時要特別設計。
- 成本不低。pairwise + 雙向順序 + CoT = 每個樣本 4 次長呼叫。大規模評估前先算帳，並用小模型當裁判做初篩。
- pointwise 的分數沒有絕對意義。「平均 4.2 分」跨系統、跨時間都不可比。
- 裁判無法評估它看不到的東西：延遲、成本、UI 體驗、長期使用者滿意度。
🧪 我實際套用的紀錄
- 2026-09-20：從面試題庫展開。待辦：任何要用裁判的專案，先人工標 150 筆算 kappa。
🔗 相關
- 沒有標註時怎麼建評估集 —— 裁判是其中一個手段
- 幻覺偵測 —— 事實性判斷該用什麼取代裁判
- 上線閘門與線上評估 —— 裁判分數怎麼進 CI
- Agent 評估 —— 多步軌跡的評估更難
- RLHF 全流程 —— 為什麼比較優於打分
- 工具-AI系統評估 —— 決策層
- 工具-AI改動的AB對照評測 —— pairwise 的應用