没人愿意写的 AI 事故复盘：四层诊断框架

上季度，某推荐引擎推送了冒犯性内容，随后召开的事故复盘会议以一种我们再熟悉不过的方式收场：两小时的会议里，ML 工程师把矛头指向检索语料库，数据工程师把矛头指向提示词，产品工程师把矛头指向监控，基础设施团队把矛头指向没人记得何时升级的模型版本。最终产出了三条行动项，却没有一条落实到具体负责人。事故就此关闭。六周后，同样的故障模式再次上线。

这不是某一个团队的故事，而是大多数组织处理 AI 事故时的默认结局。AI 功能在生产环境中造成的后果，由足够多的参与方共同承担，导致标准的事故复盘根本无法锁定因果关系。那套在排查数据库超时时行之有效的"5 Why"分析法，面对"模型给出了错误答案"时便彻底失灵——因为下一步该追问什么，从来都不显而易见。

从 2023 年到 2024 年，AI 事故增加了 56.4%。然而只有 20% 的组织拥有经过演练的 AI 事故响应预案。这两个数字之间的鸿沟，正是生产系统悄然劣化的温床。

为什么标准复盘对 AI 失效

传统复盘的前提是：一个根本原因，一个责任团队。标准流程是：找到出问题的服务，找到它的值班工程师，沿着系统往回追溯，直到找到原因，然后分配整改措施。

AI 功能至少在三个层面打破了这套模型。

第一，因果关系是分散的。 当一个 LLM 给出错误答案时，这个输出是模型权重、提示词、检索上下文、服务基础设施以及集成逻辑共同作用的产物。上述任何一层都可能是直接原因，而其他层看起来一切正常。对 1200 个生产 LLM 部署的分析发现，40% 的故障源于模型漂移，60% 源于工具版本问题——也就是说，在大多数事故中，模型本身并非罪魁祸首。但大多数复盘一上来就先审讯模型。

第二，故障信号是"软"的。 硬错误——HTTP 500、超时、空响应——会触发告警，很快被发现。但 AI 的劣化通常表现为延迟升高、点击率下降、答案细微出错——用户将就着忍受，直到彻底停止使用该功能。某 LLM 服务商发布的一份复盘报告记录了三个同时发生的质量回归，持续数周未被察觉，原因是整个过程中 HTTP 成功率始终正常。其中一个 bug 导致返回语言错误，另一个导致算术计算出错。两者对外呈现的都是干净的 API 响应。

第三，所有权本身就不清晰。 ML 工程师负责模型逻辑和提示词。数据工程师负责检索语料库和特征流水线。产品工程师负责集成逻辑和面向用户的行为。基础设施负责服务层、模型版本和部署配置。四方各有部分责任、各有部分可见性，却没有一方掌握全貌。当一次事故横跨两个层——比如一个原本没问题的提示词，在检索语料库 schema 变更后开始出错——组织根本没有本能反应来判断谁来主导这场复盘。

四层诊断

解决方案不是重新画一张 RACI 矩阵。大多数 AI 团队已经有了所有权矩阵，只是这些矩阵的结构并不围绕事故最核心的追问——哪一层出了问题？

一场有价值的 AI 事故复盘，在分配任何责任或行动项之前，应先对四个层进行结构化诊断。

第一层：模型层

模型的输出发生了变化吗？这包括模型漂移（随着真实世界相对于训练数据的变化，性能退化）、硬件级错误（多个 LLM 服务商的生产复盘中均有记录的 TPU 或 GPU 算术 bug），或无人标记的模型版本变更。典型信号：输出错误，但输入看起来正常。实用核查项：事故窗口前后模型版本或配置是否有变化？预测分布是否发生偏移？故障是确定性的还是随机的？

第二层：数据层

流入模型的信息发生了变化吗？检索流水线上游的 schema 变更是 AI 事故的重要来源——不是因为数据团队犯了错，而是因为 AI 功能对数据结构存在隐式依赖，这些依赖几乎从未被显式记录。数据漂移（输入分布偏离训练分布）、语料库新鲜度问题，或特征计算方式的悄然改变，都属于这一层。典型信号：输入发生了变化，输出正确地反映了这一变化。模型做的正是它被训练要做的事——只是用了不同的数据。

第三层：集成层

模型周边的产品侧逻辑出了问题吗？提示词注入、限流处理不当、上下文组装错误、兜底逻辑未被激活，以及功能解释模型输出的方式发生变化，都归属这一层。这通常由产品工程负责，却往往是最后被排查的地方，因为它只是"管道"。Zalando 的 AI 复盘分析系统就经历了一次典型的集成层故障：它把事故归因于复盘文本中提到的任何技术名词，产出了系统性错误的根因分析。模型本身没问题，是集成逻辑在做表面归因而非因果归因。

第四层：基础设施层

部署环境发生了变化吗？负载均衡配置、缓存行为、多区域故障转移、流量路由和扩缩容逻辑都在这一层。基础设施的变更对 ML 和产品团队往往是不可见的，这正是它导致最令人困惑的事故的原因。一份有据可查的生产事故记录显示，一次负载均衡变更在数周内悄然让某模型 16% 的请求劣化，直到人工审计发现了时序重叠，才将基础设施变更与质量回归联系起来。

每一层的诊断问题不是"谁来负责"，而是"这一层在事故窗口前后是否发生了变化或退化"。基础设施层发生了变化，不代表基础设施是罪魁祸首——它只是意味着基础设施是需要调查的相关层。

让诊断成为可能的审计日志

四层诊断的前提是，你能在事故发生时观测到每一层的状态。大多数 AI 监控关注的是聚合指标——错误率、延迟百分位数、吞吐量。这些指标衡量的是四层共同作用的集成输出，无法帮助你隔离哪一层出了问题。

加载中…