AI 系统值班：当 Bug 是模型时的事故响应手册

你的监控显示一切正常。延迟处于正常水平。错误率平稳。然而，你的客服 AI 刚刚告诉 10,000 名用户退货是免费的——且是永久免费——而这根本不是公司的政策。没有触发任何报警。没有进行任何部署。模型只是自己决定这么做了。

这就是 AI 系统轮值（on-call）的现状：这类生产环境故障不会触发你构建的报警，无法追溯到某行代码，也无法通过回滚上一次部署来修复。标准的事件响应手册——检查日志、确定提交（commit）、回滚更改、验证恢复——是为确定性系统设计的。应用到 LLM 时，它们完全无法捕捉到真正的失败模式。

以下是真正有效的方法。

为什么你的操作手册（Runbook）会失效

传统的事件响应依赖于三个假设，而 LLM 违反了这些假设：

确定性（Determinism）：给定相同的输入，得到相同的输出。在 LLM 中，即使是相同的提示词，只要 temperature > 0，每次调用都可能产生不同的响应。如果你不捕获精确的参数——模型版本、temperature、top_p、seed 以及完整的对话历史——你就无法“重现问题”。即便捕获了这些，非确定性也意味着你是在重建一个概率分布，而不是重放一次崩溃。

显式失败信号（Explicit failure signals）：应用程序通过抛出错误来中断。而 LLM 是静默失败。幻觉（hallucination）、护栏绕过（guardrail bypass）或质量退化会生成一个带有有效 JSON 负载的 200 OK。你的错误预算（error budget）没有任何波动。损害会在暗处累积，直到人类察觉或下游系统根据错误数据采取行动。

回滚作为遏制手段（Rollback as containment）：当错误的部署导致事故时，回滚可以解决问题。但当上游模型供应商推送更新并改变了你的 LLM 行为时，通常没有回滚路径。你没有部署任何东西，模型却在你不知情的情况下发生了变化。

AI 事件需要一种不同的思维模型：你不是在调试崩溃，而是在检测概率系统中的行为漂移（behavioral drift）。

四种关键的事件类型

并非所有的 AI 事件都是一样的。区分它们会改变分诊方法和遏制措施。

**能力退化（Capability regression）**是指模型的输出质量下降——它不再遵循格式指令、语气发生转变、准确性下降或结构化输出损坏。这通常是由上游模型更新、引入歧义的提示词更改或微调权重漂移引起的。检测需要行为基线（behavioral baselines）：你需要在检测到变化之前，了解“正常”输出的样子。

**护栏绕过（Guardrail bypass）**是指安全过滤器失效或被绕过——无论是通过提示词注入（prompt injection）、对抗性输入，还是改变了拒绝阈值的模型更新。这一类别在 2025 年的 OWASP LLM Top 10 中上升到了第 2 位。这也是法律和声誉受损最严重的 AI 事件类别，真实案例包括聊天机器人幻觉出的政策在诉讼中产生了约束力。

**成本爆炸（Cost explosion）**是指智能体进入了非预期的死循环，或在没有自然终止条件的情况下进行了天文数字般的调用。2025 年 7 月发生的一起涉及编程智能体的事件中，在被人发现之前，11 天内累积了 47,000 美元的 API 成本——这并不是因为没有报警，而是因为报警配置的是每日支出汇总，而不是实时速率监控。当报警触发时，损失已经造成。

**延迟恶化（Latency degradation）**是 SRE 最熟悉的，但具有 LLM 特有的细微差别。需要跟踪两个独立的信号：首字时间（TTFT, time-to-first-token）是用户在流式传输开始前看到的等待时间；单 token 输出时间（TPOT, time-per-output-token）决定了此后响应流的速度。在这里，P99 延迟比平均值更重要——LLM 响应的尾部延迟通常比中位数差一个数量级，而这正是用户所记住的。

构建检测层

标准监控捕获你的系统是否正常运行。AI 监控则需要捕获你的系统行为是否正确——这是一个明显更难的问题。

**输出质量采样（Output quality sampling）**是生产环境中功能测试覆盖的最接近模拟。将百分之几的真实流量路由到一个轻量级评估器——可以是另一个模型或启发式算法——根据定义的标准对输出进行打分：响应是否扣题、是否遵循格式指令、是否包含必要的披露信息。关键是要持续进行，而不仅仅是在部署时。发布时看起来正常的质量信号，可能会随着上游模型的更新或提示词漂移的累积，在几周内逐渐退化。

