布吉岛 Agent

Appearance

9.5.3 如何建立问题分类和误差归因机制？ ​

先给结论：错误归因机制不是开会时临时讨论几句，而是一套可重复的记录和复盘流程。它至少要包含统一的错误标签、案例记录字段、主次错误判断规则，以及持续回看统计结果的机制。

很多团队的问题不是没有失败案例，而是：

  • 错误样本散落在聊天记录、表格、工单和群消息里
  • 每个人用不同语言描述同一种问题
  • 本周说是检索问题，下周又说是模型问题
  • 出现退化时，很难判断是偶发还是某一类问题系统性增多

这说明你缺的不是案例，而是机制。

一个能用的归因机制，至少要解决四件事 ​

第一，统一怎么给错误命名 ​

如果同一个问题，A 同学叫“召回不准”，B 同学叫“答案答偏”，C 同学叫“模型胡说”，后面就没法统计。

所以第一步要先统一错误桶。例如：

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

名字不一定必须是这套，但必须固定下来。

第二，统一每个案例至少记录什么 ​

如果错误记录只有一句“这题答错了”，后面基本没法复盘。

更稳的最小字段通常包括：

  • 用户原始问题
  • 系统最终回答
  • 正确答案或判定规则
  • 正确证据范围
  • 初次召回结果摘要
  • 最终上下文摘要
  • 主错误桶
  • 次错误桶
  • 严重程度
  • 是否属于新问题类型

这些字段能帮助你在后面做横向统计，而不只是看单题。

第三，统一主错误和次错误怎么判 ​

很多失败案例会跨多个环节，所以最好明确：

  • 什么叫主错误：最早导致失败、最该优先修复的环节
  • 什么叫次错误：即使主错误修掉，仍可能影响质量的次级问题

这样能减少团队里“到底算谁的问题”的争论。

第四，统一多久复盘一次、按什么口径看趋势 ​

如果没有周期性回看，标签再完整也会失效。最少要做到：

  • 每周或每版本回看一次错误桶分布
  • 对比新旧版本各桶占比变化
  • 观察有没有某类问题突然上升

归因机制最终是为了指导动作，不是为了积累表格。

更实用的建立顺序 ​

如果你现在还没有任何错误归因机制，可以按下面这个顺序起步。

第一步，先定一套轻量标签，不要一开始就过细 ​

刚开始标签太细，通常会导致：

  • 打标成本太高
  • 不同人理解不一致

更稳的做法是先用一级标签起步，例如：

  • 数据问题
  • query 理解问题
  • 检索问题
  • 重排/选择问题
  • 上下文构造问题
  • 生成忠实性问题
  • 边界与拒答问题

等案例积累到一定量，再往下细分二级标签。

第二步，先在高价值失败样本上跑通流程 ​

不要一开始试图给所有日志打标签。先挑：

  • 高频失败样本
  • 高风险错误样本
  • 新版本回归样本

先把流程跑通，再逐步扩大覆盖。

第三步，建立“先证据、后归因”的习惯 ​

不要看一眼答案就直接给标签。更稳的流程是：

  1. 先确认正确证据是什么
  2. 再看召回结果
  3. 再看最终上下文
  4. 最后看模型回答
  5. 再决定主错误和次错误

这样归因会稳定很多。

第四步，让标签能够映射到动作 ​

好的错误标签应该天然对应后续动作。例如：

  • metadata_filter_error 对应检查 filter 设计和检索执行位置
  • context_construction_error 对应检查聚合、排序、截断和模板组织
  • faithfulness_error 对应检查 prompt 约束、证据组织和生成评测

如果一个标签无法引导动作，这个标签往往还不够好。

一个最小记录结构示意 ​

python
analysis_record = {
    "query": "企业版退款是否包含定制服务",
    "gold_evidence": ["refund-policy-2026#2.3"],
    "gold_evidence_in_recall": True,
    "gold_evidence_in_final_context": False,
    "answer_grounded": False,
    "primary_bucket": "rerank_selection_error",
    "secondary_bucket": "context_construction_error",
    "severity": "medium",
    "next_action": "check rerank ordering and final context truncation"
}

这个结构最关键的不是字段多，而是它把：

  • 现象
  • 证据状态
  • 归因结果
  • 下一步动作

连在了一起。

怎样让不同人打标签更一致 ​

归因机制最大的现实难点，不是没有框架，而是多人判断不一致。要降低这个问题，通常要补三样东西：

  • 每个标签的定义说明
  • 典型正例和反例
  • 主错误优先级判断规则

例如：

  • 如果关键证据根本没召回，主错误优先归到检索层
  • 如果关键证据召回了但没进最终上下文，主错误优先归到选择或上下文构造层
  • 如果关键证据已在上下文里，回答仍然外推，主错误优先归到忠实性问题

这种规则会显著降低争议。

复盘时不要只看案例，要看分布变化 ​

一个很常见的低效做法是：

  • 每次只看几道错题

这样当然有帮助，但还不够。更关键的是看：

  • 某一类错误是否正在系统性上升
  • 某次改动之后，错误结构有没有发生迁移
  • 一类错误修复后，是否把问题推到了下一层

例如：

  • recall 提升后，faithfulness 问题反而变多

这不一定说明系统更差，而可能说明：

  • 以前是“没找到”，现在变成“找到了但没用好”

这种迁移只有在错误分布里才看得清。

一句话总结 ​

问题分类和误差归因机制的核心，不是把错误写进表格，而是建立一套稳定流程，让每个失败案例都能沉淀成可统计、可行动、可复盘的信息。