布吉岛 Agent

Appearance

10.4.1 为什么 RAG 调优必须建立问题分类和误差归因机制？ ​

先给结论：没有问题分类和误差归因，RAG 调优几乎一定会变成随机试参。你可能修好几道题，但很难知道该优先改哪一层、下一步该改什么。

这句话背后的核心原因是：

  • RAG 不是一个单点能力，而是一条链路

当你看到“答案不好”时，可能存在的根因非常多：

  • 数据缺失
  • 过滤出错
  • 召回偏题
  • 排序不稳
  • 上下文组织不合理
  • 生成不忠实

如果没有分类和归因机制，你只能凭感觉猜：

  • 先改哪一层

结果就是调优动作越来越多，但收益越来越难判断。

为什么“修好个案”不等于系统变好 ​

很多团队会从单个错误案例出发：

  • 这个问题答错了
  • 那就加一段 Prompt

这种做法短期内可能有效，但长期会带来两个问题：

  • 优化动作不能扩展到同类问题
  • 不同改动之间开始互相打架

只有把问题分类到一个更稳定的错误桶里，你才知道：

  • 修的是哪一类问题
  • 能不能复用到更多场景

误差归因机制的真正价值 ​

误差归因不是为了让你写更多表格，而是让你做三个关键动作：

  1. 把错误归到明确的链路阶段
  2. 把优化动作对准当前主矛盾
  3. 让优化结果可被统计、可被复盘

没有归因，你就只能靠：

  • 经验和运气

有了归因，你才有：

  • 方向和优先级

什么样的分类机制才有用 ​

有用的分类机制通常具备三个特点：

  • 能映射到链路阶段
    例如：召回问题、过滤问题、重排问题、上下文构造问题、生成忠实性问题

  • 能支持主次错误标注
    因为一个案例很可能同时有两个错误

  • 能引导优化动作
    如果一个标签不能指导下一步要改什么，这个标签就不够好

一个最小但可用的分类层级 ​

如果你刚开始做归因，不需要一上来做得很复杂，可以先用下面这套一级标签：

  • data_preparation_error
  • query_understanding_error
  • retrieval_recall_error
  • metadata_filter_error
  • rerank_selection_error
  • context_construction_error
  • faithfulness_error
  • should_abstain_but_answered

这套标签能覆盖大多数常见错误，同时也能直接映射到后续的优化方向。

为什么“没有归因”会导致优化成本快速上升 ​

如果没有归因，你会不断做这些动作：

  • 同时改多个参数
  • 对单个案例做特判
  • 反复试不同组合

结果是：

  • 成本越来越高
  • 改动越来越难复盘
  • 系统越来越难维护

而有了归因后，调优会更像：

  • 对准某个错误桶
  • 针对性实验
  • 用数据验证变化

一个很实用的落地顺序 ​

更稳的起步顺序通常是：

  1. 先定义错误桶
  2. 先在高价值失败样本上做归因
  3. 用归因结果指导下一轮优化
  4. 回到评测集看该错误桶是否下降

这样你会发现，优化不再是“修一题”，而是“修一类问题”。

一个最小归因记录示意 ​

python
case = {
    "query": "企业版升级后还适用老合同折扣吗",
    "gold_evidence_in_recall": True,
    "gold_evidence_in_final_context": False,
    "answer_grounded": False,
    "primary_bucket": "rerank_selection_error",
    "secondary_bucket": "context_construction_error"
}

这个结构的意义在于：

  • 你可以对同类问题做聚合
  • 可以评估某个优化是否真的打掉了这一类错误

一句话总结 ​

RAG 调优必须建立问题分类和误差归因机制，因为没有它，优化动作就没有方向感，只能靠随机试参；有了它，你才能把优化从“修个案”升级为“修一类问题”。