跳到主要内容

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

· 阅读需 11 分钟
Tian Pan
Software Engineer

你的监控看板显示延迟升高,错误率小幅上升,然后归于平静。用户已经在 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 校验、输出过滤和基于置信度的路由可以在调查并行进行的同时遏制降级。

加载中…
References:Let's stay in touch and Follow me for more thoughts and updates