Embeddings multimodaux au-delà d’un seul vecteur

Depuis la sortie de pplx-embed-v1 en février, nous travaillons sur une nouvelle génération de modèles de plongement. La semaine dernière, nous avons présenté notre nouveau modèle de plongement contextuel, pplx-embed-v2-context. Aujourd’hui, nous élargissons la famille avec pplx-embed-v2-late, une collection de modèles à interaction tardive. En plus de capacités de recherche plus fortes, ces modèles sont les premiers à combiner trois caractéristiques de base :

• Représentations multivecteurs. Plutôt que de compresser chaque entrée en un seul vecteur, ces modèles conservent des vecteurs au niveau des jetons pour permettre des comparaisons requête-document plus fines. Cela permet à différentes parties d’une requête de correspondre à différentes parties d’un document, en préservant des détails particulièrement précieux pour la recherche multimodale.
• Prise en charge des modalités texte et image. En plus des capacités de recherche texte-à-texte de nos modèles précédents, ces nouveaux modèles prennent en charge la recherche texte-à-image, ce qui leur permet d’interroger directement des pages PDF rendues sans nécessiter d’OCR ni de texte analysé.
• Espace de plongement partagé. Nous publions deux tailles de modèle, 0,6B et 9B, pour répondre à différents besoins en qualité, latence et calcul. Chacune peut être utilisée indépendamment, mais l’espace de plongement partagé permet aussi au plus petit modèle d’interroger un index créé avec le plus grand modèle, combinant des plongements de documents de meilleure qualité avec une inférence à la requête peu coûteuse et rapide.

Ces nouveaux modèles obtiennent des résultats de pointe sur une série de bancs d'essai de recherche visuelle et textuelle, ainsi que sur des tâches agentiques de questions-réponses. Notamment, sur ViDoRe (V3), un banc d'essai de référence en recherche de documents visuels, notre modèle de 0,6 milliard de paramètres obtient des résultats équivalents à ceux de modèles comptant cinq fois plus de paramètres actifs. Les deux modèles sont accessibles au public sur Hugging Face. Notre rapport technique fournit plus de détails sur la méthodologie et les résultats d'évaluation.

Des vecteurs uniques à l’interaction tardive

Les systèmes de recherche doivent trouver un équilibre entre l’efficacité et la profondeur de l’interaction entre les requêtes et les documents. Les modèles d’intégration dense encodent chaque requête et chaque document indépendamment, ce qui permet de les comparer à l’aide d’un simple produit scalaire peu coûteux. Cela rend pratique la recherche approximative des plus proches voisins (ANN) sur des milliards de documents. À l’autre extrême, les cross-encoders traitent la requête et le document ensemble, ce qui permet une interaction plus riche, mais exige un passage avant séparé pour chaque candidat. Appliquer ce calcul sur un vaste corpus de documents pour chaque recherche est prohibitif, si bien que les cross-encoders sont généralement réservés au reclassement d’un petit ensemble de candidats récupérés.

Limites des plongements denses

Représenter un document entier avec un seul vecteur de taille fixe crée un goulot d’étranglement informationnel. À mesure que les documents s’allongent et couvrent davantage de sujets, le modèle doit compresser plus de contenu dans le même vecteur, ce qui rend plus difficile la conservation de tout ce qui est pertinent pour une requête. Le découpage en segments peut réduire cette pression, mais il fragmente le document et peut séparer des informations qui n’ont de sens qu’ensemble, un problème que nous abordons aussi avec notre modèle de plongement contextuel. Ce goulot d’étranglement s’aggrave dans les contextes multimodaux, où la densité d’information des images exige une compression encore plus forte.

La recherche dense à vecteur unique réduit aussi chaque comparaison à un produit scalaire entre deux vecteurs, ce qui limite l’expressivité de la fonction de score. Pour une dimension de plongement fixe et un corpus suffisamment grand, certains schémas de scores entre paires requête-document sont impossibles à produire, quel que soit l’entraînement. Le benchmark LIMIT transforme cette préoccupation théorique en test de stress concret pour la recherche à vecteur unique.

Recherche à interaction tardive

