Wiki Notes

Appearance

真实告警样例专题 ​

版本：v1.2

最后更新：2026-07-08

适用对象：正在做 LLM 应用、RAG、Agent、多模态与审批系统，需要把“观测到了异常”真正变成“有人响应、能快速止血、能复盘回流”的平台、运营和值班同学

很多团队都知道“要做监控和告警”，但一到实际落地，最容易卡住的通常不是：

  • 指标能不能采集
  • 机器人能不能发消息

而是：

  • 到底什么值得报警
  • 报警阈值怎么设
  • 告警来了谁处理
  • 什么样的告警才算能指导动作
  • 处理完之后怎样沉淀成下一次更早发现问题的能力

OpenAI 当前 Production best practices、Evaluation best practices、Trace grading、Integrations and observability，以及 Google SRE 当前 Alerting on SLOs、Implementing SLOs、Postmortem analysis 的一手资料，在 2026-07-08 复核时都指向一个很明确的运维共识：

  • 告警的目标不是把异常喊出来，而是把少量真正值得行动的信号，以足够上下文的形式交给正确的人。

这篇专题不只讲“监控原则”，而是从真实 AI 系统里最常见的告警样例出发，讲清楚：

  1. 什么信号值得告警
  2. 一条高质量告警应该带哪些上下文
  3. 告警如何回流到评测、版本治理和事故复盘

1. 为什么 AI 系统更需要样例化告警 ​

AI 系统里，很多最糟糕的问题不会表现成：

  • 服务挂了
  • HTTP 500
  • 机器打满

更常见的是：

  • 质量退化
  • 输出漂移
  • 工具行为异常
  • 审批链卡住
  • 成本和时延异常

也就是说，很多最该报警的问题会表现为：

  • 接口返回 200
  • 但业务已经开始失败

这也是为什么 AI 告警如果只盯：

  • CPU
  • 内存
  • 500

通常远远不够。

更可执行的做法通常是：

  • 按“失败样例长什么样”去反推告警设计

这样做的价值在于：

  • 告警不是抽象指标，而是与真实事故形态对应

2. 一条“能处理”的 AI 告警，和一条“只会吵人”的告警有什么区别 ​

更有价值的告警通常同时满足三个条件。

2.1 它明确需要人处理 ​

例如：

  • 高风险工具调用量突然翻倍
  • 审批队列积压到 SLA 外
  • 某关键 workflow 成功率跌破阈值

2.2 它能定位到影响范围 ​

例如：

  • 哪个 workflow
  • 哪个 tenant
  • 哪个版本
  • 哪个模型、prompt、route 或工具

2.3 它能指向下一步动作 ​

例如：

  • 查看指定 trace
  • 回滚指定版本
  • 暂停某个工具
  • 切只读 / 转人工

如果告警只告诉你“系统异常”，但没有影响范围和处理入口，它更像噪音，不像运维资产。

3. 告警阈值不该靠拍脑袋，最好和基线、SLO、风险等级绑定 ​

Google SRE 当前 Alerting on SLOs 和 Implementing SLOs 的核心思想非常适合 AI 系统：

  • 告警应围绕真正重要的服务目标
  • 阈值需要兼顾 precision、recall、detection time、reset time

翻译到 AI 场景里，更实用的理解通常是：

  • 不是任何波动都要报警
  • 只有威胁到业务目标、风险边界或错误预算的波动，才该进入动作型告警

所以更稳的阈值来源通常是：

  • 历史基线
  • 版本对照
  • SLO / SLA
  • 高风险场景单独阈值

而不是：

  • “感觉这个数字差不多”

4. AI 告警更适合按失败类型分桶，而不是只按技术组件分桶 ​

传统系统很多告警按组件分就够了：

  • 数据库告警
  • 网关告警
  • 计算资源告警

AI 系统里，更有用的往往是按失败形态分桶。

例如：

  • 质量退化
  • 检索失真
  • 工具异常
  • 审批积压
  • 成本飙升
  • 实时体验恶化

原因很简单：

  • 组件视角回答“哪块出问题”
  • 失败形态视角回答“用户感知到什么问题、团队该怎么止血”

