08-SLO、错误预算与事故复盘¶

核心目标：让 AI 系统设计从“能画架构图”升级到“能把系统稳定地跑在生产上”。

一、为什么这章很重要¶

很多候选人能讲清：

• 模型怎么选
• 检索怎么做
• 推理怎么优化

但一旦面试官追问下面这些问题，就明显掉层级：

• 线上服务的 SLO 怎么定义？
• 错误预算耗尽后怎么处理？
• 新版本上线为什么敢放量？
• 幻觉率上升算不算事故？
• GPU OOM 或检索劣化时，怎么回滚和复盘？

真正高质量的 AI 系统岗位，不只看“能不能做出来”，还看“能不能稳定地跑、出事后能不能处理”。

二、基础概念¶

这一节先把面试里最容易混淆的几个词拆开，后面所有发布、回滚和事故判断都建立在这里。

2.1 SLI、SLO、SLA¶

一句话理解：

• SLI 是量化指标
• SLO 是目标线
• SLA 是对外承诺线

2.2 错误预算（Error Budget）¶

错误预算 = 100% - SLO

例如：

• SLO：月可用性 99.9%
• 错误预算：0.1%

若按 30 天计算：

30天 = 43,200 分钟
错误预算 = 43,200 × 0.1% = 43.2 分钟

这 43.2 分钟就是本月允许你“出问题”的总额度。
一旦预算快耗尽，发布节奏和变更策略就必须收紧。

三、AI 服务的 SLI 应该怎么定义¶

AI 系统不能只看“服务有没有活着”，还要看“输出有没有价值”。
因此通常需要分成 3 层：

3.1 基础可靠性 SLI¶

3.2 AI 特有质量 SLI¶

3.3 资源与成本 SLI¶

四、不同 AI 系统的 SLO 示例¶

不同系统的 SLO 口径差异很大，重点不是背数字，而是知道为什么同样叫“可用”，RAG、Agent 和推理服务看的是不同东西。

4.1 RAG 问答系统¶

基础目标：
- 月可用性 >= 99.9%
- P99 延迟 < 3s
- 5xx 错误率 < 0.2%

质量目标：
- Recall@5 >= 0.90
- Faithfulness >= 0.85
- 引用缺失率 < 2%

成本目标：
- 单请求平均成本 < 0.08 元
- 缓存命中率 >= 25%

4.2 Agent 系统¶

基础目标：
- 月可用性 >= 99.5%
- 任务超时率 < 1%

质量目标：
- 任务成功率 >= 80%
- 工具调用成功率 >= 95%
- 危险操作误执行率 = 0

治理目标：
- Prompt Injection 检出率 >= 95%
- 错误循环平均步数 <= 2

4.3 LLM 推理服务¶

基础目标：
- 月可用性 >= 99.95%
- P99 首 token 延迟 < 1.5s
- P99 完整响应延迟 < 5s

资源目标：
- GPU 利用率 >= 60%
- OOM 率 < 0.1%
- 单千 token 成本持续下降

五、错误预算怎么指导发布¶

错误预算真正的价值，不是做报表，而是决定什么时候可以继续发、什么时候必须停下来修系统。

5.1 一个简单的策略表¶

5.2 AI 服务中的典型高风险变更¶

• 更换主模型
• 调整 RAG 检索链路
• 修改系统 Prompt 或工具策略
• 更换 reranker / embedding 模型
• 切换量化精度或批处理策略
• 变更缓存策略

这些改动看上去不像“基础设施改动”，但对 AI 服务质量和可靠性影响很大。

六、发布、灰度与回滚¶

SLO 和错误预算如果不能落到发布动作上，就只是名词解释；这一节把它们接到真实上线流程里。

6.1 推荐上线流程¶

离线评测
  -> 人工抽检
  -> 小流量灰度(1%-5%)
  -> 关键指标稳定
  -> 扩大灰度(10%-30%)
  -> 全量发布

6.2 AI 服务上线的 4 条铁律¶

1. 没有 baseline 不上线。
2. 没有关键指标监控不放量。
3. 没有回滚方案不上生产。
4. 错误预算逼近上限时，不做高风险实验。

6.3 典型回滚触发条件¶

触发任一条件立即回滚：
- P99 延迟恶化 > 30%
- 5xx 错误率 > 1%
- Faithfulness 下降 > 5 个百分点
- 工具调用失败率翻倍
- GPU OOM 持续增长

七、AI 事故的分类方法¶

