一项针对 12 个大语言模型 (LLM) API 的新基准测试发现，几乎所有服务返回的 JSON 都符合请求的 schema，但相当一部分服务会输出事实错误的值。相同 schema 的 token 成本从几十个 token 到近五千个不等。构建提取流水线或数据驱动型智能体的开发者不能再将“schema 有效”视为“正确”的代名词。

为什么这项测试很重要

API 提供商一直将“结构化输出”吹捧为消除解析错误的一种方式。其承诺很简单：给模型一个 JSON schema，它就会填充字段，而无需你编写脆弱的后处理代码。在实践中，许多生产系统已经依赖这一保证来避免崩溃并保持下游分析流水线的整洁。当这种保证仅能实现一半时，错误会悄无声息地潜入，而基于 token 使用量的成本计算也会出现巨大偏差。

好消息：schema 现在基本得到了强制执行

  • 测试套件中的大多数模型生成的 JSON 都能通过严格的验证器。
  • 约束解码 (Constrained decoding) —— 将解码器锁定在 schema 上的模型无法发出多余字符，因此格式错误的负载几乎绝迹了。
  • 解析错误率 —— 开发者不再需要为了 JSON 语法错误而将每个调用都包裹在 try-catch 块中。

坏消息：有效性 ≠ 准确性

有效的结构并不保证有效的值。12 个模型中有 4 个——DeepSeek V4、Qwen 和 GLM-5.2（后两者在报告中以两个不同的名称出现）——在开启“思考”（或思维链/chain-of-thought）模式时，会生成格式完美但包含错误数字的 JSON。

  • 在 Qwen 模型上，一个简单的算术提取任务，在启用推理时仅有 16 个答案中 1 个正确，而在禁用推理时则为 8 个答案全部正确。
  • DeepSeek V4 Pro 也表现出类似的波动：一旦模型停止尝试解释其步骤，提取准确率就从 1/8 提升到了 7/8。

额外的推理步骤会干扰约束解码器，使模型在遵守外部括号的同时，陷入幻觉之中。

糟糕的一面：token 成本意外和被忽略的参数

  • Claude 的响应格式 —— 当通过兼容 OpenAI 的端点访问时，Claude 完全忽略了 response_format 标志，返回的 schema 合规输出率为 0%。该模型确实支持结构化调用，但仅限于通过 Anthropic 原生的 tool-call 接口。
  • Schema token 通胀 —— 一个仅 12 KB 的 schema 在 DeepSeek 上仅花费 30 个 token，但在 Claude 上同样的负载却消耗了 4,959 个 token。
  • 计费不一致 —— 一些提供商将 schema 视为 prompt 的一部分，对它消耗的每个 token 进行计费；而另一些则将其视为免费的叠加层。在大规模应用时，schema 的账单可能会超过模型生成内容的成本。

开发者现在该怎么做

  1. 验证值，而不仅仅是结构 —— 即使数值符合预期类型，schema 验证器也不会捕捉到错误的数值答案。应增加特定领域的检查（范围、单位、跨字段一致性）。
  2. 在需要可靠的字段填充时，在 DeepSeek、Qwen 和 GLM 上关闭用于提取任务的思维链 (chain-of-thought)。额外的推理步骤是可选的，并非保证正确性所必需。
  3. 审计 token 使用情况 —— 记录每个请求消耗的 token 数量（包括 schema 部分），并在进行大规模部署之前比较不同供应商的账单。
  4. 测试可移植性 —— 在 OpenAI 上有效的 schema 在 Gemini 或 Claude 上可能会被悄悄忽略。在发布代码之前，请在每个目标平台上进行快速的完整性检查。

供应商的反驳观点

一些提供商辩称，“思考”模式是开发者的一种选择，适用于解释比原始提取准确性更重要的任务。Claude 忽略了 response_format 标志，并建议改用 Anthropic 原生的 tool calls。这些解释在技术上是正确的，但它们将负担转移到了开发者身上，要求开发者知道该选择哪种模式，以及如何为隐藏的 token 费用进行预算。

总结

JSON schema 不再是安全网，它仅仅是一个形状。请确保其中的数据符合事实，密切关注隐藏的 token 成本，并记住模型的“思考”过程可能会破坏即使看起来最整洁的输出。