Perplexity pplx-embed-v2-late répartit la recherche multimodale entre une indexation à 9B et des requêtes à 0,6B

Perplexity a publié deux modèles pplx-embed-v2-late avec une répartition notable : un modèle à 9B construit des index plus riches, tandis qu’un modèle à 0,6B gère des requêtes plus rapides. Les deux modèles recherchent du texte, des images et des pages de documents rendues dans le même espace d’embeddings.

Cette association importe davantage que le nombre de paramètres. Les équipes chargées de la recherche choisissent généralement un seul modèle d’embeddings et acceptent partout ses compromis en matière de qualité, de latence et de coûts d’infrastructure. Perplexity propose plutôt de mobiliser davantage de calcul lors de l’entrée des documents dans l’index, puis d’utiliser un encodeur plus petit sur le chemin des requêtes.

Les modèles remettent également en cause le pipeline standard de recherche dans des PDF visuellement complexes. Au lieu d’extraire du texte via OCR, un développeur peut encoder une page rendue et la retrouver avec une requête textuelle. Toutefois, cette approche remplace une partie des coûts d’analyse par des index plus volumineux et un scoring plus coûteux.

Perplexity a publié deux modèles qui fonctionnent comme un seul système de recherche

La publication centrale n’est pas simplement une paire de checkpoints. Il s’agit d’une architecture de recherche asymétrique construite autour d’un espace d’embeddings partagé.

Perplexity a publié les versions 0,6B et 9B de pplx-embed-v2-late sous licence MIT. Les poids sont disponibles via des dépôts de modèles Hugging Face distincts, dont le modèle 0,6B et son homologue 9B plus grand.

Les deux modèles sont des systèmes de recherche multimodale à interaction tardive. L’interaction tardive signifie que les documents et les requêtes sont encodés séparément, mais que leurs vecteurs de tokens individuels interagissent lors du scoring. Cela diffère de la recherche dense, qui réduit habituellement chaque entrée à un seul vecteur.

Chaque modèle produit un vecteur de 128 dimensions par token. Le scoring MaxSim trouve ensuite la correspondance de token de document la plus forte pour chaque token de requête et additionne ces similarités maximales. Différents termes de requête peuvent ainsi correspondre à différentes régions d’une page.

Perplexity a construit cette famille sur des backbones Qwen3.5 avec attention bidirectionnelle. Selon la fiche du modèle, les deux modèles publiés ont été distillés à partir d’un enseignant ColBERT interne de 18B. ColBERT est une architecture de recherche qui préserve les représentations au niveau des tokens pour une comparaison tardive.

L’entreprise a entièrement affiné le plus petit modèle. Pour la version 9B, elle a entièrement entraîné les huit dernières couches de transformeur tout en adaptant les couches restantes et l’encodeur de vision avec LoRA.

Les tailles annoncées nécessitent également du contexte. Le plus petit checkpoint contient environ 594 millions de paramètres au total, mais Perplexity indique 340 millions de paramètres actifs. L’encodage de texte active environ 240 millions de paramètres, tandis que l’encodage d’images en active environ 340 millions.

Perplexity a produit la tour de texte plus petite en élaguant une tour Qwen3.5-0.8B de 24 couches à 12 couches. Sa table d’embeddings de tokens représente 254 millions de paramètres supplémentaires, selon l’entreprise.

Cette construction vise l’économie des requêtes. L’indexation peut s’exécuter hors ligne, sur du matériel parallèle, et uniquement lorsque les documents changent. L’encodage des requêtes se situe sur le chemin de requête en direct, où chaque milliseconde supplémentaire affecte l’expérience utilisateur.

L’espace partagé relie ces deux charges de travail. Une entreprise peut encoder des documents avec le modèle 9B, puis interroger l’index résultant avec des requêtes encodées par le modèle 0,6B. Le remplacement de l’encodeur de requêtes ne nécessite pas de reconstruire cet index.

Perplexity décrit également une configuration locale-cloud. Un appareil pourrait encoder une requête privée ou un document local avec le plus petit modèle, puis comparer cette représentation aux résultats d’un index 9B hébergé dans le cloud.

