长文档OCR验收:一行明细怎样被合掉

导读：用四个可复现样例，检查长PDF转成表格后，哪些内容可能悄悄丢失。

假设一位采购助理收到供应商的扫描报价单。表格跨了页，第二页重新印了表头，两笔纸箱采购恰好品名、金额都相同。整理完的表格很干净，总额却少了一笔。交付之前，谁来发现它？

10月27日，百度发布了Unlimited OCR 2，继续推进长文档连续解析。对经常整理合同附件、报价清单和制度手册的人，它值得关注的地方，是跨页内容能否接得上，以及接好之后能否追溯。

我们核对了官方仓库、魔搭模型文件和一份新提交的社区报告，还实际运行了官方后处理程序。测试输入是手工构造的版面文本，不经过OCR模型；这篇讨论文档交付验收，不给模型识别准确率打分。

其中一组样例，输入明细合计320元，整理后只剩200元。问题发生在已经“识别完成”之后。这也让长文档工具的验收，有了一个比“看起来挺整齐”更具体的起点。

01 长文档接得上，工作才有机会少做一遍

传统的逐页识别容易留下拼接工作。上一页的表格没有结束，下一页又来了一个表头；说明文字分布在页尾和页首，复制到文档里可能变成两段。页数一多，负责整理的人就要不停核对原件。

Unlimited OCR 2的官方接口可以按顺序接收多张页面图像。它的原始输出用页面、版面块、跨页关系等标记组织内容，再交给后处理程序整理。这里的“跨页”有工作意义：合并表格、接续文字、保持阅读顺序，都需要知道相邻内容的关系。

仓库介绍的稀疏滑动窗口机制，会限制每步重点参考的内容，给出的窗口例子是512个token。它针对的是长输入下的计算负担。官方所说的每步延迟和内存趋于稳定，不能读成整本书无论多少页都一样快；扫描、图片传输、逐步生成和最后核对仍然要花时间。

对行政和采购团队，第一件可做的事是整理跨页报价清单。先把品名、数量、单位、金额提取为待核对的结构，再回到原页检查续表位置。结果适合进入复核队列，不能直接触发付款或替代正式采购台账。

第二件是建立制度手册的检索底稿。把章节和正文拆清楚，让同事能快速定位相关段落。每段都带回原文件页码，后续回答才能说明依据；漂亮的全文摘要无法替代这一层定位信息。

第三件是整理合同附件索引。先找出附件标题、表格和图章出现的位置，再由经办人确认版本和内容。图章被检测到，只能说明对应区域存在，不能据此认定合同有效，或判断签章真伪。

这三件事的共同起点，是减少重复搬运。最终需要核对的对象不同：报价单盯明细，制度文档盯原句，合同附件盯版本与出处。先确定交付对象，再选工具，往往比一开始就试整本文件更省返工。

02 先看成功样例：两页表格怎样变成一张

官方文档写得很明确：模型原始输出并非可以直接使用的Markdown，而是带布局标记的一段文本。仓库里的process_unlimitedOCR2.py负责把它转成标题、正文、HTML表格和图片引用。

本次只运行这段标准库Python代码，没有安装模型、下载权重或调用付费接口。测试使用下载时的代码副本，原始输入与输出都保留，方便区分“代码做了什么”和“模型能否正确识别页面”。

第一个样例很小。第一页有表头“物料／金额”，以及纸箱120元；第二页重复同一个表头，增加标签80元。我们把第一页标为跨页表格，把第二页标为续表，模拟模型已经正确给出版面关系的情况。

运行后，两段表格合成一张，表头只出现一次，纸箱和标签两行都保留，总额仍为200元。这个结果证明，在这份合成输入下，后处理能完成续表与重复表头清理。它没有证明扫描件里的文字、金额或跨页标签一定会识别正确。

 

图1｜手工构造的原始输出，经官方后处理得到一张表；金额单位为元，非OCR识别实测。

这一步很容易被低估。很多团队验收时只打开最终文件，觉得没有分页、没有多余表头，就算完成。实际上，还应该同时保存原始输出，否则后来发现少了一行，很难知道问题出在识别、分组还是格式清理。

最小交付包可以只有三个部分：原始页面、原始输出、整理结果。文件名使用同一个文档编号，页面文件按数字顺序排列。把这个约定写进需求，比事后在聊天记录里寻找“当时用的是哪个版本”更有效。

