RAG 怎么评测？从检索命中到答案可信度的完整方法

RAG 系统回答错了，原因可能完全不同：没有找对资料、找到了但片段不完整、模型误读了证据，或者回答看似合理却越过了资料范围。只看最终“答得像不像”无法解决问题，必须把评测拆开。

RAG 评测的三层

1. 检索评测：资料有没有找对

给定一个问题，检查正确答案所在的文档或片段是否进入了候选结果。常见观察项包括：

• 命中率：正确片段是否出现在前 K 条结果中
• 排序质量：正确片段排得是否足够靠前
• 覆盖度：回答需要多个事实时，是否都检索到了

如果正确资料根本没进上下文，后面的模型再强也很难答对。此时应检查切分方式、Embedding、查询改写和过滤条件，而不是只改提示词。

2. 生成评测：有没有忠于证据

资料找对后，模型仍可能遗漏限定条件、拼错数字或补充资料里没有的内容。生成层应检查：

• 回答是否能被引用片段支撑
• 是否回答了用户真正的问题
• 是否明确说明资料缺失或不确定性
• 格式、语气和长度是否符合产品要求

这一步的核心不是文笔，而是“有据可查”。

3. 端到端评测：用户任务完成了吗

用户不在乎你在哪一层得分高，只在乎问题是否解决。端到端测试把检索、生成、权限、延迟与前端体验放在一起，检查最终任务是否可用。

测试集怎么准备

从真实用户问题中抽样，脱敏后标注标准答案、支持它的资料片段和不可接受的回答。测试集至少应包含：

• 普通事实问答
• 多文档综合问题
• 资料中没有答案的问题
• 已过期或相互冲突的信息
• 权限不同的用户问题

“资料中没有答案”尤其重要。好的 RAG 应该会说“现有资料无法确认”，而不是为了显得有帮助而编造。

一张定位问题的表

现象	更可能的原因	优先检查
回答完全跑题	查询理解或检索失败	查询改写、过滤、Top K
答案缺一半	文档切分或覆盖不足	chunk 大小、相邻片段、重排
引用了资料仍答错	生成误读或提示词不足	引用格式、回答约束、模型
总说不知道	阈值过高或知识库不全	检索分数、资料覆盖
偶尔泄露不该看的内容	权限过滤位置错误	检索前权限控制

自动评测与人工评测如何配合

规则能检查是否有引用、是否输出指定 JSON；模型裁判能大规模评估相关性和忠实度；人工最擅长判断业务语义和高风险错误。三者应结合，而不是只相信某一个总分。

评测也要持续做。资料更新、Embedding 更换、模型升级、提示词调整都可能造成回归。将一小套高价值测试接入发布流程，效果类似传统软件的回归测试。

总结

RAG 评测的关键是分层：先确认找没找对，再确认有没有忠于资料，最后确认用户任务是否完成。准备覆盖正常、边界和“无答案”场景的测试集，并用结果反推检索、上下文与生成模块，才能把知识库问答从“偶尔很惊艳”做成稳定可信的产品。想先了解基础架构，可看什么是 RAG。