Мультимодальні вбудовування за межами одного вектора

Від моменту випуску pplx-embed-v1 у лютому ми працювали над новим поколінням моделей вбудовувань. Минулого тижня ми представили нашу нову контекстну модель вбудовувань, pplx-embed-v2-context. Сьогодні ми розширюємо сімейство моделлю pplx-embed-v2-late — набором моделей пізньої взаємодії. Окрім сильніших можливостей пошуку, це перші моделі, які поєднують три ключові можливості:

• Багатовекторні представлення. Замість того щоб стискати кожен вхід у один вектор, ці моделі зберігають вектори на рівні токенів для точнішого порівняння запиту й документа. Це дає змогу різним частинам запиту відповідати різним частинам документа, зберігаючи деталі, які особливо цінні для мультимодального пошуку.
• Підтримка як текстових, так і зображеневих модальностей. Окрім можливостей пошуку текст-в-текст, наявних у наших попередніх моделях, ці нові моделі підтримують пошук текст-в-зображення, що дає змогу безпосередньо шукати візуалізовані сторінки PDF без потреби в OCR або розпізнаному тексті.
• Спільний простір вбудовувань. Ми випускаємо дві моделі — 0,6B і 9B — щоб підтримати різні вимоги до якості, затримки та обчислювальних ресурсів. Кожну можна використовувати незалежно, але спільний простір вбудовувань також дає змогу меншій моделі виконувати запит до індексу, створеного більшою моделлю, поєднуючи вищу якість вбудовувань документів із дешевим і швидким інференсом для запитів.

Ці нові моделі досягають найкращих на сьогодні результатів у низці бенчмарків візуального й текстового пошуку, а також в агентних завданнях із відповідями на запитання. Зокрема, у ViDoRe (V3) — провідному бенчмарку візуального пошуку документів — наша модель 0.6B не поступається моделям із вп’ятеро більшою кількістю активних параметрів. Обидві моделі загальнодоступні на Hugging Face. Докладніше про методологію та результати оцінювання читайте в нашому технічному звіті.

Від одиничних векторів до пізньої взаємодії

Системи пошуку мають знаходити баланс між ефективністю та глибиною взаємодії між запитами й документами. Щільні моделі вбудовувань кодують кожен запит і кожен документ незалежно, що дає змогу порівнювати їх за допомогою дешевого внутрішнього добутку. Це робить практичним приблизний пошук найближчих сусідів (ANN) по мільярдах документів. На іншому полюсі, cross-encoders обробляють запит і документ разом, забезпечуючи багатшу взаємодію, але потребуючи окремого прямого проходу для кожного кандидата. Застосовувати це обчислення до великого корпусу документів для кожного пошуку надто дорого, тому cross-encoders зазвичай використовують лише для повторного ранжування невеликого набору знайдених кандидатів.

Обмеження щільних вбудовувань

Представлення всього документа одним вектором фіксованого розміру створює інформаційне вузьке місце. У міру того як документи стають довшими й охоплюють більше тем, моделі потрібно стискати більше вмісту в той самий вектор, що ускладнює збереження всього, релевантного для запиту. Фрагментація на частини може зменшити цей тиск, але вона розбиває документ і може розділяти інформацію, яка має сенс лише разом; цю проблему ми також вирішуємо з нашою контекстною моделлю вбудовувань. Це вузьке місце ще більше погіршується в мультимодальних умовах, де щільність інформації в зображеннях вимагає ще більшого стискання.

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

Пошук пізньої взаємодії

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

Наші моделі pplx-embed-v2-late використовують архітектуру у стилі ColBERT, формуючи вбудовування розмірністю 128 для кожного токена у вході. Ми оцінюємо пари запит-документ за допомогою MaxSim; для кожного токена запиту модель обирає токен документа з найвищою оцінкою і підсумовує максимальні схожості для кожного токена, щоб отримати фінальну оцінку. Це дає змогу різним частинам запиту відповідати різним частинам документа, причому кращі збіги токенів роблять більший внесок у результат.

Розгорнути

Ця додаткова виразність має вищі витрати на зберігання та на оцінювання кандидатів. Щільний пошук зберігає один вектор на документ і оцінює кандидата одним внутрішнім добутком; пізня взаємодія зберігає вектори для токенів документа і обчислює багато подібностей між токенами. Вартість зростає разом із довжиною документа, тому пізня взаємодія потребує іншого компромісу між індексуванням і обслуговуванням, ніж ANN-пошук з одним вектором. Натомість вона забезпечує багатший початковий етап пошуку для корпусів, чутливих до якості, і може також слугувати пізнішим етапом у більших вебмасштабних пошукових пайплайнах.

