Мультимодальные embedding-и за пределами одного вектора

Новая семейство моделей позднего взаимодействия для поиска по тексту и изображениям с общим embedding-пространством между размерами моделей.

АвторыPerplexity Research

С момента выпуска pplx-embed-v1 в феврале мы работали над новым поколением embedding-моделей. На прошлой неделе мы представили нашу новую контекстную embedding-модель, pplx-embed-v2-context. Сегодня мы расширяем семейство с помощью pplx-embed-v2-late — набора моделей позднего взаимодействия. Помимо более сильных возможностей поиска, эти модели первыми объединяют три ключевые особенности:

  • Мультивекторные представления. Вместо того чтобы сжимать каждый вход в один вектор, эти модели сохраняют векторы на уровне токенов для более детального сравнения запроса и документа. Это позволяет разным частям запроса сопоставляться с разными частями документа, сохраняя детализацию, особенно ценную для мультимодального поиска.
  • Поддержка как текстовой, так и визуальной модальностей. Помимо возможностей поиска «текст к тексту» в наших предыдущих моделях, эти новые модели поддерживают поиск «текст к изображению», позволяя напрямую искать по отрендеренным страницам PDF без необходимости OCR или извлеченного текста.
  • Общее embedding-пространство. Мы выпускаем две размерности моделей, 0,6B и 9B, чтобы поддерживать разные требования к качеству, задержке и вычислениям. Каждую можно использовать независимо, но общее embedding-пространство также позволяет меньшей модели выполнять запрос к индексу, созданному большей моделью, объединяя более качественные embedding-и документов с дешевым и быстрым выводом на этапе запроса.

Новые модели показывают передовые результаты в целом ряде бенчмарков визуального и текстового поиска, а также в агентных задачах ответа на вопросы. Примечательно, что в ViDoRe (V3), одном из ведущих бенчмарков визуального поиска документов, наша модель с 0,6 млрд параметров не уступает моделям, у которых в пять раз больше активных параметров. Обе модели находятся в открытом доступе на Hugging Face. Подробнее о методологии и результатах оценки читайте в нашем техническом отчёте.

От одиночных векторов к позднему взаимодействию

Системы поиска должны находить баланс между эффективностью и глубиной взаимодействия между запросами и документами. Плотные embedding-модели кодируют каждый запрос и документ независимо, позволяя сравнивать их с помощью дешевого скалярного произведения. Это делает практичным приближенный поиск ближайших соседей (ANN) по миллиардам документов. На другом полюсе cross-encoder'ы обрабатывают запрос и документ вместе, обеспечивая более богатое взаимодействие, но требуя отдельного прямого прохода для каждого кандидата. Применение этого вычисления ко всему большому корпусу документов при каждом поиске чрезмерно дорого, поэтому cross-encoder'ы обычно используют только для повторного ранжирования небольшого набора найденных кандидатов.

Ограничения плотных embedding-ов

Представление всего документа одним вектором фиксированного размера создает информационное узкое место. По мере того как документы становятся длиннее и охватывают больше тем, модели приходится сжимать больше содержимого в тот же вектор, и становится труднее сохранить все, что релевантно запросу. Разбиение на фрагменты может снизить это давление, но оно фрагментирует документ и может разъединить информацию, которая имеет смысл только вместе; эту проблему мы также решаем с помощью нашей контекстной embedding-модели. Это узкое место усугубляется в мультимодальных сценариях, где высокая плотность информации в изображениях требует еще более сильного сжатия.

Плотный поиск по одному вектору также сводит каждое сравнение к скалярному произведению двух векторов, ограничивая выразительность функции оценки. При фиксированной размерности embedding-а и достаточно большом корпусе некоторые паттерны оценок по парам запрос–документ невозможно получить независимо от обучения. Бенчмарк LIMIT превращает эту теоретическую проблему в конкретный стресс-тест для поиска по одному вектору.

Поиск с поздним взаимодействием

Модели позднего взаимодействия занимают пространство между более дешевыми плотными embedding-моделями и более выразительными cross-encoder'ами. Как и плотные модели, они кодируют документы независимо от запроса, что позволяет вычислять представления документов офлайн. Однако вместо того чтобы сводить каждый вход к одному вектору, они сохраняют несколько векторов и используют более богатую функцию оценки при сравнении запроса с документом.

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

Пример оценки MaxSim: каждый токен запроса выбирает токен документа с наивысшей оценкой, а максимальные сходства на уровне токенов суммируются в итоговую оценку сходства между запросом и документом.

Эта дополнительная выразительность сопровождается более высокими затратами на хранение и оценку кандидатов. При плотном поиске хранится один вектор на документ и кандидат оценивается одним скалярным произведением; при позднем взаимодействии хранятся векторы токенов документа и вычисляется множество сходств между токенами. Стоимость растет с длиной документа, поэтому позднее взаимодействие требует иного компромисса между индексированием и обслуживанием, чем поиск по одному вектору с ANN. Взамен оно обеспечивает более богатый первый этап поиска для корпусов, чувствительных к качеству, а также может служить более поздним этапом в более крупном поисковом пайплайне веб-масштаба.

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

