💡一句話定義：為什麼 LLM 這麼難評
LLM 評測（LLM Evaluation）＝對開放式生成的輸出，用多層方法交叉驗證它的正確性、有用性與安全性：自動指標（快但粗）、Benchmark（可比較但會被污染）、人評（最可信但貴）、LLM-as-judge（便宜但有偏誤）。沒有任何一層可以單獨下結論，評測集必須與訓練資料隔離。
先想一下分類模型怎麼評：貓還是狗，答案唯一，算 Accuracy、F1 就好。LLM 不一樣：
| 面向 | 分類／迴歸模型 | LLM（生成式） |
|---|---|---|
| 輸出型態 | 一個類別或一個數字 | 一段開放式文字、程式碼、對話 |
| 正解 | 唯一（標籤） | 沒有唯一正解：同一題可以有十種都對的寫法 |
| 「好」的定義 | 答對 | 正確、相關、完整、簡潔、安全、符合格式……多個面向可能互相衝突 |
| 評估方式 | 跟標籤比對，算指標 | 要靠參考答案相似度、題庫、人類判斷或另一個模型判斷 |
| 主要風險 | 過擬合、類別不平衡 | 幻覺、Benchmark 污染、裁判偏誤、評測集洩漏進訓練資料 |
所以業界的答案是分層：越往上越貴、越可信。
第一層：自動指標BLEU、ROUGE、Perplexity。有參考答案就能秒算，適合迴歸測試，但抓不到「意思對、用字不同」。
第二層：BenchmarkMMLU、GSM8K、HumanEval、MT-Bench、Arena。公開題庫、可跨模型比較，但會被訓練資料污染。
第三層：人評量表評分、成對比較、多位標注者算一致性。最可信、最貴、最慢。
第四層：LLM-as-judge用強模型當裁判模擬人評。便宜可大量跑，但有位置、冗長、自我偏好等偏誤，要用人評校準。
📏第一層：自動指標——BLEU、ROUGE、Perplexity 各測什麼
自動指標的共同邏輯是「跟參考答案比 n-gram 重疊」或「模型對正確文字有多不意外」。它們便宜到可以每次 commit 都跑，但要知道它們看不到語意：
| 指標 | 怎麼算 | 典型用途 | 限制 |
|---|---|---|---|
| BLEU | 生成句中的 n-gram 有多少比例出現在參考答案（精確率導向，加短句懲罰） | 機器翻譯 | 同義改寫被扣分；對流暢度、事實正確性無感 |
| ROUGE | 參考答案的 n-gram（ROUGE-N）或最長共同子序列（ROUGE-L）有多少比例被生成句涵蓋（召回率導向） | 摘要 | 抄原文越多分越高，不等於摘要品質 |
| Perplexity（困惑度） | 模型對一段真實文字的平均「驚訝程度」，越低代表語言模型越擬合該文本 | 預訓練品質、語言建模比較 | 只衡量「像不像這種文字」，與有用、正確無關；不同分詞器之間不可直接比 |
| Exact Match／Accuracy | 生成答案是否完全等於（或包含）標準答案 | 有唯一答案的題（數學、選擇題） | 格式稍有不同就算錯；只適用封閉式任務 |
| BERTScore 等語意指標 | 用嵌入向量算生成句與參考句的語意相似度 | 補 BLEU／ROUGE 看不到同義的洞 | 仍需參考答案；對事實錯誤不敏感 |
考題陷阱：「用 ROUGE 評估聊天機器人的回答品質是否恰當？」——不恰當。ROUGE 需要參考答案、只看字面重疊；開放式對話沒有唯一參考答案，且字面重疊高不代表回答有用。正確做法是人評或 LLM-as-judge，自動指標只能當輔助。
🏆第二層：Benchmark——MMLU、GSM8K、HumanEval、MT-Bench、Arena
Benchmark（基準測試）就是公開的標準化題庫，所有模型考同一份卷，分數才能互比。看模型發表時的「成績單」要知道每一科測的是什麼：
| Benchmark | 測什麼 | 題型與評分 | 注意 |
|---|---|---|---|
| MMLU | 57 個學科的知識與推理（STEM、人文、法律、醫學…） | 四選一選擇題，算準確率 | 最常被污染的題庫之一；接近天花板後鑑別力下降 |
| GSM8K | 小學程度的多步驟數學應用題 | 算出最終數字是否正確（Exact Match） | 常搭配思維鏈（CoT）提示；題目已大量流入網路 |
| HumanEval | 程式能力：依函式描述寫 Python | 跑單元測試，pass@k（k 次嘗試至少一次全過的比例） | 只有 164 題、只測 Python；工程實務能力不等於 HumanEval 高分 |
| MT-Bench | 多輪對話的指令遵循、推理、寫作等 8 類能力 | 80 題兩輪對話，由 GPT-4 當裁判打 1–10 分 | 裁判本身有偏誤（見下節）；分數反映「裁判覺得好」 |
| Chatbot Arena | 真人盲測偏好：兩個匿名模型同時回答，使用者投票 | 用 Elo／Bradley–Terry 把成對勝負換成排名分數 | 最接近真實使用者感受；但投票者偏好可能偏向冗長、格式漂亮的回答 |
最大的坑：資料污染（Data Contamination）
Benchmark 題目一旦公開，就會被爬進下一代模型的訓練語料——模型不是「會解題」，而是「背過答案」。徵兆：某模型在 GSM8K 滿分，但把題目數字換一換就崩。對策：（1）用未公開／動態更新的評測集；（2）做擾動測試（改數字、改敘述）；（3）看 Arena 這類即時人類投票而非靜態題庫；（4）自己的評測集絕不可出現在微調資料裡。這跟傳統 ML「測試集不能洩漏進訓練集」是同一條鐵律，只是 LLM 的訓練資料太大，洩漏更難察覺。
🎮互動一：Benchmark 雷達圖——權重一改，第一名就換人
三個虛構模型，五個 Benchmark。先按預設權重看排名，再拖「權重」滑桿：重視程式？重視對話？你會發現沒有絕對的第一名，只有「對你的任務」最好的模型。也可以切換模型改它的分數。
📡 Benchmark 雷達圖與加權排名
⚖️ Benchmark 權重（你的任務在乎什麼）
🎚️ 調整模型分數
👩⚖️第三層與第四層：人評 vs LLM-as-judge
人評（Human Evaluation）怎麼做才算數
📊量表評分（Likert）
每個回答在「正確性、相關性、流暢度、安全性」各打 1–5 分。要有評分準則（rubric）說明每一分的標準，否則人人標準不同。
每個回答在「正確性、相關性、流暢度、安全性」各打 1–5 分。要有評分準則（rubric）說明每一分的標準，否則人人標準不同。
⚔️成對比較（Pairwise）
同一題給兩個回答，只問「哪個比較好」。人類做相對判斷比絕對打分穩定，Arena 與 RLHF 的偏好資料都用這招。
同一題給兩個回答，只問「哪個比較好」。人類做相對判斷比絕對打分穩定，Arena 與 RLHF 的偏好資料都用這招。
🤝標注一致性（Kappa）
同一題找 2–3 位標注者，用 Cohen's κ（兩人）或 Fleiss' κ（多人）衡量扣掉「巧合一致」後的同意程度。κ 太低代表 rubric 不清楚或任務太主觀，分數不可信。
同一題找 2–3 位標注者，用 Cohen's κ（兩人）或 Fleiss' κ（多人）衡量扣掉「巧合一致」後的同意程度。κ 太低代表 rubric 不清楚或任務太主觀，分數不可信。
Kappa 怎麼讀：κ＝(觀察一致率 − 隨機一致率) ÷ (1 − 隨機一致率)。κ < 0.4 弱、0.4–0.6 中等、0.6–0.8 良好、> 0.8 幾乎一致。考題常問：「兩位標注者一致率 90%，Kappa 卻只有 0.3，為什麼？」——因為類別極度不平衡時，隨機亂標也會有很高的一致率，Kappa 把這部分扣掉了。
LLM-as-judge：讓強模型當裁判
人評太貴太慢，於是用 GPT-4 等級的模型照著 rubric 幫你打分或做成對比較。好處是便宜、快、可重複、可大量跑；壞處是裁判有系統性偏誤，而且你可能不知道：
| 偏誤 | 現象 | 為什麼 | 緩解 |
|---|---|---|---|
| 位置偏誤（Position Bias） | 成對比較時偏好先出現（或後出現）的回答；交換順序結論就變 | 注意力與訓練語料中的順序慣性 | 每對兩種順序各評一次，不一致就算平手或重評 |
| 冗長偏誤（Verbosity Bias） | 偏好更長、結構更漂亮的回答，即使內容錯 | 訓練偏好資料本身就偏好長回答 | rubric 明確要求「以正確與簡潔為先」；控制長度或做長度校正 |
| 自我偏好（Self-enhancement） | 裁判偏好與自己同家族模型的回答 | 風格與分布相似，裁判「看得順眼」 | 用不同家族的模型當裁判，或多裁判投票 |
| 推理能力不足 | 數學、程式題裁判自己也算錯，卻給錯答案高分 | 裁判不比受評者強 | 有標準答案的題用參考答案導向評分或直接跑測試 |
🎮互動二：當一次裁判——體驗位置偏誤與冗長偏誤
先自己幫 A、B 兩個回答打分，再按「看裁判結果」，比較你、LLM 裁判、人評共識三者的分數。然後按「🔁 交換 A/B 順序」：內容完全沒變，看看 LLM 裁判會不會改口。
⚖️ 當一次裁判
🧪任務導向評測與安全評測
通用 Benchmark 高分不代表你的應用好用。真正上線前要針對任務設計評測：
| 應用型態 | 核心指標 | 怎麼量 |
|---|---|---|
| RAG 問答 | 忠實度（Faithfulness）：答案是否只根據檢索到的文件；答案相關性：是否回答到問題；脈絡相關性／召回：檢索到的段落是否包含答案 | 裁判模型逐句比對答案與引用段落；用含標準答案的問答集算檢索命中率 |
| Agent | 任務完成率、步數／成本、工具呼叫正確率、是否做出危險操作 | 沙盒環境跑固定任務集，自動判定最終狀態是否達成 |
| 摘要／改寫 | 資訊涵蓋、無捏造、長度符合 | ROUGE 當輔助＋人評或裁判檢查捏造 |
| 客服對話 | 解決率、轉人工率、使用者滿意度、政策遵循 | 線上 A/B 測試與抽樣人工審核 |
安全評測：紅隊與幻覺率
🛡️紅隊測試（Red Teaming）
由人或攻擊模型刻意用越獄、提示注入、誘導偏見等方式攻擊，統計「成功攻破率」。上線前必做，上線後要持續。
由人或攻擊模型刻意用越獄、提示注入、誘導偏見等方式攻擊，統計「成功攻破率」。上線前必做，上線後要持續。
🌫️幻覺率（Hallucination Rate）
抽樣回答，逐一查核事實，算「含不實陳述的回答比例」。RAG 場景用忠實度；開放問答用事實查核或 FActScore 這類逐句驗證法。
抽樣回答，逐一查核事實，算「含不實陳述的回答比例」。RAG 場景用忠實度；開放問答用事實查核或 FActScore 這類逐句驗證法。
⚖️偏見與公平性
把題目中的性別、族群、地區換掉，看回答品質或態度是否改變。
把題目中的性別、族群、地區換掉，看回答品質或態度是否改變。
評測集要與訓練集隔離
自己建的評測集是你最寶貴的資產，絕對不能拿去微調模型或塞進少樣本提示，否則分數只是「背答案」。做法：評測集獨立存放、版本控制、定期補新題；微調資料進去前先做去重與重疊檢查（n-gram 或嵌入相似度），確認沒有評測題洩漏。
⚠️常見誤區
- 「Benchmark 第一名就是最好的模型」：Benchmark 測的是公開題庫；你的任務分布不同、還可能被污染。要用自己的任務評測集再驗一次。
- 「用 BLEU／ROUGE 評對話機器人」：需要參考答案、只看字面重疊；開放式任務要靠人評或裁判。
- 「LLM 裁判便宜所以全用它」：裁判有位置、冗長、自我偏好偏誤；要先用人評校準、雙順序評分、多裁判投票。
- 「一致率 90% 所以標注很可靠」：要看 Kappa，不是原始一致率；類別不平衡時隨機也會很一致。
- 「Perplexity 低＝模型好用」：困惑度只衡量語言建模擬合度，跟指令遵循、正確性無關，且不同分詞器不可比。
- 「評測做一次就好」：模型更新、提示改版、資料漂移都要重跑；評測集也要持續補題防污染。
✅自我檢測
五題單選，點選後立刻看答案與解釋。
🎯重點整理
- 難在哪：LLM 輸出開放式、無唯一正解、多面向互相衝突，所以要分層交叉驗證。
- 自動指標：BLEU（翻譯、精確率導向）、ROUGE（摘要、召回導向）、Perplexity（語言建模擬合度）；需要參考答案、看不到語意與事實。
- Benchmark：MMLU 知識、GSM8K 數學、HumanEval 程式（pass@k）、MT-Bench 多輪對話（GPT-4 裁判）、Arena 真人投票（Elo）。最大風險是資料污染。
- 人評：量表＋rubric、成對比較更穩定、多位標注者算 Kappa 看一致性。最可信、最貴。
- LLM-as-judge：便宜、可大量跑，但有位置偏誤、冗長偏誤、自我偏好；要雙順序評分、多裁判、用人評校準。
- 任務導向：RAG 看忠實度與相關性、Agent 看任務完成率；安全看紅隊攻破率與幻覺率。
- 鐵律：評測集與訓練／微調資料隔離，否則分數只是背答案。