17. 线上事故复盘怎么做？大模型应用的事故和传统服务有什么不同？

简单回答

大模型应用的事故复盘和传统服务在流程上类似（时间线还原、根因分析、改进项），但事故类型有显著差异：除了传统的可用性事故（5xx、超时），还多了一类"内容质量事故"——服务正常返回但内容是错的、有害的、引发投诉的。这类事故的复杂之处在于发现链路长（从用户反馈到工程师介入可能要几小时）、根因模糊（可能是模型本身、Prompt、检索质量、用户输入分布漂移）、修复路径多样（改 Prompt、换模型、加 Guardrails、补 RAG 数据）。我做复盘的标准做法是分两类各走不同流程：技术性事故按 SRE 经典流程做 5 Whys 分析，质量性事故重点放在样本对比、Prompt 版本溯源、和数据闭环改进上。

详细解释

大模型应用的事故分类

把事故分成两大类有助于走不同流程：

类型 A：技术性事故（可用性/性能）

• 模型 API 返回 5xx 或超时
• 自部署推理 GPU OOM、CUDA 错误、模型 crash
• 限流配额耗尽（自身限流或 Provider 端 429）
• 向量库连接问题、索引损坏
• Streaming 输出中断、连接断开
• Token 异常消耗（Agent 死循环、工具调用爆炸）
• 端到端延迟超 SLO

特点：有明确的错误信号（5xx、超时、异常日志），监控告警能秒级到分钟级发现。

类型 B：质量性事故（内容/行为）

• 模型给出事实错误的回答
• 回答有偏见、攻击性、违反合规（涉政、涉黄、涉敏）
• 严重的幻觉（编造法律条款、虚构产品功能）
• 回答风格异常（突然变得啰嗦/简短、风格不一致）
• 工具调用频繁出错或选错工具
• Agent 任务完成率显著下降但单步无报错
• 输出格式不符合下游解析（突然破坏 JSON 格式）

特点：服务"正常"返回，没有显式错误信号。发现依赖用户反馈、人工抽检、或质量指标延迟告警。

事故响应（不分类型）

无论哪类事故，前 30 分钟的目标都是 止血——让影响停止扩散，然后再做根因分析。

止血手段优先级：

1. 回滚最近变更——最近一次代码发布、Prompt 改动、模型版本切换、知识库更新，按"最近 + 最相关"原则尝试回滚
2. 降级到备选路径——切到旧模型、关闭 RAG 走纯模型、关闭工具调用、返回兜底话术
3. 限流缩流量——让影响面变小，给排查争取时间
4. 熔断异常下游——如果是某个 Provider 或某个工具异常，先熔断它

事故初期的判断逻辑：与其纠结"到底是什么坏了"，不如先"把可疑的最近变更全部回退一遍试试"。LLM 应用变更点多——代码、Prompt、模型、索引、配置——一个个 ABtest 太慢，先全部回退快速止血。

类型 A 的复盘流程

这一块和传统 SRE 的事故复盘几乎一样：

还原时间线：从最早异常告警到完全恢复，列出每个关键节点的时间和动作。包括误判、走错方向、回滚等都要诚实记录。

5 Whys 根因分析：层层追问"为什么"直到落到根因上。比如：

• 现象：API 返回 5xx 飙升
• 为什么 5xx？→ 推理服务 OOM
• 为什么 OOM？→ KV Cache 占满
• 为什么 KV Cache 占满？→ 大量长 context 请求堆积
• 为什么堆积？→ 限流没按 token 而按 QPS 限
• 根因：限流策略不当，对长 context 请求没有保护

改进项分类：

• 立即修复（已经做了或正在做）
• 短期改进（一周内）—— 改进监控告警、补充限流规则、加自动化降级开关
• 长期改进（一个月内）—— 架构调整、能力建设

经验沉淀：归类到 runbook 里，下次类似现象有处置 SOP。

LLM 应用类型 A 事故的常见根因 pattern：

• 长 context 请求挤占资源（限流不分长短）
• Provider 端 SLA 抖动（自身没问题但被外部影响）
• 工具调用扇出过多（一个 Agent 请求触发几十次 tool call）
• Prompt 模板更新引起 token 数突增（Prompt Caching 失效成本爆涨）
• KV Cache 配置和实际负载不匹配（突然来了大量长会话）

类型 B 的复盘流程

质量性事故复盘和传统服务差别最大。核心问题是 没有显式错误信号，复盘要重点解决三件事：

Step 1：精确定位有问题的样本

用户反馈往往模糊（"今天的回答好像有问题"），第一步是把"有问题"具象化——找到具体哪些 query、哪些用户、哪个时间段开始出问题。

工具：

• 完整的调用日志（含 Prompt 版本、模型版本、检索结果、最终输出）
• 用户反馈系统（点踩、负面表情、人工投诉）按时间分布
• 自动化质量监控（LLM judge 周期性抽检）的趋势变化
• 人工抽检——把可疑时段的样本拉出来人工逐条看

Step 2：分层归因

确定有问题的样本后，按"哪一层出错了"归因。LLM 应用的层级：

• 用户输入：用户表达模糊、有歧义、超出业务范围
• 检索：召回不到相关文档、召回了错误文档、文档本身有错
• Prompt 组装：上下文截断错位、System Prompt 改动副作用
• 模型推理：模型本身的判断错误、对相同 Prompt 不同 sampling 的方差
• 后处理：内容过滤误伤、格式转换出错

每个样本要走一遍这五层判断"问题首先出在哪里"。这一步通常要做 50-100 条样本的归因才能看出 pattern。