03 少掉的120元，藏在重复表头规则里

第二个样例只改一处：第二页表头下面，再放一笔纸箱120元，后面仍是标签80元。按样例设定，两笔纸箱采购是独立明细，原始总额应为120加120加80，也就是320元。

后处理结果却与第一个样例完全相同：纸箱120元、标签80元，两行合计200元。消失的是第二页那笔纸箱明细，共少了120元。

代码解释了这个现象。合并表格时，它会比较后一个片段开头的行，与第一个片段开头的行是否一致，最多查看前5行。匹配到的连续行会被当成重复表头跳过。这里不仅表头相同，紧接着的纸箱明细也相同，于是两行一起被跳过了。

这份输入没有订单号、批次号等可以区分两笔业务的字段，正好触发了边界。它是我们刻意构造的测试条件，不代表真实报价单都会遇到同样结果，也不能据此把整个模型判断为不可用。

 

图2｜本次后处理边界测试：应保留3行、320元；实际保留2行、200元。两笔相同明细在样例中均有效。

补救需要回到交付规则。首先，把跨页处前后几行单独检查，不能只看表格结尾的合计。其次，业务数据有行号、订单号、批次号时，保留这些字段；判断重复记录需要业务身份，光比文字相同不够。

如果原件确实没有区分字段，整理结果就应附上“原文件第几页、第几行”的来源标记，再由经办人决定是否合并。不能为了让表格更短，自动删除相同的明细。来源标记应从原始页面和块信息建立，不能让下游语言模型猜一个页码补上。

也别简单把“去掉重复表头”整体关闭当成万能修复。这样可能把每页表头都混进数据区，后续求和、筛选和导入会碰到新的错误。更稳妥的改造是明确表头范围，保留不确定行，并把重复候选列出来；本文没有修改官方算法，也没有把这些改造建议算作已经验证的功能。

还有一个验收启发：只比较总金额仍然可能漏错。两处金额一增一减，合计会碰巧一致。行数、关键字段和合计应分别核对，任何一项有差异，都应回到具体页面定位，而不是直接让AI“修成正确数字”。

04 图片有了文件名，也可能根本没落盘

第三个样例安排了3页内容：第一页是正文，第二页留空，第三页放一个图片块。实际输出保留了图片来自第3页的信息，没有因为中间空白页而错算成第2页，这一点符合官方说明。

但生成的结果只是一条图片文件引用。我们的测试目录里没有相应JPEG文件。后处理程序负责写出文件名，并不负责把原页面裁剪成图片。若交付流程少了裁图和复制素材这一步，最终文档就可能出现空白占位。

这类问题适合直接查文件，不必再问模型。整理完成后，逐个确认图片引用指向的文件确实存在、能打开，并且对应正确页面。带图片的文件交给同事时，把素材一起打包，或用经过验证的嵌入方式导出。

第四个样例考察金额校验：数量3、单价40元，输入金额故意写成720元。后处理仍输出720元，没有改成算术上应得的120元。这里的错误由我们手工写入，用来验证职责边界，并非观察到模型把120识别成720。

 

图3｜两个独立复测结果：图片引用没有生成图片文件；格式清理没有修正错误金额。

因此，采购类表格至少需要一层业务算术检查：数量乘单价、明细之和、合计是否含税、单位是否统一。无法确定税费或折扣口径时，标记待确认，不能硬套乘法把原金额覆盖掉。

同样，Markdown里保留了图片的页号，不等于所有正文都有页码映射。本次普通文本输出已经去掉页面标记。需要逐句追溯的制度和合同工作，应另外保存块到页的对应关系，不能只留下最后那份看上去更干净的文件。

05 社区反馈：服务器启动成功，结果仍可能坏掉

10月28日提交的GitHub问题114，提供了一组有价值的正反反馈。报告者使用DGX Spark上的GB10，在同一台机器、同一份权重和同一页面图像下，比较了两条运行路径。

按他的记录，Transformers路径约22秒得到正常内容；SGLang服务路径虽然成功启动，却很快重复输出坐标数字。一个页面约95秒触及8000个token的页面上限，仍未得到可用结果。输入来自论文页面，按300 DPI渲染。

