Des embeddings multimodaux au-delà d’un simple vecteur

Depuis la publication de pplx-embed-v1 en février, nous travaillons sur une nouvelle génération de modèles d’embeddings. La semaine dernière, nous avons présenté notre nouveau modèle d’embeddings 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 renforcées, ces modèles sont les premiers à combiner trois fonctionnalités essentielles :

• Représentations multi-vecteurs. Plutôt que de compresser chaque entrée en un seul vecteur, ces modèles conservent des vecteurs au niveau des tokens pour 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 à la fois 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 gèrent la recherche texte-à-image, ce qui leur permet d’interroger directement des pages PDF rendues sans nécessiter d’OCR ni de texte analysé.
• Un espace d’embeddings partagé. Nous publions deux tailles de modèles, 0,6B et 9B, pour répondre à différents besoins en qualité, latence et calcul. Chaque modèle peut être utilisé indépendamment, mais l’espace d’embeddings partagé permet aussi au plus petit modèle d’interroger un index créé avec le plus grand, en combinant des embeddings de documents de meilleure qualité avec une inférence au moment de la requête peu coûteuse et rapide.

Ces nouveaux modèles obtiennent des résultats de pointe sur un ensemble de benchmarks de recherche visuelle et textuelle, ainsi que sur des tâches agentiques de questions-réponses. Sur ViDoRe (V3), benchmark de référence pour la recherche de documents visuels, notre modèle de 0,6 milliard de paramètres égale notamment des modèles comptant cinq fois plus de paramètres actifs. Les deux modèles sont accessibles publiquement sur Hugging Face. Notre rapport technique détaille 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 efficacité et profondeur d’interaction entre les requêtes et les documents. Les modèles d’embeddings denses encodent chaque requête et chaque document indépendamment, ce qui permet de les comparer à l’aide d’un simple produit scalaire. Cela rend praticable la recherche ANN (approximate nearest-neighbor) sur des milliards de documents. À l’autre extrême, les cross-encoders traitent ensemble la requête et le document, ce qui permet une interaction plus riche mais exige un passage avant séparé pour chaque candidat. Appliquer ce calcul à un vaste corpus de documents pour chaque recherche est prohibitivement coûteux, si bien que les cross-encoders sont généralement réservés au reranking d’un petit ensemble de candidats récupérés.

Limites des embeddings denses

Représenter un document entier avec un seul vecteur de taille fixe crée un goulot d’étranglement de l’information. À 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 préservation 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 que prises ensemble, un problème que nous traitons aussi avec notre modèle d’embeddings contextuel. Ce goulot d’étranglement s’aggrave dans les contextes multimodaux, où la densité d’information des images exige encore plus de compression.

La recherche dense à vecteur unique réduit aussi chaque comparaison à un produit scalaire entre deux vecteurs, limitant l’expressivité de la fonction de score. Pour une dimension d’embedding fixe et un corpus suffisamment vaste, certains motifs 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 un test de résistance concret pour la recherche à vecteur unique.

Recherche à interaction tardive

Les modèles à interaction tardive occupent l’espace entre les modèles d’embeddings denses, 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 lors de la comparaison d’une requête avec un document.

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

Agrandir

Cette expressivité supplémentaire s’accompagne de coûts de stockage et d’évaluation des candidats plus élevés. La recherche dense stocke un vecteur par document et évalue un candidat avec un seul produit scalaire ; l’interaction tardive stocke des vecteurs pour les tokens de document et évalue de nombreuses similarités token à token. Le coût croît avec la longueur du document, si bien que l’interaction tardive nécessite un compromis différent en matière d’indexation et de service qu’une recherche ANN à vecteur unique. En retour, elle offre une recherche de première étape plus riche pour les corpus sensibles à la qualité et peut aussi servir à un stade ultérieur dans un pipeline de recherche web à grande échelle plus large.

Un modèle, plusieurs modalités

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

Les corpus du monde réel ne se composent pas uniquement de texte propre. Ils arrivent sous forme de PDF, de diaporamas, de captures d’écran, de pages numérisées, de graphiques et de tableaux. Le pipeline conventionnel analyse ces documents, applique de l’OCR ou de la génération de légendes, puis recherche dans le texte obtenu, ce qui est coûteux et source de pertes : cela peut introduire des erreurs d’OCR et élimine la mise en page, la structure des tableaux, les figures et les relations spatiales. La recherche documentaire visuelle 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 multi-vecteurs 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). Bien que nous nous attendions à 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 sur des 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, de sorte que son coût de calcul est amorti sur de nombreuses recherches futures. L’encodage des requêtes s’exécute en ligne pour chaque requête, ce qui le rend sensible à la latence et parfois soumis à des limites de service ou d’appareils en périphérie. Notre famille de modèles exploite cette asymétrie, en proposant des tailles adaptées à chaque côté du pipeline de recherche.

