把长文档塞进AI大脑，到底该用多高的分辨率？

你有没有用手机扫描过一份几十页的合同，然后想让AI帮你读一遍找出某个关键条款？

这时候你会遇到一个很尴尬的选择：扫描分辨率调低一点，文件小、上传快，但AI可能认错字，把"不得转让"看成"不得转让"（对，就是这种细微到肉眼都得瞪大眼睛看的差别）；分辨率调高一点，字倒是看得清楚了，可整个文件变得又大又慢，AI要花更多时间和"计算力"去消化这些像素。

这其实就是这篇论文要解决的核心矛盾。它有一个学术名字，叫"视觉文本压缩"。

**视觉文本压缩**：一句话解释是把大段文字渲染成图片，再让AI用图像的方式去读，而不是逐字逐句地"吃"文字token。这样做的好处是，一张图片哪怕装下满满一页字，消耗的计算资源也可能比同等信息量的纯文字token少得多。

这篇来自中国科学院自动化研究所团队的论文，提出了一个叫FocusVTC的方法，试图打破"分辨率越高效果越好、但代价也越大"这个看似天经地义的权衡。

长文本喂给AI，为什么会变成一个"负担"

先说说这件事到底难在哪儿。

现在的大语言模型越来越多地被用来读长文档、做多文档问答、处理很长的聊天记录。听起来很美好，但背后有个越来越沉重的代价：文本越长，AI处理起来越贵。

这里说的"贵"不是虚指，是实打实的计算成本和内存占用。模型在处理长文本时要计算注意力（**注意力机制**：AI理解句子里每个词和其他词之间关联程度的核心计算方式，是Transformer模型的基础），文本越长，这个计算量增长得越快。同时还要维护一个叫KV缓存的东西。

**KV缓存**：模型在生成回答过程中，为了避免重复计算之前处理过的内容，会把中间结果存起来，这部分存储随着文本变长而线性增长，占用大量显存。

业内已经尝试过很多办法来缓解这个问题，比如扩展模型能处理的最大长度、优化注意力的计算效率、管理好缓存、或者干脆把提示词本身压缩短一点。这些方法各有各的战场，而视觉文本压缩走的是另一条路：既然文字太占地方，那就把它变成图片。

想象一下，同样一页A4纸的文字内容，如果逐字输入给AI，可能要消耗几千个token；但如果把这一整页渲染成一张图片再输入，AI处理这张图片可能只需要几百个视觉token。这就是视觉文本压缩的吸引力所在，用更少的"计算单位"装下同样多的信息。

但问题来了。之前的工作，比如Glyph和DeepSeek-OCR，都是用固定分辨率去渲染整篇文档。这就意味着，无论文档里哪部分内容重要、哪部分不重要，AI都用同一个"放大镜倍数"去看。

低分辨率省token，但字迹模糊容易认错；高分辨率字迹清楚，但哪怕是完全不相关的段落也要花掉同样多的计算资源。

这就好比你去图书馆查一本厚厚的百科全书里某一个条目。如果你被要求把整本书都用放大镜逐页细读一遍才能找到答案，那效率显然低得离谱。可如果你只是粗略翻一遍目录，很可能会把关键细节看漏。真正聪明的做法是什么？先快速翻页找到大概位置，然后只在那一页凑近了细看。

这正是FocusVTC这篇论文的核心洞察：全局的覆盖面和局部的精确阅读，其实不需要用同一个分辨率去完成。一个问题往往只依赖文档里很小一部分内容，没必要把整篇都放大。

FocusVTC怎么做到"该粗则粗、该细则细"

FocusVTC的整体思路是，先用低分辨率快速浏览整份文档，建立一个大致的全局印象，然后在推理过程中，如果发现某个区域跟当前问题密切相关，就主动申请把这个区域"放大"看清楚。

这套机制听起来简单，但实现起来涉及两个训练阶段，我们一步步拆开看。

### 第一步：教会AI"哪里重要"——REL-SFT

要让AI学会"该往哪看"，首先得有数据教它。研究团队构建了一个包含29.4万条高质量样本的数据集，叫REL-CoT。

**REL-CoT**：全称是Reasoning-Evidence Localization Chain-of-Thought，意思是"推理-证据定位思维链"，每一条数据都把AI的推理过程和具体的页码、区域坐标绑定在一起，相当于给每一步思考都标注了"我是从文档哪个位置得出这个结论的"。

