AI 事故响应手册：为什么你的值班 Runbook 对 LLM 不管用

你的监控看板显示延迟升高，错误率小幅上升，然后归于平静。用户已经在 Slack 里投诉了。你的 AI 功能有四分之一的响应在产生幻觉，而这些幻觉在你的告警系统眼中看起来完全正常。等你找到原因——两小时前上线的一个提示词里改了六个字——一场你的 Runbook 从未预料到的慢燃事故已经结束了。

这就是在生产环境中运营 AI 系统的核心挑战。这些故障模式真实存在、危害显著，却对传统工具完全隐形。一个在悄悄产生幻觉的 LLM，从外部看和一个运行正常的 LLM 毫无区别。

你现有的值班手册是为确定性系统构建的。一个服务要么返回 200，要么不返回。一条数据库查询要么成功，要么抛出你可以 grep 到的异常。整套事故响应机制——告警、Runbook、升级路径、事后分析——都建立在一个假设之上：故障会留下可追溯的痕迹。

AI 系统彻底打破了这个假设。

你的值班假设在四个维度上失效

非确定性是第一个问题。 同一条提示词在上午 9 点可能返回正确答案，在 9:15 就可能返回幻觉。故障无法可靠复现。当你的值班手册写着"上报前先在 Staging 复现问题"时，这一步对于 LLM 故障来说可能根本做不到。系统在设计上就是随机的。

没有错误码是第二个问题。 一个 500 错误会告诉你有东西坏了。一个幻觉返回 200，带着一个结构完美的 JSON 载荷。你的错误率指标看不到任何异常。你的延迟指标也看不到任何异常。唯一的信号在于响应的内容本身——而你的基础设施层根本不知道如何检查内容。

排查矩阵是错的。 当一个服务挂掉，你知道去哪里看：部署、依赖、基础设施。对于 AI 系统的质量下降，根本原因可能属于四个完全不同的类别——每一个都需要不同的团队、不同的工具和不同的修复方案：

• 模型：底层模型发生了漂移，被悄悄更新，或者在你特定的输入分布上表现出不同的行为。
• 提示词：最近的提示词变更删除了某些上下文，而这些上下文原本隐式地锚定了模型的事实基础。
• 数据：进入系统的输入分布发生了偏移——你现在收到的查询模式是系统当初没有为之设计的。
• 基础设施：API 速率限制、延迟尖峰或服务提供商侧的降级导致重试和级联故障。

间歇性让情况更糟。 一个 30% 概率触发的 bug，如果你没有监控正确的质量指标，几乎无法被阈值告警检测到。而大多数团队并没有这样做。

构建 AI 事故排查决策树

AI 事故前十五分钟的目标不是修复问题——而是正确判断你处于上述四个类别中的哪一个。每个类别有不同的负责人、不同的工具和不同的修复路径。

第一步：排除基础设施问题。 检查 API 可用性、请求队列深度、延迟百分位数和超时率。基础设施故障往往产生一致性故障（而非间歇性），在地理上成簇分布，并且通常与服务提供商的状态页相关联。如果你的错误率确实升高（不只是质量下降）且模式一致，从这里开始排查。

第二步：检查模型变更。 查看当前部署的模型版本。许多团队使用浮动别名（如 gpt-4）而非固定版本（如 gpt-4-turbo-2024-04-09）进行部署。浮动别名可能会收到提供商的静默模型更新——模型漂移大约占生产环境 Agent 故障的 40%。将你的事故时间线与近期模型版本变更进行交叉比对。

第三步：检查提示词变更。 拉取你的提示词模板的部署历史。如果一个提示词在事故开始前两小时内有过变更，那就是你的首要嫌疑对象。比较不只是语法层面的——六个字的删除就能在剩余文本看起来完全相同的情况下，显著改变模型行为。

第四步：检查输入分布漂移。 计算近期输入的语义嵌入，与你的历史基线进行比较。如果分布发生了偏移——新的意图模式、不寻常的查询类型、你以前没见过的流量来源——你可能处于数据驱动的故障模式中，模型正在被要求处理它从未被校准过的内容。

不需要找到根本原因的止血措施

这是最反直觉的一点：你应该能在不知道原因的情况下就止住出血。

在确定性系统中，你通常需要理解故障才能缓解它。在 AI 系统中，你有几个钝器可以立即减少损害：

提示词回滚是你最快的选项。如果你的提示词模板有版本控制（你应该有），回滚到上一个版本是一个不需要代码部署就能在一分钟内完成的操作。这就是为什么提示词部署与代码部署解耦很重要——你的值班工程师应该能在不触碰应用程序的情况下回滚提示词。

模型版本固定是你第二快的选项。如果事故与模型变更相关，固定到最后一个已知良好的版本。浮动别名在开发中很方便；在生产环境中它是一个可靠性负担。

