约束解码是怎么保证 JSON 格式的？

让大模型稳定输出一段合法 JSON，靠提示词恳求十次能成八次，剩下两次照样语法崩坏——约束解码把八成提到十成：每一步只放行合法字符，格式违规在物理上不可能发生。扣子这类工作流平台、通义千问的结构化输出接口都内置了这类机制，本文讲它怎么拦。

每步只许合法字符：状态机怎么拦

先定义一套语法规则，比如 JSON 的括号配对、键名加引号、逗号位置。解码时把这套规则装成一个状态机：它记录当前走到语法的哪一步、下一步允许哪些字符，然后把这些字符之外的候选全部拉黑——在 logits 层面直接屏蔽，概率再高也选不中。进来的候选分布，出去的只剩合法子集，挑字在铁笼子里进行。一条消息的完整旅程里，这套拦截发生在每一步挑字之前，越靠前越省事。

硬约束与软约束：拦和劝的差别

硬约束如上所述，违规即物理不可达，代价是可能为了凑格式写出语义空洞的内容；软约束走提示词与重试路线，格式错了就重新生成，灵活但兜不住底线。生产环境要稳定接口就用硬约束，探索性任务用软约束加人工检查。重复循环是怎么自我强化的那篇的复读在强约束下偶尔会被逼出怪圈——合法字符太少时模型反复兜圈，这时要检查语法是否定义得过窄，放宽一点往往就通。

两类格式保障手段对照表

• 硬约束：语法层拦截，格式必定合法，语义不保证
• 软约束：提示加重试，成本低，仍可能翻车
• 关键接口选硬约束，内容质量靠后续校验补
• 上约束前想清这句：它保格式，不保内容，两道关都要设

格式对了内容错了：管不到的地方

约束解码只管语法合法性，管不了语义正确：括号齐全、键名标准，值仍然可能张冠李戴。所以完整方案是格式靠约束、内容靠校验与人工抽检，两道关缺一不可。指令放长文前后为什么效果不同那篇的位置效应、上下文压缩是怎么做的那篇的历史压缩，影响的都是「值」的质量，与格式无关。随机种子是怎么影响输出的那篇讲的复现实验，在约束开启后照样成立——约束只是缩小了候选集，采样逻辑照旧运行。

关于约束解码的三个常问问题

• 开了约束还会输出格式错误吗？：语法层面不会，规则拦截在每一步生效；但字段内容是否正确、是否符合业务含义，约束管不着，需要另行校验。
• 为什么有时输出合法却很空洞？：合法字符集过窄时，模型只能反复选安全选项，内容自然干瘪；放宽语法或简化结构能缓解。
• 约束解码会拖慢速度吗？：会带来少量每步开销，但换来免重试，整体往往更快；具体开销随规则复杂度变化。

分工要清楚：语法交给状态机，语义交给校验，别指望一道闸门管所有事。还要分清一件事：约束解码管的是能不能这么写，不管写得对不对。状态机可以保证输出是合法结构，但保证不了字段取值合理、枚举值在业务允许范围内——这些要靠格式校验与后处理兜底。另外约束会小幅拖慢生成，因为每步都要在候选集里做一次合法性掩码，格式复杂的场景这笔开销更明显。实践中常见组合是：宽松场景用提示词加示例，关键场景才上约束解码，再配一层程序校验，三道防线各管一段。总之把它当成格式保险丝：平时可以不用，关键链路上值得配一道，成本不高，堵的却是最难排查的那类错。