Les modèles à interaction tardive occupent l’espace entre les modèles d’intégration dense, moins coûteux, et les cross-encoders, plus expressifs. Comme les modèles denses, ils encodent les documents indépendamment de la requête, ce qui permet de calculer les représentations des documents hors ligne. Cependant, plutôt que de réduire chaque entrée à un seul vecteur, ils conservent plusieurs vecteurs et utilisent une fonction de score plus riche lorsqu’ils comparent une requête à un document.

Nos modèles pplx-embed-v2-late utilisent une architecture de type ColBERT, produisant des intégrations de 128 dimensions pour chaque jeton de l’entrée. Nous calculons les paires requête-document à l’aide de MaxSim ; pour chaque jeton de requête, le modèle sélectionne le jeton de document ayant le score le plus élevé, et la somme des similarités maximales par jeton produit le score final. Cela permet à différentes parties d’une requête de correspondre à différentes parties d’un document, les correspondances de jetons plus fortes contribuant davantage au score.

Agrandir

Cette expressivité supplémentaire s’accompagne de coûts de stockage et de score des candidats plus élevés. La recherche dense stocke un vecteur par document et attribue un score à un candidat à l’aide d’un seul produit scalaire ; l’interaction tardive stocke des vecteurs pour les jetons du document et évalue de nombreuses similarités jeton à jeton. Le coût augmente avec la longueur du document, si bien que l’interaction tardive requiert un compromis différent en matière d’indexation et de service qu’une recherche ANN à vecteur unique. En contrepartie, elle offre une recherche de première étape plus riche pour les corpus sensibles à la qualité et peut aussi servir d’étape ultérieure dans un pipeline de recherche Web à grande échelle plus vaste.

Un seul modèle, plusieurs modalités

Il a été démontré que cette profondeur d’interaction améliorée est très utile pour diverses tâches, notamment la recherche à long contexte, agentique et hors domaine. Cette différence est particulièrement évidente dans la recherche multimodale, comme le montre la large avance des modèles ColPali sur le tableau de classement ViDoRe(V3).

Les corpus du monde réel ne sont pas composés uniquement de texte propre. Ils se présentent sous forme de PDF, de présentations, de captures d’écran, de pages numérisées, de graphiques et de tableaux. Le pipeline classique analyse ces documents, applique l’OCR ou la génération de légendes, puis recherche dans le texte obtenu, ce qui est coûteux et perte d’information : cela peut introduire des erreurs d’OCR et supprimer la mise en page, la structure des tableaux, les figures et les relations spatiales. La recherche visuelle de documents saute cette étape en projetant directement la page rendue dans l’espace de représentation, où des requêtes textuelles peuvent la rechercher.

Notre nouvelle famille de modèles s’appuie sur les solides performances des modèles multivecteurs pour la recherche multimodale et fait progresser la frontière de Pareto pour les petits modèles sur le benchmark de recherche documentaire le plus utilisé, ViDoRe(V3). Même si nous nous attendons à ce que les rendus de documents soient la forme d’entrée visuelle la plus courante, nos modèles prennent aussi en charge la recherche sémantique d’images naturelles, comme des photographies de paysages.

Former une famille de modèles interopérables

La recherche est fondamentalement asymétrique : l’indexation et l’encodage des requêtes ont des contraintes opérationnelles différentes. L’indexation s’effectue hors ligne et peut être parallélisée, si bien que son coût de calcul est amorti sur de nombreuses recherches futures. L’encodage des requêtes s’effectue en ligne pour chaque demande, ce qui le rend sensible à la latence et parfois soumis à des limites de service ou de périphérique. Notre famille de modèles exploite cette asymétrie en offrant des tailles adaptées à chaque côté du pipeline de recherche.

Nous entraînons un enseignant de 18B de manière contrastive, puis le distillons séparément en étudiants de 9B et de 0,6B. Plutôt que d’entraîner chaque étudiant uniquement à reproduire la distribution de classement de l’enseignant, nous utilisons une distillation de représentation de type LEAF : pour chaque jeton d’entrée, nous alignons l’intégration de sortie de l’étudiant sur celle de l’enseignant. Bien que la distillation dans l’espace de représentation ait déjà été utilisée pour des modèles denses à vecteur unique, nous l’étendons à l’interaction tardive, où la cible d’alignement est un vecteur pour chaque jeton conservé.

