RAG 效果评估

RAG 效果评估解决的是判断 RAG 是否真的在变好这个问题。它关心检索命中、引用准确性、回答忠实度和用户反馈。

在 Way To Agent 的知识体系里，这篇文章关注的是 RAG 系统如何评估检索命中、引用准确性、回答忠实度和用户反馈。

为什么不能只看最终答案

只看最终答案，会把很多问题掩盖掉。

比如：

• 答案错了，可能是没召回到正确片段
• 答案看起来对了，但引用片段其实不支撑这个结论
• 检索命中了，生成却偏离了引用

如果不把这些层次拆开，最后只会得到一句模糊判断：效果不稳定。这对系统优化几乎没有帮助。

评估要拆成哪几层

效果评估的工作方式是把检索、引用和最终答案拆开看，再分别判断它们是否在变好。

用户输入
  -> 业务上下文与权限判断
  -> 数据、检索、Prompt 或工具编排
  -> 模型调用或确定性服务执行
  -> 结构化校验、引用、日志和反馈

RAG 评估最核心的不是打一个总分，而是知道问题出在链路哪一层。

评估样本从哪里来

评估样本通常来自三类来源：

• 人工编写的标准问答集
• 真实用户问题和反馈
• 系统运行日志里反复出现的失败样本

这三类样本的作用不同：

• 标准问答集适合做回归验证
• 真实用户问题能反映开放场景
• 失败样本最适合用来做针对性修复

如果只有第一类样本，系统很容易在测试里看起来稳定，在线上却继续出问题。

哪些指标最容易误导

最容易误导人的，是把单个指标当成整体质量。

例如：

• 只看召回率，不看召回结果是否真的进入答案
• 只看最终答案，不看答案是否忠实于引用
• 只看离线样本得分，不看真实用户反馈

RAG 评估天然是多层的，任何单一指标都只能解释一部分问题。

最常见的误解

• 最终答案对了，系统就一定是健康的。
• 召回率高，说明 RAG 效果就好。
• 只要做一次离线评测，就能代表线上表现。
• 用户没投诉，就说明评估可以先不做。

怎么排查

当效果评估相关功能表现不稳定时，不要先猜模型不好。更有效的排查顺序是：

输入是否明确
上下文是否正确
权限与数据范围是否匹配
Prompt / 工具 / 检索配置是否符合预期
模型调用是否超时、限流或输出不合规
日志、引用和评估样例是否能复现问题

排查评估问题时，先把样本、指标和链路层次对应起来，比盯着总分更重要。

一句话结论

RAG 效果评估的核心不是记住一个名词，而是理解它在 AI 应用链路中的责任边界。RAG 评估要分层，否则只看最终答案会掩盖解析、检索和生成各自的问题。

上手前先画清楚

1. 把检索、引用、生成三层评估拆开。
2. 分清标准样本、真实问题、失败样本各自的用途。
3. 不要只设计总分，要设计能定位问题层次的指标。

继续阅读

04-rag/001-what-is-rag.md
04-rag/002-rag-architecture.md
04-rag/003-document-parsing.md