Votre RAG a un talon d’Achille : le modèle d’embedding que personne ne choisit vraiment

Tout le monde parle de RAG. Les guides prolifèrent sur le chunking, le re-ranking, les bases vectorielles. Mais une décision reste systématiquement escamotée : le choix du modèle d’embedding. Pourtant, c’est la décision la plus irréversible de votre pipeline RAG.

La mauvaise nouvelle tient en une phrase : changer de modèle d’embedding après avoir indexé vos documents, c’est tout supprimer et repartir de zéro. Pas de migration, pas de compatibilité partielle : un recalcul complet. Cet article couvre ce que vous payez réellement, comment fonctionnent les deux moments de facturation, et quels modèles choisir selon votre profil d’usage. Avec les tarifs vérifiés en mars 2026.

Ce qu’est un embedding, et pourquoi deux modèles ne se mélangent pas

Un modèle d’embedding transforme un texte en vecteur numérique : une liste de nombres qui encode le sens du texte dans un espace à plusieurs centaines ou milliers de dimensions. C’est ce vecteur que votre base vectorielle stocke, et c’est la comparaison entre vecteurs qui permet au retriever de trouver les passages pertinents à votre question.

Le point critique, et que peu de guides explicitent : chaque modèle d’embedding projette le langage dans son propre espace vectoriel. Voyage AI, OpenAI et Google n’utilisent pas le même espace. Un vecteur produit par text-embedding-3-large et un vecteur produit par voyage-4 ne sont pas comparables : mathématiquement, ils n’ont aucun rapport l’un avec l’autre.

L’analogie la plus juste : imaginez deux systèmes de coordonnées GPS différents, avec des méridiens de référence distincts. Vos anciennes positions deviennent fausses dès que vous changez de référentiel. Mélanger des vecteurs issus de modèles différents dans la même base, c’est exactement ça : vos recherches de similarité ne retournent plus que du bruit.

Ce que vous payez réellement : la mécanique économique

Tokens et caractères : même convention que les LLMs

Les modèles d’embedding facturent en tokens, exactement comme les grands modèles de langage. La règle d’approximation est identique : 1 token ≈ 4 caractères en anglais, 3 à 3,5 caractères en français. Le français produit généralement plus de tokens que l’anglais pour un texte équivalent : il est plus verbeux, les mots y sont en moyenne plus longs, et la morphologie (accords, conjugaisons, prépositions) multiplie les sous-mots dans les tokenizers BPE. Rien de surprenant : c’est la même mécanique que lorsque vous utilisez Claude ou GPT sur un texte en français.

Un PDF de 50 pages représente approximativement 25 000 à 35 000 tokens selon sa densité textuelle. Gardez ce chiffre en tête pour les calculs qui suivent.

L’asymétrie fondamentale : embedding vs LLM

C’est le chiffre que personne ne met côte à côte, et il mérite d’être dit clairement : un token d’embedding coûte entre 25 et 150 fois moins cher qu’un token LLM en entrée.

Exemple concret avec les tarifs actuels :

• 1 million de tokens avec Voyage voyage-4 → $0,06
• 1 million de tokens avec Voyage voyage-4-large → $0,12
• 1 million de tokens en entrée avec Claude Sonnet 4.6 → $3,00

Le rapport est de 25× (Sonnet vs voyage-4-large) à 150× (Sonnet vs voyage-4-lite à $0,02/MTok). C’est structurel : les modèles d’embedding sont des architectures encoder uniquement, plus légères et entraînées pour une tâche unique, sans génération.

Point souvent ignoré : les embeddings ne facturent que l’entrée. Il n’y a pas de tokens de sortie, contrairement aux LLMs qui facturent input ET output, où l’output est généralement 5 à 15 fois plus cher que l’input. Dans un pipeline RAG complet, le coût dominant reste donc le LLM d’inférence, pas l’embedding. Mais l’embedding est récurrent à chaque interaction, ce qui crée un poste qui s’accumule à fort volume.

Les deux moments de facturation

Phase 1 : l’indexation (one-shot)

C’est la phase visible. Vous envoyez vos PDF, vos pages web, votre documentation interne. Le modèle d’embedding les « lit » pour construire votre base de connaissances : chaque chunk de texte est transformé en vecteur et stocké.

Vous payez ici les tokens contenus dans vos documents originaux. Fréquence : une seule fois par document, sauf si vous modifiez le contenu ou, et c’est là que ça fait mal, si vous changez de modèle d’embedding.

