失败归因面板 — 工具失败 / 模型幻觉 / 上下文污染三分

日期: 2026-07-10 阶段: Phase 1 - 产品定义×评测×可观测底座 标签: #failure-attribution #observability #agentic-control-plane

核心问题

W2 的错误分析产出了 6 类 failure taxonomy（轴向编码结果），W4 的 tracing 栈记录了每一步 step/toolCall 的输入输出。但当一个 run 给出错误答案时，开发者真正要回答的不是「错了」，而是**「错在哪一层」**：是工具调用本身失败（API 4xx/超时/空结果），还是模型凭空捏造（model hallucination），还是检索/上游污染了上下文让模型「忠实地复述了垃圾」（context contamination）？

这三者的修复路径完全正交：工具失败要修 retry/熔断/降级；模型幻觉要修 prompt/约束/judge；上下文污染要修检索/重排/去噪。把三者混为一谈，就会用错药——给上下文污染加 judge 是无效的，因为模型并没有「不忠实」，它忠实地复述了被污染的上下文。「失败归因面板」就是把 trace 自动折叠到这三个桶里，让修复有的放矢。

反直觉洞察（本篇核心）：生产中被标为「幻觉」的失败，多数其实是上下文污染或检索 miss。AgentHallu（arXiv 2601.06818, 2026-01）的核心发现即此——许多 apparent model hallucination 实际源于 upstream context/retrieval 问题，而非模型的生成过程。误判归因 = 用错修复路径 = 浪费一个迭代周期。

关键内容

A. 三分归因的判定信号与边界（怎么区分幻觉 vs 上下文污染）

三分框架的难点全在「幻觉 vs 上下文污染」这条边界上——工具失败有显式 error 字段，最易判（见 B 节决策树第一岔）。真正考验是后两者：二者的表象一样（模型输出了一个事实，该事实是错的），但机制相反：

• 模型幻觉（model hallucination）：上下文里没有支撑该陈述的证据，模型自行编造。判定信号 = 输出陈述在 retrieved context / tool results 中找不到来源（unsupported by context）。
• 上下文污染（context contamination）：上下文里有该陈述，但上下文本身是错的——检索召回了错误/过时/对抗性文档，或前序步骤把错误结果写进了 working memory。判定信号 = 输出陈述在上下文中有来源，但来源本身错误。

关键的可操作判据是「陈述-来源对齐检查（claim-source grounding check）」：对每条输出陈述，在本步可见的上下文（StepTrace 的检索结果 + 上游 toolCall.result）中搜索支撑片段。

注意第三行：RAG 引入的新失败面叫 unfaithfulness——检索召回了正确文档，但模型仍输出与之矛盾的内容（Lakera/futureagi 2026 口径：RAG 在 chunk 含答案时降低 fabrication，却新增了 model contradicts retrieved context 这一面）。本框架把 unfaithfulness 折叠进「模型幻觉」桶，因为修复路径同向（约束模型、judge 拦截），与「上下文污染」（修检索）正交。

B. 归因决策树（自动折叠 trace 到三桶）

面板对每个失败 run 自上而下跑这棵决策树，第一个命中的叶子即归因：

attribute(run, failedStep):
  # 第 1 岔：工具层显式失败 —— 最易判，优先
  for tc in failedStep.toolCalls:
    if tc.error != null:                      → TOOL_FAILURE (subtype: error)
    if tc.endedAt == null:                     → TOOL_FAILURE (subtype: timeout/hang)
    if isEmpty(tc.result):                      → TOOL_FAILURE (subtype: empty_result)

  # 第 2 岔：上游污染 —— 检索/工具结果本身有问题
  ctx = collectContext(failedStep)   # 本步可见的检索片段 + 上游 toolCall.result
  if retrievalRecallMiss(ctx):                  → CONTEXT_CONTAMINATION (subtype: retrieval_miss)
  if hasStaleOrConflicting(ctx):                → CONTEXT_CONTAMINATION (subtype: poisoned_ctx)

  # 第 3 岔：陈述-来源对齐
  for claim in extractClaims(failedStep.output):
    src = findSupport(claim, ctx)
    if src == null:                             → MODEL_HALLUCINATION (subtype: fabrication)
    elif src.isWrong:                           → CONTEXT_CONTAMINATION (subtype: faithful_to_garbage)
    elif contradicts(claim, src):               → MODEL_HALLUCINATION (subtype: unfaithfulness)

  return UNATTRIBUTED   # 兜底桶：归因器自己也搞不清 → 进人工队列