En conséquence, les deux points de contrôle publiés partagent le même espace d’intégration multivecteur. Cela permet la recherche intermodèle, rendant possibles des options de déploiement supplémentaires.

• Qualité maximale : encoder les documents et les requêtes avec le modèle 9B.
• Efficacité maximale : encoder les documents et les requêtes avec le modèle 0,6B pour une inférence locale à 100 %.
• Recherche à faible latence : construire l’index du corpus avec le modèle 9B, puis encoder les requêtes en direct avec le modèle 0,6B afin de tirer parti du calcul au moment de l’indexation tout en conservant une recherche rapide.
• Recherche locale–nuage : encoder des documents locaux privés ou des requêtes en direct avec le modèle 0,6B sur l’appareil, puis comparer ou fusionner ces représentations avec les résultats d’un index 9B hébergé dans le nuage.

Pour les contextes sensibles à la latence, nous avons conçu le modèle 0,6B comme un encodeur de requêtes léger pouvant aussi s’exécuter sur des appareils en périphérie. En partant de Qwen3.5-0.8B, nous avons élagué sa tour texte de 24 couches à 12 couches, réduisant cette tour de 498 millions à 240 millions de paramètres hors intégration. Le modèle résultant compte 594 millions de paramètres au total, mais sa taille nominale surestime le coût de service : 100 millions sont utilisés pour l’encodage d’images et 254 millions se trouvent dans la table d’intégration des jetons, ce qui a peu d’effet sur le temps d’exécution. Seuls environ 240 millions de paramètres sont actifs pour l’encodage du texte et 340 millions pour l’encodage des images, ce qui donne au modèle un coût de service comparable à celui d’un modèle beaucoup plus petit, tout en conservant la compatibilité avec l’index 9B.

Nous avons appliqué le même processus pour construire notre enseignant 18B à partir d’un squelette 27B, ce qui a rendu l’enseignant considérablement moins coûteux à distiller, sans affaiblir le signal qu’il fournit.

Données d’entraînement multilingues, multimodales et non contaminées

Nous entraînons les deux modèles sur un ensemble de données de 186 millions de paires requête-document tirées de 594 ensembles de données dans 46 langues. Parmi ces paires, 88,3 % sont texte-à-texte, 8,3 % sont texte-à-image et 3,4 % sont texte-à-document visuel. Plutôt que d’échantillonner proportionnellement à la taille des ensembles de données, nous attribuons à chacun un poids d’échantillonnage, ce qui produit un mélange d’entraînement plus équilibré de 56,5 %, 30,9 % et 12,6 %, respectivement.

Lors de la constitution de nos données d’entraînement, nous excluons tout ensemble de données associé aux benchmarks sur lesquels nous nous évaluons afin de représenter fidèlement nos résultats sans gonfler les scores de benchmark. Cette décision s’accompagne du compromis que certains des ensembles de données que nous avons choisi d’exclure contiennent des données de haute qualité qui pourraient améliorer les performances de notre modèle sur des tâches autres que le benchmark dont ils proviennent. En fin de compte, nous avons choisi d’accepter ce coût : des chiffres fiables sont plus utiles pour nous pendant le développement, et pour les utilisateurs lorsqu’ils comparent des modèles.

Évaluation

Nous évaluons les deux modèles sur la recherche textuelle, de documents visuels, d’images mixtes et agentique. Les deux modèles surpassent les bases de référence évaluées sur Q2D-Web et BrowseComp+, et obtiennent de bons résultats en recherche de documents visuels et sur MADQA.

Recherche textuelle

Nous évaluons la recherche texte-à-texte sur trois benchmarks :

