跳转至

如何分层评估 RAG 的检索、生成与端到端效果？

  • ID：Q026
  • 难度：进阶 / 系统设计
  • 标签：RAG Evaluation、Recall、NDCG、Faithfulness、Golden Set、Online Eval

同义问法

  • RAGAS、DeepEval、TruLens 解决什么？
  • Faithfulness、Answer Relevance、Context Relevance 有什么区别？
  • 检索指标很好但答案仍然错，为什么？
  • 没有标准答案时怎么评测 RAG？
  • RAG 的线上指标怎么设计？

来源

  • 用户提供的二手题库：3.14、3.15、9.4

可视化图解

flowchart TD
  Q[评测问题集] --> I[检索评估]
  I --> M1[Recall@K MRR nDCG]
  Q --> G[生成评估]
  G --> M2[Faithfulness 完整性 引用准确]
  I --> E[端到端评估]
  G --> E
  E --> M3[任务成功率 延迟 成本]
  M1 --> R[回归门禁]
  M2 --> R
  M3 --> R

核心结论

RAG 必须分层评估，因为“最终答案错”可能来自数据、解析、召回、排序、上下文构造或生成中的任意一层。 只用一个 LLM Judge 给最终回答打分，无法定位根因，也无法指导工程修复。

一、先定义评测对象

一条完整链路可以拆成：

对应流程使用 Mermaid 图解展示。

每层都要有独立输入、输出和指标，并保存 Trace。否则调参后即使总分变化，也不知道收益来自哪里。

二、检索层评估

需要标注每个 Query 的相关文档或支持答案所需的证据集合。

Hit@K

Top-K 中是否至少出现一个相关结果。适合单证据问答，但无法衡量多证据是否完整。

Recall@K

所有相关证据中召回了多少。多跳问题尤其重要。

Precision@K

Top-K 中相关结果的比例，用于观察噪音。

MRR

关注第一个相关结果的位置，适合希望首条就命中的场景。

NDCG

考虑多级相关性和排名折损，适合一个 Query 有“直接证据、背景材料、弱相关材料”等不同等级。

Context Sufficiency

即使文档被标为相关，也要判断当前召回片段是否足以回答。例如命中了财报文档，但只召回标题，没有数字所在表格，仍然不充分。

三、上下文层评估

Context Builder 需要单独检查：

  • 证据覆盖率；
  • 无关内容比例；
  • 重复 Chunk 比例；
  • Token 占用；
  • 来源和版本是否正确；
  • 权限过滤是否正确；
  • 多个证据之间是否存在冲突。

检索命中不等于最终上下文命中，因为结果还可能被重排、裁剪或预算策略丢弃。

四、生成层评估

Faithfulness / Groundedness

回答中的可验证断言是否被提供的上下文支持。它回答的是“有没有脱离证据编造”。

Answer Relevance

是否直接回应用户问题，避免答非所问或大量无关扩展。

Correctness

与标准答案或事实真值是否一致。一个回答可能忠实于错误文档，却仍然不正确，所以 Faithfulness 不等于 Correctness。

Completeness

是否覆盖完成任务所需的关键点。

Citation Correctness

引用是否真实存在、是否指向正确版本、是否真正支撑相邻结论。

五、Agentic RAG 还要评轨迹

若系统会多轮搜索，需要增加：

  • 查询改写保持率；
  • 路由准确率；
  • 无效检索次数；
  • 停止是否合理；
  • 总工具调用数；
  • 证据收敛速度；
  • 是否重复搜索相同内容。

只评最终文本会掩盖一个“偶然答对但过程浪费且危险”的 Agent。

六、评测集如何构建

Golden Set 不应只包含简单 FAQ。至少分桶：

  • 事实定位；
  • 多跳综合；
  • 专有名词和错误码；
  • 否定条件；
  • 时间版本；
  • 文档冲突；
  • 无答案、应拒答；
  • 权限隔离；
  • 表格、图片、代码和复杂 PDF；
  • 历史 Badcase。

每条样本保存：Query、相关证据、标准答案或关键事实点、允许的答案变体、拒答预期和风险等级。

七、LLM-as-Judge 如何可靠使用

LLM Judge 适合规模化评估语义质量，但不能作为唯一真值。

降低偏差的方法：

  • 使用清晰 Rubric，不要求一个模糊总分；
  • 把答案拆成原子断言；
  • Judge 只看需要判断的证据；
  • 对顺序、长度和模型自偏好做校准；
  • 用人工标注集测 Judge 与人的一致性；
  • 高风险样本人工复核；
  • 模型或 Prompt 变化时版本化 Judge。

八、线上评估

线上指标分三类：

质量信号

点赞、点踩、复制、追问、转人工和人工 Review，但这些都是带噪信号，不能直接等同于答案正确性。

业务指标

一次解决率、任务完成率、平均处理时长、工单减少量和人工接管率。

系统指标

P50/P95/P99 延迟、检索与重排耗时、错误率、Token、每请求成本和索引新鲜度。

上线采用离线回归 + 小流量灰度 + 在线 A/B。平均分提高不能掩盖红线样本退化，因此高风险用例必须设硬门槛。

九、根因定位矩阵

常见错误回答

用 RAGAS 跑一个分数就可以。

框架只能自动化指标，不能替你定义业务真值、风险分桶和根因链路。

用户点踩就是 Badcase。

点踩可能来自格式、延迟、预期不符或用户误操作，需要二次归因。

面试口述版

我会把 RAG 评测拆成检索、上下文、生成和端到端四层。检索看 Recall@K、MRR、NDCG 和多证据覆盖；上下文看充分性、噪音、重复、版本与权限；生成看 Faithfulness、Correctness、Completeness 和 Citation Correctness；Agentic RAG 再评路由、改写、无效调用和停止。Golden Set 会覆盖无答案、时间冲突、权限和复杂文档，LLM Judge 用 Rubric 并通过人工集校准。线上再结合任务完成率、转人工率、延迟和成本，依靠 Trace 把错误定位到具体层，而不是只看一个总分。

结合个人项目

故障诊断 Agent 的标准答案不应只是“一段文字”，而应包含：直接根因、关键证据日志、排除过的替代原因、修复动作和置信度。这样才能分别评估证据召回、因果判断和修复建议。