Cette flexibilité demeure une proposition technique plutôt qu’une promesse de produit géré. La fiche du modèle indique que les checkpoints fonctionnent avec des versions récentes de Sentence Transformers et Transformers. Elle précise également qu’aucun fournisseur d’inférence ne sert actuellement le plus petit checkpoint.

Perplexity indique que les embeddings à interaction tardive, denses et contextuels arriveront progressivement sur sa plateforme API. D’ici là, les équipes évaluant pplx-embed-v2-late devraient supposer qu’elles devront exploiter elles-mêmes les modèles et l’infrastructure de recherche.

Le mécanisme de Perplexity pplx-embed-v2-late préserve le détail des pages

Perplexity parie que la correspondance au niveau des tokens peut conserver des éléments de preuve qu’un unique vecteur de document compresse souvent.

Un modèle d’embeddings dense représente une requête et un document par un vecteur chacun. La recherche devient une recherche efficace de plus proches voisins, ce qui fonctionne bien sur de très grandes collections. Pourtant, le vecteur doit résumer chaque détail potentiellement pertinent.

Cette compression devient plus difficile à mesure que les documents s’allongent ou contiennent des sections sans rapport. Elle devient encore plus difficile lorsque les pages incluent des graphiques, tableaux, diagrammes, légendes et une signification dépendante de la mise en page. Une représentation unique dispose d’un espace limité pour tous ces signaux.

Le découpage réduit la quantité d’information placée dans chaque vecteur. Toutefois, il peut séparer un tableau de son libellé, un graphique de sa légende ou une clause d’une qualification importante. Les règles d’analyse varient aussi selon les formats de documents.

Un cross-encoder traite une partie du problème en traitant ensemble une requête et un candidat. Cette attention conjointe permet des comparaisons détaillées, mais le modèle doit s’exécuter de nouveau pour chaque paire requête-candidat. Il n’est généralement pratique que pour réordonner une courte liste de candidats.

L’interaction tardive occupe une position intermédiaire. Les documents reçoivent toujours leurs représentations avant l’arrivée d’une requête. Le système de recherche effectue ensuite plusieurs comparaisons au niveau des tokens au lieu de calculer un produit interne par candidat.

L’explication technique de Perplexity illustre la méthode avec MaxSim. Chaque token de requête sélectionne sa meilleure correspondance de token de document, et le système ajoute ces similarités dans un score de document.

Prenons une requête portant sur une loi, une échéance et une exception. Un vecteur de requête unique mélange ces concepts. MaxSim peut faire correspondre chaque concept à un passage, un libellé ou une région visuelle distincte au sein de la même page.

Le même mécanisme s’applique aux images. Une page PDF rendue entre dans l’encodeur de vision comme une image au lieu de passer d’abord par OCR. Une requête textuelle peut ensuite retrouver directement la représentation visuelle.

Cela ne signifie pas que le modèle « lit » un fichier PDF sans préparation. L’application doit rendre chaque page pertinente sous forme d’image et encoder cette image. La distinction concerne la manière dont la représentation interrogeable est produite.

Ignorer l’OCR peut préserver des relations de mise en page et visuelles que l’extraction de texte perd. Les positions des lignes et colonnes d’un tableau financier peuvent porter une signification essentielle. Un diagramme peut communiquer des relations que sa légende ne décrit que partiellement.

La recherche sans OCR peut également éviter les erreurs de reconnaissance sur des numérisations, des polices inhabituelles et des structures de page complexes. Toutefois, elle ne fournit pas automatiquement du texte extrait pour la mise en évidence, les citations, les contrôles d’accès ou le contexte destiné à un modèle de langage en aval.

De nombreuses applications conserveront donc l’analyse parallèlement à la recherche visuelle. Les embeddings visuels peuvent identifier une page prometteuse, tandis que l’OCR ou le texte PDF natif fournit ensuite des passages exacts. Les techniques peuvent se compléter.