• Benchmarks spécifiques à un domaine : une collection de 72 tâches de type MTEB, dont 55 réparties sur cinq domaines (finance, juridique, santé, conversation, technologie), plus 17 tâches multilingues diverses. La collection comprend des tâches telles que FinQA, AILACasedocs et XLSum. Aucun de ces ensembles de données n’apparaît dans nos données d’entraînement, comme décrit ci-dessus.
• Q2D-Web : notre benchmark de recherche à l’échelle du Web, d’environ 70 000 requêtes de recherche reformulées par un agent, tirées du trafic de recherche de production, sur un corpus de 190 millions de documents Web. Ce benchmark mesure les performances de recherche dans un contexte beaucoup plus proche de la recherche Web réelle que les autres benchmarks de recherche disponibles, en raison de ses requêtes semblables à celles de la production et de son corpus à grande échelle.
• ViDoRe(V3) Markdown : ViDoRe(V3) est généralement une tâche de recherche texte-à-document visuel, mais elle peut aussi être évaluée comme une tâche textuelle à l’aide d’une version du corpus qui a été analysée en Markdown, ce qui nous permet d’évaluer la recherche de documents riches en information dans les modalités image et texte.

Nous mesurons les performances à l’aide du nDCG@10, sauf pour Q2D-Web, où nous rapportons Recall@1000 en raison de l’accent mis par le benchmark sur un scénario de recherche Web en première étape. Tout au long de nos évaluations, nous comparons les modèles aux modèles de représentation vectorielle les plus performants de l’industrie dans différentes classes de taille. Pour la recherche textuelle, nemotron-embed-8b, gemini-embedding-2, voyage-large-4 et qwen3-embed-8b représentent les concurrents denses les plus forts et les plus utilisés, tandis que voyage-4-nano et qwen3-embed-0.6b servent de bases denses à moins d’un milliard de paramètres. Nous comparons également aux modèles d’interaction tardive topk-embed-v1 récemment publiés par TopK, pour les benchmarks sur lesquels TopK a publié des résultats. Les scores ViDoRe(V3) proviennent de leurs fiches de modèle à 128 dimensions, ce qui correspond à la largeur de nos représentations vectorielles de jetons ; le score Q2D-Web provient de notre tableau de classement.

Sur les benchmarks spécifiques à un domaine, nos modèles 9B et 0,6B obtiennent en moyenne 81,3 % et 78,0 %, respectivement. Notre modèle 9B obtient le score le plus élevé de tous les modèles que nous avons évalués, battant le modèle suivant de 1,6 pt de pourcentage. Notre modèle 0,6B est compétitif avec les autres modèles les mieux classés, accusant seulement 0,3 pt de pourcentage de retard sur gemini-embedding-2. Fait important, comme nous n’avons entraîné sur aucune donnée de ces tâches de benchmark, les benchmarks spécifiques à un domaine montrent que nos modèles d’embeddings peuvent généraliser à de nouveaux domaines.

Agrandir

La force relative de notre modèle 0,6B est encore plus grande sur la tâche ViDoRe(V3) Markdown ; son score de 61,2 % dépasse tous les autres modèles à l’exception de notre modèle 9B, qui a obtenu 64,7 %. Le prochain meilleur modèle externe a obtenu 60,6 %, et le prochain meilleur modèle de moins d’un milliard de paramètres, topk-embed-v1-0.8b, accusait 4,3 pts de pourcentage de retard sur notre modèle 0,6B.

Agrandir

Sur Q2D-Web, la pertinence provient de trois ensembles de jugements : les documents cités par l’agent (Citation), les documents classés par notre système de recherche de production (Web) et l’union des deux, enrichie de jugements LLM sur des documents non étiquetés (Combined). Les deux modèles pplx-embed-v2-late dominent toutes les bases de référence sur les trois ensembles de jugements. Nous nous concentrons sur les jugements combinés, car les ensembles Citation et Web sont dérivés de ce que nos propres systèmes ont déjà fait ressortir et favorisent donc les modèles qui les classent comme eux ; les jugements LLM ajoutés dans Combined couvrent des documents qu’aucun des deux systèmes n’a récupérés. Sur cet ensemble, nos modèles 9B et 0,6B surpassent tous les concurrents, avec des scores de 74,8 % et 73,6 %, respectivement, contre le précédent meilleur score de 69,3 %.

