把文档拍成照片，比打字复述省事多了

你有没有想过一件事：为什么我们查资料的时候，宁愿翻手机相册里那张会议白板的照片，也懒得手动把上面的字全部打出来？

因为照片省时间。一张图能装下的信息量，用文字敲出来可能要花你十倍的功夫，但你的眼睛扫一眼就能抓住重点。

这篇论文讲的就是这么个朴素的道理，只不过它把这个道理用在了一个你可能从没想过的地方：让AI在给文档排序打分的时候，不去读文字，而是去"看"文档的照片。

**这篇论文来自韩国高丽大学等机构的研究团队，他们给这个方法起名叫RenderRank。**

先说说这事儿到底难在哪

咱们平时用搜索引擎、问AI问题，背后其实有一整套流程。你输入一个问题之后，系统先从海量文档里粗筛出一批可能相关的候选文档，这一步叫做检索。

检索:从大量文档中快速找出可能和你的问题相关的一批候选内容，速度快但不够精准

但检索出来的这批文档质量参差不齐，有的真相关，有的其实牛头不对马嘴。所以还得有第二道工序，把这批候选文档重新打分排序，挑出最靠谱的几个，这道工序就叫重排序。

重排序:对检索出来的候选文档逐个和问题配对打分，判断哪个文档真的能回答这个问题

问题就出在这第二道工序上。

重排序模型要对每一个候选文档都单独打一次分，如果检索出来了100个候选文档，那模型就要跑100次。每一次都要把问题的文字和文档的文字一起塞进模型里处理，文档越长，塞进去的字（专业说法叫"token"，你可以理解成模型处理文字时的最小单位，一个中文字可能会被拆成一两个token）就越多，模型算起来就越慢。

token:大语言模型处理文字时切分出的最小单位,一段话会被拆成若干个token,token数量越多,模型计算量越大,速度越慢

这就是这篇论文出发的起点。既然每个候选文档都要重新算一遍，那如果能让每个文档变得"更短"（消耗更少的token），是不是整个重排序流程就能快很多？

这里就出现了一个乍一看有点反直觉的思路：把文字渲染成图片，反而能让模型处理得更快。

你可能会问，图片不是应该比文字占用更多空间吗？我们平常发微信，一张图片的文件大小明明比一段文字大得多。但这里说的不是文件存储空间，而是模型内部处理时用的"视觉token"数量。

视觉token:图像被视觉编码器切分处理后生成的信息单元,一张图可能只需要几百个视觉token,而同样内容用文字表示可能需要更多的文本token

现代的视觉语言模型（能同时理解图片和文字的AI模型，缩写VLM）有一个特性：它会把一张图切成一个个小方块（叫做patch），每个patch变成一个视觉token，然后再把相邻的几个token合并压缩。这套流程走下来，一段密密麻麻的文字，如果排版紧凑地印在一张图上，产生的视觉token数量可能比逐字转成文本token还要少。

这就好比你要把一篇作文的内容传给朋友。你可以一个字一个字地念给他听，也可以直接拍一张作文纸的照片发过去。念的方式看起来"信息保真度高"，但耗时耗力；拍照的方式看似压缩了信息的呈现形式，实际上朋友扫一眼照片就能抓住大意，你反而省了时间。如果坚持要一字一句念完，对方等待的时间只会更长，效率上的代价是实打实的。

这就是RenderRank的核心思路：把文档渲染成图片，让视觉编码器把图片压缩成一串更短的视觉token，再让语言模型拿着这串视觉token和文字问题一起去打分。

排版这件事，讲究不小

但这里马上会冒出一个新问题：图片压缩得越狠，信息丢失得越多，模型还看得懂吗？

字体太小，模型可能认不清字形；行间距太挤，模型可能分不清哪行是哪行。这就像你把课本内容拍照发朋友那样，如果字体缩得比蚂蚁还小，对方拿到照片也只能干瞪眼，这时候图片再"省流量"也没用，因为信息压根传达不到。

研究团队为了搞清楚哪种排版方式既省token又不影响理解，专门做了一轮实验。他们用两个不同的AI模型（Gemma-4-26B和Qwen3.6-35B），在两个任务上测试：一个是问答任务（考验模型能不能从文档里精准找到答案），一个是摘要任务（考验模型能不能抓住文档整体大意）。

他们把字体从10磅试到14磅，行间距从1.0倍试到1.2倍，逐一记录效果和token消耗。结果发现，12磅字体、1.0倍行距是一个比较划算的平衡点：字体太小（比如10磅）虽然token省了，但两个模型的问答准确率都明显下滑，其中Qwen3.6模型的QASPER问答得分从48.72掉到了41.32，掉了7个多百分点；而行距拉大到1.2倍，token消耗反而增加了，效果却没有同步提升。

