生产环境中的结构化输出可靠性：为什么 JSON 模式并非契约

一个团队发布了一个文档提取流水线。它使用了 JSON 模式。QA 通过了。监控显示解析错误接近于零。六周后，一个隐蔽的失败浮出水面：语料库中的每一份风险评估都被标记为 “低” —— JSON 格式有效，字段名称正确，但答案是错的。该流水线已经在以符合架构（Schema）的格式自信地撒谎了好几周。

这是将 JSON 模式视为可靠性保证的核心问题。结构一致性（Structural conformance）和语义正确性（Semantic correctness）是系统的不同属性，混淆两者是生产级 AI 工程中最代价高昂的错误之一。

JSON 模式到底保证了什么

OpenAI 在 2023 年 11 月推出的 JSON 模式只保证一件事：输出将符合有效的 JSON 语法。没有未闭合的括号，没有多余的逗号，没有包裹响应的散文式文字。这就是保证的全部范围。

它对以下内容只字未提：

• 你的代码所期望的字段是否存在
• 字段值是否具有下游代码所假设的类型
• 数据内容是否准确、相关或在逻辑上一致
• 模型的结论是否源自输入

架构强制的结构化输出（Schema-enforced structured outputs）是下一个演进阶段，提供商将你的 JSON Schema 编译成一个约束 Token 生成的有限状态机 —— 这增加了更强的保证。OpenAI 在 2024 年 8 月发布的严格模式（Strict mode）可以将语法和架构一致性的失败率降低到 0.1% 以下。Anthropic 在 2025 年末增加了原生的结构化输出支持。到目前为止，每个主流提供商都有某种形式的架构强制生成。

但 “符合架构” 和 “正确” 仍然是两个独立的属性。一个具有完美架构强制执行力的系统可以可靠地产生 {"sentiment": "positive"}，语法有效、类型正确且枚举值有效 —— 但仍然可能有 30% 的时间是错误的。

生产环境中真正重要的三种失败模式

失败模式 1：负载下的架构违规

尽管有提供商的保证，架构违规在生产环境中确实会出现。它们集中在特定条件下：输出非常长导致模型在最后段落发生漂移；深度嵌套的架构导致受约束的解码器难以在数百个 Token 中跟踪括号；以及高并发场景下，某些编排层中的微妙竞态条件与流式解析器发生交互。

仅通过 Prompt 的 JSON 提取 —— 没有受约束的解码，只有 “输出 JSON” 的指令 —— 在处理数百万次请求的生产系统中，有 8–15% 的调用会失败。即使有受约束的解码，失败只是发生了转移而非消失：它们从解析失败变成了拒绝响应（Refusal responses），即模型生成了触发安全机制的拒绝信息，而不是符合要求的输出。

实际意义在于：你仍然需要处理解析错误。一个返回模型拒绝而非有效 JSON 的架构强制端点，仍然会使预期结构化数据的下游解析器崩溃。

失败模式 2：语法有效但语义错误的输出

这是在生产系统中悄无声息地致命的失败模式。架构通过了。类型匹配。值在枚举范围内。但数据是错的。

“置信度总是 0.99” 的模式是最清晰的例子：一个分类器无论输入质量如何，始终输出 {"label": "positive", "confidence": 0.99}，因为架构中没有任何内容约束 “置信度” 实际上应该衡量什么。模型学到高置信度是常态，并无条件地产生它。

字段顺序（Field ordering）会带来一种更微妙的变体。如果你的 JSON Schema 将答案字段放在推理字段之前 —— {"answer": ..., "reasoning": ...} —— 受约束的解码会迫使模型在生成推理之前就必须确定答案。这直接损害了思维链（Chain-of-thought）的质量。与自由格式生成相比，在受约束生成下进行推理的模型在复杂任务上的性能下降了 10–15%，而架构字段顺序是导致这一差距的重要驱动因素。解决方法是机械式的：在你的架构中，始终将推理字段放在结论字段之前。

必填字段（Required fields）引发了另一类语义失败。当给定输入时，如果一个必填字段没有好的答案，模型会产生幻觉。它会生成一个包裹在有效语法下的自信谎言，而不是表达不确定性。强制每次调用都填充所有字段的架构，实际上是在模型无话可说时暗示它去捏造。

失败模式 3：模型更新后的隐蔽行为漂移

加载中…