Apple LensVLM：把长文档压成图片，再按需展开

Apple 最近开源了 LensVLM-9B，这是一个专门面向长文档视觉理解的 9B 参数视觉语言模型。它没有沿着传统路线，把整份 PDF 的所有页面都直接塞进模型上下文，而是先把长文档压缩成一组页面图像，让模型快速浏览全局，再通过学习到的工具只展开与问题相关的页面。

这套方法的核心价值很明确：让模型用低成本获得长文档的全局视野，用高成本处理少量真正相关的细节。 对合同、论文、财报、技术手册、扫描档案这类几十页甚至上百页的文档来说，LensVLM 解决的不是单纯的图像识别问题，而是视觉上下文如何分配的问题。

LensVLM 是什么？

LensVLM 是一种通过页面图像压缩长上下文、再选择性展开相关页面的视觉语言模型。 与把每一页都以高分辨率输入模型的做法相比，它把文档理解拆成了两个阶段：第一阶段快速扫描压缩后的页面，第二阶段调用工具获取关键页面的完整细节。

从用户角度看，这个过程类似于人在查一份很长的报告。人通常不会从第一页开始逐字阅读，而是先扫目录、标题、页眉、图表和关键词，判断哪些页面值得仔细看。LensVLM 尝试把这种阅读策略变成模型的原生能力：先看缩略版的全局，再决定把注意力花在哪里。

这里的“压缩”并不是把文本简单摘要成几句话，也不是把 PDF 转成纯文本后截断。LensVLM 保留的是页面的视觉布局，包括段落位置、表格结构、图片、图表、标题层级以及扫描文档中的文字。模型先从低成本的视觉表示中定位信息，再对相关页面进行更高保真的读取。

它为什么要把文字变成图片？

把长文档渲染成图像，可以在保留页面布局的同时减少传统文本上下文的线性膨胀。 一份包含大量表格、双栏排版和复杂脚注的 PDF，转换为纯文本后往往会丢失版式关系；如果全部以高分辨率页面输入，又会迅速消耗视觉 token。

传统长文档 VLM 通常面临两个互相牵制的问题：输入页面越多，模型看到的全局信息越完整，但上下文和显存压力越大；页面分辨率越高，文字和表格越清晰，但输入成本也越高。LensVLM 的思路是把两者拆开处理，而不是要求每一页同时满足“看得全”和“看得清”。

可以把它理解成图书馆的检索系统。缩略页面相当于书架索引，负责告诉模型某个答案大概在哪几页；页面展开相当于取下原书，负责读取合同条款、表格数字或论文公式等细节。模型不需要在第一轮就把整本书逐字读完。

这对于包含大量冗余页面的真实文档尤其有用。财报中可能只有几页涉及现金流，技术手册中可能只有某个章节涉及指定错误码，法律合同中真正决定结论的可能只是定义、例外和违约责任条款。让模型把计算资源集中在这些页面上，比平均分配给所有页面更符合实际使用场景。

技术路线：Qwen3.5-9B-Base 作为骨干

LensVLM-9B 使用 Qwen3.5-9B-Base 作为基础视觉语言模型，并在其上训练长文档页面选择与工具调用能力。 根据论文资料，这个骨干模型由 9B 参数语言解码器和视觉编码器组成，视觉编码器采用带空间合并的 ViT，并根据图像分辨率生成不同数量的视觉 token。

这一选择有三个直接原因。第一，Qwen3.5-9B-Base 原生支持图文交错输入，适合页面浏览、问题追问和工具调用混合在一起的多轮格式。第二，它支持可变分辨率图像，不需要先把所有页面强行缩放到同一个尺寸，这有助于减少渲染文字时的细节损失。第三，Apple 的规模实验显示，9B 是可靠工具使用行为开始出现的最低规模之一。

LensVLM 并不是简单地给一个基础 VLM 加上“选页”提示词。它需要模型学会一套完整的操作流程：判断当前页面缩略图是否包含答案线索，选择需要展开的页面，读取展开后的内容，必要时继续发起新的页面选择，然后把多个页面的信息合并成回答。

这意味着模型要学会的不是单次分类，而是一种带有中间动作的推理行为。它既要回答“答案在哪”，也要决定“下一步该看什么”。这也是为什么论文把页面选择准确率单独列出来，而不是只报告最终问答结果。

9B 规模带来的提升有多大？

在论文给出的规模实验中，LensVLM-9B 的问答准确率达到 68.9%，页面选择准确率达到 76.8%。 这两项指标分别衡量最终回答是否正确，以及模型是否选择了与问题相关的页面。

