Sakhanda Wire
NVDA $230.86 +1.09% MSFT $512.80 -0.02% GOOGL $338.24 -1.70% META $725.93 +0.10% AMZN $248.23 -0.37%
← До новин

NeoMME: ефективний мультимодальний і багатомовний енкодер

NeoMME: ефективний мультимодальний і мультимовний енкодер
Команда Стаття
Опубліковано 3 вересня 2026 року
Hugging Face Наукова стаття HF arXiv

Логотип NeoMME

Коротко

Ми представляємо NeoMME — сімейство мультимовних мультимодальних енкодерів на 260 млн і 800 млн параметрів. На відміну від багатьох генеративних візуально-мовних моделей, NeoMME не використовує окрему попередньо навчену візуальну вежу чи каузальну мовну модель. Один двонапрямлений Transformer обробляє і текстові токени, і необроблені фрагменти зображень, а всю модель ми навчаємо з нуля за допомогою цілі маскованої дискретної дифузії.

Ми донавчили NeoMME для пошуку візуальних документів, використовуючи підхід ColPali на основі зображень сторінок. NeoMME-Retriever повертає щільні ембеддинги та ембеддинги пізньої взаємодії за один прямий прохід. Обидва розміри моделей лежать на фронтирі Парето ViDoRe v3 за показниками nDCG@10 і розміром моделі. За однакового розміру вхідного зображення 2048×2048 на GPU NVIDIA L40S модель на 260 млн параметрів кодує приблизно 51 сторінку за секунду — майже вдвічі швидше за ColModernVBERT. Ієрархічне об’єднання токенів і асиметричне квантування зменшують обсяг сховища індексу пізньої взаємодії приблизно з 1,5 МБ до 6 кБ на сторінку (у 255 разів менше), зберігаючи понад 95% базового nDCG@10.

NeoMME доступна в Hugging Face Transformers. Ми випускаємо всі контрольні точки моделей за ліцензією Apache 2.0.

Навіщо ще один мультимодальний енкодер?

Багато сучасних систем пошуку у візуальних документах адаптовано з попередньо навчених генеративних візуально-мовних моделей. Окремо попередньо навчений візуальний енкодер створює візуальні ознаки, які проєктор відображає у простір входів мовної моделі. Потім каузальний декодер обробляє об’єднані представлення зображення й тексту. Пошук, класифікація та маркування токенів не генерують текст авторегресійно, тому їм не потрібні ні каузальний декодер, ні пов’язані з цією архітектурою витрати параметрів і обчислень.

ModernBERT запропонував ефективні архітектурні та навчальні вдосконалення для двонапрямлених енкодерів. Для пошуку у візуальних документах ModernVBERT застосував двонапрямлений текстовий енкодер у стилі ModernBERT, зберігши окрему попередньо навчену візуальну вежу SigLIP2. Ми хотіли піти ще далі, спроєктувавши й навчивши мультимодальний енкодер без перенесення витрат параметрів і обчислень, властивих VLM.

NeoMME (вимовляється «ні-оу-мі», IPA /ˈniː.oʊ.mi/) — це мультимовний мультимодальний базовий енкодер, який створює векторні представлення для вхідного тексту та/або зображень за допомогою одного енкодера Transformer. Він не ґрунтується на наявній попередньо навченій візуальній вежі, текстовому енкодері чи текстовому декодері.

Порівняння шляхів входу для двох веж, VLM, ModernVBERT і NeoMME
На відміну від енкодерів із двома вежами та VLM, NeoMME обробляє фрагменти зображень і текстові токени в одному двонапрямленому Transformer без попередньо навченої візуальної вежі, текстового енкодера або декодера.

Зображення й текст використовують один і той самий обчислювальний шлях, тож NeoMME легше застосовувати для попереднього навчання, донавчання, паралелізації та обслуговування обох модальностей.

Основа енкодера NeoMME

Один Transformer для зображень і тексту

