为什么AI文档阅读器在处理长PDF时会中途“卡壳”

想象一份 40 页的供应商合同。你将其上传到你最喜欢的 AI 工具，并询问终止条款的内容。该条款位于第 22 页。模型回答迅速且显得非常自信。然而，它给出的答案是错误的，如果你深入探究其实际行为，会发现它抓取的是第 3 页模板文本中的语言。

这并非一个假设的边缘案例。根据名为 SynthDocBench 的新论文，这几乎是一种可预测的故障模式。研究人员密切测试的六个视觉语言模型中，有五个模型在处理长文档的中间三分之一部分时最为困难，而且大多数模型在要求它们查看文档更深层内容时，表现会稳步下降。如果你基于这些模型构建产品，或者正在为实际工作流程在 OCR 和文档 AI 引擎之间进行选择，那么这篇文章值得你花费二十分钟来关注。

基于单一杂乱试卷进行评分的问题

大多数针对文档的视觉语言模型（VLM）基准测试，例如 DocVQA、ChartQA 和 MMLongBench-Doc，在评估“模型能否阅读文档并回答相关问题”方面做得相当不错。但它们的一个短板在于，无法告诉你模型为何会失败。

真实文档往往在多个维度上同时存在差异：文档长度、布局复杂度（单栏文本、密集的财务表格还是带有复选框的表单）、嵌入内容的类型（纯文本、表格、图表、扫描图像）以及问题的难度。当模型在现有基准测试中给出错误答案时，这四个因素纠缠在一起。模型是因为文档太长而困惑？还是因为布局特殊？亦或是因为答案需要表格计算而非简单的 Word 查找替换？你根本无法判断，因为这些基准测试中的文档是从现实世界中抓取而来，没有任何因素受到控制。

SynthDocBench 试图填补这一空白。作者们没有收集真实文档并指望各种变化相互抵消，而是从头生成文档，并独立调节每个因素，就像在实验室中设计受控实验，而不是观察野外出现的任何情况。

像做科学实验一样构建文档，而非简单抓取

用通俗的话来说，其机制如下：研究人员构建了一个大语言模型（LLM）流水线，能够端到端地生成完整的文档，包括内容、结构和视觉布局。每份文档都被分配六种布局原型之一（例如报告式、表单式、表格与文本混合式等），然后论文中独立变化文档长度、布局复杂度、文本/表格/图表/图像的组合比例，以及所提问的问题类型。这就是此处“组合设计”的含义：不是用一个旋钮将所有因素混合在一起，而是有多个旋钮，可以逐一调节，同时保持其他因素固定。

这里有一个巧妙的设计细节。在 40% 的情况下，生成过程会故意打破文档的“预期”模式，例如将图表放置在布局惯例中通常不会出现的位置。其目的是防止模型“作弊”。如果模型因为真实的年度报告通常如此排版，而学会了“关于收入的答案总是出现在第一页顶部”，它就可以在不实际阅读文档的情况下取得高分——这实际上是在匹配文档惯例，而非进行真正的理解。40% 的随机覆盖打破了这种捷径，因为模型不能再假设文档是按照“常规”方式排版的。

另一个引人注目的特点是长度。SynthDocBench 中的文档比 DocVQA、ChartQA 或 MMLongBench-Doc 通常包含的文档要长得多，且结构更多样化。这一点很重要，因为本文中发现的许多有趣失败案例只有在文档足够长时才会显现，而较短的基准测试会完全遗漏这些情况。

文档越长，模型性能下降越明显

第一个发现虽然最不出人意料，但仍值得明确指出：随着文档变长，准确率会下降。这本身并不令人震惊（随着上下文增长，一切任务都会变得更难），但关键在于下降的速度和幅度。由于 SynthDocBench 能够独立于版面和内容类型来控制长度，研究人员可以将准确率的下降具体归因于长度，而非“较长的文档往往也具有更混乱的版面”——这是以往所有基准测试中都存在的混淆因素。

对于任何构建处理多页文档（如租赁合同、医疗记录、财务报表、技术手册）产品的开发者来说，这是一个提醒：在双页样本上表现良好的演示，对于模型在真实用户上传的 60 页文档上的实际表现，几乎无法提供有效参考。

文档中部的盲区

这是该论文最有趣的结果。研究人员将每份文档分为三部分（早期、中期、晚期），并观察模型在哪些部分出现错误。在这样测试的六个模型中，有五个模型发现，文档的中间三分之一部分是回答问题最困难的部分。并不是结尾部分，人们可能会预期模型在那里“力竭”。而是中间部分。