Nous entraînons d’abord un enseignant de 18B de manière contrastive, puis nous 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 à la manière de LEAF : pour chaque token d’entrée, nous alignons l’embedding de sortie de l’étudiant avec celui 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 ici à l’interaction tardive, où la cible d’alignement est un vecteur pour chaque token conservé.

Ainsi, les deux checkpoints publiés partagent le même espace d’embeddings multi-vecteurs. Cela permet la recherche intermodèles et rend 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 gardant des requêtes rapides.
• Recherche locale-cloud : encoder sur l’appareil des documents privés locaux ou des requêtes en direct avec le modèle 0,6B, puis comparer ou fusionner ces représentations avec les résultats d’un index 9B hébergé dans le cloud.

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

Nous avons appliqué le même processus pour construire notre enseignant 18B à partir d’un backbone 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 issues de 594 jeux de données dans 46 langues. Parmi ces paires, 88,3 % sont texte-à-texte, 8,3 % texte-à-image et 3,4 % texte-à-document visuel. Plutôt que d’échantillonner proportionnellement à la taille des jeux 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 jeu de données associé à des benchmarks sur lesquels nous évaluons, afin de représenter fidèlement nos résultats sans gonfler les scores de benchmark. Ce choix implique un compromis : certains des jeux 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. Au final, nous avons choisi d’assumer ce coût : des chiffres fiables nous sont plus utiles pendant le développement, et aux utilisateurs lorsqu’ils comparent des modèles.

Évaluation

Nous évaluons les deux modèles sur la recherche textuelle, la recherche de documents visuels, la recherche mixte d’images et la recherche agentique. Les deux modèles surpassent les bases évaluées sur Q2D-Web et BrowseComp+, et obtiennent de solides 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, tech), plus 17 tâches multilingues diverses. La collection inclut des tâches comme FinQA, AILACasedocs et XLSum. Aucun de ces jeux de données n’apparaît dans nos données d’entraînement, comme indiqué plus haut.
• Q2D-Web : notre benchmark de recherche à l’échelle du web composé d’environ 70 000 requêtes de recherche reformulées par l’Agent, issues du trafic de recherche en production, sur un corpus de 190 M de documents web. Ce benchmark mesure les performances de recherche dans un contexte bien plus proche de la recherche web réelle que les autres benchmarks de recherche disponibles, grâce à ses requêtes proches de la production et à son corpus à grande échelle.
• ViDoRe(V3) Markdown : ViDoRe(V3) est généralement une tâche de recherche texte-vers-document visuel, mais il peut aussi être évalué comme une tâche textuelle en utilisant une version du corpus qui a été analysée en Markdown, ce qui nous permet d’évaluer la recherche de documents riches en informations à la fois en modalité image et en modalité texte.

Nous mesurons les performances avec nDCG@10, sauf sur Q2D-Web, où nous rapportons Recall@1000 en raison de l’accent mis par le benchmark sur un scénario de recherche web de première étape. Tout au long de nos évaluations, nous comparons nos résultats à ceux de modèles d’embeddings de référence dans l’industrie, répartis en 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 de moins d’un milliard de paramètres. Nous comparons en outre aux modèles à interaction tardive topk-embed-v1 récemment publiés par TopK sur les benchmarks pour lesquels TopK a publié des résultats. Les scores ViDoRe(V3) sont repris de leurs model cards à 128 dimensions, ce qui correspond à la largeur de nos embeddings de tokens ; le score Q2D-Web est repris de notre 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 meilleur score de tous les modèles que nous avons évalués, battant le modèle suivant de 1,6 point de pourcentage. Notre modèle 0,6B est compétitif avec les autres modèles les mieux notés, avec seulement 0,3 point de pourcentage de retard sur gemini-embedding-2. Fait important, comme nous n’avons entraîné sur aucune des données de ces tâches de benchmark, ces 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 % bat tous les autres modèles à l’exception de notre modèle 9B, qui a obtenu 64,7 %. Le meilleur modèle externe suivant a obtenu 60,6 %, et le meilleur modèle de moins d’1B suivant, topk-embed-v1-0.8b, accuse un retard de 4,3 points de pourcentage 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 en 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 arrivent en tête de toutes les bases 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 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 battent tous les concurrents, avec des scores respectifs de 74,8 % et 73,6 %, contre un 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 nous comparons à deux grands modèles vision-langage de pointe, 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 multi-vecteurs « vision-only » entraînées spécifiquement pour les 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 65,2 % en moyenne, n’étant devancé que par EVIE. Notre modèle 0,6B obtient un score de 62,3 %, devant topk-embed-v1-2b et n’étant devancé que par les bien plus grands EVIE et nemotron-colembed-v2-8b parmi les bases externes.