**行为基线（Behavioral baselines）**为你提供比较的对象。在部署提示词更改之前，捕获具有代表性的输入样本及其预期的输出特征。将这些输出向量化（Embed），存储其分布，并在生产中使用余弦相似度（cosine similarity）检查来检测漂移。答案漂移（Answer drift）——即响应逐渐偏离历史输出——是最微妙的失败模式之一，也是在没有基线的情况下最难捕捉的模式之一。

**实时成本速率监控（Real-time cost rate monitoring）**与预算报警不同。如果你是在每日支出超过阈值时报警，你是在损失造成后才发现。相反，你应该计算一个滚动速率——每分钟 API 调用数或每分钟 token 数——并在该速率超过移动平均值的 3 倍时报警。到那时，你可以在它变成 47,000 美元的问题之前终止任务。

**拒绝率追踪（Refusal rate tracking）**是护栏状态的一个有用先行指标。拒绝请求的 LLM 往往会重复使用模板化短语（“我无法提供帮助”、“我无法做到”）。跟踪输出流中这些模板的频率，可以为你提供一个代理信号，说明你的护栏是否按预期运行——过度拒绝（安全方向的能力退化）和拒绝不足（护栏绕过）都会表现为异常。

分层诊断：隔离根本原因

当 AI 事故发生时，首要任务是确定是哪一层导致的。主要分为三个层级，每一层都需要不同的专业知识和修复手段。

模型层（Model layer） 指的是 LLM 本身——其权重、版本和采样参数。这一层的事故通常由上游供应商更新、微调退化（Fine-tuning regressions）或参数配置错误引起。要进行分层诊断，你需要使用完全相同的参数（模型版本、temperature、top_p、max_tokens，以及设定的 seed 和对话历史）来复现失败。如果你无法复现，说明你正在处理随机样本——你需要收集足够的样本以了解失败的概率分布。

提示词层（Prompt layer） 包含你的系统提示词和任何提示词工程代码。这是大多数团队拥有最高控制权且变更最频繁的地方。这一层的事故表现为与提示词修改相关的行为变化——即使是微小的措辞变化也可能不可预测地改变模型行为。提示词版本化——像对待代码一样通过 Git 历史、测试覆盖和分阶段发布来管理提示词——是让这一层变得可控的实践。如果没有它，你就是在试图调试一个没有变更日志的事故。

数据和检索层（Data and retrieval layer） 涵盖 RAG 流水线、向量数据库以及注入到提示词中的任何动态上下文。这一层的事故表现为幻觉激增或检索相关性下降。常见的诱因包括源文档过时、嵌入偏移（Embedding drift，即嵌入模型更改导致旧向量不再与新查询对齐）或向量数据库损坏。这一层往往监测不足——团队通常会对 LLM 调用进行埋点，但会忽略对检索步骤的监测。

在实践中，工具版本管理导致的生产环境智能体故障约占 60%——这一统计数据表明，基础设施层和数据层作为事故主要来源的可能性超过了模型层。

AI 事故严重性框架

标准的 SEV1-5 等级需要加入 AI 特有的触发条件。一个在技术上处于“在线”状态但在大规模产生幻觉的系统，即使没有服务宕机，也属于 SEV1 级事故。

严重程度	AI 特有触发条件	响应时间
SEV1	生产环境防护栏（Guardrail）被绕过、智能体执行未经授权的命令、成本实时超过基准 100 倍、PII 泄露	15 分钟
SEV2	影响超过 20% 流量的质量退化、成本达到基准 10-100 倍、核心能力不可用	1 小时
SEV3	P99 延迟超过基准 2 倍、影响小于 20% 流量的质量退化、成本异常达到基准 2-10 倍	4 小时
SEV4	孤立的质量下降、单用户问题、轻微的延迟波动	24 小时

关键的补充是 SEV1 中的成本率触发器。传统的 SRE 严重性框架关注用户影响和可用性。AI 系统引入了一种失效模式：服务在“正常运行”——成功生成响应——但却产生了灾难性的成本。

按事故类型采取遏制措施

