Мультимодальні embeddings: протестуйте кожну модальність перед production

Мультимодальні embeddings: протестуйте кожну модальність перед production

Аудиторія: Досвідчені фахівці, які створюють системи пошуку, RAG, рекомендацій або агентів для роботи з текстом, зображеннями, відео та візуальними документами.

Мультимодальні embeddings можуть об’єднати кілька retrieval-пайплайнів в одному векторному просторі. Але вони не зводять оцінювання до одного показника. Модель може очолювати агрегований benchmark і водночас пропускати короткі відеоподії, точні терміни, підписи на графіках або локальні докази на сторінці, які потрібні production-системі.

Правило для production просте: зберігайте результати для тексту, зображень, відео та візуальних документів окремо; порівнюйте dense, sparse і hybrid retrieval там, де кожен із них доречний; вимірюйте те, чого encoder ніколи не бачив; і розглядайте кожну зміну моделі як міграцію індексу.

Три статті, опубліковані протягом п’яти днів, незвично чітко показують цю межу. UEmbed за один прохід генерує dense і sparse представлення. DME від Douyin навчає компактний вектор зберігати retrieval-докази. ReLoop-UME додає рекурентну глибину без генерації rationale-токенів. Усі вони демонструють сильніший retrieval, але їхні патерни помилок вказують на різні операційні ризики.

Що таке мультимодальні embeddings?

Мультимодальні embeddings перетворюють різні типи вхідних даних на вектори, які можна порівнювати у спільному просторі. Текстовий запит може знайти фотографію, відео може відповідати текстовому опису, а скриншот — знайти візуально схожу сторінку документа.

Такий спільний інтерфейс корисний, оскільки retrieval-система може використовувати approximate nearest-neighbor search замість запуску generative model для кожного кандидата. Водночас він приховує важливі відмінності. Текст містить точні лексичні сигнали. Зображення містять локальні об’єкти та зв’язки між ними. Відео додає часові події та вибір кадрів. Візуальні документи поєднують layout, OCR, таблиці, графіки та контекст сторінки.

Сучасні системи демонструють ці відмінності через власні обмеження. Документація Gemini Embedding 2 від Google відображає текст, зображення, відео, аудіо та PDF в одному просторі, але обробляє не більше 32 кадрів на відео й не обробляє аудіодоріжку відео. PDF обмежено шістьма сторінками на запит. Картка моделі Qwen3-VL-Embedding-2B підтримує текст, зображення, скриншоти, відео та змішані входи з контекстом 32K і налаштовуваними розмірностями від 64 до 2 048.

Ці можливості є вхідними даними для плану оцінювання, а не доказом того, що кожна модальність однаково добре працює для конкретного корпусу.

Що насправді вимірювали три нові статті

Статті оптимізують різні частини одного retrieval-обмеження: зберегти достатньо доказів для розрізнення, не перетворюючи кожен запит на повільне завдання генерації.

Ці числа походять з експериментів авторів. Це не результати зі спільного production-середовища, і їх не слід порівнювати так, ніби hardware, дані, масштаб моделей і serving-стеки були контрольованими.

UEmbed: dense і sparse retrieval за один прохід

UEmbed додає 16 learnable special tokens до decoder-only multimodal model. Кожен токен прогнозує sparse-ваги над окремим розділом vocabulary; фінальний стан end-of-sequence забезпечує dense-вектор. Автори випускають варіанти 2B, 4B і 9B, навчені на публічних даних.

UEmbed-9B повідомляє 71.8 для dense retrieval і 71.0 для sparse retrieval на MMEB-V2. Hybrid-результат додає 0.3 бала для тексту та 0.5 для візуальних документів порівняно з dense retrieval, майже не змінюючи показники для зображень і відео. Це підтримує вузький висновок: learned sparse-сигнали можуть доповнювати dense retrieval там, де важливі точні терміни або текст документа. Це не доводить, що hybrid search покращує кожну модальність.

Обмеження мають практичний характер. Навчальні дані зміщені в бік англійської та китайської мов, а стаття повідомляє про слабшу cross-lingual sparse-генералізацію. Sparse-представлення також зберігає артефакти vocabulary. Для відео спостерігається більший розрив між dense і sparse-показниками, а стаття не містить повного дослідження ефективності inverted index.

