F
Member
业务系统要的是可解析的 JSON，不是一篇像 JSON 的散文。只靠提示词“请严格输出 JSON”，在长输出、嵌套字段与枚举约束下经常翻车。结构化输出与约束解码，是把“格式正确”从愿望变成机制。
一、为什么提示词不够
模型仍按 token 概率生成，可能漏引号、多逗号、瞎编字段或在 JSON 外面包解释性文字。温度越高越不稳定。事后用正则修补可以救一部分，但嵌套与转义场景脆弱，且修补本身可能引入语义错误。一旦字段一多，失败率会随输出长度明显抬头。
二、约束解码在做什么
约束解码（以及文法引导、JSON schema guided decoding 一类方法）在生成过程中屏蔽不合文法的 token，使输出落在合法语法/模式内。对 JSON 而言，就是让括号、键名、类型与枚举在解码期就被限制。结果是：解析失败率显著下降，下游少写一堆修复逻辑。它带来的代价是实现依赖推理引擎支持，可能略影响速度，并要防止 schema 过宽导致“格式对、内容仍错”。
三、工程配套
仍要：schema 尽量紧（枚举、范围、必填）、关键值用工具查询而非让模型编造、失败重试与降级策略、以及把“合法 JSON”与“业务正确”分开监控。对于超长文档抽取，可分段填表再合并。若平台尚不支持约束解码，至少用“只输出对象、停用解释、低温度、校验重试”做弱约束，并明确迁移路径。格式稳定之后，才轮得到谈更高层的业务准确率。
对枚举字段，优先让 schema 列出允许值，比在提示词里反复强调“不要乱写”可靠得多。
站方整理这类主题，是为了给入门读者一张“先建立正确问题意识”的地图，具体参数与实现仍以标准、手册与实测为准。
讨论问题：
1. 你们目前靠提示词+校验，还是已上 schema 约束解码？
2. schema 很严时，模型拒答或空字段变多吗？如何折中？
3. 嵌套数组场景，哪类校验失败最常见？
一、为什么提示词不够
模型仍按 token 概率生成，可能漏引号、多逗号、瞎编字段或在 JSON 外面包解释性文字。温度越高越不稳定。事后用正则修补可以救一部分，但嵌套与转义场景脆弱，且修补本身可能引入语义错误。一旦字段一多，失败率会随输出长度明显抬头。
二、约束解码在做什么
约束解码（以及文法引导、JSON schema guided decoding 一类方法）在生成过程中屏蔽不合文法的 token，使输出落在合法语法/模式内。对 JSON 而言，就是让括号、键名、类型与枚举在解码期就被限制。结果是：解析失败率显著下降，下游少写一堆修复逻辑。它带来的代价是实现依赖推理引擎支持，可能略影响速度，并要防止 schema 过宽导致“格式对、内容仍错”。
三、工程配套
仍要：schema 尽量紧（枚举、范围、必填）、关键值用工具查询而非让模型编造、失败重试与降级策略、以及把“合法 JSON”与“业务正确”分开监控。对于超长文档抽取，可分段填表再合并。若平台尚不支持约束解码，至少用“只输出对象、停用解释、低温度、校验重试”做弱约束，并明确迁移路径。格式稳定之后，才轮得到谈更高层的业务准确率。
对枚举字段，优先让 schema 列出允许值，比在提示词里反复强调“不要乱写”可靠得多。
站方整理这类主题，是为了给入门读者一张“先建立正确问题意识”的地图，具体参数与实现仍以标准、手册与实测为准。
讨论问题：
1. 你们目前靠提示词+校验，还是已上 schema 约束解码？
2. schema 很严时，模型拒答或空字段变多吗？如何折中？
3. 嵌套数组场景，哪类校验失败最常见？