Perplexity publie deux modèles late interaction pour rechercher dans les pages PDF sans OCR

Perplexity a mis en ligne sur Hugging Face la collection pplx-embed-v2, qui contient deux modèles pplx-embed-v2-late. Ils reposent sur le principe de la late interaction et recherchent dans les pages de documents comme dans des images. La page entière, avec ses tableaux, ses graphiques et sa mise en page, est convertie en embeddings, et l'étape de reconnaissance de texte (OCR) disparaît du pipeline. Le blog de Qdrant, daté du 13 octobre 2026, désigne d'emblée le point faible de cette publication : le retriever visuel de Perplexity pose un problème de taille, que l'équipe de Qdrant affirme avoir résolu. Le fragment disponible ne détaille pas cette solution ; nous séparons donc ci-dessous les faits établis des hypothèses raisonnables.

Pourquoi rechercher par page plutôt que par texte

Un chiffre dans un rapport financier, sans ligne, sans colonne ni unité de mesure, ne signifie rien. Un graphique sans légende non plus. Le pipeline classique extrait le texte du PDF via l'OCR, le découpe en fragments, puis l'indexe. La structure s'effondre alors : la cellule d'un tableau se retrouve détachée de l'en-tête de sa colonne, la légende d'un axe de l'axe lui-même.

Perplexity propose une autre voie. Le modèle reçoit l'image de la page et l'encode en entier. Le tableau reste un tableau, le graphique reste un graphique. La requête cherche sa correspondance dans la page telle qu'un humain la voit. Pour les corpus de rapports, de présentations et de spécifications techniques, cela supprime toute une couche d'erreurs : plus besoin de régler l'OCR en fonction des polices, des langues et des scans.

Où se pose le problème de taille

La late interaction fonctionne autrement que la recherche classique à un seul vecteur par document. Dans des schémas comme ColBERT et ColPali, une page est représentée par un ensemble de vecteurs, et la pertinence se calcule en comparant chaque vecteur de la requête au meilleur vecteur de la page (MaxSim). La précision est meilleure, mais il faut stocker non pas un vecteur par page, mais beaucoup. C'est un principe général de cette classe de modèles, et non une donnée issue de la publication. La dimension et le nombre de vecteurs par page ne sont pas indiqués dans le texte disponible.

C'est pourquoi le titre évoquant un « problème de taille » se lit comme un problème de volume de l'index multivecteur. C'est une déduction, pas une citation. Sur un corpus de millions de pages, la différence entre un vecteur et des centaines de vecteurs par page se traduit en écarts de mémoire, de coût de serveurs et de latence de recherche. Qdrant prend en charge le stockage multivecteur depuis longtemps, son intérêt pour le sujet se comprend donc aisément. Pour savoir comment l'équipe a réduit la taille, il faut consulter la version complète de l'article.

Ce que l'on sait à ce jour

• Éditeur : Perplexity, collection pplx-embed-v2 sur Hugging Face
• Modèles : deux modèles late interaction pplx-embed-v2-late
• Entrée : image de la page du document
• Éléments encodés : tableaux, diagrammes, mise en page
• OCR : non requis
• Source de l'analyse : blog de Qdrant, 13 octobre 2026
• Non précisé dans le fragment : dimension des embeddings, nombre de vecteurs par page, résultats de benchmarks, licence, méthode de compression

Ce qu'il faut vérifier avant le déploiement

Il ne faut pas basculer la recherche en production sur des embeddings visuels avant d'avoir chiffré plusieurs points.

1. Combien de vecteurs le modèle produit par page, et quelle quantité de mémoire votre corpus occupera à cette densité. Multipliez le nombre de pages par la taille du multivecteur et comparez le résultat à votre budget.

2. Comment se comporte la qualité sur vos propres documents. Prenez 50–100 requêtes réelles portant sur des tableaux et des graphiques et comparez les résultats avec la solution de référence : OCR plus embeddings textuels.

3. Si votre base vectorielle prend en charge nativement les multivecteurs et MaxSim. Sinon, vous devrez construire vous-même le recalcul.

4. Quelle méthode de compression est appliquée et quel est son effet sur la qualité. Toute réduction de l'index doit être vérifiée sur ces mêmes requêtes, sans se fier aux moyennes.

Si le corpus est de taille modeste et que les tableaux et diagrammes y tiennent la première place, le retriever visuel peut déjà être testé. Si vous avez des millions de pages, ce n'est pas la qualité qui sera décisive, mais la réussite de la compression de l'index.