Было показано, что эта улучшенная глубина взаимодействия очень полезна для различных задач, включая поиск с длинным контекстом, агентный поиск и поиск вне домена. Это различие особенно заметно в мультимодальном поиске, что видно по значительному отрыву моделей ColPali в лидерборде ViDoRe(V3).

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

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

Обучение семейства совместимых моделей

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

Мы обучаем 18B teacher контрастивно, а затем отдельно дистиллируем его в студентов 9B и 0,6B. Вместо того чтобы обучать каждого студента только воспроизводить распределение ранжирования teacher-модели, мы используем дистилляцию представлений в стиле LEAF: для каждого входного токена мы выравниваем выходное embedding-представление студента с представлением teacher-модели. Хотя дистилляция в пространстве представлений ранее использовалась для плотных моделей с одним вектором, мы распространяем ее на позднее взаимодействие, где целью выравнивания является вектор для каждого сохраняемого токена.

В результате оба опубликованных checkpoint-а используют одно и то же мультивекторное embedding-пространство. Это обеспечивает кросс-модельный поиск, открывая дополнительные варианты развертывания.

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

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

Мы применили тот же процесс, чтобы построить наш 18B teacher на основе backbone-а 27B, что сделало teacher значительно дешевле для дистилляции, не ослабив предоставляемый им сигнал.

Многоязычные, мультимодальные, очищенные от утечки тренировочные данные

Мы обучаем обе модели на наборе данных из 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 из-за того, что бенчмарк ориентирован на сценарий первого этапа веб-поиска. На протяжении всей оценки мы сравниваемся с ведущими в отрасли embedding-моделями разных классов по размеру. Для поиска по тексту 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 измерениях, что соответствует ширине наших embedding-ов токенов; оценка Q2D-Web взята из нашей таблицы лидеров.

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

Результаты доменно-специфичного поиска по тексту, измеренные метрикой nDCG@10. Среднее значение взвешивает шесть доменов поровну, а в скобках указано число задач в каждой группе.

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

Поиск по тексту на общедоступном подмножестве ViDoRe v3 после преобразования изображений страниц в Markdown с помощью OCR. Наша модель 0,6B в среднем занимает второе место, уступая только нашей модели 9B по среднему nDCG@10.

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

Веб-масштабный поиск по тексту на Q2D-Web, измеренный Recall@1000 по оценкам релевантности Citation, Web и Combined. Обе модели превосходят оцененные базовые модели во всех трех наборах оценок.

Визуальный поиск

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

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

Визуальный поиск документов на общедоступном подмножестве ViDoRe v3, измеренный nDCG@10. Обе модели Perplexity лидируют среди оцененных мультимодальных базовых моделей; модели только для зрения показаны отдельно.

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

Качество поиска изображений ViDoRe v3 в зависимости от числа активных параметров модели в логарифмической шкале. Линии соединяют границу Парето внутри каждой панели: модели, которые не превосходятся моделью того же или меньшего размера.

Мы также оцениваем визуальный поиск на MIRACL-Vision, бенчмарке, корпус которого состоит из скриншотов статей Википедии, и 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), не достигаются ценой ухудшения общего поиска изображений.

Поиск изображений на MIRACL-Vision и PPLX-Q2I, измеренный nDCG@10. Модели Nemotron ColEmbed не оценивались на PPLX-Q2I, поскольку индексирование корпуса при их стандартной размерности выхода было непрактичным.

Кросс-модельный поиск

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

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

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

Запуск модели 9B на обеих сторонах по-прежнему дает лучший результат: в среднем 81,3% на доменно-специфичных бенчмарках. Таким образом, асимметричная конфигурация восстанавливает примерно половину разницы в качестве между двумя моделями для текста, не увеличивая стоимость кодирования запросов. Выбор конфигурации зависит от того, доступна ли модель 9B на этапе запроса; если нет, асимметричная схема обеспечивает значительную часть ее преимуществ.

Индексирование с помощью модели 9B и запросы с помощью модели 0,6B улучшают поиск по сравнению с использованием модели 0,6B для обоих этапов. Показатели — nDCG@10; среднее по шести доменам не включает отдельно показанные результаты ViDoRe v3.

Агентный поиск

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

Точность ответов BrowseComp+ и полнота поиска в зависимости от среднего числа поисков для агента GPT-OSS-120B (высокие усилия). Более высокие показатели и меньшее число поисков означают лучшее качество и эффективность.

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

Точность ответов и F1 на уровне страниц в MADQA. В связке с Gemini 3.5 Flash наши модели 9B и 0,6B достигают точности 92,4% и 90,1% соответственно, по сравнению с 88,9% у поисковика Mixedbread и 93,4% у Mixedbread Agentic Search.

Начало работы

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

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

Цитирование

BibTeX
@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}
}