Perplexity a entraîné les deux modèles sur 186 millions de paires requête-document issues de 594 jeux de données et de 46 langues. L’entreprise indique que 88,3 % étaient des paires texte-à-texte, 8,3 % des paires texte-à-image et 3,4 % des paires texte-à-document-visuel.

Le mélange d’échantillonnage a accru la présence relative des données visuelles. Perplexity affirme que ses pondérations d’échantillonnage finales ont produit 56,5 % d’exemples texte-à-texte, 30,9 % texte-à-image et 12,6 % texte-à-document-visuel.

Ces détails comptent, car « multimodal » couvre plusieurs problèmes différents. Retrouver une photographie n’est pas identique à trouver des éléments de preuve dans une page dense de rapport annuel. L’équilibre de l’entraînement influence les cas d’usage qui bénéficient de la représentation la plus robuste.

La fiche du modèle publiée précise également une contrainte d’implémentation. Les éléments uniquement textuels et uniquement visuels nécessitent des appels d’encodage distincts, et les entrées mixtes texte-plus-image ne sont pas prises en charge dans un même élément. Les applications doivent concevoir leur ingestion en conséquence.

Les embeddings partagés mettent sous pression les pipelines de recherche à modèle unique

La pression concurrentielle s’exerce sur les systèmes de recherche qui utilisent une seule taille d’encodeur pour l’indexation hors ligne comme pour les requêtes sensibles à la latence.

La plupart des déploiements d’embeddings traitent le modèle comme un composant uniforme. Le même checkpoint encode un corpus et chaque requête entrante. Cette symétrie simplifie les opérations, mais elle ignore les économies différentes de ces tâches.

L’encodage de documents constitue généralement une dépense amortie. Une entreprise peut traiter une page une fois, puis répondre à des milliers de recherches sur sa représentation stockée. Elle peut planifier l’indexation sur du matériel plus puissant ou regrouper le travail en lots.

L’encodage des requêtes se répète pour chaque recherche. Il affecte le temps de réponse, la concurrence et la faisabilité sur appareil. Exécuter un grand encodeur vision-langage pour chaque requête peut annuler les gains obtenus lors de l’indexation hors ligne.

L’espace partagé de Perplexity sépare ces choix. Le modèle 9B peut mobiliser davantage de calcul pour capturer l’information des documents, tandis que le modèle 0,6B produit des requêtes compatibles. L’index conserve une partie du bénéfice du plus grand encodeur de documents.

Dans l’évaluation de Perplexity sur 72 tâches de recherche spécifiques à des domaines, la configuration asymétrique a gagné en moyenne 1,6 point de pourcentage par rapport à l’utilisation de 0,6B des deux côtés. L’encodeur de requêtes est resté inchangé.

Pour la recherche d’images ViDoRe v3, la configuration avec requêtes 0,6B et documents 9B a obtenu 63,5 % de nDCG@10. La configuration symétrique à 0,6B a obtenu 62,3 %, soit une différence de 1,2 point.

L’utilisation du modèle 9B à la fois pour les requêtes et les documents a tout de même produit la meilleure moyenne de domaine rapportée, à 81,3 %. Perplexity indique que la configuration asymétrique a comblé environ la moitié de l’écart de qualité textuelle sans augmenter l’encodage au moment de la requête.

C’est l’argument le plus pratique de cette publication. Le plus petit modèle n’a pas besoin d’égaler seul chaque résultat du 9B. Il doit seulement rendre un index 9B de haute qualité utile sous des contraintes de service plus strictes.

L’approche met sous pression les modèles denses standard, mais elle concurrence également d’autres systèmes de recherche multi-vecteurs. Perplexity compare ses modèles à Qwen3-VL-Embedding, EVIE, TopK Embed et à la famille Nemotron ColEmbed de Nvidia.

Sur la partie publique de recherche d’images de ViDoRe v3, Perplexity indique 65,2 % de nDCG@10 pour le modèle 9B et 62,3 % pour le modèle 0,6B. Les scores markdown correspondants étaient de 64,7 % et 61,2 %.