Phase 2 : la requête (récurrente et invisible)

C’est la phase que personne ne visualise immédiatement. Quand un utilisateur pose une question, cette question doit elle-même être transformée en embedding avec le même modèle que celui utilisé pour indexer vos documents : c’est la condition sine qua non pour que la comparaison de similarité ait du sens.

Vous payez donc les tokens de chaque question posée. En RAG de production, une requête représente typiquement 50 à 150 tokens. Les questions courtes sont rares dès lors qu’on intègre un historique conversationnel ou des reformulations. À 10 000 questions par mois de 100 tokens en moyenne avec voyage-4, le coût de requête tourne autour de $0,06, une somme anecdotique. L’indexation initiale représente donc presque toujours la part dominante du budget embedding.

La règle d’or et son corollaire douloureux

Changer de modèle d’embedding après avoir indexé vos documents n’est pas une migration : c’est une reconstruction. Vous devez supprimer l’intégralité de vos vecteurs existants et les régénérer avec le nouveau modèle.

Cas concret : vous avez indexé 500 000 pages avec text-embedding-3-large. Vous décidez de passer à Voyage pour améliorer la cohérence avec Claude. Le coût de ré-indexation seul :

500 000 pages × 500 tokens/page = 250 M tokens 250 M tokens × 0,06 $/MTok = 15 $

Ce n’est pas le problème principal. Le vrai problème, c’est l’interruption de service, le temps de recalcul, et le fait de devoir invalider tous les vecteurs en production.

Choisissez votre modèle d’embedding avant d’indexer la première ligne de contenu. C’est la règle la moins spectaculaire et la plus importante de ce guide.

Quatre profils, quatre réponses

🎯 Cohérence maximale avec Claude → Voyage AI voyage-4

Voyage AI est le partenaire officiel d’Anthropic pour les embeddings : c’est le fournisseur recommandé dans les guides d’architecture RAG d’Anthropic, et les retours terrain montrent de meilleures performances de retrieval qu’avec des modèles génériques lorsque Claude est le LLM d’inférence. La nature précise de cette optimisation n’est pas documentée publiquement : ce qui est établi, c’est le partenariat commercial, la recommandation technique, et les benchmarks retrieval qui placent la famille voyage-4 en tête sur les tâches de recherche documentaire.

Pour voir un pipeline complet bâti autour de Voyage AI (embedding), d’une base vectorielle et d’un LLM, ce tutoriel pas à pas est particulièrement utile :

Sur les benchmarks de retrieval cosine similarity couplés à un reranker externe (BGE-reranker-v2.5 ou voyage-rerank-2.5), le gap avec OpenAI s’est légèrement réduit en 2026 : il tourne autour de 3 à 5 % sur des datasets neutres. Voyage garde un avantage net sur les corpus domaine-spécifiques et les tâches asynchrones à fort volume.

La famille Voyage 4 : shared embedding space (janvier 2026)

La vraie nouveauté de la famille voyage-4, c’est l’espace d’embedding partagé entre tous ses membres : voyage-4-large, voyage-4, voyage-4-lite et l’open-weight voyage-4-nano. Tous quatre produisent des vecteurs dans le même espace à 1 024 dimensions : ils sont directement interchangeables, sans ré-indexation.

Ce que ça change concrètement : vous pouvez désormais pratiquer le retrieval asymétrique. Indexez vos documents une seule fois avec voyage-4-large ($0,12/MTok) pour la qualité de représentation maximale, puis embarquez vos requêtes à la volée avec voyage-4-lite ($0,02/MTok) ou même voyage-4-nano (open-weight, coût compute seul) : six fois moins cher, latence divisée d’autant, sans perte de cohérence vectorielle et sans toucher à votre index.

C’est l’argument système majeur de Voyage en 2026, surtout en contexte de fort volume de requêtes. Sur 10 000 questions par mois, le poste requête passe de $0,12 (tout en voyage-4-large) à $0,02 (requêtes en voyage-4-lite), soit une économie de 83 % sur ce poste, à qualité de retrieval quasi identique.

Shared space + Matryoshka : toute la famille voyage-4 produit des embeddings à 1 024 dimensions par défaut et partage le même espace vectoriel : c’est ce qui rend le retrieval asymétrique possible. Via le paramètre output_dimension, vous pouvez monter à 2 048 dimensions (précision maximale) ou descendre à 512 ou 256 (Matryoshka, sans recalcul). Les deux mécanismes sont cumulables : indexez en voyage-4-large à 2 048 dimensions, requêtez en voyage-4-nano à 512 ; empreinte vectorielle divisée par 4, coût requête divisé par 6, index inchangé.

