AI系统的事故复盘-从一次错答追到根因

摘要传统系统的事故通常有清晰的因果链某个服务挂了、某个配置错了。AI 系统的事故往往模糊得多——用户说答错了而系统看起来一切正常没有报错、延迟正常、日志完整。从答错了追到根因需要的不是更聪明的推理而是更完整的留痕与一套固定的定位流程。本文拆解四类常见根因、复盘必须依赖的三类数据、定位的标准路径以及把结论变成防线的四个动作。2026 奇点智能技术大会11 月 20-21 日 · 北京万达文华酒店将讨论 AI 工程实践与可靠性。一、AI 事故的四类根因把常见事故归类根因通常落在四类之一。根因类别典型表现定位难度常见触发输入侧用户给了模糊/异常输入低边界输入、多语言混杂上下文侧关键信息被截断或污染中上下文管理策略缺陷模型侧模型换代或参数漂移中升级未做充分回归集成侧解析失败、工具错误、缓存串味高上下游契约不一致第四类定位最难因为问题不在 AI 组件本身而在它与周边系统的接缝处。而接缝恰恰是最少被监控的地方。二、复盘依赖的三类留痕没有数据复盘就只能靠猜。三类数据必须留存第一类完整调用记录。包括调用方标识、模型版本、提示词版本、路由决策、实际使用的参数temperature 等、耗时、token 消耗。缺任何一项都可能让复盘卡住。第二类输入输出内容。在合规允许范围内留存原始输入与输出用于复现。只存摘要或指标事后无法还原现场。第三类中间步骤。对智能体系统尤其关键每一步的工具调用、返回结果、以及模型的中间判断。没有中间步骤就无法定位是哪一步走偏。留痕完整度自查 · 能否还原某次请求使用的确切提示词 · 能否看到当时模型返回了什么 · 能否知道中间调用了哪些工具、返回了什么 ↑ 任一为否复盘就只能靠运气三、定位的标准流程建议固定为五步避免复盘变成自由讨论。第一步复现。用留痕数据重放请求确认问题可复现。如果无法复现先解决留痕不足的问题——这也是一条重要结论。第二步定位层级。判断问题出在哪一层输入、上下文、模型、还是集成。方法是从两端往中间排查先看最终输出是否异常再看中间步骤最后看输入。第三步确定触发条件。是个例还是一类找出共同特征——某类用户、某类输入、某个时间段、某个模型版本。第四步追到机制。不只要知道发生了什么还要知道为什么会发生。例如上下文截断导致关键信息丢失比模型答错了更有价值。第五步评估影响面。有多少请求受影响是否持续是否需要通知用户defreplay(request_id,store):复现示意按留痕还原一次完整调用用于定位。recstore.get(request_id)return{prompt:store.prompt_version(rec.prompt_id),model:rec.model_version,params:rec.params,steps:store.tool_calls(request_id),output:store.output(request_id),}四、把结论变成防线复盘的价值在于防线不在于报告。四个动作动作一加监测。针对根因加一个可观测的指标。例如根因是上下文截断就加一个截断发生率指标。能被观测的问题下次会被更早发现。动作二加拦截。在问题发生前拦住它。例如输入侧问题加输入校验与提示改写。拦截优于告警。动作三加用例。把这次的问题加入回归测试集。这是防止复发的成本最低手段。动作四改设计。如果同一类问题反复出现说明设计有缺陷需要结构性调整而不是继续打补丁。防线的有效性排序改设计 加拦截 加用例 加监测 ↑ 越靠前越根本也越难做到五、三个常见误区误区一把事故归因于模型不稳定。这是一个无法行动的结论。模型行为确实有随机性但大多数事故背后都有具体机制——参数、上下文、集成。归因到模型就这样等于放弃改进。误区二只修现象不修机制。例如发现答错了就加一条提示词约束而不去查为什么这条约束原本缺失。补丁会越来越多系统越来越难理解。误区三复盘不跟踪。报告写完、改进项列出然后没有跟进。改进项必须有责任人与期限并在下次评审时回顾。六、一份精简的复盘模板建议固定包含六项现象用户侧看到了什么影响范围、时长、严重程度时间线从发生到发现到恢复的关键节点根因机制层面的解释不是现象描述改进项具体动作、责任人、期限遗留风险本次未解决、需要持续观察的部分第六项常被省略但它决定了下次复盘是否需要从头开始。把已知但未解决的问题记录下来是团队积累的关键。七、复盘文化的三个前提复盘机制能否持续取决于文化而不只是流程。三个前提值得建立。前提一对事不对人。如果复盘会变成追责会参与者会隐藏信息复盘结论就会失真。明确不复盘个人失误只复盘系统缺陷是机制可持续的前提。前提二允许暴露不确定性。很多时候根因无法一次查清。允许记录暂时无法确定并持续跟踪比强行给出一个结论更诚实也更有用。前提三改进项必须闭环。每次复盘开始时先回顾上次改进项的完成情况。这一条动作能显著提升改进项的实际完成率。复盘的敌人追责氛围、强行结论、有始无终 复盘的支撑完整留痕、固定流程、改进闭环八、读者问答问小事故也需要复盘吗可以按轻量流程处理但值得记录。很多大事故在发生前都有过小的先兆只是没有被记录。问复盘要花多长时间一次中等复杂度的复盘通常一到两小时加上准备时间。超过这个时长往往说明留痕不足导致大量时间花在还原现场上。问如何判断复盘是否有效看两个信号同类事故是否重复发生、改进项是否按期完成。两个信号都不好说明复盘流于形式。问没有事故时还需要演练吗需要。定期演练能验证留痕是否足够、定位流程是否顺畅。等到真事故发生才发现留痕缺失代价太大。九、留痕的合规与隐私边界留痕是复盘的前提但留痕本身也带来风险。三个边界需要明确。其一是留存期限。不同数据的合理留存期不同调用元数据可以留较久输入输出内容应设较短期限。无限期留存既没必要也不合规。其二是脱敏规则。个人标识信息在写入日志前应脱敏但要保留可用于定位的结构信息。完全脱敏会让日志失去复盘价值需要在两者之间取得平衡。其三是访问权限。事故复盘需要访问原始内容但这类访问应当受限并可审计。权限不加控制的日志系统本身就是风险源。defredact(payload,rules):脱敏保留结构与类型信息替换敏感值。out{}fork,vinpayload.items():ifkinrules.pii_fields:out[k]f{type(v).__name__}:{len(str(v))}# 保留类型与长度else:out[k]vreturnout保留类型与长度是一个实用技巧它足以支撑大部分复盘判断又不会保留原始敏感内容。十、读者问答问复盘需要保存全部输入输出吗不需要也不应该。建议全量保存元数据输入输出按比例采样或按异常条件保存。异常样本的全量留存价值最高。问留痕会不会影响性能同步写入会有影响建议异步落盘并接受极少量丢失。复盘需要的是统计意义上的完整性不是绝对不丢。问日志系统与追踪系统的关系日志回答发生了什么追踪回答经过哪些环节。AI 系统两者都需要——只有日志时无法定位链路只有追踪时无法还原内容。问如何验证留痕是否够用定期做一次盲复盘演练随机选一次历史请求尝试仅凭留痕还原现场。还原不了的地方就是留痕的缺口。十一、最后几个问题问复盘结论需要对外公开吗视组织文化而定。至少应在团队内公开并归档只对内可见的复盘也能积累价值关键是持续。问AI 事故与传统事故的处理有何不同最大的不同是看起来正常但结果错误这类情况没有明确告警信号需要依赖质量指标发现。问如何降低事故发生的概率三个方向缩小变更粒度、加强变更前验证、以及保留快速回退能力。第三项在 AI 系统里尤其重要。十二、衔接大会专题问复盘报告应该保存多久至少一年。历史复盘是最有价值的知识库能让新成员快速理解系统曾经的失败模式与应对方式。问没有造成损失的事故需要复盘吗值得。未遂事故往往揭示了系统的真实脆弱点且成本为零——这是最便宜的学习机会。问复盘能否外包给工具自动完成工具可以自动生成时间线与指标变化但根因判断与改进决策仍需人来做。自动化的价值在于准备材料不在于替代判断。11 月 20-21 日北京万达文华酒店2026 奇点智能技术大会将讨论 AI 工程实践、可靠性与可观测性C 及系统软件技术大会则从故障定位、日志与追踪角度给出底层方法论。带着我们的系统能不能还原任意一次请求的完整现场这个问题的答案去参会会立刻知道复盘能力处在什么水平。大会信息2026 奇点智能技术大会 C 及系统软件技术大会时间2026 年 11 月 20-21 日地点中国·北京万达文华酒店大会报名点击报名领取大会PPT资料立即报名锁定 Lukasz Kaiser Keynote 与 70 场演讲完整资料