Answer.AI 发布 ReadBench：揭示视觉语言模型在长文本图像阅读上的显著性能衰减

欢迎阅读这篇新的 TIL，介绍 ReadBench。ReadBench 是一个非常直观的基准测试，我们开发它是为了评估多模态 AI 中一个重要但被低估的方面：模型真正阅读、推理和从文本图像中提取信息的能力。

当前视觉语言模型（VLM）非常酷、非常有前景，并且在各种基准测试上表现越来越好。这些基准测试绝大多数都聚焦于它们的视觉理解能力，这完全合理：毕竟它们是视觉模型。

VLM 的进步反过来催生了诸如 ColPali 或 DSE 这样的最先进多模态检索方法。这些方法本身又为完全视觉 RAG 的出现铺平了道路，即检索文档图像后直接传给 VLM，无需任何文本到图像的提取步骤。

对于这种方法来说，有一件事非常重要，而大多数基准测试目前并未测试：VLM 到底能多好地阅读文本？毕竟，许多文档 95% 都是文本（相信我）。

我们对此很好奇，于是构建了 ReadBench 来评估这一点。ReadBench 是一个非常直观的基准测试：它选取几个常见的文本基准测试，涵盖短上下文和长上下文输入，将上下文转换为图像，同时将问题保留为文本，然后评估模型在文本输入和多模态输入之间的性能变化。这种设置类似于通常的视觉 RAG 流程。

结果如何？几乎所有 VLM 在所有多模态设置下都会出现一定程度的性能下降，不过在不足一页的短输入上这种下降要轻微得多，而且有些模型表现明显更好（我为之前对 GPT-4o 的不敬道歉）。

在较长的输入上，所有模型都出现了非常显著的性能下降，这意味着将多页内容传入你的视觉 RAG 流程还不是一个可行的解决方案。

这些发现与 MixedBread 团队同期且略有不同的研究相符：虽然多模态检索是最先进的，但基于多模态输入的生成还不是，尽管它正在快速进步。

ReadBench 已公开发布，数据在 HuggingFace 上（GPQA 需要你自己获取），代码在 GitHub 上，更正式的细节在 arXiv 上。要给一个新模型打分，你只需添加一个方法来获取它的预测结果，就可以开始了 :)。

ReadBench 稍详细一点

构建基准测试

为了构建 ReadBench，我们采用了一种简单的方法：挑选几个流行的纯文本基准测试，并将它们转换为文本截图。为了准确反映现实世界的视觉 RAG 用例，我们采用了真正的多模态场景，而非完全基于图像的方式：

所有指令和问题都保留为文本。
所有上下文（用于基于上下文的问答）和答案选项（用于无上下文的多选题基准测试）都转换为图像。

至于数据集，我们挑选了几个非常流行的基准。对于短上下文，我们使用：

MMLU-Redux：MMLU 的更新版本，通过过滤模糊或完全错误的问题来提高数据集的整体质量。
MMLU-Pro：MMLU 的更难版本，特别关注 STEM，每个问题有 10 个答案选项，而不是只有 4 个。
GPQA-Diamond：一个非常难的“研究生水平”科学多项选择题基准，正确回答需要对科学主题有非常高级的知识。

对于更长的上下文，我们使用了：

BABILong 及其所有 10 个组成部分问题。Babilong Q1 是一个“大海捞针”基准，模型只需检索上下文中某处明确陈述的单个事实。其他 9 个问题在草堆中添加了各种简单推理层，例如计数、将两个事实联系起来等。
LongBench 的四个 QA 子集，以提供各种评估主题

选择这些数据集后，我们通过一个简单的管道运行它们，生成文本截图，在标准化 A4 页面大小上选择 92.9 PPI 比率。我们选择 92.9 是因为它非常接近“大多数扫描仪”的 93 PPI 标准，并产生整洁的 768 像素宽度。

最后，我们进行了一些实验，发现将每个数据集下采样到每个子集 35 个示例是一个最佳点，此时所有模型分数与运行完整数据集高度相关，同时大大减少了运行基准所需的时间、计算和金钱。

高分辨率再次对生成不重要