Одна модель, кілька модальностей

Показано, що така покращена глибина взаємодії є дуже корисною для різних завдань, зокрема пошуку з довгим контекстом, агентного пошуку та пошуку поза доменом. Ця відмінність особливо помітна в мультимодальному пошуку, що демонструє значне лідерство моделей ColPali на лідерборді ViDoRe(V3).

Реальні корпуси складаються не лише з чистого тексту. Вони надходять у вигляді PDF-файлів, презентацій, скриншотів, відсканованих сторінок, діаграм і таблиць. Традиційний конвеєр розбирає ці документи, застосовує OCR або captioning і шукає в отриманому тексті, що дорого і з втратою даних: це може вносити помилки OCR і відкидає макет, структуру таблиць, зображення та просторові відношення. Візуальний пошук документів пропускає цей крок, безпосередньо проєктуючи візуалізовану сторінку в простір подань, де по ній можуть виконувати пошук текстові запити.

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

Навчання сім’ї сумісних між собою моделей

Пошук за своєю суттю є асиметричним: індексація та кодування запиту мають різні операційні обмеження. Індексація виконується офлайн і може бути розпаралелена, тож її обчислювальні витрати амортизуються між багатьма майбутніми пошуками. Кодування запиту виконується онлайн для кожного запиту, що робить його чутливим до затримки та іноді підпорядкованим обмеженням сервісу або edge-пристроїв. Наша сімейство моделей використовує цю асиметрію, пропонуючи розміри, адаптовані до кожного боку конвеєра пошуку.

Ми контрастивно навчаємо вчителя на 18B, а потім окремо дистилюємо його в учнів 9B і 0,6B. Замість того щоб навчати кожного учня лише відтворювати розподіл ранжування вчителя, ми використовуємо дистиляцію подань у стилі LEAF: для кожного вхідного токена ми вирівнюємо вихідне вбудовування учня з учительським. Хоча дистиляцію в просторі подань раніше застосовували для щільних моделей із одним вектором, ми розширюємо її на пізню взаємодію, де ціль вирівнювання — це вектор для кожного збереженого токена.

У результаті обидва опубліковані checkpoints мають спільний багатовекторний простір вбудовувань. Це дає змогу кросмодельному пошуку, роблячи можливими додаткові варіанти розгортання.

• Максимальна якість: кодуйте документи й запити моделлю 9B.
• Максимальна ефективність: кодуйте документи й запити моделлю 0,6B для 100% локального інференсу
• Пошук із низькою затримкою: побудуйте індекс корпусу моделлю 9B, а потім кодуйте живі запити моделлю 0,6B, щоб використати обчислення на етапі індексації й водночас зберегти швидке виконання запитів.
• Локально-хмарний пошук: кодуйте приватні локальні документи або живі запити моделлю 0,6B на пристрої, а потім порівнюйте або об’єднуйте ці подання з результатами з індексу 9B, розміщеного в хмарі.

Для сценаріїв, чутливих до затримки, ми спроєктували модель 0,6B як легкий енкодер запитів, який також може працювати на крайових пристроях. Відштовхуючись від Qwen3.5-0.8B, ми обрізаємо її 24-шаровий текстовий tower до 12 шарів, зменшуючи цей tower з 498 млн до 240 млн параметрів, не пов’язаних із вбудовуванням. У результаті модель має загалом 594 млн параметрів, але її номінальний розмір завищує вартість обслуговування: 100 млн використовуються для кодування зображень, а 254 млн містяться в таблиці токенових вбудовувань, що мало впливає на час виконання. Для кодування тексту активними є лише близько 240 млн параметрів, а для кодування зображень — 340 млн, що дає моделі вартість обслуговування, притаманну значно меншій моделі, водночас зберігаючи сумісність з індексом 9B.

Ми застосували той самий процес, щоб побудувати наш учитель 18B на основі backbone 27B, що зробило дистиляцію з нього значно дешевшою без послаблення сигналу, який він надає.

Багатомовні, мультимодальні, не забруднені тренувальні дані

