Structured Output / Constrained Decoding 解读

本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。

Source Anchors

---

核心导读

结构化输出的核心不是“让模型尽量返回 JSON”，而是把模型输出变成下游系统可消费、可验证、可审计的契约。Constrained decoding、LMQL、Guidance、Outlines、Jsonformer 等方法说明，格式、字段、枚举和部分控制流可以由 schema、grammar 和程序化解码约束，而不是完全依赖提示词。

结构化输出能支撑工单路由、政策引擎、人工复核和审计日志，但它只保证形状，不保证事实、权限和业务安全。架构设计要把 schema、grammar、validator、semantic verifier、policy gate 和 workflow action 串成控制链。

---

1. 核心问题：自然语言输出不能直接驱动系统动作

AI 原型常写：

请用 JSON 输出。
字段包括 risk_tier、reason、next_action。
不要输出额外解释。

这对 demo 可能有效，但生产系统会遇到 JSON 语法错误、字段名漂移、枚举值不稳定、必填字段缺失、模型把解释塞进字段、下游 API 无法解析等问题。

更关键的是，金融零售系统的结构化字段经常驱动真实流程：

Model output
  -> validator
  -> policy engine
  -> workflow routing
  -> tool call
  -> UI display
  -> audit log

如果输出对象不稳定，下游系统会脆弱；如果输出对象稳定但语义错误，下游系统会稳定地执行错误动作。因此要解决的问题不是“JSON 好不好看”，而是“模型输出能否成为受控系统契约”。

---

2. 技术贡献：从 Prompt-only 到 Constrained Generation

结构化输出可以分成几个层级：

这组工具和论文的贡献，是把结构化输出从“模型自觉遵守格式”推进到“运行时约束和程序化控制”。

2.1 Constrained Decoding

普通解码是：

prefix -> model logits -> choose next token

约束解码是：

prefix -> model logits
       -> schema / grammar computes allowed tokens
       -> mask invalid tokens
       -> choose next token from valid set

模型仍然负责内容选择，但框架约束形式。例如 risk_tier 只能是 low | medium | high | critical，模型就不能生成 "very risky" 这种下游无法处理的值。

2.2 Jsonformer

Jsonformer 的启发是：固定结构 token 不让模型生成，模型只生成 schema 中的 value。花括号、字段名、冒号和数组结构由框架控制，模型只填值。

这强化了一个架构原则：

字段结构属于产品和平台契约，模型只负责在契约内判断和填充。

2.3 LMQL / Guidance / Outlines

LMQL、Guidance、Outlines 展示了更广义的语言模型编程思想：prompt 可以包含变量，输出可以绑定 schema，生成可以受 grammar 约束，中间结果可以被捕获，控制流可以和模型调用组合。

它们共同指向一个趋势：prompt 不只是文本模板，而是可测试、可版本化、可约束的程序资产。

---

3. 机制原理：Schema、Grammar、Validator、Policy Gate

结构化输出系统不是单点能力，而是一条控制链：

Task signature
  -> prompt / LM program
  -> constrained decoder or parser
  -> schema validator
  -> semantic validator
  -> policy engine
  -> workflow / tool / UI
  -> trace and monitoring

Schema 定义字段名、类型、必填项、枚举、范围、嵌套结构和字段说明。Grammar 更接近生成过程，可以约束 JSON、SQL 子集、DSL、表单或特定格式。

生成后仍要验证。Validator 至少分三层：

Policy gate 决定结构化字段能否驱动动作。例如一个 JSON 可能写着 risk_tier=high 且 requires_human_review=false，格式完全合法，但业务上应被阻断。

---

4. 为什么结构化输出有效

第一，它把输出变成系统契约。自然语言适合人读，但系统需要稳定字段来路由、展示、记录和执行。

第二，它降低格式漂移。Constrained decoding 或固定结构生成把一部分格式责任从模型转移到运行时系统，减少解析失败。

