Зрительно-языковые модели читают хуже (или лучше), чем вам кажется

Знакомство с бенчмарком ReadBench, позволяющим без труда оценить, насколько хорошо ваши любимые зрительно-языковые модели читают изображения с большими объёмами текста.

В этой статье будет рассказано о ReadBench. ReadBench — это очень простой бенчмарк, который мы разработали для оценки важного, но недооценённого аспекта мультимодального ИИ: насколько хорошо моделям удаётся, собственно, читать текст на картинках, рассуждать о нём и извлекать информацию из таких изображений, на которых много текста.

Введение

Современные зрительно-языковые модели (VLM) очень крутые, многообещающие и показывают всё более высокие результаты на самых разнообразных бенчмарках. Неудивительно, что в абсолютном большинстве этих бенчмарков делается акцент на визуальном понимании: в конце концов, это же зрительные модели.

Такое развитие VLM, в свою очередь, создало условия для появления ультрасовременных мультимодальных методов извлечения информации, в частности, ColPali ^[1] или DSE ^[2]. Эти методы подготовили почву для возникновения полностью визуального RAG ^[3], при котором извлекаются изображения документов, и далее эта информация передаётся напрямую в VLM — то есть, отсутствует этап извлечения текста с изображения.

При таком подходе очень важна одна деталь, которая до сих пор не тестируется большинством бенчмарков, а именно: насколько хорошо VLM в принципе читают текст? В конце концов, многие документы на 95% состоят из текста (поверьте нам).

Нам стало любопытно, поэтому мы создали ReadBench, чтобы оценить этот показатель. Бенчмарк ReadBench устроен очень просто: он берёт несколько распространённых текстовых бенчмарков, предназначенных для оценки как коротких, так и длинных контекстов, подаваемых на вход. Затем он преобразует контексты в картинки, в то же время оставляя вопросы в текстовом виде. После этого он оценивает, насколько варьируется производительность при сравнении текстовых и мультимодальных вариантов ввода. Такая конфигурация похожа на обычный конвейер визуального RAG.

Что у нас получилось? Оказывается, почти все VLM демонстрируют некоторое падение производительности при любых мультимодальных конфигурациях, хотя, этот эффект очень слабо выражен на коротких входных контекстах (менее 1 страницы), а некоторые модели работают значительно лучше других (просим прощения за то, что ранее проявляли неуважение к GPT-4o).

Получая на вход более длинные контексты, почти все модели демонстрируют серьёзное падение производительности. Это значит, что пока у вас не получится ничего жизнеспособного, если попробуете подать в конвейер визуального RAG контекст длиной несколько страниц.

Эти результаты согласуются с тем, что показало конкурирующее и при этом немного другое исследование ^[4], выполненное командой MixedBread: притом, что мультимодальное извлечение самого современного поколения работает хорошо, генерация на основе мультимодального ввода работает плохо, хотя, и эта часть технологии стремительно развивается.

Бенчмарк ReadBench выложен в публичный доступ и снабжён данными с HuggingFace ^[5] (GPQA вам придётся выбирать самим), код выложен на GitHub, а более строгое описание эксперимента приводится на arXiv. Всё, что вам потребуется, чтобы оценить новую модель — просто добавить один метод, через который вы будете получать её прогнозы.

Немного подробнее о ReadBench

Конструирование бенчмарка

Чтобы собрать ReadBench, пойдём простым путём: выберем несколько популярных бенчмарков, предназначенных для работы только с текстом, после чего преобразуем их в скриншоты текста. Чтобы точно представить реалистичные примеры использования визуального RAG, нужно придерживаться полноценного мультимодального сценария, а не такого, который целиком ориентирован на работу с изображениями:

• Все инструкции и вопросы хранятся в виде текста.

• Все контексты (для QA на основе контекста) и варианты ответа (для бенчмарков с вариантами множественного выбора, без контекста) преобразуются в изображения.

Что касается датасетов, мы выбрали несколько очень популярных бенчмарков. Для кратких контекстов мы используем:

• MMLU-Redux ^[6]: обновлённая версия MMLU, в которой качество датасета удалось в целом повысить, отфильтровав двусмысленные или попросту неверные вопросы.

• MMLU-Pro ^[7]: усложнённая версия MMLU, особо сфокусированная на STEM, где на каждый вопрос предусматривается 10 вариантов ответа, а не 4.