在运行完整基准之前，我们好奇的一件事是那个老生常谈的问题：分辨率重要吗？我认为关于这个主题的权威资源，Lucas Beyer 关于 ViT 的博客文章，似乎表明它并不真正重要：即使你的图像对人类来说看起来模糊，只要它足够可读，模型性能就不应该受到强烈影响，如果有的话。

在下图中，我们决定在 A4 页面大小上尝试一系列 PPI：从 72ppi（一种常见的“较低”ppi 比率，此时完整 A4 页面为 595 x 841 像素，对人类读者来说看起来相当模糊）到 300ppi（著名的“视网膜”PPI 比率，此时 A4 页面为 2481 x 3507，看起来非常清晰）。

事实证明，对于当前的 VLM，分辨率确实影响很小：Gemini 2.0 Flash 在 72 PPI 下的表现与在 300 PPI 下几乎完全相同。这是一个有趣的发现，因为它证实了我们对“视觉”模型的许多了解，但与最近多模态检索的结果不一致，后者似乎暗示更高的分辨率会导致更好的检索质量（尽管本研究中使用的模型是后期交互模型，这可能是因为 MaxSim 的工作方式允许更细粒度的评分）。

那么，它们能读得多好？

下面，您将找到显示每个模型在每个单独基准上的表现以及基于页数（在多模态世界中，页数是上下文长度的代理）的聚合指标的表格。

完整的解读留给读者（以及 arXiv 预印本！），但有几个明确的信号：

短上下文下的性能下降似乎与任务难度有一定相关性。MMLU-Redux 比 MMLU-Pro 容易，MMLU-Pro 又比 GPQA-Diamond 容易，我们可以看到模型在从图像中提取简单答案方面整体表现相当不错，但当事情变得更难、需要更多推理时，表现就没那么好了。
总体而言，在短上下文下，大多数模型表现尚可，尽管会有一些性能下降，即使在更难的任务上也是如此。
更长的上下文输入会引发明显得多的性能下降，以至于你可能会对是否要向你的 Visual RAG 流水线传入多页内容产生犹豫。这与坊间传闻和其他人的结果一致。
GPT-4o 表现异常出色，整体性能下降相对较小，是一个明显的异类（与其中一个 Qwen2.5-VL 一样，不过后者的绝对性能显然差得多，因此不那么引人注目）。有趣的是，它在多模态输入下的 GPQA 表现似乎更好，乍一看令人惊讶，但这也与关于 GPT-4o 随时间演变的分析相符：随着它在多模态推理和编程方面变得更强，有报告称其 GPQA 性能急剧下降。可能并不是多模态版 4o 在 GPQA 上表现出色，而是文本版 4o 出于未知原因在该任务上性能严重退化。

没有“通用触发器”：所有模型都有各自独立的失败案例

最后，我们研究了模型之间的退化重叠，并测量了各模型性能不匹配集合之间的 Jaccard 相似度。呼，这说法真拗口，但其实非常简单。这是一种花哨的说法，意思是：在模型 X 中触发文本与多模态输入之间不匹配的问题中，有多大比例也会在模型 Y 中触发不匹配？

而这一结果表明，实际上重叠似乎相对较少。有趣的是，同一家族的模型（4o 系列、Gemini 系列和 Qwen2.5-VL 系列）之间似乎并没有明显更多的重叠，尽管它们很可能是在非常相似的数据上训练的。

我们还对不匹配分布感到好奇，也就是：有多少问题会在一定数量的模型中导致性能下降？：

这里有一个有趣的发现，说实话让我有些意外，那就是没有任何单一输入似乎是失败的“通用触发器”。任何给定问题最多能让 9 个被评估模型中的 7 个出错，而即便这也是一个非常小的集合：仅 0.6%！反过来，超过三分之一的问题只会让一个模型产生不匹配，另有 26% 的问题只会让两个模型产生不匹配！

实际上，这表明我们观察到的性能下降似乎由多种原因造成，并且非常具有模型特异性——似乎并不存在一种放之四海而皆准的方式来搞乱它们的阅读。

接下来怎么办？

虽然 ReadBench 清晰呈现了当前的局限性，但未来仍有令人兴奋的机会：

将评估扩展到多语言场景。
纳入音频和视频等额外模态。
为未来的基准测试探索更深入、更细致的数据集设计。