简介：长文档OCR解析长期面临显存占用高、跨页内容断裂、计算成本随页数快速上升等难题。本文从工程视角拆解一种面向超长PDF的持续解析方案：通过稀疏参考滑动窗口注意力机制压缩视觉计算，再配合分块解码与KV Cache复用控制显存峰值，使解析跨度可持续延伸。读者可了解其背后的注意力筛选、状态缓存与调度策略，为自研或选型长文档OCR方案提供参考。
超长PDF的OCR解析，从来不是简单地把页面拆开再识别。真正困难的地方在于：页数一旦从几十页增长到几百页甚至上千页，解析系统面临的不仅是单页识别精度问题，更是一整套关于计算资源、状态管理与上下文连续性的系统性问题。
以常见的年报、档案、论文合订本为例，这类文档少则两三百页，多则上千页。传统的逐页解析方案虽然容易实现，但会带来明显的副作用。表格可能被拦腰截断，段落跨页时语义被割裂，页眉页脚重复识别却难以去除，目录页码与实际内容错位。更麻烦的是，如果为了提高跨页理解能力而把整本页面同时送入模型，显存占用会以接近线性的速度增长，单步解码时间也会急剧上升。
在这个问题上的工程判断，通常需要在三个维度之间做出权衡：计算成本、显存上限、上下文连续性。大多数落地场景中，显存是硬约束，而上下文连续性又不能完全牺牲。于是问题就转化为：能不能让模型在持续解析长文档时，每一步只关注最相关的一小部分视觉信息，同时保留跨页依赖所必需的历史状态？
要理解这个问题的解法，可以先回到注意力机制本身。标准的多页文档解析如果采用全局注意力，意味着每个解码步骤都要与全部页面的视觉Token计算相关性。页数越多，注意力矩阵就越大，计算与显存占用同步增长。这种“全量参考”的策略虽然理论上能保留最多的跨页信息，但在工程上难以持续。
一个合理的优化方向是引入稀疏性：不是每一步都扫描全部历史页面，而是让模型具备一种“按需回看”的能力。现实中，人在阅读第500页时，并不需要把前499页重新看一遍，只会在遇到跨页表格、引用说明或者上下文理解困难时，有选择地回看少数相关页面。多页文档的信息结构也类似：页内关联密集，跨页依赖相对稀疏。真正需要跨越几十页甚至几百页建立联系的情况并不经常出现，但一旦出现，就对解析质量至关重要。
基于这个观察，可以设计一种两层筛选结构。第一层是页面级筛选，把视觉参考范围从“全部页面”缩窄到若干相关页面，同时保留这些页面之间的位置关系。第二层是Token级筛选，在候选页面的视觉信息块中进一步打分，只选择分数最高的一小部分远程Token参与当前解码。这样，视觉计算的规模不再随总页数线性增长，而是趋于一个相对稳定的预算范围。
这种机制的价值不在于单纯减少计算量，而在于它把长文档解析从“越到后面越重”变成了一种近似匀速的过程。每一步解码的视觉输入保持在可控规模，模型依然具备跨页回溯的能力，只是回溯经过了筛选而非全量扫描。
上述思路可以具体化为一种稀疏参考滑动窗口注意力机制。它的核心由两个组件构成：页面门控与Token筛选。
页面门控负责回答一个问题——当前解码步骤应该参考哪些页面。对于长文档OCR任务，视觉参考范围可以分成两类：一类是当前页及其邻近页面，它们承载了绝大多数的局部上下文；另一类是跨页依赖所指向的远端页面，例如上一节末尾延续到当前页的表格，或者某个被引用的附录图表。页面门控通过计算粗粒度的相关性分数，决定是否把某个远端页面纳入参考集合。
Token筛选则是在页面门控选中的候选页面内部做进一步压缩。每个页面的视觉特征通常被切分为多个信息块，每个块包含了若干Token。Token筛选会对这些信息块打分，只保留分数最高的一小部分参与注意力计算。这样做的依据是：即便某个页面与当前步骤相关，也未必需要该页面的全部视觉细节。例如，一个跨页表格的延续部分可能只需要参考表格的表头和上一页末尾的几行，而不是整页的所有图元。
这两个组件串行工作，形成“先选页面、再挑Token”的漏斗结构。从工程实现角度看，这种方式将远程视觉参考的规模从“页面数×每页Token数”压缩到一个固定预算，使得注意力矩阵的大小不再受总页数直接影响。更重要的是，页面门控保留的是“页面”这一层级的位置关系，不会因为Token压缩而完全丢失跨页结构信息。
稀疏参考滑动窗口注意力机制解决了视觉计算随页数增长的问题，但仅有这一层还不够。长文档解析的另一个瓶颈在于解码过程中的状态管理，也就是KV Cache的增长与复用。
在多页文档的持续解析中，一种常见的做法是按页面分块处理。每一块内部正常计算注意力并保存KV Cache，处理完一块后，不丢弃全部状态，而是保留边界页的缓存作为下一块的初始化上下文。这样，当解析推进到后续页面时，模型依然可以“看到”上一块的结尾几页，从而维持表格、段落与列表的连续性。
这种分块与缓存复用策略的关键收益在于显存峰值控制。全量处理时，KV Cache的峰值与总页数成正比；而分块处理后，峰值只取决于单个块的大小加上保留的边界缓存规模。对于数百页甚至上千页的文档，这种差异是数量级级别的。显存峰值的大幅下降，使得原本需要大显存设备才能完成的任务，可以在更有限的硬件条件下运行。
值得注意的是，这里的“无限”描述的是解析跨度的可持续性，而不是总耗时的恒定。整本书的解析时间仍然随页数增加而增长，这是任何逐页处理方式都无法回避的。工程目标在于让每一步的解码成本保持近乎稳定，避免越往后越慢、越往后越吃显存的退化现象。将有限的计算资源用在持续处理上，而不是消耗在重复加载与状态重建中。
在实际落地长文档OCR解析时，稀疏注意力与缓存复用需要配合合理的调度策略。一个典型的处理流水线可以描述如下：
# 示意性调度流程def parse_long_document(pages, block_size=16, boundary_keep=2):cache = Noneresults = []for start in range(0, len(pages), block_size):block = pages[start:start + block_size]# 当前块解码，携带上一块的边界缓存block_cache = decode_block(block, prev_cache=cache)# 保留边界页缓存，供下一块使用cache = block_cache[-boundary_keep:]results.extend(block_cache.parse_results)return results
这段伪代码表达的是一种通用的分块调度思路，并非某个特定产品的接口。其中，块大小与边界保留页数这两个参数决定了显存峰值与跨块连续性的平衡。块越小，显存峰值越低，但跨块衔接的次数增加；边界保留越多，连续性越好，但缓存占用上升。实际部署时需要根据目标硬件与文档类型调参。
另一个工程细节是视觉Token的预算分配。稀疏参考机制虽然减少了远程Token数量，但当前页及其邻近页的Token仍然占据主要预算。对于版式复杂的页面，例如双栏论文、含大量表格的年报、带批注的扫描件，单页Token数本身就可能很高。此时可以在页面内部进一步做自适应压缩，例如根据版式分析结果调整不同区域的分辨率与Token密度。
这套技术路线给长文档OCR的工程选型带来几点启示。第一，文档解析的连续性不能只靠后处理拼接来解决。先拆页再识别再拼接的流水线，在简单文档上可行，但在包含复杂表格与跨页段落的长文档上会暴露出大量结构问题。更合理的方式是在解码阶段就保留跨页状态，让模型具有持续解析的能力。
第二，视觉计算与文本状态是两个需要分别控制的瓶颈。只优化文本侧的缓存增长，而不限制视觉参考规模，页数一多仍会陷入视觉计算的瓶颈。反过来，只压缩视觉Token而不管理解码缓存，也没法真正控制显存峰值。两者需要协同设计。
第三，长文档解析的工程目标不应该是追求绝对的最快或最省，而是追求成本与质量的稳定。一旦每一步的解码成本保持可控，整本书的解析时间就大致与页数成线性关系，这对于容量规划与资源预估非常重要。
最后，相关技术报告中提到这套方案在单序列推理条件下将KV Cache峰值显存从数十GB量级降低到不足2GB，这个数据可以作为工程参考。它说明的是分块与缓存复用策略在极限场景下的收益量级，而非对任何特定环境的承诺。不同的文档类型、版式复杂度与硬件配置，都会影响最终的实际效果。对于有意在长文档OCR方向投入的团队来说，核心不是照搬某个数字或某套参数，而是理解其背后的注意力筛选与状态管理逻辑，再结合自己的场景做取舍。