大多数团队评估 RAG 的方式是：准备一批问题，跑一遍，人工或用模型给最终答案打分，得到一个「准确率 72%」。这个数字唯一的用途是汇报，它无法指导任何一次优化——因为它不告诉你那 28% 错在哪个环节。
RAG 是一条串联的流水线，端到端失败可能来自任何一段。而不同环节的修复手段完全没有交集：检索没召回，调 prompt 无用；模型误读材料，换 embedding 模型无用。把这些混在一个分数里，等于把发动机、变速箱和轮胎的故障合并成一个「车不太好开」的指标。
这一层不需要发明新东西，信息检索领域已经把指标打磨了几十年。关键是选对：
| 指标 | 衡量什么 | 什么时候用它 |
|---|---|---|
| Recall@k | 前 k 个结果中是否包含正确材料 | RAG 最重要的检索指标。因为召回不到就彻底没救了，而排序问题还能靠 rerank 补 |
| MRR 平均倒数排名 | 正确材料排在第几位 | 关心「是否排在最前面」时；对只送 top-3 的系统尤其重要 |
| nDCG@k | 考虑多档相关性的排序质量 | 有多个不同相关程度的正确材料时 |
| Precision@k | 前 k 个里有多少是相关的 | 关心噪声——无关材料会挤占上下文并干扰生成 |
实践建议：主看 Recall@k，辅看 MRR。先用 Recall@20 确认「材料到底进没进候选池」，再用 MRR 或 Recall@3 确认「重排后有没有排到能被送进 prompt 的位置」。这两个数一起看，能立刻区分是召回问题还是排序问题——而这两者的修法完全不同。
生成层最重要的指标不是「答得对不对」，而是 groundedness（也称 faithfulness，忠实度）：回答中的每一个事实性陈述，是否都能在召回的材料里找到依据？
为什么它比「正确性」更重要？因为它是可自动化、可归因的。正确性需要标准答案，且答对了也可能是模型碰巧知道（而非用了材料）；忠实度只需要对比回答与材料，可以用模型自动判定，且它直接测量了 RAG 系统是否真的在按 RAG 的方式工作。
配合两个辅助指标：answer relevance（回答是否切题——防止模型输出一堆忠实但答非所问的内容）和拒答率（材料不足时是否老实说「资料中未提及」，见 6.3）。
一个反直觉但重要的原则：不要用生成质量去反推检索质量。「答案对了所以检索是好的」这个推论不成立——模型可能靠参数化知识蒙对了，此时检索其实失效了，而你的指标看不见。同理，「答案错了所以检索差」也不成立。两层必须各自独立测量，用各自的标注。
上面所有指标都需要一个标注好的评估集。它的构建质量决定了评估的价值，而这里有三条经验：
① 从真实失败案例开始，而不是从想象的问题开始。最有价值的评估集来自线上：用户重问的、点踩的、转人工的。这些是系统真实的弱点分布。凭空编写的问题往往集中在系统本来就擅长的区域。
② 规模不必大，覆盖必须全。100 条精心挑选、覆盖各类查询形态（精确查找、模糊语义、多跳、否定、超纲）的样本，价值远高于 1000 条同质化样本。关键是每一类失败模式至少有几条代表。
③ 检索标注是逐 chunk 的，不是逐问题的。标注要记录「哪些 chunk 是这个问题的正确材料」，才能算 Recall。这一步是体力活，但没有它检索层就无法量化——这也是绝大多数团队卡住的地方，值得咬牙做掉。可以先用模型辅助标注、人工复核来降低成本。
背景：内部知识库问答，人工抽样评估显示答案准确率约 65%，团队定下「提到 85%」的目标。
第一轮（两周）：判断是检索不准，换用榜单排名更高的 embedding 模型并重建索引。上线后人工评估——准确率约 66%。在误差范围内，等于没变。
第二轮（一周）：怀疑是模型太弱，换成更大的生成模型。准确率约 68%。有一点提升，但成本涨了数倍，且离目标依然很远。
转折：一位工程师停下来做了件本该最先做的事——拿 50 个失败案例，把每个案例召回的 chunk 原文打印出来，逐条人工标注「正确材料在不在里面」。半天的工作量，结果让所有人意外：
真正的瓶颈是排序，不是召回，更不是生成。换 embedding 模型改善的是召回，而召回本来就有 90%——难怪没有效果。换更大的生成模型是在给一个拿不到材料的模型加算力，同样无效。两轮优化都作用在了没有问题的环节上。
修复：加一个 rerank 阶段，召回 20 条后重排取前 3。这个改动的工作量约一天，Recall@3 从约 55% 提升到接近 Recall@20 的水平，端到端准确率随之显著改善。此外把 top-k 从 3 调到 5 也带来了额外收益——代价是每次调用多花一些 token。
三条教训：
① 三周的返工，本可以用半天的分层标注避免。分层评估的成本远低于盲目优化的成本。
② 「换个更强的组件」是最容易想到、也最容易白费的动作——它假设你已经知道瓶颈在哪，而这个假设通常没被验证过。
③ Recall@10 与 Recall@3 之间的落差是一个极有信息量的信号：两者差距大 = 排序问题（上 rerank）；两者都低 = 召回问题（改切分、加 BM25）；两者都高但答错 = 生成问题。这三个数是排查 RAG 的第一现场。
RAG 专用评估库：RAGAS、TruLens、DeepEval 等提供了 groundedness / answer relevance / context precision 等开箱即用的指标实现，多数基于 LLM-as-judge。用它们之前必须先校准——拿几十条人工标注过的样本，检查工具的判定与人工判定的一致率。一致率低于八成的指标不值得信任（LLM 评委的问题详见 6.4）。
检索指标：不需要专用工具，Recall@k、MRR 都是几行代码的事。真正的成本在标注，不在计算。
降低标注成本的实操路径：① 用模型为每个 chunk 生成「这段能回答什么问题」，反向构造问题-材料对，人工快速复核；② 把线上用户点击/采纳的引用作为弱标注信号；③ 只精标失败案例，成功案例抽样标。不要等「完美的评估集」——先有 50 条能用的，比三个月后有 500 条完美的更有价值。
接入 CI：把 golden set 跑成一个可重复的脚本，每次改动切分策略、embedding 模型、prompt、top-k 都跑一遍并记录全部分层指标。RAG 系统的改动极易「修好一处、弄坏两处」，没有回归测试根本发现不了。
务必分桶看指标：按查询类型（事实查找 / 汇总 / 多跳）分开统计。整体指标会把某一类的崩塌平均掉——常见情形是事实查找 95%、多跳查询 30%，平均下来是「还不错的 70%」。
A · 召回问题。正确材料压根没进候选池，后面所有环节都无力回天。排查顺序：① 先看切分——把失败案例的正确材料找出来，检查它是否被切碎了（3.2）；② 加 BM25 混合检索——若失败查询含标识符、专有名词或否定，这是稠密检索的系统性盲区（3.3）；③ 确认 embedding 模型的最大输入长度 ≥ chunk 大小（超出会被静默截断）；④ 最后才考虑换 embedding 模型。
B · 排序问题。材料在候选池里，但排不进能被送进 prompt 的位置。这是投入产出比最高的一类问题：加 rerank 阶段（召回 20 重排取 3），通常能把 Recall@3 拉到接近 Recall@20 的水平。同时可以试着把 top-k 从 3 调到 5——但注意 3.4 的提醒，召回太多反而会把关键材料挤到上下文中间。
C · 生成问题。材料到位了，模型却没忠实使用。排查：① prompt 是否明确要求「仅依据给定材料回答，材料未提及则说明」；② 上下文是否太长、关键材料是否落在中间位置；③ 材料之间是否存在矛盾（模型面对冲突材料时容易自由发挥）；④ 是否需要要求模型输出引用编号——强制引用会显著提升忠实度，也让问题可自动检测。
通用心法：这三个数（Recall@20 / Recall@3 / groundedness）是 RAG 的「三视图」，任何优化前先看它们，能省掉大量无效工作。
① 可自动化。忠实度只需比对回答与召回材料，不需要标准答案，可以用模型自动判定并规模化运行。正确率需要为每个问题准备标准答案，成本高且难以覆盖开放式问题。
② 可归因。忠实度直接衡量「模型有没有按 RAG 的方式工作」。它低，就是生成环节的问题，指向明确。正确率低则可能来自六个环节中的任何一个。
③ 它能识破「蒙对」。模型可能靠参数化知识答对而完全没用材料——正确率看起来很好，但系统实际上并没有在做 RAG，一旦遇到模型不知道的私有知识就会崩。忠实度能暴露这种虚假的健康。
④ 它对应真实的业务风险。企业场景中「答案有据可查」往往比「答案恰好正确」更重要——尤其在法律、医疗、金融领域，不可溯源的正确答案同样不可用。
但不能只看它：一个只会回答「材料中未提及」的系统，忠实度 100%，却毫无用处。必须配合 answer relevance 和拒答率一起看——三者构成一组相互制衡的指标。
问题一：不分层，不可行动。「好/中/差」是端到端评分，无法定位环节。这是最根本的缺陷——指标掉了也不知道该改什么。改进：至少拆成 Recall@k 与 groundedness 两层。
问题二：随机抽样浪费了标注预算。线上大部分请求是系统本来就做得好的简单查询，随机抽 100 条可能有 80 条毫无信息量。改进：分层抽样——按查询类型分桶，并加权抽取失败信号强的样本（用户重问、点踩、转人工）。
问题三：每周换样本，不可比。这周 72% 和上周 68% 的差异，可能完全来自样本难度差异而非系统变化。改进：建立固定的 golden set 用于版本间对比（回归），另用滚动抽样监控线上分布漂移。两个用途需要两套数据，不能混用。
问题四：无标注一致性校验。两位工程师对「中」的理解可能差异很大。改进：写明评分标准，定期做一致性检查（同一批样本双盲标注比对）。
问题五：只在事后评估，不进 CI。每周一次意味着一个退化最多可能上线七天。改进：把 golden set 做成自动化脚本接入发布流程，任何影响 RAG 的改动都必须跑一遍并比对分层指标。
问题六：没有区分「评估」与「监控」。golden set 回答「这次改动好不好」，线上指标回答「现在是不是正常」。两者的数据来源、频率、告警方式都不同（见 6.4）。