09-RAG 评测体系：从 Hit@K、MRR 到 Faithfulness

上一篇讲幻觉治理时，重点放在引用、拒答、证据约束和答案后校验。治理手段设计出来以后，还会遇到一个更现实的问题：怎么证明系统真的变好了。

RAG 的效果很容易被主观感受带偏。几条测试问题回答得不错，不代表整体稳定；一次线上反馈很差，也不一定说明整个链路都坏了。RAG 的答案来自文档、索引、召回、Rerank、上下文、Prompt 和模型生成的组合，最终体验变好或变差，背后可能来自任何一层。

所以，RAG 评测的核心，是把最终答案拆回证据链路里观察。检索层要看正确证据有没有被找回来，上下文层要看证据有没有干净地进入 Prompt，生成层要看答案是否忠实、相关、可引用，线上层要看真实用户是否解决了问题，同时还要关注延迟和成本。

这一篇的核心判断可以先放在前面：

RAG 评测不能只看最终答案是否顺眼。更稳的方式，是用 Golden Set 固定问题和标准证据，用检索指标评估候选覆盖，用生成指标评估答案忠实度，用 trace 回放定位失败层级，再用线上反馈持续修正评测集。

RAG 评测要拆成多层

普通问答系统评测往往更关注最终答案。RAG 的复杂之处在于，最终答案只是链路末端。答案正确，可能是因为检索找到了证据，也可能是模型靠参数知识答对了。答案错误，可能是文档缺失，也可能是召回漏掉、Rerank 排错、上下文截断、Prompt 约束弱、模型生成时越界。

因此，RAG 评测要把链路拆开。一个相对完整的评测视角可以这样看：

问题与期望证据
  -> query 改写结果
  -> 召回 topK
  -> Rerank 排序
  -> 最终上下文
  -> 模型答案
  -> 引用与后校验
  -> 用户反馈和线上指标

这条链路里，每一层都有不同指标。检索指标主要回答“证据有没有找回来”。上下文指标关注“给模型的证据是否干净完整”。生成指标关注“答案是否回答了问题，是否被证据支持”。线上指标关注“真实用户是否觉得有用，系统成本是否可接受”。

评测层次	核心问题	常见指标
检索层	正确证据有没有进入候选池	Hit@K、Recall@K、Precision@K、MRR、NDCG
上下文层	最终 Prompt 里的证据是否完整干净	Context Recall、Context Precision、证据完整性
生成层	答案是否相关、忠实、可引用	Faithfulness、Answer Relevancy、Answer Correctness、引用准确性
线上层	用户是否真的解决问题，成本是否可接受	点踩率、追问率、转人工率、引用点击率、延迟、成本

分层评测的意义在于定位。最终答案差，只知道差在哪里，才能知道该改哪一层。盲目换模型、调大 topK、增加 Prompt 都可能暂时改善个别样本，却让系统在其他问题上退化。

Golden Set 是评测的核心资产

RAG 评测首先需要一批稳定样本。这个样本集通常可以叫 Golden Set，也就是用来持续回归的标准问题集。

一个好的 Golden Set 除了问题和标准答案，还应该包含标准证据。对 RAG 来说，证据比答案更关键。因为系统的目标是基于知识库回答，不能依赖模型记忆碰巧答对。一个样本最好能记录用户问题、会话上下文、期望命中的文档或 chunk、允许引用的来源、标准答案要点、必须保留的限制条件，以及在证据不足时是否应该拒答。

Golden Set 的来源应该尽量贴近真实业务。早期可以从文档目录、FAQ、客服工单、内部问答、产品手册里人工构造一批问题。系统上线后，用户点踩、追问、转人工、后校验失败和人工修正的样本，都应该持续回流。这样评测集会从“覆盖知识点”逐渐变成覆盖真实失败模式。

Golden Set 还要包含负样本。很多 RAG 系统只评估能回答的问题，忽略了应该拒答的问题。比如知识库没有相关文档、用户问了权限外内容、问题缺少版本条件、多个来源存在冲突，这些样本能测试系统是否会在证据不足时收敛。

