文档解析与字段提取要分别设计
Z.ai的GLM-OCR模型卡将其介绍为面向复杂文档理解的多模态OCR模型，参数规模约0.9B。官方推荐的SDK用于文档解析，结合版面分析形成结构化输出；信息提取任务则要求按规定的JSON结构直接进行模型推理。
文档解析关注原内容及其布局，字段提取关注业务所需的信息。两者可以前后衔接，但不能把解析页面的示例直接视为任意业务表单已经适配，也不应使用通用聊天模型的方式随意改变任务提示。
先定义一张真正要用的表（本站分析）
例如整理供应商提供的采购资料，可以先约定产品名称、型号、数量、单位、资料日期和来源页。字段定义要说明允许的类型、缺失时如何表示，以及哪些值必须由人确认；只有字段名相同，无法保证不同资料采用同一口径。
遇到“每箱数量”和“采购箱数”同时出现时，不应把两者放进一个数量栏。货币、含税说明、计量单位和适用批次也应分开记录。模型输出一个数字前，系统需要知道这个数字究竟描述什么。
格式校验不能替代事实核对
JSON能够被程序读取，只说明结构可解析。还要核对字段与原文对应位置、数字的小数点、符号和空白处理。可以让每个关键字段关联页码和原图区域，复核人员直接查看依据，减少逐页寻找的时间。
未找到的值应保留为空或待确认，不能用常见值、旧订单或上下文猜测补齐。出现异常单位、重复型号或互相冲突的信息时，进入待处理队列，待确认后再写入正式业务表。
把导入设计成可回查的过程
每次批量处理保存原文件清单、提取版本、复核状态及最终导入记录。重复上传同一文件时，先识别是否已处理，避免生成重复条目。人工纠正应留下更正前后的值，方便定位错误来自源资料还是识别过程。
小团队可先交付一个固定表单类型的整理服务，再扩展到其他版式。成本要计入人工校对和异常处理；本文未测定识别准确率，也未将OCR输出描述为财务审核或正式业务批准。
延伸阅读
理解整页解析流水线；了解盘古行业资料服务。更多介绍见AI模型栏目。