结构化输出

人读回答时，多一句客套话无所谓。程序读回答就不行了。比如风控系统要从模型输出里取出「风险等级」这个字段，再决定是否拦截。只要模型多写一句「好的，以下是结果：」，或者把字段名写成「风险级别」，程序就会解析失败。

所以，当模型的输出要交给程序而不是人看的时候，就需要结构化输出：让模型按约定的格式（最常见的是 JSON）输出，字段名、类型、取值范围都固定。

JSON 是一种用键值对表示数据的文本格式，例如：

{"风险等级": "高", "理由": "单笔金额超过日均 20 倍", "需要人工复核": true}

JSON Schema 是一份描述 JSON 结构的「说明书」。它规定：

• 有哪些字段，哪些字段必须有（required）；
• 每个字段是什么类型（字符串、数字、布尔值、数组……）；
• 取值能不能是固定几个选项之一（enum）；
• 是否允许多出没定义的字段（additionalProperties: false 表示不允许）。

上面那个例子对应的 Schema 大致是：

{
  "type": "object",
  "properties": {
    "风险等级": {"type": "string", "enum": ["高", "中", "低"]},
    "理由": {"type": "string"},
    "需要人工复核": {"type": "boolean"}
  },
  "required": ["风险等级", "理由", "需要人工复核"],
  "additionalProperties": false
}

即使不写代码，也要能读懂这份说明书，因为它就是「模型输出」和「下游系统」之间的接口约定。

OpenAI 文档原话的意思是：结构化输出是 JSON 模式的升级版，两者都保证合法 JSON，但只有结构化输出保证遵守 Schema；能用结构化输出时，建议总是用它。文档列出的好处有三条：

• 不需要再校验或重试格式错误的回答；
• 出于安全原因的拒答可以被程序识别出来；
• 提示词不必再用强硬措辞反复强调格式。

第 14 讲（解码与采样）讲过，模型每一步都会给所有候选 token 打出一个概率，再从中挑一个。受约束解码（constrained decoding）就是在挑之前加一道筛子：按 Schema 判断哪些 token 在当前位置是合法的，把不合法的概率清零，剩下的重新归一化。

手算演示（概率为示意）：模型已经写到 {"情绪": "，Schema 规定这里只能是「正面 / 负面 / 中性」。

1. 模型原本想写的下一个词：正面 0.35、积极 0.30、负面 0.15、中性 0.10、好 0.10。
2. 「积极」「好」不在允许的枚举里，清零。
3. 剩下的和：0.35 + 0.15 + 0.10 = 0.60。
4. 重新归一化：正面 0.35/0.60 = 0.583，负面 0.15/0.60 = 0.250，中性 0.10/0.60 = 0.167。

不受约束时，模型有 40% 的概率写出不合法的词（「积极」或「好」）。受约束后，这个概率变成 0。

（说明：这是通用原理。OpenAI 等厂商内部具体怎么实现，文档没有详细公开。开源库 Outlines 的论文（Willard & Louf, 2023）公开了它的做法：把正则表达式或语法规则转换成有限状态机，事先为模型词表建好索引，生成时每一步只放行能让状态机继续走下去的 token。论文说这种做法能保证生成文本的结构，额外开销很小。）

即使用了结构化输出，也不能完全不设防。OpenAI 文档专门提醒了两种边界情况：

• 拒答：出于安全原因拒绝回答时，返回的不是你的 Schema，而是一个单独的 refusal 字段；
• 截断：输出达到 token 上限时，JSON 可能写到一半就停了。

如果用的是只靠提示词的第 1 级做法，或者用的模型不支持结构化输出，就更需要兜底流程：

1. 解析：尝试把文本解析成 JSON；
2. 校验：按 Schema 检查字段、类型、取值；
3. 重试：失败了就把错误信息附在提示里再调用一次，比如「上次输出缺少字段『理由』，请补全」；
4. 设上限：最多重试 2 次，仍失败就走人工或默认值。

算一笔账（假设各次失败相互独立，这在现实中只是近似）：单次失败率 5%，最多重试 2 次，那么 3 次全失败的概率是 0.05³ = 0.0125%，大约万分之一。

OpenAI 文档建议：

• 字段名起得清楚直观；
• 给重要字段写标题和说明（description）。模型会读这些说明，它们相当于嵌在 Schema 里的提示词；
• 用评测比较不同的结构设计，找出最适合自己场景的那一个。

再补充两条常用经验：

• 先推理、后结论：如果需要模型思考，可以在 Schema 里把「推理过程」字段放在「结论」字段前面。模型从左到右生成，这样写结论时已经有了推理作为「前文」（第 18 讲（思维链 CoT）的思维链原理）。OpenAI 文档里的数学辅导例子就是先 steps 再 final_answer。
• 用枚举代替自由文本：能用固定选项的字段，就不要让模型自由发挥。

第 13 讲（推理模型）讲的推理模型会在内部先思考，再给出回答。给它们写提示词时：

• 不必写「一步步思考」，它们本来就会；
• 给目标和约束，不要规定每一步怎么做。OpenAI 的提示词工程指南原话是：推理模型像资深同事，给它一个目标，就可以放心让它自己搞定细节；GPT 模型像新同事，给出明确的指令，它才能做出特定的结果。OpenAI 的推理模型最佳实践还提醒：提示词要简单直接，不必写「一步步思考」，有时反而有害；先试零样本，需要时再加少量示例；
• 格式要求依然要明确。内部想得再多，最终输出给程序时也要符合 Schema，结构化输出照样适用。

• OpenAI, Structured model outputs（Structured Outputs 指南）：platform.openai.com
• OpenAI, Prompt engineering：platform.openai.com
• OpenAI, Reasoning best practices：platform.openai.com
• JSON Schema 官方入门 Understanding JSON Schema：json-schema.org
• Outlines（开源的结构化生成库）：github.com ；Willard & Louf, Efficient Guided Generation for Large Language Models, 2023：arxiv.org