• GPQA-Diamond ^[8]: очень сложный бенчмарк «аспирантского» уровня на естественнонаучную тему с вопросами на множественный выбор, где для ответов на вопросы требуется очень хорошо ориентироваться в научных темах.

Для более длинных контекстов мы использовали:

• BABILong ^[9] и все 10 вопросов, входящих в его состав. Первый вопрос в Babilong — это бенчмарк вида «иголка в стоге сена», где единственная задача модели — извлечь единственный факт, чётко сформулированный где-то в пределах контекста. Все остальные 9 вопросов уровень за уровнем добавляют в стог сена различные простые суждения, такие как счёт, связывание двух фактов и т.д.

• Четыре QA-подмножества из LongBench ^[10], чтобы предоставить различные темы для оценки.

Остановившись на этих датасетах, мы прогоняли их через простой конвейер, на выходе из которого генерировались скриншоты текста. Размер скриншота (в пикселях) составлял a 92.9 PPI для стандартного формата A4. Мы выбрали значение 92.9 как очень близкое к стандартному 93 PPI, принятому в «большинстве сканеров» и дающему аккуратную ширину в 768 пикселей.

Наконец, мы выполнили несколько экспериментов и пришли к выводу, что при прореживании каждого отдельного датасета до 35 примеров на подмножество — как раз то, что нам нужно. На такой выборке все модели показывают очень высокие результаты, коррелирующие с результатами задействования всего датасета, но при этом на выполнение бенчмарка требуется гораздо меньше времени, вычислительных ресурсов, и работа обходится дешевле.

Высокое разрешение не имеет значения для генерации

Перед тем, как выполнять бенчмарк в полном размере, нам было любопытно ответить на вечный вопрос: а важно ли разрешение? Я считаю, что очень авторитетный материал на эту тему написал Лукас Бейер, опубликовавший у себя в блоге пост о ViT ^[11], позволяет предположить, что, в сущности, не влияет. Даже если человеку ваша картинка кажется размытой, но читаемой, на производительности модели эта нечёткость (практически) не должна отразиться.

На следующем рисунке показано, как мы попробовали поработать с диапазоном разных PPI на странице формата A4. Разрешение варьируется от 72ppi, типичного «пониженного» качества, где на целую страницу A4 приходится 595 x 841 пикселей (с точки зрения ^[12] человека выглядит очень расплывчато) до знаменитого «сетчаточного» PPI, где на страницу A4 приходится 2481 x 3507 пикселей, и она выглядит кристально чисто.

Оказывается, для современных зрительно-языковых моделей разрешение значит очень немного: Gemini 2.0 Flash работает примерно с равным успехом и при 72 PPI, и при 300 PPI. Это интересный вывод, так как подтверждает многое, что нам известно о «зрительных» моделях, но не согласуется с последними результатами, достигнутыми в мультимодальном извлечении данных. Это позволяет предположить, что чем выше разрешение, тем выше должно быть качество извлечения (хотя, в этом исследовании применялась модель позднего взаимодействия, но дело может быть и в том, что она обеспечивает более детализированное начисление баллов — так работает MaxSim).

Итак, насколько же хорошо они читают?

В следующей таблице показано, какие результаты каждая модель показала по каждому из бенчмарков. В частности, учтены совокупные метрики, основанные на количестве страниц (количество страниц в мультимодальных контекстах — это показатель, опосредованно соответствующий длине контекста).

Полную интерпретацию оставим сделать читателям (также посмотрите препринт на arXiv!), но здесь есть несколько чётких сигналов:

• По-видимому, снижение производительности на коротких контекстах как-то коррелирует со сложностью задачи. MMLU-Redux проще, чем MMLU-Pro, которая, в свою очередь, проще, чем GPQA-Diamond. Как видим, модели вполне достойно справляются с задачами во всём спектре, легко извлекают с картинок простые ответы, но не так успешно работают при переходе к более сложным темам, которые требуют более тщательно рассуждать.

• В целом, на коротких контекстах большинство моделей работают хорошо, хотя их производительность снижается тем сильнее, чем сложнее задача.

• При подаче на вход более длительного контекста производительность падает значительно заметнее, до такой степени, что вы можете лишний раз задуматься, а стоит ли добавлять много страниц в ваш конвейер визуального RAG. Это согласуется с информацией, поступающей по сарафанному радио, а также с результатами, которые были получены другими людьми.

