百度开源长文档解析模型，支持跨页合并

百度发布并开源的文心 Unlimited OCR 2，把重点放在了长文档解析：除了识别每页内容，还支持跨页文案合并、表格识别与合并。报道给出的代表性案例，是一次性解析累计超过 3,600 页的《哈利 · 波特》全系列 7 部作品。

对需要处理多页文档的程序员，这个方向值得关注。但「无限」不能直接理解为没有资源上限，基准测试拿到高分，也不等于接入业务后就一定更快、更省。短消息里的能力声明和证据边界，需要分开看。

「无限」页数，已经证明了什么

据 IT之家 10 月 30 日报道，百度在本月 27 日正式发布并开源 Unlimited OCR 2。报道将它的文档解析上限描述为从数十页推向「无限」，并给出超过 3,600 页、涵盖 7 部作品的解析案例。

这个案例支持的判断是：模型已经展示了处理数千页文档的能力。对于此前受页数限制、需要拆分文件的工作流，这是一个值得验证的变化。

「无限」应当看作长文档能力的宣传表述，不能当作没有资源约束的工程承诺。

原文没有说明这次解析使用了什么硬件、耗时多久、占用多少内存或显存，也没有给出案例的解析准确率。「一次性解析」具体如何组织任务，内部是否分段处理，报道同样没有交代。因此，不能仅凭页数推断它能在普通开发机器上完整运行。

比页数更有用的，是能不能接上跨页内容

Unlimited OCR 2 原生支持版面要素切分识别，并具备跨页文案合并、表格识别合并能力。

版面要素切分识别，可以理解为先区分页面中的不同内容区域，再进行识别。跨页合并则处理另一个问题：物理页面结束了，内容未必结束。一个段落可能延续到下一页，一张表也可能被分页截开。

对文档解析应用来说，文字识别只是前一步。后续如果要检索、展示或提取字段，还需要知道哪些内容属于同一个连续结构。否则，即便每页都识别出了文字，也可能留下大量拼接工作。

这也是这次发布更值得关注的地方：它不仅强调能处理多少页，还强调跨页内容的组织能力。不过，报道没有展示具体输出样例，也没有说明复杂表格的合并规则和失败情况，实际效果仍需用自己的文档验证。

两项基准高分，能说明多少问题

百度给出的测试结果是：

• 面向多页文档解析的 MPDocBench，得分为 84.6。
• 专门评估百页级超长文档解析能力的 MarathonDocBench，得分为 77.1。

百度称，两项测试均达到端到端性能 SOTA，即当前最佳水平。这里应保留归属：这是百度公布的测试结论，报道没有提供独立复测。

这两个成绩与产品定位一致，分别涉及多页和百页级超长文档。但原文没有列出对比模型、测试配置和分项结果，不能从总分继续推断它在中文扫描件、复杂表格等具体输入上都领先。

效率方面，报道还称它能在同样算力下处理更多、更快、更省。但没有给出吞吐量、耗时或成本数据，也没有明确比较对象。这部分只能视为尚待量化验证的能力声明。

我的判断

我更看重跨页文案与表格合并。单纯提高可处理页数，解决的是任务规模；把跨页内容接对，才可能减少后续的数据修复和人工检查。

但这篇报道不足以支撑直接选型。它给出了发布信息、大规模解析案例和两项基准成绩，却缺少部署条件、输出格式、许可证细节及可复核的效率对照。尤其是「更快、更省」，目前只有结论，没有足够数据供团队估算收益。

与逐页 OCR 后再写规则拼接的常见方案相比，模型原生处理跨页关系有吸引力。不过，原文没有给这两种做法的对照实验，无法判断具体能省下多少工作，也不能断言它在所有文档上都更可靠。

能拿来做什么

• 如果正在做文档解析或知识库导入，可以准备一组包含跨页段落和跨页表格的真实文件，把「是否正确合并」作为单独的验收项。
• 如果现有流程需要先拆分长文件，可以用同一份长文档比较两套流程，记录总耗时、资源占用和人工修复量，验证减少拆分是否带来实际收益。
• 在安排前端展示或 Node 服务接入前，先确认开源仓库、许可证、部署要求和输出结构。原文没有给出 API、命令或参数，暂时无法据此编写接入代码。