Meilleurs modèles d'embedding open source (RAG)

Pourquoi le choix est difficile à inverser

Dans un montage de génération augmentée par récupération (RAG), le modèle d'embedding transforme chaque document en un embedding de texte (un vecteur), et ce sont ces vecteurs qu'on recherche au moment de la requête. La propriété critique, c'est que la longueur du vecteur n'est pas qu'un chiffre — elle est intégrée à votre schéma de stockage, à votre index de distance, et à votre base vectorielle. Cet embedding est la base de la recherche sémantique et de la recherche de similarité dans tout votre corpus, ce qui constitue le cœur de la récupération d'information en RAG. Changez de modèle d'embedding plus tard et les nouveaux vecteurs ne s'aligneront pas avec les anciens, ce qui impose de ré-encoder tout le corpus. Pour une base de connaissances qui grossit, c'est une vraie migration, pas un remplacement direct.

C'est pourquoi « le meilleur » est la mauvaise question par laquelle commencer. La bonne question est : quel modèle de dimensions, de contexte et de coût correspond à votre corpus, à votre mix de langues et à votre budget — parce que vous allez vivre avec la réponse longtemps.

Les trois chiffres qui décident

• Dimensions. La longueur du vecteur. Plus de dimensions capturent plus de nuance mais coûtent plus à stocker, comparer et récupérer. Si votre corpus est volumineux, le nombre de dimensions est un budget de stockage et de latence, pas un motif de fierté.
• Fenêtre de contexte. Combien de tokens un seul appel d'embedding accepte. Une fenêtre plus grande vous permet d'encoder un grand document comme vous le voulez, au lieu de découper en morceaux fixes. La stratégie de découpage et la fenêtre de contexte interagissent plus qu'on ne le croit.
• Coût par token. Les embeddings sont facturés sur les tokens d'entrée uniquement (pas de tarif de sortie), donc le chiffre est simple : taille du corpus × prix d'entrée. Pour un gros corpus, c'est le chiffre qui domine.

Le score MTEB ne fait pas partie des trois. C'est un signal utile à la marge (les chiffres vérifiés sont plus bas), mais il ne dit pas comment le modèle se comporte sur votre mix de langues ni sur votre découpage, et sa position au classement bouge constamment. Les trois chiffres ci-dessus, c'est ce sur quoi vous pouvez agir.

Les options open-source en ligne en 2026

Voici les modèles d'embedding open-source que nous servons, avec des faits vérifiés — dimensions mesurées par un appel réel, fenêtres de contexte annoncées par le fournisseur (mesurée à la limite pour Qwen3 Embedding 8B). Une sélection curée, pas le marché entier ; les prix en vigueur sont sur la page embeddings.

Les trois sont multilingues et servis par des opérateurs souverains UE : OVHcloud pour BGE-M3, Scaleway pour les deux autres. BGE-M3 est en pause depuis le 20 octobre 2026, OVHcloud, son seul fournisseur européen, nous étant indisponible ; BGE Multilingual Gemma2 et Qwen3 Embedding 8B restent en ligne. Leurs licences diffèrent : BGE-M3 est sous MIT et Qwen3 Embedding 8B sous Apache-2.0, tandis que BGE Multilingual Gemma2 relève des Gemma Terms of Use de Google — des poids ouverts, mais pas une licence permissive.

Ce que disent les scores MTEB, et ce qu'ils ne disent pas

MTEB, le Massive Text Embedding Benchmark, fait la moyenne d'un modèle sur des dizaines de tâches publiques. Deux des trois modèles ci-dessus figurent dans le même tableau du rapport technique de Qwen3 Embedding, sur MTEB Multilingual :

Comment les lire :

• De qui sont ces chiffres. Ils viennent du rapport de l'équipe Qwen elle-même, publié en juin 2025 ; sa fiche de modèle revendiquait la première place du classement MTEB multilingue au 5 juin 2025. Nous ne les avons pas relancés, et les positions ont bougé depuis.
• La colonne Recherche est celle qui compte pour le RAG. L'écart y est d'environ 16 points (70,88 contre 54,60), plus large que sur la moyenne générale.
• Ce que coûte cet écart. Aux prix du tableau ci-dessus (TTC), indexer un corpus de 100 millions de tokens coûte environ 1,70 € avec BGE-M3 (quand il est en ligne) et environ 16,80 € avec Qwen3 Embedding 8B. Les deux factures sont petites. Le vrai prix du plus gros modèle, c'est le stockage et la vitesse de recherche : 4 096 dimensions occupent quatre fois la place de 1 024.
• BGE Multilingual Gemma2. Sa fiche publie des résultats par tâche mais aucun agrégat comparable au tableau ci-dessus ; nous ne citons donc pas de score pour lui plutôt que d'en deviner un.
• Un benchmark est une moyenne de jeux de données publics. Il ne connaît pas vos documents. Le test de récupération sur vos propres requêtes, décrit plus bas, reste ce qui tranche.

La question du multilingue

Si votre corpus n'est pas en anglais monolingue, la force multilingue compte bien plus que le score brut. BGE-M3 est conçu pour la récupération multilingue et c'est un défaut célèbre (en pause chez Frontière AI depuis le 20 octobre 2026). BGE Multilingual Gemma2 échange un vecteur plus grand de 3 584 dimensions contre un profil multilingue différent. Qwen3 Embedding 8B apporte une fenêtre de contexte bien plus grande de 40 960 tokens, ce qui change plus votre liberté de découpage que votre budget dimensionnel.