Perplexity affirme que le modèle 0,6B est arrivé à 1,2 point de Nemotron ColEmbed V2 8B sur la recherche d’images. L’entreprise souligne également que ses sorties utilisent 128 dimensions par token.

Cette comparaison de dimensions concerne directement la faisabilité des index. Perplexity indique des dimensions de sortie de 2 048 pour EVIE-4.5B et de 4 096 pour les modèles EVIE et Nemotron plus grands. Moins de dimensions peuvent réduire la taille de chaque vecteur de token stocké.

Les dimensions seules ne déterminent pas le coût de production. Le nombre de tokens conservés, la précision numérique, la méthode de compression, la structure de l’index et la stratégie de génération des candidats comptent également. Perplexity n’a pas publié de calcul complet de stockage pour des corpus représentatifs.

L’alternative ne disparaît pas. La recherche dense reste plus facile à indexer et à interroger à une échelle immense. Les cross-encoders demeurent attrayants pour le réordonnancement. La recherche lexicale hybride protège toujours les identifiants exacts, les noms et les termes techniques rares.

Pplx-embed-v2-late a donc davantage vocation à devenir une étape d’une pile de récupération qu’un remplacement universel. Perplexity décrit lui-même la late interaction comme une première étape de récupération plus riche ou comme une étape ultérieure dans des systèmes à l’échelle du web.

Pour les équipes qui construisent une base de connaissances interrogeable, la question de conception devient plus précise. Elles doivent déterminer quels documents justifient une indexation visuelle à vecteurs multiples et lesquels restent efficaces avec une récupération textuelle.

Les résultats des benchmarks sont solides, mais restent communiqués par l’entreprise

Les scores publiés justifient des tests sérieux, mais ne tranchent pas la question de la latence réelle, du stockage ou de la qualité de récupération.

Perplexity annonce un score d’exactitude des réponses de 64,0 % pour le modèle 9B sur BrowseComp+. Ce résultat dépasse le modèle ColBERT suivant de 4,9 points de pourcentage et le modèle dense suivant de 8,7 points.

BrowseComp+ utilise un corpus fixe plutôt qu’une recherche web en direct. Sa conception du benchmark comprend 830 requêtes difficiles et environ 100 000 documents web sélectionnés, accompagnés d’éléments de preuve vérifiés par des humains.

Une collection fixe améliore la reproductibilité. Les chercheurs peuvent séparer la qualité de récupération des évolutions des moteurs de recherche commerciaux ou du web ouvert. Elle rend également le benchmark plus étroit que l’exploitation d’un index web vivant et en évolution continue.

Perplexity a associé son récupérateur à GPT-OSS-120B avec un niveau d’effort élevé. Un autre modèle de langage a évalué si la réponse générée correspondait à la référence. Le score annoncé de 64,0 % mesure donc un système agent-récupérateur, et non un score d’embedding isolé.

L’entreprise affirme que le modèle 0,6B a également dépassé tous les modèles hors de la famille pplx-embed-v2-late. Toutefois, l’annonce ne fournit pas tous les scores sous-jacents sous forme de texte consultable. Le rapport technique complet doit être publié ultérieurement.

Sur MADQA, Perplexity annonce une exactitude des réponses de 92,4 % pour son récupérateur 9B et de 90,1 % pour le modèle 0,6B. Les deux ont été associés à Gemini 3.5 Flash.

MADQA évalue la recherche agentique à travers des PDF hétérogènes. L’article MADQA décrit 2 250 questions rédigées par des humains et ancrées dans 800 documents, tandis que l’évaluation annoncée utilise un sous-ensemble de 500 questions.

Perplexity indique que ce sous-ensemble couvre plus de 18 000 pages. Les questions ne peuvent pas être résolues à partir de connaissances générales ; l’agent doit donc récupérer des éléments de preuve dans la collection de documents.

Le résultat du modèle 9B dépasse de 3,5 points un récupérateur Mixedbread standard associé au même agent. Mixedbread Agentic Search a atteint 93,4 %, un score que Perplexity affirme situé dans son intervalle de confiance.

