大模型结构化输出翻车的三种姿势：JSON 约束、字段漂移与兜底解析

大模型结构化输出翻车的三种姿势：JSON 约束、字段漂移与兜底解析

在做 Agent 与业务系统集成时，我们几乎都会走到同一步：让大模型按约定的 JSON 结构输出结果，交给下游程序消费。听起来很美，做起来全是坑。过去几个月我们在线上把结构化输出这条链路反复加固了三版，踩过的坑可以归为三类：约束失效、字段漂移、解析崩溃。这篇文章把三类问题的根因和对应的工程手段梳理清楚，给同样在接这条链路的同学一个 checklist。

第一类：约束失效。很多人以为在 prompt 里贴一段 JSON Schema，模型就会严格照着输出。实际情况是，模型在长上下文、多轮对话后，会逐渐"遗忘" schema 细节：枚举值写成自由文本、必填字段偶尔缺失、数组里混进对象、对象里混进数组。更隐蔽的是温度设置——temperature 高于 0.3 时，字段顺序和格式的抖动率显著上升。工程上的对策分两层：接口层，优先使用推理服务原生支持的 structured output / JSON mode 参数，让解码层直接约束 token 采样，这比 prompt 约束可靠一个数量级；prompt 层，把 schema 放进 system prompt 的固定位置，并在 few-shot 示例里展示边界情况（空数组、null 值）的正确写法。

第二类：字段漂移。即使 JSON 语法合法，语义漂移依然存在。典型症状：模型自作主张加一个 schema 里没有的解释性字段；数字写成字符串（"count": "3"）；日期格式在 ISO 8601 和中文日期之间来回切换；嵌套层级悄悄加深。这类问题不会抛解析异常，而是静默地污染下游数据，往往要等到统计报表对不上才发现。对策：解析后立刻做 schema 校验（用 ajv、pydantic 这类工具，严格 additionalProperties: false），校验失败进入修复通道而不是直接报错。修复通道的顺序很关键：先程序化修复（类型强转、字段归一化、删除多余字段），能修就修并打点记录；修不了的再把原始输出和校验错误喂回模型做一次自我修正，最多重试一次——无限重试只会放大成本。

第三类：解析崩溃。模型有时会输出带 ```json 代码围栏的内容、在 JSON 前后加解释性文字，流式场景下还会在未闭合的半截 JSON 上触发解析。对策很简单但经常被忘掉：先剥离围栏与前后缀（正则截取第一个 { 到最后一个 }），再用容错解析器兜底；流式场景用增量解析器，等 JSON 完整闭合后再触发下游处理，而不是每收到一段就尝试 parse 一次。

最后是监控。结构化输出的质量必须作为一条独立的线上指标来观测：schema 校验通过率、程序化修复率、模型自我修正率、最终失败率，四个数字缺一不可。我们的经验值是：接了原生 JSON mode 后，最终失败率能压到千分之一以下；纯 prompt 约束的方案在复杂嵌套下很难低于 2%。如果某个模板的失败率突然抬头，大概率是上游 prompt 或模型版本变了，这条指标就是你最早的烟雾报警器。

总结成一句话：结构化输出不要信任 prompt，要用解码层约束 + 硬校验 + 分级修复 + 独立监控这四件套把它变成一条真正可靠的工程链路。