NeoMME доступна у двох розмірах: 260M і 800M. Обидва варіанти мають однакову архітектуру:

  • Нативні мультимодальні входи: для текстових входів використовуються факторизовані токен-ембеддинги, а зображення поділяються на сітку неперекривних фрагментів 32×32 і проєктуються за допомогою невеликої MLP. І ті, й інші надходять до одного енкодера Transformer.
  • Динамічна роздільна здатність зображення: зображення зберігають співвідношення сторін і розмір. Завдяки цьому модель може використовувати більше токенів для високороздільної, насиченої інформацією сторінки документа, ніж для меншого зображення з меншим обсягом вмісту.
  • Довгий двонапрямлений контекст: обидві моделі мають довжину контексту 16 384 токени (цього достатньо для двох стандартних зображень 3840×2160 4K UHD). У більшості шарів використовується симетрична увага у ковзному вікні, тоді як кожен шостий шар і фінальний шар використовують глобальну увагу.
  • Сучасний стек енкодера: NeoMME використовує сучасні вдосконалення енкодерів, зокрема увагу з групованими запитами, нормалізацію query-key, керовану увагу, двовимірні обертальні позиційні ембеддинги та MLP із квадратною ReLU.
  • Мультимовний текст: ми з нуля навчили BPE-токенізатор зі словником на 131 тис. токенів на мультимовному тексті, коді, математиці та створених машиною транскриптах зображень.
Чергування шарів із ковзним вікном і глобальною увагою в NeoMME
Чергування шарів із ковзним вікном і глобальною увагою у стеку енкодера NeoMME.

Навчання на зображеннях через маскований текст

Ми попередньо навчаємо NeoMME з нуля як засіб шумозаглушення тексту з дискретною маскованою дифузією. Для кожного прикладу, що містить лише текст, ми рівномірно вибираємо рівень спотворення від 0 до 1. Потім кожен придатний текстовий токен незалежно маскується з такою ймовірністю.

Для мультимодальних прикладів використовуються рівні спотворення від 0,3 до 1. Фрагменти зображення залишаються видимими, тоді як NeoMME відновлює замаскований текст. За слабкого маскування модель часто може відновити пропущене слово лише з навколишнього тексту. Наприклад, «cat» є правдоподібним завершенням речення «The [MASK] sat on the mat», навіть без зображення. Але сильне маскування змушує модель навчатися описів, прив’язаних до зображення, маючи мало або взагалі не маючи сигналу від незамаскованих текстових токенів.

Вплив спотворення тексту на текстові та візуальні дані, доступні NeoMME
Сильніше спотворення тексту усуває суто мовні спрощення й заохочує NeoMME використовувати видимі візуальні дані.

Попереднє навчання поєднує мультимовний текст, код, математику, природні зображення та зображення документів. Кожна модель обробляє приблизно 524 мільярди упакованих вхідних токенів, зокрема 290 мільярдів токенів із прикладів, що містять лише текст. Цей обсяг тексту відносно невеликий порівняно з 2 трильйонами навчальних токенів ModernBERT. Тому для підвищення ефективності використання даних під час навчання ми обрали оптимізатор NorMuon.

NeoMME-Retriever

Щоб змістовно оцінити базову модель у прикладних задачах, ми донавчили NeoMME для пошуку у візуальних документах, використовуючи методологію зображень сторінок, запропоновану ColPali. Тоді як традиційний текстовий пошук полягає в пошуку фрагментів тексту, NeoMME-Retriever ранжує скриншоти сторінок документів і обходить усі етапи попередньої OCR-обробки, необхідні для вилучення тексту з PDF-файлів. Подання сторінок як зображень зберігає макет, графіки, таблиці, тип і розмір шрифту та інші візуальні підказки, які не здатна відтворити навіть ідеальна OCR-модель.

Конструкція з двома головками для щільного пошуку та пошуку з пізньою взаємодією

NeoMME-Retriever повторно використовує основу NeoMME, але додає до неї дві спільно навчені головки для пошуку:

  • Щільна головка усереднює вектори прихованих станів основи в нормалізований вектор (усереднене об’єднання). Щільні ембеддинги сьогодні використовуються найчастіше: вони компактні й природно працюють із методами приблизних найближчих сусідів (ANN) для швидкого пошуку.
  • Головка пізньої взаємодії проєктує кожен текстовий токен або фрагмент зображення з вихідних прихованих станів основи в нормалізований вектор розмірністю 128. Порівняно зі щільними ембеддингами, вища деталізація зберігає локальні відповідності між окремими токенами запиту та ділянками зображення.
Головки пізньої взаємодії та щільного пошуку для NeoMME
Головки пізньої взаємодії та щільного пошуку для обох розмірів моделей NeoMME.

Омар Хаттаб, який запровадив пізню взаємодію в ColBERT, пояснює, чому цей термін точніший за «мультивекторний». Він описує деталізацію та здатність до навчання функції оцінювання, а не просто кількість збережених векторів.

Щоб дізнатися більше про пізню взаємодію, радимо прочитати цей короткий курс Амелі Шателен.