评测集的价值不取决于规模本身，关键是结构合理。它应该覆盖高频问题、复杂问题、边界问题、精确匹配问题、多轮指代问题、需要拒答的问题和历史失败样本。每次调整 chunk、embedding、检索策略、Rerank、Prompt 或模型版本，都要用同一批样本回归，观察改动到底影响了哪一层。

Golden Set 字段	作用
用户问题和会话上下文	复现真实输入
标准证据 / 标准 chunk	判断检索和上下文是否命中
标准答案要点	判断最终答案是否正确
必须保留的限制条件	防止答案过度概括
是否应该拒答	测试证据边界和拒答能力
失败层级标注	帮助后续定位和聚类

检索指标看正确证据有没有回来

检索评测关注的是候选证据。它通常不需要等模型生成答案，只要比较召回结果和标准证据，就能判断检索层是否有效。

Hit@K 是最直观的指标。它关心前 K 个检索结果里有没有至少一个正确证据。比如 Hit@5 表示正确 chunk 是否出现在前 5 个结果中。这个指标适合看“答案入口是否打开”。如果 Hit@K 很低，说明正确证据经常进不了候选池，后面的 Rerank 和生成很难补救。

Recall@K 关注标准相关证据被覆盖了多少。一个问题可能需要多个证据共同回答，比如配置步骤、前置条件和限制说明分散在不同 chunk 里。Hit@K 只要命中一个就算成功，Recall@K 会进一步看相关证据覆盖比例。对需要综合多段证据的问题，Recall@K 更有价值。

Precision@K 关注前 K 个结果里有多少是相关证据。它衡量候选池纯度。Recall 高但 Precision 低，说明正确证据可能找回来了，但噪声也很多。噪声会增加 Rerank 压力，也会污染上下文。RAG 的检索层不能只追求覆盖，还要控制进入后续阶段的候选质量。

MRR 关注第一个正确结果的位置。它的全称是 Mean Reciprocal Rank。如果正确证据排在第一位，得分高；排得越靠后，得分越低。这个指标适合评估排序体验。对于只取少量 topK 进入上下文的系统，第一个正确证据的位置非常重要。

NDCG 更适合多相关结果和分级相关性。某些证据直接回答问题，某些证据只是背景补充，某些证据提供限制条件。NDCG 可以把不同相关程度和排序位置一起考虑，更贴近复杂 RAG 场景。

这些指标的价值不在于名字本身，而在于它们分别照亮不同问题。Hit@K 低，优先看召回覆盖。MRR 低，优先看排序。Precision@K 低，优先看噪声控制。Recall@K 低，优先看多证据覆盖。NDCG 低，说明排序和相关性分级还需要调整。

指标	主要回答的问题
Hit@K	正确证据有没有出现在前 K 个结果里
Recall@K	多个标准证据覆盖了多少
Precision@K	前 K 个结果里噪声多不多
MRR	第一个正确证据排得靠不靠前
NDCG	多个相关结果的排序质量如何

检索评测要区分召回和 Rerank

实际排查时，检索评测最好拆成召回前后两层。第一层看多路召回后的候选池，第二层看 Rerank 后的排序。

如果正确证据没有出现在召回 topN 里，说明问题在 query、索引、chunk、embedding、关键词检索或 metadata filter。此时调 reranker 没有意义，因为它没有机会看到正确证据。

如果正确证据出现在召回 topN 里，但 Rerank 后掉到很后面，问题就更接近排序模型、排序特征或业务权重。此时要看 reranker 是否理解领域表达，候选是否缺少标题和 metadata，来源质量权重是否合理，旧版本文档是否被错误加权。

如果 Rerank 后正确证据排在前面，但最终上下文没有包含它，问题可能在 topK、token 预算、去重、合并或截断策略。这个问题已经进入上下文工程层，继续调检索召回可能收益有限。

因此，评测时要保存多个中间结果。只保存最终答案，会丢掉定位能力。一个成熟的 RAG 评测系统，应该能回放每个样本的 query 改写、召回候选、Rerank 排序、上下文打包和最终回答。

观察结果	更可能的问题层级
召回 topN 没有正确证据	query、索引、chunk、embedding、关键词检索或 metadata filter
召回 topN 有正确证据，但 Rerank 后靠后	reranker、排序特征、来源权重或领域适配
Rerank 后靠前，但最终上下文没有	topK、token 预算、去重、合并或截断
上下文有正确证据，但答案仍错	Prompt 约束、模型生成、引用或后校验

