约束税：衡量小语言模型结构化输出中的有效性与正确性权衡

# 约束代价：测量结构化输出对小型语言模型的正确性-有效性权衡

来源：https://arxiv.org/html/2605.26128

###### 摘要

许多已部署的LLM应用将模型生成结果直接输入到软件中：JSON信封、类型化追踪、正则表达式限制字段以及工具调用参数。我们研究了在端侧和低成本小型语言模型（SLM）部署中的这一接口，其中低于3B参数的检查点因隐私、延迟和通用硬件优势而具有吸引力，但在同时进行求解和格式化时缺乏余量。通常的假设是，严格的输出约束只会改善答案的外部包装。我们的测量表明，对于小型模型，包装本身可能会改变答案。我们定义了**约束代价**，这是一个配对协议，用于在固定模型、任务分布和问题实例下，测量由结构化输出约束导致的答案和可执行准确率损失。我们报告了五种结果设置：主流的通用GPU测试套件、日历工具调用模拟、3B边界检查、后端复现以及本地扩展接口研究。在包含15,000次生成的测试套件中，严格的仅答案模式解码将模式有效性从61.5%提升至100.0%，但将答案准确率从19.7%降低至11.0%，并将错误的有效模式输出从49.5%增加至88.9%。在日历模拟中，仅提示的JSON实现了91.5%的可执行准确率；而相同的严格工具调用模式仅达到48.0%，尽管两种直接生成模式都是100.0%模式有效。错误是语义性的，而非结构性的。我们还在3B边界发现了直接模式的代价，并通过延迟包装作为实用模式的证据：先自由推理，后施加约束。生产报告应区分模式有效性、答案准确率、可执行准确率和错误有效模式率。

## 1 引言

结构化输出现已成为服务契约。智能体将JSON传递给工具，网关验证模式，路由器期望类型化字段，产品代码通常将可解析性视为执行前的关卡。这一契约有用，但并非中立。一个低于3B的本地模型在解码容量和指令遵循方面弱于大型托管模型，因此相同的模式可能与它本应打包的任务产生竞争。

目标场景是端侧SLM部署：私人助手、离线应用智能体、本地企业工作流，以及需要可执行输出但不将每个请求路由到托管模型的边缘工具。这些系统仍然需要工具调用、UI操作和本地API的模式。它们还在更紧的存储、延迟和模型容量预算下运行。在这些约束下，推理和输出控制成为同一个系统问题的一部分。

结构化输出不仅仅是后处理。在约束解码过程中，它会改变哪些标记是合法的、哪些中间表示可以出现，以及完成预算中有多少花费在语法而非问题求解上。一个有效的JSON对象仍可能编码错误的决策，因此一个只追踪解析成功的仪表盘可能在改进的同时，下游执行却变得更糟。

我们将此视为一个测量问题，而非解码器设计问题。问题是：当一个小型模型被迫遵循某个模式时，相对于可比较的无约束或仅提示基线，语义正确性损失了多少？

本文贡献如下：

1. 我们定义了**约束代价**，即在相同模型和任务分布下，基线接口与结构化输出模式之间的准确率差值。
2. 我们将部署日志中经常混为一谈的指标区分开：模式有效性、答案准确率、可执行准确率、追踪正确性、延迟、标记数、结构开销以及错误有效模式率。
3. 我们提供了一个低计算开销的工具，用于运行无约束模式的MLX推理，以及在主流GPU上使用vLLM/SGLang进行约束解码。
4. 我们测量了一个静默的可执行正确性回归：在日历工具调用模拟中，两种接口都是100.0%模式有效，但硬模式解码损失了43.5个点的可执行准确率。
5. 我们识别出建设性设计模式**先自由推理，后施加约束**：使用满足下游契约的最低侵入性约束，并在模型解决任务后才打包答案。

## 2 背景与动机

### 2.1 输出约束作为推理干预

约束解码会屏蔽违反语法、正则表达式或JSON模式的标记。当语法是主要目标时，这是合适的。但当模型需要草稿本时，它的破坏性就更大。一个小型模型可能需要外化部分算术、符号状态或中间决策。一个僵硬的模式可能将这些状态推入为软件消费而非推理而选择的字段名、引号字符串、数组、对象分隔符和类型约束中。

该交互可总结为：

Q = f(R_reason, R_format, B_decode)，  (1)

其中质量取决于推理资源、格式化资源和解码预算。对于大型模型，格式保真度可能只消耗一小部分有效容量。对于低于3B的模型，相同的模式可能成为生成问题的重要组成部分。令人担忧的情况不仅是无效JSON，更是**错误答案，有效模式**。

### 2.2 结构化解码作为服务系统接口

