Знакомство с бенчмарком ReadBench, позволяющим без труда оценить, насколько хорошо ваши любимые зрительно-языковые модели читают изображения с большими объёмами текста.
В этой статье будет рассказано о ReadBench. ReadBench — это очень простой бенчмарк, который мы разработали для оценки важного, но недооценённого аспекта мультимодального ИИ: насколько хорошо моделям удаётся, собственно, читать текст на картинках, рассуждать о нём и извлекать информацию из таких изображений, на которых много текста.
Введение
Современные зрительно-языковые модели (VLM) очень крутые, многообещающие и показывают всё более высокие результаты на самых разнообразных бенчмарках. Неудивительно, что в абсолютном большинстве этих бенчмарков делается акцент на визуальном понимании: в конце концов, это же зрительные модели.
Такое развитие VLM, в свою очередь, создало условия для появления ультрасовременных мультимодальных методов извлечения информации, в частности, ColPali или DSE. Эти методы подготовили почву для возникновения полностью визуального RAG, при котором извлекаются изображения документов, и далее эта информация передаётся напрямую в VLM — то есть, отсутствует этап извлечения текста с изображения.
При таком подходе очень важна одна деталь, которая до сих пор не тестируется большинством бенчмарков, а именно: насколько хорошо VLM в принципе читают текст? В конце концов, многие документы на 95% состоят из текста (поверьте нам).
Нам стало любопытно, поэтому мы создали ReadBench, чтобы оценить этот показатель. Бенчмарк ReadBench устроен очень просто: он берёт несколько распространённых текстовых бенчмарков, предназначенных для оценки как коротких, так и длинных контекстов, подаваемых на вход. Затем он преобразует контексты в картинки, в то же время оставляя вопросы в текстовом виде. После этого он оценивает, насколько варьируется производительность при сравнении текстовых и мультимодальных вариантов ввода. Такая конфигурация п��хожа на обычный конвейер визуального RAG.
Что у нас получилось? Оказывается, почти все VLM демонстрируют некоторое падение производительности при любых мультимодальных конфигурациях, хотя, этот эффект очень слабо выражен на коротких входных контекстах (менее 1 страницы), а некоторые модели работают значительно лучше других (просим прощения за то, что ранее проявляли неуважение к GPT-4o).
Получая на вход более длинные контексты, почти все модели демонстрируют серьёзное падение производительности. Это значит, что пока у вас не получится ничего жизнеспособного, если попробуете подать в конвейер визуального RAG контекст длиной несколько страниц.
Эти результаты согласуются с тем, что показало конкурирующее и при этом немного другое исследование, выполненное командой MixedBread: притом, что мультимодальное извлечение самого современного поколения работает хорошо, генерация на основе мультимодального ввода работает плохо, хотя, и эта часть технологии стремительно развивается.
Бенчмарк ReadBench выложен в публичный доступ и снабжён данными с HuggingFace (GPQA вам придётся выбирать самим), код выложен на GitHub, а более строгое описание эксперимента приводится на arXiv. Всё, что вам потребуется, чтобы оценить новую модель — просто добавить один метод, через который вы будете получать её прогнозы.
Немного подробнее о ReadBench
Конструирование бенчмарка
Чтобы собрать ReadBench, пойдём простым путём: выберем несколько популярных бенчмарков, предназначенных для работы только с текстом, после чего преобразуем их в скриншоты текста. Чтобы точно представить реалистичные примеры использования визуального RAG, нужно придерживаться полноценного мультимодального сценария, а не такого, который целиком ориентирован на работу с изображениями:
Все инструкции и вопросы хранятся в виде текста.
Все контексты (для QA на основе контекста) и варианты ответа (для бенчмарков с вариантами множественного выбора, без контекста) преобразуются в изображения.
Что касается датасетов, мы выбрали несколько очень популярных бенчмарков. Для кратких контекстов мы используем:
MMLU-Redux: обновлённая версия MMLU, в которой качество датасета удалось в целом повысить, отфильтровав двусмысленные или попросту неверные вопросы.
MMLU-Pro: усложнённая версия MMLU, особо сфокусированная на STEM, где на каждый вопрос предусматривается 10 вариантов ответа, а не 4.
GPQA-Diamond: очень сложный бенчмарк «аспирантского» уровня на естественнонаучную тему с вопросами на множественный выбор, где для ответов на вопросы требуется очень хорошо ориентироваться в научных темах.
Для более длинных контекстов мы использовали:
BABILong и все 10 вопросов, входящих в его состав. Первый вопрос в Babilong — это бенчмарк вида «иголка в стоге сена», где единственная задача модели — извлечь единственный факт, чёт��о сформулированный где-то в пределах контекста. Все остальные 9 вопросов уровень за уровнем добавляют в стог сена различные простые суждения, такие как счёт, связывание двух фактов и т.д.
Четыре QA-подмножества из LongBench, чтобы предоставить различные темы для оценки.
Остановившись на этих датасетах, мы прогоняли их через простой конвейер, на выходе из которого генерировались скриншоты текста. Размер скриншота (в пикселях) составлял a 92.9 PPI для стандартного формата A4. Мы выбрали значение 92.9 как очень близкое к стандартному 93 PPI, принятому в «большинстве сканеров» и дающему аккуратную ширину в 768 пикселей.
Наконец, мы выполнили несколько экспериментов и пришли к выводу, что при прореживании каждого отдельного датасета до 35 примеров на подмножество — как раз то, что нам нужно. На такой выборке все модели показывают очень высокие результаты, коррелирующие с результатами задействования всего датасета, но при этом на выполнение бенчмарка требуется гораздо меньше времени, вычислительных ресурсов, и работа обходится дешевле.
Высокое разрешение не имеет значения для генерации
Перед тем, как выполнять бенчмарк в полном размере, нам было любопытно ответить на вечный вопрос: а важно ли разрешение? Я считаю, что очень авторитетный материал на эту тему написал Лукас Бейер, опубликовавший у себя в блоге пост о ViT, позволяет предположить, что, в сущности, не влияет. Даже если человеку ваша картинка кажется размытой, но читаемой, на производительности модели эта нечёткость (практически) не должна отразиться.
На следующем рисунке показано, как мы попробовали поработать с диапазоном разных PPI на странице формата A4. Разрешение варьируется от 72ppi, типичного «пониженного» качества, где на целую страницу A4 приходится 595 x 841 пикселей (с точки зрения человека выглядит очень расплывчато) до знаменитого «сетчаточного» 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 в качестве «мгновенного снимка» чётко показывает, каковы ограничения современных моделей, перед нами открываются следующие увлекательные возможности:
Расширит процесс оценки на многоязычные контексты
Инкорпорировать дополнительные модальности, например, аудио и видео
Исследовать более глубокие и насыщенные нюансами конфигурации датасетов для дальнейшей разработки бенчмарков.
Ресурсы