上下文指标看证据是否适合生成

检索结果进入 Prompt 之前，还要经过上下文工程。这个阶段也需要评测，因为模型真正看到的是上下文，完整候选池只停留在前面的检索和排序阶段。

Context Recall 关注标准证据是否进入最终上下文。它和检索 Recall 有关系，但层级不同。检索 Recall 看候选池有没有，Context Recall 看 Prompt 里有没有。很多问题就是在这一步丢证据：召回命中了，Rerank 也排上来了，最后因为 token 预算或去重策略被删掉。

Context Precision 关注最终上下文中有多少内容真正与问题相关。上下文里如果塞了太多弱相关材料，模型会受到干扰。Context Precision 低时，答案可能出现上下文污染，幻觉治理也会变得困难。

上下文评测还要看证据完整性。单个 chunk 可能命中了关键句，但缺少标题、版本、表头、前置条件或例外说明。此时 Context Recall 看起来命中，模型仍然可能答错。对于表格、代码块、配置示例和制度条款，上下文是否保留结构信息非常重要。

还可以评估引用准备质量。进入上下文的证据是否有 source_id，source_id 是否能回到原文，版本和更新时间是否保留，引用粒度是否足够细。这些信息会直接影响后面的可追溯性和答案校验。

上下文指标把评测从**“找没找到”推进到“给模型的材料是否可用”**。这一步做好以后，生成层的稳定性才有基础。

生成指标看答案是否相关和忠实

生成评测关注最终答案。RAG 场景里的答案不能只看流畅度，还要看它是否回答用户问题，是否被上下文支持，是否保留证据边界，是否给出正确引用。

Answer Relevancy 关注答案和用户问题是否匹配。一个答案可能事实正确，但没有回答当前问题。用户问“这个接口的限流是多少”，模型回答接口调用步骤，语言再完整也偏离了问题。Answer Relevancy 低时，要看问题理解、上下文布局和生成指令。

Faithfulness 关注答案是否忠实于给定上下文。它衡量回答中的事实声明能否从证据中推出。RAG 幻觉治理里最关心的就是这个指标。答案说“企业版支持自定义保留周期”，上下文里必须有对应证据。答案补充了上下文没有的数值、版本或承诺，就会降低 Faithfulness。

Answer Correctness 关注答案整体是否符合标准答案或人工标注。它比 Faithfulness 更接近用户视角。一个答案可能忠实于上下文，但上下文本身是旧文档，最终仍然错误。此时生成层没有越界，问题发生在检索和上下文侧。

引用准确性也应该单独看。答案里标注的 source_id 是否存在，引用段落是否真的支持对应结论，多个结论是否能分别追到不同证据。只要引用不准确，答案的可追溯性就会下降。

生成指标通常需要人工评审或 LLM-as-judge。人工评审更可靠，但成本高。LLM-as-judge 速度快，适合大批量回归，但需要明确评分标准，还要用人工样本校准。评测 Prompt 要稳定，评分维度要清楚，最好给出等级和原因，方便对失败样本做聚类。

生成指标	关注点
Answer Relevancy	是否回答了用户当前问题
Faithfulness	答案事实是否被上下文支持
Answer Correctness	答案整体是否符合标准答案或人工判断
引用准确性	source_id 是否存在，引用是否支撑结论

LLM-as-judge 要有边界

用大模型评测大模型很方便，但需要谨慎。评测模型本身也可能误判，尤其是在专业领域、长上下文、多证据引用和细微事实差异上。

LLM-as-judge 更适合做批量初筛和趋势观察。比如同一批 Golden Set，在改动前后分别跑一遍，观察 Faithfulness、Answer Relevancy、引用准确性是否整体变化。它可以帮助快速发现退化样本，也能把失败原因归类成证据不足、回答偏题、引用错配、过度概括等。

高风险样本仍然需要人工复核。特别是金融、法律、医疗、安全、合规、生产运维这类场景，评测模型给出的高分不能直接当作上线依据。人工评审可以抽样校准 LLM-as-judge，发现它对哪些问题容易宽松或误判。

