分层评估的思路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.880%命中率很好理解但它有一个明显的缺点——不关心正确答案排在第几位。chunk_12 排在第 1 位和排在第 3 位命中率上没有区别都算命中。但实际使用中排在第 1 位和排在第 3 位的差别很大——排在第 1 位意味着检索系统很自信地找到了正确答案排在第 3 位可能只是凑巧混进来了。MRRMean 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.7MRR 比 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 里。比如用户问退货政策是什么完整答案涉及三个 chunkchunk_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 调到 5Hit Rate 从 80% 提升到了 90%看起来不错。但要同时检查忠实度有没有下降多召回了 2 个 chunk如果多出来的 chunk 质量不高可能干扰模型生成导致幻觉增加。兜底率有没有变化多召回可能让一些原本触发兜底的问题强行找到了不太相关的 chunk模型基于不相关 chunk 编了个答案兜底率下降了但正确率也下降了。用表格记录每次优化的效果对比预设结果从这个表可以看到单纯增加 Top-K 虽然 Hit Rate 提升了但 MRR 下降正确 chunk 排名变差了、忠实度也下降了多出来的不相关 chunk 干扰了生成。加上 Reranker 之后各项指标才全面改善——Reranker 本身改善的是检索排序但排序变好意味着高相关的 chunk 排到前面、噪音 chunk 被过滤掉模型看到的上下文质量更高忠实度自然也跟着提升。这就是评估的价值——没有数据你可能以为调 Top-K 就够了实际上还需要配合 Reranker 才行。小结这篇讲了 RAG 系统的评估与优化核心要点靠感觉优化是不行的——没有评估体系改了东西不知道效果变好还是变差更发现不了回归问题。量化评估是系统化优化的前提分层评估定位问题——不是只看答案对不对而是分三层检索阶段chunk 找对了吗、生成阶段答案忠实吗、端到端用户满意吗。哪层指标差就优化哪层检索指标Hit Rate命中了没有和 MRR排在第几位最常用Recall 和 Precision 适合需要多 chunk 回答的场景生成指标忠实度有没有编造和答案相关性有没有答非所问是核心。其中幻觉率忠实度 ≤ 2 分的占比是系统级红线指标RAG 的核心价值就是基于检索回答幻觉率居高不下就失去了意义评测数据集是基础50~100 条起步覆盖不同类型和难度大模型辅助生成 人工校验是性价比最高的方式LLM-as-Judge 实现自动化用大模型做评委设计好评分 PromptJSON 格式输出方便程序解析。定期用人工校准一致性评估驱动优化根据指标定位问题环节针对性改进改完重新评测确认改善且无回归到这里整个 RAG 系列从概念到实现、从各环节到评估一条完整的链路已经讲完了数据入库 → 分块 → 元数据 → 向量化 → 向量数据库 → 检索策略 → 生成策略 → Function Call → MCP 协议 → 会话记忆 → Query 改写 → 意图识别与路由 → 评估与优化