第三，它支持业务规则组合。当字段稳定时，系统可以明确写规则：高风险必须人工复核，无引用不能执行动作，自动化字段为 false 时阻断工具调用。

第四，它支持审计和监控。高风险比例、升级率、拒答原因、缺证据类型、引用失败率、自动化阻断率和人工 override 原因，都可以来自结构化字段。

这也是结构化输出对产品和架构的核心价值：它让 AI 输出从一段文本变成可运营流程。

---

5. 局限和误用：Schema 不是安全边界

最重要的原则是：

Schema can validate form, not truth.

合法 JSON 仍可能包含错误事实、错误判断或危险动作。比如 risk_tier=low 可能判断错，citations 可能指向不支持结论的条款，automation_allowed=true 可能违反政策。

常见风险包括：

Constrained decoding 能阻止非法格式，但不能阻止错误推理、错误证据、越权数据使用、不合规建议和工具滥用。结构化输出必须和 RAG verification、authorization、policy engine、human review 和 monitoring 组合使用。

---

6. 架构和产品价值：Structured Output Control Plane

结构化输出应进入平台控制面：

Schema Registry
  -> Task Signature Registry
  -> Prompt / LM Program Registry
  -> Constrained Decoder / Parser
  -> Validator Layer
  -> Policy Engine
  -> Tool Gateway
  -> Workflow Engine
  -> Audit Trace
  -> Eval and Monitoring

Schema registry 应记录 schema_id、version、owner、risk_tier、downstream_consumers、allowed_actions、compatible_models、eval_set_version 和 deprecation_policy。

每个字段都应有下游目的。没有消费者的字段会增加噪音；会驱动动作的字段必须更强验证。

Retry policy 也要区分错误类型。JSON parse failure 可以重试；citation mismatch 不能直接修成看似合理的引用；high-risk action conflict 必须阻断并人工复核。

---

7. 金融零售系统案例

7.1 KYC Policy Assistant

输出对象可以包含 jurisdiction、customer_type、required_documents、policy_sources、missing_information、requires_manual_review 和 answer_boundary。

这些字段支持地区政策选择、材料清单生成、补证任务、人工复核和审计引用。必要控制是 policy_sources 必须来自当前有效版本，requires_manual_review 与风险等级联动，缺证据时不能编造材料要求，未授权政策不得进入输出。

7.2 Payment Dispute Agent

支付争议对象可以包含 dispute_type、transaction_ids、network_rule、deadline_status、evidence_needed、draft_message 和 automation_allowed。

高风险约束是：draft_message 不得承诺退款，network_rule 必须经过版本验证，automation_allowed=true 必须满足低风险和证据完整，deadline_status=urgent 必须升级。

7.3 AML Narrative Draft

AML narrative 可以拆成 facts、analysis、gaps、boundary 和 evidence。这样能把事实、推断、缺口、下一步建议和数据 lineage 分开，让 reviewer 更容易检查。

必须控制的是：不自动生成 SAR filing decision，不把推断写成事实，不隐藏不利证据，高风险 typology 必须触发人工复核。

7.4 Credit File Review

信贷文件对象可以包含 income_evidence、debt_obligations、policy_exceptions、missing_documents、adverse_action_risk 和 underwriter_review_required。

控制重点是不使用 prohibited basis，adverse_action_risk 不能直接生成外发通知，所有证据字段必须有来源，自动化只能生成草稿和 checklist。

---

8. Eval 设计

结构化输出 eval 不能只看 JSON 是否 parse。

指标包括 schema pass rate、required field completeness、enum accuracy、citation-field consistency、action gate accuracy、repair rate 和 unsafe valid output rate。

其中 unsafe valid output rate 最重要，因为它揭示“格式正确但业务危险”的问题。

---

9. Schema Versioning