AI 事故不能只按“服务挂没挂”来分，还要区分质量、行为和成本层面的异常。

7.1 基础设施事故¶

• 服务不可用
• GPU 节点异常
• 网络抖动
• Redis / 向量库故障

7.2 质量事故¶

• 检索结果显著变差
• 回答无引用或错引用
• 幻觉率飙升
• reranker 失效

7.3 Agent 行为事故¶

• 调错工具
• 参数错误
• 死循环
• 危险动作未拦截

7.4 成本事故¶

• Token 暴涨
• 缓存失效
• 模型路由失灵
• 小模型流量意外打到大模型

八、复盘模板¶

复盘模板的目标不是写长文，而是让一次事故能沉淀成下一次发布前必须检查的动作。

8.1 一页事故复盘¶

## 事故名称

- 时间：
- 影响范围：
- 严重级别：
- 现象：
- 发现方式：
- 临时止血动作：
- 根因：
- 永久修复：
- 需要补的监控：
- 需要补的流程：
- Owner：
- 截止日期：

8.2 推荐的复盘结构¶

1. 事实时间线¶

按分钟列出：

• 何时开始异常
• 谁发现
• 做了哪些操作
• 何时恢复

2. 影响评估¶

至少包括：

• 用户影响
• 业务影响
• 指标影响
• 错误预算消耗

3. 根因分析¶

不要只写表面原因。
建议至少追到流程层和系统层。

示例：

表面原因：新 reranker 版本导致召回后排序异常
深层原因：
1. 上线前只做了小样本人工验证，未做完整离线评测
2. 灰度指标缺失，没有监控 Faithfulness 变化
3. 缓存导致问题在 20 分钟后才暴露

4. 改进行动¶

必须分成 3 类：

• 监控补齐
• 流程补齐
• 系统修复

九、三个典型 AI 事故案例¶

下面三个案例分别对应检索、推理和 Agent 行为，是面试里最容易被追问的三类事故。

案例 1：RAG 检索劣化¶

现象：

• 服务仍然 200 OK
• 延迟正常
• 用户投诉“答非所问”明显增多

问题本质：

• 这不是基础设施事故，而是质量事故
• 如果你只盯可用性，根本发现不了

应对：

• 补检索质量与 Faithfulness 监控
• 建立坏例抽样看板
• 将质量指标纳入发布门禁

案例 2：推理服务延迟暴涨¶

现象：

• P99 从 2.8s 涨到 6.5s
• GPU 利用率偏低，但排队时间上升

常见根因：

• Continuous Batching 配置不合理
• 流量路由异常
• 缓存命中率下降
• 上游请求长度分布突变

应对：

• 先回滚高风险变更
• 再排查队列、批处理、prompt 长度分布

案例 3：Agent 工具调用错误循环¶

现象：

• 请求没有失败，但任务执行步数异常增加
• 成本上升，用户等待时间变长

常见根因：

• 工具描述不清
• 参数校验不足
• 失败后重试策略设计错误
• 缺少最大步数限制

应对：

• 加最大步数
• 加工具参数白名单
• 加失败短路与人工接管

十、面试怎么回答这类问题¶

问：你们怎么定义 SLO¶

推荐回答结构：

1. 先区分基础可靠性、AI 质量、资源成本三层指标
2. 说明不同系统 SLO 不同
3. 给出一两个具体目标
4. 说明错误预算如何影响发布策略

问：如果新模型效果更好，但稳定性更差怎么办¶

推荐回答：

• 先灰度，不直接全量
• 同时监控效果和稳定性
• 若错误预算消耗过快，优先保稳定
• 长期再做结构性优化，而不是硬扛

问：AI 服务复盘和普通服务复盘有什么不同¶

回答重点：

• AI 服务多了“质量事故”和“输出风险”
• 不能只看 5xx 和延迟
• 还要看事实性、检索质量、工具行为、成本

十一、自检清单¶

• 我能解释 SLI / SLO / SLA 的区别
• 我能给 RAG / Agent / 推理服务分别定义 3-5 个核心 SLI
• 我知道错误预算怎么计算
• 我知道预算耗尽时发布策略要怎么变
• 我能说出至少 2 个 AI 特有事故类型
• 我有一套复盘模板

结论¶

AI 系统设计到高阶阶段，考的不是“系统能不能跑”，而是“系统能不能长期稳定、可控地跑”。
SLO + 错误预算 + 复盘能力，就是把你和只会讲架构图的候选人拉开差距的关键。