当JSON不够用时：模式约束的LLM点餐代理的语义可靠性

# 当JSON不够用时：模式约束的LLM下单代理的语义可靠性
来源：https://arxiv.org/html/2607.18261
\(2026年5月\)

###### 摘要

LLM代理正越来越多地被用作交易编译器：用户以自然语言表达意图，模型输出一个可由API执行的结构化对象。JSON Schema和提供商级别的结构化输出模式虽然有用，能消除一大类解析失败，但它们本身并不能决定该对象是否为安全、可靠的交易。我们引入了OrderBench，一个用于餐厅下单代理的确定性基准，它区分了语法有效性、Schema有效性、状态决策、精确商品语义、约束保留和不安全接受。通过2,400次对四个开源模型在仅提示和JSON-Schema模式下的Nebius Token Factory调用，我们发现符合Schema的输出仍可能具有较高的语义错误率。在最强模型中，两种模式均实现了100%的Schema有效性，但语义成功率仍接近80%；在较弱模型中，符合Schema的不安全接受率高达两位数。结果是一个具体的工程警告：结构化输出是必要的接口层，但不能替代领域验证和故障安全执行。

## 1 引言

生产环境中的LLM代理常常介于无约束的自然语言和严格的交易API之间。在食品订购、零售支持、旅行预订、健康登记和金融操作中，模型不仅仅是格式化文本：它是在将用户的请求编译成一个可能用于预留库存、扣款或触发安全相关工作流的对象。因此，实际上的失败模式不仅仅是格式错误的JSON，更是格式正确但内容错误的JSON。

提供商的结构化输出模式和约束解码在格式化问题上取得了实质性进展。JSON Schema Draft 2020-12定义了JSON数据的标准契约语言\[3\]，OpenAPI 3.1将API Schema与JSON Schema对齐\[6\]，而OpenAI的结构化输出公告报告称，其支持的模型在内部复杂Schema评估上实现了完美遵循\[5\]。XGrammar等系统进一步优化了用于结构化输出的语法约束生成\[1\]。这些进展很有价值，但其成功标准通常是结构性的：输出能否被解析，以及是否匹配声明的类型层级形状？

本文研究下一层：在领域契约下的语义可执行性。我们聚焦于餐厅下单，因为该领域足够紧凑以便精确评估，但又足够丰富以暴露生产相关的边界情况：修饰词否定、修饰词对多个商品的作用范围、不可用的目录条目、过敏原冲突、饮食限制，以及过敏原在移除某个修饰词后才安全的情况。这些是常见的业务规则，而非玩具式的推理难题。

我们的贡献如下：

- •OrderBench，一个确定性的300例基准，包含一个小型菜单、手工编码的预言机，以及十种交易边缘情况类别。
- •一个验证器，报告JSON有效性、Schema有效性、状态正确性、精确商品语义、约束保留、语义成功和不安全接受。
- •对仅提示JSON生成与提供商JSON-Schema模式的配对评估，使用相同的用例、模型、提示和温度。
- •一个经验性演示：Schema有效性可以完美，但语义可靠性仍不足以直接执行。

## 2 相关工作

### 工具与函数调用

Gorilla和APIBench研究了模型能否选择API并生成准确的参数，强调了幻觉或不正确的调用是可靠工具使用的障碍\[8\]。伯克利函数调用排行榜将函数调用评估系统化，涵盖语言、API、SQL、相关性检测和多轮设置\[7\]。\(\tau\)-bench通过测试领域特定工具代理与用户及策略的交互，更接近部署，并报告称即使是最强的函数调用代理在现实领域中也仍然不一致\[9\]。OrderBench比这些基准更窄，但更具针对性：它隔离了单轮契约编译步骤，并对结构正确与领域正确的参数之间的差异进行评分。

### 结构化生成

JSON Schema现在是结构化LLM输出的常见目标。近期工作对约束解码框架进行了基准测试，针对JSON Schema测试套件和结构化输出任务\[2\]，而XGrammar专注于结构化生成的高效语法执行\[1\]。我们的工作假设结构化生成是有用的，并提出在结构有效之后还有哪些问题未解决。

## 3 基准

OrderBench定义了一个包含七个SKU、商品尺寸、默认修饰词、允许的添加/移除、过敏原和饮食标签的菜单。每个示例包含一个顾客话语和一个确定性预言机对象，该对象有五个顶层字段：`status`、`items`、`constraints`、`clarification_question`和`reasons`。状态可以是`accepted`、`needs_clarification`或`rejected_safety`。Schema禁止额外属性，并将数量限制为可执行的整数值。

