NeoMME: мультимодальный энкодер почти сравнялся с ColQwen2.5 в поиске по документам, используя примерно в 14 раз меньше параметров

NeoMME: мультимодальный энкодер почти сравнялся с ColQwen2.5 в поиске по документам, используя примерно в 14 раз меньше параметров

NeoMME (произносится «нео-ми», IPA /ˈniː.oʊ.mi/), новое семейство мультимодальных энкодеров на 260 миллионов и 800 миллионов параметров, представленное в блоге на Hugging Face. В отличие от многих генеративных визуально-языковых моделей, NeoMME не использует ни отдельную предобученную «башню» для зрения, ни каузальную языковую модель: единый двунаправленный трансформер обрабатывает и текстовые токены, и необработанные патчи изображения, а вся модель обучена с нуля по методу маскированной дискретной диффузии (masked discrete diffusion). NeoMME дообучен в отдельную модель, NeoMME-Retriever, для визуального поиска по документам методом ColPali: за один проход вперёд она возвращает и плотные (dense), и поздние (late-interaction) эмбеддинги. Все чекпоинты опубликованы под лицензией Apache 2.0 и уже доступны в библиотеке Hugging Face Transformers.

Авторы объясняют, зачем нужен ещё один мультимодальный энкодер. Многие современные ретриверы для визуального поиска по документам собраны из уже предобученных генеративных визуально-языковых моделей: отдельный визуальный энкодер извлекает признаки изображения, проектор переносит их в пространство языковой модели, а дальше всё обрабатывает каузальный декодер. Но задачи поиска, классификации и разметки токенов не генерируют текст авторегрессивно, а значит, им не нужен ни каузальный декодер, ни связанные с ним лишние параметры и вычисления. ModernBERT принёс архитектурные и обучающие улучшения в двунаправленные энкодеры; ModernVBERT применил такой ModernBERT-подобный текстовый энкодер к визуальному поиску по документам, но всё ещё опирался на отдельную предобученную визуальную «башню» SigLIP2. Авторы NeoMME пошли дальше и обучили мультимодальный энкодер, вовсе не унаследовавший параметры и вычислительные затраты визуально-языковой модели.

Обе версии, 260M и 800M, используют одну архитектуру. Текст подаётся факторизованными токен-эмбеддингами, а изображение делится на сетку неперекрывающихся патчей 32×32, которые проецируются небольшим MLP-слоем; и текст, и изображение поступают в один и тот же трансформер. Разрешение изображений динамическое, модель сохраняет исходные пропорции и размер, выделяя больше токенов на насыщенную деталями страницу документа и меньше, на более простое изображение. Длина контекста, 16 384 токена, этого хватает максимум на два стандартных изображения формата 4K UHD (3840×2160). Большинство слоёв используют симметричное скользящее окно внимания, а каждый шестой слой и последний слой, глобальное внимание. Из современных архитектурных приёмов применены группированное внимание (grouped-query attention), нормализация запросов и ключей (query-key normalization), управляемое внимание (gated attention), двумерные вращающиеся позиционные эмбеддинги (2D RoPE) и MLP-слои с squared-ReLU. Токенизатор BPE обучен с нуля на многоязычных текстах, коде, математике и машинных транскриптах изображений; его словарь, 131 тысяча токенов.

NeoMME обучен с нуля как модель, восстанавливающая замаскированный текст, по методу дискретной маскированной диффузии. Для чисто текстовых примеров доля маскируемых токенов на каждый пример выбирается случайно и равномерно в диапазоне от 0 до 1, и каждый подходящий токен маскируется независимо с этой вероятностью. Для мультимодальных примеров (изображение плюс текст) доля маскирования, от 0,3 до 1, при этом патчи изображения остаются видимыми, пока модель восстанавливает скрытый текст. При слабом маскировании модель часто угадывает пропущенное слово по одному лишь окружающему тексту, например, «кот» правдоподобно продолжает фразу «[MASK] сидел на коврике» даже без изображения. А при сильном маскировании модели приходится опираться на описания, привязанные к изображению, почти без сигнала от немаскированных токенов текста. В обучающую выборку входят многоязычные тексты, код, математика, натуральные изображения и изображения документов. Каждая модель обрабатывает около 524 миллиардов упакованных токенов, из них 290 миллиардов, из чисто текстовых примеров; это заметно меньше 2 триллионов токенов, на которых обучался ModernBERT, поэтому авторы выбрали оптимизатор NorMuon для повышения эффективности использования данных.