Репозиторію UEmbed було лише кілька днів на момент перевірки 4 серпня 2026 року. Він мав два коміти, шість зірок, жодного fork і жодного release. Ці числа описують зрілість, а не якість моделі. Реалізація ще настільки рання, що production-командам слід очікувати змін інтерфейсу та serving.

DME: навчити вектор зберігати retrieval-докази

Технічний звіт Douyin Multimodal Embedding розділяє навчання на два етапи. Спочатку масштабне contrastive pretraining створює широкий спільний простір. Потім latent reasoning і cross-conditional reconstruction, що використовуються лише під час навчання, змушують компактний embedding зберігати дрібнозернисті докази про відповідний об’єкт.

Заявлений показник MMEB-V2 зростає з базових 70.9 до 72.5 після pretraining першого етапу, до 73.8 після evidence-grounded latent reasoning і до 74.8 після reconstruction для моделі 2B. Для моделі 9B повідомляється 78.4. Стаття також повідомляє про відносний приріст 2.92% на внутрішньому offline-наборі та приріст 0.1% на внутрішній Lifetime-метриці в online A/B-тесті.

Автори вимірювали ці production-результати всередині Douyin. У статті робиться висновок, що навчання зі збереженням доказів покращує industrial retrieval без накладних витрат generative serving. Читач не може незалежно відтворити внутрішній dataset, визначення метрики, traffic mix або умови deployment за цим звітом. Тому практична інтерпретація обмежена: reconstruction може бути корисною training objective, але online-показник не є прогнозом, який можна безпосередньо перенести.

ReLoop-UME: додати обчислення вздовж depth

ReLoop-UME досліджує, чи може модель виконувати більше retrieval-специфічних обчислень без генерації проміжних токенів. Вона визначає middle-to-late-ділянку, де позитивні та негативні приклади розділяються, повторно використовує цей parameter-shared блок чотири рази й переносить докази через п’ять learnable retrieval registers.

На MMEB-V2 модель 2B повідомляє 63.2 загалом проти 58.0 для VLM2Vec-V2 і 60.1 для UME-R1 у порівнянні зі статті. Модель 7B повідомляє 65.9. На одному H20 GPU автори вимірюють 201 мілісекунду на приклад: у 44.9 раза швидше за UME-R1 і в 1.5 раза швидше за PLUME, але в 1.3 раза повільніше за non-recurrent VLM2Vec-V2 baseline.

Агреговане покращення приховує попередження. ReLoop-UME-2B отримує 40.5 на video slice зі статті — нижче за 44.1 у PLUME; результат 7B також поступається UME-R1 на відео. Метод вибирає вісім кадрів. У власному розділі обмежень зазначено, що recurrence не може відновити докази, пропущені під час sampling, а згладжування temporal boundaries може пропускати короткі події.

Чому одного середнього показника benchmark недостатньо

MMEB-V2 було представлено разом із VLM2Vec-V2 для охоплення 78 datasets: 36 image, 18 video і 24 visual-document datasets. Така широта робить benchmark корисним для розробки моделей. Але середнє значення за цими завданнями все одно застосовує ваги, які можуть майже не відповідати production-навантаженню.

Уявімо три системи з однаковим агрегованим показником:

Першій потрібні лексична точність і розуміння скриншотів. Друга залежить від temporal coverage. Третій потрібні page-local OCR, layout і точність modifier-ів. Усереднення їхніх помилок створює акуратне число й погане рішення.

Відтворюване оцінювання multimodal embedding

Почніть із зафіксованого snapshot корпусу та набору запитів, що містить відомі релевантні докази. Зберігайте разом оригінальний source object, embedding input і relevance judgment. Інакше помилка encoder та помилка ingestion стануть нерозрізненими.

1. Створіть modality slices до вибору метрик

Створіть окремі slices для тексту, зображень, відео та візуальних документів. Потім розділіть їх за важливою поведінкою:

Додайте поле coverage для кожного прикладу. Фіксуйте, чи дійшов source evidence до encoder. Пропущений кадр, обрізана легенда графіка або пропущена сторінка PDF не мають оцінюватися як помилка embedding.

2. Порівнюйте повні retrieval-пайплайни

Протестуйте щонайменше таких кандидатів на однакових relevance judgments:

Hybrid baseline важливий, оскільки результат UEmbed показує приріст, зосереджений у тексті та візуальних документах, а не в кожній модальності. Text baseline важливий, оскільки captions, OCR і structured metadata можуть бути дешевшими для індексації, простішими для налагодження та кращими для точних термінів, ніж native multimodal vector.

