如果您曾尝试用通用 OCR 服务从提单提取结构化数据，就已知道结果：行不通。至少无法可靠完成。在国际贸易合规中，“不可靠”等同于“根本无效”。
Atlas Verify 处理数千份贸易文件 — 提单、有机证书、植物检疫证书、原产地证书、商业发票、装箱单以及数十种其他文件。早期我们评估了市场上所有主要 OCR 平台。它们都未通过同一个测试：提供未经专门训练的文件，输出从不完整到危险的错误不等。
本篇说明我们为何构建定制文件处理流程、贸易文件为何特别困难，以及指导我们方法的工程原则。
文件多样性问题
大多数 OCR 服务针对少量文件类型优化。Google Document AI 擅长发票和收据。AWS Textract 善于处理结构化表单。Azure Form Recognizer 可针对自定义模板训练。但国际贸易产生的文件种类极为庞大。
仅在我们的系统中，就处理超过 35 种不同文件。提单与有机证书完全不同。USDA 签发的植物检疫证书与欧盟签发的几乎没有结构相似性。一家船公司的到货通知可能是表格清晰的结构化 PDF；另一家的可能是带手写注释的扫描传真。
关键认识是，每种文件都有自己的模式，即合规核验所需的特定字段集。提单需要发货人、收货人、通知方、集装箱编号、船名、装卸港和商品描述。有机证书需要认证机构、经营主体名称、NOP ID、已认证产品和生效日期。
通用 OCR 工具不理解这些模式。它们提取文字，也可能识别表格，但不知道“MEDU4107760”是集装箱编号，或“NOP ID: 7880315519”是需要对照 USDA Organic Integrity Database 核验的关键标识。如果不了解模式，OCR 就只是昂贵的文字转换。
为什么“足够好”很危险
在大多数软件应用中，95% 准确率很优秀。在贸易合规中，却是风险。
以集装箱编号为例。标准格式（ISO 6346）是四个字母加七位数字，最后一位为校验位。若 OCR 误读一个字符 — “0”变成“O”，“8”变成“B” — 编号就无效。尝试跟踪该集装箱的下游系统会无结果返回，核验链悄然断裂。
同一原则适用于 NOP ID、HS 编码、IMO 编号和认证日期。单字符错误就可能完全改变含义。HS 编码 0901.11（未烘焙、未脱咖啡因咖啡）与 0901.12（未烘焙、已脱咖啡因咖啡）会触发不同关税、监管要求和风险档案。
我们的架构
文件处理流程分三个阶段，各自旨在针对贸易文件的特定挑战最大限度提高准确度。
阶段 1：文件分类 — 提取任何数据之前，先识别文件类型。分类决定采用哪种提取模式、寻找哪些字段，以及如何核实结果。
阶段 2：模式识别提取 — 文件分类后，采用特定类型的提取模型，明确知道应寻找哪些字段，以及通常位于该类文件的何处。这与提取一切、留给用户解释的通用 OCR 根本不同。
阶段 3：交叉核实 — 提取的数据自动对照外部来源交叉核查。集装箱编号通过船公司 API 核实。NOP ID 对照 USDA Organic Integrity Database 检查。港口代码对照 World Port Index 核验。这一阶段同时发现 OCR 错误和欺诈数据。
经验总结
处理数万份贸易文件后，几项原则变得明确：
1. 专用领域方案优于通用方案。 每次尝试通用 OCR 服务都需要大量后处理，以至于修正输出花费的工程时间，比构建定制方案还多。
2. 分类是基础。 文件类型判断错误会影响所有后续步骤。我们大量投入分类准确度，因为所有下游工作都依赖它。
3. 核实比提取更重要。 提取集装箱编号有用，但确认它是正确港口真实船舶上的真实集装箱，才是合规真正关心的事。
4. 结构化输出支持自动化。 目标不是将文件数字化供人阅读，而是生成机器可读的结构化数据，直接纳入自动核验流程。
为国际贸易构建可靠文件处理流程确实困难。文件多样、准确度要求极高、错误后果重大。但它也是基础 — 我们构建的每项核验能力，都依赖准确读取和理解随货物在全球供应链中流转的文件。