第十八章：RAG 评估体系¶
18.1 为什么必须分层评估¶
RAG 是一条多环节的流水线。最终答案不好，可能是任何一个环节出了问题。
如果只看一个端到端的总分，你能知道"效果差"，但不知道差在哪。而分层指标能直接告诉你问题落在第十四章框架的哪一层。
flowchart TB
E[RAG 评估] --> E1[检索层<br/>找到了吗 排前面了吗]
E --> E2[生成层<br/>忠实吗 切题吗]
E --> E3[端到端<br/>用户问题解决了吗]
E --> E4[线上<br/>真实用户怎么反馈的]只看端到端分数只能发现退化，不能定位病因；只看检索又无法判断整条链路是否完成任务。两类评测需要同时存在。
18.2 检索层指标¶
前提：需要一个标注了每个 Query 对应哪些 chunk 是正确依据的评测集。
| 指标 | 衡量什么 | 什么时候用 |
|---|---|---|
| Hit@K | Top-K 里是否至少有一个正确 chunk | 最常用的核心指标 |
| Recall@K | Top-K 里覆盖了多少比例的正确 chunk | 答案需要多个片段综合时 |
| MRR | 第一个正确结果的排名倒数的平均 | 衡量排序质量 |
| NDCG@K | 考虑相关性等级和位置的综合排序质量 | 相关性分多档时 |
| Precision@K | Top-K 里正确的比例 | 关注噪音比例时 |
18.2.1 怎么用这些指标定位问题¶
更有用的是把这些指标组合起来定位问题。
| 现象 | 诊断 | 对应的层 |
|---|---|---|
| Hit@50 低 | 根本没召回，可能是索引或召回路问题 | 索引层 / 召回层 |
| Hit@50 高但 Hit@5 低 | 召回到了但排序不好 | 重排层 |
| Hit@5 高但答案差 | 检索没问题，生成层有问题 | 生成层 |
| Recall@K 低但 Hit@K 高 | 找到了一部分依据，但不完整 | 索引层（粒度）/ 召回层（K 太小） |
实际分析时，通常把这组指标作为诊断表来定位问题。
18.3 生成层指标¶
RAGAS 这类框架提供了几个常用的无参考答案指标：
| 指标 | 衡量什么 |
|---|---|
| Faithfulness（忠实度） | 答案中的每个陈述是否能从检索材料中推出 |
| Answer Relevancy（答案相关性） | 答案是否切题（不跑题、不答非所问） |
| Context Precision（上下文精确率） | 检索到的材料中，相关的是否排在前面 |
| Context Recall（上下文召回率） | 回答所需的信息是否都被检索到了 |
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 | 模型对照参考答案打分 | 中 | 中（需校准） |
| 程序化断言 | 检查答案是否包含关键事实 | 低 | 高（但覆盖窄） |
| AB 测试 | 线上对比两个版本 | 中 | 最贴近真实 |
推荐组合：程序化断言做主体（快速、确定性、可回归），LLM-as-Judge 做补充（覆盖开放性问题），定期人工抽查做校准（验证前两者的可信度）。
LLM-as-Judge 需要先校准：用一批人工标注样本检查评判模型与人工的一致性。未校准的 Judge 分数不应直接用于决策。
18.4.1 Citation、时效与鲁棒性¶
端到端“答案正确”不足以说明系统可审计、可用于当前事实，或能抵抗输入扰动。对需要依据的答案，至少增加以下维度：
| 维度 | 要测什么 | 可操作判定 |
|---|---|---|
| Citation 完整性 | 关键可核查主张是否都有引用 | 人工或断言统计“有有效来源的主张 / 应引用主张” |
| Citation 正确性 | 引用是否真的支撑它旁边的主张 | 核验来源、页/段/时间定位与主张的蕴含关系；只检查编号存在不够 |
| Citation 可访问性 | 用户能否在其权限内打开引用 | 检查 ACL、稳定 doc_id/version_id 与定位信息，不泄漏路径 |
| 时效性（freshness） | 答案是否依据查询时有效的版本 | 用已知更新、撤销和过期样例，评测正确版本选择、日期呈现和缓存失效 |
| 鲁棒性 | 无关噪声、同义改写、拼写/OCR 错误、冲突或注入内容是否改变结论 | 成对运行原始与扰动样例，报告任务成功、错误接受、拒答和引用变化 |
时效评测必须固定“查询时刻”和可见版本；否则系统可能引用今天正确、当时错误的材料。鲁棒性不应只报告攻击成功率，还要报告正常任务效用，避免以全拒答获得表面高分（安全细节见第二十章）。
18.5 评测集怎么建¶
这一部分通常最耗时，但决定评估体系是否可用。
18.5.1 分三档¶
| 类型 | 规模 | 频率 | 用途 |
|---|---|---|---|
| Smoke | 10–30 条 | 每次改动 | 快速验证没有明显退化 |
| Regression | 100–300 条 | 每次发版 | 防止已修复的问题复发 |
| Full | 500+ 条 | 定期 / 大改动 | 全面评估 |
18.5.2 必须覆盖的问题类型¶
- 简单事实查找；
- 同义表述（用户的说法与文档不同）；
- 专业术语与型号（测 BM25 那一路）；
- 多跳/复合问题；
- 需要综合多个片段的问题；
- 时效性问题（固定查询时刻，新旧版本共存时能否选择当时有效的信息）；
- 带引用的问题（标注每个关键主张所需证据与页/段级定位）；
- 鲁棒性成对样例（同义改写、OCR 噪声、无关文档、冲突证据和恶意指令）；
- 知识库里没有答案的问题（测拒答能力）；
- 诱导性问题（前提本身是错的，看模型是否会顺着编）。
最后两类直接关系到系统的可信度，评测集里不能缺。
18.5.3 数据来源¶
优先级从高到低：
- 真实的线上用户问题——最有代表性；
- 业务专家出题——覆盖重要但低频的场景；
- LLM 生成——补充规模，但必须人工审核。
LLM 生成评测集时有个常见偏差：直接让 LLM 读一个 chunk 然后出题，生成的问题会过度贴合该 chunk 的措辞，导致检索"虚假地容易"。题目需要人工改写成真实用户会使用的问法。
18.6 公开基准的价值与局限¶
| 基准 | 特点 |
|---|---|
| TREC RAG | 学术界的标准化评测，方法论严谨 |
| CRAG Benchmark | 覆盖多领域、多类型问题，含动态变化的答案；注意与 Corrective RAG 区分 |
| 各类领域 QA 数据集 | 特定领域的参考 |
公开基准的作用是横向比较方法，而不是预测你的系统在你的数据上的表现。
以 CRAG Benchmark 这类更贴近真实场景的评测为例，即使是当时最好的系统，准确率也只在 50% 上下。这说明 RAG 仍有明显边界，也能避免对外给出过高承诺。
18.7 线上指标¶
离线评测跑得再好，也要看真实用户的反馈。
| 指标 | 说明 |
|---|---|
| 点踩率 / 点赞率 | 最直接的用户满意度信号 |
| 转人工率 | 客服场景的核心指标 |
| 追问率 | 用户需要追问，说明首次回答不完整 |
| 引用点击率 | 用户是否在核查来源（信任度的反向信号） |
| 拒答率 | 需要与幻觉率一起看（第十七章 17.3） |
| P95 延迟 / 成本 | 体验与经济性 |
点踩数据的最大价值不是统计比例，而是作为评测集的来源——把点踩的 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 本章总结¶
- 必须分层评估：检索层、生成层、端到端、线上——只看总分无法定位问题；
- 检索层指标（Hit@K、Recall@K、MRR、NDCG）的价值在于组合起来做诊断：Hit@50 低 = 召回问题，Hit@50 高但 Hit@5 低 = 排序问题，Hit@5 高但答案差 = 生成问题；
- RAGAS 四指标：Faithfulness、Answer Relevancy、Context Precision、Context Recall；
- 四条局限：忠实度≠正确性、可被拒答刷满、LLM-as-Judge 有同源偏见、无参考答案导致方差大；适合看趋势不适合当绝对分；
- 端到端还要测 Citation 完整性/正确性/可访问性、固定时刻的时效性，以及成对扰动下的鲁棒性；
- 端到端推荐组合：程序化断言为主 + LLM-as-Judge 补充 + 人工抽查校准；
- 评测集分三档（Smoke / Regression / Full），必须包含无答案、诱导、时效、引用和鲁棒性成对问题；
- LLM 生成的题目必须人工改写，否则检索指标虚高；
- 公开基准用于横向比较；真实场景分数依赖数据、任务和评判口径，不能脱离版本横比；
- 线上点踩数据是高价值的问题来源，经过脱敏、分诊和标注后再进入评测闭环。