简介：本文深入解析超长文档OCR的无限解析技术。针对多页文档解析中显存占用高、跨页内容衔接难等痛点，介绍稀疏参考滑动窗口注意力机制（SR-SWA）如何通过页面筛选与Token筛选两道"筛子"，配合无限跨度解码与KV Cache复用策略，将峰值显存从47GB降至1.77GB，实现解析跨度的持续延伸，为开发者处理千页级文档提供可复用的工程思路。

长文档 OCR 如何实现”无限”解析？一文讲透稀疏注意力与缓存复用机制

一、问题的提出：为什么长文档解析这么难

在文档智能处理领域，OCR（光学字符识别）早已不是新鲜事物。单页图片转文字、几十页 PDF 的批量处理，现有方案基本都能胜任。但当我们把目光投向真实业务场景——上百页的上市公司年报、上千页的历史档案、数千页的成套文献——问题就暴露出来了。

核心矛盾在于：页数越多，单步计算越重，显存越吃紧。

从模型推理的视角看，主流的多页文档解析方案通常采用”整序列推理”或”简单拆页”两种路径，各有各的麻烦：

整序列推理：把所有页面的视觉 Token 和文本 Token 一次性送入模型。随着页数增长，注意力计算的规模和 KV Cache 的占用呈线性甚至超线性上升，显存很快见底。
简单拆页：把长文档切成若干片段分别处理。拆页本身不难，难的是”接回来”。跨页的表格会被拦腰截断，段落连续性被破坏，页眉页脚、章节编号、图表引用等上下文信息丢失，后处理拼接的成本极高，效果还难以保证。

换句话说，行业缺少的不是”能识别文字”的模型，而是能让解析跨度持续延伸、同时把单步解码成本控制在稳定水平的机制。

近期某云厂商公开的一项 OCR 技术升级，正是围绕这个目标展开的。其上一代方案在开放模型社区累计下载已超过 1000 万次，而这次升级的核心，是从”控制文本侧缓存”进一步走到”压低视觉侧计算开销”，让任意页数的文档解析成为可能。本文不讨论具体产品评测，而是把这套方案背后的技术思路拆解出来，供开发者在自建长文档处理链路时参考。

二、一个朴素的灵感：人是怎么抄书的

这套机制的设计出发点非常朴素：人是怎么抄一本厚书的？

假设你要抄写一本 500 页的书。抄到第 500 页时，你会盯着当前这一页，遇到跨页的句子或表格，再翻回去看一眼上一页的结尾。你绝不会每写一个字，就把前 499 页重新通读一遍。

这个日常经验揭示了多页文档的一个关键结构特征：

页内联系密集：同一页内的文字、表格、图注之间高度相关，需要充分建模。
跨页依赖相对稀疏：真正需要跨页参考的，往往只是边界处的一小段内容、少数几个视觉区域。

如果模型能把注意力资源按这个分布来分配——页内算充分，跨页只算必要的——那么单步计算的成本就有可能不随总页数增长而膨胀。基于这一观察，研究团队提出了稀疏参考滑动窗口注意力机制（Sparse Reference Sliding Window Attention，简称 SR-SWA）。

三、SR-SWA 的两道筛子：Page Gate 与 Token Sieve

SR-SWA 可以理解为一个两级过滤流程，目标是层层缩小参与注意力计算的视觉参考范围，同时不破坏跨页的位置关系。

3.1 第一道筛：Page Gate——先选页面

第一级过滤作用于页面粒度。模型维护一个滑动窗口式的参考范围，将视觉参考限制在与当前解析位置相关的少数页面上，而不是全部历史页面。关键在于，筛选过程中保留跨页的位置关系——页码顺序、页面间的相对位置仍然作为结构信息参与计算，避免因裁剪而丢失”这一页在第几页之前/之后”的语义。

这一步的收益是直接的：参与后续计算的页面数量从”全部历史页”降为”窗口内相关页”，视觉 Token 的基数大幅缩小。

3.2 第二道筛：Token Sieve——再挑重点

第二级过滤作用于Token 粒度。在 Page Gate 筛选出的候选页面内，仍然存在大量视觉信息块（图像区域、视觉 Token）。Token Sieve 对这些候选块进行相关性打分，只选择少量最相关的远程 Token 桶参与注意力计算。

用工程语言描述，这相当于在注意力计算前做了一次稀疏化采样：不是所有视觉 Token 都值得被”看一眼”，让打分机制决定谁进入计算图。经过两道筛子，单步注意力实际处理的视觉 Token 规模被压到很小的量级，而这正是显存与算力开销的主要来源。