Reranker : voyage-rerank-2.5 est le compagnon naturel de la famille voyage-4. Sur un pipeline recall@60 → rerank → top-5, il récupère une fraction significative des erreurs du retriever initial, particulièrement efficace sur les requêtes longues ou ambiguës que Claude reçoit en production.

Tarifs : voyage-4-large $0,12/MTok · voyage-4 $0,06/MTok · voyage-4-lite $0,02/MTok · voyage-4-nano open-weight gratuit. 200 M tokens offerts au démarrage sur tous les modèles API.

Si vous utilisez Claude comme LLM d’inférence, Voyage est le choix rationnel par défaut. Pas une préférence : une cohérence d’architecture, renforcée en 2026 par la flexibilité du shared embedding space.

🔬 Précision maximale sur gros volumes → OpenAI text-embedding-3-large

3 072 dimensions et une bonne résistance au semantic collapse sur les corpus très larges (plusieurs dizaines de milliers de documents). La concentration des distances en haute dimension est un phénomène réel dont le seuil dépend de la densité du corpus, du chunking et du type d’index, et les modèles à plus grande dimensionnalité le tolèrent mieux.

Il faut toutefois être honnête sur sa position en 2026 : text-embedding-3-large n’est plus « le » choix de précision brute absolue sur le leaderboard MTEB/RTEB. Gemini Embedding 001 le devance sur le retrieval anglais (67,71 vs ~65), et les open-weights comme NV-Embed-v2 (72,31 MTEB global) ou Qwen3-Embedding-8B (70,58 MTEB multilingue) l’écrasent sur les benchmarks généraux. Il reste top-tier dans l’écosystème OpenAI (cohérence maximale avec GPT-4/GPT-4o, intégration sans friction, SLA commercial) et sur les corpus massifs en anglais pour lesquels la fiabilité opérationnelle prime sur le dernier point de benchmark.

text-embedding-3-large supporte également la réduction de dimension Matryoshka (jusqu’à 256 dimensions), ce qui offre une flexibilité appréciable sur les très grands corpus sans ré-indexation.

Tarif : $0,13/MTok. Justifié si vous êtes dans l’écosystème OpenAI ou si la fiabilité opérationnelle prime sur la performance brute absolue.

💰 Meilleur rapport qualité/prix → OpenAI text-embedding-3-small ou Mistral Embed

Pour prototyper, pour une base inférieure à 20 000 documents, ou simplement pour garder les coûts maîtrisés sans sacrifier l’essentiel, deux options se détachent.

text-embedding-3-small à $0,02/MTok offre 1 536 dimensions et des performances solides sur la grande majorité des cas d’usage. C’est le couteau suisse du développeur qui ne veut pas se poser de questions à coût réduit. Pour 10 000 documents de 500 tokens chacun (5M tokens), l’indexation complète revient à $0,10. Littéralement dix centimes.

mistral-embed à $0,01/MTok est le moins cher du marché commercial, et une option souveraine européenne si vous êtes déjà dans l’écosystème Mistral. Qualité inférieure à 3-small sur les benchmarks généraux, mais suffisante pour des cas d’usage internes ou des prototypes.

🌍 Alternative multilingue robuste → gemini-embedding-001, BGE-M3 ou Qwen3-Embedding-8B

Si votre corpus mélange intensivement plusieurs langues (documentation FR/EN/DE, base de connaissances internationale, support client multilingue), les modèles généralistes montrent leurs limites.

• gemini-embedding-001 de Google reste en tête du classement MTEB retrieval anglais (67,71 NDCG@10, mars 2026). Accessible gratuitement via AI Studio dans la limite de 1 500 requêtes/jour, ce qui suffit pour l’indexation initiale de la plupart des bases. Le tier payant Gemini Embedding 2 (multimodal, preview) facture $0,20/MTok. Contrainte principale : cohérence réduite si votre LLM n’est pas Gemini, et dépendance à l’écosystème Google.
• Qwen3-Embedding-8B (Alibaba, Apache 2.0) : n°1 du leaderboard MTEB multilingue avec un score de 70,58, supporte 100+ langues dont le français, contexte 32K tokens et dimensions flexibles de 32 à 4096. C’est aujourd’hui le meilleur choix open-source pour un corpus multilingue intensif : auto-hébergeable sur un A100, coût compute seul après installation.
• BGE-M3 (BAAI) reste une référence solide sur l’on-prem multilingue : retrieval dense, sparse et multi-vecteur en un seul modèle, excellent sur le français et les langues européennes, très bien supporté par les frameworks RAG courants.
• multilingual-e5-large (Microsoft Research) reste une option valide mais a été rattrapé par Qwen3 et BGE-M3 sur les benchmarks 2026. Il conserve l’avantage de la légèreté (560M paramètres vs 8B) pour les setups contraints en mémoire GPU.