Cette distinction est importante. Mixedbread Agentic Search inclut un sous-agent de recherche capable de planifier et d’exécuter plusieurs recherches pour chaque appel externe. Pplx-embed-v2-late fonctionne comme un récupérateur au sein de l’agent, plutôt que comme un service complet de recherche agentique.

Les auteurs de MADQA soulignent également une limite plus large des agents documentaires. Leur étude conclut que des systèmes performants peuvent approcher l’exactitude humaine tout en réussissant sur des questions différentes. Les agents compensent souvent une stratégie faible par des recherches répétées.

Un meilleur récupérateur peut réduire ce gaspillage, mais il ne peut pas garantir une bonne planification des recherches ni une bonne synthèse des preuves. L’exactitude de récupération, l’exactitude des réponses, la qualité des preuves au niveau des pages, la latence et le nombre d’appels aux outils doivent tous être évalués séparément.

Perplexity annonce également de solides résultats sur ViDoRe v3. Ce benchmark public offre aux développeurs une vision plus directe de la récupération de pages que les tests de génération de réponses. Les collections de benchmarks ne peuvent toutefois pas reproduire tous les formats de documents d’entreprise.

Les corpus réels comportent des doublons, des restrictions d’accès, des révisions, des annotations manuscrites, des numérisations basse résolution et des pages à la mise en page presque identique. Ils comportent aussi des abréviations propres à un domaine qui peuvent être absentes des mélanges de données d’entraînement généraux.

Le benchmark interne PPLX-Q2I introduit une autre lacune de vérification. Perplexity l’a construit à partir de journaux de production de recherche d’images et a évalué 10 000 requêtes sur 100 000 images. Les chercheurs externes ne peuvent pas encore reproduire ce test privé.

Perplexity affirme que les deux modèles ont dépassé Qwen3-VL-Embedding-8B de plus de neuf points sur PPLX-Q2I. L’entreprise indique également que le modèle 9B se situait environ deux points derrière Gemini Embedding 2. Ces conclusions doivent rester attribuées à l’entreprise.

La sortie mérite l’attention, car les poids et les points de contrôle des benchmarks publics permettent des tests indépendants. Elle ne mérite pas d’être automatiquement considérée comme la meilleure option pour tous les corpus.

Les développeurs devraient constituer un jeu d’évaluation à partir de leurs propres documents et requêtes réelles. Il devrait inclure des recherches exactes, des preuves réparties sur plusieurs pages, des tableaux visuels, une terminologie obscure et des négatifs volontairement difficiles.

Ils devraient également comparer des systèmes complets équivalents. Une configuration ne devrait pas bénéficier d’un meilleur OCR, de davantage de cycles de recherche ou d’un reranker plus puissant, sauf si ces différences représentent la conception de production visée.

La recherche multi-vecteur déplace les coûts au lieu de les supprimer

Pplx-embed-v2-late évite un goulot d’étranglement de compression en acceptant des représentations plus volumineuses et une évaluation des candidats plus complexe.

La récupération dense stocke un vecteur pour chaque document ou segment. La late interaction conserve plusieurs vecteurs, souvent un pour chaque token non élagué. Une page longue peut donc produire de nombreuses représentations interrogeables.

Même à 128 dimensions, ces vecteurs s’accumulent. Le stockage de l’index dépend du nombre de tokens, du format numérique, du schéma de compression, des métadonnées et du moteur de récupération. Les représentations visuelles au niveau des pages peuvent encore modifier ce calcul.

MaxSim demande également davantage de travail qu’un seul produit scalaire requête-document. Chaque token de requête doit identifier sa correspondance la plus forte parmi les tokens du document. Un service efficace nécessite une indexation spécialisée, de l’élagage ou une récupération par étapes.

Perplexity reconnaît ce compromis dans son annonce. L’entreprise indique que la late interaction exige des choix d’indexation et de service différents de ceux de la récupération approximative des plus proches voisins à vecteur unique. Les documents plus longs augmentent le coût.

