Skip to content

9.1.2 RAG 评测为什么通常分检索层、生成层、端到端层? ​

先给结论:因为这三层分别在回答不同问题。检索层评测回答“证据找没找对”,生成层评测回答“证据用没用对”,端到端评测回答“用户最终看到的答案好不好”。少看哪一层,都会让评测失真。

很多人第一次接触 RAG 评测时,会问:

  • 为什么要搞这么多层

原因并不复杂,因为 RAG 本来就不是一个单一动作,而是至少包含:

  • 召回证据
  • 组织证据
  • 基于证据生成答案

既然链路本身分层,评测自然也要跟着分层。

一、检索层评测在看什么 ​

检索层主要回答的是:

  • 系统有没有把真正关键的证据找回来

它更关注的问题通常是:

  • recall 是否足够
  • precision 是否合理
  • 正确块是否出现在前 K 个候选里
  • filtering / routing 有没有把证据挡掉

这一层的意义在于:

  • 如果证据根本没进候选池,后面做得再好也救不回来

所以检索层评测是在看:

  • 系统有没有先把“料”备齐

二、生成层评测在看什么 ​

生成层主要回答的是:

  • 模型有没有正确使用这些证据

它更关注的问题通常是:

  • 回答是否忠实于材料
  • 有没有把材料外推测说成事实
  • 有没有答非所问
  • 有没有忽略限制条件

这一层很重要,因为:

  • 证据找回来,不等于就一定会被正确使用

所以生成层评测是在看:

  • 系统有没有把“料”用对

三、端到端评测在看什么 ​

端到端评测主要回答的是:

  • 用户最终拿到的回答值不值得用

它更偏整体体验视角,比如:

  • 最终答案是否正确
  • 是否完整
  • 是否满足任务目标
  • 用户是否能接受

这层评测不能少,因为线上系统真正交付给用户的是:

  • 最后那条答案

所以端到端评测是在看:

  • 整个链路最终交付效果如何

四、为什么三层必须一起看 ​

因为它们解决的问题不同,彼此不能替代。

只看端到端,不看分层 ​

你只能知道:

  • 系统整体好不好

但你不知道:

  • 为什么好
  • 为什么不好

只看检索,不看生成 ​

你可能会误以为:

  • 证据都找到了,系统就没问题了

但真实情况是:

  • 模型仍然可能误读、漏用、乱答

只看生成,不看检索 ​

你可能会把很多“没证据”的问题误判成:

  • Prompt 没写好
  • 模型没理解好

所以更稳的做法一定是组合看:

  • 检索层看证据是否进来
  • 生成层看证据是否被正确使用
  • 端到端层看最终体验是否过关

一个最小示意 ​

python
retrieval_score = eval_retrieval(query, retrieved_docs)
generation_score = eval_generation(answer, supporting_context)
e2e_score = eval_end_to_end(answer, gold_answer)

这段代码想说明的是:

  • 一个完整的 RAG 评测,不该只剩一个总分

一个常见误区 ​

很多人会把这三层理解成:

  • 只是评测指标换了名字

这不准确。它们真正不同的地方不只是指标名称,而是:

  • 看的问题不同
  • 服务的优化动作不同

所以这不是重复劳动,而是对同一条链路从不同层次做诊断。

一句话总结 ​

RAG 评测通常分检索层、生成层、端到端层,是因为这三层分别在回答“证据找没找对”“证据用没用对”“最终答案好不好”。只有把这三层结合起来,评测结果才既能反映用户体验,也能支持工程定位。