9.5 错误分型与归因

先给结论：RAG 系统一旦进入真实使用场景，“答得不好”这个结论几乎没有行动价值。只有把错误拆成具体类型，并归到明确链路环节，你才知道下一步该改数据、改检索、改上下文构造，还是改生成策略。

前面几节已经分别讲了：

• 为什么不能只看最终回答
• 检索层应该怎么评
• 生成层和忠实性应该怎么评
• 评测集为什么必须有结构

而这一节要做的事，是把这些判断真正收束成一套归因视角。因为真实系统里最常见的问题，不是没有指标，而是：

• 有很多现象，但不知道怎么归类
• 看见错误案例，但不知道根因在哪
• 知道效果差，却不知道该先改哪一层

学这一节时，最值得先建立的判断

• 一个错误案例，往往只是表面现象，根因可能在更前面的链路
• “没答对”不等于“模型差”，也不等于“检索差”
• 没有错误分桶，就很容易陷入随机试参和反复返工
• 归因的目标不是给错误起名字，而是让下一步动作更明确

这一节会回答什么问题

• 一个 RAG 错误，怎么判断到底是“没召回到”还是“召回到了没用好”？
• RAG 常见错误类型有哪些？
• 如何建立问题分类和误差归因机制？
• 为什么 RAG 调优必须建立错误分桶，而不能靠随机试参？

读完这一节后，你最好能更稳地判断：

• 一个失败案例应该先从哪一层开始排查
• 哪些错误应该归到数据、检索、重排、上下文构造或生成
• 为什么没有错误分桶时，调优动作很容易又慢又乱