这种失效模式跨越了模型服务边界。一个产品系统可能使用一个后端进行自由形式生成，另一个用于语法约束解码，第三层用于解析和验证。测量到的行为是模型、提示、解码算法、模式和验证栈的共同属性。仅靠模型准确率或解析器成功会忽略这种交互。

因此，我们将结构化输出路径视为一个完整的系统。每条记录存储提示、模式或正则表达式、后端、原始生成、解析结果、可执行检查器结果、追踪检查器结果、延迟和输出标记数。这支持在通用日志格式下比较仅提示JSON、正则约束答案、直接JSON模式、vLLM、SGLang和MLX执行。

## 3 测量设计

确定性任务生成器 → 提示 + 模式（自由形式、正则、模式） → 后端路由器（MLX, HF, vLLM, SGLang） → 生成（约束或自由） → 解析器 + 验证器 → 执行器 + 追踪检查 → 记录（代价、有效性、延迟） → 输出控制干预 → 测量层

图1：约束代价工具。基准固定问题实例，变化输出控制干预。测量层分别记录语法结果和语义正确性。图1 (https://arxiv.org/html/2605.26128#S3.F1) 总结了实验中所用的工具。

### 3.1 任务

基准使用确定性合成任务，具有精确答案归一化。合成任务是故意的。它们并不声称覆盖广泛的用户效用，但提供了受控的真实情况、可复现的任务生成以及可执行的答案检查。这使得它们适合隔离输出约束的影响，而无需使用另一个语言模型作为评判。

基准报告五种结果设置。主运行涵盖五类确定性任务家族的小型模型套件。一个单独的生产模拟使用一个可执行的日历对象任务，在该任务中，输出作为工具调用参数被检查。对于暴露中间推理的任务，工具还支持追踪检查。追踪检查器验证预期步骤数和归一化的最终中间输出。表1 (https://arxiv.org/html/2605.26128#S3.T1) 列出了生成器支持的任务家族名称、提示模板和真实格式。

表1：StructReason-Small 任务家族，由确定性生成器实现。每个实例的真实情况存储为最终答案字符串加上类型化的追踪步骤。

### 3.2 输出模式

工具比较在推理期间施加不同结构程度的接口；表2 (https://arxiv.org/html/2605.26128#S3.T2) 列出了评估的模式。

表2：基准使用的输出模式。这些模式区分了仅提示格式化、正则约束、直接模式、结构化推理、类型化追踪和延迟打包。`prompt_json` 衡量自然语言格式化指令是否足够。`final_only_regex` 衡量狭窄的最终答案约束是否避免了大部分推理干扰。直接模式衡量严格的语法压力。`typed_trace_schema` 测试使推理本身结构化是否有助于小型模型。`delayed_constraint` 测试结构化打包是否应在模型解决问题后进行。

### 3.3 后端

基准设计用于低成本执行。Mac 本地实验根据模型支持使用 MLX 或 Hugging Face Transformers。约束解码通过使用 vLLM 或 SGLang OpenAI 兼容服务器路由到主流 GPU 运行。3B 检查点用作边界检查，而非默认的低于 3B 模型。

这种划分形成了一个解释规则：除非部署环境被归一化，延迟比较在后端家族内最有意义。在可能的情况下，准确率和有效性比较仍会跨解码引擎复现。

## 4 指标

### 4.1 语法与语义指标

对于每次生成，工具记录：

- **模式有效性**：输出是否解析并满足所需的模式或正则表达式。
- **答案正确性**：归一化答案是否匹配确定性真实情况。
- **可执行准确率**：任务特定检查器是否接受生成的对象或答案。
- **追踪正确性**：预期追踪属性是否匹配。
- **错误有效模式率**：模式有效但未能通过任务相关答案或可执行检查器的样例比例。
- **结构开销、延迟和标记数**：服务和接口成本指标。

这些指标有意地区分有效性与正确性。生产解析器只关心对象是否可用。基准额外检查可用对象是否正确。

### 4.2 约束代价

设 m 为模型，t 为任务家族，c 为约束输出模式，b 为相同问题实例的基线接口。我们定义绝对约束代价为：

Tax(m, t, c; b) = max(0, Acc(m, t, b) - Acc(m, t, c)).   (2)

归一化形式为：

Tax_norm(m, t, c; b) = Tax(m, t, c; b) / max(ε, Acc(m, t, b)).   (3)

这里 Acc 是任务相关的语义指标，即答案准确率或可执行准确率。截断为零是有意的。该指标询问相对于基线损失了多少准确率。如果约束提高了准确率，则报告为准确率增益，而非负代价。在可用时，我们报告问题实例上的 95% 自助法置信区间。

### 4.3 统计报告

对于配对比较，当实验设计支持配对时，差值在相同生成的问题实例上计算。表中报告的置信区间是问题实例上的非参数自助法区间。我们仅报告在生成的结果工件中存在的区间。因此，MLX 扩展接口研究是设计证据，而非主要显著性声明。

### 4.4 错误分类

输出被分配到可解释的错误类别：`correct_valid`、`invalid_json`、`parse_failure_freeform`、`schema_validation_error`、`trace_answer_contradiction` 或 `wrong_answer_valid_schema`。这种分类比简单的通过/失败位更具可操作性。解析器重试有助于无效 JSON；它们无法修复错误的有效答案。

## 5 实验协议

所有报告的数字来自实验目录中生成的 JSONL 或 CSV 工件。我们不从模型期望或手动标记的输出推断数字。

**主GPU运行**：我们在主流GPU上运行vLLM，使用主流小型模型套件。每个检查点在五个确定性任务家族上评估1000个问题实例，分别使用五种模式：`freeform`、`freeform_direct`（应为freeform_direct? 原文有freeform_direct? 实际上是freeform, freeform_direct, freeform_brief_reasoning, prompt_json, answer_only_schema 五种？原文列出了freeform, freeform_direct, freeform_brief_reasoning, prompt_json, answer_only_schema需要确认，但按照原文描述是five modes: freeform, freeform_direct? 原文写的是"freeform, freeform_direct, freeform_brief_reasoning, prompt_json, and answer_only_schema" 但freeform_direct和freeform_brief_reasoning是什么？在表2中也有，我们保持原样）。这产生了15,000次生成。

**生产模拟**：我们在一个确定性日历工具调用参数任务上运行一个主流套件检查点。模型必须产生一个包含工具名称和参数的对象：标题、日期、开始时间、持续时间、参与者和主题。我们比较仅提示JSON与相同对象作为硬模式强制执行的比较，每种直接生成模式200个样例，并包含一个派生的延迟打包控制，该控制确定性地重新序列化仅提示JSON第一阶段记录。

**后端复现与3B边界**：我们为主流套件检查点跨vLLM和SGLang复现`answer_only_schema`。我们还使用`prompt_json`和`answer_only_schema`运行3B边界检查点，以测试直接模式代价是否在3B边界附近消失。

**本地扩展接口研究**：我们使用MLX进行本地研究，涉及四个公开小型模型，每个任务家族20个样例，以及完整的接口集，包括推理模式、类型化追踪、延迟约束和正则模式。该研究的每个任务家族样例数少于主直接比较研究，因此我们主要将其用于接口设计洞察。

## 6 实证结果

结果从广泛的主运行聚合开始，然后转向日历工具调用模拟。日历任务是更尖锐的测试：有效性已经饱和，因此执行下降不能解释为解析失败。

### 6.1 有效性提升而正确性下降

表3：主套件中小型模型检查点的聚合。硬模式解码带来了有效性，但将错误转移到错误有效模式输出中。括号内为95%自助法置信区间。请参见图2说明。

图2：主GPU实验。硬仅答案模式解码达到100%有效性，但答案准确率下降，错误有效模式率急剧上升。

表3 (https://arxiv.org/html/2605.26128#S6.T3) 和图2 (https://arxiv.org/html/2605.26128#S6.F2) 显示了基本的权衡。硬仅答案约束解码修复了格式：有效性提高了38.5个点，从61.5%上升到100.0%。它也使得答案更差：答案准确率下降了8.7个点，从19.7%下降到11.0%。可执行准确率几乎持平，因为仅提示模式中许多本来正确的答案由于格式错误或模式不兼容的JSON而丢失。重要的变化在于错误类型。错误有效模式输出从49.5%上升到88.9%。

这就是系统风险。解析器看到更干净的流；执行器看到更多格式良好但内容错误的对象。

表4：主确定性套件按任务家族的指标，聚合于主流低于3B检查点。每行每种模式使用600次生成。这里的`tool_call_argument`行是主套件中的答案包装版本，而非表6 (https://arxiv.org/html/2605.26128#S6.T6) 中的可执行日历对象模拟。

表4 (https://arxiv.org/html/2605.26128#S6.T4) 分解了聚合。算术和对象追踪导致了最明显的答案准确率损失。符号字符串在两种接口中均接近地板。布尔逻辑是反例：有效性提高且可执行准确率没有损失，因为仅提示JSON通常...（原文不完整，保留截断？实际上原文后面是"often"然后换行？我们按照原文结尾处理：often 后面可能是缺失，但根据上下文可以补充？但谨慎起见保留原样）