5. 真实告警样例一：成本突然飙升 ​

5.1 典型现象 ​

  • 单位时间 token 使用激增
  • 某高成本模型占比异常提高
  • 缓存命中率突然下降
  • 某类 workflow 平均成本短时间翻倍

5.2 常见原因 ​

  • 路由策略变更
  • prompt 变长
  • 检索 top-k 放大
  • 重试和 fallback 放大
  • 工具循环
  • prompt cache key 设计失效

5.3 更好的告警字段 ​

  • workflow 名称
  • model / route
  • prompt version
  • avg input / output / reasoning tokens
  • cached token ratio
  • 最近变更记录

5.4 典型处理动作 ​

  1. 先看是否是单一 workflow 放大。
  2. 再看是否与某次发布相关。
  3. 需要时先切轻模型、降 top-k、限重试。
  4. 再决定是否回滚 prompt / route。

5.5 这类告警最怕什么 ​

  • 只看到“今天更贵了”
  • 却看不到是哪条链路在烧钱

6. 真实告警样例二：高风险工具调用异常增多 ​

6.1 典型现象 ​

  • 某敏感工具调用次数短时间内激增
  • 原本低风险工作流开始频繁触发审批
  • 某类用户请求突然触发大量动作型调用

6.2 常见原因 ​

  • prompt injection
  • prompt 版本误鼓励工具使用
  • route 分类漂移
  • guardrail 阈值或策略失效

6.3 这类告警为什么必须和 trace 一起看 ​

团队真正需要知道的不是：

  • “工具多了”

而是：

  • 哪一类输入在触发
  • 经过了哪些中间步骤
  • 是否都来自同一版本
  • 是否已经误执行了高风险动作

6.4 更好的处理动作 ​

  • 暂停高风险工具自动执行
  • 切换到必须确认 / 审批模式
  • 拉取相关 traces 做失败分桶
  • 回流成 red-team 或 regression case

7. 真实告警样例三：检索命中率或引用质量下降 ​

7.1 典型现象 ​

  • 用户追问率明显上升
  • 引用质量下降
  • 回答看起来完整，但证据不对
  • 某个知识域失败样例明显集中

7.2 常见原因 ​

  • 索引更新异常
  • metadata 变更
  • rerank 或 query rewrite 改坏
  • 权限过滤导致召回被切空

7.3 更适合设置的告警信号 ​

  • retrieval hit rate
  • citation presence rate
  • citation validation failure rate
  • 某域问答失败率

7.4 这类告警的真正价值 ​

它能让团队尽早发现：

  • 问答质量问题未必是模型能力问题
  • 很可能是知识链路问题

8. 真实告警样例四：人工审批量异常增长 ​

8.1 典型现象 ​

  • 审批触发率大幅升高
  • 审批队列积压
  • 平均审批等待时间超出 SLA

8.2 常见原因 ​

  • guardrails 策略收紧
  • route 错误把大量低风险请求打进审批
  • “需确认”规则写得过宽
  • 审批人力没有及时跟上

8.3 这类告警的本质 ​

它往往不只是安全问题，而是：

  • 安全策略和业务流程耦合出了问题

8.4 更实用的处理动作 ​

  • 查哪类请求触发最多
  • 看是否集中在某版本或某 tenant
  • 必要时先切分级审批或只读降级

9. 真实告警样例五：实时系统延迟突然升高 ​

9.1 典型现象 ​

  • 首包延迟升高
  • turn 切换变慢
  • 中断后恢复异常
  • 语音播放开始明显变晚

9.2 常见原因 ​

  • 模型或路由策略变化
  • 工具执行变慢
  • 会话过长导致上下文膨胀
  • 背景任务堆积
  • 语音 / realtime 路由异常

9.3 更值得报警的指标 ​

  • p95 latency
  • first token / first audio latency
  • tool wait time
  • session length distribution

9.4 最容易漏掉的一点 ​

实时系统里，不是总时长最重要，而往往是：

  • 用户多久开始感觉“它慢了”

