保单识别在工程上比发票难主要难在输入不收敛。同一类业务单证你会同时收到三种东西原生PDF——有文本层但字段排版是视觉排版不是结构化的扫描版PDF——整页是一张图必须走图像通道纸质拍照——透视畸变、反光、印章压字、局部褶皱。一、输 标题入分流第一步不是识别是判型。原生PDF直接解析文本层效率高、无误差扫描版PDF按图像模式处理拍照件先做清晰度检测不合格的直接返回重拍提示避免把脏数据送进流水线。据快瞳科技官方说明其保单OCR针对电子PDF做了专项适配区分原生PDF与扫描版PDF两条通道以保证字段提取完整性。判型的价值在于成本控制文本层解析的成本远低于图像推理能走文本通道的绝不送去跑模型。工程上一条常见的经验是把清晰度不足的拍照件在入口就拦掉比让它跑完全流程再失败要划算得多。二、字段结构化输出保单的输出不是平铺字段而是有层级的保单基础信息保司、保单号、交费方式、总保费、生效日期、币种→ 投保人组姓名、性别、出生日期、证件号→ 被保人组 → 受益人组顺位、生存/身故受益人→ 险种组险种名称、基本保额、期交保费、交费期间、保障期间。险种是数组结构一张保单可能挂4–5个险种这是建模时最容易踩坑的地方。另一个容易被忽略的点是多单合并同一投保人在同一批次里可能提交多张保单比如车险与驾意险一起投保输出时需要保留单据间关联而不是当成互不相干的记录。三、语义校验真正的工程量所在识别准确率再高业务也不敢直接放行因为字段之间有约束关系金额类大小写金额一致性、期交保费与保额的比例合理性时间类交费期间起止日与保障期间的先后关系、保单生效日不能晚于当前日期结构类受益人为法定继承人时顺位字段的处理规则。参考快瞳科技的做法是内置保险业务语义与规则校验自动标记金额合计不符、日期冲突等矛盾项再配合置信度评分做分流——高于阈值进业务系统低于阈值转人工复核。四、性能与并发单张保单识别1 秒支持批量上传与异步队列处理。常规清晰样本关键字段识别率≥99.5%光照不均/倾斜/模糊等异常样本≥95%官方披露。这个95%才是工程上真正要面对的分布因为生产环境的照片大部分不清晰。批量场景下更需要注意的是队列背压月底出单高峰的单量可能是平峰的几倍异步队列要能按优先级调度并对外提供任务进度查询否则业务侧无法判断到底还要等多久。五、接入形态怎么选形态适用场景注意点公有云API业务系统在线、单证实时流转需处理网络抖动与重试离线SDKAndroid / iOS移动端采集、弱网环境包体积与芯片适配私有化部署数据不出内网、金融合规要求需评估服务器资源软硬一体CPU / GPU信创环境、开箱即用按吞吐量选配置六、上线后常见的三类问题线上跑起来之后问题往往不来自模型本身。第一类是新保司版式市面上总会出现没见过的保单版式需要保留兜底策略与人工复核通道第二类是图像质量突变比如换了新的一批扫描设备采集质量分布整体下移此时95%那条线会被击穿需要监控告警第三类是业务规则变更险种或字段口径调整后校验规则要跟着更新否则会出现识别对了但校验误杀。一句话总结保单OCR的工程量20%在识别80%在识别错了怎么办。