超长文档OCR的稀疏注意力与显存优化解析

一、长文档OCR为什么难

在真实业务里，长文档OCR并不是简单地把单页识别循环执行。合同、财报、招股书、扫描书籍、档案资料动辄几百页，版面结构复杂，表格、标题、页眉页脚、跨页段落交错出现。传统单页识别方案容易在页面边界处丢失上下文，跨页表格可能被截断，页脚页码可能被误判为正文，连续段落的语义关联也容易被切断。

如果将整份文档一次性送入视觉编码器，让模型直接读取所有页面，理论上可以获得全局信息。但视觉Token数量会随页数线性增长。300页文档可能产生数万甚至更多的视觉Token，注意力计算量随序列长度呈平方增长，显存占用也迅速膨胀。即便显存足够，长序列中的远距离注意力也未必带来等比例的精度收益，反而容易被无关页面干扰。

因此，长文档OCR的核心问题不只是“看得完”，而是如何在有限的显存和算力下，让模型在阅读当前页时仍然能获得必要的跨页上下文，同时避免被全部历史页面拖垮。这涉及两个层面：一是注意力范围控制，二是视觉缓存的调度与释放。

二、从“抄书”到注意力范围控制

长文档解析可以类比为人工抄写一本厚书。抄写者目光主要落在当前页，只在需要核对前文时才翻回相关页面。没有人会每写一句话就把整本书从头翻一遍。这个直觉构成了稀疏参考滑动窗口注意力机制，即SR-SWA的出发点。

SR-SWA的目标不是让当前页关注所有历史页面，而是从大量历史页面中快速筛选出少数真正有价值的参考区域。整个机制可以拆成两个关键步骤。

第一是页面门控。模型在处理当前页时，不需要把所有历史页都纳入候选。页面门控先根据页面间关联性，把可能包含有用信息的页面范围缩小。例如，当前页提到的某个段落、某个定义或某张续接表格，通常只会落在最近若干页或明显相关的少数页面上。页面级筛选的粒度较粗，但可以迅速压缩候选规模。

第二是Token筛选器。在缩小后的候选页面集合里，不是所有视觉Token都值得当前步关注。页面中大量空白、页眉页脚、重复背景元素或与当前问题无关的区域会形成噪声。Token筛选器从候选区域中挑出最相关的一批视觉Token块，进一步提高注意力计算的密度。

通过页面门控和Token筛选器的组合，模型每一步解码所参考的视觉Token数量被限制在一个相对稳定的范围，单步注意力计算成本几乎不随总页数增长。这意味着解析第1页和第300页时，单步计算量保持近似恒定，长文档推理不会因为历史变长而持续变慢。

三、无限解码：让显存不再随页数累积

注意力范围缩小能降低单步计算成本，但如果没有缓存管理，所有处理过的页面视觉表示会一直留在GPU显存中。即使每步只关注少量Token，几千页累计下来的视觉KV Cache仍会撑爆显存。长文档解析还需要解决“读过的内容如何保存、何时丢弃”的问题。

无限解码机制将整份文档切分成多个有重叠的页面组，按顺序处理。这种分块方式的关键在于相邻块之间存在重叠页，边界页面的视觉缓存可以被复用。当模型处理到下一块时，不需要重新编码所有边界内容，只需要把仍然有参考价值的缓存保留在工作区中。已经离开滑动窗口、不再被后续页面需要的视觉KV Cache则及时释放。

可以将其理解为一个固定大小的视觉缓存工作区。模型持续向后阅读时，工作区像窗口一样沿文档移动：新页面进入，旧页面退出，显存中始终只维护有限数量的视觉表示。随着文档长度增加，显存占用不再线性增长，而是趋于稳定。

这种设计尤其适合长文档吞吐场景。批量处理多份长文档时，如果每个请求都长期占用大量显存，并发能力会受到严重限制。缓存工作区缩小后，单请求显存需求下降，同样硬件条件下可以容纳更多并发任务，端到端吞吐量得以提升。

四、工程实现思路

在工程上，长文档OCR系统通常分为几个阶段：版面检测、文本行级识别、阅读顺序恢复和结构化输出。稀疏注意力与无限解码主要作用在识别和语义理解层面，尤其适合多页扫描件或版式复杂文档的端到端解析。

