结构化输出的隐性代价：JSON 模式质量税

大多数团队采用结构化输出，是因为厌倦了用脆弱的正则表达式从模型响应中抽取数据。这个动机合情合理。但他们没料到的是，几个月后当他们真正度量任务准确率时，会发现那次"可靠性提升"同时让推理密集型任务的内容质量下降了 10 到 15 个百分点。语法问题解决了，语义问题却悄然而生。

本文的目的是精确理解这一权衡——约束解码的实际代价是什么、什么时候值得支付这笔税，以及如何在上线前构建评测来判断它是否正在拖累你的系统。

约束解码的工作原理

理解失效模式，首先要理解机制本身。在每个生成步骤中，语言模型会在整个词汇表（数万个 token）上产生一个概率分布。约束解码（JSON 模式、结构化输出 API 以及 Outlines、XGrammar 等框架背后的核心机制）的工作方式是：在采样之前对该分布进行掩蔽，将所有会导致 Schema 不合法的 token 清零，模型只能从剩余合法的 token 中进行采样。

对于 JSON 和正则模式，这一机制通过有限状态机（FSM）实现；对于更复杂的上下文无关文法，则使用下推自动机（PDA）。XGrammar 等库——目前已成为 vLLM 和 SGLang 的默认方案——会提前将 Schema 编译为这些自动机，在推理时实现低于 40 微秒的 token 掩码生成。

问题的根源在于：模型在某一步骤偏好的 token，未必是 Schema 约束下的合法 token。 当排名靠前的 10 个 token 全部被掩蔽时，模型被迫从概率更低的候选中采样。这些候选在语法上是合法的，但在语义上可能是错误的、生硬的或不完整的。在整个响应生成过程中，这些被迫做出的次优选择会不断积累。

语法正确性得到了保证，语义质量却没有。

质量下降的证据

NeurIPS 2024 的研究对约束生成与自由生成后解析两种方式进行了对比，发现约束条件下推理任务的性能下降了 10 到 15 个百分点。原因正如预期：当模型无法自由选择偏好的 token 时，每一步都会做出稍差的决策，而这些错误会在多步推理中不断叠加。

这并不意味着约束生成总是处于劣势。对于较简单的抽取任务——从文本中提取命名字段、固定标签集分类、结构化数据规范化——质量损耗微乎其微。这类任务不需要模型将推理步骤串联起来；它不过是在填写模板，而答案空间本身已经受到约束。约束的代价越低，答案空间本身就越受限。

质量损失最严重的场景包括：

• 多步推理，模型的工作空间就是输出本身（思维链被压缩进 JSON 字段）
• 复杂的嵌套 Schema，字段数超过 10 个或嵌套层级超过两层
• 开放式生成被困在固定字符串字段中（模型的创造力被双重惩罚：既受 Schema 限制，又受 token 掩蔽限制）

研究人员还识别出约束生成中三类结构性输出变异：Schema 变异（模型生成了完全不同的字段结构）、表达变异（语义释义）和语义变异（底层内容的含义发生改变）。只有第一类会被 Schema 验证捕获。

另一面：速度与可靠性

约束解码并非纯粹的成本。对于较简单的 Schema，它通常更快。现代实现可以通过跳过样板内容，将延迟降低 50%。当 Schema 的脚手架是固定的（花括号、字段名、引号），模型只需生成值，约束机制负责其余部分。DOMINO 算法中的推测性解码技术更进一步，能够对可预测的结构区域实现多 token 跳跃。

可靠性提升是真实且显著的：

方式	解析失败率
仅靠提示词工程	5–20%
JSON 模式（无 Schema）	1–5%
带 Schema 的约束解码	<0.1%

一个做金融数据抽取的团队，切换到约束解码后，验证失败率从 27% 降至 2%，提升了 92%。对于解析失败需要人工介入的系统，这是巨大的运营收益。

问题在于，你是否为你的工作负载做出了正确的权衡。如果内容准确率同时下降了 12% 而你没有度量，那 92% 的解析失败率下降意义有限。

服务商的差异不可忽视

各服务商对结构化输出的实现方式不同，差异具有实质性影响：

OpenAI（Strict 模式，2024 年 8 月发布）：服务端 Schema 强制执行，数学上保证 JSON 输出合法，失败率最低。约束在响应到达你之前已经施加。

Anthropic Claude：通过工具调用实现结构化输出，而非语法约束解码。模型经过训练会遵循工具 Schema，但并非通过 token 掩蔽强制执行。失败率视 Schema 复杂度在 0.5% 到 5% 之间。Claude 在复杂推理任务上的语义质量往往优于原生约束方式，但你需要在客户端进行验证。

Google Gemini：带严格 JSON 强制执行的响应 Schema，服务端实现，与 OpenAI 方式相当。在基准测试中对复杂嵌套 Schema 的处理表现良好。