Ми навчаємо обидві моделі на наборі з 186 мільйонів пар запит-документ, зібраних із 594 датасетів у 46 мовах. Із цих пар 88,3% — текст-в-текст, 8,3% — текст-в-зображення, а 3,4% — текст-в-візуальний документ. Замість того щоб семплювати пропорційно до розміру датасету, ми призначаємо кожному датасету вагу семплювання, що дає більш збалансовану суміш для навчання: відповідно 56,5%, 30,9% і 12,6%.

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

Оцінювання

Ми оцінюємо обидві моделі в текстовому, візуально-документному, змішаному зображенневому та агентному пошуку. Обидві моделі перевершують оцінені базові моделі на Q2D-Web і BrowseComp+, а також демонструють сильні результати у візуально-документному пошуку та MADQA.

Текстовий пошук

Ми оцінюємо пошук текст-в-текст на трьох бенчмарках:

• Доменні бенчмарки: добірка з 72 завдань у стилі MTEB, 55 у п’яти доменах (фінанси, право, охорона здоров’я, розмови, технології), а також 17 різноманітних багатомовних завдань. Добірка включає такі завдання, як FinQA, AILACasedocs і XLSum. Жоден із цих датасетів не входить до наших навчальних даних, як описано вище.
• Q2D-Web: наш вебмасштабний бенчмарк пошуку з приблизно 70 000 запитів, переформульованих агентом, узятих із виробничого пошукового трафіку, по корпусу з 190 млн вебдокументів. Завдяки запитам, схожим на реальні, і великомасштабному корпусу цей бенчмарк вимірює ефективність пошуку в умовах, набагато ближчих до реального вебпошуку, ніж інші доступні бенчмарки пошуку.
• ViDoRe(V3) Markdown: ViDoRe(V3) зазвичай є завданням пошуку текст-в-візуальний документ, але його також можна оцінювати як текстове завдання, використовуючи версію корпусу, перетворену в Markdown, що дає змогу оцінювати пошук насичених інформацією документів як у зображеневій, так і в текстовій модальностях.

Ми вимірюємо продуктивність за допомогою nDCG@10, за винятком Q2D-Web, де повідомляємо Recall@1000 через фокус бенчмарку на сценарії вебпошуку на першому етапі. Упродовж усього оцінювання ми порівнюємося з провідними в галузі моделями вбудовувань різних розмірних класів. Для текстового пошуку nemotron-embed-8b, gemini-embedding-2, voyage-large-4 і qwen3-embed-8b представляють найсильніших і найуживаніших щільних конкурентів, тоді як voyage-4-nano та qwen3-embed-0.6b слугують щільними базовими моделями з менш ніж мільярдом параметрів. Додатково ми порівнюємося з нещодавно випущеними TopK моделями пізньої взаємодії topk-embed-v1 на бенчмарках, для яких TopK опублікувала результати. Результати ViDoRe(V3) взяті з їхніх model cards на 128 вимірах, що відповідає ширині наших токенових вбудовувань; результат Q2D-Web взято з нашого лідерборду.

На доменно-специфічних бенчмарках наші моделі 9B і 0,6B у середньому набирають 81,3% і 78,0% відповідно. Наша модель 9B показує найвищий результат серед усіх моделей, які ми оцінювали, випереджаючи наступну найкращу модель на 1,6 в.п. Наша модель 0,6B є конкурентною з іншими найрезультативнішими моделями, поступаючись лише на 0,3 в.п. моделі gemini-embedding-2. Важливо, що оскільки ми не навчалися на жодних даних для цих бенчмарк-задач, доменно-специфічні бенчмарки демонструють, що наші моделі вбудовувань можуть узагальнювати на нові домени.

Розгорнути

Відносна сила нашої моделі 0,6B ще більша на завданні ViDoRe(V3) Markdown; її результат 61,2% перевищує всі інші моделі, окрім нашої моделі 9B, яка набрала 64,7%. Наступна найкраща зовнішня модель набрала 60,6%, а наступна найкраща модель менш ніж 1B, topk-embed-v1-0.8b, відстала від нашої моделі 0,6B на 4,3 в.п.

Розгорнути

