把GPT-5.5的多模态能力接入业务系统跑了两周，最大的感受是：Demo里“能识别”到生产环境“可控输出”，中间隔着的不是模型能力，而是工程代码。

事情是这样的。我们把GPT-5.5接入了财务报销系统，用户上传发票图片，系统自动抽取金额、税号、开票日期，结构化存入数据库。Demo跑得飞起，10张发票全对。上线第一周，出纳那边查出三笔金额对不上的——模型把“壹佰贰拾万元整”抽成了12万，少了个零。还有一张发票因为折痕遮挡了部分金额数字，模型直接猜了一个数填进去，没有任何置信度标记。

这时候你才意识到，多模态从Demo到生产，缺的不是模型精度，而是一整套保证输出可控的工程机制。

在做工程化改造之前，我把几家的多模态能力拉出来横向对比了一下。在KULAAI（dl.877ai.cn）上把同一批发票、合同、单据推给GPT-5.5、GPT-5和Claude 4.8，对比它们的结构化输出稳定性和异常输入的边界行为。这一步帮我确认了GPT-5.5在哪些场景需要加更多的兜底逻辑。下面展开讲。

一、输出不可控才是多模态落地的头号杀手

很多人关注多模态模型的准确率——有没有抽对发票金额、有没有读错合同条款。但实际落地中，比准确率更致命的问题是输出不可控。准确率98%意味着100次里错2次，靠人工复核兜得住。但输出格式不可控意味着下游解析代码随时可能崩——模型这次返回的JSON少了一个字段，下次多了一层嵌套，再下次字段名变了。

GPT-5.5在结构化输出上做了很多改进，原生的JSON Mode加上response_format约束，格式一致性已经做到99%以上。但1%的异常在日均调用量上百万的场景下，意味着每天上万次需要人工介入的异常。而且异常的分布不是均匀的——正常光照、清晰扫描件几乎不出问题，低质量输入下格式异常的概率会明显上升。

我们踩的第一个坑就是异常输入处理。一张完全空白的图片、一张跟发票毫无关系的表情包、一张曝光过度的白纸——这些输入在测试阶段很少被覆盖，但上线后出现频率并不低。GPT-5.5在处理这类输入时，约85%的情况下会正确返回“无法识别”的结构化提示，但剩下15%要么输出格式不符合约定的Schema，要么从图片中强行脑补出一些数据。

二、第一道防线：锁死输出格式

要让输出可控，第一步是把格式锁死。GPT-5.5的response_format参数支持json_object和json_schema两种模式，选后者。

json_schema模式需要预先定义完整的Schema——每个字段的类型、是否必填、枚举值范围、嵌套结构。不要在Schema里留模糊空间，所有可选字段用nullable标记而不是直接省略。字段描述用自然语言补充说明，比如金额字段写明“单位为元，保留两位小数，无法识别时返回null”。

{
  "type": "object",
  "properties": {
    "invoice_number": {
      "type": "string",
      "description": "发票号码，无法识别时返回null"
    },
    "amount": {
      "type": "number",
      "description": "合计金额，单位为元，保留两位小数。若金额被遮挡或模糊不清，返回null"
    }
  },
  "required": ["invoice_number", "amount"]
}

Schema定义好之后，在Prompt里补充异常处理规则。关键是把低质量输入下的行为写清楚——图片模糊、遮挡、过曝、完全无关时分别应该返回什么。GPT-5.5的指令遵循能力足够强，你写清楚它就会执行。但如果你不写，它就会按自己的理解自由发挥。

还有一个容易被忽略的点：Prompt里的提取指令和格式约束需要分开层级。System Prompt专注格式约束和异常处理规则，User Prompt专注当前任务描述。这样后续调优时可以独立修改每一层，不用每次改Prompt都要重新测试整个链路。

三、第二道防线：Schema校验加业务规则校验

格式锁死只是减少不确定性，不能消除。模型输出进入业务系统之前，必须加两层校验。

Schema校验是第一关。用JSON Schema Validator对模型输出做结构校验——必填字段缺没缺、类型对不对、嵌套层级是否匹配。校验不通过直接触发重试，重试还不通过走降级链路，记录原始输出并告警。这层校验的代码很简单，定义一个Schema对象，调用validate函数即可。

import jsonschema
from jsonschema import validate

schema = {
    "type": "object",
    "properties": {
        "invoice_number": {"type": "string"},
        "amount": {"type": "number", "minimum": 0}
    },
    "required": ["invoice_number", "amount"]
}

def validate_schema(result):
    try:
        validate(instance=result, schema=schema)
        return True, None
    except jsonschema.exceptions.ValidationError as e:
        return False, str(e)

业务规则校验是第二关。Schema过了不代表数据对——金额可能是负数，日期可能是未来时间，税额和金额的比例关系可能不合理。把业务约束编码成校验规则，放在Schema校验之后执行。校验失败的字段标记为“待人工复核”，校验通过的字段正常写入数据库。这样业务不会因为个别字段异常而全量阻塞。

四、重试与降级：异常链路的设计

校验失败之后怎么处理，直接决定了系统的可靠性。重试策略需要根据失败原因做区分。Schema校验失败大概率是偶发性的输出格式抖动，重试一次通常能解决。业务规则校验失败可能是图片本身的问题，重试大概率还是失败，不需要浪费Token。

降级路径有三种。Schema重试后仍然失败时，记录原始输出和失败原因，写入异常日志并触发告警，该条记录标记为“解析失败”推人工处理。业务规则校验不通过时，将失败字段标记为“待复核”，校验通过的字段先入库，异常记录推送到消息队列等待人工处理。异常输入检测到完全无关图片或空白图片时，直接返回“请上传有效票据”的提示，不消耗后续链路资源。

降级路径需要完整的监控配合。校验失败率、重试次数、人工复核占比这些指标需要实时监控，一旦出现异常上升，第一时间排查是模型侧变化还是输入质量变化导致的。

五、关键字段的兜底校验

对于金额、日期这类一旦出错就会造成实际损失的关键字段，只用模型输出是不够的，需要加兜底校验。

方法是在模型返回结构化的金额字段和对应区域坐标之后，用坐标信息从原图中裁剪出金额所在的局部区域，然后走传统OCR引擎独立识别一次。把OCR结果和模型输出做比对——如果一致，直接入库；如果不一致，标记为“需人工复核”，同时把两个结果都展示在复核界面上供人工判断。

兜底校验的代码也不复杂。模型返回的坐标信息可以用来定位裁剪区域，然后把裁剪出来的局部图片送给OCR引擎。OCR结果和模型输出做比对，简单的编辑距离阈值就能判断是否一致。

这套兜底机制的成本比直接多调用一次模型低得多，但能拦截掉大部分数值抽取错误。对于那些模型信心十足但实际上抽错了的情况，这是最后一道防线。

六、稳定输出不靠模型，靠工程体系

GPT-5.5的多模态能力在Demo层面已经能做到“上传一张图，输出结构化JSON”。但从Demo到生产，中间需要补上Schema约束、两层校验、重试降级、兜底校验、监控告警这一整套工程体系。

Schema约束锁死输出格式，两层校验保证数据质量，重试降级兜住异常场景，兜底校验保证关键字段准确性，监控告警保证异常可感知。这五层机制加起来才能把一个“能用”的多模态能力变成“可控”的生产级能力。

模型能力在持续进化，但工程体系是长效的。把这套东西搭好，不只是为GPT-5.5服务——下次模型升级，这套体系同样适用。可控输出不是模型给的，是自己写出来的。