AI 功能的功能开关给你一个熔断器。你可以在几秒内完全关闭 AI 功能或将流量路由到降级路径。有趣的是，71% 的企业没有针对生产 AI 的书面降级计划——这意味着当他们的 AI 功能出故障时，他们没有预先规划的降级方案。这应该在你发布 AI 功能之前就成为一等关注点，而不是在它出故障之后。

输出层的护栏即使在你不知道根本原因的情况下也能减少损害范围。更严格的 Schema 校验、输出过滤和基于置信度的路由可以在调查并行进行的同时遏制降级。

监控真正重要的指标

如果你只监控 AI 系统的延迟和错误率，你是在盲飞。以下是能检测 AI 特定事故的指标：

幻觉率是最关键的。根据你的领域，商业 LLM 的基线幻觉率从 15% 到超过 50% 不等。重要的不是绝对值——而是与你已建立基线的差值。两小时内从 4% 跳升到 22% 是一个事故；稳定的 12% 可能只是你系统的正常运行范围。

拒绝率告诉你安全设置何时发生了漂移。太高意味着你的模型在拒绝合法请求。太低意味着安全性在侵蚀。分别追踪原始拒绝率和误拒绝率。

结构化输出合规率能快速捕捉提示词回归。如果你的模型应该返回符合特定 Schema 的 JSON，追踪响应的合规百分比。突然下降几乎总是提示词回归或模型更新的信号。

与基线的语义相似度衡量近期输出在统计上是否与历史良好输出相似。这计算成本更高，但能捕捉更简单指标遗漏的质量下降——对于自由形式的生成任务特别有用。

输入分布嵌入在你的流量漂移向分布外领域时给你早期预警。建立每周基线，当当前分布超过发散阈值时触发告警。

用户反馈信号是最直接的质量指标，也是最未被充分利用的。点赞率突然下降或"这个答案是错的"反馈激增，通常是 AI 事故的第一个信号——往往在你的自动化指标检测到任何异常之前。

随机性系统的事后分析

标准的事后分析模板假设你可以重放事故。对于 AI 系统，这个假设不成立。你需要扩展事后分析格式来容纳不可复现的故障。

明确记录间歇性。 不要写"系统在下午 2:15 出现故障"，而要写"下午 2:15 到 3:42 之间，28% 的请求返回了幻觉响应"。这种表述更准确，对未来分析也更有用——它捕捉到了故障是概率性的而非二元的。

添加根本原因类别字段。 明确分类事故属于模型、提示词、数据还是基础设施。这迫使事后分析作者做出明确分类，而不是写出"AI 表现异常"之类的模糊语言。

记录事故期间的质量指标。 幻觉率是多少？结构化输出合规率是多少？这些数字应该出现在事后分析中，就像 p99 延迟出现在传统事后分析中一样。如果你没有这些数字，"为什么我们没有更早发现"这个部分就自己写出来了。

撰写考虑随机性的行动项。 传统行动项是"修复这个 bug"。AI 事后分析的行动项可能是："添加幻觉率监控，设置 5% 尖峰告警阈值"或"在 CI 中要求对所有提示词变更进行语义相似度评估"。重点不是消除随机性——那是不可能的——而是让降级更快变得可见。

添加一个聚焦于评估缺口的"为什么没被发现"章节。 最常见的答案是没有在生产环境中运行实时检查输出质量的评估。明确点出这个缺口会产生填补它的压力。

运营就绪检查清单

在将 AI 功能发布到生产环境之前，以下内容应该已经就位：

• 所有提示词模板都有版本控制，可以独立于应用程序代码进行回滚。
• 模型版本固定到具体的发布标识符，而不是浮动别名。
• 每个 AI 驱动的功能都存在功能开关，并定义了降级路径。
• 幻觉率、拒绝率和结构化输出合规率已完成仪表化，有基线值和告警阈值。
• 专门针对 AI 功能的值班 Runbook 记录了四类排查路径。
• 至少一种优雅降级模式经过测试——通常是返回缓存数据、简化响应或路由到非 AI 路径。

大多数团队在功能上线后才在第一次事故后补建 Runbook。这行得通，但意味着第一次事故是你的学习练习。这堂课的代价因领域而异——对于客服聊天机器人是令人尴尬的，对于医疗摘要工具则可能是危险的。

未来走向

SRE 这个学科正处于重大扩张之中。AI 系统的可靠性工程需要所有经典技能——值班轮换设计、事后分析文化、Runbook 维护——加上一套新的领域特定能力：评估基础设施、语义监控、提示词生命周期管理和模型漂移检测。

走在前面的团队在需要之前就构建评估基础设施。他们在系统健康时建立质量基线。他们在没有事故压力时撰写 AI 专属 Runbook。他们以和对待应用程序版本管理同等的严格程度对待模型版本管理。

没有走在前面的团队在最糟糕的情境下发现这一切：凌晨两点，试图向利益相关者解释为什么 AI 功能在产生错误答案，以及为什么他们的监控显示一切正常。