设计要点有三：(1) 顺序敏感——工具失败必须先判，否则一个空 result 会被误判成「模型没有上下文 → 幻觉」，实际是工具没返回；(2) extractClaims + findSupport 这两步可由代码型检查（精确匹配/embedding 相似度）做，也可由 LLM-judge 做，但 judge 必须先按 Day 3 的人工一致率门槛校准；(3) UNATTRIBUTED 桶不可省——归因器自身也会失败，强行三选一会污染统计，宁可显式进人工队列。

C. taxonomy 6 类如何折叠进三分框架

W2 轴向编码产出的 6 类 failure taxonomy 是「现象层」分类（用户看到的症状），三分框架是「修复层」分类（开发者怎么修）。二者是多对三的折叠关系，不是替换关系——现象类别给产品/PM 看（按症状统计、定优先级），三分桶给工程看（按修复路径分工）。映射如下（taxonomy 的具体 6 类来自 W2 在 agent-v2 真实 traces 上的开放编码，此处用 AML copilot 域的代表性现象命名）：

折叠的价值：6 类现象按症状报给 PM（哪类最高频→定迭代优先级），但工程修复只需面对 3 条路径。一个失败 run 在面板上同时带「现象标签（多选）+ 归因桶（单选）」两套元数据——前者驱动产品决策，后者驱动代码修复。

D. 为什么「失败归因」是 agentic 系统设计的高频面试点（控制面视角）

2026 的 agentic system design 面试已稳定收敛为八域（《Complete Agentic AI System Design Interview Guide 2026》, Medium 2026）：Core Concepts、Agent Architecture & Control Plane、Planning、Tool Use、Memory & Context、Multi-Agent、Evaluation/Safety/Reliability、Scaling/Production。失败归因横跨第 2 域（控制面）与第 7 域（可靠性），是高频考点，原因有三：

1. 它是控制面存在的理由。控制面把「编排/执行（orchestrator）」与「推理/决策（LLM）」分离（IBM/Google Cloud agent control plane 口径）——分离的直接收益就是可归因：能指出失败发生在编排逻辑、LLM 推理、还是工具执行。面试官问「你怎么 debug 一个多步 agent」，标准答案骨架就是这三分。
2. 它考的是分布式系统功底。归因技术几乎照搬分布式 tracing：correlation ID 贯穿 trace、每步 state snapshot 对比预期/实际、schema validation 在执行前分离「畸形请求（LLM 错）」与「执行错误」。这把 LLM 系统拉回到经典可观测性范畴——区分本仓 dsdb 笔记里 Jepsen「不信任、必测试」的同一精神。
3. 多 agent 放大归因难度。多步工作流里中间错误会传播（AgentHallu 2026-01：sequential nature amplifies hallucination），所以「哪个 agent、哪一步引入了失败」本身成为一个研究问题——Princeton 等已有专门的 failure-attribution-in-multi-agent 方法。面试要求候选人能说清「为什么不能只看最终输出，必须 step-level 归因」。

设计要点/决策表

对本项目的落地