Dimensions vectorielles : la variable économique oubliée

Le nombre de dimensions d’un vecteur n’est pas qu’une métrique de précision : c’est un coût direct de stockage dans votre base vectorielle (Pinecone, Weaviate, pgvector, Qdrant). Chaque document indexé occupe dimensions × 4 octets en float32.

Sur un corpus de 10 millions de documents, text-embedding-3-large requiert 3× plus de stockage vectoriel que voyage-4, avec un impact direct sur les coûts Pinecone ou la RAM Qdrant. La réduction de dimension Matryoshka (disponible sur voyage-4 et 3-large) permet de descendre à 512 ou 256 dimensions sans ré-indexation, ce qui divise l’empreinte par 2 à 4 avec une perte de recall généralement inférieure à 2 %.

Règle pratique selon la taille du corpus :

• Moins de 10 000 documents → 768 à 1 024 dimensions suffisent
• 10 000 à 100 000 documents → 1 024 à 1 536 dimensions
• Plus de 100 000 documents → 1 536 à 3 072 dimensions (ou Matryoshka sur un modèle haute dimension)

Le pipeline de retrieval moderne : embedding + hybrid search + reranker

En 2026, le retrieval pur par similarité vectorielle est rarement suffisant en production. Le pattern standard est devenu :

La recherche hybride dense + sparse combine la compréhension sémantique du modèle d’embedding (bi-encoder) avec la précision lexicale de BM25, particulièrement utile sur les corpus avec des termes techniques, des références précises (SKUs, codes, noms propres) ou des langues morphologiquement riches comme le français. Elle est supportée nativement par Vespa, Weaviate hybrid, Qdrant BM42 et Elasticsearch.

Pour une démonstration concrète de recherche hybride dense+sparse et de reranking en RAG (en français) :

Le reranker est un cross-encoder : il encode la paire (query, document) en un seul passage forward et calcule un score de pertinence conjoint, bien plus précis qu’un bi-encoder (qui encode query et documents séparément puis compare les vecteurs résultants). Cette précision a un coût : le cross-encoder est trop lent pour s’appliquer sur l’intégralité du corpus. D’où le découplage recall large (bi-encoder) → rerank fin (cross-encoder), désormais incontournable pour atteindre un recall@5 satisfaisant sur des corpus hétérogènes.

Parent-Document Retrieval : le meilleur des deux mondes

Avec des chunks larges (800–2 000 tokens), les vecteurs capturent mieux le contexte global d’un passage, mais le retriever perd en précision sur les requêtes courtes. La solution 2026 : le Parent-Document Retrieval. Vous indexez de petits chunks (200–400 tokens) pour la recherche (précision maximale du retriever), mais vous transmettez au LLM le grand chunk parent (800–2 000 tokens) qui les contient. Claude reçoit ainsi le contexte complet nécessaire pour répondre, sans que le retriever n’ait sacrifié sa précision. Ce pattern est nativement supporté par LangChain (ParentDocumentRetriever) et LlamaIndex (NodeParser + IndexStore).

*Gratuit jusqu’à 1 500 requêtes/jour via AI Studio ; Gemini Embedding 2 (multimodal) : $0,20/MTok.

Matrice de décision

• Votre LLM est Claude, volumes modérés → Voyage voyage-4 symétrique.
• Votre LLM est Claude, fort volume de requêtes → Indexation voyage-4-large + requêtes voyage-4-lite ou voyage-4-nano.
• Corpus >50k documents, stack OpenAI → text-embedding-3-large.
• Vous prototypez ou budget contraint → text-embedding-3-small.
• Corpus intensément multilingue, API → Gemini embedding-001.
• Corpus multilingue, on-prem, performance SOTA → Qwen3-Embedding-8B.
• Souveraineté totale, ressources GPU limitées → BGE-M3.

Ce que les benchmarks MTEB (et RTEB) ne vous disent pas