Voici la règle pratique : les dimensions sont un engagement, le contexte est une commodité, le coût est une constante. Si votre corpus est énorme, penchez vers des dimensions plus basses pour contrôler le stockage et récupérer plus vite. Si vos documents sont longs ou que vous voulez de la flexibilité de découpage, la plus grande fenêtre de contexte vous l'achète. Les deux sont légitimes — ce sont juste des optimisations différentes du même arbitrage à trois chiffres.

La place des embeddings dans la pipeline de récupération

Pour bien utiliser ces chiffres, voyons où le modèle d'embedding se situe dans la pipeline de récupération. Le RAG fonctionne en deux phases. Au moment de l'indexation, vous découpez chaque document en morceaux, vous passez chaque morceau dans le modèle d'embedding pour obtenir un vecteur, et vous stockez ces vecteurs dans une base vectorielle à côté de leur texte. Au moment de la requête, vous encodez la question de la même façon et vous cherchez les vecteurs les plus proches par distance — ce sont vos documents candidats, transmis à un modèle de chat comme contexte.

Le modèle d'embedding est utilisé dans les deux phases, et les deux utilisent les mêmes trois chiffres. Les dimensions déterminent la taille et la forme de votre index vectoriel : un vecteur de 4 096 dimensions prend quatre fois plus de stockage et ralentit la recherche du plus proche voisin qu'un vecteur de 1 024 dimensions, à nombre de lignes égal. La fenêtre de contexte décide comment fonctionne le découpage : une petite fenêtre impose de courts morceaux fixes, tandis qu'une fenêtre de 40 960 tokens permet d'encoder une longue section en un seul vecteur, ce qui peut améliorer le rappel pour les documents cohérents dans leur ensemble. Et le coût d'entrée se multiplie par le nombre total de tokens que vous indexez.

Un détail souvent oublié : le côté requête coûte aussi des tokens d'entrée. Encoder une question courte est presque gratuit, mais si vous réordonnez ou encodez des requêtes longues, ce coût est réel lui aussi. Rien de tout cela ne change le cadre de décision — cela explique juste pourquoi les trois chiffres sont ceux qui comptent, et pourquoi changer de modèle plus tard est si cher.

Les erreurs fréquentes qui coûtent du rappel

La plupart des problèmes de récupération ne sont pas la faute du modèle — ils viennent d'erreurs d'indexation qui survivent à un changement de modèle. Les gains les moins chers viennent de leur correction, pas d'une chasse à un score MTEB légèrement meilleur.

• Découper contre la fenêtre de contexte au lieu de l'utiliser. Des morceaux fixes arbitraires peuvent couper une phrase ou une idée cohérente en deux vecteurs. Recette : dimensionnez les morceaux pour que la plupart des unités sémantiques tiennent dans un seul vecteur, avec un léger chevauchement pour attraper les frontières. Une plus grande fenêtre de contexte vous donne plus de liberté ici.
• Ignorer le prétraitement. Les en-têtes, le texte répétitif et la navigation sont encodés dans les vecteurs et polluent les résultats du plus proche voisin. Les retirer avant l'encodage est bon marché et améliore fiablement le rappel.
• Aucun soin côté requête. Si vous encodez la question brute de l'utilisateur mot pour mot, les incohérences (« API » vs « clé API ») peuvent nuire. Appliquer la même normalisation aux requêtes qu'aux documents comble cet écart.
• Juger le rappel sur un petit ensemble propre. Tester sur une centaine de documents propres ne prédit jamais le comportement sur dix millions de documents désordonnés. Testez sur un échantillon représentatif de vos vraies données, cas limites compliqués compris.

Aucune de ces étapes n'exige de changer de modèle — c'est de l'hygiène d'indexation. Réglez-les d'abord, et le choix du modèle devient un levier bien plus petit.

Comment choisir avant d'indexer

1. Mesurez la taille de votre corpus et son mix de langues. Les chiffres qui comptent sont le nombre de tokens et son degré de multilingue.
2. Faites un petit test de récupération avec vos vraies requêtes, pas un classement, sur quelques centaines de documents. La qualité de rappel est une propriété de vos données, pas de MTEB.
3. Chiffrez le coût. Tokens du corpus × prix d'entrée = votre facture d'indexation. À ces tarifs, un gros corpus est bon marché à indexer ; c'est le budget dimensionnel qui passe à l'échelle avec votre base.
4. Verrouillez le choix. Une fois les vecteurs dans votre schéma, le modèle est effectivement engagé. La certitude maintenant vaut mieux qu'un gain marginal de MTEB plus tard.

Faire tourner les embeddings sur une infrastructure souveraine UE

Vectoriser des documents est souvent l'étape qui expose le plus de données sensibles — vous envoyez des documents entiers à travers le modèle. Si ces documents doivent rester sous juridiction UE, l'opérateur compte plus que le modèle. Les trois modèles ci-dessus sont servis via des opérateurs détenus par l'UE (OVHcloud, Scaleway), donc la moitié « embedding » de votre pipeline RAG est calculée sous contrôle UE ; la passerelle qui relaie vos requêtes tourne chez Vercel, région de Paris, un sous-traitant américain qui ne stocke ni prompt ni réponse (voir notre politique de confidentialité). La moitié « génération » — le modèle de chat qui répond à partir du contexte récupéré — est le même catalogue à appel d'outils, servi souverain ou accès rapide avec l'étiquette affichée avant votre appel.

Les deux moitiés ensemble — embedding sur infrastructure UE, génération sur infrastructure UE, derrière une seule API compatible OpenAI — c'est ce qui permet à une équipe de bâtir une pipeline RAG dont toute l'inférence tourne chez des fournisseurs sous contrôle UE. Facturé au token depuis un crédit prépayé : si vous avez besoin de millions d'embeddings par mois, l'analyse hébergement vs API vous dit où se situe le seuil de rentabilité, et le guide des modèles en général complète le reste du catalogue.

FAQ