AI 事故严重程度分类法：幻觉何时算作 Sev-0？

一个法律团队的 AI 研究助手伪造了三个案例引用，并将它们混入了法庭文件中。这些引用看起来非常可信 —— 真实的法院、听起来很真实的案例名称、连贯的判决理由。在提交摘要之前，没有人发现它们。这一事件导致律所面临紧急听证会、公开道歉以及律师协会的调查。

那是 Sev-0 还是 Sev-2？答案取决于你使用的框架 —— 而传统的严重程度模型几乎每次都会给你错误的答案。

软件事故严重程度分类是为确定性系统构建的。服务要么有响应，要么没有。数据库查询要么成功，要么抛出错误。失败模式是二进制的，责任可以追溯到某个 commit，而修复方案则是回滚或补丁。AI 系统同时打破了这三个假设，如果组织将传统的严重程度框架应用于 LLM 故障，最终要么是对噪声感到恐慌，要么是将结构性故障视为偶然的异常。

为什么传统的严重程度分类对 AI 系统失效

标准的严重程度级别 —— 通常是 Sev-0 到 Sev-4 或 Sev-5 —— 是围绕可观察、持续的故障状态设计的。Sev-0 是全线宕机。Sev-1 是影响大多数用户的关键性能下降。该模型假设严重程度与范围和持续时间直接相关，且两者都是可衡量的。

LLM 系统从三个方面违反了这一模型。

非确定性瓦解了持续的故障状态。 在 temperature 为 0.7 的情况下，将相同的输入传递给相同的模型，每次调用都会得到不同的输出。一个复现率为 30% 的错误在抽查中看起来像 Sev-3，但在大规模运行下表现得像 Sev-1。传统的事故响应会问：“它还在发生吗？”对于概率系统，这个问题没有稳定的答案。

语义错误通过了验证。 当服务抛出 500 错误时，你的监控会捕获它。当 LLM 产生一个语气坚定、格式完全符合预期的错误答案时，下游的每一项检查都能通过。故障作为有效数据进行传播。在多智能体系统中，研究表明，与单智能体基准相比，独立的智能体流水线会将这些错误放大 17 倍，而中心化协调将放大控制在 4 倍左右。10 步流水线中第 2 步的幻觉不仅会影响第 2 步 —— 它会毒害下游的所有环节。

因果关系是分布式的。 传统的复盘将故障追溯到某个 commit。AI 事故没有单一原因。模型改变了。提示词模板更新了。训练数据分布偏移了。推理 temperature 被调高了。检索语料库过时了。这些因素的任何组合都可以产生相同的观察到的退化，而责怪“模型”就像责怪“网络”一样毫无意义。

多维事故分类框架

解决方案是停止将严重程度视为单一维度，而是开始将其视为四个维度的矩阵。每个维度都是独立可衡量且独立可操作的。

维度 1：范围 —— 单次会话 vs. 群体性

在任何 AI 事故中，首先要回答的问题是故障是在影响单个会话还是相关的群体。

单次会话故障（per-session failure）看起来是随机的。用户 A 得到了一个幻觉答案；用户 B 问同样的问题得到了正确的答案。这是任何概率系统的基准行为 —— 你测量的是分布的尾部，而不是结构性缺陷。

群体性故障（per-cohort failure）在性质上则完全不同。所有调用系统且文档长度超过 8,000 token 的用户都会得到截断的答案。所有通过移动端 SDK 在 iOS 17.4 上运行的用户都会遇到上下文封送（context marshaling）漏洞。所有包含日期范围的查询都会返回微妙的错误结果。群体性故障表明存在结构性问题：这类输入、这个用户群体或这条执行路径在系统层面上是损坏的。

事故响应的意义在于：单次会话故障需要监控和统计基准。群体性故障则需要立即调查并可能需要对功能进行开关控制（feature gating）。影响 0.3% 会话的幻觉可能是正常的噪声；但在特定提示词模式下影响 100% 会话的幻觉，无论原始用户数量多少，都属于 Sev-1。

维度 2：故障类型 —— 事实性 vs. 风格化偏移

并非所有的输出退化都是平等的。AI 事故可以清晰地分为两类，且具有截然不同的紧迫性。

事实性退化（factual degradation）意味着模型正在产生错误的断言。伪造的引用、不正确的统计数据、幻觉产生的产品功能、错误的日期。这些故障可以根据客观事实进行衡量，它们会造成直接伤害，而且这就是大多数人所说的“AI 坏了”的意思。

