一文带你搞懂分层评估

分层评估的思路

RAG 系统是一个多环节的流水线，如果只看最终结果——用户的问题有没有被正确回答——你知道答错了，但不知道错在哪个环节。

打个比方，就像工厂的质检。一个产品从流水线下来不合格，你不能只说产品坏了就完事了。你得搞清楚是原材料有问题（检索到的 chunk 不对），还是加工工序出了问题（模型基于正确的 chunk 生成了错误的答案），还是设计本身就有缺陷（知识库里根本没有这个信息）。

RAG 系统的评估也一样，要分层：

三层评估的核心逻辑：

• 检索阶段：召回的 chunk 对不对？正确答案有没有在召回的 Top-K 里？排在第几位？——这层出了问题，后面全白搭，模型再厉害也没法基于错误的 chunk 生成正确的答案。
• 生成阶段：给了正确的 chunk，模型有没有忠实地基于 chunk 内容回答？有没有编出 chunk 里没有的信息（幻觉）？有没有答非所问？——这层出了问题，说明 Prompt 或模型需要调整。
• 端到端：不管中间过程，最终答案正确吗？用户满意吗？——这是最终的结果指标，但光看这个定位不了具体问题。

分层评估的好处是定位精准：检索指标好但生成指标差，说明问题在 Prompt 或模型上；检索指标差，那就先去优化检索环节，调 Prompt 没有用。

检索阶段的评估指标

检索阶段是 RAG 系统的基础，chunk 都没召回来，后面的生成再好也是空中楼阁。检索阶段的评估核心问题就一个：Top-K 个召回的 chunk 里，有没有包含正确答案对应的 chunk？

围绕这个问题，有四个常用指标。

命中率（Hit Rate）

最简单的指标：Top-K 个召回的 chunk 里，有没有包含正确答案？有就是 1，没有就是 0。多个问题取平均值。

用电商客服的例子来算。假设评测集有 5 个问题，每个问题的 Top-3 召回结果：

Hit Rate = 命中次数 / 总问题数 = 4 / 5 = 0.8（80%）

命中率很好理解，但它有一个明显的缺点——不关心正确答案排在第几位。chunk_12 排在第 1 位和排在第 3 位，命中率上没有区别，都算命中。但实际使用中，排在第 1 位和排在第 3 位的差别很大——排在第 1 位意味着检索系统很自信地找到了正确答案，排在第 3 位可能只是凑巧混进来了。

MRR（Mean Reciprocal Rank，平均倒数排名）

MRR 在命中率的基础上，还关心正确答案排在第几位。

计算规则：如果正确答案排在第 1 位，得 1 分；排在第 2 位，得 1/2 = 0.5 分；排在第 3 位，得 1/3 ≈ 0.33 分……排在第 K 位，得 1/K 分。如果 Top-K 里没有正确答案，得 0 分。多个问题取平均。

还是用刚才的 5 个问题，这次多关注一下正确答案的排名位置：

MRR = (1.0 + 1.0 + 0 + 0.5 + 1.0) / 5 = 3.5 / 5 = 0.7

MRR 比 Hit Rate 更能反映检索质量。两个系统 Hit Rate 都是 80%，但一个系统的正确答案大部分排在第 1 位（MRR 接近 0.8），另一个系统的正确答案大部分排在第 3 位（MRR 可能只有 0.4）——后者的检索质量明显不如前者，因为排在第 3 位的 chunk 在实际使用中更容易被忽略或被不相关的 chunk 干扰模型生成。

MRR 的直觉理解：MRR = 0.7 意味着平均来看，正确答案大约排在第 1.4 位（1 / 0.7 ≈ 1.43）。MRR 越接近 1，说明正确答案越稳定地排在第 1 位。

召回率与精确率（Recall & Precision）

命中率和 MRR 都是围绕一个正确答案来评估的。但现实中，一个问题的完整答案往往分散在多个 chunk 里。

比如用户问退货政策是什么，完整答案涉及三个 chunk：

• chunk_12：退货条件（7 天内、未拆封）
• chunk_13：退货流程（申请 → 审核 → 寄回 → 退款）
• chunk_14：退货运费（质量问题免运费，其他自付）

只命中其中一个，用户拿到的答案就是残缺的。这时候就需要召回率和精确率来衡量找全了没有和找准了没有。

继续用这个例子。系统 Top-5 召回了这些 chunk：

召回率（Recall）：该找的 chunk，找到了几个？分母是应该找到的总数，分子是实际命中的个数。

$$Recall = \frac{命中的相关\ chunk\ 数}{标注的相关\ chunk\ 总数} = \frac{2}{3} = 66.7%$$

