第 21 章：Bad Case 分类与根因归因
第 21 章：Bad Case 分类与根因归因
21.1 “模型不行”不是一个可执行结论
客服 Agent 答错了一条退款政策。用户问：“我用了优惠券并且只退一件商品，会员积分会扣回吗？”Agent 回答：“积分不会受影响，退款会按原支付金额退回。”人工客服复核后发现，这个回答同时违反了退款金额计算规则和会员积分扣回规则。
会议上很快出现一个判断：模型不行。
这个判断没有办法指导修复。因为真正的根因可能在不同层：
- 知识库没有最新政策。
- 检索没有召回正确条款。
- Prompt 没有要求遇到金额和权益问题必须引用政策。
- Agent 没有调用退款规则工具。
- 工具返回了错误字段。
- 业务规则本身没有同步到 AI 系统。
- 模型看到了正确上下文，但生成时没有忠实回答。
Bad Case 归因的目标，是把“系统错了”拆解为“哪一层、哪类机制、在什么证据下导致错误”。只有这样，后续优化才不会变成盲目调参。
21.2 Bad Case 不是一条失败样本，而是一组证据
一个可归因的 Bad Case 至少包含五类证据。
| 证据 | 作用 |
|---|---|
| 用户输入与对话上下文 | 判断任务目标和多轮状态 |
| 最终回答 | 判断错误现象和影响 |
| 检索与工具记录 | 判断系统是否拿到正确信息和执行结果 |
| Agent Trace | 判断规划、工具选择、状态管理和异常恢复 |
| 版本与配置 | 判断问题是否与某次变更相关 |
如果只保存最终回答，归因会高度依赖猜测。企业级评测必须让 Bad Case 进入可回放、可比较、可复验的证据结构。
一个 Bad Case 可以这样表达：
case_id: bc_refund_policy_20260708_001
scenario: 会员部分退款
user_intent: 查询优惠券退款与积分扣回规则
final_answer: 积分不会受影响，退款按原支付金额退回
expected_behavior: 引用最新政策说明优惠券分摊和积分扣回规则
risk_level: P1
version:
agent: refund_agent_gray_20260708
prompt: refund_prompt_v12
knowledge_base: refund_policy_kb_20260701
evidence:
retrieval: available
tool_call: missing
trace: available
human_review: confirmed_wrong
status: pending_attribution
这个结构不急于下结论，而是为诊断准备证据。
21.2.1 证据成熟度
不是所有 Bad Case 都具备相同诊断价值。可以按证据成熟度分级。
| 等级 | 证据状态 | 可做动作 |
|---|---|---|
| E0 | 只有用户反馈或投诉摘要 | 进入候选池，继续补充上下文 |
| E1 | 有用户输入和最终回答 | 可做现象分类，不适合深度归因 |
| E2 | 有检索、工具或部分 Trace | 可做初步分层归因 |
| E3 | 有完整 Trace、版本和人工复核 | 可做高置信归因 |
| E4 | 有对照实验和复现结果 | 可进入修复决策和回归沉淀 |
证据成熟度能防止团队过早下结论。只有 E1 证据时，不应直接判断“模型不行”；只有 E3 或 E4 证据时，才适合把结论用于高风险修复决策。
21.3 错误分类：先描述现象，再判断根因
归因前要先分类。分类的第一层是错误现象，而不是技术根因。
| 错误现象 | 定义 | 客服 Agent 示例 |
|---|---|---|
| 知识错误 | 回答内容与事实或政策不一致 | 退款期限说错 |
| 检索失败 | 正确知识存在但未进入上下文 | 没召回最新会员政策 |
| 幻觉 | 无依据生成具体承诺 | 编造补偿金额 |
| 工具错误 | 工具选择、参数或结果使用错误 | 订单号参数填错 |
| 状态丢失 | 多轮信息没有被保留 | 忘记用户已说明商品类型 |
| 业务规则错误 | 对业务约束理解或执行错误 | 未判断是否高风险转人工 |
| 安全错误 | 泄露隐私、越权或误放 | 未核验身份直接查订单 |
| 体验问题 | 回答冗长、绕圈或不可执行 | 让用户重复提交已给信息 |
错误现象可以多标签。一次退款误答可能同时是知识错误、业务规则错误和体验问题。
第二层是影响等级。
| 等级 | 判断标准 |
|---|---|
| P0 | 隐私泄露、越权、严重合规风险、不可接受承诺 |
| P1 | 影响核心业务结果或造成明显用户损失 |
| P2 | 影响体验或效率，但有兜底路径 |
| P3 | 表达、格式、轻微偏好问题 |
第三层才进入技术归因。
21.4 分层根因模型
企业级 LLM / Agent 系统的错误根因通常分布在七层。
| 层级 | 典型根因 | 诊断证据 |
|---|---|---|
| 模型层 | 基础能力不足、忠实性差、推理不稳定 | 同样上下文下仍答错，多模型对比 |
| Prompt 层 | 指令缺失、约束冲突、示例偏移 | Prompt 版本对比、约束覆盖检查 |
| RAG 层 | 解析、Chunk、召回、排序、上下文拼接问题 | 检索日志、TopK、引用、召回评测 |
| 工具层 | 工具描述不清、参数错误、返回异常 | Tool Call、Schema、错误码 |
| Agent 编排层 | 规划错误、状态丢失、循环、异常恢复失败 | Trace、状态快照、步骤序列 |
| 系统层 | 超时、缓存、路由、并发、权限配置问题 | 系统日志、请求链路、配置差异 |
| 业务规则层 | 政策过期、规则未同步、人工流程不一致 | 规则库、业务公告、人工客服记录 |
归因时不要默认模型层优先。很多线上 Bad Case 的根因在 RAG、工具、状态和业务规则。
21.4.1 主根因与贡献因素
很多 Bad Case 不是单一根因。归因报告应区分主根因和贡献因素。
| 类型 | 说明 |
|---|---|
| 主根因 | 没有它，错误大概率不会发生 |
| 贡献因素 | 加剧错误、降低恢复能力或扩大影响 |
| 暴露条件 | 让问题显性化的触发场景 |
退款政策误答中，主根因可能是 RAG 未召回会员积分规则；贡献因素可能是 Prompt 没有要求证据不足时转人工；暴露条件是用户询问优惠券和会员积分叠加场景。
这样的区分能避免修复动作过窄。只修复主根因可能让同类问题在其他条件下继续发生。
21.5 RAG 归因：把“没答对”拆到检索链路
RAG 类错误要沿着链路逐段检查。
| 环节 | 诊断问题 | 证据 |
|---|---|---|
| 文档解析 | 政策内容是否被正确解析 | 解析后的文本、表格、标题结构 |
| Chunk | 关键规则是否被切散或混入无关上下文 | Chunk 内容、长度、边界 |
| 索引 | 文档是否进入正确索引 | 索引版本、更新时间 |
| 召回 | 正确 Chunk 是否进入 TopK | Query、TopK、召回位置 |
| Rerank | 正确 Chunk 是否被排到前面 | 排序分、重排结果 |
| 上下文构造 | 正确信息是否进入模型上下文 | Prompt Context |
| 生成 | 模型是否忠实使用上下文 | 最终回答、引用、反事实测试 |
以退款政策误答为例，诊断顺序可以是：
- 最新退款政策是否在知识库中。
- 会员积分扣回规则是否被解析为可检索文本。
- 用户问题是否召回该规则。
- 召回后是否被放入模型上下文。
- 模型是否忽略上下文并生成错误承诺。
如果正确 Chunk 没有进入 TopK，优先查 Query 改写、Embedding、索引和召回策略。如果正确 Chunk 进入上下文但模型仍答错，才进一步检查 Prompt 约束和模型忠实性。
21.6 Agent 归因：不要只看最终答案
Agent 错误经常发生在中间步骤。
| Agent 环节 | 常见错误 | 客服 Agent 示例 |
|---|---|---|
| 任务规划 | 漏掉必要步骤 | 没有先核验订单状态 |
| 工具选择 | 选错工具或不调用工具 | 应调用退款规则工具却只检索知识库 |
| 参数构造 | 参数缺失、类型错误、字段映射错 | 把商品 ID 当订单 ID |
| 状态管理 | 多轮信息丢失或污染 | 忘记用户已选择部分退款 |
| 记忆使用 | 引入无关历史信息 | 把其他订单的售后状态带入会话 |
| 异常恢复 | 工具失败后继续编造 | 工具超时后直接给出确定回答 |
| 循环控制 | 重复询问或重复调用 | 反复要求用户提供已提交信息 |
Agent 归因必须依赖 Trace。没有 Trace，只看最终回答，很容易把编排错误误判为模型错误。
21.7 Trace 回放
Trace 回放的目标，是复现 Agent 在某个 Bad Case 中的关键决策路径。
一个 Trace 回放记录应包含：
| 字段 | 说明 |
|---|---|
| step_id | 步骤编号 |
| input_state | 当前状态 |
| action | 模型生成、检索、工具调用、人工转接等 |
| action_reason | 可观察的选择依据 |
| output | 步骤输出 |
| expected | 该步骤期望行为 |
| deviation | 偏差说明 |
| evidence | 日志、上下文、工具返回 |
退款政策误答的 Trace 回放可能如下：
| step | 实际行为 | 期望行为 | 初步判断 |
|---|---|---|---|
| 1 | 识别为退款咨询 | 识别为会员部分退款 | 意图粒度不足 |
| 2 | 检索退款通用政策 | 检索会员退款和优惠券规则 | 检索 Query 缺少关键实体 |
| 3 | 未调用退款规则工具 | 调用规则工具计算权益影响 | 工具选择失败 |
| 4 | 给出确定回答 | 引用政策或转人工确认 | 生成阶段未执行风险约束 |
回放不一定立刻给出唯一根因，但能把问题缩小到几个可验证假设。
21.8 消融、对照和反事实
归因不能只靠观察。关键问题要通过对照实验验证。
| 方法 | 做法 | 适用问题 |
|---|---|---|
| 版本对比 | 同一 Case 在不同版本运行 | 判断是否由某次变更引入 |
| 上下文替换 | 替换为正确检索上下文 | 判断是检索问题还是生成问题 |
| 工具强制调用 | 强制加入工具结果 | 判断是否工具选择失败 |
| Prompt 消融 | 移除或加入关键约束 | 判断 Prompt 对错误的影响 |
| 模型替换 | 用不同模型运行同一输入 | 判断基础能力或忠实性差异 |
| 人工 Trace 标注 | 让专家标出偏差步骤 | 校准自动归因结果 |
例如，如果把正确会员退款政策直接放入上下文后，模型能够正确回答，根因更可能在检索或上下文构造。如果正确上下文已经存在，模型仍给出错误承诺，就要检查 Prompt 约束、模型忠实性或安全策略。
21.9 归因置信度
不是每个 Bad Case 都能立刻得到确定根因。归因结果应带置信度。
| 置信度 | 标准 |
|---|---|
| 高 | 有直接日志证据，并通过对照验证 |
| 中 | 多项证据一致，但缺少完整复现 |
| 低 | 只有现象推断，缺少关键 Trace 或对照 |
归因结论可以这样写：
该 Bad Case 的主要根因判断为 RAG 召回失败，置信度高。证据是最新会员退款政策存在于知识库，但原 Query 的 Top10 未召回相关 Chunk；将正确 Chunk 注入上下文后，模型能够给出正确回答。
这种写法比“模型答错了”更可执行。
21.9.1 归因会诊
高价值 Bad Case 应进入归因会诊，而不是由单个角色独立判断。
参与者通常包括：
| 角色 | 关注点 |
|---|---|
| 评测负责人 | 错误分类、风险等级、证据完整性 |
| RAG 工程师 | 文档、Chunk、召回、Rerank、上下文 |
| Agent 工程师 | 工具、状态、流程、Trace |
| 产品负责人 | 用户旅程和业务影响 |
| 客服运营 | 人工处理结果和用户反馈 |
| 安全负责人 | 隐私、越权、合规红线 |
会诊输出不应只是讨论结论，而应形成结构化记录：主根因、贡献因素、证据、置信度、Owner、修复动作和回归要求。
21.9.2 归因决策树
可以用一个简化决策树推进归因：
图 21-1 Bad Case 分层归因流程图
flowchart TD
A{"最终回答或过程存在问题吗？"} -->|最终回答错误| B{"正确知识是否存在？"}
A -->|过程/副作用/体验问题| L["检查Trace、工具副作用、体验或安全边界"]
B -->|否| C["知识库或业务规则问题"]
B -->|是| D{"正确证据是否召回？"}
D -->|否| E["RAG召回或索引问题"]
D -->|是| F{"正确证据是否进入上下文？"}
F -->|否| G["上下文组装或截断问题"]
F -->|是| H{"是否需要工具？"}
H -->|是但未调用| I["Agent工具策略问题"]
H -->|调用但参数错| J["Tool/参数问题"]
H -->|工具正确但回答错/无需工具| K["Prompt/模型忠实性问题"]
决策树不能替代专业判断，但能帮助团队避免跳步。
21.9.3 归因结论要能被反驳
一个可信归因结论，不只是听起来合理，还应当能被证据支持或反驳。
可以给每个归因结论补三类信息：
| 信息 | 作用 |
|---|---|
| 支持证据 | 哪些日志、Trace、对照实验支持该结论 |
| 反证检查 | 哪些证据如果成立，会推翻该结论 |
| 仍需验证 | 当前证据不足，需要补什么实验或数据 |
例如，团队判断“主根因是 RAG 召回失败”。支持证据是 Top10 没有召回会员积分规则；反证检查是如果正确 Chunk 已经进入上下文但模型仍答错，则主根因需要改为生成忠实性或 Prompt 约束；仍需验证的是改 Query 后同类 Case 是否稳定通过。
这种写法能防止归因变成经验判断。它也让后续修复更可验证：如果修复了召回策略，但同类问题仍出现，团队可以回到反证检查，重新评估根因。
21.10 案例：退款政策误答的分层诊断
围绕同一条 Bad Case，团队可以提出五个假设。
| 假设 | 验证方式 | 结果 |
|---|---|---|
| 知识库没有政策 | 查询知识库版本和文档内容 | 政策已存在 |
| 检索没有召回 | 查看 TopK 检索结果 | 未召回会员积分规则 |
| 上下文被截断 | 查看模型上下文 | 无相关规则 |
| 工具未调用 | 查看 Tool Trace | 未调用退款规则工具 |
| 模型忽略正确证据 | 注入正确政策后重跑 | 能正确回答 |
结论是：主根因是检索 Query 没有覆盖“会员积分扣回”和“优惠券分摊”，次要根因是 Agent 没有在金额权益问题上强制调用退款规则工具。
修复建议不在本章展开，但归因已经指向后续动作：改 Query 改写、补充检索评测样本、调整工具调用策略，并将该问题加入回归集。
21.10.1 归因输出要转成修复任务
归因如果不能转成修复任务，就仍然停留在分析层。每个高价值 Bad Case 的归因输出应至少形成三类任务：
| 任务类型 | 示例 | 验证方式 |
|---|---|---|
| 系统修复 | 优化 Query 改写、调整工具策略、修复 Prompt 约束 | 同类 Case 通过，相关指标恢复 |
| 数据沉淀 | 新增 RAG Case、Tool Case、端到端 Regression Case | 数据集版本更新并进入后续 Run |
| 监控补强 | 增加线上会员退款问题簇监控 | 看板能持续观察同类问题 |
以退款政策误答为例，RAG 工程师负责改 Query 和索引策略，Agent 工程师负责金额权益场景强制工具校验，评测负责人负责新增回归样本，产品或运营负责人负责确认人工兜底话术。归因报告必须把这些任务分派清楚，否则同类问题仍会反复出现。
这一归因还应形成可追踪记录：
| 字段 | 内容 |
|---|---|
| 主根因 | RAG Query 缺少会员积分扣回实体 |
| 贡献因素 | Agent 没有强制调用退款规则工具 |
| 暴露条件 | 用户询问优惠券、部分退款和会员积分组合 |
| 证据等级 | E4 |
| 置信度 | 高 |
| 修复 Owner | RAG 工程、Agent 工程、评测负责人 |
| 回归要求 | 新增 RAG Case、Tool Case、端到端 Regression Case |
21.11 交付物一：Bad Case 分类标签体系
| 标签维度 | 可选值 |
|---|---|
| scenario | 退款、物流、订单、售后、会员、发票 |
| user_intent | 查询、修改、取消、申诉、投诉、确认 |
| error_type | 知识错误、检索失败、幻觉、工具错误、状态丢失、业务规则错误、安全错误、体验问题 |
| risk_level | P0、P1、P2、P3 |
| affected_layer | 模型、Prompt、RAG、Tool、Agent、系统、业务规则 |
| evidence_status | Trace 完整、Trace 部分、仅最终回答 |
| recurrence | 首次、重复、集中爆发 |
| fix_status | 待归因、待修复、待回归、已关闭 |
标签体系要稳定，不要为每个问题临时造标签。否则后续统计和聚类会失效。
21.12 交付物二：分层根因归因模板
## Bad Case 基本信息
- case_id:
- 场景：
- 用户意图：
- 风险等级：
- 影响范围：
## 错误现象
- 最终回答：
- 期望行为：
- 错误类型：
## 证据链
- 用户上下文：
- 检索结果：
- 工具调用：
- Agent Trace：
- 版本信息：
## 分层排查
| 层级 | 是否相关 | 证据 | 结论 | 置信度 |
| --- | --- | --- | --- | --- |
| 模型 | | | | |
| Prompt | | | | |
| RAG | | | | |
| Tool | | | | |
| Agent | | | | |
| 系统 | | | | |
| 业务规则 | | | | |
## 归因结论
- 主根因：
- 次要根因：
- 置信度：
- 需要补充的验证：
模板的重点是让归因结论可审计、可复验。
21.13 交付物三：Trace 回放诊断表
| step_id | 输入状态 | 实际动作 | 期望动作 | 偏差 | 证据 | 归因线索 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | ||||||
| 3 |
Trace 回放表适合用于高价值 Bad Case 的深度诊断。不是每条线上样本都需要完整回放，但 P0、P1 和高频问题必须具备这种能力。
21.14 归因常见误区
21.14.1 看到 Bad Case 就微调
微调可能修复表面现象，也可能掩盖真正的检索、工具或业务规则问题。
21.14.2 只看最终回答
Agent 系统的错误经常发生在中间步骤。只看最终回答会丢失关键证据。
21.14.3 把单一根因当成全部解释
真实系统经常是多因素叠加。检索召回失败和工具策略缺失可能同时存在。
21.14.4 没有对照验证
没有版本对比、上下文替换或工具强制调用，归因很容易停留在主观判断。
21.14.5 归因后不沉淀标签
没有统一标签，Bad Case 只能逐条处理，无法形成趋势分析和系统性修复。
21.15 本章小结
Bad Case 归因的核心，是从“系统错了”走向“哪一层为什么错”。
有效归因需要三件事：
- 稳定的错误分类和风险分级。
- 覆盖模型、Prompt、RAG、Tool、Agent、系统和业务规则的分层诊断。
- Trace 回放、对照实验和归因置信度。
找到根因后，下一章我们将看到修复如何被验证、防复发机制如何建立，让每一个 Bad Case 都成为体系资产。