RAG 评测指标 RAG Evaluation Metrics

所属：01-fundamentals / 05-agent-evaluation
面试权重：★★★
来源：通用领域知识；未做一手考证
相关知识点：01-fundamentals/03-rag/pipeline.md、hybrid-rerank.md、01-fundamentals/05-agent-evaluation/llm-as-judge.md

一句话#

RAG 是一个两段式流水线，所以评测必须拆成检索侧（该找的找回来了吗）和生成侧（拿着找到的东西答对了吗）；只有用一个数字看端到端，你永远不知道是没找到还是找到了没用。

为什么重要（面试角度）#

「RAG 效果不好怎么办」是最常见的一道开放题，而它 90% 的面试时间是诊断题，不是定义题。面试官想看：

• 你能不能说清检索侧指标（Recall@k、Precision、MRR、nDCG）各自衡量什么、为什么 RAG 里 Recall@k 通常最优先
• 你能不能说清生成侧指标（faithfulness、answer relevance、citation correctness）
• 最关键：给一个失败 case，你能用可操作的方法（而不是猜）判断是检索坏了还是生成坏了
• 你知道这些指标的前提假设（需要标注、需要 gold evidence），以及没有标注时怎么退化处理

RAG 是绝大多数 LLM 应用的主干，这题答得深 = 你能独立定位线上质量问题。

核心内容#

为什么要拆两段#

端到端指标（如「答对率」）是一个乘积：答对率 ≈ 检索命中率 × 生成正确率。它把两个来源的失败混在一起：

• 检索没召回正确文档 → 生成再好也只能编
• 检索召回了正确文档但生成被噪声带跑 → 生成侧问题

同一个从 80% 掉到 70% 的数字，可能对应完全不同的两个修复动作（换 chunking/embedding/rerank，还是改 prompt/上下文组织）。不拆开就无法归因，无法归因就无法迭代。

检索侧指标#

先明确一件事：评测的「单位」是什么 —— 是 chunk 还是文档？同一批数据按不同粒度算出来的指标不可比。大多数 RAG 系统的检索单位是 chunk。

必须能说清的取舍：

• Recall@k 与 k 绑定：k=20 的 Recall 一定高于 k=5，报告时必须写明 k。讨论「提升召回」时要问一句：代价是不是噪声也多了（precision 掉）。
• 需要标注：（query, 相关 chunk）的标注是这类指标的硬前提。没有标注时，常见退化做法是用 LLM 辅助判定「这段上下文是否足以回答该 query」，但这类自动标注本身需要和人工抽检校准，不能默认可信。
• 检索指标好 ≠ 端到端好：召回满分但生成仍答错，说明瓶颈在生成侧。

生成侧指标#

评测方法：faithfulness 常做成「把答案拆成若干原子断言 → 逐条判断能否被上下文支撑 → 算支撑比例」。correctness / relevance 这类主观维度一般交给 LLM-as-a-Judge，那就必须走它的校准流程（→ 见 llm-as-judge.md）。业界有 RAGAS 一类现成框架提供这套指标，可以直接用，但要清楚它内部同样是"LLM 判断 + 提示词假设"，换模型、换语言、换领域后指标可能漂移，需自行校准。

诊断：怎么把两类失败分开（本节是重点）#

拿到一个失败 case，按下面流程走，每一步都是一个可执行的实验：

第一步：看证据在不在。

检查检索到的上下文里，是否包含回答该问题所必需的证据。

这个 2×2 就是诊断的全部骨架。四格里最值得警觉的是「证据不在，但答对了」—— 它意味着模型在绕开检索用先验知识作答，在私有知识/时效性场景下迟早翻车。

第二步：两个 oracle 实验，把归因和修复方向钉死。

• Oracle Retrieval（喂金标）：把人工标注的 gold 上下文直接塞给生成器，跳过检索。
  • 答对了 → 瓶颈在检索侧：去查 chunking 粒度、embedding 模型是否匹配语言/领域、是否该上 hybrid（BM25 + 稠密）、是否该加 reranking、query 是否需要改写（多轮指代尤其常见）。
  • 还是答错 → 瓶颈在生成侧：去查 prompt 是否明确要求"只依据上下文"、上下文是否太长导致关键信息被淹没（lost-in-the-middle 类问题）、噪声是否太多、模型能力是否不足。
• Oracle Generation（冻结上下文换生成器）：保持检索结果不变，换一个更强的生成模型跑同一批 case。
  • 明显变好 → 生成侧是瓶颈（模型能力或 prompt 问题）。
  • 没变化 → 检索侧是瓶颈。