10. 真实告警样例六：评测回归分数跌破关键基线 ​

OpenAI 当前 Working with evals、Agent evals、Trace grading 都在强调：

  • 评测不只是离线实验，而应接进版本和发布流程

10.1 典型现象 ​

  • 某个关键评测桶分数跌破阈值
  • 高风险子场景回归失败
  • 新版本总分未退，但某个子桶明显退化

10.2 为什么它也应该是告警 ​

因为对企业平台来说，评测失败本质上就是：

  • “即将把异常带进生产”

10.3 更适合的处理动作 ​

  • 阻断发布
  • 触发人工复核
  • 回退到上一个稳定版本

11. 真实告警样例七：trace grading 暴露异常长链路 ​

这类告警是很多团队最晚补、但特别值钱的一类。

11.1 典型现象 ​

  • 某类 Agent 运行步数明显超出常态
  • handoff 频繁
  • 工具调用次数异常多
  • 成本和时延一起飙升

11.2 常见原因 ​

  • route 分类不准
  • 工具 schema 太松
  • fallback 和 retry 叠加
  • 任务终止条件不清

11.3 更好的告警字段 ​

  • trace id
  • step count
  • tool call count
  • handoff count
  • retry count
  • total reasoning / token cost

11.4 更适合的处理动作 ​

  • 抽样看异常 traces
  • 给异常长链路单独建 grader
  • 补 step limit / retry budget

12. 高质量告警至少要带哪些上下文 ​

一条高质量 AI 告警，至少建议带上：

  • 受影响 workflow
  • 受影响 tenant / 业务域
  • model / prompt / workflow / route version
  • 关键 cost / latency / quality 指标
  • 最近变更信息
  • 相关 trace / dashboard / runbook 链接

更高质量的做法还包括：

  • 自动附 3 到 5 个代表性失败样例

这样值班同学拿到后，不需要从零猜问题。

13. 告警最好分成观察、处理、紧急三层 ​

建议至少分成三层。

13.1 观察类 ​

适合：

  • 轻微波动
  • 还未超过动作阈值
  • 更适合 dashboard / 报表观察

13.2 处理类 ​

适合：

  • 需要工作时间内跟进
  • 已影响某类工作流或某类租户
  • 需要 trace 调查和责任人动作

13.3 紧急类 ​

适合：

  • 高风险动作异常
  • 大面积质量或时延故障
  • 审批链失效
  • 大租户或关键业务受影响

如果不分层，很容易出现：

  • 什么都报警
  • 最后什么都没人真正管

14. 告警处理完，真正的价值在回流 ​

最成熟的做法不是“告警解决完就结束”，而是把告警回流成：

  • 失败样例分桶
  • regression dataset
  • 新的 guardrail 规则
  • 新的基线和阈值
  • 新的 runbook

更实用的闭环通常是：

text
alert
 -> triage
 -> pull traces / samples
 -> bucket failure modes
 -> add eval cases
 -> fix / rollback
 -> update threshold / runbook / release gate

这样告警系统会越来越像知识资产，而不是重复打扰。

15. 常见反模式 ​

  • 只做基础设施告警，不做 AI 行为告警
  • 告警太多，没有 owner
  • 告警没有版本标签
  • 告警没有 trace 入口
  • 阈值完全靠拍脑袋，没有基线支持
  • 告警后不进入复盘与评测回流
  • 把“轻微波动”和“必须立刻止血”的问题混在一起

16. 推荐搭配阅读 ​

17. 重点官方资源 ​

以下入口在 2026-07-08 复查时可访问：

18. 落地检查清单 ​

  • 是否已经为质量、成本、安全、稳定性分别定义了动作型告警
  • 是否为关键阈值绑定了历史基线、SLO 或高风险红线
  • 是否在告警中携带 workflow、tenant、版本、trace、runbook 等关键上下文
  • 是否能区分观察类、处理类、紧急类，而不是全部混在一起
  • 是否能从告警中快速抽到代表性失败样例和 trace
  • 是否把处理结果回流到 eval、runbook、guardrail 和发布门禁