结构化输出不是"求模型听话"，是推理器在解码时的约束工程

很多生产团队遇到同一个问题：模型答得挺流畅，但返回的 JSON 偶尔会缺个括号、多个逗号、字段名打错，下游解析一报错，整条流水线就断。于是有人把锅甩给"模型不稳定"，也有人试图靠 prompt 反复叮嘱"一定要输出合法 JSON"。

这不是提示词能解决的。结构化输出（structured output）在真正做对的地方，根本不在模型层，而在推理器的解码阶段。今天用工程视角拆开看：系统是怎么在"一个字一个字往外蹦"的过程里，硬性保证结果符合语法。

约束解码：让词典先"失去自由"

大模型生成 token 时，每一步都在一个完整的词表上做概率采样。自由生成意味着任何一个 token 都可能被选到，所以"{"后面跟什么，是概率决定的，理论上可能出错。

约束解码（constrained decoding / guided generation）做的就是：把词表根据当前已经生成的前缀和你的 schema，动态剪枝。比如你知道接下来必须出现一个合法的 key，就把所有不是合法字段名的 token 概率直接压成 0，再在剩下的里面采样。模型不是"被劝着"服从，而是物理上没法选错。

实现上有几条路线，差别很大：

- **正则约束**：用正则表达式编译成有限状态自动机，decoder 每一步只允许匹配状态可转移的 token。轻量、快，但表达能力有限，复杂 JSON 的嵌套规则写哭了。

- **JSON schema 编译**：把 schema 编译成上下文无关文法（CFG），再转成自动机。能处理嵌套对象、数组、条件字段，是目前生产上最常见的一类做法。

- **上下文无关文法通用方案**：支持自定义语法，灵活度最高，但配置不当容易让采样空间过度收窄。

这三条路线都在同一个原理上：把"允许的下一步"从整个词表缩到合法子集，解码速度反而可能变快，因为可选项少了，但框架本身的校验开销要另算。

为什么不能只靠"再试一次"

最朴素的替代方案是：让模型自由生成，解析失败就重试。听起来简单，实际在成本敏感的场景里很吃亏。

第一，重试会让延迟和 token 成本出现长尾。一条高频调用，正常 200 毫秒，一旦失败重试可能就是翻倍再加。第二，重试是概率性的缓解，不是保证，极端情况下一次调用可能失败好几轮。第三，很多下游系统对"一次就给对"有硬性要求，比如支付回调、CI 触发，等不起轮询。

约束解码的价值正在于此：它把"输出合法"从概率事件变成确定事件，牺牲的是 token 选择上的些许灵活度，换来的是端到端的确定性。

真正要权衡的工程取舍

结构化输出不是银弹，有几个坑在实践中几乎绕不开。

一是**速度与质量的平衡**。约束过度收紧，采样空间过小，模型可能在某些任务上表现变差，因为它没法"自由发挥"绕弯。实践上是给 schema 留出合理的自由字段（比如 description 用 string，别把枚举收得太死）。

二是**错误信息要可读**。即使有约束，字段内容本身仍可能不符合业务规则，比如日期格式对、但日期是未来的。这时候 decoder 帮不了你，业务校验必须放在上层。别把"语法合法"误当成"语义正确"。

三是**多语言与 token 边界**。中文、日文这类 token 化方式特殊的语言，在逐 token 约束时容易出现边界问题，字段值里的空格、换行被插件吃掉，这类 bug 排查起来很费时间。

结语

结构化输出的本质，是把"格式正确"从模型的概率行为，挪到推理器解码阶段的确定性工程里。它不是让模型更听话的玄学技巧，而是一套具体的约束与自动机实现。下次遇到 JSON 解析失败，别再堆 prompt 提示词了——先看你的推理框架支不支持 guided decoding，把格式保证从 prompt 层搬到解码层，这才是治本的改法。