Agrandir

Recherche visuelle

Notre principal benchmark de recherche visuelle est le sous-ensemble public standard de ViDoRe (V3), où le corpus se compose d’images de pages rendues plutôt que de la conversion Markdown. Nous le comparons à deux modèles vision-langage à embeddings denses de premier plan, qwen3-vl-embed-8b et gemini-embedding-2, ainsi qu’aux modèles à interaction tardive topk-embed-v1. En outre, les modèles EVIE de Tencent et les modèles Nemotron ColEmbed V2 de NVIDIA sont des bases de référence « vision uniquement » à plusieurs vecteurs, entraînées spécifiquement pour des tâches de recherche d’images.

Nos deux modèles atteignent des performances de pointe pour les modèles vision-langage. Notre modèle 9B obtient une moyenne de 65,2 %, derrière seulement EVIE. Notre modèle 0,6B atteint un score de 62,3 %, devant topk-embed-v1-2b et derrière seulement les beaucoup plus grands EVIE et nemotron-colembed-v2-8b parmi les bases de référence externes.

Agrandir

Notre modèle 0,6B est particulièrement compétitif compte tenu de sa taille. Il devance tous les modèles de taille comparable et se situe à moins de 1,2 pt de pourcentage de nemotron-colembed-v2-8b tout en activant seulement 340 millions de paramètres pour les entrées image. Nos modèles produisent des intégrations de 128 dimensions par jeton, contre 2 048 pour EVIE-4.5B et 4 096 pour EVIE-8B et nemotron-colembed-v2-8b. Cette différence de coûts de stockage peut avoir un effet drastique sur les scénarios où ces modèles sont pratiques à utiliser.

Agrandir

Nous évaluons également la recherche visuelle sur MIRACL-Vision, un benchmark dont le corpus se compose de captures d’écran d’articles Wikipedia, et PPLX-Q2I, un benchmark interne couvrant à la fois des documents visuels et des images naturelles. PPLX-Q2I est construit à partir des journaux de recherche d’images de production de Perplexity et conçu pour refléter la diversité des cas d’utilisation de la recherche d’images. Nous utilisons un échantillon de 10 000 requêtes, stratifié par langue et par domaine, sur un corpus de 100 000 images ; les documents pertinents de chaque requête sont les images qui lui ont été servies. Nous n’avons pas évalué EVIE-8B ni Nemotron ColEmbed sur PPLX-Q2I, car indexer un corpus de cette taille à leurs dimensions de sortie par défaut (2 560 pour Nemotron ColEmbed 4B et 4 096 pour Nemotron ColEmbed 8B et EVIE-8B) était impraticable.

Comme pour ses performances sur ViDoRe(V3), notre modèle 0,6B est compétitif face à des modèles beaucoup plus grands, n’accusant qu’un retard de 1 pt de pourcentage sur qwen3-vl-embed-8b sur MIRACL-Vision. Notre modèle 9B surpasse tous les autres modèles, à l’exception de gemini-embedding-2.

Sur PPLX-Q2I, nos deux modèles battent qwen3-vl-embedding-8b avec une marge de plus de 9 pts de pourcentage, et notre modèle 9B n’accuse qu’un retard de 2 pts de pourcentage sur gemini-embedding-2. Nos résultats demeurent compétitifs sur des corpus qui contiennent à la fois des images naturelles et des documents visuels, de sorte que les représentations multivecteurs qui s’avèrent payantes sur ViDoRe(V3) ne se font pas au détriment de la recherche d’images générale.

Agrandir

Recherche intermodèle

Les résultats des sections précédentes évaluent chaque modèle par rapport à un corpus qu’il a lui-même intégré. L’espace d’intégration partagé fait que ce n’est pas une exigence : un corpus indexé par le modèle 9B peut être recherché avec des requêtes intégrées par le modèle 0,6B. C’est la configuration que nous prévoyons pour la plupart des déploiements en production, puisque l’indexation est un coût ponctuel amorti sur la durée de vie du corpus, tandis que l’intégration des requêtes s’effectue dans le chemin critique de latence de chaque requête.

