5.1 LLM 应用的故障分类
5.1 LLM 应用的故障分类
本节摘要：传统服务的故障分类（宕机、错误率、延迟、饱和度）对 LLM 应用不够用——它漏掉了最贵的两类：坏答案与成本爆炸，都不抛异常、状态码全是 200。本节把 LLM 应用故障收敛为四类：超时与慢（延迟类）、降级与不可用（错误类）、坏答案（质量类）、成本爆炸（预算类），每类给一张特征表：三支柱里哪个信号先亮、常见根因清单、第一止损动作。再给责任层判定口径——上游供应商、检索侧、编排侧、工具侧四层，对应能力清单第 9 问"错误率上升时能否区分责任在哪层"。分类是排障的第一秒：类分对了，第 5.2 节的排障树才能从正确的入口走下去。
学习目标
- 用四类故障给告警归类，说出每类的信号特征与第一止损动作
- 区分"降级"与"坏答案"：一个是没答上，一个是答错了
- 按四层责任口径（上游/检索/编排/工具）定位责任方
- 把前半的信号（三本账、三线、漂移四信号）接成分类索引
一、为什么是这四类
四金指标时代的故障分类隐含一个假设：服务要么在好好干活，要么在报错。LLM 应用多了两个新状态：在好好报错（输出通顺但错误，无任何异常）与在好好地烧钱（一切正常，只有账单异常）。所以分类必须在传统的"慢、错"之外，加上"坏、贵"：
| 类 | 一句话 | 状态码 | 用户感受 | 恶化速度 |
|---|---|---|---|---|
| 超时与慢 | 答得慢、答不出 | 200 或 504 | 转圈、"这机器人好卡" | 分钟到小时 |
| 降级与不可用 | 调用失败、被限流拒绝 | 429/5xx | "用不了了" | 秒到分钟 |
| 坏答案 | 答错了、答非所问、该拒不拒 | 200 | "答的什么玩意" | 小时到天 |
| 成本爆炸 | 一切正常，钱不正常 | 200 | 无感受（先于用户） | 分钟（循环）到天（漂移） |
四类监测来源不同：慢与错看传统信号（延迟分布、错误率），坏看第 4 章质量信号，贵看第 3 章账本与三线。一张告警进来，先问"这是哪类的信号在响"——这就是分类表的作用。
分类还有一个常被忽视的用途：决定响应节奏。慢与错是分钟级响应（用户正在受苦），坏答案是小时级响应（先确认范围再动手，回滚要谨慎），成本爆炸介于两者之间（循环类必须分钟级止血，漂移类可以进周会）。把响应节奏写进告警路由，值班就不会把"点踩率缓慢上升"当成半夜电话的理由——也不会把"agent 正在烧钱"拖到明天早会。
| 类 | 响应节奏（示意） | 半夜叫醒值班？ |
|---|---|---|
| 超时与慢 | 分钟级止损，小时级根因 | 影响面大才叫 |
| 降级与不可用 | 分钟级 | 叫 |
| 坏答案 | 小时级确认，回滚前对齐版本 | 突发型叫，缓变型不叫 |
| 成本爆炸 | 循环类分钟级；漂移类进周会 | 循环类叫，漂移类不叫 |
二、四类故障特征表
超时与慢。 先亮的信号：P95/P99 与 TTFT 越带（第 4.2 节）；超时率（网关或客户端口径）。常见根因：上游容量不足或排队（llm.call 段占比高）、prompt 变长（账一涨 + 生成变慢）、检索段慢（retrieve 段占比高）、自身并发打满。第一止损：临时下调 max_tokens 与检索篇数、超时熔断兜底、必要时切轻量模型——先让用户拿到短答案，再查慢因。
降级与不可用。 先亮的信号：错误率、429/5xx 占比、供应商状态（参考但别依赖，见第 1.2 节坏答案模式之三）、连接池/密钥失效。常见根因：限流额度打穿（TPM/RPM，见第 7.2 节）、供应商区域故障、网关剥掉 usage 或改了响应结构、密钥轮换未同步。第一止损：切备用模型或供应商、非核心功能排队降级、对旧问题回放缓存答案（本站《请求缓存与智能路由降低 token 成本》文集的正向用法）。
坏答案。 先亮的信号：裁判分下跌、点踩率上升、拒绝率与输出长度突变（第 4.2 节四信号）。常见根因按命中率排：检索未命中或检索库更新引入坏文档、prompt 改动引入回归、模型快照静默更新（版本飞轮，第 1.1 节）、上下文污染（多轮历史里混入错误内容）。第一止损：回滚最近变更——prompt 版本、检索库版本、模型版本三方标签（第 2.2 节）对齐故障起点，最快的那条路通常是回滚而不是修。
成本爆炸。 先亮的信号：第 3.3 节三线（提醒/暂停/升级）、单会话 token TopN、三本账结构突变。常见根因：agent 循环失控（账二暴涨）、缓存前缀被改导致全 miss（账三异动）、新版 prompt 更费 token（版本回归）、刷量用户。第一止损：会话熔断（第 3.3 节 SessionCap 预扣口径）、限速、必要时功能级降级。三类来源的完整清单见第 3.1 节"成本突增的三个典型来源"。
💡 四类的止损优先级不同：慢与错止损求快（分钟级），坏答案止损求准（回滚前先确认版本对齐），成本爆炸止损求狠（宁可误杀会话，不可放任循环）。
三、责任层判定：坏了该找谁
能力清单第 9 问："错误率上升时，你能否区分责任在模型上游（供应商 API）、检索侧、编排侧还是工具侧？"判定口径一张表：
| 责任层 | 信号特征（span 层归属见第 2.1 节四层模型） | 快速验证 |
|---|---|---|
| 上游供应商 | llm.call 段错误率高：429/5xx、超时集中；多模型同时受影响则疑区域故障 | 直连供应商做一次最小调用；查状态页做旁证 |
| 检索侧 | retrieve 段正常返回但 hits=0 或命中无关文档；坏答案类主责 | 抽故障时段问题重放检索，人工看命中 |
| 编排侧 | 重试风暴、循环、上下文拼装错误；账本异动但单次调用正常 | 看 pipeline 层重复模式与重试计数 |
| 工具侧 | tool 段返回错误或超时；agent 因工具失败而循环重试 | 看 tool span 状态码与返回摘要 |
两个易错判定要记住：上游正常不等于你没坏（检索坏了上游照样 200）；工具超时常伪装成慢（总延迟涨，先看是哪一段涨——第 2.1 节"问题有固定住址"）。
给一个四类交叉的例子（示意）：某天同时出现"P95 变慢 + 输出长度均值上涨 + 单会话 token TopN 异常"。三个信号拼起来：先怀疑输出变长拖慢生成（慢+贵同源），下钻 TopN 会话的 trace 看到 pipeline 层重复的 llm.call+tool 循环——分类从"慢"改判"成本爆炸"，责任层落在编排侧（循环重试）。单看任何一个信号都会误判：只看延迟会去怪供应商，只看长度会去砍 max_tokens（治标），只看账本会以为是用量增长。
⚠️ 两对最易混淆的组合：坏答案对降级——"没答上"（拒答、空结果）偏降级类，"答错了"才是坏答案；成本爆炸对用量增长——前者每成功会话成本恶化、后者持平（第 3.3 节单位经济是判据）。混淆的代价是处置反了：对用量增长上熔断会误伤正常用户，对循环失控只谈限价会继续烧钱。
四、把分类接进信号体系
分类不是背表，是给信号体系装索引。落地三件事：
- 每条告警带分类标签：三线告警（3.3）与漂移阈值告警（4.2）在配置时就打上四类之一与责任层初判，值班看到的第一行就是"疑似：成本爆炸 / 编排侧"；
- 特征表变成 runbook 索引：第 3.3 节要求每条告警线配三行处置——"先看什么"直接抄本节特征表的"先亮的信号"列，"常见原因"抄根因清单，"止损动作"抄第一止损；
- 月度盘点分类命中：复盘时统计"告警归类 vs 最终根因"的一致率，错得最多的那类，就是下次演练的靶子（第 5.2 节案例复盘的方法）。
（文字流程图） 告警 ──▶ 看信号来源（延迟/错误/质量/预算哪个视图在响） ──▶ 对特征表归类（5.1）──▶ 打标签 + 责任层初判 ──▶ 进排障树对应路径（5.2）──▶ 下钻 trace 到根因 ──▶ 止损 ──▶ 复盘回写
💡 分类表的最后一条用法：拿它当新值班的培训教材。新人第一次值班最怕的不是故障，是"不知道该看哪个屏幕"——四类特征表 + 责任层判定，就是一张三十分钟可以背下来的值班地图。
⚠️ 分类不是一次性的：每次复盘如果发现"归错类"的案例，回来改特征表——它应该随你们的故障史一起进化，而不是写成那天起就冻结。
本节要点回顾
- 四类故障：超时与慢、降级与不可用、坏答案、成本爆炸——后两类状态码全 200，是 LLM 特有的"静默故障"。
- 每类三件套：先亮的信号（接 3.3/4.2）、常见根因清单、第一止损动作（慢求快、坏求准、贵求狠）。
- 责任四层：上游、检索、编排、工具；上游正常不等于你没坏，工具超时常伪装成慢。
- 分类决定响应节奏：慢错分钟级、坏答案小时级、循环类成本爆炸分钟级止损——节奏写进告警路由。
- 分类要进告警标签、进 runbook 索引、进月度命中率盘点——表是用来接线的，不是用来背的。
类分好了，下一步是沿树走。第 5.2 节给出一棵从告警直达根因的排障决策树，并用一则 25 分钟的完整案例复盘，演示树上的每一步在真实故障里长什么样。