3.3 为什么是”视觉侧”

值得注意一个技术演进的脉络。上一代方案已经用滑动窗口注意力（R-SWA）控制了文本侧 KV Cache 的增长——文本 Token 的缓存不再随页数无限膨胀。但即便如此，模型仍需关注全部参考视觉 Token。页数一多，视觉侧的计算就成了新的瓶颈。

1.0 管住了文本缓存，2.0 进一步压低视觉计算开销。两级过滤的组合，使得”每一步解码需要处理的信息量”与”文档总页数”逐渐解耦。

四、无限跨度解码：分块处理与 KV Cache 复用

仅有稀疏注意力还不够。要在有限显存下实现持续解析，还需要一套流式推进的解码策略，即所谓的”无限跨度解码”。

其核心做法可以概括为三点：

按页面分块处理：将文档按页切分为块，模型逐块向前推进，而不是等待整个文档一次性输入。
复用边界页的 KV Cache：块与块之间存在重叠的边界页，这些页面的 KV Cache 被保留并复用，保证跨块上下文的连续性——这正好补上了”简单拆页”方案丢失跨页信息的短板。
持续解码：解析游标不断向后移动，已处理页面的缓存按策略释放或保留，使每一步的解码成本保持近乎稳定。

一个直观的伪代码示意：

# 无限跨度解码的简化逻辑示意
kv_cache = None
for page_block in split_by_pages(document, block_size=B, overlap=K):
    # 边界页复用上一块的 KV Cache，保证跨块连续性
    inputs = merge_overlap(kv_cache, page_block)
    # SR-SWA 在块内完成两级稀疏筛选
    output, kv_cache = model.decode(inputs, attn="SR-SWA")
    emit(output)
    # 按策略释放非边界页缓存，控制峰值显存
    kv_cache = retain_boundary(kv_cache, keep=K)

在这套组合拳下，官方披露的一项实验数据值得关注：在长文档基准测试、单序列推理条件下，分块与缓存复用方式将 KV Cache 峰值显存从 47GB 降到了 1.77GB。这个数量级的下降，意味着原本需要多卡或高显存设备才能处理的任务，可以在更普通的硬件配置上跑起来。

同时需要澄清一个容易被误解的点：“无限”指的是解析跨度可以持续延伸，而不是总耗时不变。整本书的总处理时间仍然随页数正常增长——毕竟每一页都要被真正解析。这套机制优化的是”单步成本”和”显存峰值”，而不是凭空压缩总计算量。

五、工程视角的启示

把这套方案抽象出来，对自建长文档处理链路的开发者有几条可复用的经验：

第一，先分析依赖分布，再设计注意力。 “页内密集、跨页稀疏”是一个可验证的结构假设。在动手做长序列优化前，先用数据统计跨页注意力的实际分布，往往能发现大量计算是冗余的。

第二，稀疏化要分层做。 页面级筛选降低基数，Token 级筛选提升精度，两级配合比单级粗筛更能在效果与开销之间取得平衡。只做一层，要么筛得太狠丢信息，要么筛得太松没收益。

第三，缓存复用是流式处理的命脉。 分块不难，难在块间衔接。保留边界页缓存这一招，本质上是用少量冗余存储换取上下文连续性，性价比极高。

第四，区分”峰值”与”总量”两个指标。 显存峰值决定方案能不能跑，总耗时决定跑得快不快。长文档场景下，前者往往是硬约束，优先优化峰值显存通常能解锁更多部署选项。

第五，少折腾拆分与拼接。 传统方案里大量的工程复杂度来自”切开再缝上”——切分策略、重叠窗口、后处理对齐、表格跨页合并。当模型自身具备持续解析能力时，这些外围补丁可以大幅简化，链路的鲁棒性反而更好。

六、小结

长文档 OCR 的难点，从来不只是”识别准不准”，而是”能不能在有限资源下一直识别下去”。稀疏参考滑动窗口注意力通过 Page Gate 与 Token Sieve 两道筛子压缩视觉侧计算，无限跨度解码通过分块推进与边界缓存复用控制显存峰值，二者结合把单步解码成本压到近乎稳定，让解析跨度得以持续延伸。

对于需要处理年报、档案、成套文献等千页级文档的团队而言，这套思路提供了一个清晰的技术方向：不要试图一次性吞下整本书，而是设计一套能一页接一页读下去、且每页成本可控的机制。这比任何拆分拼接的工程补丁都更接近问题的本质。

长文档OCR如何实现无限解析？技术原理解析