大语言模型结构化输出

大语言模型结构化输出，是指让模型按照预先定义的数据结构返回内容，使程序可以更稳定地读取字段、类型和取值范围。常见形式是 JSON，但结构化输出并不限于 JSON，也可表现在工具参数、函数调用或其他可解析格式中。它解决的是模型与软件接口之间的表达约束问题：例如，客服系统希望抽取订单号、问题类别和摘要，而不是每次都收到格式各异的一段自然语言。

“结构化输出”在不同服务商的产品文档中可能指不同 API 能力、模型支持范围和 Schema 子集，并非所有平台共同遵循的一项单一行业功能标准。OpenAI 将自家 API 功能命名为 Structured Outputs；本文借此说明一般概念，同时把具体参数和版本边界限定在 OpenAI 官方文档。接入其他模型服务时，应以其对应版本文档为准，不能因为名称相近就推定参数兼容。

判断结构化结果至少要分开看三个层次。第一层是语法：输出是不是可解析的 JSON。第二层是结构：对象是否有要求的字段、字段类型是否符合 Schema、枚举值是否在约定范围。第三层是语义与业务规则：字段值是否真实、完整、符合上下文，并且满足应用约束。前两层可以由格式和 Schema 机制帮助控制，第三层通常需要来源核验、业务逻辑检查或人工审核。

例如，假设某系统要从发票文字中提取币种、金额和日期。Schema 可以要求金额为数字、日期为字符串、币种只能从给定枚举中选择；它无法仅凭输出格式保证识别到的金额就是原文金额，也无法判断币种和税额是否符合业务规则。模型可能返回格式完全合格但内容错误、信息缺失或依据不足的结果。结构合规不等于事实准确，更不等于法律、财务或安全结论正确。

OpenAI在2024年8月6日的发布说明中，将 Structured Outputs 定位为比早期 JSON mode 更严格的接口能力。两种方式都以合法 JSON 为目标；JSON mode主要约束输出语法，不保证结果符合某一特定 Schema。Structured Outputs 则可在支持的模型和Schema范围内，要求结果遵循开发者提供的结构。由此，若应用只需可解析对象，JSON mode可能够用；若调用方依赖固定字段与类型，Schema约束更契合。

这不意味着“任意JSON Schema都能传入”或“任何模型都支持”。截至2026年10月6日，OpenAI当前开发文档把Structured Outputs描述为仅支持JSON Schema的一部分；某些关键字、嵌套结构或特定模型组合可能不受支持，严格模式下传入不兼容Schema会导致请求错误。文档也对微调模型列出额外限制。工程上应使用目标模型实际支持的子集、为Schema建立兼容性测试，并在切换模型快照或端点时重新验证。

OpenAI文档区分两类使用方式。若模型要把结构化答案返回给用户界面或业务程序，通常使用响应格式：在Chat Completions中通过 response_format 配置 JSON Schema，在Responses API中通过 text.format 设置格式。若模型要请求应用调用数据库、搜索服务或界面函数，则使用工具或函数调用，让模型提出带结构参数的调用请求。前者约束回答的形状，后者表达模型打算调用什么功能及其参数；二者不能只看“都是JSON”就混为一谈。

工具调用本身也不是授权或执行的同义词。模型输出一个看似合格的参数对象，并不代表应用必须执行该操作。通常由宿主程序校验参数、检查用户权限、核对目标资源，再决定是否调用对应函数；对于付款、删除或对外发送等有实际后果的动作，还应设计相应审批与确认。Schema能够限定字段，却无法代替权限控制，也不能证明模型理解了工具的业务含义。

从使用者视角看，开发者提交Schema、提示和上下文，模型返回受约束的结构化结果，SDK可进一步把结果解析为程序语言中的数据对象。OpenAI早期介绍说明其方法结合了模型训练与约束输出的工程机制；具体实现会随服务、模型和版本演进。使用方通常无需自行实现解码算法，但需要把Schema视作接口契约：明确字段含义，使用稳定的类型和枚举，控制嵌套复杂度，并通过评测检验模型是否把正确内容映射到正确字段。

一个稳妥的集成流程通常包含：先定义并版本化Schema；再用目标模型和代表性样本测试常规、缺失、矛盾和边界输入；随后检查输出状态、解析错误和业务规则；最后才把经过验证的数据传给下游系统。字段名可读、描述具体，有助于模型理解字段含义，但不能代替程序校验。应用应保留未匹配、需要澄清和来源不确定等状态，而不是强行把所有内容填进看似完整的结构。

Structured Outputs并不表示每次请求都会返回一个满足Schema的完整对象。官方文档指出，安全拒答可能通过独立的 refusal 信息表达，而非照常填充用户定义的字段；达到最大输出限制时，结果也可能不完整。流式传输还可能只收到部分片段。调用端需要分辨正常完成、拒答、不完整、解析失败和API错误，避免把缺少的字段静默替换成默认值后继续执行。

如果Schema校验失败，重试可以作为一种工程策略，但并非所有失败都适合重试：原文缺少信息时，重复请求可能只制造看似确定的猜测；安全拒答也不应被当成格式错误而反复绕过。更稳妥的处理可能是返回待人工核查、询问用户补充，或明确标注无法提取。要不要重试以及最多重试几次，应由应用基于错误类型和成本设计，而不是认为格式约束会消除所有边界情况。

Structured Outputs是API层能力，具体可用性受服务商、端点、模型家族、快照、Schema关键字和SDK版本影响。OpenAI文档当前同时展示Responses API与Chat Completions的不同参数形式；历史发布说明中的模型列表不能自动视作2026年仍完整适用的兼容清单。升级时应固定并记录模型快照、端点、SDK版本与Schema版本，查阅当前官方支持表，在预发布环境跑回归测试，并为接口返回值保留异常分支。

因此，这项能力最适合减少格式漂移、提高抽取和路由结果的可解析性。它可以帮助构建表单提取、分类、结构化摘要、界面组件数据或工具参数等应用，但其输出仍需结合权威来源和业务规则验证。把模型的流畅回答转换为结构良好的对象，只解决了数据接口的一部分；真实性、安全性和业务正确性仍取决于完整系统。

• OpenAI：Introducing Structured Outputs in the API，2024年8月6日
• OpenAI API开发文档：Structured model outputs（Responses API）
• OpenAI Responses API创建响应参考