У Q2D-Web релевантність визначається трьома наборами оцінок: документами, які агент цитував (Citation), документами, ранжованими нашою виробничою системою пошуку (Web), і об’єднанням обох, доповненим оцінками LLM для неанотованих документів (Combined). Обидві моделі pplx-embed-v2-late лідирують серед усіх базових моделей на всіх трьох наборах оцінок. Ми зосереджуємося на об’єднаних оцінках, оскільки набори Citation і Web похідні від того, що вже відбирали наші власні системи, і тому надають перевагу моделям, які ранжують так само; додані в Combined оцінки LLM охоплюють документи, які не повернула жодна з систем. На цьому наборі і наша модель 9B, і 0,6B випереджають усіх конкурентів, досягаючи результатів 74,8% і 73,6% відповідно, проти попереднього найкращого результату 69,3%.

Розгорнути

Візуальний пошук

Наш основний бенчмарк візуального пошуку — стандартна публічна підмножина ViDoRe(V3), де корпус складається з візуалізацій сторінок, а не з перетворення в Markdown. Ми порівнюємо з двома провідними щільними моделями візуально-мовного пошуку, qwen3-vl-embed-8b і gemini-embedding-2, а також із моделями пізньої взаємодії topk-embed-v1. Крім того, моделі Tencent EVIE та моделі NVIDIA Nemotron ColEmbed V2 — це багатовекторні базові моделі лише для візуальних даних, спеціально навчені для завдань пошуку зображень.

Обидві наші моделі досягають найкращої в галузі продуктивності для моделей візуально-мовного пошуку. Наша модель 9B у середньому набирає 65,2%, поступаючись лише EVIE. Наша модель 0,6B досягає результату 62,3%, випереджаючи topk-embed-v1-2b і поступаючись лише значно більшим EVIE та nemotron-colembed-v2-8b серед зовнішніх базових моделей.

Розгорнути

Наша модель 0,6B є особливо конкурентною з огляду на розмір моделі. Вона випереджає всі моделі порівнюваного розміру й поступається лише на 1,2 в.п. моделі nemotron-colembed-v2-8b, активуючи лише 340 млн параметрів для вхідних зображень. Наші моделі формують вбудовування розмірністю 128 на токен, порівняно з 2 048 у EVIE-4.5B та 4 096 у EVIE-8B і nemotron-colembed-v2-8b. Ця різниця у витратах на зберігання може кардинально впливати на сценарії, у яких ці моделі практично доцільно використовувати.

Розгорнути

Ми також оцінюємо візуальний пошук на MIRACL-Vision, бенчмарку, корпус якого складається зі скриншотів статей Wikipedia, і PPLX-Q2I — внутрішньому бенчмарку, що охоплює як візуальні документи, так і природні зображення. PPLX-Q2I побудовано на основі виробничих журналів пошуку зображень Perplexity і створено так, щоб відображати різноманітність сценаріїв використання пошуку зображень. Ми використовуємо вибірку з 10 000 запитів, стратифіковану за мовою та доменом, проти корпусу з 100 000 зображень; релевантними документами для кожного запиту є зображення, видані для нього. Ми не оцінювали EVIE-8B або Nemotron ColEmbed на PPLX-Q2I, оскільки індексування корпусу такого розміру на їхніх типовий вихідних розмірностях (2 560 для Nemotron ColEmbed 4B і 4 096 для Nemotron ColEmbed 8B та EVIE-8B) було непрактичним.

Подібно до своєї продуктивності на ViDoRe(V3), наша модель 0,6B є конкурентною з набагато більшими моделями, поступаючись лише на 1 в.п. моделі qwen3-vl-embed-8b на MIRACL-Vision. Наша модель 9B перевершує всі інші моделі, окрім gemini-embedding-2.

На PPLX-Q2I обидві наші моделі випереджають qwen3-vl-embedding-8b більш ніж на 9 в.п., а наша модель 9B відстає від gemini-embedding-2 лише на 2 в.п. Наші результати залишаються конкурентними на корпусах, що містять як природні зображення, так і візуальні документи, тож багатовекторні подання, які дають виграш на ViDoRe(V3), не досягаються ціною погіршення загального пошуку зображень.

Розгорнути

Кросмодельний пошук

Результати в попередніх розділах оцінюють кожну модель щодо корпусу, який вона сама вбудувала. Спільний простір вбудовувань означає, що це не є вимогою: по корпусу, індексованому моделлю 9B, можна виконувати пошук запитами, вбудованими моделлю 0,6B. Саме таку конфігурацію, на нашу думку, використовуватиме більшість промислових розгортань, оскільки індексування — це одноразова витрата, амортизована протягом усього життя корпусу, тоді як вбудовування запитів виконується в критичному для затримки шляху кожного запиту.

