第十八章：RAG 评估体系

18.1 为什么必须分层评估

RAG 是一条多环节的流水线。最终答案不好，可能是任何一个环节出了问题。

如果只看一个端到端的总分，你能知道"效果差"，但不知道差在哪。而分层指标能直接告诉你问题落在第十四章框架的哪一层。

flowchart TB
    E[RAG 评估] --> E1[检索层
找到了吗 排前面了吗]
    E --> E2[生成层
忠实吗 切题吗]
    E --> E3[端到端
用户问题解决了吗]
    E --> E4[线上
真实用户怎么反馈的]

只看端到端分数只能发现退化，不能定位病因；只看检索又无法判断整条链路是否完成任务。两类评测需要同时存在。

18.2 检索层指标

前提：需要一个标注了每个 Query 对应哪些 chunk 是正确依据的评测集。

18.2.1 怎么用这些指标定位问题

更有用的是把这些指标组合起来定位问题。

实际分析时，通常把这组指标作为诊断表来定位问题。

18.3 生成层指标

RAGAS 这类框架提供了几个常用的无参考答案指标：

18.3.1 四个使用边界

使用这些指标时，需要同时看清它们的边界。

（1）Faithfulness 不等于事实正确性

首先要区分这一点（与第十七章 17.8 呼应）：

Faithfulness 衡量的是「答案忠实于材料」，不是「答案事实正确」。 材料本身错了，忠实度依然满分。

（2）Faithfulness 可以被"我不知道"刷满

模型回答「材料中没有相关信息」时，这个陈述完全忠实于材料，忠实度得分很高。

因此 Faithfulness 需要和 Answer Relevancy 联合解释，否则一个倾向拒答的系统也可能拿到很高的忠实度分数。

（3）LLM-as-Judge 的循环性问题

用 LLM 评估 LLM 的输出，存在同源偏见：评判模型可能偏好与自己风格相似的回答，也可能与被评模型犯同样的错误。

缓解：用与生成模型不同的模型做评判；用人工标注的子集校准评判模型的一致性。

（4）无参考答案带来的噪声

Context Recall 等指标在没有标准答案时依赖 LLM 推断，方差较大。

这些指标更适合看趋势和相对比较，不适合当作绝对分数。像「Faithfulness 从 0.82 涨到 0.85」这样的变化，需要结合评测集和判定方差一起解释。

18.4 端到端评估

最终还是要回答「用户的问题解决了吗」。

推荐组合：程序化断言做主体（快速、确定性、可回归），LLM-as-Judge 做补充（覆盖开放性问题），定期人工抽查做校准（验证前两者的可信度）。

LLM-as-Judge 需要先校准：用一批人工标注样本检查评判模型与人工的一致性。未校准的 Judge 分数不应直接用于决策。

18.4.1 Citation、时效与鲁棒性

端到端“答案正确”不足以说明系统可审计、可用于当前事实，或能抵抗输入扰动。对需要依据的答案，至少增加以下维度：

时效评测必须固定“查询时刻”和可见版本；否则系统可能引用今天正确、当时错误的材料。鲁棒性不应只报告攻击成功率，还要报告正常任务效用，避免以全拒答获得表面高分（安全细节见第二十章）。

18.5 评测集怎么建

这一部分通常最耗时，但决定评估体系是否可用。

18.5.1 分三档

18.5.2 必须覆盖的问题类型

• 简单事实查找；
• 同义表述（用户的说法与文档不同）；
• 专业术语与型号（测 BM25 那一路）；
• 多跳/复合问题；
• 需要综合多个片段的问题；
• 时效性问题（固定查询时刻，新旧版本共存时能否选择当时有效的信息）；
• 带引用的问题（标注每个关键主张所需证据与页/段级定位）；
• 鲁棒性成对样例（同义改写、OCR 噪声、无关文档、冲突证据和恶意指令）；
• 知识库里没有答案的问题（测拒答能力）；
• 诱导性问题（前提本身是错的，看模型是否会顺着编）。

最后两类直接关系到系统的可信度，评测集里不能缺。

18.5.3 数据来源

优先级从高到低：