NeoMME-Retriever дообучен для визуального поиска по документам по методике ColPali: вместо того чтобы извлекать текст из PDF через OCR и искать по текстовым фрагментам, модель напрямую ранжирует скриншоты страниц документов, сохраняя вёрстку, диаграммы, таблицы, шрифт и другие визуальные подсказки, которые не улавливает даже идеальный OCR. У модели два независимо обученных выхода: dense-выход усредняет скрытые состояния трансформера в один нормализованный вектор (mean pooling), компактный и хорошо работающий с приближённым поиском ближайших соседей (ANN); late-interaction-выход проецирует каждый текстовый токен или патч изображения в отдельный нормализованный 128-мерный вектор, более тонкая детализация сохраняет локальные совпадения между отдельными токенами запроса и участками изображения. Омар Хаттаб, представивший late-interaction в модели ColBERT, поясняет в посте, что этот термин точнее «multi-vector»: он описывает детализацию и обучаемость самой функции скоринга, а не просто число хранимых векторов; там же дана ссылка на отдельный разбор late-interaction, написанный Амели Шатлен. Один проход NeoMME-Retriever вперёд сразу возвращает оба представления; авторы советуют по умолчанию использовать late-interaction, он мощнее и совместим с открытой библиотекой NextPlaid, а для очень больших корпусов документов предлагают сначала отобрать небольшой набор кандидатов через dense-эмбеддинги и ANN-индекс, а затем переранжировать его с помощью late-interaction.

На бенчмарке ViDoRe v3 (метрика nDCG@10) NeoMME-Retriever-260M набирает 0,523, лучший результат среди всех оценённых моделей строго младше 800M параметров, всего на 0,002 nDCG@10 отличаясь от ColQwen2.5, которая использует примерно в 14 раз больше параметров. NeoMME-Retriever-800M набирает 0,556, в пределах 0,009 nDCG@10 от сопоставимой по размеру модели Vultron Retriever Flash (0.8B). Обе модели NeoMME-Retriever лежат на границе Парето по соотношению размера модели и качества поиска. На более старых бенчмарках ViDoRe v1 и v2 (метрика nDCG@5) NeoMME-Retriever-260M превосходит ColModernVBERT и вдвое более крупную ColSmol-500M, а NeoMME-Retriever-800M превосходит ColPali v1.3, используя в 3,6 раза меньше параметров.

Хранение late-interaction-индекса растёт линейно с числом векторов в эмбеддинге, а более высокое разрешение страницы даёт больше патчей и, соответственно, больший эмбеддинг: страница 2048×2048 даёт эмбеддинг из 4 200 векторов, то есть около 2,1 МБ в формате float32, а в среднем по бенчмарку ViDoRe v3, около 1,5 МБ на документ. Чтобы это сократить, авторы совмещают два приёма: иерархический пулинг токенов (похожие векторы одного эмбеддинга группируются в кластеры и заменяются их средним) и асимметричное квантование (эмбеддинги документов переводятся в int8 или бинарный формат, а эмбеддинги запросов, которые не хранятся, а считаются на лету, остаются в более высокой точности). С коэффициентом пулинга 10 и int8-квантованием и запросов, и документов хранение падает с 1,5 МБ до 39 КБ на страницу (уменьшение в 39 раз) при сохранении более 99% исходного nDCG@10. Более агрессивная настройка, коэффициент пулинга 8, int8 для запросов и бинарное квантование для документов, даёт 6 КБ на страницу (уменьшение в 255 раз) при сохранении более 95% исходного качества поиска.

