Sentence Transformers 6.0 ajoute les MultiVectorEncoder, une API unifiée pour exploiter les modèles de late interaction de type ColBERT. Voici ce que cette approche apporte à la recherche sémantique, et ce qu’elle coûte réellement en infrastructure.
Un embedding dense résume habituellement un document entier dans un seul vecteur. C’est rapide, pratique à indexer et suffisamment efficace pour une grande partie des cas d’usage. Mais cette compression a un défaut structurel : elle peut diluer le détail qui rend un résultat pertinent, qu’il s’agisse d’un identifiant produit, d’une contrainte précise ou d’un passage décisif au milieu d’un document long.
Avec sa version 6.0, Sentence Transformers ajoute un quatrième type de modèle : MultiVectorEncoder. L’objectif est de rendre les modèles d’embeddings multi-vecteurs, aussi appelés modèles de late interaction ou modèles de style ColBERT, accessibles depuis la même bibliothèque Python que les encodeurs denses, clairsemés et les rerankers. Pour une équipe qui travaille sur la recherche sémantique ou le RAG, ce n’est pas un simple changement d’API : c’est une option technique supplémentaire, avec un compromis très net entre qualité de recherche et coût d’indexation.
Les modèles multi-vecteurs préservent une représentation par token au lieu de condenser un texte dans un unique vecteur. Ils peuvent mieux traiter les requêtes à critères multiples et les correspondances exactes, mais leur index est nettement plus volumineux sans compression adaptée.
Pourquoi un vecteur unique peut perdre l’information utile
Un modèle dense lit un texte puis produit un vecteur de taille fixe, par exemple 384, 768 ou 1 024 dimensions. La comparaison entre une requête et un document se fait alors, en substance, par un produit scalaire entre ces deux résumés numériques.
Le mécanisme fonctionne bien, mais il oblige le modèle à faire tenir tous les signaux du texte dans une seule représentation. La source illustre cette limite avec une recherche de canapé vert, à pieds en bois et coussins arrondis. Dans un vecteur global, chacune de ces propriétés doit être agrégée ; un canapé vert aux mauvais pieds peut donc être jugé artificiellement proche du résultat attendu.
Le problème devient plus sensible quand la requête contient plusieurs contraintes, quand le corpus comporte des documents longs, ou lorsque la pertinence dépend d’un élément rare : numéro de référence, nom propre, nom de fonction, clause contractuelle. Ce ne sont pas des garanties de performance universelles : la source décrit des situations où la late interaction peut améliorer la récupération, pas un classement chiffré valable pour tous les jeux de données.
Late interaction : conserver les tokens et les comparer au dernier moment
Un modèle multi-vecteurs ne réalise pas le pooling final qui transforme les représentations de tokens en un seul vecteur. Il conserve plutôt un vecteur par token, après projection dans une dimension plus petite — 128 dimensions étant la configuration classique évoquée par Hugging Face.
Un document de neuf tokens n’est donc plus représenté par un vecteur de 128 dimensions, mais par une matrice de neuf vecteurs de 128 dimensions. Les documents restent encodables indépendamment, et peuvent être préparés hors ligne pour être indexés. C’est ce qui différencie l’approche d’un cross-encoder : ce dernier traite la requête et le document ensemble, ce qui peut être précis mais empêche de pré-calculer les représentations des documents pour chaque nouvelle requête.
La late interaction se situe entre ces deux extrêmes. Elle garde la préparation indépendante des documents propre aux bi-encodeurs, tout en réintroduisant davantage d’interactions entre requête et document lors du calcul du score.
MaxSim : chaque terme de la requête cherche sa meilleure preuve
Le score utilisé est l’opérateur MaxSim. Pour chaque token de la requête, le système cherche le token du document dont la similarité est la plus élevée. Il additionne ensuite ces meilleurs scores.
MaxSim(Q, D) = somme, pour chaque token q de Q, de max(d dans D) q · dLes vecteurs de tokens étant normalisés selon la source, chaque produit scalaire correspond à une similarité cosinus comprise entre -1 et 1. Le score final dépend donc notamment du nombre de tokens dans la requête ; il ne faut pas le lire comme une probabilité ni comparer aveuglément son amplitude entre des requêtes de longueurs différentes.
Cette méthode crée une forme d’alignement souple. Chaque terme de la requête trouve le meilleur élément de preuve dans le document. La correspondance n’est pas seulement lexicale : l’exemple fourni indique que, avec le modèle lightonai/mLateOn, le terme anglais live peut s’aligner avec inhabit dans un contexte sur les manchots. En parallèle, une référence exacte n’est pas noyée dans un résumé global : elle reste représentée au niveau du token.
Le coût à anticiper : l’index grossit vite
Le revers est direct : un index multi-vecteurs stocke beaucoup plus de vecteurs. Sur l’exemple de 4 874 passages Natural Questions rapporté dans la source, le modèle lightonai/LateOn produit 608 414 vecteurs de tokens, soit 124,8 vecteurs par passage en moyenne.
- Un index dense
all-MiniLM-L6-v2occupe 7,5 Mo en float32 dans cet exemple. - Un index dense
gte-modernbert-baseoccupe 15 Mo. - L’index multi-vecteurs LateOn non compressé atteint 311,5 Mo.
Dans cette comparaison, le stockage est environ 42 fois supérieur à celui de MiniLM. Ce chiffre ne doit toutefois pas être appliqué mécaniquement à ton corpus : longueur des documents, dimension, précision numérique et stratégie d’indexation changent fortement le résultat.
La source mentionne l’index fast-plaid, qui compresse les vecteurs en stockant un identifiant de centroïde et un résidu quantifié. Sur le même jeu de données, les 608 414 vecteurs passeraient à 92 Mo. Elle cite aussi le token pooling, qui réduit le nombre de vecteurs avant l’indexation, ainsi qu’une stratégie de récupération suivie d’un reranking pour éviter la construction d’un index multi-vecteurs complet dans certains scénarios.
Ce que Sentence Transformers 6.0 simplifie pour ton stack
L’intérêt pratique de cette mise à jour est l’unification. Selon Hugging Face, MultiVectorEncoder charge directement les checkpoints PyLate et Stanford-NLP ColBERT. Les modèles colpali-engine sont également utilisables pour la recherche visuelle dans des documents, via une API familière pour les utilisateurs de Sentence Transformers.
La recherche visuelle mérite une attention particulière : la source indique que les modèles multi-vecteurs constituent l’état de l’art pour comparer une requête textuelle à des images de pages directement, sans étape OCR intermédiaire. Elle ne fournit en revanche ni protocole de benchmark, ni mesures de précision ou de latence dans l’extrait fourni. Avant d’en déduire un gain pour tes propres PDF, factures ou catalogues, il faut donc évaluer le modèle sur un échantillon représentatif.
Pour tester la fonctionnalité, l’installation annoncée est simplement :
pip install -U sentence-transformersCommence par un corpus limité et des requêtes réelles. Mesure séparément la qualité des résultats, la latence de recherche, le temps d’encodage et le poids de l’index. Si tes recherches dépendent souvent de plusieurs attributs précis ou de références exactes, les embeddings multi-vecteurs méritent un test sérieux. Si ton enjeu premier est le coût par requête ou l’empreinte mémoire minimale, un bi-encodeur dense associé à un reranker restera souvent une architecture plus simple à opérer.