LLM-as-a-Judge 怎麼校準？人工基準、偏差與不確定性實務
用 LLM 評分另一個模型的輸出，可以降低逐題人工成本，但評審模型也會受提示、順序、答案長度、模型版本與自身錯誤影響。企業不能因工具回傳 1–5 分，就把 3 分直接當成通用及格線。正確做法是先定義評測目的，用人工判斷建立基準，再量測評審在特定 rubric 與案例上的可靠程度。
先決定什麼適合交給模型評審
格式、欄位、數字與明確標準答案應優先用程式規則；權限、付款、法律效力與重大錯誤應保留人工或確定性阻斷。模型評審較適合先判斷相關性、完整度、語意一致與大量低風險案例，再把低信心、分歧與高影響項目送人。
可先到AI 評測指標資料庫選定要量的概念，避免一個「品質分數」混合正確、完整、依據與語氣。再用AI 測試案例庫加入答案部分正確、引用不支持、需求模糊與重大錯誤案例，檢查評審能否分辨真正差異。
建立人工 ground truth 與標註指南
選一批能代表正式分布與高風險邊界的案例，由熟悉業務的人依明確 rubric 評分。先校準標註者，記錄分歧與裁決，不能把人工意見當成天然無誤。若任務涉及不同群體、語言或領域，基準也要分群，不只看整體平均。
Google Cloud 的官方評測文件明確要求以人工評分作 judge model 的 ground truth，並可用 balanced accuracy、F1 與混淆矩陣檢查評審品質。這是平台實作範例，不表示每個工具共用相同分數定義；rubric、提示、評審模型與參數都必須版本化。
測試位置、長度與自我偏好
成對比較要交換候選 A／B 順序，觀察結果是否翻轉；長短答案要刻意平衡，避免把篇幅當品質；評審模型與被評模型相同時，也要檢查是否偏好相似語氣或推理模式。對同一案例重跑，記錄評分變異與理由是否一致。
不要要求評審輸出隱藏思考過程；只保存可供複核的判斷理由、引用與結構化結果。若理由與分數矛盾，該案例應升級人工，不要用平均掩蓋。
報告分歧與不確定性
NIST AI 800-3 指出，常見 benchmark 分析可能依賴未揭露假設、混淆不同系統表現概念，或沒有正確量化不確定性；該文件提出統計模型作為改善方向。企業不一定要直接採用特定模型，但至少應報告樣本數、分布、信賴或變異、分群與評審—人工分歧，而不是只報一個小數點平均。
模型評審上線後也要監控漂移：模型、提示或案例分布改變時重新拿人工抽樣校準。把校準結果寫入企業 AI 評測計畫並保留驗收門檻指南中的阻斷條件，讓自動分數不會取代真正的責任決策。