LLM 输出格式约束：JSON 模式不是万能保险
一、结构化输出仍会失败
很多大模型应用要求输出 JSON，于是以为加一句“请严格输出 JSON”就安全了。实际生产里，模型仍可能输出注释、Markdown、缺字段、字段类型错误、枚举越界或内容截断。某个日志分析系统用 LLM 提取时间范围和关键词，线上出现过 JSON 被截断只剩前半段、字段值超界等多次故障，导致后端解析失败、告警漏报。
JSON 模式能降低风险，但不是万能保险。后端必须做校验和恢复。
二、先定义 Schema
flowchart TD A[模型输出] --> B[JSON 解析] B --> C[Schema 校验] C --> D[业务校验] D --> E[入库或执行]Schema 要定义字段类型、必填项、枚举值和长度限制。不要只在自然语言里描述。
{ "type": "object", "required": ["title", "tags"], "properties": { "title": { "type": "string", "maxLength": 80 }, "tags": { "type": "array", "items": { "type": "string" } } } }结构清楚，程序才好验证。
三、解析失败要可恢复
解析失败时，可以重试、让模型修复 JSON、降级为人工处理，或者返回可读错误。不要把坏输出直接传给业务。
parse_recovery: retry_once: true repair_json: optional fallback_manual: high_risk重试也要有限制。JSON 解析错误通常不是随机波动——如果第一遍就错了，大概率是 Prompt 或截断问题，只重试一次足够，多轮重试只会白花 token 成本。无限重试只会增加成本。
四、业务校验比格式更重要
JSON 合法不代表业务合法。价格不能为负，日期不能早于当前时间，操作类型不能越权，工具参数不能指向危险路径。
if amount < 0: raise ValueError("amount must be positive")模型输出进入工具调用前，必须经过业务规则校验。
最后，要统计格式失败率。某个 Prompt 或模型版本导致解析失败升高，就不能上线。结构化输出是工程接口，不是聊天结果。
输出约束还要考虑截断。模型回答超过 token 限制时，JSON 可能只生成一半。解析失败日志里要区分语法错误、字段缺失、截断、业务校验失败，这些问题的修复方向不同。
format_error_types: invalid_json: syntax missing_field: schema enum_out_of_range: schema truncated_output: length business_invalid: rule对于高风险动作，不建议自动修复后直接执行。比如模型生成支付参数、删除路径、权限变更，即使 JSON 修复成功，也应该重新校验并要求确认。
还可以采用“先生成草稿，再由程序组装最终结构”的方式。模型负责自然语言内容，程序负责固定字段和枚举，这比让模型自由生成完整 JSON 更稳。
最后，结构化输出的 Prompt 示例要覆盖错误场景。只给一个完美示例，模型遇到缺数据时可能硬编字段。
还要考虑流式输出。前端边收边展示时，JSON 只有在结束后才完整。不要在流式中途就解析并执行业务动作，除非协议明确支持增量事件。
streaming_structured_output: parse_only_when_done: true buffer_with_size_limit: true reject_incomplete_payload: true如果使用函数调用或工具调用，也不能跳过校验。模型生成的参数仍然可能越界、缺字段或包含危险路径。工具层永远要把模型当作不可信输入。
最后，格式约束失败的样本要进入回归集。每一次解析事故，都是下一版 Prompt 和 Schema 的测试资产。
五、总结
LLM 输出格式约束要依靠 Schema、解析校验、业务校验、有限重试和失败率监控。
JSON 模式不是万能保险。模型输出只要进入系统，就必须按接口治理。