大模型输出格式幻觉解决思路

一、背景

下游系统解析Agent输出常见写法：

python 复制代码

import json
def handle_agent_response(response_str: str):
    data = json.loads(response_str)
    order_status = data["order_status"]
    tracking_id  = data["tracking_id"]
    downstream_system.update(status=order_status, tracking=tracking_id)

上述代码随着调用量不断增多，就可能会发现下游系统偶尔抛异常，或者数据写错，通过看日志，通常会有三类原因：

JSON语法错误
字段名错误
语义层失效

绝大部分同学会认为结构化输出是：加个开关，就可以完事大吉。要弄清上述问题出现的原因，得先搞清楚市面上约束模型输出的三档机制。

二、三档机制约束模型输出

2.1 Prompt约束（包含普通Function Calling）------靠概率遵守

这一档防线其实没建起来，全靠模型"自觉"，最开始的那种糟糕情况随时会发生。模型会理解prompt要求，会在统计意义上尽量照做，但它依然有物理上的自由度去乱写。Schema定义age：integer，它可能填-5，定义status：enum，它可能填"shipped "（多了空格）

2.2 JSON Mode（json_object）------语法层强制

**这一档防线建在语法层。**第一种情况不见了，但第二种和第三种情况依然可能会出现。OpenAI等大模型厂商在API接口中提供了一个名叫response_format的参数，专门用来控制输出命令。当你把response_format设为{"type": "json_object"}时，就相当于给模型下了一道死命令，所以最终输出的json格式一定时正确的。但是，它只管语法，不管结构。里面的字段名称等信息依然可能出错。

2.2 Structured Outputs（约束解码）---------结构层强制

这是目前最高级别的保证。注意看参数，这里 response_format 变成了 {"type": "json_schema"}。json_object 和 json_schema 一字之差，到底差在哪？差在引擎不仅要管语法，还要把你的 Schema 编译成一个有限状态机（FSM）。引擎会通过 Logits Masking 把不符合 FSM 当前状态的 token 概率设为负无穷。这就意味着，模型物理上根本无法生成你 Schema 之外的字段名或类型。只要 Schema 没 bug，字段名和数据类型永远合法。

但这一档防线依然有代价：

**代价一：FSM 故障是生产失效，不是软错误。**某些复杂 Schema 下会触发 FSM stall（状态机无法推进），此时引擎直接 abort 请求。线上告警跳出 StructuredOutputAbortError，你找半天才发现根因是 Schema 里某个嵌套对象的 anyOf 触发了 FSM 边界条件。

**代价二：格式正确 ≠ 内容正确。**当模型被强制在 FSM 允许的 token 集合里生成时，它会优先保证"格式合规"，有时会牺牲"内容质量"。业界把这个现象称为"Structured Outputs 创造了虚假安全感"：模型可能为了填满 Schema 要求的字段，在自己不确定的情况下"瞎填"了一个在格式上合法、在语义上完全错误的值。、

所以你看，这第三档防线虽然建在了结构层，能保证物理上不出格，但"语义失效"不仅还在，反而被完美的格式掩盖了。

这意味着结构化输出根本不是加几行 Prompt 或者拨一个 API 开关就能搞定的事，它本质上是个工程问题。

既然厂商的开关防不住"瞎填"的语义错误，我们就必须在工程侧自己架设防线，绝不让模型裸写的 JSON 直接灌进业务系统。

网络协议设计里有个著名的 Postel 定律："发送时保守，接收时宽容"。但在处理大模型输出时，这条铁律得反过来用：接收时必须严格，执行时必须保守。为什么？因为对模型输出宽容，后果是脏数据污染数据库；对工具执行宽容，后果就是直接引发生产事故。

为了把"瞎填"这条路彻底堵死，生产系统必须架起双层防线。架起双层防线。

三、双层防线

....明天继续补充