一个简化的工作流如下：

# 伪代码：按页面组处理长文档
def process_long_document(page_images, group_size, overlap):
    # 工作区缓存，保存当前窗口内的视觉表示
    workspace = {}
    groups = split_into_groups(page_images, group_size, overlap)
    for group in groups:
        # 对当前页面组提取视觉特征
        visual_features = encode_pages(group, workspace)
        # 使用稀疏参考滑动窗口注意力进行解码
        for page in group:
            candidate_pages = page_gate(page, workspace)
            selected_tokens = token_filter(page, candidate_pages)
            result = decode_with_sparse_attention(page, selected_tokens, workspace)
            # 输出当前页结果
            yield result
            # 更新工作区：保留必要缓存，释放过期缓存
            update_workspace(workspace, page, group)

其中page_gate负责页面级筛选，token_filter负责Token级筛选，update_workspace维护缓存工作区。实际系统中，页面分组和重叠宽度需要根据文档类型调整。例如，财报通常有大量跨页表格，重叠页可以适当增加；简单合同或单栏文档可以减小重叠，以降低重复计算。

对于显存敏感场景，还需要结合混合精度推理、激活检查点以及缓存量化。视觉缓存本身占用的显存经过筛选后已经显著减少，进一步量化可以在精度损失可控的前提下换取更高并发。

五、性能收益与适用边界

在超长文档场景下，稀疏参考滑动窗口注意力与无限解码的主要收益体现在三个方面。

第一，单步解码计算量保持近似恒定。页面门控和Token筛选器限制了每步参考的视觉Token规模，使得模型处理第300页时不会比处理第10页明显更慢。

第二，显存占用从线性增长变为近似恒定。随着视觉缓存工作区不断滑动，旧页面缓存被释放，峰值显存由窗口大小决定，而不是由文档总页数决定。

第三，吞吐量提升。单请求显存降低带来更高的并发空间，在多份长文档同时解析时，系统整体吞吐能力更强。

需要注意的是，这类方法的收益与文档类型、页面结构以及任务形态相关。对于页与页之间语义关联较弱的文档，滑窗和稀疏注意力通常可以在很小精度损失下获得较大速度收益。对于跨页关联非常强的复杂文档，需要合理设置参考范围，否则可能漏掉远距离依赖。实际业务中，需要根据文档类型调整页面门控的候选范围和Token筛选器的保留比例。

六、从长文档OCR到通用长上下文理解

长文档OCR可以看作是长上下文多模态理解的一个具体实例。视觉输入与文本输入不同，视觉Token往往数量庞大，且包含大量冗余信息。在视频理解、多页文档问答、长表格解析等场景中，类似问题同样存在：全量保存所有帧或所有页面的视觉缓存不现实，远距离注意力也未必总是有效。

稀疏参考与缓存工作区的思想并不局限于OCR。任何需要处理超长视觉序列的场景，都可以借鉴“只维护有限窗口内的关键缓存、按需引用远距离信息、及时释放无效表示”的思路。随着多模态模型处理的内容越来越长，如何在精度、速度和显存之间取得平衡，会持续成为工业落地中的重点。

对于企业用户而言，长文档解析能力直接影响业务流程自动化程度。合同审核、年报分析、档案数字化、招标文件解析等场景都涉及数百页甚至上千页的文档处理。一个能够稳定处理长文档、同时保持可控资源占用的OCR系统，可以将这些场景从人工分页识别推进到端到端结构化输出，减少拆页和拼接带来的错误。

七、总结

长文档OCR的瓶颈不在单页识别精度，而在于跨页上下文建模与超长视觉输入的工程可控性。稀疏参考滑动窗口注意力通过页面门控和Token筛选器，把每步注意力的参考范围保持在有限规模；无限解码机制则通过滑动窗口缓存，让显存占用不再随页数线性增长。二者结合，使模型可以持续处理长文档，同时维持稳定的单步计算成本和有限的显存工作区。

这类方法的价值在于，它把长文档解析从简单的“页数扩展”变成有控制的“信息筛选与调度”。对于需要处理海量长文档的企业场景，理解注意力范围控制和缓存管理背后的设计逻辑，比单纯追求单页指标更有实际意义。