为了让 LLM-as-judge 更稳定，评分标准要尽量具体。不要只问“答案好不好”，而要分别评估是否回答问题、是否基于证据、是否包含未支持声明、引用是否准确、证据不足时是否拒答。每个维度给出清晰等级，评测结果才更适合工程分析。

Trace 回放是定位问题的关键

RAG 评测如果只输出一个总分，很难指导优化。真正有用的是 trace 回放。

trace 回放记录一次请求从输入到输出的中间状态。它应该包括原始 query、改写 query、metadata filter、召回结果、Rerank 分数、最终上下文、Prompt 版本、模型答案、引用映射、后校验结果和用户反馈。

Trace 信息	可以定位什么
原始 query / 改写 query	问题是否被误解或改偏
metadata filter	权限、版本、时间条件是否误过滤
召回结果 / Rerank 分数	正确证据是否进入候选并排到前面
最终上下文	证据是否在打包阶段丢失或污染
Prompt 版本 / 模型答案	生成约束是否生效
引用映射 / 后校验结果	答案是否被证据支持

当一个样本失败时，可以按 trace 分层定位。正确文档是否存在于知识库。正确 chunk 是否被切出来。召回 topN 是否包含它。Rerank 是否把它排到前面。上下文是否保留它。Prompt 是否明确要求证据边界。答案里的结论是否能被引用支持。

这种回放能力会让评测从“打分”变成“诊断”。比如 Faithfulness 下降，可能是模型变差，也可能是上下文污染加重。Hit@K 提升，最终答案却下降，可能是召回扩大后噪声进入上下文。延迟下降，答案质量下降，可能是候选 topN 或 rerank 阶段被削弱。

trace 还能帮助做回归对比。同一个问题在改动前后，召回结果、排序、上下文和答案有什么变化。这样可以判断一个优化到底改好了哪一层，又损伤了哪一类样本。

线上指标看真实使用效果

离线评测再完整，也只能覆盖有限样本。RAG 上线后，还需要观察真实用户行为。

点踩率是最直接的负反馈，但它很粗。用户点踩可能是答案错了，也可能是答案不完整、表达不清、没有引用、操作不可执行、响应太慢。点踩样本要进入 trace 回放，不能只作为一个数字留在报表里。

追问率可以反映答案是否一次解决问题。用户看完后继续问“具体怎么做”“你确定吗”“来源在哪”，说明答案可能缺少步骤、证据或边界。转人工率适合客服和内部支持场景，能反映系统无法解决的比例。

引用点击率也有参考价值。用户点击引用，可能说明他需要验证答案；引用点击后停留时间较长，可能说明引用有帮助。若答案经常没有引用点击，也可能是引用位置不明显或用户对答案已经满意。线上指标要结合业务场景解释，不能孤立下结论。

还要看延迟、成本和稳定性。RAG 优化经常会增加 Query Rewrite、多路召回、Rerank、后校验和更大模型调用。质量提升如果伴随延迟和成本大幅上升，就要看业务是否能接受。一个生产系统需要在质量、速度、成本之间找到可持续平衡。

线上失败样本要回流到离线评测

RAG 评测最重要的闭环，是把线上失败样本变成离线 Golden Set 的一部分。

线上反馈能暴露真实分布。用户会问文档里没写的问题，会使用系统没有预料到的缩写，会提出带上下文的多轮追问，也会触发权限、版本、地区和产品线边界。这些样本比人工构造的问题更能代表系统未来会遇到的风险。

失败样本回流时，要补齐标注。只保存用户问题不够，还要标注正确证据、期望答案、失败层级和修复方式。比如某个问题失败是因为文档缺失，就应该标成知识库问题；某个问题失败是因为 metadata 过滤错误，就应该标成检索约束问题；某个问题失败是因为答案没有拒答，就应该标成生成约束问题。

这样做的好处是，每次修复都可以沉淀成回归样本。下一次换 embedding、改 chunk、调 Rerank、更新 Prompt 或升级模型时，这些历史失败样本可以防止问题重新出现。

Golden Set 也需要版本管理。评测集会增长，标注会修正，知识库会更新。每次评测应该记录评测集版本、索引版本、模型版本、Prompt 版本和参数配置。否则不同实验之间很难比较。

