Confident AI 的 LLM 評估指標指南
Confident AI 解析 LLM 評估指標，從正確性、相關性、幻覺到 agent 任務完成，教你挑對 metric。
這篇在講怎麼用對的指標，去評估 LLM 的正確性、相關性、幻覺和任務完成度。
說真的，LLM 評估很容易做歪。模型可以講得很順，內容卻是錯的。這篇 Confident AI 的文章，就是在講這件事。
它的核心很直接。你要先知道系統在做什麼。是聊天、檢索、還是多步驟 agent。不同任務，要看的 metric 完全不同。
如果你只看一個總分，通常會踩雷。因為分數好看，不代表產品真的好用。這篇就是在拆這個迷思。
| 指標或方法 | 檢查什麼 | 適合情境 |
|---|---|---|
| Answer relevancy | 有沒有回到題目 | 聊天機器人、助理 |
| Correctness | 答案有沒有對 | 有標準答案的任務 |
| Hallucination | 有沒有亂編事實 | 信任與安全場景 |
| Task completion | agent 有沒有把事做完 | AI agent、工作流 |
| G-Eval | 用 LLM 搭配 rubric 評分 | 語意判斷、開放式輸出 |
| Prometheus | 開源 LLM judge | 想要可控的模型評審 |
老派指標為什麼不夠用
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
文章先點名幾個老面孔，像 BLEU、ROUGE、METEOR，還有 edit distance。這些方法不是沒用，只是它們本來就為翻譯、摘要、字串比對設計。
問題來了。LLM 的答案常常有很多種講法。意思對就行，不一定要跟 reference 長得一模一樣。你用字詞重疊去打分，很容易把好答案打低分。
更麻煩的是，這類分數常常只看表面。它可能獎勵了相似字句，卻沒抓到事實錯誤。對聊天機器人、RAG、coding assistant 來說，這種分數真的不夠看。
- BLEU 看 n-gram precision
- ROUGE 偏向 recall，摘要任務常會用
- METEOR 會考慮同義詞與詞序
- Levenshtein distance 看字元編輯次數
講白了，這些指標適合封閉任務。像拼字修正、欄位抽取、格式固定輸出，都還能用。可是一旦進到自然語言互動，它們就開始失真。
Confident AI 的意思很明白。只要任務牽涉語意、推理、或判斷，單靠統計分數就太薄了。你需要能對齊人類判斷的方式。
LLM-as-a-judge 才是重點
這篇最有料的地方，就是 LLM-as-a-judge。做法很簡單。你不再比字串，而是給模型一份 rubric，叫它根據規則打分。
這種方法特別適合開放式輸出。像回答問題、摘要、對話品質、工具使用，都很難用 n-gram 解決。你要看的是意思對不對，不是字有沒有對齊。
文章提到 G-Eval。它讓 LLM 用步驟化推理去評估輸出。也提到 Prometheus，這是開源 judge model，基於 Llama-2-Chat，還用 10 萬筆 feedback 做 fine-tune。
"The secret to making a good LLM evaluation metric great is to make it align with human expectations as much as possible." — Jeffrey Ip, Co-founder @ Confident AI
這句話很直白。評分標準要像人。不是像數學題。你如果 rubric 寫得很模糊，judge 也只會回你一個模糊分數。
文章作者 Jeffrey Ip 也是 DeepEval 的創辦人。這點很重要。因為他不是只在講理論，還在推一套真的能落地的工具。
不同系統，要看不同指標
這篇另一個實用點，是它把系統類型分開看。chatbot、RAG、agent，本來就不是同一種東西。你不該用同一把尺量到底。
對 agent 來說，重點是 task completion、argument correctness、tool correctness、plan quality、plan adherence。這些指標在看的是決策過程，不只是結果。
對 RAG 來說，重點又變成 faithfulness、answer relevancy、contextual precision、contextual recall、contextual relevancy。因為問題常常出在檢索，而不是生成。
- Agent 要看工具選擇和步驟順序
- RAG 要看檢索品質和答案是否依據 context
- Foundation model 要看 hallucination、toxicity、bias
- 摘要、抽取、對齊任務常需要自訂 rubric
這裡的重點很實際。你不需要一個超長 dashboard。你只需要少數高訊號指標。每個 metric 只回答一個問題，才好 debug。
我覺得這比那種「全都量一輪」的做法健康多了。因為分數越多，團隊越容易吵架。最後大家都在看圖表，沒人在修產品。
數字怎麼看，才不會看錯
這篇文章雖然不是 benchmark 報告，但它其實在提醒一件事。評估要能回到數字，而且數字要能對應失敗模式。這才是 production eval 的核心。
如果一個 agent 的分數掉了 12%，你要知道是工具錯了，還是步驟亂了。這兩種問題，修法完全不同。把它們混在一起，只會讓團隊越修越亂。
如果一個 RAG 系統答錯，你也要分清楚。是檢索不到資料，還是檢索到了卻亂講。前者是 retrieval 問題，後者是 grounding 問題。
- BLEU、ROUGE 適合比對字面重疊
- G-Eval、judge model 適合看語意和規則
- Task completion 適合 agent 工作流
- Hallucination、bias、toxicity 適合安全檢查
你可能會想問，那到底要選哪個？答案是看產品。不是看論文。不是看社群在吹什麼。你要看使用者會在哪裡失望。
如果使用者會因為答案錯而翻白眼，那 correctness 就要高優先。如果使用者只是想要有用回覆，那 relevancy 可能比 exact match 更重要。
這篇其實在推一種工作流
Confident AI 的文章不只是講指標。它也在推一種 eval 工作流。先定義 metric，再拿真實例子測，接著用 regression testing 追版本變化。
這很像軟體測試。只是測的不是 function output，而是 LLM 行為。模型、prompt、工具一改，分數就會跟著變。你如果沒有固定流程，很快就不知道問題從哪來。
文章也把 DeepEval 放進來。它是開源工具，主打用幾行 code 寫出現代 LLM metrics。搭配 Confident AI 的雲端平台，還能做觀測、資料集管理、測試報表。
這種設計很符合現在團隊的痛點。大家不是不想測，是不知道怎麼把「品質」變成可重複的流程。只靠人工 review，根本撐不住版本迭代。
如果你在做 LLM app，我會建議你先問三件事。使用者最常抱怨什麼。哪個失敗最貴。哪個指標能穩定重現這個失敗。這三題比堆一堆分數有用多了。
產業脈絡也很清楚
現在很多團隊都在做 LLM app。從客服、搜尋、內部知識庫，到 agent 自動化，都開始上線。問題是，大家很愛先做 demo，後補評估。
這種順序很危險。因為 demo 看起來順，不代表 production 穩。真實資料更髒，使用者問題更雜，模型也更容易亂編。沒有 eval，很多 bug 會一路滑進正式環境。
更現實的是，LLM 系統的成本也不低。每次呼叫都要算 Token。每個 judge 也要算 API 費。你不能無腦把所有東西都丟給大模型評分，否則成本會先爆。
所以現在主流做法，通常是混搭。簡單任務用規則或 exact match。語意任務用 LLM judge。安全項目再加人工抽查。這樣才比較像真的工程。
這篇文章的價值，就在這裡。它沒有把評估講成神話。它只是很務實地說，對的 metric 才有用。這句話聽起來普通，但很多團隊真的做不到。
先選對 metric，再談模型好壞
如果你現在正在做 LLM 產品，我的建議很簡單。先列出 3 個最常見失敗。再替每個失敗找 1 個指標。不要一開始就追求全套評分系統。
你也可以先從最容易對齊的地方開始。像 answer relevancy、correctness、hallucination，這三個就很夠用了。等你真的有 agent 或 RAG，再補 task completion 和 retrieval 類指標。
講白了，eval 不是裝飾品。它是產品的一部分。你不先定義怎樣算好，後面就只剩下吵架。這篇 Confident AI 的指南，最有價值的地方就是把這件事講得很實際。
如果你要我下結論，我會說：先把 metric 收斂到 3 到 5 個，再把每個指標對到一種真實失敗。這樣你才有辦法真的管住 LLM 品質，不然數字再多也只是好看而已。