300个示例均匀分布在十个类别中：简单精确订单、数量和尺寸、否定修饰词、作用范围修饰词、共享修饰词、过敏原安全接受、过敏原冲突、饮食冲突、不可用商品和不可用修饰词。话语是手工编写交易模板的确定性释义；未使用模型来创建标签。这种设计牺牲广度换取了可审计性：每个预言机都可以被检查并从源代码重新生成。

## 4 评估

对于每个模型和模式，我们通过Nebius Token Factory的OpenAI兼容API\[4\]，在温度为零的条件下运行全部300个用例。两种模式是：

- •**仅提示**：提示要求模型仅返回JSON，并将Schema作为文本包含在内。
- •**JSON Schema**：相同的提示，加上提供商的严格`json_schema`响应格式化。

我们评估了提供商在运行时提供的四个模型：GPT-OSS 120B-fast、Qwen3-30B-A3B、Llama-3.1-8B和Gemma-2-2B。确切的提供商模型标识符记录在发布的JSONL输出中。一次兼容性测试排除了一个候选模型，因为它在响应预算中频繁耗尽并在此提示下解析失败。原始模型响应、提供商使用情况、延迟、解析后的对象和验证器结果都写入JSONL。

主要指标是**语义成功**。对于接受的订单，要求正确的状态、SKU、数量、尺寸、添加、移除和特殊指令的精确多重集相等，以及陈述的过敏原和饮食约束的精确保留。对于未接受的订单，要求正确的状态、空的可执行商品列表和精确的约束。这是有意严格的：它衡量模型的输出能否作为即插即用的交易契约，而非答案是否大致有用。由于精确相等并不意味着严重程度相同，我们还报告一个多标签错误分类：安全失败、目录幻觉、数量/尺寸错误、作用范围拆分错误、否定错误和过敏原保留错误。

最重要的风险指标是**不安全接受**。仅当模型对验证器认为绝不能发送执行的输出发出`status=accepted`时，我们才计数为不安全接受：过敏原冲突、饮食冲突、不可用商品、不可用修饰词，或接受的商品仍然与陈述的过敏原冲突。普通的精确性失误（例如遗漏默认尺寸）是语义失败，但不计入不安全接受。对于仅提示与JSON-Schema模式的配对比较，我们报告Schema模式减去提示模式的比率差、基于用例的配对bootstrap 95%置信区间，以及基于不一致配对结果的精确McNemar检验。

## 5 结果

表1报告了完整的配对评估。关键模式是JSON和Schema有效性远比语义可靠性容易。结构化模式通常能改善较小模型的Schema有效性，但不能保证更好的业务决策或更安全的可执行对象。

评估中最强的模型GPT-OSS 120B-fast在两种模式下均达到100%的Schema有效性，但语义成功在仅提示模式下为83.0%，在JSON-Schema模式下为81.3%。Qwen3-30B-A3B在两种模式下也达到100%的Schema有效性，而语义成功分别仅为31.3%和30.7%，不安全接受率保持在15%左右。对于Llama-3.1-8B，结构化输出将Schema有效性从68.7%提高到100.0%，并将不安全接受率从13.3%降至8.3%，但语义成功仍然只有36.0%。Gemma-2-2B是最严重的反例：JSON-Schema模式产生了100% Schema有效的对象，但语义成功率为2.0%，不安全接受率为41.7%。

**表 1：主要结果**。除 \(n\) 外所有值均为百分比。“语义”指精确的领域契约成功；“不安全”指接受不应执行的订单。

表2按类别和模式汇总了语义成功。困难的类别不是通用的JSON格式化任务，而是领域边界任务：商品可用性、修饰词可用性以及必须改变执行状态的用户约束。由于该表格是对所有模型的平均值，附录中的表6提供了按模型和类别的热力图，用于检查某个类别层面的效应是广泛存在的还是由单个弱模型驱动的。

**表 2：跨模型聚合的类别级结果**。值均为百分比。

表3按操作严重性拆分了精确语义失败。标签是多标签而非互斥的；例如，接受菜单外的修饰词既是目录错误也是不安全接受。该表使得语义成功的严格性更容易理解：数量/尺寸错误和作用范围错误很常见，但部署关键类别是不安全接受和目录幻觉。

**表 3：跨模型聚合的多标签错误分类**。值均为每种模式下所有用例的百分比。类别之和不为100%。

