9.1.1 为什么不能只看最终回答，必须拆开评测 RAG？

先给结论：因为 RAG 不是一个单点模型，而是一条由检索、筛选、上下文构造和生成组成的链路。只看最终回答，相当于只看链路末端结果，却看不到中间每一层到底有没有正常工作。

这就像你在看一个复杂系统时，只记录：

• 最后成功还是失败

这种信息当然有用，但它远远不够用来定位问题。

一、最终回答只反映“总结果”，不反映“过程质量”

当一个 RAG 回答错误时，表面现象只有一个：

• 最终答案不对

但这个“不对”背后可能有很多完全不同的原因：

• 正确证据没召回
• 候选里有正确证据，但没排上来
• 上下文组织得太乱
• Prompt 没把约束说清楚
• 模型生成时误读了证据

如果你只看最终答案，就会把这些完全不同的问题都压缩成同一个信号。

这会让后面的优化变得非常盲。

二、同样一个错误，修法可能完全相反

这是只看最终回答最危险的地方。

比如两个系统都答错了：

• 系统 A 是因为关键证据没召回
• 系统 B 是因为关键证据已经进了上下文，但生成时误用了

它们在“最终结果”上看起来一样，但真正该做的优化却完全不同：

• A 更该调检索、chunk、metadata
• B 更该看上下文构造、Prompt、生成控制

如果没有拆层评测，你很可能会：

• 对着生成问题调检索
• 对着检索问题调 Prompt

这就是为什么很多团队花了很多精力，却感觉系统始终提不上去。

三、RAG 评测的目标不只是“判分”，更是“支持定位”

很多人把评测理解成：

• 给系统一个分数

但对工程系统来说，更有价值的问题通常是：

• 这个分数为什么会这样
• 哪一层是主要瓶颈
• 哪种错误最常发生

所以真正可用的 RAG 评测，不只是一个最终结果，而是一套能支持排查的观察框架。

四、端到端结果为什么仍然重要

这里也不能走到另一个极端。

拆层评测很重要，但不代表端到端结果不重要。端到端评测仍然回答一个核心问题：

• 用户最终看到的回答好不好

所以更稳的做法不是二选一，而是：

• 端到端结果看总体体验
• 分层评测看问题归因

一个最小示意

if final_answer_is_wrong():
    check_retrieval_layer()
    check_context_construction()
    check_generation_layer()

这段代码想说明的是：

• 最终回答只是起点，不是定位终点

一个常见误区

很多人会觉得：

• 只要最终答案对，过程就不重要

这在小规模 Demo 里也许还能勉强接受，但在线上系统里不稳。因为一个系统偶尔答对，不代表：

• 它的链路足够稳
• 它的错误来源已经清楚
• 它的优化方向已经明确

工程上真正要的，不只是“这次答对了”，而是：

• 为什么能答对
• 下次为什么还能答对

一句话总结

不能只看最终回答评测 RAG，因为最终回答只能告诉你结果现象，不能告诉你问题出在哪一层。RAG 是链路系统，评测也必须服务链路定位，否则后面的调优很容易失焦。