遏制 AI 事故并不意味着“事故已结束”，而是意味着“故障不再扩散”。针对不同类型的操作有所不同。

对于能力退化，主要的杠杆是通过特性标志（Feature flag）进行提示词回滚。如果提示词经过版本化处理且版本历史清晰，你可以在几秒钟内切换回上一个已知良好的提示词，而无需重新部署。这就是为什么提示词版本化不是工程师的个人偏好，而是具备任何事故响应能力的先决条件。

对于防护栏绕过，立即行动是禁用受影响的功能并将用户引导至备选方案——人工接入、静态响应或更保守的模型配置。在调查根本原因时，降低 temperature（使模型更具确定性）和收紧系统提示词约束是临时缓解措施。

对于成本爆炸，遏制措施是设置一个紧急停机开关（Kill switch），停止针对受影响功能或用户细分的新 LLM 调用。这需要在事故发生前就实现，而不是在事故期间临时抱佛脚。单用户 Token 预算——在调用前执行，而不是通过账单警报在事后通知——是结构性的修复方案。

对于延迟劣化，响应取决于延迟是发生在模型层（增加超时容忍度、切换到更快的模型变体）还是检索层（减少检索深度、使用缓存响应路径）。

在事故发生前进行影子测试

发现行为退化的最佳时机是在它们触达生产用户之前。影子测试（Shadow testing）——在不向用户提供结果的情况下，针对真实生产流量运行新模型版本或提示词——能为你提供基准测试（Benchmarks）无法涵盖的覆盖范围。

这种做法在概念上很简单：在评估变更时，将 100% 的生产流量同时路由到旧配置和新配置。捕获两者的输出，并根据你的质量指标进行比较。只有在影子测试数据运行 7 到 14 天且未显示退化后，才晋升到 A/B 测试（即真实用户可以看到新版本的阶段）。

成本是实实在在的：在评估窗口期间，影子测试会让你的 LLM API 支出翻倍。但收益也是实实在在的：这种模式能捕捉到那些通过了所有单元测试和评估基准，但在没人想到的长尾生产输入中失败的微妙行为变化。

你的值班团队真正需要什么

AI 故障需要三种类型的专业知识，而这三种知识很少集中在一个人身上。AI 系统的值班轮换需要涵盖以下方面：

• 一名能够追踪请求、检查工具调用并排查基础设施和数据层问题的软件工程师
• 一名理解模型行为、能够解读评估 (eval) 结果，并知道如何在紧急情况下调整采样参数和提示词 (prompt) 的机器学习工程师
• 一名能够检查检索质量、审计向量数据库并验证嵌入 (embedding) 正确性的数据工程师

这对人员配置产生了影响。如果团队只安排一名软件工程师负责 AI 值班，那么有一半的故障领域将处于无人管辖的状态。软件工程师可以确认模型是否返回了响应，但他们通常无法判断响应是否错误，也无法在出错时诊断原因。

另一个影响在于文档。AI 故障的操作手册 (Runbooks) 需要涵盖传统手册不会涉及的问题：最后一个已知良好的提示词版本是什么？当前的模型版本是什么，上次更新是什么时候？该功能的基准质量分数是多少，当前分数又是多少？检索流水线是否返回了相关结果？这些问题必须能在凌晨 2 点由非机器学习博士回答——这意味着它们需要通过仪器化手段实现监控，而不是手动检查。

改变一切的转变

传统故障响应背后的思维模型是：某些东西坏了，找到导致损坏的变更，回滚该变更。这之所以有效，是因为传统系统是确定性的且可观测的。你可以通过现象推导出原因。

LLM 故障需要一种不同的思维模型：某些东西发生了偏移 (drift)，识别它在哪个层级发生了偏移，并采取相应的手段。其症状是行为上的，原因是概率性的，而修复方法通常是缩小输出的分布范围，而不是修复特定的 Bug。

能够出色处理 AI 故障的团队，都是那些及早接受了这种差异的团队。他们在需求出现之前就建立了行为基准，将提示词视为具有版本历史的可部署制品，对实时成本率而非每日摘要进行监控，并在值班中配置了具备多种专业知识的人员。这些都不是什么特别奇特的工程技术，只是将生产运营的规范应用到了一个与传统系统行为完全不同的系统上。