| 模型规模 | 训练阶段 | 问答准确率 | 页面选择准确率 | |---|---:|---:|---:| | 2B | Base | 13.2% | — | | 2B | LensVLM | 45.5% | 49.4% | | 4B | Base | 25.7% | — | | 4B | LensVLM | 56.3% | 59.1% | | 9B | Base | 31.3% | — | | 9B | LensVLM | 68.9% | 76.8% |

从这组数据看，训练方法本身带来了明显收益。2B 模型从 13.2% 提升到 45.5%，绝对提升 32.3 个百分点；4B 模型从 25.7% 提升到 56.3%，绝对提升 30.6 个百分点；9B 模型从 31.3% 提升到 68.9%，绝对提升 37.6 个百分点。

更值得注意的是，9B 不是简单地比 4B 多一点容量。LensVLM-9B 的问答准确率比 LensVLM-4B 高 12.6 个百分点，页面选择准确率也达到 76.8%。这说明在长文档任务中，模型规模可能直接影响它能否稳定执行“扫描—选择—展开—回答”这条多步链路。

不过，这些数字需要放回论文实验设置中理解。资料目前给出了整体 QA Acc 和 Sel. Acc，但没有在公开摘要中完整展开所有数据集、文档类型和上下文长度的细分结果。因此，不能简单把 68.9% 当成所有 PDF 场景下的通用准确率。对于高度结构化的报告、低质量扫描件、手写内容或跨页表格，实际表现仍需要进一步测试。

它和普通长上下文模型有什么区别？

普通长上下文模型主要依靠扩大输入窗口容纳更多内容，而 LensVLM 主要依靠选择性读取减少无效内容。 这两种路线并不是完全互斥，但解决的是不同层面的问题。

如果模型拥有极大的文本上下文窗口，可以把 PDF 转成文本后一次性输入，但文本化过程可能破坏布局，还会丢失图表、公式和页面位置关系。即便输入窗口足够大，模型也可能遇到“信息埋在中间”的问题：相关内容确实在上下文里，却因为大量无关页面干扰而难以稳定调用。

视觉长上下文模型则更擅长保留页面原貌，但每一页高分辨率图像都可能产生大量视觉 token。对于 100 页文档，平均处理每一页的成本通常不划算，因为用户的问题往往只涉及其中几页。

LensVLM 的不同之处在于，它把“上下文长度”转化成了“检索与展开策略”。模型不是被动接受所有页面，而是主动决定哪些页面值得消耗更多上下文。这种方式更接近一个带视觉检索能力的 VLM，而不是单纯扩大输入窗口的多模态模型。

| 方案 | 全局浏览能力 | 细节保真度 | 上下文成本 | 主要问题 | |---|---|---|---|---| | 纯文本长上下文 | 较强 | 取决于解析质量 | 随文本长度线性增加 | 容易丢失版式、图表和页面关系 | | 全页面高分辨率 VLM | 强 | 高 | 页面越多成本越高 | 大文档推理压力大 | | LensVLM 选择性展开 | 强 | 相关页面高 | 主要集中在选中的页面 | 依赖页面选择是否准确 |

LensVLM 的短板也很清楚：如果第一轮压缩图像没有暴露关键线索，或者模型选错了页面，后续展开就可能建立在错误路径上。这类系统的性能上限，不仅由视觉识别能力决定，也由页面选择器的召回率决定。换句话说，它把一部分传统上下文压力转移成了检索错误风险。

对开发者意味着什么？

LensVLM 更适合被当成长文档智能体的视觉基础模型，而不是普通的图片问答模型。 它的价值不在于看一张图片回答一个问题，而在于处理多页、跨页、信息稀疏的文档任务。

对于文档问答系统，LensVLM 可以承担第一层视觉检索和第二层精读。系统先把整份 PDF 渲染为页面缩略图，让模型建立文档地图；当用户询问某个财务指标、合同义务或实验结果时，再展开相关页面，必要时把多个页面的内容放在一起比较。

对于企业知识库，它可以减少“所有页面都进入上下文”的粗放式做法。知识库不再只是把文档切成固定长度的文本块，而是保留页面级视觉单元，并允许模型根据问题动态选择页面。这对表格、流程图、产品截图和扫描件较多的知识库尤其有意义。

对于本地部署，9B 参数规模也比几十亿到数百亿参数的超大模型更容易落地。需要注意的是，实际资源消耗不只取决于参数量，还取决于页面分辨率、同时展开的页面数量、视觉编码器实现以及推理框架是否支持图像批处理。LensVLM 降低的是无关页面带来的上下文浪费，不等于所有场景都能低显存运行。