最终团队定下的渲染规格是：用Roboto Regular字体，12磅大小，1.0倍行距，图片宽度固定896像素，高度按内容多少动态调整，最高不超过896像素，超出一页的内容自动续到下一张图，图片按顺序排列，作为同一份候选文档的一部分喂给模型。

学打分这件事，得分两步走

搞定了排版问题，接下来更关键的是：模型怎么学会看着图片给文档打分？

这不是理所当然的事情。你把文字换成图片喂给模型，模型原本在文字上练出来的判断相关性的本事，未必能直接照搬到图片上。就像一个精通盲文的人突然要求他用眼睛去读印刷体，就算内容一模一样，他也得重新适应这套新的"读法"。

研究团队为此设计了两阶段训练法。

第一阶段叫跨模态相关性蒸馏。

蒸馏:让一个较小或较新的模型去模仿一个更强大的"老师"模型的输出结果,以此传递老师模型的能力

具体做法是这样的：先找一个已经训练得很好的纯文字重排序模型当老师（这里用的是Qwen3-Reranker-4B），让老师看着文字版的问题和文字版的文档，给出一个相关性分数。同时，让RenderRank这个"学生"模型看着同样的问题文字和渲染成图片的文档，也给出一个分数。训练的目标就是让学生打的分尽量贴近老师打的分，用的是均方误差（预测值和真实值之间差距的平方，越小说明预测越准）来衡量差距。

这一步的巧妙之处在于，它不要求学生和老师内部的特征表示完全对齐，只要求最终打出来的分数接近。这就好比教一个新手厨师做菜，你不需要他和老师傅的每一个切菜动作、颠勺力度都一模一样，你只要求他做出来的菜尝起来味道差不多。如果非要要求动作完全复刻，反而会限制学生根据自己的工具（这里是视觉输入而不是文字输入）找到最适合的路径。

第二阶段叫查询局部相关性判别。

这一步解决的是另一个问题：光是分数贴近老师还不够，重排序真正要干的活是要在一堆候选文档里，把真正相关的那个（正样本）排到前面，把不相关的（负样本）排到后面。

于是团队针对每一个问题，构造了一个候选集合：一个正确答案文档，加上几个错误干扰文档。训练时用的是一种叫InfoNCE的对比损失函数，简单说就是让模型学会：面对同一个问题，正确文档的得分要显著高于错误文档的得分，此消彼长，拉开差距。

这就像老师给学生做单选题训练，不是简单告诉学生"这道题的正确答案分数应该是多少"，而是把四个选项摆在一起，让学生学会分辨哪个才是最靠谱的那个，训练的是相对判断力，而不是绝对打分能力。如果没有这一步，模型可能会打出一堆看起来都还行、但彼此区分度很低的分数，导致排序时正确文档未必能挤到最前面。

这套训练方法用了两批数据：第一阶段用了628万条问题文档配对数据，第二阶段用了将近10万条筛选过的候选集合数据。模型的底座选用的是Qwen3-VL-Reranker-2B，训练时冻结了视觉编码器部分，只对语言解码器部分用LoRA做低秩微调（一种只调整模型一小部分参数、大幅节省训练成本的技术手段）。

效果到底怎么样

说了这么多设计思路，最终得看数据说话。

研究团队在11个BEIR基准数据集（信息检索领域常用的标准评测集合，涵盖问答、事实核查、论点检索等各种任务类型）上做了对比测试，评价指标用的是NDCG@10（一种衡量排序质量的指标，数值越高说明相关文档排得越靠前，满分是100）。

结果显示，RenderRank平均拿到了55.96分，超过了所有参数量小于40亿的文字版重排序模型，也超过了一些参数量更大的模型。

比如说，它比zerank-2-reranker（40亿参数）高出7.66%，比LightOn-rerank-PW-4B（45亿参数）高出7.26%。而RenderRank自己的参数量只有21亿，换句话说，它用更小的模型体量打出了超越更大模型的分数。

更关键的是token消耗。RenderRank平均每个问题文档对只需要290个输入token，相比其他文字版模型少了16.5%到35.5%。这意味着同样的计算资源，RenderRank能处理更多的候选文档，或者用同样数量的候选文档，跑得更快。

速度和算力的账，也得算明白

光看token数量减少还不够直观，研究团队进一步做了两方面的效率评估：一是理论上的计算量估算，二是实际跑起来测出来的处理速度。

计算量这块，他们参考了一种叫E?R-FLOPs的估算方法（FLOPs是"每秒浮点运算次数"的缩写，衡量模型计算量大小的常用单位），把模型架构（层数、隐藏层维度等）和实际输入长度都考虑进去，算出处理每一对问题文档需要多少万亿次浮点运算（TFLOPs）。

结果RenderRank平均每对只需要0.63 TFLOPs，对比bge-reranker-v2-gemma需要的1.10 TFLOPs，效率高出不少，而两者的排序效果相当。

但这里有个值得琢磨的细节：理论计算量小，不代表实际跑起来速度一定快。

