GLM-5.3-Flash 做结构化抽取时怎么留住证据链：从图文输入到字段校验

当图片里有一串零件编号、铭牌参数或表格字段时，GLM-5.3-Flash 可以把图像和文字指令放在同一条消息里处理；真正容易出错的地方，却不是“模型能不能看图”，而是把候选字段误当成已经核实的事实。更稳妥的做法，是把图片消息、文本约束、模型候选结果和证据校验拆成四个边界。

模型负责提出结构化候选，应用负责保留原始证据、检查字段约束，并决定哪些结果可以进入业务数据。

先把证据放进输入边界

官方模型卡片展示了 GLM-5.3-Flash 的图文消息用法：消息内容可以同时包含图片和文本。这个能力适合做“从图片提出候选字段”，但不等于模型替业务系统完成取证。比如一张设备铭牌可以提供型号、额定电压和序列号的视觉线索，文本指令则应该说明字段名、单位和无法辨认时的返回方式。

一个原创的抽取约定可以写成下面这样。字段名是业务协议的一部分，不要让模型自由发明同义词。

输入：设备铭牌图片 + “抽取 model、voltage，无法辨认返回 null”
候选：{"model":"X-200","voltage":"380 V","evidence":"铭牌右下角"}
下一步：Schema 校验字段类型，再由人工或原图定位确认

模型输出只是候选字段

结构化抽取至少要保留三类信息：字段值、原始证据位置、以及不确定状态。只保留一个漂亮的 JSON，后面很难回答“这个值来自哪里”。证据位置可以是页码、图片区域描述或业务对象的原始附件标识，重点是它能把字段重新指回输入。

在接口层，建议把模型输出包在一个候选对象里，而不是直接写入最终表。这样做的好处是，模型更换、提示词调整或二次复核时，原始候选仍然可追溯。

把 Schema 校验和事实核验分开

Schema 适合检查必填项、字符串或数字类型、枚举值和长度限制。例如 voltage 必须是带单位的字符串，model 不能为空；这些规则能拦截格式错误，却不能判断图片上的字符是否真的看清。

事实核验要回到证据：放大查看原图并不意味着可以把低清图片放大后当高清证据，而是确认输入本身是否足够清楚；遇到反光、遮挡或多个候选字符时，应保留 null 或标记待复核。把“Schema 通过”写成“业务确认”是这类链路最常见的越权。

一个可维护的字段协议

下面的结构只表达字段协议，不是 GLM-5.3-Flash 的官方返回格式；它把模型能力和业务验收隔开：

{
  "value": "380 V",
  "confidence_note": "数字清晰，单位位于同一行",
  "evidence_ref": "asset://plate-001#lower-right",
  "review": "pending"
}

confidence_note 是解释线索，不要把它当概率；evidence_ref 指向原始附件，review 则由业务流程决定。若下游只接受已确认值，应该在入库前检查 review，而不是在提示词里祈求模型“保证准确”。

常见误区与修复方式

把模型卡片示例当成生产协议

官方示例说明如何组织图文消息和调用库，不会替你的业务定义字段、审计记录和人工复核。接入时应单独写一份字段协议，并为每个字段声明来源和缺失策略。

只保存最终 JSON

没有原图标识、指令版本和候选时间，后续无法复盘。至少保存输入资产引用、文本指令版本、模型版本标识、原始候选和校验结果。

用置信度代替证据

置信度提示不能替代原始材料。对铭牌、票据、合同等高风险字段，宁可把不确定项交给复核，也不要把一个格式正确的字符串当作事实。

相关问题

图片和文本指令应该放在一条消息里吗？

在官方模型卡片示例对应的图文输入场景中可以这样组织；业务上仍要记录图片资产和文本指令的独立版本，方便复盘。

Schema 校验通过后可以自动入库吗？

只有当字段风险低、证据链完整且业务允许自动化时才考虑。Schema 通过本身只代表结构满足约束。

看不清的字段怎么处理？

返回 null 或待复核状态，并保留证据引用；不要为了填满 JSON 猜一个看似合理的值。

总结

图文模型接入的关键不是把提示词写得更长，而是把责任边界写清楚：图片和文本定义输入，GLM-5.3-Flash 提出候选字段，Schema 负责结构，证据引用负责回溯，业务审核负责最终确认。这样即使模型、提示词或下游系统变化，抽取链路仍然可解释、可复查。