AI 轮值：当你的系统在“思考”时，该针对什么发告警

一个运行多智能体市场调研流水线的团队花了 11 天时间观察他们的系统正常运行——绿色的仪表盘、零错误、正常的延迟——而 4 个 LangChain 智能体却在无限循环中互相博弈。等到有人扫了一眼账单仪表盘时，这一周 127 美元的预估成本已经变成了 47,000 美元。这些智能体从未崩溃。API 从未返回过错误。每一个基础设施告警都保持沉默。

这就是 AI Oncall 的核心问题：你的系统在运维层面可以显示为绿色，但在其本应完成的任务上却发生了灾难性的失败。传统的监控旨在检测崩溃、延迟飙升和错误率。AI 系统可以在满足所有基础设施 SLO 的同时，悄无声息地产生错误输出、无限期地循环执行任务，或者在不产生任何有用结果的情况下消耗数千美元的计算费用。错误代码的缺失并不代表结果的正确。

为什么 AI 事故与众不同

当传统服务出现故障时，事故几乎肯定是由最近的某些变化引起的——一次部署、一次配置推送或一次依赖更新。你可以通过重放相同的请求来重现故障。你可以通过回滚直到错误消失来二分定位问题。

AI 事故打破了所有这三个假设。

非确定性使得重现变得不可靠。 同样的输入明天可能会产生不同的输出。当 OpenAI 在 2024 年 5 月回滚 GPT-4o 时（因为用户报告该模型变得极度“讨好”——验证阴谋论并赞扬欺诈性投资计划），这种检测并非来自内部监控，而是来自一个拥有 10,000 个点赞的 Reddit 帖子。模型没有崩溃，没有错误飙升。这种迎合模式无法按需重现；它是输出分布的一种统计特性。

设计层面的根本原因具有模糊性。 传统的调试会收敛到一个单一的缺陷。而 AI 调查则是在不孤立单一原因的情况下缩小嫌疑范围——模型提供商的更新、查询分布的偏移、提示词注入攻击，或者用户表达请求方式的变化，都可能产生相同的降级结果。你的运维手册（runbook）需要适应这种模糊性，而不是停滞不前直到确定性到来。

质量回归可能在没有任何部署的情况下发生。 即使你这边没有发生任何变化，AI 系统也可能降级：上游模型提供商悄悄更新了他们的基础模型，训练数据过时，或者随着新用户发现你的产品，查询分布发生了偏移。支撑每个传统事故调查的“最近发生了什么变化？”这个问题，可能根本没有答案。

事故在大规模运行中悄然积累。 SQL 注入会影响单个请求。而 LLM 中的行为回归在任何人工审核员看到模式之前，可能会影响数千个响应。从 2023 年到 2024 年，记录在案的 AI 安全事件增加了 56%，这主要是因为生产部署的规模扩大速度超过了检测能力。

真正重要的四类告警

在设计 AI Oncall 告警时，你需要覆盖四种不同的故障类别——并且你需要为所有这些类别准备工具。

1. 质量降级

这是最难检测也最重要的。你的系统返回 200 响应，延迟低于 200ms，但产生的输出却是错误的、有害的或无用的。

质量告警需要针对采样的生产流量运行自动化评估。在实践中行之有效的方法是：使用 LLM-as-judge，根据与你的用例相关的维度（事实准确性、任务完成度、格式约束遵循情况、无有害内容）对实时响应的随机样本进行评分。当这些分数偏离基准线超过两个标准差，或者当超过 5% 的采样响应低于定义的质量阈值时，触发告警。

这项投入是实打实的：据团队报告，他们花了六个月或更长时间来调整阈值，才使质量告警变得足够可靠，能够用于传呼而不是沦为噪音。与任何单一信号相比，多指标告警（结合响应质量、用户参与度代理指标和会话长度）可将误报减少约 40%。

对于 RAG 系统，增加忠实度评分（faithfulness scoring）——响应是否基于检索到的上下文，还是模型在超出来源支持的范围进行胡编乱造？这种告警能在语料库偏移变得对用户可见之前捕捉到它。

2. Token 预算异常

Token 消耗异常是最具操作性的 AI 特定信号之一，因为它们表明你的系统处理请求的方式在结构上出现了问题，而不仅仅是特定运行中的糟糕输出。

GetOnStack 事件是一个典型案例：上下文累积导致 Token 使用量从每个会话步骤 5,000 个增长到 80,000 多个。这 16 倍的增长率就是可检测的信号。当增长开始时，绝对成本还不算异常——但实际 Token 与预期 Token 的比率异常。

针对偏离预期 Token 消耗的情况进行告警，而不仅仅是绝对成本。如果你的系统平均每个请求消耗 1,000 个 Token，而一个会话消耗了 45,000 个，那么无论账单看起来是否令人担忧，都应该触发告警。

那次 4.7 万美元事故给出的关键教训是：告警需要人类响应。在基础设施层强制执行的硬性 Token 上限可以自动阻止成本失控。软性告警和硬性限制服务于不同的目的。在达到会话预算的 70% 时告警；在达到 100% 时终止。这种终止操作在凌晨 2 点不应需要任何人工干预。

3. 拒绝率偏差

拒绝率（Refusal rate）——即模型拒绝回答或过度回避请求的比例——是模型行为变化的主要指标。它应该作为一个指标进行跟踪，并在两个方向上都设置警报阈值。

拒绝率激增可能意味着：

• 模型提供商更新了他们的安全微调
• 提示词注入（Prompt injection）攻击触发了安全过滤器
• 最近的提示词更改无意中使请求看起来违反了政策

拒绝率下降通常更危险——这可能表明模型变得更加放任，倾向于那种触发 GPT-4o 回滚的“奉承性”（Sycophancy）。当模型很少拒绝时，在面对困难或对抗性问题时，幻觉率会激增。

按请求类别细分拒绝率。如果医疗类查询的拒绝率激增而其他类别的拒绝率保持稳定，这表明是特定类别的模型行为问题，而不是广泛的系统问题——每种情况都需要不同的应对措施。

4. 具有 AI 感知扩展的基础设施

标准的监控基础设施（延迟、错误率、可用性）仍然是必要的，但现在这只是底线，而非上限。专门针对 AI 的两项补充非常重要：

加载中…