Le modèle d'embedding est la décision la plus chère à changer dans une pipeline RAG, parce que la longueur du vecteur qu'il produit devient partie de votre schéma de stockage. Changez de modèle plus tard et vous devrez tout ré-encoder. Le choix mérite donc plus que « celui avec le meilleur score MTEB » — il mérite les trois chiffres qui le gouvernent réellement : dimensions, fenêtre de contexte, et coût. En 2026, les options open-source sérieuses sont rares et mesurables, et toutes peuvent tourner sur une infrastructure souveraine UE. Ce guide explique ce que signifie chaque chiffre, les options en ligne, et comment choisir avant d'indexer un seul document.
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 text embedding (vector de texte), et c'est 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.
Remarquez ce qui est absent : le score MTEB. C'est un signal utile à la marge, 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 les faits que nous avons mesurés par un appel réel — dimensions et contexte vérifiés, pas lus sur une fiche. Une sélection curée, pas le marché entier.
| Modèle | Dimensions | Contexte | Entrée €/100k (client) |
|---|---|---|---|
| BGE-M3 (multilingue, BAAI) | 1 024 | 8 192 | 0,0013 € |
| BGE Multilingual Gemma2 (BAAI) | 3 584 | 8 192 | 0,0013 € |
| Qwen3 Embedding 8B | 4 096 | 40 960 | 0,014 € |
Les trois sont multilingues et tournent sur des opérateurs souverains UE (OVHcloud et Scaleway).
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. 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
- 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.
- 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.
- 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.
- 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 ne quitte jamais le contrôle UE. 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 pleinement souveraine. 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
Quel est le meilleur modèle d'embedding open-source pour le RAG en 2026 ?
Il n'y a pas de meilleur unique — la décision est un arbitrage à trois chiffres : dimensions (votre budget de stockage/récupération), fenêtre de contexte (votre liberté de découpage), et coût d'entrée. De bonnes options en ligne : BGE-M3 (1 024 dim), BGE Multilingual Gemma2 (3 584 dim) et Qwen3 Embedding 8B (4 096 dim, contexte 40 960 tokens). Choisissez avec un petit test de récupération sur vos propres requêtes, puis verrouillez.
Les modèles d'embedding sont-ils facturés en tokens d'entrée ou de sortie ?
En tokens d'entrée uniquement. Un appel d'embedding produit un vecteur, pas du texte, donc il n'y a pas de tarif de sortie. Votre coût total d'embedding est simplement taille du corpus × prix d'entrée au token — c'est pourquoi le coût est facile à prévoir avant d'indexer.
Pourquoi changer de modèle d'embedding est-il coûteux ?
Parce que la longueur du vecteur fait partie de votre schéma de stockage et de votre index de distance. Un autre modèle produit des vecteurs de longueur différente qui ne s'alignent pas avec les anciens, donc le changement impose un ré-encodage complet du corpus. C'est pourquoi le choix doit être mesuré puis verrouillé tôt.
Ai-je besoin d'un modèle d'embedding multilingue ?
Seulement si votre corpus ou vos requêtes ne sont pas monolingues. Pour un anglais monolingue, un modèle général suffit généralement ; pour des corpus mixtes ou en langues européennes, un modèle multilingue comme BGE-M3 ou BGE Multilingual Gemma2 évite une chute brutale de rappel sur les requêtes non anglaises.
Puis-je faire tourner une pipeline RAG entièrement sur une infrastructure souveraine UE ?
Oui. Frontière AI sert à la fois la moitié embedding (vectoriser sur des opérateurs UE comme OVHcloud ou Scaleway) et la moitié génération (modèles de chat souverains UE), derrière une seule API compatible OpenAI. Les deux moitiés gardent vos documents sous juridiction UE et sont facturées au token depuis un crédit prépayé.
Le côté requête des embeddings coûte-t-il aussi des tokens ?
Oui. Les embeddings sont facturés en tokens d'entrée, et le côté requête encode votre question de la même façon, donc il consomme aussi des tokens d'entrée — généralement une quantité minuscule pour une question courte, mais réelle si vous encodez des requêtes longues ou de réordonnancement. L'indexation domine, mais le coût de requête n'est jamais nul.
Quelle est la différence entre un modèle d'embedding et un reranker ?
Un modèle d'embedding transforme le texte en vecteur pour la récupération de premier niveau — il trouve des candidats. Un reranker prend les candidats récupérés et les re-score par rapport à la requête pour un ordonnancement final plus précis. Ils travaillent généralement ensemble dans les pipelines à haut rappel : les embeddings fixent le plafond de rappel, le reranking améliore la précision par-dessus.
Ai-je besoin d'une base vectorielle pour le RAG, ou une passerelle suffit-elle ?
Une passerelle est l'API qui encode le texte et appelle les modèles ; une base vectorielle stocke et recherche les vecteurs. Pour la plupart des montages RAG, il vous faut les deux — encodez via la passerelle, stockez et interrogez dans votre base vectorielle. Le rôle de la passerelle est de rendre chaque étape compatible OpenAI et de garder les données dans la juridiction de votre choix.
Un plus grand nombre de dimensions est-il toujours meilleur pour la récupération ?
Non. Plus de dimensions capturent plus de nuance mais coûtent proportionnellement plus à stocker, indexer et rechercher, et peuvent ajouter du bruit. Un vecteur de 1 024 dimensions issu d'un modèle multilingue bien entraîné bat souvent un vecteur de 4 096 dimensions sur le rappel par octet stocké. Choisissez les dimensions pour votre taille de corpus et votre budget de latence, pas pour le chiffre d'appel.
Dois-je encoder à l'indexation et à la requête avec le même modèle ?
Oui, toujours. L'espace vectoriel n'a de sens que si les requêtes et les documents vivent dans le même espace, ce qui exige exactement le même modèle. Mélanger un modèle d'embedding différent à la requête qu'à l'indexation produit des vecteurs qui ne se comparent pas correctement. C'est une autre raison de verrouiller le modèle tôt.
Prêt à essayer ?
Créez un compte et appelez n'importe quel modèle du catalogue en quelques minutes.