Один прямий прохід NeoMME-Retriever повертає обидва представлення, що забезпечує гнучкість незалежно від вашого сценарію використання та інфраструктури. Загалом ми рекомендуємо використовувати ембеддинги пізньої взаємодії, оскільки вони потужніші й легко працюють із бібліотеками з відкритим кодом, такими як NextPlaid. Однак якщо у вас дуже великий корпус, можна виконати один прямий прохід NeoMME-Retriever, отримати щільний ембеддинг, знайти невелику кількість документів через ANN-індекс, а потім використати пізню взаємодію для повторного ранжування знайдених кандидатів.

Конкурентний пошук у компактних моделях

Ми наводимо nDCG@10 на ViDoRe v3. NeoMME-Retriever-260M досягає 0,523 — найвищого показника серед оцінених моделей із менш ніж 800 млн параметрів. Від ColQwen2.5 її відділяє лише 0,002 nDCG@10, хоча вона використовує приблизно у 14 разів менше параметрів. NeoMME-Retriever-800M досягає 0,556, відстаючи на 0,009 nDCG@10 від близької за розміром моделі Vultron Retriever Flash (0.8B). Обидві моделі NeoMME-Retriever лежать на фронтирі Парето за розміром моделі.

nDCG@10 ViDoRe v3 залежно від розміру моделі
nDCG@10 ViDoRe v3 залежно від розміру моделі.

У ViDoRe v1 і v2 використовується nDCG@5. В обох тестах NeoMME-Retriever-260M перевершує ColModernVBERT і вдвічі більшу ColSmol-500M. NeoMME-Retriever-800M перевершує ColPali v1.3, використовуючи у 3,6 раза менше параметрів.

Результати пошуку у візуальних документах на тестах ViDoRe.
Дані про модель ViDoRe (nDCG@k)
Модель Параметри v3 (@10) v2 (@5) v1 (@5)
<300M
ColModernVBERT 250M 0.261† 0.407‡ 0.806‡
ColSmol-256M† 256M 0.207 0.348 0.797
NeoMME-260M‡ 260M 0.523 0.522 0.860
Від 300M до 1B
ColSmol-500M 500M 0.340‡ 0.455† 0.825†
Vultron Flash† 850M 0.565 0.604 0.882
NeoMME-800M‡ 800M 0.556 0.559 0.874
>1B
ColQwen2.5-v0.2† 3.75B 0.524 0.601 0.895
ColPali v1.3† 2.92B 0.430 0.547 0.848

† Показники з MTEB. ‡ Результати наших власних оцінювань.

Практичний пошук у високій роздільній здатності для пізньої взаємодії

Обсяг сховища пізньої взаємодії лінійно залежить від кількості векторів у вихідному ембеддингу. Зображення з вищою роздільною здатністю містять більше фрагментів, тому створюють більші ембеддинги. Наприклад, квадратна сторінка розміром 2048×2048 створює в NeoMME-Retriever ембеддинги, що містять 4200 векторів, або приблизно 2,1 МБ у форматі float32. На тесті ViDoRe v3 виміряне середнє значення становить приблизно 1,5 МБ на документ.

Щоб зменшити обсяг індексу пізньої взаємодії, ми поєднуємо два взаємодоповнювальні методи стиснення:

  1. Ієрархічне об’єднання токенів групує схожі вектори документів у заданому мультивекторному ембеддингу й замінює кожен кластер його середнім значенням, зменшуючи кількість векторів, що зберігаються для кожної сторінки.
  2. Асиметричне квантування квантує ембеддинги документів до int8 або бінарного формату. Оскільки ембеддинги запитів не зберігаються й створюються лише на вимогу, їх можна залишати з вищою точністю.

Ми протестували цю конфігурацію на ViDoRe v3. За коефіцієнта об’єднання 10 та int8 для запитів і документів обсяг сховища зменшився приблизно з 1,5 МБ до 39 кБ на сторінку — у 39 разів, причому було збережено понад 99% базового nDCG@10. Агресивніша конфігурація використовує коефіцієнт об’єднання 8, int8 для запитів і бінарний формат для документів. Вона займає 6 кБ на сторінку (у 255 разів менше) і зберігає понад 95% початкової якості пошуку.

Фронтир якості та обсягу сховища для індексу пізньої взаємодії NeoMME-260M
Фронтир якості та обсягу сховища для індексу пізньої взаємодії NeoMME-260M на ViDoRe v3. Підписи показують коефіцієнт об’єднання, збережену якість, стиснення та обсяг сховища.

