AI 流水线异常处理：幻觉、拒绝和格式违规是一等公民错误
你的 AI 流水线昨晚报告了零错误。但输出结果完全是错的。
这不是假设。一份近期的行业报告发现，大约每 20 个生产环境 LLM 请求中，就有 1 个以永远不会触发异常的方式失败——HTTP 200、格式正确的 JSON、流畅的散文，但内容却是错的。可观测性系统保持绿灯，而流水线却在悄悄地欺骗用户。
根本原因是一个从传统服务工程中借来的架构假设：HTTP 状态码和解析错误覆盖了所有故障空间。但事实并非如此。LLM 流水线至少有四种底层基础设施看不到的故障类型——幻觉、拒绝、格式违规和上下文溢出——把它们当作边缘情况而非一等公民错误类型来处理，正是生产 AI 系统如何大规模传播隐性 Bug 的根源。
错误日志未能捕获的故障分类
传统异常处理是二元 的：请求要么完成，要么抛出。LLM 流水线打破了这一模型，因为一个已完成的请求可能代表多种截然不同的故障状态，每种状态都有不同的原因和不同的补救路径。
事实性幻觉是讨论最多但检测最少的故障类型。模型返回了一个自信、连贯但与现实相悖的响应。系统提示中没有关于事实核查的内容。下游应用将响应视为权威来源。流水线指标显示成功。关于下一词元训练目标的研究解释了这在结构上为何会发生：模型被训练为产生合理的延续，而不是在猜测时发出不确定信号。自信的错误是训练目标的特性，而非 Bug。
指令拒绝是工程师经常与格式违规混淆的独立类别。当模型拒绝时，它确实理解了请求——它只是选择不遵从，要么是因为安全策略（"不应该"），要么是声称无法做到（"不能"）。这两种子类型需要不同的处理程序。对合法业务任务的"不应该"拒绝通常意味着系统提示错误地触发了安全分类器；解决办法是重新措辞。对模型真正无法完成的任务的"不能"拒绝意味着你需要的是不同的能力，而不是换个说法的提示词。如果不加以区分，重试循环将会浪费大量 Token 去解决错误的问题。
模式和格式违规看起来是最容易处理的问题，但前提是你必须将其视为错误。故障模式是在应用层面变通处理格式错误的 JSON 响应（"只需去掉尾随逗号"），而不是将其视为生成步骤失败的信号，并需要采用不同策略。在 Token 压力下、当模式定义不明确时，或者当模型根本未能内化输出契约时，模型会可靠地产生语法无效的输出。
上下文溢出和上下文腐化更为微妙。溢出是硬限制：输入超过了模型的上下文窗口，截断了关键信息。腐化则更为隐蔽：随着相关信息被埋在长上下文的中间，准确性会明显下降，这在达到任何硬限制之前就会发生。
研究表明，在复杂任务中，有效上下文窗口通常远小于宣传的最大值，被推到中间位置的相关块可能导致准确性下降 30% 或更多。一个将完整对话历史、检索结果加上长系统提示全部塞入的系统不会可靠地失败——它只会悄悄地表现不佳。
为什么这些故障是静默的
基础设施健康与行为可靠性之间的可观测性差距是核心问题。当你部署传统微服务时，运营健康和功能正确性是紧密耦合的：如果服务返回垃圾数据，它通常会抛出异常，请求失败，错误计数器递增。你会收到告警。
LLM 打破了这种耦合。模型的工作是以输出格式生成合理的文本，无论内容是否正确、安全分类器是否误触发，或者输入是否超过了其有效推理能力，它都会这样做。应用层收到一个格式良好的 200 响应并继续处理。
在多步骤流水线中，这种情况会更加复杂。第二步产生的幻觉实体名称在第三步成为检索查询，返回无结果，触发第四步的回退，返回通用内容，最终作为答案呈现给用户。没有任何步骤抛出异常。故障以任何单一错误处理程序都无法捕获的方式分散在整个流水线中——而用户只看到一个自信的错误答案。
2025 年流传的制造业案例清楚地说明了这一点：一个 AI 系统遇到了不熟悉的产品包装，并将其解读为错误信号，触发了额外的生产运行。当故障被发现时，已经生产了数十万件多 余的产品。每个独立组件都按照其本地成功标准"正确地"运行了。系统在整体层面是错误的。
检测：处理之前你需要什么
检测不到的故障是无法处理的。每种错误类型都需要不同的检测策略。
对于幻觉，最具生产可行性的方法是一致性检查和基础验证。一致性检查（对同一输入多次采样模型并测量一致性）之所以有效，是因为具有真实知识的模型产生稳定的输出，而幻觉细节则会变化。开销是真实存在的——你需要多次推理调用——因此将其保留给高风险输出。基础验证将输出中的每个声明与检索到的上下文进行比较；不受支持的声明会被标记。这每次调用更便宜，并且自然地与 RAG 流水线集成。
对于拒绝，检测是基于模式的。拒绝输出具有可识别的结构特征——类似"我无法"、"我不能协助"、"我没有关于……的信息"的短语——基于真实拒绝数据训练的轻量级分类器优于启发式关键词匹配。关键步骤是区分拒绝和合法的简短响应。"不"是一个有效答案；"我无法提供关于此主题的信息"是一个拒绝。这种区别很重要，因为你对它们的处理方式不同。
