文心Unlimited OCR 2：超长文档解析的技术跃迁

一、从“单页识别”到“整册理解”：长文档解析的必答题

企业级文档处理的真实负载，往往不是一张发票、一页合同，而是数百页的年报、上千页的卷宗、成套的技术规范。传统OCR方案通常按页切分、逐页识别，再依靠后处理规则把结果拼回去。这种方式在单页场景下足够好用，但放到整册文档上会暴露三个问题：

• 跨页结构丢失：跨页表格、段落续接、章节层级很难在“页”的粒度上正确还原；
• 上下文割裂：术语、编号、指代等长程信息分散在不同页面，拼接时容易自相矛盾；
• 工程成本高企：切分、排序、合并、校验的流水线越堆越长，维护成本随文档复杂度持续上升。

另一种思路是借助长上下文模型“一锅端”地处理整册文档，但自注意力的计算量随序列长度呈平方增长，显存占用同样水涨船高。百度于2026年10月27日发布并开源的文心Unlimited OCR 2，正是针对这一矛盾给出的系统性方案：它支持一次性解析累计超过3,600页的超长文档，已实现对一套共7部、累计超过3,600页的长篇系列作品的完整解析，并在多项长文档解析基准评测中分别取得84.6分与77.1分的成绩。

二、超长文档解析的三重技术挑战

1. 计算复杂度的平方陷阱。 标准自注意力的计算复杂度为 O(L²·d)，其中 L 为序列长度、d 为表示维度。文档从100页扩展到3,600页，序列长度增长36倍，注意力计算量约增长1,296倍——这不是简单堆机器就能线性解决的问题。

2. 显存与中间状态的开销。 注意力矩阵、键值缓存等中间状态均随长度增长；对生成式解码而言，若一次性产出整册文本，解码侧同样需要维护庞大的上下文状态，显存峰值很容易突破单卡上限。

3. 跨页结构与长程语义。 即使算力充足，模型还要“读懂”文档：页眉页脚噪声过滤、多栏阅读顺序还原、跨页表格合并、图表与正文对应、章节层级重建，以及术语与编号的全局一致性。这些恰恰是长文档解析质量的关键，也是基准评测重点考察的维度。

三、从第一代到第二代：路线演进与遗留瓶颈

第一代Unlimited OCR引入参考滑动窗口注意力机制，将解析范围从单页拓展至连续数十页。其核心思路是：把注意力限制在局部滑动窗口内，将复杂度从 O(L²) 降为 O(L·W)（W为窗口宽度），同时通过“参考”机制在窗口之间传递关键信息，缓解窗口割裂带来的长程依赖丢失。

这解决了“几十页”的问题，但距离“几千页”仍有距离：

• 窗口总量仍随页数增长，注意力与中间表示的累计开销线性攀升，显存占用持续走高；
• 解码侧若一次性生成整册文本，输出状态同样不可持续。

换言之，编码与解码两端都存在随文档长度增长的“隐性账单”，超长文档场景下二者叠加成为瓶颈。

四、文心Unlimited OCR 2 的核心设计

4.1 SR-SWA：编码侧的复杂度“降压”

该模型采用的SR-SWA延续了参考滑动窗口注意力的技术脉络，可以理解为面向超长文档的升级：窗口内部负责精细的局部建模（版面、文字、表格结构），跨窗口的长程信息则通过参考机制压缩与传递。其设计意图在于：让长程依赖建模的开销不随总页数平方增长，而是受控于窗口数量、近似线性扩展——远距离上下文不必两两可见，而是通过参考载体“间接通信”，在保留关键长程信息的同时压住计算与显存开销。

4.2 无限解码：解码侧的状态“瘦身”

如果说SR-SWA解决的是“读得进”，无限解码机制解决的就是“写得完”。传统生成式解码需要为整篇输出维护完整上下文状态；无限解码以流式方式按窗口、按段落滚动产出结果，处理完的中间状态及时释放。这样，解码侧的显存占用与“当前正在处理的窗口”相关，而不再与全文档长度挂钩；输出可以边解析边消费，天然适合流水线化处理。

4.3 编码与解码的协同

编码端控计算、解码端控状态，两者配合之后，“输入长度”不再受限于单次前向的显存上限，“输出长度”也不再受限于单次生成的上下文配额。这正是其能一次性完成3,600余页解析的关键：把一个“超长序列问题”转化为“连续窗口上的流式问题”。

五、能力表现与理性解读

在两项长文档解析基准评测中，该模型分别取得84.6分与77.1分，综合反映了多页版面还原、长文档内容识别与结构化输出等方面的表现。需要提醒的是：评测得分依赖任务口径与数据分布，实际选型时建议使用业务自有数据复测，重点关注跨页表格、阅读顺序、术语一致性等与自身场景强相关的指标。

六、典型应用场景

• 档案与卷宗数字化：历史档案、司法卷宗、工程配套文档的整册入库；
• 金融、法律、医疗长文档批量结构化：招股书、审计底稿、病历报告的规模化解析；
• 出版与文献整理：整本图书、古籍、学位论文的文本化与结构重建；
• RAG知识库构建：为检索增强生成系统提供整书级别、结构完整的高质量语料，避免碎片化切分损伤语义。

七、工程落地建议

# 伪代码：超长文档流式解析的一般流程（仅作示意，非真实接口）
pipeline = LongDocParsingPipeline(
    window_size=64,         # 按显存预算设定窗口大小
    streaming_decode=True   # 解码侧流式产出
)
for window in stream_pages("archive_3600p.pdf"):
    layout = pipeline.analyze_layout(window)   # 版面分析
    blocks = pipeline.decode(window, layout)   # 流式解码输出
    emit(merge_cross_page(blocks))             # 跨页合并与结构重建

实践中还应注意五点：

1. 输入预处理：统一分辨率与色彩、纠偏去噪，扫描质量直接决定识别上限；
2. 窗口与并发调优：结合显存预算设置窗口大小与批处理度，在吞吐与稳定性间取得平衡；
3. 结构化后处理：重建标题层级与阅读顺序，合并跨页表格与续接段落；
4. 质量保障闭环：以置信度阈值筛出低可信结果，叠加跨页一致性校验与人工抽检；
5. 云上流水线组织：可借助百度智能云的对象存储、容器服务、日志与监控告警等通用产品类目，搭建“存储—解析—校验—入库”的弹性流水线。

八、结语

从第一代的“连续数十页”到第二代的“3,600页整册解析”，文心Unlimited OCR 2展示了一条清晰的演进路径：以SR-SWA压住编码侧的计算与显存开销，以无限解码机制化解解码侧的状态膨胀，把超长文档解析从“工程上的不可能”变为“可以规划的能力”。对于需要规模化处理长文档的团队而言，值得先基于自有数据完成一轮验证，再决定将其纳入生产流水线的深度，同时兼顾数据合规与隐私保护要求。