这些数字属于报告者的环境和样本，本号未复现。失败路径与成功路径也不能拿来计算正常吞吐差距。检索时该问题尚无评论，具体原因仍待确认，不能把作者对底层实现的怀疑写成已经查明的缺陷。

对使用者最有帮助的，是故障表现足够具体：接口能访问，服务能返回，内容却在反复生成坐标。遇到这样的结果，应先停止批量任务，保存一个最小失败页面、运行环境和原始输出，再按官方支持路径排查。

不要上来就换扫描分辨率、改提示词、调并发，把所有变量一起动。可以先用同一页验证另一条官方路径，再判断是否是运行实现差异。这样的比较能缩小问题范围，却仍需要维护者确认原因。

团队验收也应把“请求成功”和“内容可交付”分开记录。连续重复、缺页、图片失效、表格行数异常，都应该能让任务进入待处理队列。否则，一次批处理显示全部完成，人工接到的可能是一整批格式正确的坏结果。

06 上手之前，先把成本和验收表备好

魔搭页面显示模型为3.34B，文件总量约6.87GB，两个权重分片分别约5.00GB和1.69GB。页面标注MIT，官方代码仓库也提供MIT许可。模型页未单列LICENSE文件；实际使用仍应核对所取版本及依赖的许可。

文件大小不能当显存需求。官方列出的测试环境使用A800-80GB，这说明作者测试了什么环境，不能反推所有使用者都必须购买80GB显卡，也不能据此承诺普通办公电脑能够顺畅运行。本轮Hugging Face访问失败，未核验其模型卡及文件与魔搭是否一致。

仓库的服务示例有10页窗口的设置，并明确提醒：缩小窗口有助降低内存，但可能削弱窗口边界上的跨页表格连接。参数调小后即使运行更稳，也要重测那些刚好跨过窗口边界的表格。

费用分成两条路看。自部署需要计算资源、环境维护和复核工时，开源许可不代表这些成本消失；托管服务按所选服务实际计费。本次没有核实适用的云服务报价，不给出“每页几分钱”的结论，也没有试用付费接口。

作为算账示例，假设同一批1000页文件，逐页复核平均耗时30秒，仅复核就约8.3小时。若某流程把平均复核降到10秒，仍需约2.8小时。这是工时假设，不是本号效率实测；评估试点时，应把实际耗时填回公式，并把失败重跑和修改结果的时间一起记入。

没有技术同事的团队，可以先把自己的验收要求写好，再找现有获批工具处理一小份脱敏样本。涉及合同、个人资料或内部价格时，先确认公司的上传范围。本文的本地后处理演示不需要真实业务文件，也不需要GPU。

 

图4｜试点验收按页面覆盖、明细保留、金额口径、素材可用逐项检查；任一异常都保留原件回溯。

下面这份记录可直接复制到工作表：文档编号、输入页数、空白页位置、跨页表位置、原始明细行数、输出明细行数、原始合计、输出合计、金额口径、图片能否打开、问题所在页、处理人、复核结论。原件无法确定的字段填“待确认”，不要填零冒充没有差异。

第一次试点，选一张普通页面、一段跨页表、一个带空白页和图片的文档，再加上业务上允许重复的明细。记录预期结果后再运行工具，避免看见输出以后才改验收标准。差异消除后扩大样本，正式交付仍保留复核责任。

想复现本文代码结果，可以从官方仓库取得对应后处理脚本，把带跨页标记的原始文本放进raw目录，用脚本的infer-dir指定输入、out-dir指定输出。第一次先做两页两行的正常样例，再增加第二笔相同明细。本文配套保存了四组输入、输出和运行脚本，读者也可以按图中的金额与行结构自行构造，不必安装整套模型来验证这一环。

One More Thing

一份文档被整理得越像成品，接收的人越容易跳过检查。长文档OCR的价值，应该体现在减少搬运之后，剩下的错误更容易定位、更容易改。跨页表格能否保留每一笔业务，比少显示几个重复表头更值得计入验收。

在实际工作里，最容易漏掉的是重复明细、原文页码，还是图片附件？这个答案，往往就是下一次试点最该放进样本的内容。

参考链接： https://github.com/baidu/Unlimited-OCR https://github.com/baidu/Unlimited-OCR/issues/114 https://modelscope.cn/models/PaddlePaddle/Unlimited-OCR-2

本文由AI辅助整理，已完成人工校核与修订。