一、问题的发现做财务系统时发票解析是硬需求上传 PDF/图片自动抽出购销方、价税合计、明细行品名、规格、数量、单价、金额、税率、税额。我接入的是阿里云官方RecognizeInvoice增值税发票识别。抬头、价税合计这类字段通常很稳真正难的是明细行特别多的电子发票——一页四五十行货品时接口会把多行「粘」成一行。本文记录的是这个问题怎么暴露、我走过哪些弯路、最后为什么用「安全空隙对半识别」解决以及方案里的几个关键设计点。二、现象什么叫「粘行」正常明细大致是项目名称数量单价金额教具某某商品A112.0012.00教具某某商品B18.508.50粘行后同一条invoiceDetails里会出现品名多个税收分类前缀连在一起例如*教具*A...*教具*B...数量数字被拼成长串例如111111135226单价一个字段里出现多个小数点业务上很致命不是「识别差一点」而是行边界丢了。后面无论怎么映射字段、怎么展示表格货品行数和金额对不上。三、定位先证明不是自己写错了出问题后很容易怀疑SDK 调用方式不对前后端字段映射错了多页合并时搞乱了我做了对照实验同一账号、同一接口输入结果整页密集 PDF / 整页 PNG粘行同一张发票里明细稀疏的一页正常把密集页人为裁成上下半页再识别粘行消失结论很明确不是接入问题是模型在「单次视觉密度过高」时行切分失败。密度降下来接近稀疏页RecognizeInvoice就恢复正常。这决定了后续方向修输入形态而不是修输出 JSON。四、走过的弯路1. 后处理丢弃「脏行」写规则检测多个*分类*、数量位数异常、单价多个小数点 → 直接丢掉。问题脏行里往往塞着好几行真实货品。丢掉等于少记成本财务场景不可接受。2. 正则「拆开」粘在一起的品名看起来能救一部分但品名、规格、数量纠缠在一起规则极脆边界 case 无穷。而且本质是在猜测模型已经弄丢的行边界治标不治本。3. 固定中线裁切 / 选「更好」的半页结果固定对半裁切容易横切半行造出残片品名、残片金额。若再用「行数更少 / 更干净」的结果当赢家还会误删上半页真实明细。4. 用 VL 模型先裁「发票区域」实测框几乎就是整页密度没降粘行依旧。这些弯路共同指向一个原则行切分错误发生在 OCR 内部后处理只能掩盖不能恢复信息。五、最终方案安全空隙对半 → 双次 RecognizeInvoice → 接缝指纹去重管道命名page_split_halves → aliyun_RecognizeInvoice单页流程PDF / 图片 → 渲染高清 PNG → 在「两行之间」找安全落刀点文字层优先墨迹密度兜底 → 裁上半带 下半带接缝极小重叠 → 分别调用 RecognizeInvoice → 指纹匹配剥掉接缝重复行 → 抬头以上半为主缺字段用下半补 多页再选信息最全的抬头 按页顺序拼接明细核心思想只有两点每次送给阿里的明细行数减半让密度回到模型舒适区。刀必须落在行间空隙绝不能横切半行。六、三个关键设计点1. 安全空隙怎么找有 PDF 文字层时首选取文字块的 Y 坐标优先带*的词增值税明细常见*税收分类*品名在相邻两行之间找空隙空隙太窄如 4pt跳过避免切到字落刀点限制在页面中部附近避免切到抬头/价税合计区打分空隙大小 - 偏离目标中线的距离 × 权重→ 既要空隙大又尽量靠近页中无文字层 / 纯图片兜底把图缩小按行统计「墨迹密度」平滑后在页中附近找最「空」的一行当落刀点这样就把「对半」从粗糙的几何中线升级成语义上的行间切割。2. 接缝重叠怎么控对半之后接缝处需要一点点重叠防止漏行但重叠太大重复行又变多。我的策略默认重叠约1% 页高若已知文字空隙高度重叠再压到不超过空隙的 1/3硬上限很小几个百分点量级目标重叠只活在「空隙」里不侵入上下两行正文。3. 重叠去重怎么避免误删真重复货品发票里完全可能出现「同品名、同数量」的多行真实明细。如果做全局 Set 去重会误删。我们的merge_split_details上半全部保留只拿上半末尾 N 行如 lookback8做指纹表指纹 品名 数量 金额不含单价避开小数位抖动从下半开头开始指纹命中则丢弃记审计标记并消耗一次匹配一旦出现第一个不匹配行立刻停止剥离后面全部保留这保证了只清理「接缝区」的重复同页后面真实重复货品不会被误杀一条上半行不会连环删掉多条下半行七、效果与代价在密集样张上的对照示意模式明细表现整页一次识别出现灾难性粘行安全空隙对半 接缝去重粘行消失行数回到可用区间代价也很诚实每页约 2 次RecognizeInvoice调用成本与时延翻倍需要维护裁切、空隙检测、接缝去重逻辑对我们这种「财务明细必须准」的场景这个 trade-off 是划算的多花一次 OCR换的是可入账的结构化明细。另外补一层可观测性每页记录split_ratio、空隙检测方法、上下半行数、合并后行数、丢弃的重叠行。出问题能直接看是「切歪了」还是「去重误伤」。八、架构位置系统视角前端上传 → Java 业务服务 → Python 解析服务 /parse/invoice PDF → 逐页安全空隙对半识别 图片 → 文字层/墨迹找空隙后对半 OFD → 受格式限制暂走单次识别 → 映射为业务 JSON抬头 items 表格 blocks → 用户确认后入库工程上刻意把发票解析做成独立服务裁切、OCR、合并都在解析层完成业务侧只消费「一行一项」的结果。九、可沉淀的方法论这事对我后续做 OCR/文档结构化很有启发先做对照实验把问题钉在「模型能力边界」还是「自己的胶水代码」。密度/版式往往比「换更大模型」更关键——输入形态一变同样的 API 表现天差地别。切割点要语义化几何中线廉价行间空隙才安全。去重要局部、有序、可消耗接缝去重 ≠ 全局去重。保留审计字段方便回归和线上排障也方便跟业务对齐「为什么少了一行」。一句话收束粘行不是字段映射 bug是高密度下的行切分失败解法是把一页拆成模型能吃得动的两段并且保证刀落在行与行之间。