风格化偏移（stylistic drift）意味着输出在特征上发生了变化，但在正确性上没有变化。回答变得更加冗长。语气从专业转向随意。格式规范发生了变化。回答长度翻倍。这些变化是真实存在的 —— 用户会注意到它们，评估得分会发生变化，A/B 测试会检测到它们 —— 但它们很少单独构成一起事故。

实际意义在于：事实性退化会立即升级。风格化偏移则进入监控积压任务。你需要警惕的是那些被误归类为风格化偏移的事实性退化，因为它们通过了自动化格式检查。一个只验证 JSON 结构而不验证语义正确性的系统，每次都会漏掉这种故障。

维度 3：可见性 —— 面向用户 vs. 内部

将检索精度从 0.94 降低到 0.88 的嵌入偏移 (embedding drift) 是一种真实的退化。它是否构成事故，取决于它是否呈现在用户面前。

仅限内部的故障 —— 检索得分下降、思维链追踪变慢、重排序器置信度降低 —— 对于工程团队的态势感知非常重要。它们是未来面向用户故障的先导指标。但从传统意义上讲，它们并不是事故：没有用户受到伤害，没有信任流失，系统依然在运行。

面向用户的故障则完全改变了权衡逻辑。聊天机器人幻觉出一个退款政策，导致公司随后面临法律压力不得不兑现，这是一个具有真实财务后果的面向用户事故。AI 正在“工作” —— 它返回了响应，解析正确，达到了延迟 SLO —— 但输出造成了损害。

分类问题不仅仅是“系统是否返回了错误？” 而是“系统是否返回了对真实用户造成损害、困惑或信任侵蚀的输出？” 如果是，这就是事故。如果不是，它可能是重要的监控数据，但不是一个需要呼叫 (pager) 的事件。

维度 4：损害状况 —— 可逆 vs. 复合

这是大多数团队重视不足的维度，也是决定 2% 的回归是背景噪音还是 sev-1 事故的关键。

可逆故障在你修复它们时就会停止。回滚提示词、还原模型版本、关闭功能开关 —— 损害就会停止。加拿大航空 (Air Canada) 聊天机器人幻觉出的折扣，虽然航空公司被迫兑现，但这仍是一个可逆事故：令人尴尬、财务损失有限，但影响范围是确定的。

复合故障会不断累积。考虑以下三个复合损害改变分类的情况：

• AI 编码助手开始生成细微的错误代码模式。开发人员未经测试就接受建议。这些模式在问题浮现前已在代码库中传播了三周。修复代码很容易；但补救 18 个月积累的技术债却很难。
• 数据增强流水线使用 LLM 对客户记录进行分类。分类器产生了系统性偏差。这些记录输入到推荐引擎中，引擎基于这些数据进行训练。在有人发现原始问题之前，这种“投毒”已经影响到了下一次模型训练。
• 金融智能体开始做出细微错误的预处理决策。每个单独的决策都在正常波动范围内。但在整个投资组合中，错误会不断复合。

具有广泛每群组 (per-cohort) 范围的可逆故障：sev-1。即使每会话 (per-session) 范围很窄的复合故障：sev-1。面向用户且不可逆的事实性故障：取决于范围，定为 sev-0 或 sev-1。

阈值计算问题

团队经常询问一个简单的规则：“2% 的回归什么时候会变成 sev-2？”

并没有通用的答案，因为正确的阈值是上下文的函数：

• 在内容生成工具中，2% 的事实错误率可能是可接受的基线噪音，通过信任和不确定性 UI 模式清晰地传达给用户即可。
• 在临床决策支持工具中，药物相互作用建议中 0.1% 的事实错误率就是 sev-0。因为可能会有人因此丧命。
• 在法律研究工具中，5% 的引文虚构率对于依赖它的律师来说是职业生涯的终结。

正确的阈值计算涉及两个方面：

统计显著性 vs. 业务显著性。 如果你的样本群组足够大，2% 的回归在统计上是显著的。但统计显著性并不决定严重程度 —— 业务影响才决定。问题不在于回归是否真实存在；而在于该回归的幅度，在那个范围内，以那种损害状况，是否在你特定的部署背景下构成了阈值违规。

