大模型应用故障如何分类？
简化版
大模型故障不能只分“模型错了”和“系统挂了”。应按链路阶段分类：输入与权限、检索/上下文、模型推理、输出校验、工具执行、基础设施，以及质量/安全/成本问题；再补充影响范围、可重试性、是否有副作用和责任组件。
一个故障只选一个主原因码，同时记录多个症状标签。例如“检索索引版本错误导致幻觉”，主因是 RETRIEVAL_INDEX_STALE，幻觉是结果症状。稳定分类能驱动告警、Fallback、归因统计和失败样本回流。
详细版
建议错误结构：
{
"stage": "retrieval",
"code": "INDEX_STALE",
"retryable": false,
"side_effect": "none",
"severity": "S2",
"symptoms": ["unsupported_answer"]
}| 类别 | 例子 | 默认处置 |
|---|---|---|
| 输入/权限 | 非法 Schema、越权 | 拒绝，不重试 |
| 检索 | 空召回、旧索引 | 修索引/保守回答 |
| 模型 | 超时、上下文超限 | 有界重试/兼容路由 |
| 输出 | JSON 失败、引用不实 | 有限修复/阻断 |
| 工具 | 超时、结果未知 | 查询状态/补偿 |
| 资源 | OOM、过载 | 准入、扩容、降级 |
分类版本化且保持向后兼容；错误文案可以改变，稳定 Code 不变。每次事故复盘更新判定规则和代表样本，避免分类沦为随意标签。
完整版教学
1. 为什么需要故障分类
没有分类时，所有失败都落到“LLM Error”，团队无法判断该改 Prompt、索引、模型还是基础设施，也无法设计正确重试。
分类的目标是让同类故障有一致所有者、指标、处置和改进路径。
它还决定自动化能否安全执行：只有明确哪些错误可重试、哪些必须失败关闭，Fallback 和告警系统才不会放大事故。
2. 分类维度有哪些
主维度是发生阶段，辅助维度包括严重度、影响范围、可重试性、确定性、是否有外部副作用和用户可见性。
不要把所有维度拼成一个超长 Code；主原因码保持稳定，辅助字段便于组合分析。
例如同一个 PROVIDER_TIMEOUT 可以同时带 S2、region=ap-southeast、retryable=true，而无需为每种区域和严重度创造新错误码。
3. 输入与权限故障
包括 Schema 非法、长度超限、语言不支持、身份失效、租户越权和提示注入。多数是确定性问题，原样重试无效。
权限与安全拒绝应与基础设施失败区分，防止 Fallback 绕过策略。用户错误消息脱敏，内部保留稳定原因码。
4. 检索与上下文故障
可细分空召回、低相关、权限过滤错误、索引过期、文档冲突、截断丢证据和引用映射错误。
answer wrong
├─ evidence not retrieved
├─ evidence retrieved but omitted from context
└─ evidence present but model ignored/misused这三种症状相似，但修复分别属于召回、上下文构造和生成约束。
5. 模型推理故障
包括 Provider 超时/5xx、限流、OOM、上下文超限、生成中断、异常重复和能力不足。前几类是服务故障，能力不足是质量边界。
只有标记 retryable 的瞬时错误进入有界重试；上下文超限应压缩或换兼容模型，重复原请求没有意义。
6. 输出与校验故障
格式解析失败、Schema 不合格、引用不存在、事实不支持、安全违规和截断属于输出层。格式可有限修复，事实/安全失败通常需阻断或重做。
校验器自身不可用要单独分类，不能把“未能检查”记成“检查通过”。
7. 工具故障为何特殊
工具会产生真实副作用。区分调用前失败、确定未执行、确定已执行、结果未知和补偿失败。
| 状态 | 可否自动重试 | 处置 |
|---|---|---|
| 调用前校验失败 | 否 | 修参数 |
| 确定未执行 | 可 | 幂等重试 |
| 确定已执行 | 否 | 返回结果 |
| 执行状态未知 | 谨慎 | 查询状态/人工 |
| 补偿失败 | 否 | 升级事故 |
没有幂等键的写操作默认不自动重试。
8. 基础设施与依赖故障
包括网络、DNS、存储、队列、节点、GPU、代理和配置中心。应记录具体依赖与区域，避免一个“infra_error”失去定位价值。
外部供应商故障保留原始码，同时映射内部枚举，以便跨供应商统计。
9. 质量故障如何分类
幻觉太宽泛，可拆为无证据断言、证据矛盾、指令遗漏、推理错误、风格不符、多轮状态丢失和拒答边界错误。
质量分类需代表样本和标注指南，否则不同团队会对同一答案给不同标签。允许记录 secondary labels，但只指定一个主修复层。
10. 安全与合规故障
包括敏感信息泄露、越权、提示注入成功、有害输出、不当拒答、地域违规和审计缺失。严重事件独立升级，不被平均质量分稀释。
安全细节放受控存储，普通日志只记录分类与证据引用，避免二次传播敏感内容。
11. 成本与性能故障
成本超预算、Agent 循环、重试放大、缓存失效风暴、TTFT/TPOT 违约和冷启动异常，都属于可运营故障，即使最终答案正确。
用户取消后仍生成可归为资源泄漏；它应由取消链路负责人修复，而非算作模型质量问题。
性能故障还要区分容量不足和单请求异常：前者通常通过扩容或准入处理，后者可能来自超长上下文、坏配置或特定版本回归，责任路径并不相同。
12. 严重度如何判定
严重度由用户影响、范围、持续时间、数据/资金副作用和可恢复性共同决定。单次高风险泄露可能比大范围短暂慢化更严重。
severity = impact × scope × duration × irreversibility公式是判断框架，不是机械乘法；安全和合规可设直接升级条件。
13. 如何落地到系统
维护版本化 Taxonomy Registry：Code、定义、边界、所有者、默认重试、严重度与示例。SDK 只允许枚举值，并在 Trace 中记录 stage/code。
仪表盘按主原因统计，同时允许按症状、模型、租户和版本切片。未知类保留 UNKNOWN，但要定期治理，不能长期成为最大类别。
14. 如何验证分类质量
让多个标注者独立分类同一批真实事故，计算一致率并讨论分歧；对自动规则抽样复核。新增类别必须说明为何现有类别无法表达。
复盘时检查发现、处置和最终根因是否一致，并把代表案例加入指南。
好的故障分类不是把错误分得越细越好，而是让每个类别都能驱动明确的处置和责任归属。
15. 常见误区与追问
- 误区：所有差答案都叫幻觉。 检索失败、证据遗漏和推理错误修复层不同。
- 误区：HTTP 5xx 才算故障。 质量、安全、成本和 SLO 也可能失败。
- 误区：每个症状都设为主原因。 应区分根因与表现。
- 误区：工具超时可以直接重试。 写操作状态未知时可能重复副作用。
- 误区：错误文案可直接做统计维度。 文案不稳定，应使用版本化枚举。
- 追问：UNKNOWN 怎么处理？ 保留兜底并定期复盘拆分，而非强行误分类。
- 追问：分类多细合适？ 以能改变所有者或处置策略为拆分类别的标准。
16. 加强记忆
- 先按阶段：输入、检索、模型、输出、工具、基础设施。
- 再加运营：质量、安全、成本与性能。
- 再加属性：严重度、范围、可重试和副作用。
- 再分主次：一个主根因，多个症状标签。
- 再绑处置：重试、降级、阻断、补偿或人工。
- 再做注册表：稳定 Code、定义、所有者和样例。
- 最后用复盘校准：UNKNOWN 与低一致率持续治理。