L’espace de modèle partagé facilite l’encodage des requêtes, mais n’efface pas les coûts d’évaluation des candidats. Un encodeur de requêtes léger peut toujours produire une requête coûteuse à comparer avec des millions de vecteurs de tokens.

Les équipes devraient donc mesurer quatre composantes de latence distinctes : l’encodage de la requête, la génération des candidats, le scoring MaxSim et le reranking ou la génération en aval. Ne rapporter que le temps d’inférence du modèle masque une grande partie de l’expérience utilisateur.

L’utilisation de la mémoire exige également une mesure attentive. Le checkpoint 9B peut être un composant hors ligne, mais l’indexation d’un corpus fréquemment modifié peut encore nécessiter une capacité GPU persistante. Le réencodage des révisions de documents ajoute du travail opérationnel.

Un pipeline de documents visuels requiert le rendu des pages avant l’inférence du modèle. Les PDF volumineux nécessitent une pagination, une normalisation des images, une gestion des échecs, un mappage des métadonnées et des workflows de suppression. L’OCR peut disparaître de la récupération, mais l’ingestion demeure un problème de système.

L’OCR conserve aussi des avantages. Le texte extrait permet la recherche par mots-clés, la mise en évidence, les citations, l’examen de conformité et le contexte direct pour les modèles de langage. Un embedding de page rendue ne peut pas reproduire ces fonctions à lui seul.

La conception de production la plus probable est hybride. Un système peut indexer le texte natif pour une récupération exacte, conserver des embeddings visuels pour les pages sensibles à la mise en page et utiliser un reranker sur un ensemble limité de candidats.

Le contrôle des accès mérite une attention égale. Les index de récupération doivent filtrer les contenus non autorisés avant que les résultats n’atteignent un agent. Un espace d’embedding partagé entre local et cloud n’assure pas automatiquement les autorisations sur les documents ni les garanties de confidentialité.

Le chemin de requête proposé sur l’appareil soulève d’autres questions. Perplexity présente le modèle 0,6B comme adapté aux appareils edge, mais les catégories d’appareils varient fortement. Les limites de mémoire, la prise en charge de l’accélération, la quantification et l’autonomie détermineront la faisabilité réelle.

Le checkpoint publié utilise des tenseurs F32 sur sa page Hugging Face. Les développeurs testeront probablement des variantes de moindre précision ou propres à certaines plateformes, mais ces conversions exigent des contrôles de qualité. La quantification peut modifier les classements de récupération.

La compatibilité constitue une autre préoccupation à ce stade précoce. La fiche du modèle exige Sentence Transformers 6.0 ou une version ultérieure, et Transformers 5.4 ou une version ultérieure. Elle avertit aussi que PyLate insère les marqueurs de requête et de document à une position différente.

L’export utilise des modules Sentence Transformers natifs et ne requiert pas de code Python personnalisé. Cela réduit les frictions d’intégration, mais ne fournit pas un index de production complet ni un endpoint géré.

Les licences sont relativement simples. La licence MIT permet une utilisation et une modification étendues. Les adoptants doivent néanmoins examiner les dépendances du modèle, les considérations liées aux données d’entraînement et leur propre traitement des documents sensibles.

Le terme « open source » peut aussi masquer des distinctions importantes. Perplexity a publié les poids ouverts et les instructions d’implémentation, mais n’a pas publié le corpus d’entraînement complet ni le teacher interne 18B.

L’entreprise indique avoir exclu de l’entraînement les jeux de données liés aux benchmarks évalués. Il s’agit d’une affirmation méthodologique utile, mais les chercheurs indépendants ont besoin du rapport technique promis pour examiner les contrôles de contamination et les détails de l’évaluation.

La conclusion prudente n’est pas que la late interaction coûte trop cher. C’est que la dépense se déplace. Les équipes échangent la dépendance à l’OCR et la compression à vecteur unique contre des index plus riches, un scoring au niveau des tokens et une infrastructure plus spécialisée.

Trois signaux montreront si cette conception dépasse les benchmarks

Le prochain test consiste à déterminer si des déploiements indépendants peuvent reproduire les gains de qualité sans stockage, latence ou complexité opérationnelle inacceptables.

