RAG 的評測方法:分開量檢索與生成
把 RAG 當黑箱評測,永遠不知道該修哪裡。這篇拆成兩層各自量測。
RAG 評測最常見的錯誤是只看最終答案對不對。答案錯了,你不知道是檢索沒撈到,還是撈到了但模型沒用。
第一層:檢索指標
- Recall@k:正確片段出現在前 k 名的比例。這是最重要的單一指標。
- MRR:正確片段名次的倒數平均,反映排序品質。
- Context Precision:取回的片段中真正相關的比例,太低代表在浪費上下文。
第二層:生成指標
- 忠實度:答案的每個主張是否都能在提供的片段中找到依據。
- 答案相關性:是否真的回答了問題,而不是複述文件。
- 棄答正確性:資訊不足時有沒有正確地說不知道。
用「金標片段」建評測集
# eval.jsonl
{"q": "年假怎麼計算?",
"gold_chunks": ["hr-leave-2026#12", "hr-leave-2026#13"],
"gold_answer": "依到職滿一年起算……"}標註成本主要在 gold_chunks。實務做法是先用現有系統跑一輪,人工只需確認取回的片段對不對,比從零標註快很多。
診斷矩陣
- Recall 高、忠實度低 → 生成端提示要加強引用要求。
- Recall 低、忠實度高 → 修切塊與檢索,模型本身沒問題。
- 兩者都低 → 先修檢索,不要同時動兩邊。
評測集要跟著文件庫一起版控。文件更新後舊的 gold_chunks 可能失效,這種「評測集腐化」比程式碼腐化更難發現。