工程圈有个默认共识：给模型套上"必须输出合法 JSON"这类硬约束，模型就会变笨。

这个判断流传很广，早前也有研究报告在结构化输出场景下观察到准确率下降。10 月 26 日提交到 arXiv 的一篇新论文（arXiv:2610.35328）把这个问题拆开重做，得到的结论是：在提示词和预期输出格式完全对齐的前提下，约束解码并不必然损害推理能力；此前观察到的"退化"，主要来自提示词与输出格式的不等价，而不是解码器层面的掩码本身。

论文作者来自 Télécom Paris（Institut Polytechnique de Paris）与 Nokia Bell Labs，代码以 litelines 开源（GitHub）。

把"约束"拆成三类，而不是有或没有

论文的核心是给约束解码建立了一个三层分类：

  • 格式约束（FC）：只管输出结构，比如必须是合法 JSON、字段必须齐全。
  • 有效性约束（VC）：在格式之上再屏蔽掉语义上非法的答案，比如把不在候选集里的选项直接 mask 掉。
  • 推理约束（RC）：更进一步，约束推理轨迹本身，比如强制模型先输出"让我们一步步思考"再作答。

论文给出的理论结论是：只要满足"输出约束不排除正确答案"这一前提（文中的 Assumption 1），解码器层面的掩码就不会拉低性能；而要拿到增益，还需要额外条件。

11 个开源模型、四个家族、十一个任务

实验规模不算小：跨四个模型家族共 11 个开源模型，其中 10 个（Qwen3-1.7B、Qwen3-4B、Qwen3-8B、Qwen3.5-2B、Qwen3.5-4B、Qwen3.5-9B、Qwen3.5-27B、Llama3-8B、Gemma2-9B、SmolLM3-3B）参与任务求解，Qwen3-32B 另作两阶段抽取器使用。

数据集覆盖两个难度层级。标准档是 GSM8K 和 Last Letter Concatenation；推理密集档是 AIME 2026 与作者自建的 LastLetter-Extended（把 Last Letter 从 4 个名字扩展到 8 个）。后者与 AIME 2026 都晚于全部被测模型发布，用来降低数据泄漏风险。

解码策略比了三种：JSON（在输出里加一个 reason 字段）、NL-to-Format（先自由推理、再用第二个模型抽格式）和 InWriting（单次自由推理，用触发词切换到约束模式）。

数字：把"退化"逐条拆开

在 Last Letter 任务上做纯文本答案对比时，加了 FC+VC 之后，被约束解码的版本全面反超未约束版本：Qwen3.5-9B 从 86.8 涨到 89.9，Qwen3.5-2B 从 62.9 到 68.7，Qwen3.5-4B 从 84.1 到 86.9，Qwen3-1.7B 从 60.7 到 66.1。

换成 JSON 格式后差距同样存在，Qwen3.5-9B 是 89.6 到 91.6。

论文进一步拆分收益来源，发现有效性约束比格式约束更稳定，最高带来 17.4% 的增益。原因不玄学：有效性约束提供了关于正确答案的语义信息，而格式约束只是把输出形状掰成要求的格式——模型本来就能照做时，几乎没有收益空间。

推理约束则表现分裂。强制以"让我们一步步思考"开头，在 GSM8K 和 AIME 2026 上通常有提升；但 Qwen3.5-4B 在 AIME 2026 上反而掉了 6.6%。论文的结论很克制：推理约束不是普适手段，它依赖任务和模型，还可能误伤其他合法推理路径。

解析成功率：约束最实在的那块收益

如果说准确率上的提升还得挑条件，解析成功率就是无条件的。

在 LastLetter-Extended 上，未加约束的 JSON 输出解析成功率，Llama3-8B 是 0，Gemma2-9B 是 0，Qwen3-1.7B 是 0.7，Qwen3.5-9B 是 60.4，Qwen3.5-27B 是 82.4。加上格式约束后，这些数字分别变成 100、100、96.2、99.3、93.8。

换句话说，如果你的工程里有一条"模型输出必须能被直接解析"的硬要求，约束解码解决的正是这件事本身。而且它对大模型同样成立，Qwen3.5-27B 也不例外。

token 成本：约束不总是更贵

直觉上约束解码应该更费 token，但表里的数据不完全支持。GSM8K 上 Qwen3-1.7B 的 JSON 输出，未约束时平均 221.1 个 token，加上 FC+VC 后降到 129.2；Last Letter 上同一模型则是 192.0 降到 73.4。

真正贵的是 NL-to-Format——它需要额外一次大模型调用做抽取，论文在结论里明确说，这会让 token 用量接近翻倍。折中方案是 InWriting：只把约束施加在最终输出上，论文说实验中额外增加的 token 不到 15 个。

论文自己承认的边界

作者没有把话说满，限制部分列得很具体：

  • 有效性约束主要只在 Last Letter 与 LastLetter-Extended 上验证，化学分子结构约束、内容过滤只做了 IMDb 上的初步实验；
  • 推理约束要落地需要事先知道哪些轨迹是"有益的"，而这在真实场景往往拿不到；
  • 实验用的是相对简单的 JSON schema，"既要长推理又要复杂输出结构"的任务被明确留作未来工作。

还有个细节挺有意思：这篇论文自己在声明里写了，作者用免费版 ChatGPT 和 Claude 起草和润色了部分稿件，所有研究问题、实验和代码都出自作者本人。

怎么看

抛开标题里那个问句，这篇工作对工程实践最直接的启示，其实不在准确率，而在方法论。

当你怀疑"加约束掉分了"，先别急着怪解码器。 论文的因果消融指向的是提示词与输出格式的不等价——拿"无约束 + 自然语言提示"的分数去对比"有约束 + JSON 提示"的分数，比较的其实是两套不同的任务设定，差异未必来自约束本身。论文给出的做法是：固定提示词、固定预期输出格式，再做有约束与无约束的对照。

另一条：约束解码最大的确定性收益在工程侧，不在分数上。把解析成功率从 0 拉到 100，对一条下游流水线意味着少一整层容错代码。

实现也值得看一眼。litelines 是论文配套的实现，pip install litelines 即可安装，唯一依赖是 outlines-core，通过 Hugging Face transformers 接入，以 logits processor 的形式介入生成，并提供 allow_preamble、max_preamble_tokens、trigger_token_ids 三个控制项。

那么问题留给你：你的项目里，有多少"模型变笨了"的锅，其实该由提示词来背？