随机系统的置信区间宽度。 由于 LLM 的输出是非确定性的，你的置信区间会比确定性软件更宽。在 50 个样本的点检中看起来像是 2% 的回归，在具备足够统计效力的情况下可能是 8% 或 -1%。序列测试方法 —— 在达到全样本量之前就能检测到显著变化 —— 比批量 A/B 测试更适用于 AI 事故检测。问题不在于“我们是否看到了回归？”，而在于“我们是否有足够的信心确定这种回归是真实的，从而宣布发生事故？”

AI 事后分析：没有提交记录的问题

传统的事后分析 (postmortem) 从提交 (commit) 或配置更改开始向后追溯。AI 事后分析则从症状开始向前推导，因为因果链分布在通常没有被刻意更改的各种因素中。

真正重要的问题有所不同：

什么改变了？ 不仅仅是代码。列举：模型版本、提示词模板、few-shot 示例、检索语料库、推理参数 (temperature, top-p, max-tokens)、编排逻辑、输入分布。其中任何一个都可能是原因。如果你希望在事后能够回答这个问题，所有这些都需要进行版本化并记录日志。

哪个群组受到了影响？ 尽可能具体地描述受影响的人群。哪些输入特征、用户细分或执行路径与故障相关？这不仅是为了根因分析 —— 它还告诉你是否需要完全停用该功能，或者在调查期间按群组对其进行限制。

损害是否仍在累积？ 对于复合故障，停止根因并不能消除已经造成的损害。你需要并行回答“是什么导致了这个问题”和“哪些内容已经受到影响并需要补救”。

什么能复现这个问题？ 在没有评估用例 (eval case) 的情况下，不要结束事后分析。对于“因为非确定性而无法可靠复现”的回答是：针对可疑的输入类别运行一千个示例，直到你理解故障率分布。如果你无法在统计上描述故障，你就无法知道你的修复是否奏效。

反事实情况是什么？ 如果系统选择放弃回答而不是直接给出答案，损害是否会更小？许多 AI 事故如果系统能表达不确定性，而不是产生一个自信的错误答案，其严重程度本来会更低。事后分析不仅应评估哪里出了问题，还应评估系统的置信度校准是否加剧了影响。

总结：分类核查清单

当潜在的 AI 事故出现时，在确定严重程度级别之前，请对照此清单进行评估：

1. 范围：这是单次会话（孤立噪声）还是针对特定群体（相关的故障模式）？
2. 故障类型：这是事实性退化（错误陈述）还是风格偏移（表达方式改变）？
3. 可见性：这是面向用户的（用户受到伤害或被误导）还是仅限内部的（监控信号）？
4. 损害特征：解决根本原因是否能停止损害（可逆），还是累积的损害已经扩散（复合型）？

一个被评为“特定群体 + 事实性 + 面向用户 + 复合型”的故障属于 sev-0 或 sev-1 级别。而一个被评为“单次会话 + 风格 + 仅限内部 + 可逆”的故障只是一个监控笔记，而不是一个需要触发报警（pager）的事件。中间情况——如事实性但仅限内部、面向用户但可逆、特定群体但属于风格问题——则需要根据业务背景进行判断。

本文开头提到的法律引用事故？特定群体（涉及文档检索的特定提示词模式）、事实性（伪造的案件名称）、面向用户（提交给了法院）、复合型（无法挽回的法律后果）。这就是 sev-0。严重程度分类并不在乎系统是否在“正常工作”——它返回了响应，没有报错，也达到了延迟 SLO 指标。但其输出造成了不可逆转的现实伤害。这才是严重程度真正衡量的东西。

展望

实际的收获并不是要你把这个框架全盘照搬作为清单。而是要停止询问“AI 坏了吗？”——对于概率性系统来说，这个问题没有稳定的答案——转而开始询问四个更具体的小问题，通过它们的答案组合成一个能够真正驱动正确响应的严重程度分类。

大规模部署 AI 功能的企业需要能够区分分布尾部噪声和结构性故障的严重程度框架。他们需要一套能够在缺乏单一故障代码提交（commit）的情况下依然有效的复盘流程。他们还需要基于业务影响而非通用统计惯例的阈值计算方法。

搞错这些的代价是双向的。如果对概率性噪声反应过度，你会触发没完没了的 sev-1 事故，让值班（on-call）轮换人员精疲力竭，并减缓功能开发进度。如果对结构性故障反应不足，你会在损害发生的六周后才发现其复合型破坏——届时修复问题虽然简单，但补救造成的损失却难如登天。