Choisir son modèle d’embedding

A chaque requête que vous tapez dans un moteur de recherche, un système transforme vos mots en un vecteur de nombres, une représentation mathématique du sens. Ce vecteur est un embedding. Le modèle d’embedding que vous choisissez décide si les documents pertinents apparaissent en tête des résultats, ou se perdent dans le bruit. Avec des centaines de modèles disponibles, dont beaucoup s’appuient sur de grands modèles de langage (LLM, large language models), aucun choix universel ne tient : tout dépend de votre tâche, de votre domaine et de vos contraintes. La méthode en sept étapes qui suit vous guide de la définition de votre besoin jusqu’à la surveillance dans le temps.

1. Partez de votre tâche, pas du classement

Le point de départ n’est pas un leaderboard (un classement comparatif de modèles). C’est votre besoin concret. Les embeddings servent à des tâches variées: recherche d’information (retrieval), classification de textes, regroupement thématique (clustering), évaluation de similarité sémantique (STS, semantic textual similarity), ou encore extraction de paires bilingues ^[1]. Un modèle peut exceller sur l’une de ces tâches tout en échouant sur les autres.

Le benchmark MTEB (Massive Text Embedding Benchmark) l’a démontré de façon frappante: SimCSE, un modèle reconnu pour sa performance sur les tâches de similarité sémantique, obtient des résultats médiocres en clustering et en retrieval ^[2]. Pourtant, avant MTEB, c’était l’un des modèles les plus recommandés, précisément parce que les évaluations courantes ne testaient que la similarité sémantique.

Concrètement, avant toute recherche de modèle, listez vos tâches par ordre de priorité. Si votre système doit d’abord retrouver des documents pertinents à partir d’une requête, le retrieval est votre tâche principale. Si vous regroupez des textes par thème sans labels préalables, c’est du clustering. Si vous mesurez la proximité de sens entre deux phrases, c’est du STS. Chaque tâche oriente le choix vers des modèles différents.

2. Cherchez d’abord un modèle spécialisé dans votre domaine

Avant de parcourir les classements généralistes, posez-vous une question simple: existe-t-il déjà un modèle entraîné sur des données de votre domaine?

Les gains peuvent être considérables. BAM embeddings, un modèle entraîné spécifiquement pour la finance sur 14,3 millions de paires requête-passage, atteint un Recall@1 (la proportion de requêtes où le document pertinent arrive en première position) de 62,8% sur un jeu de test, contre seulement 39,2% pour le meilleur modèle généraliste d’OpenAI ^[3]. En physique, PhysBERT a été entraîné sur 1,2 million d’articles publiés sur arXiv et évalué sur des tâches de recherche d’information, de classification et de similarité sémantique adaptées au domaine ^[4]. L’absence même d’un embedding dédié à la physique était identifiée comme un manque critique avant sa création ^[4].

Que faire : recherchez si un modèle pré-entraîné existe dans votre secteur (finance, droit, médecine, physique, chimie, etc.). Les dépôts comme Hugging Face en recensent des milliers. Dans les domaines testés, un modèle de domaine entraîné sur des données spécialisées surpasse nettement un modèle généraliste ^[4][3].

3. Utilisez MTEB comme filtre, pas comme verdict

Si aucun modèle de domaine n’existe, ou si vous voulez comparer plusieurs options, le benchmark MTEB est votre meilleur outil de présélection. Voici ce qu’il couvre:

Au total, MTEB évalue 8 familles de tâches sur 58 datasets, dont 10 multilingues couvrant 112 langues ^[2]. L’API est volontairement simple: le modèle reçoit une liste de textes et renvoie un vecteur par texte, ce qui permet de tester des architectures très différentes avec la même interface ^[2].

Comment lire le classement. Ne vous fiez pas au score global moyen. Un modèle peut afficher un score moyen élevé tout en étant médiocre sur votre tâche principale (c’est exactement le cas de SimCSE ^[2]). Filtrez par la ou les colonnes qui correspondent à votre usage. Si vous faites du retrieval, classez par score retrieval. Si vous faites du clustering, classez par score clustering.

Ce que MTEB ne dit pas. Le benchmark ne couvre pas tous les cas réels. Si vos documents sont très longs, très techniques, ou dans une langue peu représentée, les scores MTEB ne garantissent rien. C’est un filtre puissant, pas un verdict définitif.

4. Pas de labels ? Estimez l’adéquation avec FLARE

Dans de nombreux projets, annoter des données pour évaluer un embedding est trop coûteux ou tout simplement impossible. FLARE (Flow-based Label-free Assessment of Representation Embeddings), une méthode publiée en 2025 par des chercheurs de HKUST, propose une solution: évaluer un modèle d’embedding sur votre corpus cible sans aucune annotation ^[8].

