在把大语言模型接入业务系统时，“能生成 JSON”与“能稳定生成可解析、可验证、可消费的 JSON”是两件不同的事。前者只关注输出看起来像结构化数据，后者则要求语法正确、字段完整、类型一致，并且能够长期适配程序接口。结构化输出约束的价值，正是把模型的自由文本生成逐步收敛为可执行的数据契约。
一、JSON 生成为什么容易失稳
LLM 本质上是在预测下一个 Token，而不是调用传统序列化函数。即使提示词明确要求“只返回 JSON”，模型仍可能添加解释文字、Markdown 标记或注释，也可能漏掉引号、括号和逗号。上下文较长、目标结构复杂或输出接近长度限制时，这类问题更加明显。
语法正确也不代表业务可用。例如程序期望字段“score”为数字，模型却返回字符串；要求固定字段“items”，模型却改成“results”；预期数组，实际得到单个对象。这些结果可能顺利通过 JSON 解析，却会在类型转换、数据库写入或后续接口调用时失败。
二、结构化约束可以分为哪些层级
1. 仅通过提示词描述格式
最基础的做法是在提示词中给出字段定义、示例和“禁止输出额外内容”等要求。它实施简单，兼容多数模型，但属于软约束。模型知道期望格式，却仍有机会偏离，因此更适合原型验证或允许人工检查的场景。
2. 使用 JSON 模式
JSON 模式通常能够约束输出成为语法有效的 JSON，显著减少代码围栏、前置说明和括号不闭合等问题。不过，它主要解决“是否为合法 JSON”，不一定保证字段名称、数据类型、枚举值和嵌套层级符合业务预期。因此，JSON 模式提高的是语法解析成功率，而不是完整的模式匹配率。
3. 使用 JSON Schema 与受约束解码
更严格的方案是使用 JSON Schema 描述对象属性、必填字段、类型、数组元素和可选值，再在生成阶段限制模型只能选择不会破坏该结构的 Token。JSON Schema 本身是一种用于描述和验证 JSON 文档结构的声明式语言，相关定义可参考 JSON Schema 规范。
与生成后再提示模型“修复 JSON”相比，受约束解码把控制点前移到了生成过程。它能够阻止许多不合法的续写路径，例如在数字字段中输出普通文本，或者在禁止额外属性时随意增加字段。这样不仅减少语法错误，也能降低模式校验失败的概率。
三、约束如何影响稳定性与解析成功率
第一，输出边界更明确。自由文本可能混入解释、免责声明或格式标记，而严格结构规定了根节点必须是对象还是数组，使解析器不再需要通过正则表达式截取 JSON 片段。
第二，字段形态更一致。通过 required、type、enum 和 additionalProperties 等规则，可以减少字段缺失、类型漂移和未知属性。下游程序能够按照固定数据模型处理结果，不必为每种异常结构编写分支。
第三，重试和修复成本下降。如果系统先生成自由文本，再解析、校验、修复和重试，每个环节都会增加延迟与复杂度。生成阶段的硬约束可消除一部分格式类故障，但仍需处理请求超时、输出截断、模型拒答和业务信息不足等异常。
结构化约束提高的是“结果符合机器接口要求”的稳定性，并不自动提高事实准确性。一个完全符合 Schema 的 JSON，字段值仍可能存在理解错误、信息缺失或不可靠推断。
四、约束并非越严格越好
Schema 过于宽松时，约束效果有限；过于复杂时，又可能增加生成难度和维护成本。深层嵌套、大量枚举、冗长字段名以及复杂条件组合，会扩大接口设计与模型能力之间的摩擦。部分平台只支持 JSON Schema 的子集，因此不能假设所有关键字都能直接用于受约束生成。
另一个常见问题是把“未知”与“缺失”混为一谈。如果业务字段必填，但原始材料没有答案，模型可能为了满足 Schema 而猜测一个值。更稳妥的设计是明确允许 null，或者增加 status、confidence、evidence 等字段，使模型能够表达“无法确定”，而不是被迫填充看似完整的数据。
五、面向生产环境的实践建议
- 从最小 Schema 开始：只保留下游真正需要的字段，减少无意义的嵌套与重复信息。
- 统一字段语义：在 description 中说明单位、时间格式、空值规则和枚举含义，避免只定义类型而不定义业务口径。
- 继续执行服务端校验：即使采用严格结构化输出，也应使用标准解析器和 Schema 校验器，不要直接信任模型响应。
- 区分错误类型：分别记录 JSON 语法错误、Schema 不匹配、输出截断、拒答和业务校验失败，避免把所有异常归为“解析失败”。
- 建立真实样本测试集：覆盖空输入、长文本、多语言、特殊字符、字段缺失和边界数值，并比较不同模型、Schema 版本及参数设置。
- 保存原始响应：在符合隐私和安全要求的前提下保留必要日志，便于定位是模型生成问题、传输问题还是解析器问题。
六、应该如何衡量实际效果
评估结构化输出时，不能只统计“请求是否成功”。建议至少观察语法解析成功率、Schema 校验通过率、业务规则通过率、首次成功率、重试次数和端到端延迟。只有语法解析成功而业务校验失败，说明约束仍停留在格式层面；Schema 校验通过但人工抽检错误较多，则说明需要改进提示词、输入信息或业务定义。
测试结果还应建立在自身任务和真实数据上，而不是直接照搬供应商或第三方公布的数字。模型版本、模式复杂度、输入长度、语言和采样配置都会影响表现。持续回归测试通常比一次性的准确率结论更有参考价值。
总结
LLM 的 JSON 稳定性取决于约束层级：提示词提供方向，JSON 模式保障基本语法，JSON Schema 与受约束解码进一步约束字段和类型。严格结构化输出能够显著减少格式漂移、解析异常与脆弱的后处理逻辑，但不能替代事实核验、业务校验和异常处理。生产系统应以精简 Schema 为契约，以服务端验证为防线，以真实样本回归测试为依据，最终把“模型通常能返回 JSON”升级为“系统能够可靠消费结构化结果”。