Mistral：JSON 模式强制约束结构形态，但不严格遵守 Schema。需要客户端验证。适用于偶发失败可接受的成本敏感型工作负载。

自托管推理方面：XGrammar（2025 年起成为 vLLM 默认方案）是当前生产级首选。Outlines 使用更简单，但在复杂 Schema 上有编译超时问题——某些模式需要 40 秒到 10 分钟以上——如果 Schema 由用户定义，这会是个大麻烦。

Schema 设计是关键变量

质量税的高低不仅仅取决于是否使用约束。Schema 设计是你能掌控的最大杠杆。

质量下降与 Schema 复杂度高度相关：

• 2–5 个字段，扁平结构：质量影响低于 2%
• 10–20 个字段，2–3 层嵌套：影响 5–10%
• 深层嵌套、大型枚举、大量约束：影响 10–20% 以上

最常见的错误是直接将数据模型转换为 Schema，而不考虑你在要求模型做什么。一个有 40 个字段、一半可选、带嵌套数组和判别联合类型的 Schema，是在要求模型在巨大的约束空间中穿行，同时还要生成正确的内容。约束带来的认知负担和任务本身的认知负担都是真实的，而且会相互叠加。

第二个常见错误是将重要内容埋在深层嵌套结构的字符串字段中。Token 掩蔽适用于生成过程中的所有 token，包括你最重要字段内部的 token。如果模型对一段复杂解释最优的表达方式被外层结构元素的约束所阻断，那这段解释的质量就会下降。

何时选用哪种方案

使用约束解码的场景：

• 你的下游系统直接写入数据库或调用 API，无法容忍解析失败
• 任务是抽取或分类，而非复杂推理
• 你能度量并确认质量税在你的用例中可以接受
• Schema 复杂度低到中等（15 个字段以内，嵌套有限）

解析非结构化输出的场景：

• 任务需要多步推理或开放式生成，占据了大部分响应内容
• 你能实现重试逻辑，偶发解析失败可接受
• 在你的应用中，质量比语法可靠性更重要
• Schema 足够复杂，会引入显著的编译开销

混合方案在实践中往往是正确答案：用一个最小结构约束（只有少量必填字段的扁平 JSON 信封），让模型在文本字段中自由发挥，验证信封结构，但不约束其中的内容。严格 Schema 强制执行只保留给真正需要的字段——标识符、标签、外键——把解释性文本作为非结构化散文处理。

评估你系统中的质量税

生产环境中的典型失效模式是：团队度量解析失败率，并假定这就是在度量质量。其实只是在度量一个代理指标。解析失败率无法告诉你合法输出的内容是否正确。

正确的评估应该在约束和非约束条件下运行相同的任务，使用任务级成功指标（而非 Schema 合法性指标），并度量两者的差值。几个实践步骤：

每种任务类型运行 10 到 20 个样本。 单样本对比会掩盖方差。10 个样本能以合理置信度检测出 10% 的质量差异；20 个样本能发现 7% 的差异。

将任务准确率与解析成功率分开度量。 编写自动化评判器（或使用部分人工评审），评估输出内容是否正确——而不仅仅是是否能解析。这两个指标之间的差距就是你的质量税。

跨温度值进行测试。 约束生成在高温度下退化更快。研究显示温度 ≥ 0.7 时质量损失可达 30% 以上。对于大多数生产环境约束输出系统，温度应保持在 0.1 到 0.3 之间以确保一致性。如果你的应用需要更高温度来保证多样性，约束输出的代价可能尤其高昂。

用你的实际 Schema 做基准测试，而非简化版本。 JSONSchemaBench 等基准测试了 10,000 个真实 Schema，显示出巨大差异。平均基准性能无法告诉你你的特定 Schema——具有特定嵌套、可选字段和枚举大小——能否高效编译并无质量损耗地运行。

在生产中单独监控语义错误和解析错误。 语义错误（JSON 合法但内容错误）是无声的，不会触发你的错误处理程序。建立一个独立的评估通道，对结构化输出进行采样并验证内容准确率，是在它们积累成客服问题之前发现它们的唯一方法。

结论

结构化输出解决了一个真实问题：解析失败运营成本高昂，用户可见的失败令人尴尬。约束解码弥合了这一可靠性差距。但可靠性提升是语法层面的，质量损失是语义层面的。大多数团队只度量了前者，没有度量后者，这就是一项有用的技术如何成为产品上不可见的拖累的过程。

正确的心智模型是把约束解码视为一种交换，而非免费升级。你买到的是语法可靠性，你付出的是一部分语义质量。这笔交换是否合算，取决于你的任务、Schema 复杂度和成功指标——而你只有直接在你的工作负载上度量，才能知道答案。

对于生产系统，默认做法应该是：必须约束的才约束，能放开的就放开，然后运行评测，搞清楚你实际上放弃了什么。