研究团队专门测了实际的推理吞吐量，用的指标叫PPS（每秒处理的问题文档对数），在一块NVIDIA A6000显卡上跑的。结果发现，RenderRank平均能跑到76.83 PPS，超过了体量相近甚至更小的一些模型。比如它比参数量差不多的LAMAR-600m（67.55 PPS）还要快，尽管LAMAR-600m理论上的TFLOPs反而更低。

这说明了一件事：理论计算量和实际运行速度之间，不是简单的线性对应关系，还要看模型架构本身对硬件的适配程度、注意力机制的实现效率等等因素。这就好比两辆车纸面参数上百公里加速时间差不多，但实际路况下开起来，一辆因为变速箱调校得当反而更顺畅省油。

长文档场景，优势更明显

如果说在普通长度的文档上RenderRank表现不错，那在长文档场景下，它的优势就更突出了。

研究团队在四个长文档数据集上做了测试，包括MLDR（多语言长文档检索数据集）和三个LongEmbed系列数据集（2WikiMQA、QMSum、SummScreenFD）。这些数据集里的文档动辄几千甚至上万字，正是最考验"压缩效率"的场景。

结果RenderRank平均NDCG@10拿到88.27分，而输入token数量大约只有对比模型的一半。比如在MLDR数据集上，RenderRank只用了4198个token，其他文字版模型普遍要用8800多个token，几乎是两倍的差距。

吞吐量方面更是打出了明显优势，RenderRank平均能跑到4.51 PPS，是表现最好的文字版基线（Qwen3-Reranker-0.6B，2.66 PPS）的1.70倍。

研究团队还做了一个特别有说服力的实验：固定最大输入长度，看谁在有限长度里塞进更多有效信息。他们把所有模型的输入长度上限分别设定为2000、4000、8000个token，在同样的MLDR样本上测试。

结果RenderRank在2000 token这个最紧张的限制下就拿到了97.9分，反而超过了gte-reranker-modernbert在4000 token限制下拿到的95.8分，也超过了LightOn-rerank-PW-4B在4000 token限制下拿到的97.3分。等到RenderRank用到4000 token时，分数已经涨到99.5分，接近其他模型在8000 token限制下才能达到的水平。

这个实验的意思很直白：同样是"只给你这么多字的篇幅"，RenderRank因为用图片压缩了信息密度，能塞进去更多实质内容，所以排序表现更好。这就像同样一页A4纸的篇幅，用小四号字加单倍行距写文章，比用二号字加两倍行距写，能装下多几倍的内容，读者获取的信息量自然更充分。如果强行要求两种排版方式装下同样多的字，后者要么得多用好几页纸，要么就得砍掉大量细节。

拆开看每一块拼图起了多大作用

研究团队还做了细致的消融实验（去掉某个部分，看整体效果受到多大影响，用来验证这部分是不是真的有用），来验证两阶段训练法和渲染字体大小的实际贡献。

先看训练阶段的效果。如果完全不做任何针对性训练，直接把预训练的Qwen3-VL-Reranker-2B模型拿来看图片打分，平均分只有50.20。加上第一阶段的跨模态蒸馏训练之后，分数提升到54.86。再加上第二阶段的查询局部判别训练，最终达到55.96。

这组数字说明两件事：一是从纯预训练模型直接切换到视觉输入，效果会打折扣，说明视觉输入确实需要专门的适应训练；二是两个训练阶段各自都带来了实打实的提升，缺一不可。

再看字体大小对效果的影响。研究团队把渲染字体从10磅一路加到14磅，发现字体越大，平均输入token数量从大约236涨到370，吞吐量则从大约94 PPS降到63 PPS，但NDCG@10分数也从55.04涨到56.43。

这其实揭示了一个可以主动调节的旋钮：字体越小，信息压得越紧，速度越快，但可能损失一点精度；字体越大，信息展开得越松，精度略微提升，但速度会慢下来。团队最终选择12磅作为默认设置，是在效果和效率之间找的一个折中点，实际应用中完全可以根据自己对速度和精度的偏好去调整这个参数。

Q&A

Q1：RenderRank是什么？

A：RenderRank是韩国高丽大学团队提出的一种文档重排序方法，它把候选文档渲染成图片再交给视觉语言模型处理，用压缩后的视觉token代替传统的文本token，从而减少计算量并提升处理速度。

Q2：RenderRank相比传统文字版重排序模型有什么优势？

A：在11个BEIR基准数据集上，RenderRank平均NDCG@10达到55.96分，超过所有40亿参数以下的文字版模型，同时输入token数量减少16.5%到35.5%，在长文档任务上吞吐量最高提升到1.70倍。

Q3：RenderRank是怎么训练出来看图打分能力的？

A：训练分两阶段，第一阶段让模型模仿文字版老师模型的打分结果学会跨模态对齐，第二阶段用对比学习方法训练模型在同一问题的候选文档中把正确答案排到最前面。