Un déploiement qui ne peut pas exécuter le modèle 9B au moment des requêtes indexerait sinon aussi avec le modèle 0,6B, de sorte que cette configuration symétrique 0,6B est le point de comparaison pertinent. Nous évaluons par rapport aux 72 benchmarks spécifiques à un domaine utilisés ci-dessus et sur la recherche d’images ViDoRe v3. Les requêtes sont intégrées avec pplx-embed-v2-late-0.6b, et nous ne faisons varier que le modèle qui a intégré le corpus.

Indexer avec le modèle 9B constitue une amélioration nette. Sur les benchmarks spécifiques à un domaine, la configuration asymétrique affiche en moyenne un gain de 1,6 pt de pourcentage. Sur la recherche d’images ViDoRe v3, elle obtient 63,5 %, contre 62,3 % avec le modèle 0,6B des deux côtés, soit un gain de 1,2 point de pourcentage. Le coût d’encodage des requêtes est inchangé entre les configurations symétrique 0,6B et asymétrique, puisque le même modèle 0,6B encode la requête dans les deux cas ; le coût supplémentaire d’encodage des documents est supporté au moment de l’indexation.

Exécuter le modèle 9B des deux côtés reste encore meilleur, avec une moyenne de 81,3 % sur les benchmarks spécifiques à un domaine. La configuration asymétrique récupère donc environ la moitié de l’écart de qualité entre les deux modèles sur le texte, sans coût supplémentaire d’encodage des requêtes. Le choix de la configuration dépend de la question de savoir si le modèle 9B est abordable au moment des requêtes ; lorsqu’il ne l’est pas, la configuration asymétrique capture une part substantielle de son avantage.

Agrandir

Recherche agentique

La recherche agentique est un autre contexte où les intégrations multivecteurs sont particulièrement performantes. Dans BrowseComp+, un LLM (GPT-OSS-120B dans notre cas) utilise le modèle d’intégration pour rechercher dans un corpus des informations pertinentes pour une requête utilisateur complexe, et un deuxième LLM juge si la réponse obtenue correspond à la vérité terrain. Notre modèle 9B atteint une précision de 64,0 %, battant le prochain meilleur modèle ColBERT de 4,9 pts de pourcentage et le prochain meilleur modèle dense de 8,7 pts de pourcentage, tout en effectuant moins de recherches que tout autre modèle à l’exception de notre modèle 0,6B. Le modèle 0,6B devance également tous les modèles extérieurs à notre famille.

Agrandir

MADQA teste des questions-réponses agentiques sur 800 PDF réels hétérogènes totalisant plus de 18 000 pages, avec 500 questions rédigées par des humains qui ne peuvent pas être répondues à partir de connaissances générales. Un agent (Gemini 3.5 Flash dans notre cas) effectue des recherches dans la collection avec le moteur de recherche testé et est évalué sur la précision des réponses et sur le F1 au niveau des pages par rapport aux pages de preuves annotées. Notre modèle 9B établit un nouveau niveau de pointe parmi les moteurs de recherche avec une précision de 92,4 %, soit 3,5 pts de pourcentage de plus que le même agent utilisant le moteur de recherche de Mixedbread ; notre modèle 0,6B atteint 90,1 %. Nous notons également que notre moteur de recherche obtient des résultats compétitifs face à Mixedbread Agentic Search, qui utilise un sous-agent de recherche dans son système de recherche qui planifie et exécute plusieurs recherches par appel à partir de l’agent principal (93,4 %, dans notre intervalle de confiance).

Agrandir

Pour commencer

Nos modèles 0,6B et 9B sont tous deux offerts sur Hugging Face et sont compatibles dès l’installation avec sentence-transformers >= 6.0.0 et transformers >= 5.4.0. Des détails techniques supplémentaires et les résultats d’évaluation complets seront publiés dans un rapport technique plus tard cette année.

Nous entraînons actuellement la prochaine génération de nos modèles de plongements vectoriels denses et déploierons progressivement la prise en charge des plongements à interaction tardive, denses et contextuels sur la plateforme API de Perplexity.

Citation

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