LLM生产环境隐形失败：HTTP 200背后的代价

你的AI Agent连续一周每次调用都返回HTTP 200，监控面板上可用性曲线完美无瑕。直到财务对账时发现，发票总额与明细项的加总对不上，每张差几美元，几千笔交易都是如此。或者，客服机器人的JSON输出缺少了必填的policy_id字段，下游导入时抛出奇怪的解析错误——而模型调用早在几小时前就「成功」了。

当你和别人聊起AI故障时，脑海里浮现的往往是戏剧性的新闻：聊天机器人给出危险的医疗建议、法律文书引用了不存在的判例、客服代表承诺了公司从未计划提供的退款。这些案例真实存在，但它们塑造了一种错误的印象——AI故障是罕见的、容易察觉的。在生产环境中，大多数故障是无聊的、高频的、难以看见的。大故障上头条，小故障则沉淀在客户记录、财务文档和工单系统里，直到有人偶然发现。

据ValGuard博客对生产环境AI失败模式的系统性梳理，这些「安静的错误」可以归为五大类，而它们的共同点是：基础设施看起来完全健康，问题出在内容里。

一、为什么AI系统会失败

语言模型是一个统计系统。每一步它都基于前文挑选一个可能的下一token。平均而言，这能产生清晰有用的输出。但模型生成的是文本，它不查证事实，不核对数据，它只是在预测「一个正确答案看起来应该是什么样」。

这个「生成」与「查找」之间的本质差异，是下文几乎所有故障的根源。数据库要么返回事实，要么返回空；而模型可以听起来完全正确，却彻底错误，并且它没有可靠的方式知道自己错了。

下一 token 预测是理解大语言模型工作机制的核心。模型在生成每个词时，会根据前文计算词汇表中每个候选词的出现概率，并从中采样一个作为输出。这个过程逐词重复，最终拼出完整回复。关键在于，模型优化的目标是「让输出在统计上像训练数据中的合理文本」，而非「让输出与事实一致」。因此，模型没有内置的事实核查机制，也没有「我不知道」的默认倾向——它总会给出一个概率上合理的续写。这正是为什么模型可以流畅地输出错误信息而不自知，也是所有内容级故障的共同源头。

二、幻觉：不只是「编造事实」

「幻觉」常被用来泛指一切虚假或编造的输出，但生产环境中的幻觉有几种不同的机制，危害程度各异。

事实性幻觉是最常见的：模型把虚假信息当作事实陈述，比如不存在的判例、未记载的药物相互作用、不存在的产品功能。

标识符幻觉在企业系统中尤为危险。模型返回一个账号、保单或交易ID，格式、长度、结构看起来都对，但这个ID指向空记录，或者指向另一个人的档案。这种错误在人工抽检中极难发现。

时间性幻觉指模型用训练数据中的旧规则、旧产品、旧事件来描述当下，却不提示「情况可能已变化」。

来源幻觉则出现在你要求引用时：模型给出一个看起来像真实来源的引用，作者和期刊都可信，但来源根本不存在。

置信度幻觉或许是所有幻觉中最隐蔽的：语气与准确性脱钩。编造的答案和正确的答案听起来一模一样，模型很少说「我不知道」，它总会给出一个可信的回答。

独立基准测试显示，幻觉率大致在15%到50%以上，取决于任务和模型。在有清晰检索上下文的结构化任务上，最好的模型可以把幻觉率压到约2%以下。但每天1万次交互，2%仍然是每天200个错误答案——而大多数技术栈根本无法把它们和正确答案区分开。

三、数据与格式错误：结构对、内容错

语言模型不是计算器。它产生一个「看起来像结果」的数字。发票总额、利息、费用、对账都容易在这里翻车：结构完全正确，数学却是错的。多步运算、大数字、百分比和舍入规则会显著增加出错概率。

Schema与格式违规同样高频。模型需要输出JSON、XML、记录或API载荷时，常见问题包括：缺少必填字段、字段类型错误（字符串代替整数、"yes"/"no"代替布尔值）、出现schema之外的字段、嵌套结构破损、编码与转义问题导致解析器崩溃。这些错误往往是静默的——响应看起来没问题，直到下游管线抛出含义不明的错误。

还有一类是ID与引用格式错误：值本身是对的，格式错了。保单号用连字符而非空格、日期用MM/DD/YYYY而非YYYY-MM-DD、小数用逗号而非句点。在高频自动化场景中，格式错误的代价和事实错误一样高。