这个数据集不是随便攒出来的，构建过程用了三个不同的AI模型交叉把关。先用DeepSeek V4 Flash过滤掉那些靠常识就能答对、不需要真的去读文档的问题，避免AI偷懒走捷径。然后用Gemini 3.5 Flash生成带有页码和边界框标注的推理过程，边界框就是图片上圈出关键内容位置的那个矩形框，坐标被归一化到0到1000这个区间。最后用GPT-5 mini独立核查这些圈出来的区域是不是真的能支持答案，不合格的样本直接剔除。

三层过滤下来，才留下了这2.94万条可信的样本。这个过程有点像出版社审稿，一个人写初稿，另一个人负责标注引用来源，第三个人专门核实引用是否属实，一篇稿子经过三道关才能定稿。如果只让一个模型既写又标又审，很容易自说自话，把错误的推理包装成看似合理的样子，这在AI训练数据构建里是个真实存在的风险。

有了这批数据，研究团队进行了**REL-SFT**：全称是Reasoning-Evidence Localization Supervised Fine-Tuning，中文可以理解为"推理证据定位监督微调"，这一步专门训练模型学会在不同分辨率下都能准确定位到证据所在的区域。

值得一提的细节是，同一份文档会被渲染成七种不同的DPI（48、60、72、84、96、120、144），分辨率越高数字越大，让模型见过各种清晰度下的同一份内容，这样它才能学会"不管画面模糊还是清晰，我都知道该往哪儿看"。

在正式训练之前，团队还做了一件很细致的事：字体选择。

他们测试了15种字体、8种字号，用随机文本测量字符错误率。最终选定了DejaVu Sans字体，9磅字号。这个选择不是拍脑袋定的：在满足5%字符错误率标准的字体里，DejaVu Sans消耗的视觉token最少，每3.2万字的文本只需要8368.4个视觉token，比第二名Verdana的8417.8还省一点点。更关键的是，在"cl"、"rn"、"i"这类容易看错的字符组合上，DejaVu Sans的错误率比Verdana低了0.3个百分点。

别小看这0.3个百分点。论文里给了一个具体案例：在需要精确匹配UUID（一串很长的十六进制字符串）的任务里，哪怕认错一个字符，整个答案就作废了。换字体这件事看似只是排版细节，实际上直接影响到下游任务能不能答对，这也是这篇论文愿意花大篇幅做字体对比实验的原因。

### 第二步：教会AI"何时放大、放大多少"——GRPO强化学习

REL-SFT教会了模型定位，但只是"知道"哪里重要还不够，模型还得学会主动决策：什么时候该申请放大看看，放大之后又该怎么把新看到的信息用进推理里，什么时候该停下来给出答案。

这一步用的是**GRPO**：全称Group Relative Policy Optimization，即分组相对策略优化，是一种强化学习算法，通过让模型对同一个问题生成多条不同的回答路径，然后互相比较打分来学习。

具体是这样运作的：给定一个初始状态，模型会生成8条不同的推理轨迹，每条轨迹里模型可能会调用一个叫Enhance_Region的工具，也就是"放大某个区域"的操作。系统会根据这8条轨迹各自的表现打分，然后用相对比较的方式更新模型的决策倾向，表现好的轨迹对应的行为会被强化。

这里有一个巧妙的奖励设计。奖励分成三部分：答案对不对、格式对不对、以及是否恰当地使用了放大工具。有意思的是，工具使用的奖励只有在答案完全正确的前提下才会生效，这是为了避免模型学会一种投机取巧的策略,就是不管三七二十一先疯狂调用放大工具，反正调用本身就能拿分。

工具奖励里还细分了三个维度：初始分辨率的必要性、定位准确度、调用效率。分辨率越低，说明当前画面越模糊，越应该鼓励放大操作,这个权重函数在72DPI时是满分1，到144DPI时直接归零。因为高分辨率下本来就看得清，没必要再多此一举去申请放大。定位准确度看的是模型申请放大的区域和真实证据区域的重合程度，重合度用IoU（**IoU**：全称Intersection over Union，交并比，衡量两个区域重叠程度的常用指标，值域从0到1，越接近1说明两个区域重合得越好）来衡量。调用效率则惩罚那种啰嗦式的重复申请,如果证据只需要看3个区域,你却申请了10次,效率分就会大打折扣。