3 个相关 chunk 里命中了 2 个（chunk_12 和 chunk_13），漏掉了 chunk_14（退货运费）。用户问退货政策，结果运费相关的信息丢了。

精确率（Precision）：找回来的 chunk 里，有几个是真正有用的？分母是召回的总数，分子是其中相关的个数。

$$Precision = \frac{命中的相关\ chunk\ 数}{召回的\ chunk\ 总数} = \frac{2}{5} = 40%$$

召回了 5 个 chunk，但只有 2 个是相关的，另外 3 个（会员等级、促销活动、配送时效）都是噪音。这些不相关的 chunk 会干扰模型生成，还浪费 Token。

这两个指标往往是跷跷板关系：

• 召回率高但精确率低——Top-K 设得很大，找了一大堆回来，正确 chunk 确实都包含了，但噪音也很多。多余的 chunk 会干扰模型生成，增加 Token 消耗。
• 精确率高但召回率低——Top-K 设得很小，找回来的每个 chunk 都很相关，但遗漏了部分正确 chunk。答案可能不完整。

RAG 场景通常更关注召回率——宁可多召回几个不太相关的 chunk（后面可以用 Reranker 过滤掉噪音），也不要漏掉正确答案。因为漏掉了就彻底没了，模型不可能基于没看到的信息回答正确。

检索指标对比

生成阶段的评估指标

检索阶段找到了正确的 chunk，但模型有没有好好利用这些 chunk 来回答？这是生成阶段评估要回答的问题。

忠实度（Faithfulness）

忠实度衡量的是：模型生成的答案是否忠实于检索到的 chunk 内容，有没有编出 chunk 里没有的信息？

答案相关性（Answer Relevancy）

答案相关性衡量的是：模型生成的答案是否回答了用户的问题？有没有答非所问？

几个例子：

生成指标对比

端到端的评估指标

检索指标和生成指标分别看各自环节的效果，端到端指标则直接看最终结果——用户的问题有没有被正确回答。

答案正确率

最直接的端到端指标：最终答案是否正确回答了用户的问题？

这个指标需要有标准答案作为对照。评判正确本身有一定主观性——模型回答的措辞跟标准答案不一样，但意思一样，算不算正确？通常采用语义匹配而不是字面匹配，让人工或 LLM 来判断模型答案的含义是否与标准答案一致。

兜底率

系统回答“抱歉，找不到相关信息”的比例。在生成策略那篇里设计过兜底回答——当检索不到相关 chunk 或者模型判断无法回答时，返回兜底回复。

兜底率太高说明知识库覆盖不够，或检索效果差，大量问题找不到答案；太低也不正常，可能模型在强行回答不该回答的问题，编造答案。

参考范围：5%~15% 是比较合理的区间。低于 5% 要警惕是不是模型在硬答，高于 15% 要检查知识库覆盖度和检索配置。但这个范围跟业务场景强相关——如果你的知识库就是很垂直很小，只覆盖退货退款相关问题，那非退货问题触发兜底是完全正常的，兜底率高不代表系统差。反过来，如果你的知识库覆盖了所有业务场景，兜底率超过 15% 就要认真排查了。

用户满意度

最终的北极星指标。前面所有指标都是技术指标，用户满意度才是业务指标。

可以通过两种方式收集：

• 显式反馈：在回答后面加点赞或点踩按钮，让用户主动评价。简单直接，但参与率低——大部分用户不会主动反馈，反馈的往往是特别满意或特别不满意的，有偏差。
• 隐式反馈：通过用户行为推断满意度。比如用户在得到回答后没有追问（可能满意了），或者用户重复问了同一个问题（说明对上次回答不满意），或者用户在对话后转了人工客服（说明 RAG 没解决问题）。

三种标注方式

评测数据集从哪里来？三种方式各有优劣。

2.1 人工标注

让业务专家或客服人员标注：这个问题应该用哪几个 chunk 回答，标准答案是什么。

具体操作：给标注人员一份知识库 chunk 列表和一组问题，让他们标注每个问题对应的 chunk ID 和标准答案。

这是最准确的方式，标注出来的数据质量最高。缺点是成本高、速度慢。标注一条数据大概需要 5~10 分钟（需要在 chunk 列表里找对应的 chunk，还要写标准答案），50 条就是一两天的工作量。

标注时要注意一致性：如果多个人标注同一个问题，标准答案可能不一样。比如退货政策有人写得详细、有人写得简洁。需要提前约定标注规范，答案粒度保持一致。不一致的要讨论对齐。

2.2 用户反馈收集

从线上真实对话中收集评测数据：

