AI 事故复盘：当「模型导致的」成为根本原因

一家航空公司的客服 AI 告诉一位旅客，他可以先购买全价机票，事后再申请丧亲优惠折扣。旅客信以为真，飞行后提交了申请，却遭到公司拒绝。仲裁庭最终判决公司须赔偿 650 美元——因为法律上并无区分人类员工与聊天机器人所给建议的规定。那个聊天机器人并未崩溃，没有任何告警触发，p99 延迟也未见异常。系统在「正常运行」。

这正是 AI 事故的典型特征：应用程序并未报错——它成功地、自信地、大规模地生成了错误输出。 而当你坐下来撰写事后分析报告时，经典的工具箱便彻底失灵了。

五问分析法（5-Why）假设只要沿着因果链追溯足够深，就能找到一个可修复的确定性根本原因：「函数返回了 null，因为输入为空，因为上游服务丢弃了字段，因为……」这条链是存在的，可以追溯。

但在 AI 故障中，因果链终止于「模型根据此输入预测了此输出」——而这个预测是随机的。用相同的提示词再问一次，可能得到不同的答案。「bug」无法复现，没有代码行可以指向，故障在你无法控制的数十亿参数内部概率性地发生。

本文将具体讲解如何应对这一困境。

为何五问分析法在随机系统上失效

五问法是一种根因提取技术，它在原因具有确定性且单一的场景下有效。而 AI 故障同时违反了这两个前提。

模型层的不确定性：即使温度设为 0，大多数生产级 LLM 仍因批归一化、硬件间浮点不确定性以及量化效应而引入随机性。温度大于 0 时，你实际上是在从概率分布中采样。「相同」的提示词并不能保证相同的输出。

多重叠加原因：一次 AI 事故通常至少有三个相互交织的原因——模型行为、提示词缺陷和数据上下文问题——任何单一原因都不足以单独触发故障。五问法寻找单一根因，而非多因素交集。

静默失效模式：传统事故有明确的检测时刻：错误率飙升、崩溃告警触发、超时阈值被突破。AI 事故往往通过用户投诉、下游数据质量检查或人工复核才浮出水面——有时在故障发生数天之后。那时，触发故障的精确条件可能已无法还原。

结论：你不能像对待软件 bug 事后分析那样对待 AI 事后分析，需要一套不同的分析框架。

AI 故障类型分类

在撰写有价值的事后分析之前，你需要正确判断发生了哪种故障类型。不同类型的修复方案截然不同。

模型故障是嵌入在训练参数本身中的故障。亚马逊的实验性招聘工具会对包含「女性」等词汇的简历降权，因为它是在一个以男性为主的行业的十年简历数据上训练的。这个 bug 存在于训练数据和已学习的权重中——没有任何代码路径可供检查，无法打补丁，只能重训或废弃。

提示词故障是你对模型的指令方式存在缺陷。提示词的意图与模型实际优化的目标不匹配。一个要求「总结这份合同」却未指定受众、长度或关键条款的提示词，将产生不一致的输出。模型没有问题，是指令欠具体。这类问题可通过提示词迭代和评估来修复。

数据故障是由于输入分布偏离了模型构建时所针对的数据而导致的故障。Zillow 的房屋估值算法在疫情后市场剧烈波动打破所有历史规律之前运作良好。模型的内部逻辑是自洽的——是现实世界的分布变了。这类故障需要监控和重训触发机制，而非提示词修复。

大多数生产 AI 事故是多种类型的叠加：约束不足的提示词（提示词故障）在分布偏移的输入上运行（数据故障），触发了模型训练中的某个边缘情况（模型故障）。你的事后分析需要识别哪一层是主因，以及各层各自贡献了什么。

重建故障所需的遥测数据

大多数 AI 事后分析得出模糊结论的原因，在于团队在推理阶段未捕获足够的上下文。仅凭延迟指标和错误率，你无法重建一次 AI 故障。

捕获完整的请求-响应对：每次推理调用都应存储完整的提示词（包括系统提示和注入的上下文）、原始模型响应、模型版本和配置（温度、最大 token 数、top-p），以及将其与用户会话和上游请求关联的 Trace ID。

端到端追踪多阶段流水线：大多数生产 LLM 系统并非单次推理调用，而是检索流水线、链式 Agent 调用、工具执行和重排序步骤的组合。每个阶段都需要自己的 Span——检索查询与结果、重排分数、链中的每次 LLM 调用、每次工具调用及其输出。事故发生时，你需要重建完整的因果链，而不仅仅是最终生成结果。

记录上下文窗口内容：检索增强系统在检索到的上下文错误、过时或不相关时会失效。捕获推理时上下文窗口中的文档内容——而不仅仅是检索所用的查询——是你能够解释故障与在事后分析中写下「模型产生了幻觉」之间的关键差异。

保留模型版本元数据：如果你在调用 API 提供商，记录精确的模型版本，而不仅仅是模型名称。「gpt-4」并非稳定的制品；提供商会悄然进行更新。当行为发生偏移时，你需要知道模型是否在你不知情的情况下发生了变化。