1. 真实的线上用户问题——最有代表性；
2. 业务专家出题——覆盖重要但低频的场景；
3. LLM 生成——补充规模，但必须人工审核。

LLM 生成评测集时有个常见偏差：直接让 LLM 读一个 chunk 然后出题，生成的问题会过度贴合该 chunk 的措辞，导致检索"虚假地容易"。题目需要人工改写成真实用户会使用的问法。

18.6 公开基准的价值与局限

公开基准的作用是横向比较方法，而不是预测你的系统在你的数据上的表现。

以 CRAG Benchmark 这类更贴近真实场景的评测为例，即使是当时最好的系统，准确率也只在 50% 上下。这说明 RAG 仍有明显边界，也能避免对外给出过高承诺。

18.7 线上指标

离线评测跑得再好，也要看真实用户的反馈。

点踩数据的最大价值不是统计比例，而是作为评测集的来源——把点踩的 Query 收集起来人工分析，是最高质量的问题发现渠道。

18.8 建立评估的正确顺序

flowchart TB
    S1[1. 收集真实问题] --> S2[2. 人工标注正确 chunk 和参考答案]
    S2 --> S3[3. 建立检索层指标基线]
    S3 --> S4[4. 加程序化断言]
    S4 --> S5[5. 引入 LLM-as-Judge 并校准]
    S5 --> S6[6. 接入线上反馈回流]
    S6 --> S1

这是一条闭环流程：线上反馈会不断补充评测集，评测集再指导下一轮优化。

18.9 常见错误

18.9.1 只看端到端不分层

知道效果差，不知道差在哪。

18.9.2 把 Faithfulness 当作事实正确性

它衡量的是忠实于材料，材料错了也能满分。这是最常见的误解。

18.9.3 只看 Faithfulness 不看 Answer Relevancy

一个只会拒答的系统忠实度很高。

18.9.4 LLM-as-Judge 不做校准

未校准的评判分数没有可信度。

18.9.5 用生成模型自己做评判

存在同源偏见，应该换一个模型。

18.9.6 评测集不含"无答案"问题

无法检验拒答能力，而拒答是防幻觉的第一道防线。

18.9.7 LLM 生成评测集不做人工改写

问题过度贴合 chunk 措辞，检索指标虚高。

18.9.8 把 RAGAS 分数当绝对值报告

这类指标方差大，适合看趋势和相对比较。

18.9.9 只有离线评测没有线上回流

线上点踩数据是最高质量的问题来源。

18.10 本章总结

1. 必须分层评估：检索层、生成层、端到端、线上——只看总分无法定位问题；
2. 检索层指标（Hit@K、Recall@K、MRR、NDCG）的价值在于组合起来做诊断：Hit@50 低 = 召回问题，Hit@50 高但 Hit@5 低 = 排序问题，Hit@5 高但答案差 = 生成问题；
3. RAGAS 四指标：Faithfulness、Answer Relevancy、Context Precision、Context Recall；
4. 四条局限：忠实度≠正确性、可被拒答刷满、LLM-as-Judge 有同源偏见、无参考答案导致方差大；适合看趋势不适合当绝对分；
5. 端到端还要测 Citation 完整性/正确性/可访问性、固定时刻的时效性，以及成对扰动下的鲁棒性；
6. 端到端推荐组合：程序化断言为主 + LLM-as-Judge 补充 + 人工抽查校准；
7. 评测集分三档（Smoke / Regression / Full），必须包含无答案、诱导、时效、引用和鲁棒性成对问题；
8. LLM 生成的题目必须人工改写，否则检索指标虚高；
9. 公开基准用于横向比较；真实场景分数依赖数据、任务和评判口径，不能脱离版本横比；
10. 线上点踩数据是高价值的问题来源，经过脱敏、分诊和标注后再进入评测闭环。

参考资料

• Ragas: Automated Evaluation of Retrieval Augmented Generation
• Evaluation of Retrieval-Augmented Generation: A Survey
• CRAG - Comprehensive RAG Benchmark
• TREC RAG Track
• Fact, Fetch, and Reason: A Unified Evaluation of Retrieval-Augmented Generation