• GPT-4o работает исключительно хорошо и почти не демонстрирует деградации во всём спектре, поэтому является явным выбросом в общем распределении (то же касается моделей на основе Qwen2.5, хотя, её абсолютная производительность определённо гораздо хуже, поэтому не будем на ней останавливаться). Интересно, что более высокая производительность достигается с GPQA, когда на вход поступают мультимодальные данные. На первый взгляд это кажется удивительным, но согласуется с анализом развития GPT-4o с течением времени: по мере того, как модель совершенствовалась в мультиодальных рассуждениях и программировании, отмечалось, что её производительность при работе с GPQA резко падает. Возможно, дело не в том, что мультимодальная версия 4o особенно успешна на GPQA, а в том, что по каким-то неизвестным причинам текстовая версия 4o очень теряет в производительности.

• По-видимому, снижение производительности на коротких контекстах как-то коррелирует со сложностью задачи. MMLU-Redux проще, чем MMLU-Pro, которая, в свою очередь, проще, чем GPQA-Diamond. Как видим, модели вполне достойно справляются с задачами во всём спектре, легко извлекают с картинок простые ответы, но не так успешно работают при переходе к более сложным темам, которые требуют более тщательно рассуждать.

• В целом, на коротких контекстах большинство моделей работают хорошо, хотя их производительность снижается тем сильнее, чем сложнее задача.

• При подаче на вход более длительного контекста производительность падает значительно заметнее, до такой степени, что вы можете лишний раз задуматься, а стоит ли добавлять много страниц в ваш конвейер визуального RAG. Это согласуется с информацией, поступающей по сарафанному радио, а также с результатами, которые были получены другими людьми.

• GPT-4o работает исключительно хорошо и почти не демонстрирует деградации во всём спектре, поэтому является явным выбросом в общем распределении (то же касается моделей на основе Qwen2.5, хотя, её абсолютная производительность определённо гораздо хуже, поэтому не будем на ней останавливаться). Интересно, что более высокая производительность достигается с GPQA, когда на вход поступают мультимодальные данные. На первый взгляд это кажется удивительным, но согласуется с анализом развития GPT-4o с течением времени: по мере того, как модель совершенствовалась в мультиодальных рассуждениях и программировании, отмечалось, что её производительность при работе с GPQA резко падает. Возможно, дело не в том, что мультимодальная версия 4o особенно успешна на GPQA, а в том, что по каким-то неизвестным причинам текстовая версия 4o очень теряет в производительности.

«Универсального триггера» нет: для всех моделей характерны свои случаи отказа

Наконец, мы рассмотрели, насколько пересекается деградация от модели к модели и измерили коэффициент Жаккара между наборами функциональных несоответствий от модели к модели. Так изощрённо мы пытаемся сказать следующее: каков процент вопросов, провоцирующих несоответствие между текстовыми и мультимодальными вариантами кода в модели X, такой, который также спровоцирует несоответствие и в модели Y?

Нам это показывает, что, по-видимому, таких пересечений совсем мало. Интересно, что модели, относящиеся к одному семейству (4os, Gemini, Qwen2.5) по-видимому, пересекаются друг с другом значительно сильнее, несмотря на то, что с высокой вероятностью они обучались на очень похожих данных.

Также нам было любопытно проверить распределение несоответствий, то есть, сколько вопросов вызывают снижение производительности в определённом количестве моделей?:

Здесь есть особенно интересная находка, которая нас несколько удивила: по-видимому, никакой конкретный вариант входной информации не является «универсальным триггером» отказов. Наибольшее количество моделей, «оступавшихся» на конкретном вопросе — 7 из 9 исследованных, и даже это очень небольшая выборка вопросов: всего 0,6%! Верно и обратное: более трети вопросов провоцируют несоответствие для одной модели каждый, причём, ещё 26% сказываются так всего на двух моделях!

На практике это нам показывает, что наблюдаемые случаи снижения производительности вызваны самыми разными причинами, и многие из этих причин очень специфичны для конкретных моделей. Нет такого фактора, который в любых ситуациях мешает им «читать».

Что дальше?

Поскольку ReadBench в качестве «мгновенного снимка» чётко показывает, каковы ограничения современных моделей, перед нами открываются следующие увлекательные возможности:

• Расширит процесс оценки на многоязычные контексты

• Инкорпорировать дополнительные модальности, например, аудио и видео

• Исследовать более глубокие и насыщенные нюансами конфигурации датасетов для дальнейшей разработки бенчмарков.

Ресурсы

• arXiv ^[13]

• hf ^[5]

• github ^[14]