这套奖励设计其实很像公司考核销售的提成规则。光签单不算数，得客户真的付款了才有提成，这样才不会有人钻空子刷假单。而且签一个大单和签十个小单拿的提成不能一样,得看转化效率。如果没有这套精细的规则,业务员很可能会为了冲数量而放弃质量,这正是论文里担心的"模型学会滥用工具却答不对题"的陷阱。

数据构建阶段还有一个筛选细节：如果8条轨迹全部反复调用工具却始终答不出来，或者8条轨迹压根都没调用过工具，这些样本会被直接丢弃，因为它们没法提供有效的学习信号。最终保留了1万条提示，按照7:2:1的比例分配给72、96、144三种DPI。

这套系统跑起来效果怎么样

说了这么多设计思路，最终还是要看数字说话。

在RULER v1这个长上下文基准测试上，FocusVTC在72DPI下拿到了87.4分，同时输入压缩比达到2.9倍（包括工具调用产生的额外观察内容）。作为对比，Glyph在3.0倍压缩比下只拿到了57.5分。差不多相当的压缩程度下，FocusVTC的分数几乎是对方的1.5倍。

这个对比值得多说两句。RULER基准测试专门用来检验模型在长文本里精确检索信息的能力，很多"藏针"式的任务，也就是在大段无关文字里藏一两条关键信息，考验模型能不能准确找出来。固定分辨率的方法在这类任务上表现挣扎并不奇怪，因为它没法针对性地"放大"关键区域,要么模糊得看不清针在哪，要么为了看清楚不得不把整篇都放大，浪费大量token。

再看LongBench这个长文本理解基准，FocusVTC拿到56.40分，反超了它自己的纯文本版本骨干模型Qwen3.5-9B的55.86分，也超过了同类视觉压缩方法Glyph的52.34分。这个结果有点出乎意料，因为按理说，图片压缩多少会损失一些信息，视觉输入的模型很难反超纯文字输入的同一个模型。但FocusVTC做到了,这说明选择性放大带来的收益，已经能够弥补甚至超过压缩本身带来的损失。

在MRCR这个多针检索测试上，FocusVTC的宏观平均分从31.65提升到45.56，涨了13.91个百分点。VTCBench测试里，FocusVTC也拿到了51.19的宏观平均分，在检索和记忆两个维度上都排名第一。

速度方面同样有惊喜。研究团队在64K到128K长度的四针MRCR样本上做了端到端延迟测试，FocusVTC比纯文本版本快了2.79倍，平均延迟从187秒降到67秒。这背后的原因也不难理解：纯文本模型要处理更长的输入序列、生成更多的token（平均5411个 vs FocusVTC的1530个），而FocusVTC因为输入被压缩，加上生成内容更简洁，跑起来自然快很多。

更重要的是，这些提升并没有以牺牲通用能力为代价。在OCRBench、DocVQA、MMMU、MME、ChartQA、InfoVQA这六个通用多模态基准上，FocusVTC全面持平或超越骨干模型，MMMU从65.12提升到66.73，MME从2424.02涨到2457.62。这说明加入这套自适应阅读机制，并没有让模型在其他任务上"变笨"。

各个组件到底谁在起作用

一个方法效果好，光看总分还不够，得拆开来看每个零件贡献了多少。论文做了一系列消融实验，挺有意思。

如果去掉GRPO这一步，只留REL-SFT，RULER v1的分数会从87.38暴跌到32.28。更极端的是，如果给一个完全没经过训练、只是简单赋予工具调用能力的原始模型（Qwen3.5-9B+tools），它的表现甚至比不用工具还要差,LongBench分数从37.86掉到25.41。

这个结果特别耐人寻味。它说明单纯给AI一个"放大镜"工具，并不会自动让它变聪明，反而可能因为不会用而帮倒忙,就像给一个从没开过车的人一辆跑车，未必比走路快，搞不好还会出事故。真正让FocusVTC变强的，是GRPO这个阶段学会的"什么时候该拿起放大镜、往哪儿对焦"的判断力。

训练过程的动态变化也很说明问题。论文把GRPO训练分成了四个阶段。前期（0到36步），模型的工具调用次数和响应长度都在增加，定位准确度（IoU）也随之上升,这是探索阶段，模型在摸索怎么用好这个工具。中期（36到60步）出现一个有意思的现象：调用次数下降了，但响应长度还维持在高位，IoU甚至短暂下滑,这说明"少调用"本身不等于"读得准"，模型这时候可能是在学习取舍，但还没完全学明白。到了后期（60到150步），响应变短，IoU持续上升并趋于稳定，各项基准分数也在这个阶段达到最优。

