很多人做 RAG 评测时，会先算一个“答案准确率”。如果分数上涨，就认为系统变好了；如果分数下降，就继续换 Embedding、调 TopK 或改 Prompt。
问题是，RAG 不是一次模型调用。用户问题要经过 Query 处理、检索、排序、上下文组装、答案生成和引用回跳。最终回答错了，可能是正确证据根本没有被找回，也可能是证据已经排在前面，生成模型却漏掉了限制条件。只看一个端到端分数，团队仍然不知道应该修哪一段。
这也是项目面试里很容易被追问的一道题：
Recall@K、Precision@K、MRR、答案正确性和 Faithfulness，分别在评估 RAG 哪一层？如果几个指标互相矛盾，你会怎样定位问题？
如果只把几个英文缩写逐个翻译出来，回答还停留在知识点层面。面试官真正想听的是，你能不能沿着证据流解释每个指标，看懂指标组合背后的故障，并设计一套不会被自动裁判误导的评测方法。
先画清楚：一个 RAG 回答经过了哪些可评估节点
堆更多指标不能直接让评测变专业。每一个分数都要先回答一个明确问题。
用户提出问题以后，检索器给出一组候选 Chunk。这里要回答的是“应该找到的证据找到了多少”“返回内容里噪声有多少”“最有用的证据排在哪里”。
候选经过融合、重排和截断，真正进入 Prompt 的上下文往往只是其中一部分。这里要回答的是“生成模型实际看到的证据是否充分”。检索 TopK 命中了正确 Chunk，不等于这个 Chunk 最终一定进入上下文。它可能在 Rerank 后被挤掉，也可能因为上下文长度限制被截掉。
生成模型根据上下文写出答案。这里至少有三个不同问题：答案是否覆盖参考答案的要点，回答是否针对用户问题，答案里的事实是否都能被上下文支持。
如果产品还展示引用，最后还要检查“引用标记指向的原文是否真的支持这句话”“用户能否回跳到正确页码、段落或时间位置”。答案带了一个看起来合理的出处，不代表引用一定正确。
先看证据能否进入候选，再看排序、生成和引用。
这张链路图能解释为什么一个总体准确率不够。总体分数只能告诉你结果变了，分层指标才能提示原因可能在哪里。
算指标以前，先统一“相关证据”的粒度
公式不难，真正容易出错的是计分对象。
一份文档可能被切成几十个 Chunk。同一段内容也可能因为 Overlap 出现在相邻 Chunk 中。如果 Ground Truth 按文档标注，检索结果却按 Chunk 计分，那么“命中这份文档”和“命中能回答问题的具体段落”会被混成一件事。
评测前要明确相关性落在哪一层。
文档级适合判断正确资料有没有被找到。Chunk 级适合诊断切分与检索。信息点级适合多段证据问题，它记录每个答案要点需要哪一段支持。引用评测还要进一步落到答案陈述与证据位置的对应关系。
粒度不统一时，两个系统的分数没有可比性。一个系统返回整份长文档，文档级 Recall 可能很好；另一个系统精准命中答案段落，却因为 Chunk ID 与文档级标注不一致被误判。
同一套版本对比必须使用相同的知识库切分版本和标注粒度。Chunk 规则改变以后，旧 Chunk ID 也可能失效，需要重新建立证据映射，不能直接沿用原分数。
Recall@K：该找的证据有没有找回来
Recall@K 衡量的是覆盖率。
对一道问题，先有人工确认的必要证据集合，再看系统返回的前 K 条里命中了多少。可以写成：
Recall@K = 前 K 条中命中的必要证据数 / 全部必要证据数
假设一道教学题需要证据 A、B、C 三段原文共同回答。系统前五条里只找到了 A 和 C，那么 Recall@5 是 2/3，约为 0.67（只用于说明公式，不代表真实项目结果）。
Recall 最重要的使用场景，是检查“信息有没有漏”。如果问题需要多个条款、多个步骤或跨文档证据，只有其中一段命中，并不能算完整召回。
Recall 高，为什么答案仍然可能错？
因为“进入前 K 条”和“被模型正确使用”之间还有好几步。
正确证据可能排得太靠后，最后没有进入 Prompt。它也可能和大量相似 Chunk 一起出现，关键条件被噪声淹没。即使正确证据完整进入上下文，生成模型仍可能忽略否定词、时间范围或例外条件。
还有一种更隐蔽的情况：最终答案碰巧正确，但 Recall 很低。模型可能依靠训练阶段学到的常识作答，没有真正用到知识库。只看答案会把这次结果判为成功，只看 RAG 链路则应该标记为检索失败。
所以 Recall 是检索覆盖指标，不是最终答案质量指标。
K 越大，Recall 就一定越好吗？
扩大 K 往往更容易命中证据，也会增加噪声、重复、重排成本和上下文长度。报告 Recall@K 时必须说明 K 属于粗召回、重排结果还是最终上下文；同时保存粗召回与最终上下文的覆盖，才能区分“没找到”和“后处理丢掉了”。
Precision@K：前 K 条里有多少是真正相关的
Precision@K 衡量候选的纯度。
Precision@K = 前 K 条中的相关证据数 / K
仍用刚才的教学题。如果前五条只有 A 和 C 两条真正相关，那么 Precision@5 是 2/5，也就是 0.4（只用于说明公式，不代表真实项目结果）。
Precision 低，说明候选里夹着较多无关内容。对 RAG 来说，噪声不只是搜索结果不好看。它会占用上下文窗口，让模型把注意力分给无关段落，也会增加重排和生成成本。
但 Precision 也不能单独使用。一个系统只返回一条最确定的证据，Precision 可能很高，却漏掉回答所需的另一段例外条款。另一个系统返回更多候选，Precision 下降，Recall 却提高了。哪个更好，要看任务需要一条证据还是多条证据，以及后续重排能否处理增加的候选。
为什么“相关”必须先定义清楚？
同主题不等于能支持答案。例如问题询问例外条件，只有通用规则的段落只能算主题相关。标注时应把“主题相关”和“答案证据”分开，多证据题还要标明每段支持哪个要点，并按原文区间去重，避免多个相邻 Chunk 把 Precision 和 Recall 一起抬高。
MRR：第一条正确证据排得够不够靠前
MRR 的全称是 Mean Reciprocal Rank，也就是平均倒数排名。
先给每道问题算 RR：
RR = 1 / 第一条相关证据的名次
如果第一条相关证据排第一，RR 是 1；排第二，RR 是二分之一；前 K 条完全没有相关证据，RR 记为 0。再对所有问题的 RR 取平均，得到 MRR。
MRR 回答的是一个很具体的问题：用户或下游模型要走多远，才能看到第一条有用证据。
它尤其适合“找到第一条正确答案证据就能解决”的任务。例如一个事实型问题只需要一段明确原文，第一条正确证据越靠前，后续被截断或被噪声干扰的风险通常越低。
MRR 很高，为什么多跳问题仍可能失败？
MRR 只看第一条相关结果，不关心第二条、第三条必要证据在哪里。
一道问题需要 A 和 B 两段证据。A 排第一，B 完全没有召回，RR 仍然是 1。如果只看 MRR，会误以为排序已经很好，但这道题的上下文并不充分。
所以，多证据任务不能用 MRR 替代 Recall。可以把 MRR 用来观察首个证据位置，再用 Recall@K 或上下文充分性判断必要证据是否找齐。MAP 可以综合多个相关结果的排序情况。是否采用 MAP，要看一条问题是否确实存在多条经过标注的相关证据。
什么时候应该看 nDCG？
nDCG 适合一题存在多条不同相关度结果的场景，例如直接支持答案的条款是高相关，背景段落是部分相关。使用它的前提是相关性等级有稳定的人工标准；只有“必要证据”和“非必要证据”两档时，MRR、Recall 与 Precision 更容易解释。
指标实现本身并不复杂：截取前 K 条，按必要证据 ID 计算命中集合，再得到 Precision、Recall 和首条命中的倒数排名。真正困难的是计分边界：无答案题不能硬套普通 Recall，重复 Chunk 不能算多份证据，一个 Chunk 同时支持多个要点时也要先确定粒度。
答案正确性：有没有把问题答对
检索完成以后，生成阶段首先要看答案正确性。
对于答案唯一且很短的事实题，可以使用精确匹配、准确率或 F1。对于开放式回答，逐字匹配往往不公平。模型可能换一种说法，意思仍然正确；也可能复述了参考答案的大部分词，关键条件却写反了。
因此，开放答案更适合拆成答案要点。评审时检查必要要点是否覆盖、错误事实是否出现、限制条件是否保留。可以由人工根据参考答案和证据判断回答是否正确完整，也可以用词向量、BERTScore 或另一模型辅助评审。
答案正确性回答的是“结论对不对”。它没有直接回答“结论从哪里来”。这就需要 Faithfulness。
Faithfulness：每个事实能不能被本轮证据支持
Faithfulness 常被翻译为忠实度或事实一致性。它关注生成答案与检索上下文之间的关系。
评估时，可以先把答案拆成若干可核查的事实陈述，再检查每一条能否在本轮上下文里找到直接支持。没有证据支撑的事实，即使听起来合理，也不能算忠实。
这个指标解决了一个典型问题：模型可能答对，但答对的原因不是 RAG。比如知识库没有召回正确原文，模型凭自身知识给出正确结论。答案正确性可以通过，Faithfulness 或证据覆盖却应该暴露问题。
Faithfulness 高，答案就一定正确吗？
不一定。
模型可能非常忠实地复述了一段过期、错误或不完整的检索内容。此时答案与上下文一致，Faithfulness 可以很高，但答案对当前问题并不正确。
模型也可能忠实地回答了相关内容，却没有解决用户真正问的事。比如用户问例外情况，回答只复述通用流程。每句话都有出处，回答相关性和完整性仍然不合格。
因此，生成阶段至少要把三个维度分开：
- 正确性：结论与参考答案或答案要点是否一致。
- 相关性：内容是否直接回应用户问题。
- Faithfulness：事实是否被本轮上下文支持。
这三个维度互相补充，不能互相替代。
Recall、Precision、MRR、nDCG 和 Faithfulness 分别定位不同故障。
引用评估：有出处不等于出处能支撑答案
很多 RAG 页面会在答案后面显示 [1]、[2]。引用存在，只能证明系统输出了引用标记。
引用质量至少要看两件事。
第一是证据关联性。引用段落是否真的支持它旁边那句话。如果答案说的是适用条件，引用却只介绍概念背景，形式上有来源，事实上仍然张冠李戴。
第二是证据充分性。一个结论需要两段原文共同成立，系统只引用其中一段，答案可能遗漏限制条件。此时引用不是完全错误，但支持不充分。
如果产品支持原文回跳，还要把定位正确性单独检查。Chunk 文本对了，页码、段落或时间位置错了，用户仍然无法核验。这个问题更偏向元数据和前端链路，不应混进生成模型的 Faithfulness 分数里。
指标冲突时，怎样定位是哪一段坏了
面试中真正拉开差距的部分，不是背公式，而是读懂指标组合。
情况一：Recall 低，答案正确
先不要庆祝答案正确。检查模型是否依靠自身知识碰巧答对，也检查正确证据是否在粗召回之外被其他路径带入上下文。
如果答案事实无法回到本轮证据，这次结果不应被算成 RAG 链路成功。优先检查文档解析、Chunk 边界、Query 改写、过滤条件、Embedding 和召回策略。
情况二：Recall 高，MRR 低
正确证据找到了，但排得太靠后。优先检查混合检索融合、Rerank、时效性或权限过滤后的排序，以及最终上下文截断。
这时继续扩大候选 K 可能不会解决问题，反而增加成本。更关键的是让最有用的证据进入模型实际可见的位置。
情况三：Recall 和 MRR 都正常，Faithfulness 低
检索结果大概率已经可用，问题更可能出在上下文组织、Prompt 约束、答案生成或事实归因。
要查看模型实际收到的 Prompt，而不是只看向量库返回结果。检查关键证据是否在拼接时被截断，多个片段是否相互冲突，模型是否把外部常识写进答案。
情况四：Faithfulness 高，答案正确性低
模型忠实使用了上下文，但上下文本身可能错误、过期或不充分。也可能是参考答案和知识库版本不一致。
优先核对证据质量、版本、必要证据清单和 Ground Truth，不要直接把责任推给生成模型。
模型可能靠常识答对，也可能忠实复述错误证据；答案、证据和引用必须一起检查。
为什么不能把所有指标压成一个总分
综合分可以做版本看板，不能替代诊断。即使按业务风险加权，也要保留原始分项，并按事实题、多证据题、表格题、否定题和无答案题切片，避免平均值掩盖关键退化。
离线指标还要和运行指标分开。Recall、MRR、Faithfulness 主要评价质量；延迟、吞吐、模型调用次数和上下文长度评价成本与体验。一个排序模型提高 MRR，却让链路慢到不可接受，仍然不能直接上线。
更稳的结论形式是：“这次改动主要改善哪一层，哪些题型收益明显，哪些维度退化，额外成本是什么，是否通过既定门槛。”它比“总分提升”更能支撑工程决策。
LLM-as-a-judge 为什么也要被评测
开放答案很难完全靠字符串匹配，可以让另一个大模型辅助判断正确性、相关性或 Faithfulness。但自动裁判会受评审 Prompt、证据长度、领域表达和模型版本影响，它的分数不是天然真值。
一套可以落地的裁判校准流程
先用一批人工金标样本校准，覆盖正确、部分正确、证据不足、答案外事实和引用错位。固定裁判模型、版本、评审 Prompt 与输入字段，把“是否覆盖必要要点”“是否出现证据外事实”“引用是否支撑陈述”拆开判断，再检查人机分歧集中在哪些题型。
只有稳定维度才适合批量运行；高风险题、低置信度题和人机分歧集继续人工复核。每次还要保存问题、参考答案、证据、待评答案、评审 Prompt 和裁判版本，防止裁判变化被误认为 RAG 变化。
先用人工金标确认裁判可用范围，再将自动指标用于扩大覆盖。
裁判分数和人工不一致，听谁的？
先回到评分规则和证据。人工之间也不一致，说明规则需要拆细；规则清楚而裁判持续误判某类否定或多证据问题，就让该类样本转人工。自动裁判负责扩大筛查范围，不替代最终责任。
一次版本对比，最低限度应该保存什么
只保存汇总分数，后续几乎无法复盘。每次评测至少要保留知识库与数据版本、处理后的 Query、粗召回与重排顺序、最终上下文、答案与引用、逐题评分理由，以及裁判模型和 Prompt 版本。
这些记录必须能从失败答案反查到证据入库、Query、召回、排序、上下文、生成和引用中的具体一层。
对比版本时，一次尽量改变一个主要因素，并保留基线配置。混合检索、Rerank、Prompt 和生成模型同时变化，即使最终分数上涨，也很难说明是哪项改动带来的。
面试官继续追问，怎么接
追问一：Recall@K 很高，为什么不能证明检索已经做好了？
因为它只说明必要证据进入了前 K 条，不说明候选是否干净、证据是否排在模型可见位置，也不说明最终上下文是否保留了它。还要结合 Precision、MRR、冗余和最终上下文覆盖。
追问二：MRR 适合评价所有 RAG 问题吗？
不适合。MRR 只看第一条相关证据，适合首个正确结果很重要的任务。多跳或多证据问题还要看必要证据覆盖，不能用一个排第一的片段掩盖其他证据缺失。
追问三：Faithfulness 高，为什么仍然不能上线？
因为模型可能忠实复述错误、过期或不完整的上下文。还要检查答案正确性、相关性、证据充分性、引用定位和无答案处理。
追问四：没有参考答案时，怎么评估？
可以用上下文相关性、Faithfulness 或 LLM 裁判做辅助诊断，也可以抽样人工复核。但无参考评估不等于真值，重要版本仍应在有人工标准和支持证据的样本上验证。
追问五：自动裁判怎样证明可靠？
用一批人工金标样本做校准，固定裁判模型、Prompt 和输入字段，分析人机分歧，保留高风险与低置信度样本的人工复核。模型或 Prompt 变化后重新校准。
追问六：如果只能选一个检索指标，你选什么？
先看任务。单证据事实问答可以优先看 MRR 或 Hit@K，多证据问题优先看 Recall@K，候选要直接交给生成模型时还要重视 Precision 与冗余。真正的工程评测通常不会只保留一个指标。
最后完整说一遍
如果面试官让你用 60 到 90 秒完整回答，可以这样组织：
RAG 是一条证据流，所以我不会用一个准确率评价整条链路。检索层先看 Recall@K，判断必要证据有没有进入前 K 条；再看 Precision@K，判断候选噪声；用 MRR 看第一条正确证据排在哪里。多证据问题不能只看 MRR，还要看证据是否找全以及上下文是否充分。生成层把答案正确性、回答相关性和 Faithfulness 分开，正确性看结论对不对，相关性看有没有真正回答问题，Faithfulness 看每个事实能否被本轮上下文支持。引用还要独立检查关联性、充分性和原文定位。指标异常时沿着链路排查，例如 Recall 低先看解析、Query 和召回，Recall 正常但 MRR 低看融合与重排，证据已经靠前但 Faithfulness 低再看上下文组织和生成。自动裁判只用于扩大覆盖，必须先用人工金标校准，并固定裁判模型和 Prompt。最终保留分层指标、逐题结果和运行成本，不能只报一个总分。
这道题答得好，不在于背出多少指标名称，而在于每个指标都能落到一段链路、一个故障假设和下一步排查动作。