在推理旁路实现结构化评估日志：与其等待事故后再分析质量，不如将轻量级自动评估作为推理流水线的一部分来运行。在每条响应旁记录结构化质量得分（准确性、相关性、约束满足度）。这将你的生产流量转化为持续数据集——也是在用户投诉之前检测降级的手段。

如何撰写真正能带来学习的事故复盘

AI 事后分析最大的失败模式不在于分析本身，而在于框架。团队将「模型产生了错误输出」既作为事故描述又作为根本原因，然后得出结论「我们将更加仔细地监控」。这样的事后分析比没有还糟糕；它训练了团队将 AI 故障视为无法分析的天灾。

重建条件，而非仅仅记录输出：对于每次 AI 事故，事后分析应回答：上下文窗口中有什么？哪些检索结果填充了提示词？使用了哪个模型版本和参数？用户的确切输入是什么？如果你无法回答这些问题，你的可观测性基础设施才是真正的问题所在——这应该成为首要的纠正行动。

明确分类故障并直接陈述：「模型故障：模型的训练数据不包含与其学到的默认值相矛盾的最新策略信息。」「提示词故障：系统提示未说明当模型缺乏策略信息时应表达不确定性。」「数据故障：上下文注入流水线检索了六周前的缓存文档。」命名类型强制了精确性，并使纠正行动变得显而易见。

度量故障半径：有多少用户收到了错误输出？从故障发生到检测的时间窗口是多少？哪些下游系统或决策受到影响？故障半径不仅仅是严重性标签——它是一个量化估算：受影响用户数 × 检测窗口 × 用户依据该输出采取行动的概率。影响 12 名用户持续 4 小时的故障与影响 12,000 名用户持续 4 周的故障，修复优先级截然不同。

承认你不会知道的事情：诚实的事后分析承认重建的局限性。如果你没有该事故会话的 Trace，就明说。如果模型的不确定性意味着你无法确认模型当时会说什么，也明说。认识论上的谦逊不是软弱——它是向团队发出的信号：投资可观测性基础设施本可改变结果。

构建不止于「加强监控」的运行手册

AI 系统的运行手册必须做一件传统运行手册不需要做的事：区分客户时钟和诊断时钟。

客户时钟是修复时间：你能多快停止损害？答案几乎总是「回滚到上一个已知良好的模型版本或收紧输出过滤器」。这应该是一个五分钟的操作。运行手册步骤是：识别行为偏移之前部署的模型版本，切换部署，验证问题输出不再出现，更新事故状态。

诊断时钟是理解时间：你能多快识别发生了什么变化以及为什么？这需要更长时间，不应阻塞客户时钟。诊断与修复并行运行。

围绕故障类型构建 AI 运行手册：

对于疑似提示词故障：检查版本控制中的最近提示词变更，对受影响的提示词运行回归测试套件（你应该有一个），比较变更前后的输出分布，找出缺失的具体约束或指令。

对于疑似数据故障：检查相关输入的特征分布和数据新鲜度，对分布偏移运行统计检验（种群稳定性指数是标准指标），识别故障是否与特定输入段或时间窗口相关。

对于疑似模型故障：检查底层模型版本是否发生变化（API 提供商会静默更新模型），比较相同输入在不同版本上的模型行为，判断故障是否在使用固定参数的沙箱环境中可复现。

建立明确的升级标准：AI 事故何时被视为 P0？一个有用的阈值：任何用户在高风险领域（医疗、金融、法律）收到可能据此采取行动的事实错误输出，无论数量多少都是 P0。影响 10,000 名用户但后果低风险的故障可能是 P2。在事故发生之前定义这些，而不是在事故发生时。

闭环：从事后分析到预防

AI 事后分析的输出应该是以下一个或多个具体制品——而不是泛泛的行动项：

一个回归测试用例：捕获故障的具体输入、上下文和预期行为。这进入你的黄金数据集，并针对每个未来的模型版本和提示词变更运行。

一个已识别的可观测性缺口：你没有拥有的、本可加速诊断的具体遥测数据。一份捕获它的运行手册。一个落地时间表。

一条分类更新：在你的内部 AI 事故数据库（哪怕是一张电子表格）中标记记录故障类型、受影响系统、故障半径和解决方案。随着时间推移，这将成为让你看到规律的数据集——特定领域的提示词故障集群、特定输入段的周期性数据漂移。

一条护栏或约束：如果是提示词故障，向系统提示添加新约束或少样本示例。如果是模型故障，添加新的输出验证器。如果是数据故障，添加新的新鲜度检查或过期拒绝规则。

随时间推移在 AI 可靠性上取得进步的团队，是那些将每次事后分析视为评估和可观测性基础设施投资的团队——而不仅仅是记录出了什么问题的团队。目标不是让模型完美；而是让系统的失效模式可见、有界且可学习。

AI 系统会产生错误输出。这不是事故——这是概率系统的物理特性。事故是你直到用户告诉你才知道它发生了，你无法重建原因，也没有原则性的应对方案。那是流程故障，而且完全可以修复。