Користувачі можуть вибрати налаштування стиснення на цьому фронтирі залежно від доступного обсягу сховища та необхідної якості пошуку.

Швидкий висновок для здешевлення індексації мультимодальних корпусів

Перш ніж виконувати пошук у корпусі, модель пошуку має перетворити документи на ембеддинги, які зберігатимуться у векторному сховищі на кшталт Qdrant, Weaviate або Milvus. Швидше кодування прискорює створення індексу та додавання до нього нових документів, зменшуючи необхідний час роботи GPU і обчислювальні витрати.

Тому ми виміряли швидкість кодування зображень для NeoMME-Retriever та інших мультимодальних систем пошуку документів. Ми використовували попередньо оброблені тензори зображень і окремо калібрували розмір пакета для кожної моделі та роздільної здатності зображення. За однакового розміру входу 2048×2048 на одному NVIDIA L40S NeoMME-Retriever-260M кодує приблизно 51 сторінку за секунду — майже вдвічі швидше за ColModernVBERT, який обробляє 26 сторінок за секунду. Обидві моделі NeoMME-Retriever, на 260M і 800M параметрів, також швидші за інші порівнювані нами моделі на зображеннях меншого розміру.

Пропускна здатність кодування документів за різної роздільної здатності на NVIDIA L40S
Пропускна здатність кодування документів залежно від системи пошуку та роздільної здатності входу на одному NVIDIA L40S.

Спробуйте NeoMME-Retriever самостійно!

NeoMME-Retriever (260M і 800M) одночасно повертає щільні та мультивекторні ембеддинги. Наведений нижче приклад оцінює два текстові запити щодо двох зображень сторінок документів за допомогою пізньої взаємодії MeanMaxSim і щільної косинусної подібності.

Натисніть, щоб переглянути повний фрагмент прикладу 🤗 transformers

pip install -U accelerate "transformers @ git+https://github.com/huggingface/transformers.git@main" "sentence-transformers>=6.0.0"
from typing import Any, Literal

import requests
import torch
from PIL import Image
from sentence_transformers.util import cos_sim, mean_maxsim

from transformers import BatchFeature, NeoMMEForRetrieval, NeoMMEProcessor


def encode(
    messages: list[list[dict[str, Any]]],
    task: Literal["query", "document"],
) -> BatchFeature:
    return processor.apply_chat_template(
        messages,
        task=task,
        tokenize=True,
        return_dict=True,
        return_tensors="pt",
        processor_kwargs={"padding": "longest"},
    )


model_name = "Hcompany/NeoMME-260M-Retriever"
processor = NeoMMEProcessor.from_pretrained(model_name)
model = NeoMMEForRetrieval.from_pretrained(model_name, device_map="auto")


image_urls = [
    "https://github.com/tonywu71/colpali-cookbooks/blob/6ef1332da6bcb48c7ef1f19b25bfa555be7031a8/examples/data/shift_kazakhstan.jpg?raw=true",
    "https://github.com/tonywu71/colpali-cookbooks/blob/6ef1332da6bcb48c7ef1f19b25bfa555be7031a8/examples/data/energy_electricity_generation.jpg?raw=true",
]
documents = [Image.open(requests.get(url, stream=True).raw) for url in image_urls]


queries = [
    "Quelle partie de la production pétrolière du Kazakhstan provient de champs en mer ?",
    "Which hour of the day had the highest overall electricity generation in 2019?",
]

document_messages = [
    [{"role": "user", "content": [{"type": "image", "image": document}]}] for document in documents
]
query_messages = [[{"role": "user", "content": query}] for query in queries]

inputs_documents = encode(document_messages, "document").to(model.device)
inputs_text = encode(query_messages, "query").to(model.device)

with torch.inference_mode():
    document_outputs = model(**inputs_documents)
    query_outputs = model(**inputs_text)

late_scores = mean_maxsim(
    query_outputs.embeddings,
    document_outputs.embeddings,
    a_mask=inputs_text["attention_mask"],
    b_mask=inputs_documents["attention_mask"],
)
dense_scores = cos_sim(query_outputs.dense_embeddings, document_outputs.dense_embeddings)


print(late_scores, dense_scores)

Донавчання за допомогою Sentence Transformers

