RAG 系统评测实战：从指标设计到落地闭环
前言
企业落地 RAG（Retrieval-Augmented Generation）最常见的误区是：搭建完检索管线、接上大模型、跑通 demo 就上线。上线后才发现，回答质量忽高忽低，有时引用的文档并不存在相关内容，有时明明有答案却漏召回。问题出在哪里？大多数团队缺少一个把 RAG Pipeline 的每个环节拆开看的评测机制。本文从"管好检索、评好回答、建立闭环"三个层面，聊一聊一套可落地的 RAG 评测方案。
一、RAG 评测为什么难做
一个 RAG 系统由检索器（Retriever）和生成器（Generator）两部分组成，中间还夹着重排序、片段截断、Prompt 组装等环节。评测难做的根源，是这整条链路是分段式系统，每段的错误都会污染下游。检索器漏召了一个关键片段，生成器会基于不完整的事实组织回答，最后输出的结果可能看起来流畅完整，但依据已经偏了。
另一个难点是评测对象的非确定性。大模型生成部分带有随机性，同样的检索结果两次生成可能措辞不同，这让"对不对"变成了"相似度多高够及格"。如果只用一个硬性的正确率指标，很容易把细微措辞差异判成失败，或者把实质错误掩盖在流畅表达下面。
还有一个被低估的问题：评测集的质量决定了评测结果的可信度。如果评测问题太简单、或者答案可以直接在模型训练数据里找到，那么 RAG 的价值根本体现不出来。好的评测集需要区分"RAG 是否真的帮到了模型"和"模型本身会不会"。
二、评测什么：检索层和生成层分开评
2.1 检索层评测
检索层的评测可以脱离大模型独立进行，这是 RAG 评测最可控的部分。
核心指标有三个。**召回率（Recall）**衡量在所有相关文档里，检索器找回了多少。比如一个查询有 3 条相关文档，检索器召回了 2 条，召回率就是 2/3。召回率直接反映检索器有没有漏掉关键信息。**精确率（Precision）**衡量召回的片段里有多少是真正相关的。召回率 100% 但精确率很低，说明拉回来一大堆噪音，模型生成时会被干扰。**MRR（Mean Reciprocal Rank）**衡量相关文档在返回结果里的排名位置，排名越靠前得分越高。MRR 对需要靠前位片段回答问题的场景特别敏感。
检索层评测还有一个实用指标叫 NDCG（Normalized Discounted Cumulative Gain），它不仅看相关文档是否被召回，还看相关程度的高低排序。用户问"怎么退款"，如果排在第一位的片段是"怎么发货"，第二位才是退款说明，NDCG 会比反过来低很多。
2.2 生成层评测
生成层的评测关注的是大模型基于检索结果最终给出的回答质量。这里分两类指标。
事实准确性：回答里的陈述是否与检索片段一致，有没有编造不存在的信息。这是 RAG 评测最核心的指标，因为 RAG 的初衷就是用外部知识替代模型记忆。
上下文忠实度（Faithfulness）：回答中的每个主张是否都能在检索到的片段里找到依据。忠实度高不代表回答完整，但忠实度低通常意味着模型在"自己编"。
答案完整性：回答是否覆盖了问题的全部要点。完整但不忠实是幻觉，忠实但不完整是漏答。
2.3 端到端评测
端到端评测把检索和生成串起来，看最终用户拿到手的回答是否满足需求。端到端评测有两种常见做法。一种是用标注好的"标准答案"做相似度比对，适合答案相对固定的场景。另一种是用 LLM-as-Judge 对回答做多维度打分，适合答案开放、需要语义判断的场景。
三、指标体系
3.1 核心指标分类
| 指标 | 作用 | 测量方式 |
|---|---|---|
| 召回率 | 检索是否漏掉关键文档 | 标注文档匹配计数 |
| 精确率 | 检索结果是否干净 | 标注片段相关性计数 |
| MRR | 相关文档是否排在前面 | 第一相关文档排名的倒数均值 |
| NDCG | 排序质量 | 多档相关性加权排序得分 |
| 忠实度 | 回答有没有编造 | 逐句与检索片段比对 |
| 准确率 | 回答内容是否正确 | 与标准答案比对或专家评判 |
| 完整率 | 是否覆盖全部问题要点 | 逐要点检查 |
3.2 三类评测集
评测集的设计直接影响指标的参考价值。建议从三个维度构造成本：
基础集：10-50 条高频问题，覆盖核心业务场景，用于日常回归和快速验收。这组问题应该足够简单，让任何一次改动都能快速看到效果变化。
深度集：50-200 条，覆盖多跳推理、模糊查询、跨文档整合等复杂场景，用于版本对比和压力测试。深度集的问题通常需要多段检索内容才能回答完整。
对抗集：20-50 条精心构造的反例，包括：问题里包含未收录信息、要求超出权限的回答、需要时间推理才能判断的陷阱问题。对抗集用来验证系统的安全边界，确保它在不该回答的时候能守住底线。
四、怎么打分：确定性指标优先
RAG 评测的评分同样遵循分层原则：能脚本算的绝不用模型估，需要语义判断的才交给模型。
4.1 确定性指标层
召回率、精确率、MRR、NDCG 都可以通过标注集和脚本直接计算，不需要大模型参与。这些指标的优点是客观、可复现、成本低。建议把这组指标作为每日或每次发版前的必跑项，建一个简单的基线表，每次改动后对比趋势。
如果检索器用向量数据库做近似最近邻搜索，还要额外关注一个指标：检索延迟。向量检索的精度和速度通常需要权衡，P95 检索耗时超过阈值会直接影响用户体验。这个指标完全可以用脚本打点统计，不需要人工介入。
4.2 语义判断层
忠实度、准确率、完整率这三项需要语义理解，交给 LLM-as-Judge。Judge 的输入应该是结构化的：问题、检索到的片段列表、模型生成的回答，而不是原始的 pipeline 日志。Judge 的 Prompt 要明确评分标准和输出格式，避免开放式打分。
一个可落地的 Judge Prompt 结构：先列出检索片段，再给出模型回答，然后逐句检查回答里的每个主张是否能在片段里找到依据。找不到的标记为"无依据"，再统计无依据句占总句数的比例，这就是忠实度得分。
4.3 人工抽检层
LLM-as-Judge 的偏差在 RAG 评测里表现得尤为明显：位置偏差（检索片段顺序不同打分不同）、长度偏差（引用片段越多回答越长分越高）。人工抽检用来校准 Judge 的评分分布，尤其是对抗集里的边界样本。
建议每次大版本迭代后随机抽 20-50 条计算 Judge 与人工的一致性（Cohen's Kappa）。如果 Kappa 低于 0.6，说明 Judge Prompt 需要重新调整评分标准，而不是直接信任自动评分结果。
五、常见评测陷阱
5.1 评测集泄露
评测集的问题和标注文档如果混入了模型的训练数据，评测结果会虚高。尤其是用公开 benchmark 评测时，很多问题已经被模型"学过"了。解决方法是在评测集构建阶段做数据清洗，或者换用领域专属的闭源语料构造问题，确保模型没有见过。
5.2 只评生成不评检索
很多团队评测时只拿最终回答和标准答案比，跳过检索层。这种做法的问题在于：如果检索层已经漏召了关键文档，生成层不管怎么优化都补不回来。把检索和生成分开评测，才能定位问题是出在"没找到"还是"找到了没说对"。
5.3 用相似度代替忠实度
RAG 场景里，回答和标准答案的语义相似度高，不代表它就是对的。模型可能引用了错误的文档但措辞恰好接近正确答案，这种"蒙对"在相似度指标里看不出来。忠实度检查是 RAG 评测区别于普通问答评测的关键步骤，不能省。
5.4 忽略片段质量
同样的检索结果，切分方式不同会导致模型理解差异很大。评测时不仅要看检索出了哪些片段，还要看片段是否被截断在语义完整的边界上。一段被从中间切开的文档可能会丢失关键条件或结论，导致模型做出错误推断。建议在评测指标里加入"片段完整性检查"，统计召回片段中在语义边界处被截断的比例。
六、建立持续评测流程
RAG 系统上线后不是一劳永逸的。知识库会更新、用户提问方式会变、模型版本会升级，每次变更都可能影响某个环节的表现。
一个实用的持续评测流程分三步。第一步是发版前必跑：基础集全量跑，深度集采样跑，输出核心指标的当前值和基线差值，不达标不发版。第二步是增量用例补充：把线上用户提问、人工质检发现的问题回流成评测用例，持续扩充对抗集。第三步是定期评审：每季度审查一次评测集的覆盖度，淘汰已经过时的用例，补充新出现的业务场景。
评测结果的可视化也很重要。至少维护三个看板指标：检索层的召回率和精确率趋势、生成层的忠实度和准确率趋势、端到端的用户满意度或业务完成率。当某一层的指标突然下降时，看趋势图就能快速判断是检索器的问题还是生成器的问题，还是两端都出了问题。
七、结语
RAG 系统的评测本质上是在回答一个问题：用户拿到手的回答，是否真的来自我们托管的文档，而不是模型自己的"脑补"。检索层管"有没有找到"，生成层管"找到之后怎么说对"，端到端管"用户是否满意"。三层分别评测，才能把问题定位到具体环节。
几条实操建议值得落地时参考：先把检索层的召回率和精确率跑顺，再优化生成质量；评测集宁可少而精，不要多而糙；把对抗集当成安全护栏，定期验证系统有没有越界回答；最终让评测成为 RAG 迭代的标尺，而不是上线前的一次性检查。