Step 3：定位根因 pattern

汇总归因结果看 统计 pattern。是某一类 query 集体出错（说明是数据/检索/Prompt 问题），还是随机分布（说明是模型本身的方差或是抽样问题）？是某个时间点之后开始出错（说明有变更引入），还是渐进式变差（说明是数据漂移）？

常见根因 pattern：

• 知识库某次更新引入了错误数据 → 检索把错误数据召回 → 生成基于错误数据
• Prompt 某次修改虽然解决了 case A 但破坏了 case B
• 用户输入分布漂移（新场景、新话题进来），原有 Prompt/RAG 没覆盖
• 模型 Provider 端悄悄升级了模型版本（这是真实发生过的——同一个 model id 行为变了）
• Few-shot 示例里的某条数据被发现是错的，但模型在生成时一直在模仿它

Step 4：修复和数据闭环

修复路径根据根因不同：

• 数据问题 → 修知识库 + 重建索引 + 加数据校验流程
• Prompt 问题 → 改 Prompt + 评估集回归 + Prompt 版本管理流程
• 模型问题 → 切模型 / 加约束 / 加后处理校验
• 输入分布漂移 → 扩展评估集 + 增加监控覆盖

更重要的是把"出错样本"加入评估集和质量监控里，形成数据闭环——下次类似问题能更早被自动检测出来。这是质量性事故复盘的核心产物。

一个具体例子

举个真实模式：客服机器人某天开始大量给"退货政策"问题错误的回答。

止血：发现是知识库前一天更新引入的脏数据（某文档第 3 章的退货政策被新版本 V2 替换但旧版本没删除，向量检索两个版本都召回，模型混淆）。先回滚知识库到前一天版本。

根因分析：

• 第一层：用户输入正常，"退货政策"是合法 query
• 第二层：检索召回了新旧两个版本的政策文档
• 第三层：Prompt 把两份矛盾的内容都塞进上下文
• 第四层：模型选择性使用了一份（不一定是正确的那份）

根因落在"知识库更新流程没有去重新旧版本"。

修复：

• 立即：回滚知识库
• 短期：补一个去重脚本，每次更新前检查是否有同一 doc id 的旧版本残留
• 长期：知识库做版本化，每个文档明确 active 版本，检索只返回 active 版本

数据闭环：把"退货政策"相关的几十个 query 加入自动化质量监控集，每天 LLM judge 抽检确认输出和现行政策一致。

复盘文档要写什么

不管类型 A 还是 B，复盘文档至少要包含：

• 事故时间线（精确到分钟）
• 影响范围（影响用户数、影响时长、损失估算）
• 根因（5 Whys 落到底）
• 当时做对的事和做错的事（诚实，不甩锅）
• 改进项清单（带负责人和 deadline）
• 监控/告警漏掉了什么
• 类似事故是否能用同套监控覆盖

最有价值的是 改进项的执行跟进——很多团队复盘做得好但改进项跟丢了，下次同类事故再发生。建立 follow-up 机制把改进项追到完成。

防御性建设

事后复盘是被动的，主动防御要做到：

• 多维度监控（不只看技术指标，质量指标也要定期采）
• 用户反馈通道顺畅（点踩、举报路径要短）
• 内容安全前置（Guardrails 能阻断的不要靠人工发现）
• 完整调用日志（出问题能追溯每个细节）
• 评估集持续维护（线上失败样本归档进评估集）
• 演练（定期做"模型挂了"、"知识库出错"的演练）

面试时可以这样答

大模型应用的事故和传统服务最大的差别是多了一类质量性事故——服务正常返回但内容是错的、有害的。这类事故没有显式错误信号，发现链路长、根因模糊、修复路径多样。

我把事故分两类走不同流程。技术性事故和传统 SRE 一样——还原时间线、5 Whys 分析、改进项分级。LLM 应用这边的常见根因 pattern 包括限流没按 token 限、Provider 端 SLA 抖动、Agent 工具调用扇出过多、Prompt 模板更新导致 token 数突增。

质量性事故的复盘核心是三步。第一步精确定位有问题的样本——用户反馈往往模糊，要靠日志、点踩反馈、自动化质量监控找到具体出错的 query。第二步分层归因——把每个出错样本归因到用户输入、检索、Prompt 组装、模型推理、后处理这五层中的哪一层。通常要跑 50-100 条样本的归因才能看出 pattern。第三步看统计 pattern 定根因——是某类 query 集体出错（数据/检索/Prompt 问题）还是随机分布（模型方差）？是变更引入还是数据漂移？

修复后最重要的是数据闭环——把出错样本加入评估集和质量监控，下次类似问题自动检测。这是质量性事故复盘的核心产物。

事故初期的止血逻辑是：与其纠结到底什么坏了，不如把最近的变更（代码、Prompt、模型、索引）按"最近+最相关"原则全部回退一遍快速止血。LLM 应用变更点多，先回滚再分析比逐个 ABtest 快得多。

防御性建设上，监控不能只看技术指标质量指标也要定期采，用户反馈通道要短，调用日志要带版本指纹（模型版本、Prompt 版本、索引版本、code commit hash），评估集要把线上失败样本持续归档进去。

常见追问

1. 质量性事故的"严重程度"怎么定级？影响多少用户算 P0？
2. 用户反馈量天然滞后，怎么提早发现质量回归？有哪些主动监控手段？
3. 跨团队的复盘怎么做？模型由模型团队负责、Prompt 由产品团队、RAG 由数据团队，怎么避免互相甩锅？