• 数据底座已就位：src/agent/trace/types.ts 的 ToolCallTrace 已含 error、endedAt、result 三字段——决策树第 1 岔（工具失败三子型）可零改造直接判：error != null / endedAt == null / isEmpty(result)。这是面板能落地的前提，无需新埋点。
• 新增归因器（设计，非已实现）：拟在 src/agent/eval/ 新增 attributeFailure.ts，输入 RunTrace，输出 { bucket: 'tool'|'hallucination'|'context'|'unattributed', subtype, evidenceStepId }。collectContext 从 StepTrace.toolCalls[].result + 检索片段聚合；findSupport v1 用代码型精确/子串匹配（零方差、可进 CI），v2 再接 embedding 相似度。
• AML copilot 接口：AML 侧的失败现象（src/aml/ 规则误报、src/aml/sarDraft.ts 引用了不存在的证据 ID）天然映射到三桶——SAR 草稿编造证据 ID = MODEL_HALLUCINATION，类型学规则因合成数据某字段缺失而漏判 = CONTEXT_CONTAMINATION（retrieval_miss 的规则版）。Day 5 设计的 generatedBy: 'rule-template' 标注是归因的第一手锚点。
• 面板 UI：在现有 trace 可视化（src/agent/trace/useTraceStore.ts 驱动）上叠加归因色块——每个失败 step 标三桶之一的颜色 + subtype tooltip + 指向 evidenceStep 的跳转。统计区按三桶 + 6 现象类别双轴出条形图。
• CI 联动：归因器对 W2 金标失败案例的归因结果可入回归——若某次改动让「上下文污染」桶占比异常上升，提示检索退化，作为 recall@k 之外的第二道 tripwire（接 src/agent/eval/retrievalGolden.ts 的已知局限：slug 内嵌是结构匹配，归因桶能侧面暴露语义检索的真实质量）。

参考资料

• AgentHallu: Benchmarking Automated Hallucination Attribution of LLM-based Agents — arXiv 2601.06818v1（2026-01）：step-level 归因；多数 apparent hallucination 实为上游 context/retrieval 问题
• The Complete Agentic AI System Design Interview Guide 2026 — Medium/TechEon（2026）：八域框架；控制面分离 orchestrator/LLM；correlation ID / state snapshot / schema validation 归因技术
• Why AI Agents Fail: A Taxonomy of Failure Modes in Autonomous LLM-Based Systems — Vadlamudi, SSRN 6572478（2026）：四模块失败分类（reasoning/tool/memory/multi-agent）
• LLM Hallucinations in 2026 — Lakera（2026）；LLM Hallucination 2026: Causes, Types — futureagi（2026）：RAG 新增 unfaithfulness 失败面；六分幻觉模式、按模式分别报率
• What is an Agent Control Plane? — IBM（2026）；AI Control Plane — TrueFoundry / Google Cloud agentic architecture components（2026）：控制面在数据面之上、编排与推理分离
• Disentangling Deception and Hallucination Failures in LLMs — arXiv 2602.14529：Knowledge Existence × Behavioral Expression 双隐因子机制级解释

SOTA 检查 (2026-06-11)

• 失败归因为 2026 上升期热点：AgentHallu（2026-01）、Agentic Attribution「The Why Behind the Action」（arXiv 2601.15075）、多 agent 失败归因（Princeton 系）密集出现，step-level / 模块级归因是当前研究主线，无更成熟替代框架——本篇三分桶是工程简化版（按修复路径），与学术的细粒度 step 归因互补。
• 控制面叙事已是事实标准：IBM/Google Cloud/TrueFoundry 2026 口径一致——orchestrator/LLM 分离是 agentic 架构默认形态，归因能力是其卖点。
• RAG unfaithfulness 是公认新失败面：2026 多家（Lakera/futureagi）确认 RAG 不消灭幻觉而是位移失败面——本篇把它归入模型桶的决策需随社区共识跟踪（若未来证明 unfaithfulness 修复更靠检索而非约束，则应改归上下文桶）。
• 过时认知警示：把 agent 失败统计成单一「幻觉率」是 2024 做法，2026 已淘汰——必须按模式/按归因桶分别报率（futureagi 2026 明述「stopped reporting a single number」）。本项目面板的双轴统计正是对此的执行。
• 待跟踪：归因器若用 LLM-judge 做 findSupport，须按 Day 3 约束先校准；arXiv 2602.x 的 deception vs hallucination 区分（2026 更新）可能为「模型桶」再细分（编造 vs 故意误导），P2 复查时评估是否纳入。