Le premier signal sera une évaluation indépendante des poids publiés. Les chercheurs et les fournisseurs de solutions de récupération peuvent désormais comparer les deux modèles sur des tâches publiques de documents visuels et des corpus industriels privés.

La reproduction devrait couvrir la configuration asymétrique, et non seulement les tests symétriques à 0,6B et 9B. L’affirmation centrale repose sur le fait que les requêtes du petit modèle conservent leur valeur face à un index du grand modèle.

Si des résultats indépendants confirment les gains annoncés sur des documents juridiques, financiers, techniques et numérisés, la conception de Perplexity deviendra un modèle de déploiement crédible. Des baisses de qualité importantes affaibliraient l’argument de l’espace partagé.

Le deuxième signal sera un rapport technique complet avec des mesures d’index. Perplexity indique que ce rapport arrivera plus tard cette année. Il devrait divulguer les paramètres de récupération, la compression, le matériel, la latence et le stockage par token de document.

Le rapport devrait également expliquer les intervalles de confiance, le filtrage des données d’entraînement et la configuration du benchmark. Ces détails montreront si les gains d’exactitude annoncés résistent à des limites de ressources comparables.

Le stockage est particulièrement important, car la dimension de sortie n’est qu’une variable. Un vecteur de token à 128 dimensions semble compact face à une alternative à 4 096 dimensions, mais la taille totale de l’index dépend du nombre de tokens conservés.

Le troisième signal sera le support produit. Perplexity indique qu’il ajoutera progressivement à sa plateforme API des embeddings de late interaction, denses et contextuels. Un endpoint géré révélerait comment l’entreprise regroupe les compromis d’indexation et de service.

La prise en charge par API élargirait également les tests au-delà des équipes capables d’exploiter une infrastructure GPU personnalisée. L’adoption restera plus limitée si les utilisateurs doivent assembler eux-mêmes le rendu, l’indexation, la recherche MaxSim et la montée en charge.

Le déploiement devrait clarifier si les clients peuvent associer des index de documents 9B à des requêtes 0,6B au moyen d’un seul service géré. Cette configuration est l’idée opérationnelle la plus forte de cette sortie.

La tarification n’est pas encore une comparaison utile, et aucun chiffre ne devrait être déduit des précédents services d’embedding de Perplexity. Le stockage et le scoring multi-vecteurs diffèrent considérablement des embeddings textuels à vecteur unique.

Les réponses des concurrents comptent également, mais elles constituent des éléments de preuve secondaires plutôt que le test principal. Qwen, Nvidia, Google, Mixedbread et d’autres fournisseurs de solutions de retrieval peuvent améliorer la qualité, réduire les dimensions ou proposer des systèmes managés plus simples.

L’avantage de Perplexity ne reposera pas sur un seul instantané de classement. Il dépendra de la capacité de l’espace partagé à réduire les coûts des requêtes en production tout en préservant une part suffisante de la qualité de retrieval de l’indexeur plus grand.

Pour les développeurs, l’action immédiate consiste à mener une évaluation circonscrite. Constituez un corpus représentatif, rendez les pages visuellement complexes et conservez une base de référence textuelle. Comparez ensuite les configurations symétriques et asymétriques avec le même budget de retrieval.

Mesurez la précision des réponses, le rappel des pages contenant les preuves, la taille de l’index, le débit d’ingestion, la latence des requêtes et les cas d’échec. Incluez les pipelines OCR et hybrides, car le retrieval visuel n’élimine pas toutes les raisons d’analyser le texte.

Perplexity pplx-embed-v2-late avance une hypothèse claire : l’encodage des documents et l’encodage des requêtes ne devraient pas partager le même budget de calcul. Les poids ouverts permettent de tester cette hypothèse.

La question qui demeure est opérationnelle, non conceptuelle. Un index de 9B et un chemin de requête de 0,6B peuvent-ils surpasser un retrieval plus simple une fois pris en compte le stockage, le scoring, les mises à jour, les autorisations et l’extraction de preuves en aval ?