Ми надаємо окремі контрольні точки для щільного пошуку та пізньої взаємодії для донавчання за допомогою Sentence Transformers v6. За тією самою схемою, що й текстові енкодери на кшталт ModernBERT, Sentence Transformers завантажує основу через NeoMMEModel, а не через клас із двома головками NeoMMEForRetrieval. Sentence Transformers наразі підтримує одну пошукову головку на модель, тому кожна контрольна точка дає змогу незалежно донавчати щільну головку або головку пізньої взаємодії. Щоб навчати обидві головки разом, використовуйте NeoMMEForRetrieval із власним Trainer.

Від пошуку до візуального RAG

Пошук у візуальних документах можна використовувати як перший етап системи генерації з доповненням пошуком (RAG). На відміну від текстового RAG, який знаходить вилучені фрагменти тексту, візуальний RAG знаходить оригінальні зображення сторінок і надсилає їх візуально-мовній моделі. Тоді модель може використовувати таблиці, графіки, діаграми та макет сторінки, які вилучення тексту може спотворити або пропустити. Ось як працює візуальний RAG:

  1. Індексація: перетворіть кожну сторінку PDF на зображення, створіть ембеддинг за допомогою пошукової моделі та збережіть ембеддинги у векторному сховищі.
  2. Пошук: створіть ембеддинг запиту користувача за допомогою тієї самої моделі та знайдіть k найрелевантніших сторінок.
  3. Генерація: додайте зображення після запиту в повідомленні чату (наприклад, {query}{img_1}{img_2}...{img_k}) і надішліть його до VLM для генерації відповіді.

Ви можете безпосередньо протестувати візуальний RAG із NeoMME-Retriever у нашому HF Space: 🤗 tonywu71/neomme-retriever-demo.

Висновок

NeoMME замінює окремі попередньо навчені енкодери зображень і тексту одним двонапрямленим Transformer із довгим контекстом. Ми навчаємо його з нуля для обробки мультимовних текстових токенів і необроблених фрагментів зображень 32×32.

NeoMME-Retriever — це версія NeoMME, донавчена для пошуку у візуальних документах. Один прямий прохід створює щільні представлення та представлення пізньої взаємодії. Модель на 260 млн параметрів перевершує всі оцінені моделі з менш ніж 800 млн параметрів і за однакового розміру входу 2048×2048 кодує сторінки приблизно вдвічі швидше за ColModernVBERT. Щоб зменшити значний обсяг сховища, необхідний для ембеддингів пізньої взаємодії у високороздільних документах, ми експериментували з ієрархічним об’єднанням токенів і асиметричним квантуванням та змогли зменшити обсяг ембеддингів пізньої взаємодії приблизно з 1,5 МБ до 6 кБ на сторінку — у 255 разів, зберігши понад 95% базового nDCG@10.

Ми випускаємо всі контрольні точки моделей NeoMME і реалізацію Hugging Face Transformers, доступну від першого дня, щоб розробники могли створювати ефективні мультимодальні та мультимовні моделі представлень на основі нашої роботи.

Подяки

NeoMME розпочався як побічний проєкт двох добрих друзів. Ми працювали в умовах обмеженого часу й обчислювальних ресурсів і вирішили поділитися результатами, щоб спільнота могла розвивати їх далі. Дякуємо H Company за підтримку роботи та надання обчислювальних ресурсів, використаних для навчання NeoMME.

Цитування

@misc{lac2026neommesingletowermultimodalnativemultilingual,
      title={NeoMME: A Single-Tower Multimodal-Native Multilingual Foundation Encoder for Efficient Fine-Tuning and Inference},
      author={Aurélien Lac and Tony Wu},
      year={2026},
      eprint={2609.01657},
      archivePrefix={arXiv},
      primaryClass={cs.IR},
      url={https://arxiv.org/abs/2609.01657},
}

Моделі, згадані в цій статті 7

Простори, згадані в цій статті 1

Статті, згадані в цій статті 1

Колекції, згадані в цій статті 1

Спільнота

Завантажуйте зображення, аудіо та відео, перетягуючи їх у поле введення тексту, вставляючи або натискаючи тут.
Торкніться або вставте сюди, щоб завантажити зображення

· Зареєструйтеся або увійдіть, щоб залишити коментар

Моделі, згадані в цій статті 7

Простори, згадані в цій статті 1

Статті, згадані в цій статті 1

Колекції, згадані в цій статті 1

Перекладено автоматично з англійської. Оригінал статті — за посиланням нижче.

Вперше опубліковано виданням Hugging Face

Читати оригінал на Hugging Face ↗

Текст і зображення належать Hugging Face і наводяться тут із зазначенням авторства та посиланням на оригінальну публікацію.

← До новин

Ще новини

Усі останні новини