Le principe. Au lieu de comparer des distances entre vecteurs (ce qui devient instable en grande dimension), FLARE utilise un normalizing flow, un modèle probabiliste léger qui apprend la distribution de vos données. La qualité d’un embedding est mesurée par son « information suffisante », c’est-à-dire la quantité d’information que les vecteurs contiennent sur le texte source, estimée directement par la log-vraisemblance du flow ^[8]. L’erreur d’estimation dépend de la dimension intrinsèque de la variété de vos données, pas de la dimension brute des vecteurs, ce qui rend la méthode fiable même sur des embeddings de grande taille ^[8].

Les résultats publiés sont solides: sur 11 datasets et 8 modèles d’embedding testés, le classement obtenu par FLARE corrèle fortement avec les classements supervisés, avec un coefficient de Spearman (une mesure de corrélation de rang) moyen de 0,70 et jusqu’à 0,90 ^[8]. Concrètement, FLARE retrouve exactement le top 3 supervisé sur 4 datasets sur 11, et au moins 2 des 3 meilleurs modèles sur 10 datasets sur 11 ^[8]. La seule exception est un dataset où les trois meilleurs scores supervisés sont séparés par moins d’un point d’accuracy, un écart que même une évaluation supervisée ne départage pas de manière fiable ^[8].

La robustesse est également démontrée: le classement reste stable quand on injecte du bruit dans les paramètres du flow (variation de la log-vraisemblance médiane inférieure à 0,03% avec un bruit modéré) ^[8]. Le test de stabilité par bootstrap montre que le coefficient de corrélation minimum reste positif sur chaque dataset ^[8]. De plus, 20 à 40% des données de validation suffisent à reproduire le classement obtenu sur l’ensemble complet ^[8].

En pratique: si vous n’avez pas de labels mais disposez de votre corpus cible, entraînez un normalizing flow sur les embeddings de vos données pour chaque modèle candidat, comparez les log-vraisemblances, et retenez le modèle le plus performant. La démarche demande un volume de données modéré et aucun annotateur humain.

5. Intégrez vos contraintes opérationnelles

Un modèle performant sur un benchmark mais trop lent ou trop coûteux pour votre infrastructure est un mauvais choix. Trois dimensions méritent d’être évaluées avant la décision finale.

La dimension des vecteurs. Plus un vecteur est long, plus il consomme de mémoire et de temps de calcul lors de la recherche. Des techniques de compression réduisent cet impact: la quantisation par produit (Product Quantization) peut comprimer un index de 13,5 Go à 840 Mo avec une perte de performance inférieure à 1% dans les expériences menées sur Natural Questions ^[9]. Les vecteurs binaires comme BPR (Binary Passage Retriever) réduisent chaque dimension à un seul bit ^[9]. Le format MRL (Matryoshka Representation Learning) permet d’adapter la dimension du vecteur à la volée, réduisant la taille de la représentation d’un facteur 14 sur des tâches de classification et de retrieval sur ImageNet avec une perte minime d’accuracy ^[10].

Le type d’architecture. Deux grandes familles s’opposent:

• Les bi-encoders (modèles d’embedding classiques) encodent la requête et le document indépendamment. Chacun produit un vecteur. La similarité se calcule après coup, ce qui permet un index pré-calculé et une recherche très rapide. C’est le choix standard pour le retrieval en première passe.
• Les cross-encoders (encodeurs croisés) prennent en entrée la paire requête-document simultanément. Ils surpassent généralement les bi-encoders sur la recherche d’information, le dialogue et la similarité sémantique, surtout lorsque les données annotées sont rares ^[11]. Mais ils sont beaucoup plus coûteux à l’inférence, car chaque paire doit être traitée individuellement.

Une approche hybride consiste à utiliser un bi-encoder pour une première passe rapide, puis un cross-encoder pour réordonnancer les meilleurs résultats. Le format ColBERT introduit une interaction tardive (late interaction) entre les tokens de la requête et du document, offrant un compromis entre précision et efficacité ^[12].

Le coût de calcul. Les modèles basés sur de grands modèles de langage (LLM) offrent souvent les meilleures performances, mais à un prix. Parmi les architectures disponibles: T5 et FLAN-T5 (encodeur-décodeur), Mistral, LLaMA et Qwen (décodeur seul), ou encore les API commerciales d’OpenAI et de Gemini ^[13].

6. Validez sur un échantillon de vos propres données

Aucun benchmark universel, aussi complet soit-il, ne remplace un test sur vos données. Sur le framework QuOTE, les résultats varient significativement selon le modèle d’embedding sélectionné ^[14], ce qui confirme que le choix du modèle a un impact mesurable sur la qualité finale de votre système.

Recette minimale de validation:

1. Constituez un échantillon représentatif. Prenez 50 à 200 requêtes typiques de vos utilisateurs, avec les documents pertinents attendus. Un échantillon ciblé suffit pour détecter les écarts entre modèles.
2. Testez 3 à 5 modèles présélectionnés (via votre filtre MTEB ou votre recherche de modèles de domaine). Pour chaque modèle, encodez requêtes et documents, calculez les similarités, et évaluez la pertinence des résultats.
3. Définissez des critères d’acceptation explicites avant de lancer les tests: un rappel minimum (par exemple, 85% des requêtes doivent retrouver le bon document dans le top 5), une latence maximale (par exemple 500 ms par requête) ^[15]. Ces seuils doivent refléter les besoins réels de votre produit, pas des standards arbitraires.
4. Comparez avec des métriques adaptées à votre tâche. Pour le retrieval: Recall@k (le document pertinent est-il dans les k premiers résultats?) et la précision. Pour le clustering: la pureté des groupes. Pour le STS: la corrélation avec des jugements humains.

Si deux modèles sont proches en performance, privilégiez celui qui s’intègre le mieux à votre infrastructure existante. Si votre système repose sur du retrieval augmenté (RAG, retrieval-augmented generation, un système qui récupère des documents pour alimenter un LLM), la qualité de la récupération conditionne celle de la génération. Une combinaison retrieval sparse (par mots-clés, comme BM25) et retrieval dense (par embeddings), via des approches de fusion de scores comme ScoreFusion ^[12], peut améliorer la robustesse sans changer de modèle d’embedding.

7. Ne figez pas votre choix: drift et ré-évaluation

Le choix d’un modèle d’embedding n’est pas un acte ponctuel. Vos données évoluent, votre corpus s’enrichit, le langage de vos utilisateurs change. Les embeddings dérivent quand les données sources ne sont plus stationnaires ^[16].

Surveiller directement la distribution des vecteurs d’embedding est peu éclairant: les centroïdes se déplacent, les normes varient, mais ces signaux ne disent pas si votre système produit toujours de bons résultats ^[16]. La bonne approche est de monitorer la performance de votre tâche en aval: la précision de votre moteur de recherche, la satisfaction des utilisateurs, la qualité des réponses générées par votre RAG.

Si la performance se dégrade, deux leviers: re-encoder vos documents avec le même modèle (utile si votre corpus a beaucoup changé) ou ré-évaluer de nouveaux modèles (utile si le domaine a évolué, par exemple l’apparition de nouveaux termes techniques). Planifiez une re-évaluation périodique, par exemple tous les six mois, ou déclenchez-la automatiquement si vos métriques en aval chutent au-delà d’un seuil ^[16]. Le choix du modèle d’embedding est un processus continu, pas une décision figée.

Sources

• [1] Improving Text Embeddings with Large Language Models · Liang Wang et al. · 2023 · preprint · arXiv:2401.00368
• [2] MTEB: Massive Text Embedding Benchmark · Niklas Muennighoff et al. · 2022 · preprint · arXiv:2210.07316
• [3] Greenback Bears and Fiscal Hawks: Finance is a Jungle and Text Embeddings Must Adapt · Peter Anderson et al. · 2024 · preprint · arXiv:2411.07142
• [4] PhysBERT: A Text Embedding Model for Physics Scientific Literature · Thorsten Hellert et al. · 2024 · preprint · arXiv:2408.09574
• [5] Benchmarking Ten Retrieval Strategies on Financial QA over Heterogeneous Documents · Meftun Akarsu et al. · 2026 · preprint · arXiv:2604.01733
• [6] Recent advances in text embedding: A Comprehensive Review of Top-Performing Methods on the MTEB Benchmark · Hongliu Cao · 2024 · preprint · arXiv:2406.01607
• [7] German Text Embedding Clustering Benchmark · Silvan Wehrli et al. · 2024 · preprint · arXiv:2401.02709
• [8] FLARE: Task-agnostic embedding model evaluation through a normalization process · Jingzhou Jiang et al. · 2026 · preprint · arXiv:2604.17344
• [9] Boosted Dense Retriever · Patrick Lewis et al. · 2021 · preprint · arXiv:2112.07771
• [10] Matryoshka Representation Learning · Aditya Kusupati et al. · 2022 · preprint · arXiv:2205.13147
• [11] Improving Bilingual Lexicon Induction with Cross-Encoder Reranking · Yaoyiran Li et al. · 2022 · preprint · arXiv:2210.16953
• [12] CG-RAG: Research Question Answering by Citation Graph Retrieval-Augmented LLMs · Yuntong Hu et al. · 2025 · preprint · arXiv:2501.15067
• [13] When Text Embedding Meets Large Language Model: A Comprehensive Survey · Zhijie Nie et al. · 2024 · preprint · arXiv:2412.09165
• [14] QuOTE: Question-Oriented Text Embeddings · Andrew Neeser et al. · 2025 · preprint · arXiv:2502.10976
• [15] The AI Product Playbook Strategies, Skills, and Frameworks for the AI-Driven Product Manager · Amazon
• [16] Building Machine Learning Systems with a Feature Store Batch, Real-Time, and LLM Systems · Amazon