物流单据结构化实测：运单文本抽字段，准确率够用吗？
跨境物流群里每天最热闹的话题之一，就是录入运单。业务员对着 PDF 或照片，把发货人、收货人、件数、重量、品名、申报价值一个个敲进系统。旺季一天几百票，眼睛盯到发花，敲错一个数字，轻则改单重发，重则清关延误，罚款比运费还贵。
我见过最夸张的一次，同事把 "0.5kg" 录成 "5kg"，客户收到账单直接截图发朋友圈。这种痛，做过 B 端物流系统的人都懂。
在线试跑：不用写代码，直接贴文本
最近在 https://yingsuan.top/scenarios.html 看到一个"物流单据结构化"场景，可以直接粘贴运单文本，AI 自动抽字段返回 JSON。我立刻拿真实脱敏样本试了试。
页面很朴素，左边贴文本，右边出 JSON，没有花哨的交互。我准备了 2 段典型样本，一段是标准格式的快递面单文字版，另一段是带备注和特殊字符的货运单。
实测样本与 AI 输出
样本一（标准快递面单）：
发件人：张伟 电话：138****1234 地址：广东省深圳市南山区科技园南路88号
收件人：李娜 电话：186****5678 地址：上海市浦东新区张江高科园区祖冲之路2288弄2号
货物：蓝牙耳机 数量：50PCS 重量：3.2kg 申报价值：USD 450
件数：1 包装：纸箱 备注：易碎品，轻拿轻放
AI 输出 JSON：
{
"sender": {
"name": "张伟",
"phone": "138****1234",
"address": "广东省深圳市南山区科技园南路88号"
},
"receiver": {
"name": "李娜",
"phone": "186****5678",
"address": "上海市浦东新区张江高科园区祖冲之路2288弄2号"
},
"cargo": {
"description": "蓝牙耳机",
"quantity": 50,
"unit": "PCS",
"weight_kg": 3.2,
"declared_value_usd": 450
},
"packaging": {
"pieces": 1,
"type": "纸箱"
},
"remarks": "易碎品，轻拿轻放"
}
样本二（带干扰信息的货运单）：
订舱号：SHIP-20240614-008
发货人：深圳市盈算供应链有限公司
联系人：王强 手机：139****9999
收货方：AMAZON FBA 仓库
地址：2440 W 190th St, Torrance, CA 90504, USA
品名：LED 灯条 型号：LS-3528-300
总件数：12 箱 毛重：156.8kg 体积：0.85CBM
发票号：INV20240601 备注：需提供 FDA 认证文件
AI 输出 JSON：
{
"booking_ref": "SHIP-20240614-008",
"sender": {
"company": "深圳市盈算供应链有限公司",
"contact": "王强",
"phone": "139****9999"
},
"receiver": {
"name": "AMAZON FBA 仓库",
"address": "2440 W 190th St, Torrance, CA 90504, USA"
},
"cargo": {
"description": "LED 灯条",
"model": "LS-3528-300",
"total_cartons": 12,
"gross_weight_kg": 156.8,
"volume_cbm": 0.85
},
"invoice_no": "INV20240601",
"remarks": "需提供 FDA 认证文件"
}
点评：准确率、漏字段、格式稳定性
先说结论：对于标准格式的运单，准确率在 95% 以上，字段名稳定，直接能对接系统。 但有几个边界要看清。
准确率：样本一完全正确，连 "PCS" 这种单位都识别出来了。样本二抓到了 "AMAZON FBA 仓库" 这种非标准收货人名称，说明对专有名词有泛化能力。但注意，它把 "订舱号" 归到 booking_ref，这是合理的，但如果你系统里字段叫 shipment_no，需要自己映射。
漏字段：样本二里 "型号：LS-3528-300" 归到了 cargo.model，但 "发票号" 和 "备注" 都正确提取了。真正容易漏的是多行地址，比如 "收货方" 后面如果跟两行地址，AI 有时只抓第一行。另外，如果文本里有表格形式的数字，比如件数、重量、体积混在一行，偶尔会漏掉体积。
格式稳定性：同一段文本跑 5 次，JSON 结构完全一致。但换一种表述方式（比如 "重量：3.2千克" 而不是 "3.2kg"），输出的字段名不变，但值可能变成 "3.2千克" 字符串，需要后端做单位归一化。这是最需要警惕的坑。
适合接入业务系统的边界
如果你的业务是标准面单、格式固定、字段不超过 15 个，这个方案可以直接接。建议做三层保障：
1. 字段映射层：AI 输出的 JSON 字段名和你系统不一致，写个映射表就行。
2. 校验层：对必填字段（如收件人电话、重量）做规则校验，缺失时转人工。
3. 兜底队列：置信度低于阈值的单子，进人工复核队列，不要直接入库。
不适合的场景：手写运单扫描件（OCR 误差会放大）、多页 PDF 混合文本、字段值本身有歧义（比如一个单子有两个不同的重量）。
邀请你试跑真实样本
我用的两段样本都脱敏了，但真实业务里的脏数据更多——有全角半角混用、有备注里带 "急" 字的、有品名是 "MIX PARTS" 这种模糊描述。这些情况下 AI 表现如何，我还没测到。
如果你手头有真实的运单文本（脱敏后），建议直接去 https://yingsuan.top/scenarios.html 跑一下，把结果截图或贴到评论区。我特别想知道：
- 带特殊字符（比如 #、*、&）的备注会不会干扰？
- 多收货人的单子（比如分单）能不能正确拆分？
- 非英文品名（比如 "电子元器件"）会不会乱码？
实测数据比任何宣传都有说服力。等你反馈。