• 用户点赞的对话 → 说明回答正确 → 可以作为正向评测数据（问题 + 模型回答作为标准答案）
• 用户点踩或转人工的对话 → 说明回答不好 → 可以用来分析 bad case，但不能直接作为评测数据（因为你不知道标准答案应该是什么，需要人工补标）

优点是数据最真实，来自真实用户的真实问题。缺点是用户反馈有偏差——满意的用户很少会主动点赞，不满意的用户有时候也懒得点踩。能收集到的数据量通常不多。

2.3 大模型辅助生成

用大模型根据知识库文档自动生成 QA 对。做法是：给模型一段 chunk 内容，让它根据 chunk 生成 2~3 个可能的用户问题和对应的标准答案。

比如给模型这段 chunk：

评估驱动的优化

评估报告出来之后，不是看看就完了。评估的价值在于指导优化——根据指标表现定位问题环节，针对性地改进。

根据评估结果定位问题

用一张决策表来理清哪个指标差、问题在哪、该怎么优化的逻辑：

拿前面的评估报告举例：

• Hit Rate 80%，低于 85% → 检索阶段有问题，退货运费谁承担没有命中正确 chunk。分析原因：可能是退货运费和 chunk_13 的文本退货运费由买家承担语义匹配度不够，或者 Top-3 太少了。优化思路：把 Top-K 从 3 调到 5，或者加入重排序。
• 忠实度 3.33，整体偏低，退货运费忠实度 1 分、跨境商品退货和 Apple Watch 防水各 3 分 → 生成阶段的 Prompt 需要加强限定。优化思路：在 System Prompt 里加一条严禁添加参考文档中未出现的信息，对未检索到内容的场景强化兜底指令。

优化后的验证

每次优化之后，重新跑一遍评测集，对比优化前后的指标变化。这里有一个关键原则：不要只看改善的指标，还要检查有没有其他指标变差。

比如你把 Top-K 从 3 调到 5，Hit Rate 从 80% 提升到了 90%，看起来不错。但要同时检查：

• 忠实度有没有下降？多召回了 2 个 chunk，如果多出来的 chunk 质量不高，可能干扰模型生成，导致幻觉增加。
• 兜底率有没有变化？多召回可能让一些原本触发兜底的问题强行找到了不太相关的 chunk，模型基于不相关 chunk 编了个答案，兜底率下降了但正确率也下降了。

用表格记录每次优化的效果对比（预设结果）：

从这个表可以看到：单纯增加 Top-K 虽然 Hit Rate 提升了，但 MRR 下降（正确 chunk 排名变差了）、忠实度也下降了（多出来的不相关 chunk 干扰了生成）。加上 Reranker 之后，各项指标才全面改善——Reranker 本身改善的是检索排序，但排序变好意味着高相关的 chunk 排到前面、噪音 chunk 被过滤掉，模型看到的上下文质量更高，忠实度自然也跟着提升。这就是评估的价值——没有数据，你可能以为调 Top-K 就够了，实际上还需要配合 Reranker 才行。

小结

这篇讲了 RAG 系统的评估与优化，核心要点：

1. 靠感觉优化是不行的——没有评估体系，改了东西不知道效果变好还是变差，更发现不了回归问题。量化评估是系统化优化的前提
2. 分层评估定位问题——不是只看答案对不对，而是分三层：检索阶段（chunk 找对了吗）、生成阶段（答案忠实吗）、端到端（用户满意吗）。哪层指标差，就优化哪层
3. 检索指标：Hit Rate（命中了没有）和 MRR（排在第几位）最常用；Recall 和 Precision 适合需要多 chunk 回答的场景
4. 生成指标：忠实度（有没有编造）和答案相关性（有没有答非所问）是核心。其中幻觉率（忠实度 ≤ 2 分的占比）是系统级红线指标，RAG 的核心价值就是基于检索回答，幻觉率居高不下就失去了意义
5. 评测数据集是基础：50~100 条起步，覆盖不同类型和难度，大模型辅助生成 + 人工校验是性价比最高的方式
6. LLM-as-Judge 实现自动化：用大模型做评委，设计好评分 Prompt，JSON 格式输出方便程序解析。定期用人工校准一致性
7. 评估驱动优化：根据指标定位问题环节，针对性改进，改完重新评测，确认改善且无回归

到这里，整个 RAG 系列从概念到实现、从各环节到评估，一条完整的链路已经讲完了：

数据入库 → 分块 → 元数据 → 向量化 → 向量数据库 → 检索策略 → 生成策略 → Function Call → MCP 协议 → 会话记忆 → Query 改写 → 意图识别与路由 → 评估与优化