Розгортання, яке не може запускати модель 9B під час запиту, інакше також індексувало б моделлю 0,6B, тож симетрична конфігурація 0,6B є релевантною точкою порівняння. Ми оцінюємо на 72 доменно-специфічних бенчмарках, використаних вище, і на пошуку зображень ViDoRe v3. Запити кодуються за допомогою pplx-embed-v2-late-0.6b, і ми змінюємо лише те, що вбудовує корпус.

Індексація моделлю 9B — це безумовне покращення. На доменно-специфічних бенчмарках асиметрична конфігурація в середньому дає приріст 1,6 в.п. На пошуку зображень ViDoRe v3 вона набирає 63,5%, що на 1,2 відсоткового пункту вище, ніж 62,3% при використанні моделі 0,6B з обох боків. Вартість кодування запитів не змінюється між симетричною конфігурацією 0,6B та асиметричною конфігурацією, оскільки в обох випадках запит кодує та сама модель 0,6B; додаткова вартість кодування документів виникає на етапі індексування.

Запуск моделі 9B з обох боків лишається ще кращим, даючи в середньому 81,3% на доменно-специфічних бенчмарках. Отже, асиметрична конфігурація відновлює приблизно половину різниці в якості між двома моделями на тексті, без додаткової вартості кодування запитів. Яку конфігурацію обрати, залежить від того, чи можна дозволити собі модель 9B під час запиту; там, де це неможливо, асиметрична схема захоплює суттєву частину її переваг.

Розгорнути

Агентний пошук

Агентний пошук — це ще один сценарій, у якому багатовекторні вбудовування особливо сильні. У BrowseComp+ LLM (GPT-OSS-120B у нашому випадку) використовує модель вбудовувань для пошуку в корпусі інформації, релевантної складному запиту користувача, а друга LLM оцінює, чи збігається отримана відповідь із еталоном. Наша модель 9B досягає точності 64,0%, випереджаючи наступну найкращу модель ColBERT на 4,9 в.п. і наступну найкращу щільну модель на 8,7 в.п., водночас виконуючи менше пошуків, ніж будь-яка інша модель, окрім нашої 0,6B. Модель 0,6B також випереджає кожну модель поза нашою сім’єю.

Розгорнути

MADQA тестує агентне запитання-відповідь на 800 гетерогенних реальних PDF-файлах, що охоплюють понад 18 000 сторінок, із 500 написаними людьми запитаннями, на які неможливо відповісти з загальних знань. Агент (Gemini 3.5 Flash у нашому випадку) шукає в колекції за допомогою тестованого retriever і оцінюється за точністю відповіді та page F1 відносно анотованих сторінок-доказів. Наша модель 9B встановлює новий state of the art серед retrievers із точністю 92,4%, що на 3,5 в.п. вище, ніж у того самого агента з retriever від Mixedbread; наша модель 0,6B досягає 90,1%. Ми також зазначаємо, що наш retriever показує конкурентні результати проти Mixedbread Agentic Search, який використовує пошукового під-агента у своїй пошуковій системі, що планує та виконує кілька пошуків за один виклик від основного агента (93,4%, у межах нашого довірчого інтервалу).

Розгорнути

Початок роботи

Обидві наші моделі 0,6B і 9B доступні на Hugging Face та з коробки сумісні з sentence-transformers >= 6.0.0 і transformers >= 5.4.0. Додаткові технічні подробиці та повні результати оцінювання буде опубліковано в технічному звіті пізніше цього року.

Наразі ми навчаємо наступне покоління наших моделей щільних ембедингів і поступово додаватимемо на Perplexity API Platform підтримку щільних і контекстних ембедингів, а також ембедингів із пізньою взаємодією.

Цитування

@online{perplexity2026MultimodalEmbeddingsBeyondASingleVector,
  author = {{Perplexity} and Markus Krimmel and Louis Milliken and Antoine Chaffin and Sarah Eslami and Ekaterina Glazkova and Maximilian Schall and Bo Wang and Denis Bykov and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Multimodal embeddings beyond a single vector}},
  date = {2026-10-07},
  url = {https://www.perplexity.ai/hub/blog/multimodal-embeddings-beyond-a-single-vector}
}