结构化输出是大模型从“聊天玩具”变成“生产力工具”的关键一步。当你要求模型返回一段 JSON 用于下游程序解析时，经常会遇到各种意外：字段名拼错、引号缺失、输出前后夹杂解释性文字，甚至把整个对象包在 markdown 代码块里。这些问题在演示环境里只是小麻烦，在生产环境中却是事故源头。业界目前有两类主流解法：一是应用层的 JSON Mode，二是推理层的 Grammar Constrained Decoding。两者思路完全不同，效果和代价也有明显差异，值得认真比较一番。
为什么模型会输出格式错误
首先要理解一个事实：大模型本质上是一个“下一个 token 预测器”，它并不知道什么是合法的 JSON。模型在训练语料中见过大量 JSON 文本，所以能模仿出大致正确的结构，但这种模仿是概率性的。当上下文变长、逻辑变复杂时，某个位置上“不太规范”的 token 概率可能会超过规范 token，错误就这样产生了。
常见的错误形态可以归为几类：第一类是结构性错误，比如括号不闭合、多余的逗号、字符串未加引号；第二类是夹带内容，模型在 JSON 前后输出“以下是您要的结果”之类的说明文字；第三类是字段漂移，比如要求输出 user_name，模型却输出了 userName 或 name；第四类是幻觉值，结构对了但枚举值不在允许范围内。应用层的重试和正则修补只能缓解前两类，对后两类基本无能为力，这就需要更强的约束机制。
另一个容易被忽视的原因是采样温度。即使在提示词里反复强调“只输出 JSON”，temperature 较高时模型仍可能“创造性发挥”。单纯调低温度又会牺牲内容质量，所以仅靠提示工程不是长久之计。
JSON Mode：应用层的便捷方案
JSON Mode 是各大模型 API 普遍提供的功能，OpenAI、Anthropic、Mistral 等厂商都有对应参数。它的基本思路是在系统层面注入格式指令，并配合采样策略调整，引导模型输出可解析的 JSON。使用起来非常简单，以 OpenAI 风格的 API 为例：
from openai import OpenAI
client = OpenAI()
resp = client.chat.completions.create(
model="gpt-4o-mini",
response_format={"type": "json_object"},
messages=[
{"role": "system", "content": "你是一个数据提取助手，只输出合法的 JSON。"},
{"role": "user", "content": "从这段话中提取人名和职位：张三是阿里巴巴的高级工程师。"}
]
)
print(resp.choices[0].message.content)
需要注意的是，开启 JSON Mode 后通常必须在提示词中显式描述期望的 JSON 结构，否则部分厂商会直接报错或效果大打折扣。它的优点是接入成本几乎为零、兼容所有主流 API，缺点是约束粒度太粗：只能保证“输出是合法 JSON”，不能保证字段名、类型、取值范围符合你的 Schema。换句话说，模型可能返回一个语法正确但字段完全不符的 JSON，下游解析依然失败。
JSON Mode 更接近一种“软约束”。它提升了输出合法 JSON 的概率，但没有从数学上排除非法输出的可能性。对于容错性强、字段简单的场景，比如让模型自由生成一段摘要 JSON，它足够用；但对于接口对接、数据入库这类严格场景，就需要下面的硬约束方案了。
Grammar Constrained Decoding：推理层的硬约束
受限语法解码的核心思想是：在每一步 token 采样前，先根据语法规则判断哪些 token 是“合法的下一步”，把不合法 token 的概率直接置为零。这样无论模型怎么“想”，它都不可能生成违反语法的输出。数学上可以证明，这种做法等价于在语法约束的条件分布上采样，输出的合法性是百分之百保证的。
具体实现上，推理引擎会把 JSON Schema 或 EBNF 语法编译成状态机，每生成一个 token 就推进状态，再结合状态计算合法 token 集合。以 llama.cpp 为例，可以通过 json_schema_to_grammar 工具把 JSON Schema 编译成 GBNF 语法文件，然后在推理时加载：
# 将 JSON Schema 转换为 GBNF 语法 python json_schema_to_grammar.py schema.json > person.gbnf # 使用语法约束运行推理 ./llama-cli -m model.gguf --grammar-file person.gbnf \ -p "从以下文本提取信息：" -n 256
对应的 JSON Schema 大致是这样的，它精确规定了字段名、类型和必填项：
{
"type": "object",
"properties": {
"name": {"type": "string"},
"title": {"type": "string"},
"skills": {
"type": "array",
"items": {"type": "string"}
}
},
"required": ["name", "title"],
"additionalProperties": false
}
除了 JSON，语法约束还能约束任意格式，比如让输出严格匹配日期格式、SQL 的 WHERE 子句，甚至自定义的领域特定语言。这对 Agent 工具调用、命令解析等场景非常有用。代价方面，约束解码会带来一定的推理开销：每步都要做状态机转移和 token 掩码计算，实际测试中延迟增加通常在 5% 到 20% 之间，取决于语法复杂度。另外，如果语法写得过死，模型可能陷入“被迫输出某个 token”的困境，导致内容质量下降或提前结束生成，所以 Schema 设计要给内容留出足够自由度。
如何选择：场景、成本与质量权衡
两种方案不是互斥的，实践中常常组合使用。如果你的模型跑在第三方 API 上，且业务对格式要求只是“能解析成 JSON 即可”，JSON Mode 是性价比最高的选择，改一个参数就能上线。如果你的模型是自部署的开源模型（如 Llama、Qwen、DeepSeek），且下游是严格的程序解析、数据库写入或另一个模型的输入，那么语法约束解码是更可靠的方案，配合 vLLM 的 guided_json 参数或 llama.cpp 的 GBNF 文件都能落地。
还有一个折中策略：用语法约束保证结构，用提示词控制语义。例如 Schema 中把字段类型定义为 string，但在提示词中说明该字段的取值规范，这样既避免了语法过紧导致的质量下降，又保证了结构稳定。另外建议在下游始终保留一层校验，比如用 Pydantic 做一次模型验证，毕竟“格式正确”和“内容合理”是两回事，约束机制只负责前者。
总结一下选型原则：追求接入速度选 JSON Mode，追求输出确定性选语法约束解码；能自部署就尽量上硬约束，只能调 API 就 JSON Mode 加重试加校验兜底。结构化输出这条路，本质上是在模型的自由度和工程的确定性之间找平衡点，理解了这两种方案的原理，你就能根据业务特点做出合理取舍。