3. Вимірюйте якість, coverage і вартість разом

Звітуйте про метрики для кожного slice і як розподіли, а не лише як одне середнє.

Коректний підсумок залишає найгірший важливий slice видимим. Наприклад, підвищуйте кандидата лише тоді, коли weighted aggregate покращується і жоден protected slice не перевищує свій regression budget.

text promote = aggregate_gain > 0 and text_regression <= budget.text and image_regression <= budget.image and video_regression <= budget.video and visual_doc_regression <= budget.visual_doc and p95_latency <= budget.latency

Бюджети є product-рішеннями. Така структура не дозволяє image-heavy benchmark компенсувати video failure у продукті для video search.

*Спочатку оцініть кожен retrieval-канал, а потім застосуйте спільні runtime-, migration- і release-gates.*

4. Версіонуйте embedding space

Версія embedding model є частиною формату збережених даних. У migration guide Google зазначено, що `gemini-embedding-001` і `gemini-embedding-2` створюють несумісні простори, тому оновлення потребує re-embedding усіх наявних даних. Query vectors з одного простору не можна безпосередньо порівнювати з document vectors з іншого.

5. Запускайте shadow для production-запитів перед перемиканням

Offline evaluation контролює відомі випадки. Shadow traffic перевіряє фактичний розподіл, не змінюючи результати, видимі користувачам. Логуйте обидва списки кандидатів, latency, empty results і slice або input type, пов’язаний із кожною розбіжністю. Переглядайте розбіжності до часткового rollout.

Не використовуйте лише clicks як ground truth для relevance. Position bias і поточний ranker визначають, на що користувачі можуть натискати. Поєднуйте вибіркові human judgments, успішність downstream task і behavioral signals.

Framework для production-рішення

Використовуйте multimodal embedding model, коли raw visual або temporal evidence змінює relevance, а text representation втрачає ці докази. Зберігайте простіший text або hybrid pipeline, коли корпус переважно складається з прози, домінують точні ідентифікатори або надійні captions і OCR уже захоплюють корисний сигнал.

Не обирайте більшу модель до тестування preprocessing. Frame selection, page segmentation, OCR, query instructions і negative examples можуть визначати результат сильніше. Open-source activity може виявити implementation friction, але не є quality benchmark. Станом на 4 серпня 2026 року репозиторій Qwen3-VL-Embedding мав 32 коміти та 55 відкритих issues; серед нещодавніх issues були serving endpoints і representation mismatches. Це engineering signals для дослідження, а не підстави автоматично приймати чи відхиляти модель.

Що підтверджують докази

Статті підтримують три конкретні висновки.

По-перше, компактний multimodal vector може зберігати більше retrieval-специфічних обчислень, ніж один незмінений forward pass. DME додає training-only objectives; ReLoop-UME додає recurrent depth; UEmbed одночасно отримує dense і sparse views.

По-друге, механізм представлення змінює патерн помилок. Sparse retrieval має lexical і cross-lingual ризики. Recurrent depth має training і latency costs. Відео залишається вразливим до sampling ще до запуску embedding model.

По-третє, production evidence має бути локальним. Автори виміряли корисні benchmark і system results, але жодна стаття не вимірювала ваш corpus, query mix, latency budget, index migration або вартість неправильного retrieval.

Корисний висновок має операційний характер: впроваджуйте multimodal embeddings лише після того, як кожна модальність пройде власні retrieval і coverage tests. Спільний vector space може спростити serving. Оцінювання має залишатися навмисно нерівномірним.

FAQ

Чи мають text і image embeddings використовувати один індекс?

Вони можуть спільно використовувати індекс, якщо модель навчена розміщувати ці модальності в одному сумісному просторі, а cross-modal retrieval є частиною завдання. Використовуйте окремі fields або indexes, коли важливі lexical retrieval, modality-specific filters, різні update rates або незалежний rollback. Тестуйте score fusion на реальних relevance judgments, а не припускайте, що одна layout краща.

Чи потрібно робити re-embed даних під час зміни моделей?

Зазвичай так. Embedding spaces різних моделей або несумісних версій не можна безпечно порівнювати. Створіть versioned replacement index, виконайте re-embed корпусу, запустіть shadow queries проти обох індексів і зберігайте старий індекс, доки новий не пройде per-slice quality та latency gates.

Перевірка тверджень

Джерела