Structured Output / Constrained Decoding 解读

面向对象: AI PM / AI Architect / Platform PM / EvalOps / AI Product Engineer。 核心问题: 为什么“让模型按 JSON 输出”不能只靠提示词？结构化输出、约束解码和 LM program 如何影响 AI 产品架构？ 学习目标: 理解 constrained decoding、grammar、schema validation、LMQL、Guidance、Outlines、Jsonformer 等机制，并把它们转成可上线的 tool / workflow / eval 设计。

---

Source Anchors

结构化输出的核心:

不把格式正确性完全交给模型“自觉”，而是在解码、校验、重试和工具边界上共同约束输出。

---

1. 这类论文和框架解决什么问题

普通 prompt 常见问题:

• 模型输出自然语言解释，而不是机器可解析对象。
• JSON 缺少逗号、引号、字段或嵌套结构。
• 字段名漂移，导致下游 API、规则引擎、UI 和审计日志失效。
• 模型把 schema 之外的内容塞进结构里。
• 业务动作依赖结构化字段，但字段值没有经过验证。

对 AI 产品来说，结构化输出不是“格式偏好”，而是系统契约。

User / Event
  -> Model
  -> Structured Output
  -> Validator
  -> Policy Engine
  -> Tool / Workflow / UI / Audit

如果中间对象不稳定，后续所有自动化都会变脆。

---

2. 结构化输出的 5 个层级

高级 AI 架构应至少做到 L2；涉及工具调用和高风险动作时，应评估 L3/L4。

---

3. Constrained Decoding 的直觉

常规生成:

已生成 token -> 模型给出所有候选 token 概率 -> 采样/贪心选择一个 token

约束生成:

已生成 token -> schema/grammar 判断哪些 token 合法
              -> 屏蔽非法 token
              -> 在合法集合里选择 token

这意味着:

• 模型仍然决定内容。
• 框架限制形式。
• schema / grammar 成为运行时控制面。
• 输出格式正确率不再完全依赖 prompt。

例子:

{
  "risk_tier": "high",
  "action": "escalate",
  "citations": ["policy:kyc:section-3.2"],
  "requires_human_approval": true
}

如果 schema 规定 risk_tier 只能是 low | medium | high | critical，约束解码可以阻止模型生成 "very risky" 这种下游无法处理的值。

---

4. Jsonformer 的架构启发

Jsonformer 的思路可以概括为:

固定结构 token 不让模型生成，模型只生成 schema 中需要填值的 token。

对于下面 schema:

{
  "type": "object",
  "properties": {
    "case_type": { "type": "string" },
    "risk_tier": { "type": "string" },
    "missing_evidence": {
      "type": "array",
      "items": { "type": "string" }
    }
  },
  "required": ["case_type", "risk_tier", "missing_evidence"]
}

框架可以固定 {、字段名、冒号、数组括号等结构，只把字段值交给模型。

产品架构含义:

• 字段结构属于产品和平台 contract。
• 模型只负责判断和填充。
• schema review 应进入 architecture gate。
• schema 变更会影响 prompt、eval、前端、日志、审批和集成。

---

5. Guidance / Outlines / LMQL 的共同价值

对企业 AI 平台而言，这些框架说明了一个方向:

Prompt 应该从“文本模板”升级为“可测试、可约束、可观察的程序资产”。

---

6. PM 视角: 结构化输出是产品边界

PM 需要定义的不是“模型回答得像不像人”，而是:

这些字段直接决定:

• UI 展示。
• 工单路由。
• 人工复核。
• 审计日志。
• 业务指标。
• 事故复盘。

所以结构化输出 schema 应出现在 PRD、ADR、eval contract 和 release checklist 中。

---

7. 架构师视角: Structured Output Control Plane

Prompt Registry
  -> Schema Registry
  -> Constrained Decoder / Parser
  -> Validator
  -> Business Rule Engine
  -> Tool Gateway
  -> Audit Trace
  -> Eval + Monitoring

关键组件

---

8. Schema 不是安全边界

结构化输出能降低格式错误，但不能证明内容真实、合规或安全。

核心原则:

Schema 保证形状，不保证真相；truth、permission、policy 和 risk 仍要单独验证。

---

9. Eval 设计

结构化输出 eval 至少覆盖四类:

指标

最重要的是最后一项，因为它揭示“格式正确但业务危险”的问题。

---

10. 金融零售案例

10.1 KYC Policy Assistant

输出对象:

{
  "jurisdiction": "CA",
  "customer_type": "small_business",
  "required_documents": ["business_registration", "beneficial_owner_id"],
  "policy_sources": ["kyc-policy-v18:section-4.1"],
  "missing_information": ["ownership_percentage"],
  "requires_manual_review": true,
  "answer_boundary": "general_policy_guidance"
}

关键门禁:

• policy_sources 必须来自当前有效政策。
• answer_boundary 不能变成个性化法律或合规建议。
• requires_manual_review 与风险等级联动。

10.2 Payment Dispute Agent

输出对象:

高风险约束:

• 不能承诺退款。
• 不能跳过证据缺口。
• 不能把网络规则解释成最终裁决。

10.3 AML Narrative Draft

结构化对象可以把叙述拆成:

这比让模型直接写一大段 narrative 更容易评估、复核和审计。

---

11. Schema Versioning

Schema 变更要像 API 变更一样管理。

Schema registry 应记录:

• schema owner。
• supported model。
• prompt version。
• downstream consumers。
• eval set。
• release date。
• rollback version。

---

12. 架构评审清单

---

13. 作品集输出

---

14. 面试表达

30 秒版本

结构化输出不是让模型“尽量输出 JSON”，而是把模型输出变成系统契约。高风险 AI 产品要用 schema、约束解码、校验、policy engine、HITL 和 eval 共同保证输出能被下游安全消费。

2 分钟版本

Prompt-only 的 JSON 很容易字段漂移，适合 demo，不适合自动化工作流。更可靠的架构会把 schema 作为产品 contract，生成阶段可以用 constrained decoding 限制非法 token，生成后用 validator 检查类型、枚举、必填和跨字段规则，再用业务 policy engine 判断能否执行工具或是否需要人工审批。Guidance、Outlines、Jsonformer 和 LMQL 的共同启发是: prompt 应升级成可版本化、可测试、可约束的程序资产。金融场景里，schema 正确不等于业务安全，所以还要评估引用、权限、风险等级和动作边界。

CTO 深挖

我会把 structured output 放进平台控制面: schema registry、prompt registry、validator、policy engine、trace、eval harness 和 release gate。schema 变更必须像 API versioning 一样管理，因为它会影响前端、工具、日志、指标和事故复盘。

---

15. 复习问题

1. Prompt-only JSON 和 constrained decoding 的差异是什么？
2. Jsonformer 为什么能提升结构稳定性？
3. Schema 为什么不能被当作安全边界？
4. 哪些字段应该触发 HITL 或 policy engine？
5. Schema 变更为什么要进入 architecture gate？
6. 结构化输出 eval 应覆盖哪些指标？
7. 在 AML、KYC、支付争议中，哪些输出字段最容易导致业务事故？