**表 4：典型的Schema有效失败示例**。这些示例说明了为何要分别报告语义精确性、不安全接受和目录错误。

表5报告了评估协议中承诺的配对不确定性估计。GPT-OSS和Qwen的主要语义差异较小，且在统计上与零无显著差异。对于Llama-3.1-8B，JSON-Schema模式改善了Schema有效性并降低了不安全接受率，但语义成功的提升在5%水平上不显著。Gemma的语义成功提升在统计上非零，但绝对成功率仅为2.0%，实际中仍然不足。不安全接受则呈现不同模式：JSON-Schema模式显著降低了Gemma和Llama-3.1-8B的不安全接受率，但并未消除风险。

**表 5：仅提示与JSON-Schema模式的配对比较**。\(\Delta\) 是JSON-Schema减去仅提示的百分点。置信区间是基于用例的配对bootstrap 95%区间；\(p\) 是精确McNemar检验。不安全接受越低越好。

## 6 讨论

这些实验支持一条简单的部署规则：不要让符合Schema的模型输出直接执行交易。JSON Schema可以确保`items`是一个数组，`quantity`是一个整数。但它无法确保请求的过敏原冲突被拒绝，“一个不加洋葱，一个正常”被拆分成两个商品对象，或者“菠萝”没有被凭空编造为一个修饰词。这些检查需要一个领域验证器。

这并不意味着结构化输出不重要。它使得结构化输出成为更大契约栈中的第一层。一个实用的架构是：

1. 1.要求严格的结构化输出以消除解析和形状失败。
2. 2.对照业务目录和安全策略验证对象。
3. 3.对验证器错误采用故障安全模式，对安全关键字段使用澄清而非自动修复。
4. 4.将模型输出和验证器决策作为配对工件记录，用于回归测试。

## 7 局限性

OrderBench是合成且单轮的。其优势是可审计性，而非对所有餐厅语言的覆盖。菜单有意很小，因此报告的比例不应被解读为对特定供应商或餐厅的部署估计。我们还评估了一个提示和一个提供商接口；提示工程、微调、对更大目录的检索或专门的规划器-验证器循环可以改善绝对性能。核心主张更窄：Schema有效性本身并不是交易执行的充分可靠性指标。

## 8 结论

结构化输出API大大减少了接口摩擦，但生产环境中的代理需要语义契约，而不仅仅是语法契约。OrderBench表明，模型可以在满足严格JSON形状的同时仍然发出不安全或不正确的可执行订单。对于交易编译型代理，可靠性的工程单元应该是经过验证的领域动作。

## 附录A 模型-类别热力图

表6将表2中的类别平均值按模型和模式进行了细分。颜色越深的单元格表示语义成功越高。热力图显示，例如，作用范围类别的低聚合分数不仅仅是Gemma的产物：Qwen和Llama也在拆分商品语义上表现挣扎，而GPT-OSS则明显更强。

**表 6：按类别、模型和模式的语义成功**。P = 仅提示；S = JSON-Schema。值为百分比；颜色越深的单元格越高。

## 参考文献

- [1] Y. Dong, C. F. Ruan, Y. Cai, R. Lai, Z. Xu, Y. Zhao, and T. Chen (2024). XGrammar: flexible and efficient structured generation engine for large language models. External Links:2411.15100. Cited by: §1, §2.
- [2] S. Geng, H. Cooper, M. Moskal, S. Jenkins, J. Berman, N. Ranchin, R. West, E. Horvitz, and H. Nori (2025). JSONSchemaBench: a rigorous benchmark of structured outputs for language models. External Links:2501.10868. Cited by: §2.
- [3] JSON Schema Organization (2022). JSON Schema Draft 2020-12. Note: https://json-schema.org/draft/2020-12 Accessed 2026-05-16. Cited by: §1.
- [4] Nebius (2026). Nebius Token Factory API Reference. Note: https://docs.tokenfactory.nebius.com/api-reference/introduction Accessed 2026-05-16. Cited by: §4.
- [5] OpenAI (2024). Introducing structured outputs in the API. Note: https://openai.com/index/introducing-structured-outputs-in-the-api/ Accessed 2026-05-16. Cited by: §1.
- [6] OpenAPI Initiative (2021). OpenAPI Specification v3.1.0. Note: https://spec.openapis.org/oas/v3.1.0.html Accessed 2026-05-16. Cited by: §1.
- [7] S.