一、为什么不能只靠感觉评估 RAG？

很多团队刚做 RAG 时，最常见的评估方式是人工抽查几条，觉得答案还行就上线。这个方式最大的问题是：它既不稳定，也不能定位问题。今天抽的几十条样本很好，明天真实用户问的是另一批问题，系统可能马上翻车。

RAG 系统不是一个黑盒，它至少由三段组成：先理解用户问题，再从知识库里找证据，最后让大模型基于证据生成答案。只要其中一段出错，最终答案就会出错。

所以，RAG 评估的第一步，不是问“答案看着顺不顺”，而是问三个更底层的问题：资料找到了吗？找到的资料干净吗？模型有没有按资料回答？

二、一套完整的 RAG 评估闭环

成熟的 RAG 评估不能只停留在离线跑分。离线指标用于快速迭代，线上指标用于最终验收。两者之间必须形成闭环：线上发现问题，回灌到离线测评集；离线修复问题，再灰度验证线上效果。

如果没有这个闭环，离线数据会慢慢和真实用户脱节。指标看起来越来越好，但线上用户越来越不满意，这种情况在 RAG 项目里非常常见。

三、第一层：检索层评估

检索层先不要看大模型回答什么，只看检索器有没有把正确证据找出来。因为如果证据没找对，后面的大模型再强，也只能在错误上下文上发挥。

检索层最常用的是 Hit@K 和 MRR。Hit@K 看正确 chunk 有没有出现在前 K 个结果里，回答的是“找到了没有”。MRR 看正确 chunk 排在第几名，回答的是“找得靠不靠前”。

Hit@K 高，不代表排序一定好。比如正确资料每次都在第 10 名，Hit@10 可能很好，但真正送进 LLM 的前 3 个 chunk 可能全是噪音。所以，检索层不要只看一个指标，要组合看。

Python：检索层 Hit@K / MRR 计算示例

四、第二层：生成层评估

检索层通过，不代表最终答案一定好。因为大模型可能没有使用检索内容，可能把资料说错，也可能说了一堆有依据但和问题无关的话。

这时候要看生成层指标。RAGAS 这类框架的核心价值，就是把生成质量拆成几个方向：忠实度、答案相关性、上下文召回、上下文精确率。

Faithfulness（忠诚） 关注答案是否忠实于检索上下文。简单说，答案里每一句事实，都应该能在上下文中找到依据。

Answer Relevancy（答案相关性） 关注答案是否回答了用户的问题。一个答案可以完全有依据，但如果用户问的是退款条件，系统却回答了一堆公司发展史，这依然是低质量回答。

Context Recall（情境回忆） 关注检索结果是否覆盖了标准答案所需的信息。Context Precision 关注相关内容是否排在前面，以及上下文里是否混入了太多无关噪音。

Python：用 RAGAS 跑生成层评估

五、指标低了，怎么定位问题？

评估指标最大的价值，不是为了在周报里放一个漂亮数字，而是为了定位问题。不同指标低，背后的修复方向完全不同。

这里有一个非常实用的判断顺序：先看检索，再看生成。检索层没过，优先修召回和排序；检索层过了，生成层仍然差，再去看 Prompt、引用约束、答案模板和拒答策略。

六、测评集怎么建设？

没有高质量测评集，所有指标都会变成假精确。测评集不是随便找几十个问题，而是要覆盖真实业务分布、用户高频问题、长尾问题、对抗问题和高风险问题。

一条合格的 RAG 测评样本，至少要包含用户问题、标准答案、参考 chunk ID、实际召回上下文、实际回答、场景标签和风险标签。这样出了问题才能回放，才能知道到底是哪一层错了。

测试集还要持续更新。线上点踩、转人工、用户反复追问的问题，都是最好的测评样本来源。真实坏样本越多，评估越接近真实世界。

七、怎么跑实验才可信？

RAG 优化最怕“同时改很多东西”。你同时换了 Embedding 模型、调了 Chunk 大小、改了 Prompt、加了 Rerank，最后指标涨了，你也不知道到底是哪一步带来的收益。

正确做法是固定测评集和评估配置，一次只改一个变量。比如只把 TopK 从 5 调到 8，然后看 Hit@K、Context Precision、Faithfulness、延迟和成本的变化。

还要注意，指标提升不一定代表可以上线。比如 TopK 变大后 Hit@5 提升了，但 Context Precision 下降、P95 延迟上升，这说明系统召回更多内容的同时，也把更多噪音送给了大模型。

八、线上指标才是最终验收

离线指标是研发指标，线上指标才是业务验收指标。一个系统离线 Faithfulness 很高，但用户频繁追问、点踩、转人工，说明它仍然没有解决用户问题。

线上要看点踩率、追问率、转人工率、空回答率、会话解决率，同时还要看延迟和 token 成本。质量、体验、成本必须放在一起看。

线上指标不能孤立看。转人工率上升不一定是坏事，如果这是因为系统质量门控更严格，减少了错误回答，那可能是一次正确的保守策略。关键是结合点踩率、解决率和人工工单质量一起分析。

九、别让评估结果骗了你

RAG 评估很容易出现“数字好看，系统不好用”的情况。原因通常不是指标没用，而是评估设计被污染了。

对抗式审查的思路是：不要默认指标可信，要主动寻找指标可能失真的地方。比如数据集是否过于简单，Judge 是否偏爱长答案，是否只看平均分，是否漏掉了应该拒答的问题。

尤其要警惕只看平均分。一个客服 RAG 系统，普通问题答得很好，但退款、合同、合规类高风险问题答错，平均分可能依然不错，但业务风险非常大。

十、把评估接进工程流程

真正可落地的 RAG 评估，不应该只是研发同学手动跑脚本，而应该成为工程流水线的一部分。每次改检索策略、Prompt、模型、知识库，都要先跑核心测评集。

如果核心指标不过线，不能上线；如果指标过线但高风险样本失败，也不能直接上线。上线后再用灰度流量观察点踩、追问、转人工和延迟。

十一、面试时怎么回答？

如果面试官问“你怎么量化 RAG 效果”，不要只说看用户反馈，也不要只说人工抽查。可以这样回答：

这个回答的关键不是背指标名，而是体现工程判断：你知道 RAG 的错误来自不同环节，也知道用不同指标定位不同问题。

十二、总结

RAG 评估不是为了证明系统厉害，而是为了让系统持续变好。

第一，检索层先看证据有没有找对，核心指标是 Hit@K、MRR、Recall@K。

第二，生成层再看答案是否忠实、相关、完整，核心指标是 Faithfulness、Answer Relevancy、Context Recall、Context Precision。

第三，线上层看用户是否真正解决问题，核心指标是点踩率、追问率、转人工率、会话解决率、延迟和成本。

最后，一定要用真实业务数据做评估，并持续回灌线上坏样本。没有闭环的评估，只是一次性体检；有闭环的评估，才是 RAG 系统的长期免疫系统。