Авторы также замерили скорость кодирования изображений у NeoMME-Retriever в сравнении с другими мультимодальными ретриверами документов, используя заранее подготовленные тензоры изображений и подобранный для каждой модели размер батча. При одинаковом входном разрешении 2048×2048 на одном GPU NVIDIA L40S модель NeoMME-Retriever-260M кодирует около 51 страницы в секунду, почти вдвое быстрее ColModernVBERT (26 страниц в секунду). На изображениях меньшего размера обе версии NeoMME-Retriever, и 260M, и 800M, тоже быстрее остальных сравниваемых моделей. Более быстрое кодирование напрямую снижает время работы GPU и стоимость построения и обновления поискового индекса.

В посте приведён готовый пример кода на Python: библиотека transformers (классы NeoMMEProcessor и NeoMMEForRetrieval) кодирует изображения страниц документов и текстовые запросы, а сравнение эмбеддингов идёт через MeanMaxSim для late-interaction и косинусное сходство для dense-эмбеддингов.

Ключевые факты

  • NeoMME, семейство из двух мультимодальных энкодеров (260M и 800M параметров): единый двунаправленный трансформер без отдельной визуальной модели и без каузального декодера обрабатывает и текст, и изображения, обучен с нуля по методу маскированной дискретной диффузии.
  • Дообученная версия NeoMME-Retriever на бенчмарке ViDoRe v3 (nDCG@10): у модели 260M, 0,523 (лучший результат среди моделей младше 800M параметров, всего на 0,002 отличается от ColQwen2.5 при примерно в 14 раз меньшем числе параметров у NeoMME); у модели 800M, 0,556 (в пределах 0,009 от Vultron Retriever Flash, 0.8B).
  • Сжатие late-interaction-индекса: иерархический пулинг токенов вместе с int8- или бинарным квантованием сокращает хранение с около 1,5 МБ до 39 КБ на страницу (в 39 раз, более 99% исходного качества) или до 6 КБ (в 255 раз, более 95% качества).
  • На NVIDIA L40S при разрешении 2048×2048 модель 260M кодирует около 51 страницы в секунду, почти вдвое быстрее ColModernVBERT (26 страниц в секунду).
  • Все чекпоинты опубликованы под лицензией Apache 2.0 и уже доступны в библиотеке Hugging Face Transformers.

Почему это важно

Большинство сегодняшних визуальных ретриверов для поиска по документам собирают из уже готовых генеративных визуально-языковых моделей: отдельный визуальный энкодер плюс каузальный декодер, который умеет генерировать текст. Но для поиска, классификации или разметки токенов генерация текста не нужна, вместе с ней исчезает и необходимость тащить за собой её параметры и вычисления. NeoMME показывает, что двунаправленный трансформер, обученный с нуля на маскированной дискретной диффузии сразу на тексте и изображениях, способен конкурировать с ретриверами на основе генеративных VLM: версия на 260M параметров почти сравнялась по качеству поиска с ColQwen2.5, у которой параметров примерно в 14 раз больше, а сжатый индекс занимает в 255 раз меньше места при потере менее 5% качества. Это не просто ещё одна модель, а рабочий пример того, что для задач поиска, не требующих генерации текста, необязательно платить архитектурную цену генеративных моделей.

Кому это важно