Agrandir

Notre modèle 0,6B est particulièrement compétitif au regard de la taille du modèle. Il devance tous les modèles de taille comparable et n’est qu’à 1,2 point de pourcentage de nemotron-colembed-v2-8b tout en activant seulement 340 M de paramètres pour les entrées image. Nos modèles produisent des embeddings de 128 dimensions par token, contre 2 048 pour EVIE-4.5B et 4 096 pour EVIE-8B et nemotron-colembed-v2-8b. Cette différence de coût de stockage peut modifier radicalement les scénarios dans lesquels ces modèles sont pratiques à utiliser.

Agrandir

Nous évaluons aussi la recherche visuelle sur MIRACL-Vision, un benchmark dont le corpus se compose de captures d’écran d’articles Wikipedia, et sur 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 en production de Perplexity et conçu pour refléter la diversité des cas d’usage de 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.

De même que pour ses performances sur ViDoRe(V3), notre modèle 0,6B est compétitif face à des modèles bien plus grands, avec seulement 1 point de pourcentage de retard 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 plus de 9 points de pourcentage d’avance, et notre modèle 9B n’est en retard que de 2 points de pourcentage sur gemini-embedding-2. Nos résultats restent compétitifs sur des corpus qui contiennent à la fois des images naturelles et des documents visuels, de sorte que les représentations multi-vecteurs qui font la différence sur ViDoRe(V3) ne se font pas au détriment de la recherche d’images générale.

Agrandir

Recherche intermodèles

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’embeddings partagé signifie que ce n’est pas une exigence : un corpus indexé par le modèle 9B peut être interrogé avec des requêtes intégrées par le modèle 0,6B. C’est la configuration que nous attendons de la plupart des déploiements en production, car 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’exécute sur le chemin critique en latence de chaque requête.

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

Indexer avec le modèle 9B constitue une amélioration stricte. Sur les benchmarks spécifiques à un domaine, la configuration asymétrique gagne en moyenne 1,6 point 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 la configuration symétrique 0,6B et la configuration asymétrique, puisque c’est le même modèle 0,6B qui 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 mieux, 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 en 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 de la requête ; lorsqu’il ne l’est pas, la configuration asymétrique capture une part substantielle de son bénéfice.

Agrandir

Recherche agentique

La recherche agentique est un autre contexte où les embeddings multi-vecteurs sont particulièrement performants. Dans BrowseComp+, un LLM (GPT-OSS-120B dans notre cas) utilise le modèle d’embeddings pour rechercher dans un corpus des informations pertinentes pour une requête utilisateur complexe, et un second LLM juge si la réponse obtenue correspond à la vérité de référence. Notre modèle 9B atteint une précision de 64,0 %, battant le meilleur modèle ColBERT suivant de 4,9 points de pourcentage et le meilleur modèle dense suivant de 8,7 points 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 la question-réponse agentique sur 800 PDF réels hétérogènes couvrant plus de 18 000 pages, avec 500 questions rédigées par des humains qui ne peuvent pas être répondues à partir des connaissances générales. Un Agent (Gemini 3.5 Flash dans notre cas) interroge la collection avec le récupérateur testé et est évalué sur la précision des réponses et sur le F1 par page par rapport aux pages de preuve annotées. Notre modèle 9B établit un nouveau niveau de pointe parmi les récupérateurs avec une précision de 92,4 %, 3,5 points de pourcentage devant le même Agent utilisant le récupérateur de Mixedbread ; notre modèle 0,6B atteint 90,1 %. Nous notons également que notre récupérateur obtient des résultats compétitifs face à Mixedbread Agentic Search, qui utilise un sous-agent de recherche dans son système de recherche pour planifier et exécuter plusieurs recherches par appel depuis l’Agent principal (93,4 %, dans notre intervalle de confiance).

Agrandir

Pour commencer

Nos modèles 0,6B et 9B sont tous deux disponibles sur Hugging Face et sont compatibles immédiatement 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 d'embeddings denses et déploierons progressivement la prise en charge des embeddings à interaction tardive, denses et contextuels sur la Perplexity API Platform.

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://perplexity.coolkeypoint.com/hub/blog/multimodal-embeddings-beyond-a-single-vector}
}