A/B 和灰度验证生产效果

离线评测适合快速筛选方案，线上 A/B 和灰度适合验证真实效果。

一个检索策略在 Golden Set 上提升，在线上未必同样提升。原因可能是离线样本分布不完整，也可能是新策略增加了延迟，导致用户体验下降。A/B 可以让部分流量使用新方案，比较点踩率、追问率、转人工率、引用点击、延迟和成本。

灰度验证要有护栏。比如后校验失败率不能上升，拒答率不能异常增加，权限相关错误必须为零容忍，高风险问题要人工抽检。上线评测不能只看平均分，还要看关键场景是否退化。

对于 RAG 来说，平均指标有时会掩盖长尾风险。多数简单问题变好，少数合规问题变差，整体均分可能仍然提升，但业务风险变高。因此线上评测要按问题类型、文档域、用户角色、产品版本和风险等级分组看。

实验结束后，保留失败样本和对比 trace。这样即使方案没有上线，也能沉淀经验。评测的价值不只在于决定上线，也在于理解系统边界。

评测要同时看质量、延迟和成本

RAG 优化经常带来成本权衡。增加多路召回可能提升 Recall@K，也会增加检索延迟。加入 reranker 可能提升 MRR 和 Faithfulness，也会增加推理成本。答案后校验可以降低无依据输出，也会增加一次模型调用。更大的上下文窗口可以保留更多证据，也会增加 token 成本和生成时间。

所以，评测报告里不能只放质量指标。至少要同时记录平均延迟、P95 延迟、模型调用次数、token 消耗、检索次数、rerank 候选数量、后校验触发率和拒答率。

质量指标提升但成本不可控，生产上很难长期运行。成本下降但 Faithfulness 明显下降，也会损害系统可信度。RAG 的工程评测要把质量、延迟、成本放在同一张图里看。

这也是为什么评测不能只服务于算法调参。它还服务于产品决策和工程治理。不同场景可以接受不同权衡。内部知识库深度问答可以慢一点，客服实时问答需要更快，高风险合规问答需要更严格的证据和校验。

RAG 评测方案怎么组织

真正设计 RAG 评测方案时，应该先分层。

可以先说，RAG 评测要拆成检索、上下文、生成和线上反馈。检索层看 Hit@K、Recall@K、Precision@K、MRR、NDCG，判断正确证据有没有被召回以及排序是否靠前。上下文层看 Context Recall 和 Context Precision，判断最终进入 Prompt 的证据是否完整干净。生成层看 Faithfulness、Answer Relevancy、Answer Correctness 和引用准确性，判断答案是否回答问题、是否忠实证据、是否可追溯。线上层看点踩率、追问率、转人工率、引用点击率、延迟和成本。

然后补充 Golden Set 和 trace。Golden Set 里要有真实问题、标准证据、期望答案、拒答样本和历史失败样本。每次改 chunk、embedding、检索、Rerank、Prompt 或模型，都用同一批样本回归。trace 用来定位问题发生在文档、召回、排序、上下文还是生成。

最后说明闭环。线上失败样本要回流到离线评测集，评测集和索引、模型、Prompt 一起做版本管理。这样才能持续证明系统变好，避免只凭几条 demo 问答判断。

这种组织方式能体现一个核心判断：RAG 是证据链路，评测也必须围绕证据链路设计。

小结

RAG 评测的目标，是证明系统在真实问题上更稳定地找到证据、更干净地组织证据、更忠实地生成答案，并且在延迟和成本上可接受。

检索指标回答证据有没有进入候选池，Rerank 和上下文指标回答证据有没有进入 Prompt，生成指标回答答案是否相关、忠实、可引用，线上指标回答真实用户是否解决了问题。Golden Set 提供可重复回归的基础，trace 回放提供失败定位能力，线上样本回流让评测集持续贴近真实场景。

理解评测体系以后，RAG 就不再只是“效果感觉还行”的黑盒。每次优化都可以被拆解、度量、回放和比较。下一篇进入知识库动态更新，重点会从“怎么评测当前效果”转向“知识不断变化时，索引、版本、权限和回滚怎么保证生产稳定”。