这个训练轨迹给人的感觉，很像一个新手学开车。刚开始什么都想试试，方向盘打得又多又勤，车速也不稳。中间阶段开始学会少打方向盘，但因为还没找准感觉，反而开得更磕磕绊绊。到了后期，动作变得干净利落，油门刹车都恰到好处，这时候才算真正学会了。

字体选择的实验也印证了前面提到的结论。用DejaVu Sans渲染的FocusVTC在RULER两个版本和LongBench上都优于用Verdana渲染的版本，差距最大的地方出现在需要精确检索键值对的任务上，这再次说明看似微小的渲染细节，会在需要"较真"的任务里被放大成实打实的分数差距。

起始分辨率该怎么选,72DPI是个甜蜜点

论文还专门做了一组实验，测试从48DPI到144DPI，不同起始分辨率下FocusVTC的表现和token消耗。

结果发现一个很清晰的规律：FocusVTC对起始分辨率的敏感度远低于固定分辨率的基线方法。在72DPI时，模型已经能达到87.38（RULER v1）和75.94（RULER v2）的高分，而且此时的总token消耗，也就是提示词加上工具观察内容的总和，是所有测试分辨率里最小的。

低于72DPI，比如48或60DPI，画面太模糊，模型不得不申请更多的放大观察，反而抵消了低分辨率本该省下来的token。高于72DPI，虽然额外观察的token消耗变化不大，但提示词本身的长度会显著增长,从144DPI起步，输入token数量是72DPI的2.6到2.8倍，但分数提升却很有限。

这个发现其实揭示了一个反直觉的结论：并不是分辨率越高，最终效果越好、越省钱。72DPI给了模型刚好够用的信息量去做出正确的放大决策，再往上加分辨率，只是在给那些根本不需要放大看的内容也一并加大，纯属浪费。这跟我们直觉里"清晰度越高越好"是相悖的，但数据说得很清楚。

写在后面

读完这篇论文，最让我意外的一点是，工具本身并不会自动带来收益，这件事被实验数据证明得特别扎实。Qwen3.5-9B加上工具调用能力后,分数反而比不加工具还低。这提醒我们一个容易被忽略的事实：给AI增加能力，如果没有配套训练它怎么恰当使用这个能力，很可能是负资产而不是正资产。这不只是一个技术细节,它某种程度上映射出一个更普遍的现象,能力和智慧从来不是一回事。

另一个让我反复琢磨的细节是那个字体选择实验。研究团队为了0.3个百分点的字符错误率差异，专门测了15种字体、8种字号，还做了置信区间检验。这种较真程度，在很多人看来可能是"过度优化"，但正是这种毫厘之间的把控，最终转化成了下游任务里实打实的分数差距。技术研究里往往就是这样，那些看起来无关紧要的边角细节，累积起来可能就是决定成败的关键。

论文里也坦承了局限：目前FocusVTC只在90亿参数规模的模型和不到3万条训练样本上验证过，更大规模的模型和更多样化的文档类型（比如不同语言、复杂排版）能不能延续这个效果，还是未知数。这倒是给后续研究留了一个挺具体的追问方向：当放大镜的使用策略需要应对的文档变得更复杂、更多语言混杂的时候，现在这套基于边界框的定位方式还够用吗？

Q&A

Q1：FocusVTC是什么？

A：FocusVTC是中科院自动化所团队提出的一种视觉文本压缩方法，核心思路是先用低分辨率快速浏览整份文档，再对关键区域主动申请高分辨率放大查看，从而在节省计算资源的同时保持较高的准确率。

Q2：FocusVTC和之前的Glyph方法相比有什么优势？

A：在RULER v1测试中，FocusVTC在2.9倍压缩比下拿到87.4分，而Glyph在3.0倍压缩比下只有57.5分，压缩比相近但准确率明显更高，同时FocusVTC在延迟上比纯文本模型快2.79倍。

Q3：FocusVTC训练用了多少数据，效果依赖什么关键设计？

A：FocusVTC用了2.94万条REL-CoT标注数据，通过REL-SFT和GRPO两阶段训练。实验显示，只给模型工具而不做GRPO训练，分数反而会下降，说明策略学习是效果的关键，并非简单加个工具就能提升表现。