他们还测量了他们所谓的“早至晚趋势”，基本上，随着文本的推进，早期文档问题与晚期文档问题的准确率是否会变差。六个模型中有五个显示出负趋势，意味着它们在后期材料上的表现比早期材料差，最陡峭的下降达到了8.3个百分点。

如果这种模式听起来很熟悉，那确实应该如此。研究长上下文纯文本语言模型的研究人员多年来已经记录了类似的现象，通常被称为“迷失在中间”：模型善于利用长输入开头和结尾的信息，而在利用埋在中心的信息方面表现较差。SynthDocBench 表明，同样的失败也出现在视觉文档理解中，而不仅仅是纯文本。这是一个有意义的扩展，因为很多人假设多模态文档模型会表现不同，因为它们处理的是布局和图像，而不仅仅是令牌流。但它们的表现并没有不同。弱点随着架构一起存在。

实际上，这意味着一个阅读30页保险政策的模型，与第2页或第28页的内容相比，更有可能遗漏第12到20页的内容，即使这些中间页面在客观上并不更难阅读。

图表恰恰在你最需要它们时失效

第三种失效模式专门针对图表理解。阅读柱状图或折线图并回答相关问题，本身就比阅读纯文本更具挑战性，因为模型必须将视觉元素（柱体、坐标轴、图例）映射到数值含义上。SynthDocBench 发现，一旦图表嵌入长文档中，这种能力会严重退化，其下降幅度甚至超过了上述仅由文档长度增加所预测的一般性衰退程度。

想想图表在实际文档中的存在场景：季度财报演示文稿、科学论文、政府报告、导出为 PDF 的销售仪表盘。这些恰恰是图表承载着关键提取信息的文档，而 SynthDocBench 也表明，模型在这些场景下的可靠性最低。

为什么这对构建或选择 OCR 的人至关重要

如果您正在评估用于超越简单演示的 OCR 或文档 AI 引擎，这篇论文提供了三个实用的启示：

• 使用真实的文档长度进行测试，而不是短样本。 在五页测试 PDF 上表现良好的模型，在用户上传 50 页合同时可能表现迥异。要求任何供应商（或运行任何开源模型）针对您在生产中实际会遇到的文档长度进行测试。
• 不要轻信关于长文档中间部分的答案，除非进行抽查。 如果工作流依赖于从长文件内部提取信息，这正是该论文标记为最不可靠的区域。考虑将长文档分块并单独查询每个块，或者在使用模型阅读之前使用检索技术提取相关部分，而不是将整个文档放入一个长的上下文窗口中。
• 图表密集的长文档需要额外审查。 如果您的用例涉及包含嵌入图表和表格的报告（如财务报告、研究论文、分析导出），不要假设能良好处理孤立图表的模型也能同样良好地处理埋在报告第 20 页的相同图表。单独验证图表，与纯文本提取分开进行。

鉴于中文等表意文字系统具有字符数量庞大、版面布局密集的特点，若该研究主要基于英文/拉丁文本，其在处理高密度中文文档时的结论可能需要更谨慎的验证。

这并非反对在文档工作中使用 VLMs。而是主张以 SynthDocBench 测试文档 AI 的方式进行测试：分解为受控的部分，而不是基于少数示例的“感觉”来判断。

该基准无法告诉你的内容

诚实地指出局限性至关重要。SynthDocBench 是完全合成的，由 LLM 流水线生成，而非源自真实的扫描文档、申报文件或表格。合成文档之所以有用，正是因为它允许你控制每一个变量，但这种控制是有代价的：LLM 生成的“发票”或“报告”可能带有其独特的细微统计特征，这与真实发票和报告的实际排版和措辞存在差异。论文中提出的当前模型可能过度拟合基准测试人工痕迹（artifacts）的观点，是一把双刃剑。SynthDocBench 所测量的某些内容本身可能也是一种新型的人工痕迹，只不过是一种控制更为精细的痕迹。

该评估还涵盖了七款前沿 VLM，这是一个有意义的样本，但仅代表 2026 年中可用的模型快照。模型在长上下文任务上的表现正在快速演变，在假设“中间迷失”（lost in the middle）弱点普遍适用之前，值得检查较新的模型发布是否已专门针对这一弱点进行了优化。

尽管如此，无论存在上述哪些局限性，其核心贡献依然成立：通过独立控制长度、布局、模态和问题类型，研究人员隔离出了那些结构上更混乱的真实世界基准测试无法揭示的失败模式。特别是文档中间的盲点，是一个真正新颖且有用的发现，而不仅仅是对已知内容的重新包装。如果你正在构建任何以阅读长文档为生的系统，那么在设计你的评估流水线以及产品的分块（chunking）策略时，务必考虑到这一盲点。