Schema 变更应像 API 变更一样治理。新增 optional field 风险较低；新增 required field 会影响下游兼容；删除字段需要 deprecation window；enum 值变化要重跑分类 eval；字段语义或动作字段变化应进入 release review。

Schema 变更会影响 prompt、eval、前端、工单系统、工具调用、日志、指标和审计证据。没有 schema owner 和 versioning，结构化输出会从契约退化成另一种脆弱文本约定。

---

10. 可交付资产

---

11. 学习验证

读完后应能回答：

1. Prompt-only JSON、schema validation 和 constrained decoding 的差异是什么？
2. Jsonformer 为什么能提升结构稳定性？
3. LMQL、Guidance、Outlines 代表的 LM program 思想是什么？
4. 为什么 schema 不是安全边界？
5. 如果 JSON 合法但风险等级判断错，哪个控制应发现？
6. 如果字段会触发自动发消息，需要哪些额外 gate？
7. Schema versioning 为什么要像 API governance？

真正掌握结构化输出的标志，是能把 schema、解码、验证、policy gate 和 workflow 作为一个系统契约来设计，而不是只会在 prompt 里写“请输出 JSON”。

---

SOTA 检查 (2026-07-01)

• 生成引擎主线已从本篇的 LMQL/早期 Outlines 迁移到 XGrammar：XGrammar（arXiv 2411.15100，2024-11）截至 2026-03 已是 vLLM、SGLang、TensorRT-LLM 的默认结构化生成后端，JSON 生成 per-token 开销 <40µs、近零额外延迟；针对 agentic 场景（每个请求动态暴露不同工具 schema）的 XGrammar-2（arXiv 2601.04426，2026-01）进一步解决动态 schema 编译开销问题。
• Guidance 思想以 llguidance 形式进入生产：Microsoft 的 llguidance（Rust 实现的 Earley parser，~50µs/token，启动开销可忽略）是 Guidance 库的运行时内核；OpenAI 于 2025-05 公开致谢 llguidance 为其 Structured Outputs 的基础工作。2025-09 的对比基准显示：重复 schema 场景 XGrammar 靠缓存略胜，动态 schema 场景 llguidance 的 time-to-first-token 更快。
• 托管 API 已原生化，"自己搭 constrained decoder" 的适用面收窄到自托管/开源模型：OpenAI Structured Outputs（2024-08 发布）在服务器端强制 JSON Schema；Anthropic 于 2025-11 推出原生 Structured Outputs（beta header structured-outputs-2025-11-13，output_format: json_schema，支持 Claude Sonnet 4.5 / Opus 4.1）。2026 年对比测评中主流供应商 schema 合规率均 >99.7%，"格式漂移"在托管 API 上已基本是已解决问题——本篇的重心因此应放在 semantic/policy/business 三层验证上。
• 引擎选型新增维度：递归 schema。FSM 类方案（旧版 Outlines 的正则/FSM 路线）无法处理递归结构（嵌套树、递归 JSON），会拒绝 schema 或展平到固定深度；CFG 引擎（XGrammar、llguidance）可以。Outlines 本身已发布 v1.0，重构后收敛聚焦约束生成、把推理执行交还给推理框架。
• 本篇主线工具的现状：LMQL 停留在研究原型阶段（论文 2022-12），生产实践中已被上述引擎和托管 API 取代——把它当"语言模型编程/约束表达"的思想源头读即可；Jsonformer 的"结构 token 由框架填充"思想被后续引擎吸收。
• 不随版本过时的框架性结论（本篇价值所在）：L0-L4 分层模型、"Schema can validate form, not truth"、syntax/semantic/business 三层 validator、policy gate 与 unsafe valid output rate 指标、schema versioning 按 API governance 治理——这些与具体引擎无关，2026 年在 agentic 工具调用场景下反而更重要（研究热点也转向约束是否扭曲模型意图，如 AdapTrack、Draft-Conditioned Constrained Decoding 等 2025-2026 工作）。