OpenAI 上线结构化输出：API 响应 100% 遵从 JSON Schema

很多写过大模型接口的开发者，最头疼的事其实很朴素：你明明在 Prompt 里千叮咛万嘱咐「严格输出 JSON，不要任何废话」，大模型却冷不丁给你多加个逗号，或者少给一个关键字段，直接让下游解析代码当场报错崩溃。

OpenAI 终于对这个痛点动刀了。8 月 6 日，OpenAI 在 API 中正式推出「结构化输出」（Structured Outputs）功能，让大模型的输出结果能够 100% 严格贴合开发者指定的 JSON Schema。

伴随这项功能上线的，还有最新的模型 gpt-4o-2024-08-06。在复杂的 JSON Schema 基准测试中，之前的 gpt-4-0613 准确率连 40% 都不到，而新模型配合结构化输出直接拿下了 100% 的满分。

告别反复重试，从底层堵死格式错误

去年 OpenAI 搞过一个「JSON mode」，虽然能确保吐出来的是合法 JSON，但它管不住模型漏字段或者把字段类型搞错。过去一年里，开发者为了稳定接入系统，只能靠写冗长的提示词、引入各种开源验证库，甚至一旦报错就写循环重试代码。

这次 OpenAI 提供了两种调用方式。第一种是针对函数调用（Function calling），在函数定义里加上 strict: true 即可，老款的 gpt-4-0613 和 gpt-3.5-turbo 往后的模型都能直接用。第二种是在 response_format 里传入 json_schema 并开启 strict: true，支持刚发布的 gpt-4o 新版以及上个月推出的 gpt-4o-mini。

为了帮开发者省事，官方的 Python 和 Node SDK 已经原生支持了这个特性。你可以直接把 Pydantic 模型或者 Zod 对象扔进去，SDK 会自己转成 JSON Schema 并完成反序列化。

安全拒答也没有被忽略。如果模型判断请求违规，它不会硬套格式胡说八道，而是在返回中带上明确的 refusal 字段，方便你的业务逻辑捕获处理。

为什么模型这次真能拿 100%？

大模型本质上是个概率机器，单靠调优训练根本做不到百分之百严谨。OpenAI 坦白说，光靠给模型做复杂 Schema 训练，准确率最高也只能堆到 93%。

要彻底解决问题，他们选择在底层推理引擎上做工程拦截，也就是「约束采样」（Constrained Decoding）。系统会把开发者传进来的 JSON Schema 转换成上下文无关文法（CFG）。

模型每吐出一个 token，推理引擎就会实时算出下一个位置符合语法的合法 token 集合，把所有非法 token 的采样概率直接压到 0。只要下一个 token 不可能选错，整个输出格式就绝不会翻车。

业内做约束解码很多是用有限状态机（FSM）或正则表达式，但 OpenAI 选了 CFG。这样做的聪明之处在于能够支持递归结构，比如生成树状 UI 组件或嵌套任务清单时，FSM 很难准确匹配深层括号，而 CFG 轻松搞定。

不过这项技术也有代价。首次传入新 Schema 时，系统需要做语法预处理和缓存，第一次调用通常要多花几秒到十秒，极其复杂的 Schema 甚至要等上一分钟。此外它目前只支持 JSON Schema 的一个子集，而且无法兼容并行函数调用。

为什么重要

在很多人的印象里，给 API 增加一个格式约束只是小修小补，但我们认为，这是把大模型从「玩具聊天框」推向「企业级自动化基础设施」最硬核的一步。

对开发者和产品团队来说，价值是立竿见影的。以前做一个多步骤的 AI Agent 工作流，最怕中间某一步模型吐错了格式导致整条流水线卡死；为了容错，工程团队要写大量的清洗、校验和兜底代码。现在这一整套防御性工程基本上可以砍掉，开发成本和调用延迟都会大幅下降，现在就值得去把核心业务切换过来。

对行业而言，这一步直接掐断了一大批专门做结构化输出外挂库的生存空间。OpenAI 把约束解码直接做进推理引擎的底层调度中，不仅效率高得多，还依托自身算力完成了基础设施级的垄断。

但需要看清的是，结构化输出保住了「壳」，保不住「核」。它能保证字段名叫什么、格式对不对，却防不住模型在字段值里胡编乱造，比如算错公式或给出虚假的答案。把确定性的工程规则与非确定性的模型内核结合，大模型的企业级可用性确实迈了一大步，但最终的内容质量，依然要看模型本身的推理上限。