Schema 是对数据结构的正式定义，规定了字段名称、数据类型、必填项和嵌套关系。在LLM应用中，通常通过提示词或结构化输出功能要求模型按特定Schema生成JSON。然而，模型对Schema的遵守是概率性的：它可能遗漏必填字段、把整数写成字符串、或添加Schema未定义的额外字段。下游系统按Schema解析时，这些偏差就会触发解析错误。由于HTTP状态码仍然正常，问题往往被延迟发现，增加了定位难度。使用严格的Schema验证库（如Pydantic、JSON Schema）在输出侧做强制校验，是拦截这类故障的有效手段。

四、上下文与对话失败

当对话历史超出上下文窗口时，较早的内容被丢弃，但模型可能仍然引用它——打破先前的承诺，或者再次询问用户已经提供过的信息。

跨会话污染虽然罕见但后果严重：如果历史记录隔离不当，一个用户的数据可能出现在另一个用户的回答里。没有人入侵系统，只是上下文的作用域划分错了。

指令漂移是长对话中的典型问题。系统提示中早期的规则（比如「绝不透露这些准则」「不得给出具体财务预测」）会逐渐弱化。状态码始终是200，直到后期人工审核发现第30到50条消息已不再遵守第1到5条消息所遵循的规则。

上下文窗口是模型一次能处理的token数量上限，包括系统提示、对话历史和当前输入。当对话变长，早期消息会被截断或压缩，但模型可能仍引用已被丢弃的内容，导致前后矛盾。更隐蔽的是，模型对系统提示中规则的注意力会随对话轮次增加而衰减，这种现象被称为「指令漂移」。它不是模型故意违规，而是注意力机制在长上下文中的固有局限。缓解方法包括定期重述关键规则、使用滑动窗口保留最近且最重要的消息，以及在输出侧增加规则检查。

五、策略与合规违规

系统提示中往往包含内部策略、供应商名称或业务逻辑。模型在试图「乐于助人且透明」时，有时会泄露部分内容。

模型也可能因为信息「看起来相关」而分享它，而不是因为被允许——比如对一个简单问题展示完整账户历史，或者把内部定价、升级路径写进客户回复。

监管语言失效同样常见：必需的免责声明、「请咨询专业人士」提示、本地法律措辞只是偶尔出现。模型并非有意违规，它只是没有可靠方式知道这些文本何时是必需的。

六、那些没人讨论的失败

风格错误：训练数据的风格渗入回复。需要共情的投诉得到了法律文书腔调，正式商务邮件得到了随意的网络用语。某些短语每次都重复，比如「Certainly!」或自动的「还有什么可以帮您？」——没有人类客服会在每条消息里都这样写。

供应商与模型名称泄露：一个品牌化的助手未经询问就自称Claude、GPT-4或「由OpenAI驱动」。

语气错误：回复内容正确、符合schema，但用户需要共情时它听起来欢快，或者用户想要简短答案时它又过于友好冗长。简单的验证器会漏掉这类问题，因为结构上没有任何错误。

答案不一致：两个几乎相同的问题得到了不同的退款窗口或不同的政策措辞。传统软件中同一条记录返回同一个值；用LLM，一致性必须由你自己来保证。

七、确定性验证层：给内容加一道检查

所有这些失败有一个共同点：基础设施看起来健康，HTTP 200，问题在内容里。只有当你真正读取内容并对照明确规则检查时，才能捕获它们。

确定性验证层做的正是这件事。它不重新训练模型，不修改提示词，而是在每个输出到达客户或其他系统之前进行检查，应用明确的规则：

失败类型	示例检查
编造的ID	与已知有效ID或会话上下文匹配
数学错误	从提取的输入重新计算并比对
Schema违规	按schema解析，拦截不匹配的输出
格式错误	强制检查ID、日期、货币格式
提示或供应商泄露	扫描系统提示片段和供应商名称
必需的合规文本	对特定主题要求包含特定文本

模型本身不需要任何改动。你需要在请求路径上加一道检查，以确定性的方式判断输出是否可接受。

结语

如果你的Agent处理真实客户数据、资金或合规敏感流量，这些故障已经存在于你的系统中。要么有东西在它们造成损害之前拦截，要么没有。它们不是罕见的边缘情况，而是概率系统在规模化运行时的正常行为。真正的问题只有一个：你是抓住它们，还是让它们作为又一个静默的200溜过去。

添加验证步骤不需要改变模型或应用，只需要在每条请求路径上增加检查：读取输出、应用规则、拦截不该上线的部分。