Le MTEB (Massive Text Embedding Benchmark) est la référence historique du secteur, et son successeur le RTEB (Retrieval Text Embedding Benchmark, 29 datasets) est désormais la mesure la plus pertinente pour les pipelines RAG. Tous deux méritent d’être lus avec précaution.

Pour apprendre à lire le leaderboard MTEB et le relier à vos propres données, cette vidéo est un bon complément :

Premier piège : le score global peut masquer la performance réelle sur votre tâche. NV-Embed-v2 affiche 72,31 de moyenne MTEB globale, mais son score retrieval spécifique (62,65) est inférieur à celui de Gemini Embedding 001 (67,71). Si le retrieval est votre usage principal, c’est le score retrieval qui compte, pas la moyenne générale.

Deuxième réalité à intégrer en 2026 : les open-weights dominent désormais les leaderboards. Qwen3-Embedding-8B, NV-Embed-v2, BGE-M3 écrasent les APIs commerciales sur les benchmarks généraux. Ce n’était pas vrai il y a 18 mois. La question n’est plus « les open-weights sont-ils compétitifs ? » (ils le sont), mais « avez-vous l’infrastructure pour les opérer ? »

Troisième invariant : MTEB ne mesure pas la performance sur votre domaine, vos documents, avec votre LLM. Votre recall réel peut différer de 10 points ou plus du score benchmark. Un modèle excellent sur des textes juridiques génériques peut sous-performer sur votre catalogue WooCommerce, et vice versa.

Avant de vous engager sur un modèle pour une base de 100 000 documents : 500 documents représentatifs, 50 questions de vos utilisateurs réels, recall@5 mesuré sur les deux ou trois modèles candidats. C’est une journée de travail qui peut vous éviter plusieurs mois de performances décevantes.

Conclusion : le choix le moins réversible de votre stack

Le modèle d’embedding n’est pas un paramètre de configuration qu’on ajuste en cours de route. C’est une fondation : une fois vos documents indexés, votre pipeline entier repose dessus, du retriever à la qualité des réponses, jusqu’à la confiance de vos utilisateurs dans le système.

Coût total sur 3 ans : corpus 100k documents, 10k requêtes/mois

Pour rendre la décision concrète, voici une estimation sur 36 mois (indexation unique + 36 mois × 10k questions × ~50 tokens/question = 18M tokens de requêtes) :

voyage-4 symétrique : (100k × 500 tok × $0,06) + (18M × $0,06) = $3 + $1,08 = ~4 $ voyage-4-large docs + voyage-4-lite requêtes : (100k × 500 tok × $0,12) + (18M × $0,02) = $6 + $0,36 = ~6,4 $ text-embedding-3-large : (50M × $0,13) + (18M × $0,13) = $6,5 + $2,34 = ~8,8 $ text-embedding-3-small : (50M × $0,02) + (18M × $0,02) = $1 + $0,36 = ~1,4 $

La leçon : sur un corpus de cette taille, l’embedding est un coût négligeable : le LLM d’inférence domine de loin. Le critère de sélection n’est pas le prix, c’est la qualité du retrieval et la cohérence architecturale avec votre LLM.

Ce qui est vraiment ajustable en cours de route

Le re-ranking, les seuils de similarité, le prompt engineering et la stratégie de retrieval hybride se modifient sans toucher à vos vecteurs. La taille de vos chunks, en revanche, est liée à votre indexation : passer de 500 à 2 000 tokens par chunk force une ré-indexation complète. En 2026, avec les modèles long-context embedding (32K tokens sur voyage-4, 128K sur Qwen3-Embedding-8B), de plus en plus d’équipes adoptent des chunks larges (800–2 000 tokens) couplés au parent-document retrieval, ce qui rend ce choix encore plus structurant. Le modèle d’embedding et la taille des chunks forment ensemble la fondation. Fixez les deux avant de construire dessus.

Trois décisions structurent un pipeline RAG pour les deux prochaines années : le LLM d’inférence, la taille des chunks, et le modèle d’embedding. Les deux premières font l’objet de tous les débats. La troisième est celle que personne ne documente sérieusement, jusqu’à ce que ça fasse mal. Vous avez maintenant les éléments pour ne pas en faire partie.

Pour aller plus loin sur l’architecture RAG complète :

• Le RAG expliqué comme personne ne le fait
• Semantic Collapse : pourquoi les systèmes RAG s’effondrent à grande échelle
• Du RAG au CAG : quand le contexte rend votre infrastructure obsolète.