事故响应与持续改进
本节目标
在LLM应用发生质量、安全、费用或供应商故障时，先保护用户和保留证据，再定位到Prompt、上下文、检索、模型、工具或策略的具体变化。
LLM事故不只是5xx
以下情况都可能是事故：
- 服务返回200，但大量事实错误或无根据答案；
- 工具参数格式正确，却越权查询或重复写入；
- Prompt injection让系统暴露不应显示的上下文；
- 供应商或网关重试导致费用或队列爆发；
- 检索快照未更新，系统稳定返回过期政策；
- 观测管线丢弃关键spans，导致无法判断影响。
事故分级应从用户影响、数据/安全后果、可逆性、影响范围和持续时间出发，而不只看HTTP错误率。
前30分钟的原则
- 声明事故与负责人：记录开始时间、已知影响、指挥者和沟通渠道。
- 遏制：停止Canary扩大，禁用高风险工具、切换只读/人工流程或回滚完整manifest。
- 保留证据：冻结release、发布清单和candidate gate的完整SHA-256摘要、网关路由、策略、检索快照、评测报告、脱敏Trace引用和供应商请求ID；短指纹只可辅助人读，不能独自绑定事故证据。
- 评估范围：用受控元数据按时间、release、任务、租户或地区分组，不为统计便利扩大敏感数据访问。
- 沟通已知事实：区分已证实影响、调查中假设和尚未知道的范围。
不要在证据保存前批量清理日志或覆盖快照。也不要为查故障临时开启全量敏感Prompt记录，这可能创造第二个事故。
按组件分诊
| 证据 | 首先检查 | 不应直接得出的结论 |
|---|---|---|
| 新release才出现回归 | manifest差异、缓存隔离、路由 | 一定是模型变差 |
| 所有release都出错 | 供应商、共享网关、数据源、共享工具 | 回滚应用就能修复 |
| 只有有检索的请求错 | 索引快照、权限过滤、Chunking、Reranker | Prompt需要重写 |
| 工具写入重复 | 重试、超时、幂等键、工具实现 | 模型“太积极” |
| 费用突增 | Agent循环、重试、缓存命中、输出长度、价格版本 | 只是用户变多 |
指标变化是线索，根因需要时间线、版本差异和可验证假设支持。
恢复与验证
修复前先定义“恢复了”的证据：关键路径冒烟测试、用户SLI、工具副作用审计、质量/安全样本和观测完整性。回滚成功的控制面状态不等于用户影响已停止。既已写入的外部副作用还需要查找、撤销或通知。
恢复时渐进增加流量，确保监控本身正常，避免从“全降级”一步返回满负载。
复盘如何进入工程闭环
无责复盘聚焦系统如何容许失败发生和扩大，但仍需明确责任边界和行动项所有者。有效输出包括：
- 基于证据的时间线和根因/促成因素；
- 为何离线门、Canary或告警没有提前拦截；
- 需要人工分诊、脱敏、去重、许可与最小复现后才接纳的新回归样本，以及新的断言、运行手册或自动化遏制；
- 可验证行动项，例如“为写工具添加幂等键契约测试”，而不是“以后更小心”；
- 改进何时和如何被演练。
练习与自测
情景：新release上线后费用翻倍，总请求数不变，工具写入重复上升，部分Trace显示模型调用重试。写出前30分钟的遏制、证据保存、范围评估和恢复验证。然后回答：
- 哪些证据支持回滚，哪些还只是相关线索？
- 为什么只回滚模型可能无法停止重复写入？
- 这次事故应生成哪些新回归样本和合同测试？
小结与下一步
事故响应的成功不是“不再报错”，而是用户风险受控、证据完整、服务被验证恢复，且教训经受控接纳后进入回归集和发布策略。参照 离线到线上证据交接与回归闭环 的角色边界，再通过 离线发布门项目与自测 整合本库内容。
参考资料
- NIST SP 800-61 Rev. 3（发布于 2025-04，访问于2026-07-21）
- NIST AI RMF: Generative AI Profile（访问于2026-07-21）
- Google SRE: Postmortem Culture（访问于2026-07-21）