08-SLO、错误预算与事故复盘¶
核心目标：让 AI 系统设计从“能画架构图”升级到“能把系统稳定地跑在生产上”。
图源：Wikimedia Commons - Develstages.svg，Public domain。当前主图只用于辅助说明“阶段推进、门禁、灰度与回滚”的发布治理节奏，不是 SLO 官方定义图。
一、为什么这章重要¶
很多候选人能讲清模型、检索和推理链路，但一旦面试官继续追问下面这些问题，层级就会立刻拉开：
- 线上服务的 SLO 怎么定义
- 错误预算快耗尽时，为什么还敢不敢继续发版
- 新模型效果更好但稳定性更差时，如何灰度和回滚
- 幻觉率、引用缺失率、工具误调用率算不算事故
- 一次 AI 事故复盘，除了技术根因，还要补哪些流程和监控
真正成熟的 AI 系统设计，不只看“能不能做出来”，还看“能不能长期稳定、可控地跑下去”。
二、先分清 SLI、SLO、SLA 与错误预算¶
| 概念 | 你要怎么理解 | 例子 |
|---|---|---|
SLI | 可观测的服务指标 | P99 延迟、回答成功率、引用覆盖率 |
SLO | 团队给自己的目标线 | 月可用性 >= 99.9%，P99 < 3s |
SLA | 对外承诺或合同约束 | 企业客户合同中的可用性承诺 |
Error Budget | 在一个周期内允许消耗的“不稳定额度” | 若月 SLO 为 99.9%，错误预算就是 0.1% |
错误预算最常见的计算方式：
这 43.2 分钟不是“鼓励你把系统搞挂”，而是告诉你：发布节奏、变更风险和稳定性治理必须围绕这笔预算来决策。
三、AI 系统至少看三类指标¶
AI 服务不能只看“HTTP 200 有没有返回”。很多时候，服务还活着，但输出已经不可用。
3.1 可靠性指标¶
| 指标 | 常见口径 | 适用场景 |
|---|---|---|
| 可用性 | 请求是否成功返回 | 所有在线服务 |
| P95 / P99 延迟 | 尾延迟是否失控 | RAG、Agent、推理 API |
| 错误率 | 5xx、超时、模型池不可用 | 所有在线服务 |
| 吞吐 / 队列深度 | 是否出现排队积压 | 推理网关、批处理队列 |
3.2 AI 质量指标¶
| 指标 | 你在衡量什么 | 典型场景 |
|---|---|---|
| Faithfulness / 引用忠实度 | 回答是否真的基于证据 | RAG、企业知识问答 |
| 任务成功率 | Agent 是否完成目标任务 | Agent / Workflow |
| 工具调用成功率 | 工具是否被正确调用并返回可用结果 | Agent |
| 幻觉率 / 错答率 | 返回内容是否存在明显事实错误 | LLM 应用 |
| 违规命中率 / 漏放率 | 安全策略是否失效 | 审核、安全、内容平台 |
3.3 资源与成本指标¶
| 指标 | 你在衡量什么 | 典型场景 |
|---|---|---|
| GPU 利用率 | 算力是否真正被吃满 | 推理服务 |
| 单请求成本 | 每次调用花了多少钱 | API、Agent、多模态 |
| Token 消耗 | 长上下文和多步推理成本是否可控 | LLM、Agent |
| 缓存命中率 | 缓存是否真正减少了成本和延迟 | RAG、推理服务 |
四、不同 AI 系统的 SLO 示例¶
下面这些数字不是固定答案，重点是你要知道不同系统的目标口径不同。
4.1 RAG 问答系统¶
Text Only
基础目标：
- 月可用性 >= 99.9%
- P99 延迟 < 3s
- 5xx / 超时 < 0.2%
质量目标：
- Recall@5 >= 0.90
- Faithfulness >= 0.85
- 引用缺失率 < 2%
成本目标：
- 单请求平均成本受控
- 缓存命中率持续达标
4.2 Agent 系统¶
Text Only
基础目标：
- 月可用性 >= 99.5%
- 任务超时率 < 1%
质量目标：
- 任务成功率 >= 80%
- 工具调用成功率 >= 95%
- 危险动作误执行率 = 0
治理目标：
- Prompt Injection 检出率持续达标
- 错误循环平均步数受控
4.3 LLM 推理服务¶
Text Only
基础目标：
- 月可用性 >= 99.95%
- 首 token 延迟与完整响应延迟都要有目标线
资源目标：
- GPU 利用率保持在合理区间
- OOM 率维持在极低水平
- 单千 token 成本持续下降或受控
五、错误预算如何指导发布¶
错误预算的价值，不是做一张好看的周报，而是直接影响变更纪律。
| 预算消耗状态 | 发布策略 | 团队动作 |
|---|---|---|
0% - 25% | 正常发布 | 正常灰度、正常迭代 |
25% - 50% | 谨慎发布 | 提高灰度门槛，补监控 |
50% - 75% | 收紧发布 | 只发高优先级修复 |
75% - 100% | 冻结高风险变更 | 以恢复稳定性为主 |
> 100% | 停止功能发布 | 事故复盘、专项治理、补偿修复 |
AI 服务里常被低估的高风险变更包括：
- 更换主模型或推理参数
- 更换 embedding / reranker
- 修改系统 Prompt、Agent 路由或工具策略
- 更改批处理、缓存或量化策略
- 调整召回阈值、引用策略或安全阈值
这些改动未必会直接打挂服务，但很可能先把质量和成本打穿。
六、AI 事故复盘和普通 Web 复盘有什么不同¶
AI 事故不能只按“服务挂没挂”来分。
6.1 基础设施事故¶
- 模型池不可用
- GPU 节点异常
- 向量库、Redis 或网关故障
6.2 质量事故¶
- 检索结果明显劣化
- 引用缺失或错引
- 幻觉率明显上升
- reranker 失效导致答非所问
6.3 行为事故¶
- Agent 调错工具
- 参数校验失效
- 死循环或危险动作未拦截
6.4 成本事故¶
- Token 用量暴涨
- 缓存整体失效
- 小模型流量异常切到大模型
所以复盘模板里至少要写清楚：
- 影响范围
- 指标变化
- 临时止血动作
- 技术根因
- 流程根因
- 需要新增的监控和门禁
七、面试里可以直接复述的回答¶
Text Only
我会把 AI 服务的稳定性目标拆成三层：
第一层是基础可靠性，比如可用性、延迟、错误率；
第二层是 AI 质量，比如 Faithfulness、任务成功率、工具调用成功率；
第三层是资源与成本，比如 GPU 利用率、缓存命中率和单请求成本。
SLO 不是写在文档里就结束了，它要通过错误预算反向约束发布策略。
如果预算消耗过快，我会冻结高风险变更，优先恢复稳定性，再决定是否继续灰度或回滚。
复盘时我不会只写“谁操作错了”，而是会同时追技术根因、流程根因和监控缺口。
这样下一次类似问题才不会重复发生。
八、自检清单¶
- 我能解释
SLI / SLO / SLA / Error Budget的区别 - 我能为
RAG / Agent / 推理服务分别给出 3-5 个核心指标 - 我知道错误预算如何影响发布、灰度和回滚
- 我知道 AI 事故除了基础设施，还有质量、行为和成本事故
- 我能给出一份最小可用的事故复盘模板
结论¶
AI 系统设计到高阶阶段，考的已经不是“系统能不能跑”，而是“系统能不能长期稳定、可控地跑”。
SLO + 错误预算 + 事故复盘能力，就是把你和只会讲模型、讲架构图的候选人拉开差距的关键。
⚠️ 核验说明（2026-03-29）：本页已重新复核术语、示例口径与图片来源。若你所在团队已有更严格的 SLO / SLA 制度，请以团队定义为准。
最后更新日期： 2026-03-29