LLM结构化输出用JSON Schema约束字段缺失的处理方案

在摘要抽取、工单分类或知识库入库中，LLM 最麻烦的不是返回一段非法 JSON，而是 JSON 看起来能解析，却悄悄缺少业务必填字段。处理这类问题，核心是把 JSON Schema 当作输出契约：先约束对象形状和字段类型，再在应用层识别拒答、截断、缺失与语义错误，最后只对可修复的字段缺失做一次定向重试。

可靠链路不是“让模型永远不出错”，而是让每种错误都有明确出口：契约错误进入解析分流，字段缺失进入有限重试，拒答和截断保留原始响应，语义可疑结果进入业务复核。

官方文档：https://developers.openai.com/api/docs/guides/structured-outputs

先把字段契约收敛成最小 Schema

规模化接入时，最先变复杂的不是提示词，而是输出对象不断膨胀。建议从“后续服务真正必需”的字段开始：例如工单摘要需要 category、priority 和 reason，而情绪标签、营销话术等非关键字段先不要混进同一份契约。

JSON Schema 中，properties 只描述字段，只有写入 required 的字段才是必填。可选含义不要依赖模型省略字段，可以把字段设为必填并允许 null，这样下游始终面对稳定的对象形状。对支持严格结构化输出的提供商，还要按其支持的 JSON Schema 子集编写，避免复杂联合类型成为新的失败点。

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "category": {"type": "string"},
    "priority": {"type": "string", "enum": ["low", "medium", "high"]},
    "reason": {"type": ["string", "null"]}
  },
  "required": ["category", "priority", "reason"]
}

调用层要分开处理响应状态

启用 schema 后，仍然要检查响应是否被截断、模型是否拒答，以及 SDK 是否成功解析。不要看到一个空对象就直接补默认值：空对象可能代表契约不匹配，也可能是上游拒答被错误地吞掉。

const result = await client.responses.parse({
  model: "your-structured-output-model",
  input: "把工单归类并给出优先级理由",
  text: {
    // 使用严格对象契约，减少漏字段和额外字段
    format: { type: "json_schema", name: "ticket", strict: true, schema }
  }
});

// 先处理拒答和截断，再读取解析后的对象
if (result.status !== "completed" || result.output_text === "") {
  throw new Error("模型响应未完成，保留原始响应后进入人工或补偿队列");
}
const ticket = result.output_parsed;
if (!ticket?.category || !ticket?.priority) {
  throw new Error("结构可解析但业务必填字段缺失");
}

不同厂商的字段名和 SDK 形态并不完全相同，所以应用层应定义自己的归一化结果，例如 completed、refused、truncated 和 invalid。这样换模型时只改适配器，不让业务服务绑定某一家响应格式。

只对可修复缺失做一次定向重试

重试的输入不应只是“请再输出一次”。解析器应该返回缺失字段清单，把原任务、schema 版本和错误摘要一起交给重试请求；重试仍使用同一份契约，并设置固定上限。类型不符可以重试一次，拒答、上下文截断或外部依赖缺失则应该转入补偿流程。

async function completeTicket(input, schema) {
  let lastError = null;
  for (let attempt = 0; attempt 

上线后观察三个信号

第一看字段覆盖率：同一 schema 下哪些字段持续为空，往往说明字段定义或输入上下文不够清楚。第二看重试率：短期升高可能是模型或提示变更，长期偏高说明契约超出模型可稳定完成的范围。第三看人工回流率：结构合法但业务判断错误时，继续收紧 JSON Schema 没有帮助，应补充枚举、外部校验或人工确认。

还要保存 schema 版本、请求摘要、模型状态和原始响应的引用，避免只保留最终对象而无法复盘。生产系统可以按字段设置幂等键和超时预算，使重试不会重复写入工单或重复触发下游动作。

常见问题

把所有字段都放进 required 就更可靠吗？

不一定。只有下游真正需要的字段才应强制必填；对暂时无法判断的字段，用必填的可空值表达“不知道”，比让模型自由省略更容易处理。

JSON Schema 能保证模型给出的分类正确吗？

不能。它主要约束结构、类型和允许值，不能证明分类依据真实。语义正确性仍需要检索证据、业务规则、置信度策略或人工复核。