开发者还需要重点关注三个工程问题。第一是 PDF 渲染质量，低分辨率缩略图可能让细小字体和表格线索消失；第二是页面选择的召回率，不能只看最终答案是否正确，还要记录模型是否漏掉关键页；第三是工具调用循环的上限，应该限制最多展开页数和最大重试次数，避免模型在长文档里反复浏览。

Apple 为什么现在做这件事？

LensVLM 暗示 Apple 正在把视觉语言模型的竞争重点从“更大的输入窗口”推进到“更聪明的上下文管理”。 这条路线与 Apple 近年来强调的端侧计算、隐私和资源约束存在天然联系。

在设备端环境中，计算、内存和电量都比云端集群更有限。让模型把每一页文档都以最高精度处理，代价很高；先用压缩视觉上下文筛选页面，再按需读取，理论上更适合受限硬件。不过，目前公开资料主要聚焦模型方法和开源权重，并不能据此断言 LensVLM 已经集成到某个 Apple 终端产品或系统功能中。

从研究角度看，Apple 选择开源 LensVLM-9B 的意义也不小。长文档视觉理解此前经常被描述为“增加上下文窗口”问题，但 LensVLM 把它重新定义为“选择性上下文扩展”问题。这个变化可能影响后续模型设计：未来的多模态模型未必需要持续追求一次性吞下更多页面，也可以学习在不同阶段使用不同精度的视觉信息。

目前值得关注的限制

LensVLM 目前更像一套有潜力的长文档视觉理解方案，而不是已经解决所有文档问题的通用产品。 首先，页面选择准确率虽然达到 76.8%，但仍意味着部分问题可能在第一轮就选错页面。对于法律、医疗、金融等高风险任务，系统必须保留页面证据和人工复核机制。

其次，压缩图像对细节的保留具有边界。字体过小、扫描模糊、颜色对比度低或者页面中存在复杂图表时，缩略图可能只保留“这里有内容”的视觉信号，却无法暴露具体数字。模型能否通过其他页面线索判断需要展开哪一页，将直接决定最终表现。

再次，跨页关系仍然是难点。某些答案需要把目录、脚注、正文和附录放在一起理解；如果模型只展开正文页而遗漏脚注，最终结论仍可能错误。因此，页面选择不能只依赖关键词命中，还需要理解引用关系、章节层级和表格延续关系。

最后，公开资料目前没有给出足够完整的成本曲线，例如平均展开页数、不同文档长度下的视觉 token 消耗、端到端延迟以及与全页面输入方案的具体对比。对于真正准备部署的团队，这些指标可能比单一 QA 准确率更重要。

OpenAI Hub 判断

LensVLM-9B 的真正亮点不是 9B 参数，而是把长文档理解从“全部读进去”改成“先定位、再精读”。 这是一个更符合真实阅读行为的设计，也比单纯扩大上下文窗口更有工程价值。

如果你要做的是普通单页 OCR 或图片问答，LensVLM 未必是最直接的选择；如果你的任务涉及几十页以上的 PDF、扫描合同、技术手册、论文或财报，它就值得重点测试。尤其是在文档页面大多与当前问题无关时，选择性展开有机会同时改善上下文成本和模型注意力分配。

但现阶段不宜把它包装成“无限长上下文”的解决方案。LensVLM 依赖页面选择工具，工具选错就会影响后续推理；论文公开的实验数据也还不足以证明它在所有类型文档上都优于全页面视觉模型。更准确的评价是：Apple 给长文档 VLM 提供了一条可落地的新路线，9B 规模的结果已经说明这条路线不是概念演示，但距离稳定的生产级文档智能体，还需要更多关于成本、召回率、延迟和真实业务数据的验证。

对于开发者来说，最值得借鉴的不是照搬某个模型，而是它背后的上下文策略：低成本阶段负责建立全局地图，高成本阶段只处理与任务相关的局部信息。 这套思路不仅适用于 PDF，也可能延伸到网页、代码仓库、幻灯片、图像集合以及视频帧检索等更广泛的多模态场景。

参考来源

1. Apple LensVLM-9B 模型仓库（Hugging Face）：提供模型卡、权重与项目说明。
2. LensVLM 论文页面（Hugging Face Papers）：论文信息与研究摘要入口。
3. LensVLM 社区讨论（Reddit）：开源发布后的开发者讨论与使用反馈。