Инженерам, которые строят поиск по большим массивам сканов и скриншотов документов, например, в корпоративных RAG-системах: меньше GPU-времени на индексацию и на порядки меньше места для хранения векторов. Командам с ограниченным бюджетом на инфраструктуру, младшая модель на 260M параметров почти не уступает моделям, которые примерно в 14 раз крупнее. Исследователям энкодерных архитектур, как пример того, что двунаправленный энкодер, обученный с нуля без опоры на готовую визуально-языковую модель, может конкурировать с ретриверами, построенными поверх генеративных VLM. Разработчикам инструментов поиска, использующим открытую библиотеку NextPlaid для late-interaction, готовая интеграция в Hugging Face Transformers и лицензия Apache 2.0 без ограничений на коммерческое использование.

Как это применить

Обе модели, NeoMME-Retriever-260M и NeoMME-Retriever-800M, уже доступны в библиотеке Hugging Face Transformers через классы NeoMMEProcessor и NeoMMEForRetrieval: один проход модели вперёд возвращает и dense-, и late-interaction-эмбеддинги для изображений страниц документов и текстовых запросов. Для большинства сценариев авторы советуют использовать late-interaction как основной способ скоринга (например, через MeanMaxSim и открытую библиотеку NextPlaid); для очень больших корпусов документов, сначала отобрать небольшой набор кандидатов через dense-эмбеддинги и приближённый поиск ближайших соседей (ANN), а затем переранжировать этот набор через late-interaction. Если критично место для хранения индекса, можно применить иерархический пулинг токенов вместе с int8- или бинарным квантованием: настройка с пулингом 10 и int8-квантованием обеих сторон сжимает индекс в 39 раз при сохранении более 99% качества поиска, а более агрессивная настройка (пулинг 8, int8 для запросов, бинарное квантование для документов), в 255 раз при сохранении более 95% качества; конкретную точку на этой шкале «место, качество» можно выбирать под свой бюджет хранения. Все чекпоинты выпущены под лицензией Apache 2.0, что не создаёт юридических препятствий для промышленного и коммерческого использования.

Можно ли доверять

Пост написан командой разработчиков NeoMME для блога на Hugging Face: в нём даны конкретные архитектурные детали, числа с бенчмарков (ViDoRe v1/v2/v3), названо конкретное оборудование для замера скорости (NVIDIA L40S), приведён рабочий пример кода, всё это признаки технически серьёзного, проверяемого материала, а не голого маркетинга. При этом сам текст поста нигде прямо не называет организацию, стоящую за NeoMME: единственный след, имя аккаунта Hcompany на Hugging Face, встречающееся в пути к модели («Hcompany/NeoMME-260M-Retriever») в примере кода. Омар Хаттаб и Амели Шатлен упомянуты только как внешние эксперты, автор метода late-interaction и автор стороннего разбора, а не как авторы самой модели. Часть чисел в сравнительной таблице, судя по сноскам в тексте, помечена как взятая из независимого бенчмарка MTEB, а часть, как собственные измерения авторов; какие именно цифры относятся к какой категории, из сохранённого текста поста не видно. Ни оборудование, ни длительность, ни стоимость самого обучения моделей в посте не раскрыты, речь идёт только о скорости инференса на NVIDIA L40S, а не о цене создания модели.

Риски и подводные камни

Обучающее оборудование, число GPU и время тренировки нигде не указаны, весь материал об «эффективности» касается инференса и числа параметров, а не стоимости самого обучения модели. Классификация и разметка токенов названы мотивацией для конструкции без каузального декодера, но ни одного бенчмарка по классификации или разметке токенов в посте не приведено, вся заявленная конкурентоспособность подтверждена только задачами визуального поиска по документам (ViDoRe). Цены или стоимости инференса в посте тоже нет. Самое агрессивное сжатие индекса (в 255 раз) сохраняет «более 95%», а не 100% исходного качества поиска, небольшая, но реальная потеря точности; для более точного результата придётся выбрать более мягкую настройку сжатия (в 39 раз, с более 99% качества) и смириться с более крупным индексом. Наконец, сохранённый для этого пересказа текст обрывается на середине примера кода, поэтому итоговые выводы, оговорки или дополнительные детали, которые могут быть на странице дальше, в пересказе не учтены.