这两个实验花不了多少时间，但能把「我觉得是检索问题」变成「我把金标喂进去它答对了，所以是检索问题」。

第三步：分桶看，不要只看总体。

按 query 类型分桶（单跳/多跳、事实型/总结型、是否多轮、长短 query、语言）。总体指标持平很可能掩盖某一桶的严重退化 —— 多跳问题对检索尤其敏感。

评测集怎么建#

一个可用的 RAG 评测集，每条样本至少要有：

• query（最好包含真实线上 query，含错别字与口语表述）
• gold_answer（用于 correctness）
• gold_evidence / 相关 chunk id（用于检索侧指标 —— 这一项最容易被偷懒省掉，省掉就没法算 recall，也就没法做诊断）
• 类型标签（用于分桶）

补充来源：① 真实线上流量采样（分布最真实，注意脱敏）；② 从文档反向合成 query（覆盖可控，但要防止合成 query 比真实 query 更"规整"，导致指标虚高）；③ 线上失败 case 回流（最有价值，直接对应已知痛点）。

在线侧补充指标：用户点赞点踩、追问率、转人工率、无答案率、引用点击率。离线指标好但线上反馈差，通常意味着评测集分布和真实流量不一致。

常见面试问法#

Q：RAG 效果不好，你怎么查？ A：先拆两段。取一批失败 case，逐个判断必需的证据是否出现在检索上下文里：不在 → 检索侧；在但答错 → 生成侧。再用两个 oracle 实验钉死方向：把 gold 上下文直接喂生成器（答对则检索侧是瓶颈），以及冻结上下文换更强的生成模型（变好则生成侧是瓶颈）。最后按 query 类型分桶，避免总体指标掩盖局部退化。

Q：RAG 里最该看的检索指标是哪个？ A：通常是 Recall@k。因为生成器无法使用没被召回的上下文，召回是端到端正确率的硬上限；漏召回导致的失败是无法靠 prompt 或更强模型补救的。但要和 Precision@k 一起看 —— 盲目扩大 k 提召回会把噪声灌进上下文，反而拖垮生成质量。

Q：faithfulness 高是不是就说明 RAG 没问题？ A：不是。faithfulness 只保证答案被检索到的上下文支撑，如果上下文本身是错的、过时的、或不完整的，模型完全可以"忠实地"给出错误答案。所以必须同时看 correctness（对 gold）和 context recall（信息够不够），以及弃权正确性（该说不知道时有没有说）。

Q：怎么评 citation correctness？ A：拆成两个方向：citation precision —— 引用的来源是否真的支持该结论（有没有"引了但无关"或"引了但结论是编的"）；citation recall —— 答案里需要出处的事实性断言是否都给了引用（有没有该引没引）。判定通常靠 LLM judge 逐条核对"来源文本能否推出该断言"，同样需要人工抽检校准。

Q：没有标注数据，怎么做 RAG 评测？ A：退化方案是用 LLM 自动构造（query, 相关上下文）标注并生成 gold answer，或用 LLM-as-a-judge 直接判 context relevance 和 faithfulness。但要清楚这会引入 judge 的偏置与错误，必须先人工抽检校准一批、确认一致性可接受，再规模化使用。没有标注不等于可以不校准。 另一个低成本替代是先从线上失败 case 手工标注一批高价值样本作为种子集。

易错点#

• ❌ 只看端到端一个数字，不拆检索/生成，导致无法归因。
• ❌ 报告 Recall 不写 k，或以为不同 k 的数字可比。
• ❌ 只提召回，不提精度 —— 扩大 k 或放宽检索会灌噪声，反而降低生成质量。
• ❌ 把 faithfulness 当成"事实正确" —— 它只保证有据，上下文错了它照样"忠实地错"。
• ❌ 忘了评弃权：上下文无答案时硬编，是 RAG 最危险的失败模式之一。
• ❌ 混淆检索单位：把文档级标注和 chunk 级指标混着算，数字不可比。
• ❌ 用合成的、过于规整的 query 建评测集，指标虚高，线上打脸。
• ❌ 忘了评测集去重，训练/微调数据里混入了评测 query。

自测#

1. 线上答对率从 82% 掉到 74%。给你一批失败 case，你的诊断流程是什么？

2. 为什么 RAG 里 Recall@k 通常比 Precision@k 更关键？只提召回有什么风险？

3. faithfulness 打了满分，能不能说这个 RAG 系统没问题？

4. 「证据不在上下文里，但模型答对了」这一格说明什么？为什么值得警惕？

5. 你要评 citation correctness，具体怎么拆？