Embeddings : quel modèle choisir pour votre RAG en 2026 ?

Les meilleurs modèles d’embeddings sont ceux qui retrouvent de façon fiable les éléments nécessaires à votre réponse. Commencez par OpenAI text-embedding-3-small pour établir une référence textuelle à faible coût, comparez Voyage 4 pour la recherche documentaire et retenez Google Gemini Embedding 2 si vos sources contiennent de l’audio ou de la vidéo. Le modèle small d’OpenAI démarre à $0.02 par million de tokens en entrée. Mais l’engagement le plus lourd reste l’index vectoriel, qu’il faudra reconstruire si vous passez à un modèle incompatible.

Un modèle d’embeddings transforme un contenu en vecteur : une liste de nombres qui permet de retrouver des contenus de sens proche, même lorsqu’ils emploient des mots différents. Pour un bot d’assistance, cela revient à relier « Je n’arrive pas à accéder à mon compte » au bon article de dépannage sur la connexion. La génération augmentée par la recherche, ou RAG, transmet ensuite cette source au modèle qui rédige la réponse.

Caractéristiques, tarifs et licences vérifiés sur les pages officielles des fournisseurs le 15 octobre 2026. Ce comparatif repose sur leur documentation ; il ne présente pas de mesures de précision ou de latence réalisées sur le terrain. Les recommandations servent de point de départ à votre propre évaluation. Le tarif cité en introduction provient de la grille tarifaire d’OpenAI.

Comparatif des modèles d’embeddings en un coup d’œil

Retenez le modèle le moins cher qui satisfait vos exigences de recherche, puis faites évoluer votre sélection selon les langues, les formats de sources et les contraintes de déploiement. Les sept familles présentées ici couvrent les API managées, le déploiement privé et les modèles aux poids téléchargeables.

Les prix correspondent aux tarifs payants standard en USD par million de tokens de texte en entrée, sauf lorsque la ligne indique un auto-hébergement. Ils excluent la base vectorielle, la génération des réponses et le reranking, qui consiste à réévaluer les résultats retrouvés avec un autre modèle. Chaque fournisseur découpe le texte en tokens à sa manière : un même document peut donc produire un nombre différent de tokens facturables.

« Poids ouverts » signifie que les fichiers du modèle sont disponibles pour l’exécuter vous-même. Le calcul, le déploiement et la maintenance ne deviennent pas gratuits pour autant. De même, « multilingue » ne garantit pas une précision identique dans toutes les langues : testez les véritables paires de langues entre requêtes et documents utilisées par vos clients.

Les modèles à retenir

1. OpenAI text-embedding-3 : une référence simple pour le texte

Les modèles d’embeddings textuels hébergés text-embedding-3-small et text-embedding-3-large d’OpenAI constituent un point de départ pratique. Je recommande small à un fondateur qui lance un moteur de recherche classique pour son centre d’aide ou un bot d’assistance : il fournit une référence économique sans avoir à exploiter de serveurs de modèles. Comparez large lorsque small manque régulièrement des passages pertinents. Payer pour large avant d’avoir réuni ces exemples revient à sauter l’étape la plus utile de la décision.

Dimensions : 1,536 par défaut pour small ; 3,072 pour large. Les deux permettent de produire des vecteurs plus courts avec le paramètre dimensions.
Taille maximale en entrée : 8,192 tokens par entrée pour chacun des modèles.
Langues et modalités : texte multilingue ; aucun des deux n’accepte les images, l’audio ou la vidéo. La documentation citée ne donne pas de nombre exhaustif de langues prises en charge.
Déploiement : API d’embeddings hébergée d’OpenAI. Caractéristiques, modalités.
Usage à privilégier : une application centrée sur le texte, dont le développeur veut rapidement établir une référence mesurable.
Point fort : une même API pour comparer small et large et configurer la taille des vecteurs en sortie.
Tarifs : $0.02 par million de tokens en entrée pour small ; $0.13 pour large, aux tarifs standard vérifiés le 15 octobre 2026. Tarifs.
Essai gratuit : aucun crédit de bienvenue pour l’API n’est présumé ; prévoyez un budget sur la base d’un usage payant.

La limite tient au format d’entrée. Réduire un PDF de dépannage à son texte peut faire disparaître la capture d’écran qui indique sur quel bouton cliquer. Aucun de ces modèles OpenAI ne restitue cette information visuelle. Utilisez des embeddings textuels lorsque la réponse reste intacte après extraction ; comparez un modèle multimodal lorsque la présentation de la page porte l’information recherchée.

Distinguez aussi la taille du modèle de celle du vecteur. Réduire les dimensions de sortie de large peut lui permettre de respecter une contrainte de stockage existante, sans le rendre interchangeable avec small. Deux vecteurs de même longueur respectent le même schéma de données ; cela ne prouve pas que les modèles organisent le sens de la même façon.

Établir une référence sans masquer les échecs de recherche

Gardez une configuration initiale assez simple pour pouvoir expliquer pourquoi un résultat apparaît.

1. 1

   Préparer des passages sources capables de répondre aux questions

   Découpez le centre d’aide par sujet ou par section. Conservez avec chaque passage le titre du document, l’URL source, les droits d’accès des clients et un identifiant de fragment stable. Évitez de réunir des instructions sans rapport dans le seul but de remplir la fenêtre de contexte du modèle.

2. 2

   Fixer la configuration des embeddings

   Choisissez text-embedding-3-small et consignez le nombre de dimensions en sortie. Vectorisez chaque passage stocké avec cette configuration, puis créez un index vectoriel de dimension correspondante. Conservez le texte original séparément.

3. 3

   Tester la recherche avant d’ajouter la génération de réponses

   Vectorisez chaque question de test avec la même configuration, récupérez les passages les plus proches et examinez-les. Une réponse générée plausible peut masquer le fait que la recherche a sélectionné la mauvaise source.

4. 4

   Comparer un autre modèle sur les mêmes questions

   Créez un index distinct pour évaluer large ou Voyage. Gardez les mêmes passages sources et annotations de pertinence. N’adoptez le nouveau modèle que si le gain compte réellement pour votre application.

2. Voyage AI 4 : l’API à comparer pour la recherche documentaire

La famille Voyage 4 de Voyage AI propose des embeddings textuels hébergés à comparer à votre référence lorsque la qualité de la recherche est au cœur du produit. Commencez par voyage-4, puis évaluez lite pour la latence et le coût, ou large pour l’option généraliste que le fournisseur présente comme la plus qualitative. Une recherche dans une documentation technique, où les clients décrivent la même panne avec des mots différents, constitue un test plus utile qu’une collection de correspondances évidentes entre mots-clés.

Dimensions : 1,024 par défaut ; 256, 512 et 2,048 également prises en charge par voyage-4-lite, voyage-4 et voyage-4-large.
Taille maximale en entrée : 32,000 tokens pour chacun de ces modèles.
Langues et modalités : texte multilingue ; le tableau des modèles ne donne pas de nombre exhaustif de langues. Ces modèles sont distincts des modèles multimodaux de Voyage.
Déploiement : API d’embeddings hébergée de Voyage AI. Caractéristiques des modèles.
Usage à privilégier : un développeur prêt à comparer les résultats de recherche avant de choisir son API.
Point fort : des embeddings compatibles au sein de la famille généraliste Voyage 4.
Tarifs : par million de tokens en entrée, $0.02 pour 4-lite, $0.06 pour 4 et $0.12 pour 4-large, vérifiés le 15 octobre 2026. Tarifs.
Essai gratuit : la page tarifaire annonce un quota initial de 200 millions de tokens gratuits pour les modèles généralistes actuels ; vérifiez le quota correspondant au modèle utilisé.

Cette compatibilité présente un intérêt concret pour l’exploitation. Voyage documente un espace vectoriel commun à cette famille : vous pouvez donc évaluer une autre variante côté requêtes sans devoir systématiquement recalculer tous les vecteurs des documents. Gardez le même nombre de dimensions en sortie et mesurez les résultats de cette association précise entre modèles de documents et de requêtes. N’étendez pas cette garantie à tous les modèles portant le nom Voyage.

Le piège est la troncature silencieuse : le paramètre truncation de l’API vaut true par défaut. Un document long peut produire un vecteur valide alors que sa fin a été supprimée. Pendant la mise au point de l’ingestion, définissez truncation=false pour faire échouer visiblement les entrées trop longues, puis corrigez le découpage. Une grande fenêtre de contexte permet de conserver des passages cohérents ; elle ne justifie pas de transformer un manuel entier en un seul résultat de recherche. Comportement de l’API.

Pour un corpus composé uniquement de code, le fournisseur propose aussi voyage-code-4. Comparez ce spécialiste au modèle généraliste sur des questions portant sur le dépôt. La présence d’extraits de code dans quelques articles d’assistance ne suffit pas à justifier un modèle spécialisé.

3. Google Gemini Embedding 2 : pour réunir les sources multimodales

Google Gemini Embedding 2 est l’option managée à retenir dans votre sélection lorsque la recherche doit relier du texte à des images, de l’audio, de la vidéo ou des pages PDF. Un système d’assistance couvrant des guides écrits et des démonstrations produit enregistrées peut réunir ces sources dans un même espace vectoriel. Choisissez-le parce que ces modalités contiennent des informations utiles, puis comparez ses résultats sur vos sources. Un centre d’aide purement textuel ne gagne pas automatiquement à disposer de davantage de formats d’entrée.

Dimensions : de 128 à 3,072 ; Google recommande 768, 1,536 ou 3,072.
Taille maximale en entrée : 8,192 tokens.
Langues et modalités : plus de 100 langues ; texte, images, audio, vidéo et PDF.
Déploiement : API Gemini, avec l’identifiant de modèle stable gemini-embedding-2. Fiche du modèle, fonctionnalités.
Usage à privilégier : recherche managée sur des sources dont le texte extrait ne suffit pas à représenter le contenu.
Point fort : l’audio et la vidéo rejoignent le texte et les images dans le même espace vectoriel.
Tarifs : tarifs standard par million de tokens en entrée de $0.20 pour le texte, $0.45 pour les images, $6.50 pour l’audio et $12.00 pour la vidéo, vérifiés le 15 octobre 2026. Tarifs.
Essai gratuit : une offre gratuite pour l’API est disponible, dans la limite de ses quotas d’utilisation.

La difficulté se situe dans l’ingestion propre à chaque modalité. Google autorise jusqu’à 6 images, 180 secondes d’audio, 120 secondes de vidéo ou un PDF de 6 pages maximum par requête, dans le respect des limites globales d’entrée. Le traitement vidéo utilise au plus 32 images et ne traite pas la piste audio. Une démonstration commentée nécessite donc de prévoir explicitement le traitement des explications orales comme celui des éléments visuels. Limites d’entrée.

Conservez le repère temporel ou la référence de page avec chaque élément vectorisé. Trouver la bonne vidéo est moins utile que l’ouvrir au bon moment ; retrouver le bon PDF est moins utile que désigner la page contenant la réponse. Le découpage et les métadonnées déterminent cette qualité de navigation.

Un point de migration concerne les utilisateurs actuels de Google : les espaces vectoriels de gemini-embedding-001 et gemini-embedding-2 sont incompatibles. Garder le même nombre de dimensions ne préserve pas la compatibilité. Google demande explicitement de recalculer les embeddings du corpus existant lors du passage de l’un à l’autre. Consignes de migration.

4. Cohere Embed 5 : documents d’entreprise et choix du déploiement

Cohere Embed 5 s’adresse aux équipes dont la recherche porte sur des documents longs, des tableaux, des graphiques et des pages mêlant texte et images. La famille actuelle comprend embed-v5.0-pro et embed-v5.0-fast. Pour un assistant interne qui recherche dans des manuels à la mise en page structurante, comparez une recherche tenant compte des pages à votre extraction textuelle habituelle. L’enjeu est de savoir si la bonne instruction survit à l’ingestion.

Dimensions : 2,048 par défaut ; 256, 512, 768, 1,024 et 1,536 également prises en charge.
Taille maximale en entrée : 128K tokens pour Pro et Fast.
Langues et modalités : plus de 100 langues ; texte, images et entrées mêlant texte et images, y compris des représentations de pages de documents.
Déploiement : API Cohere, Model Vault, Microsoft Foundry et Amazon SageMaker ; le déploiement privé commercial dans votre VPC ou sur site est également pris en charge. Caractéristiques, déploiement et couverture linguistique.
Usage à privilégier : recherche documentaire en entreprise avec des exigences de déploiement dépassant une API publique mutualisée.
Point fort : Pro et Fast partagent un espace vectoriel, ce qui permet d’interroger avec Fast un corpus indexé avec Pro.
Tarifs : $0.08 par million de tokens de texte pour Fast ou $0.12 pour Pro ; tous deux affichent $0.40 par million de tokens d’image, tarifs vérifiés le 15 octobre 2026. Tarifs du texte, tarifs des images.
Essai gratuit : les clés API d’essai sont gratuites et limitées en débit ; elles ne peuvent pas servir en production ni à des fins commerciales.

La grande fenêtre de contexte est utile lorsqu’un passage a besoin de son contexte environnant, mais elle ne résout pas la conception de la recherche. Si un fragment retourné contient un manuel entier, le modèle de réponse doit encore y trouver le bon passage. Comparez une représentation à contexte long à un découpage par sections avant d’adopter une entrée plus volumineuse simplement parce qu’elle tient dans la fenêtre.

Cohere propose aussi des représentations de sortie float, int8 et binaires. Elles décrivent la façon de stocker les nombres du vecteur ; les formats plus compacts peuvent modifier la consommation mémoire et le comportement de la recherche. Vérifiez ce que prennent en charge votre base et votre implémentation, puis mesurez la configuration compressée elle-même. Un résultat obtenu avec des vecteurs float non compressés ne valide pas automatiquement un index binaire plus petit.

Le fournisseur documente toujours embed-v4.0, avec un contexte de 128K et 1,536 dimensions par défaut. Ce modèle existant doit être évalué selon ses propres caractéristiques, qui ne sont pas celles de la famille actuelle. Le déploiement privé ne transforme pas non plus Embed 5 en modèle téléchargeable sous licence Apache : les conditions commerciales de déploiement font partie de l’achat.

5. Qwen3-Embedding : des modèles textuels ouverts et configurables

Qwen3-Embedding propose aux développeurs des modèles d’embeddings textuels téléchargeables en plusieurs tailles. C’est une famille à envisager sérieusement en auto-hébergement lorsque la localisation des données ou la maîtrise de l’exécution détermine l’architecture. Pour une entreprise qui recherche dans une documentation technique privée, commencez par la plus petite variante atteignant l’objectif de pertinence. Passer directement à la plus grosse version risque de transformer le choix d’un modèle en projet d’infrastructure avant même de savoir si les réponses s’améliorent.

Dimensions : les tailles maximales de sortie sont de 1,024 pour 0.6B, 2,560 pour 4B et 4,096 pour 8B ; la famille permet d’ajuster les dimensions.
Taille maximale en entrée : 32K tokens pour ces variantes.
Langues et modalités : plus de 100 langues, avec prise en charge de la recherche dans du code ; entrée textuelle. Il s’agit de Qwen3-Embedding, une famille distincte de Qwen3-VL.
Déploiement : sur votre infrastructure, à partir des exemples du fournisseur pour Sentence Transformers, Transformers, vLLM ou Text Embeddings Inference. Fiche du modèle.
Licence : Apache 2.0. Fichier de licence.
Usage à privilégier : recherche textuelle multilingue auto-hébergée, avec maîtrise de la taille du modèle et des vecteurs de sortie.
Point fort : des instructions de tâche permettent de préciser la recherche à effectuer.
Tarifs : poids ouverts, auto-hébergement ; il n’existe pas de tarif d’infrastructure universel par million de tokens.
Essai gratuit : poids téléchargeables ; l’environnement d’exécution et la capacité de calcul sont à votre charge.

La difficulté tient au coût du service d’inférence et à son comportement sous charge. Mesurez séparément le débit d’indexation et la latence des requêtes interactives. L’indexation initiale d’un corpus peut accepter une file d’attente ; un client qui attend une réponse d’assistance subit chaque délai d’inférence supplémentaire. Taille des lots, longueur des entrées, matériel et concurrence des requêtes déterminent si le plus gros modèle convient au produit.

Suivez les instructions de recherche de la fiche du modèle. Le format des requêtes fait partie de la configuration évaluée : consignez-le avec la version du modèle et les dimensions de sortie. Un benchmark portant sur un format d’instruction ne valide pas un autre prompt en production. Gardez des conventions stables côté documents et côté requêtes lorsque vous comparez les candidats.

L’auto-hébergement se justifie surtout lorsque la maîtrise de l’exécution a une valeur propre, ou lorsque la charge mesurée justifie le travail d’exploitation. Ce n’est pas automatiquement la solution la moins chère pour vectoriser un petit centre d’aide. Une faible facture de tokens d’API peut coûter moins que le temps consacré à maintenir un service de modèles, avant même de compter le matériel.

6. BAAI BGE-M3 : aller au-delà du vecteur dense avec un modèle ouvert

BAAI BGE-M3 est le modèle ouvert à envisager pour obtenir des représentations denses, sparse et multi-vecteurs à partir d’un même modèle. Les vecteurs denses captent la proximité sémantique ; les représentations sparse attribuent des poids à des caractéristiques lexicales ; la recherche multi-vecteurs conserve plusieurs vecteurs pour affiner les correspondances. Un corpus d’assistance contenant des références produit et des codes d’erreur se prête bien à cette comparaison : une simple proximité de sens peut renvoyer le mauvais identifiant exact.

Dimensions : 1,024 pour l’embedding dense ; les sorties sparse et multi-vecteurs ont des structures différentes.
Taille maximale en entrée : 8,192 tokens.
Langues et modalités : plus de 100 langues ; texte.
Déploiement : auto-hébergement avec l’implémentation FlagEmbedding du fournisseur. Fiche du modèle.
Licence : MIT, comme indiqué dans les métadonnées de la fiche officielle du modèle.
Usage à privilégier : développeurs prêts à évaluer une recherche hybride combinant signaux lexicaux et sémantiques.
Point fort : plusieurs représentations de recherche issues d’une même famille de modèles.
Tarifs : poids ouverts, auto-hébergement ; calcul et stockage à votre charge.
Essai gratuit : poids téléchargeables ; aucun quota de service hébergé n’est présumé.

La limite est simple : produire plusieurs représentations ne signifie pas que votre base de données les utilise. Si vous stockez uniquement le vecteur dense et lancez une recherche dense, vous avez construit un système de recherche dense. Exploiter les sorties sparse ou multi-vecteurs nécessite une indexation et un calcul de scores compatibles, puis un choix sur la façon de combiner les résultats.

Commencez par la recherche dense, puis ajoutez le signal lexical sur les questions auxquelles il devrait profiter : noms exacts de pièces, messages d’erreur et identifiants. Vérifiez si ces gains dégradent la reconnaissance de paraphrases plus larges. N’ajoutez un reranker qu’une fois les résultats qu’il est censé corriger clairement visibles.

BGE-M3 mérite sa place pour cette souplesse ; un ancien benchmark de lancement ne prouve pas qu’il surpasse toutes les API actuelles. Si vous avez seulement besoin d’embeddings denses classiques, comparez-le à Qwen et à votre référence hébergée avant d’accepter une recherche plus complexe.

7. Google EmbeddingGemma : la recherche locale, en deux générations distinctes

Google EmbeddingGemma 2 est à envisager lorsque l’application doit rechercher du texte et des médias sur l’appareil de l’utilisateur. Un outil de gestion des connaissances sur ordinateur pourrait indexer des notes, des captures d’écran et des enregistrements sans envoyer chaque élément à une API d’embeddings hébergée. Le modèle actuel et le modèle d’origine embeddinggemma-300m diffèrent par les formats d’entrée, la longueur du contexte et la licence : fixez donc le dépôt exact utilisé dans votre build.

Dimensions : EmbeddingGemma 2 produit 768 dimensions, avec des options à 512, 256 et 128.
Taille maximale en entrée : 8,192 tokens.
Langues et modalités : plus de 100 langues ; texte, y compris le code, images, vidéo et audio.
Déploiement : en local ou sur votre infrastructure ; le fournisseur propose des exemples avec Sentence Transformers. Ses 740M de paramètres au total comprennent des encodeurs visuels et audio que l’on peut charger sélectivement. Fiche du modèle.
Licence : Apache 2.0 pour EmbeddingGemma 2, selon cette fiche.
Usage à privilégier : applications locales ou hors ligne nécessitant des embeddings multimodaux.
Point fort : ne charger que les encodeurs des modalités utiles à votre application.
Tarifs : poids ouverts, auto-hébergement ; les ressources de l’appareil et toute infrastructure hébergée restent à votre charge.
Essai gratuit : poids téléchargeables.

Le modèle d’origine EmbeddingGemma-300m reste une option textuelle distincte : 300M de paramètres, une limite d’entrée de 2,048 tokens, 768 dimensions avec des alternatives à 512/256/128 et un entraînement couvrant plus de 100 langues parlées. Il s’exécute avec Sentence Transformers, mais son dépôt exige d’accepter les conditions d’utilisation Gemma de Google. N’appliquez pas la licence Apache d’EmbeddingGemma 2 à cette ancienne version. Modèle d’origine et conditions.

La contrainte est celle des ressources de l’appareil. La mémoire disponible, le comportement thermique et les tâches exécutées en parallèle comptent davantage que la seule possibilité de charger le fichier du modèle. Testez une indexation en arrière-plan pendant que l’utilisateur effectue une tâche habituelle au premier plan. Même un modèle compact peut rendre l’application désagréable si l’ingestion monopolise l’appareil.

Pour les vecteurs raccourcis, suivez les consignes de normalisation de Google et alignez les dimensions des requêtes et des documents. Conservez aussi les préfixes de tâche. Ces réglages font partie du déploiement du modèle ; ce ne sont pas des détails facultatifs à reconstituer après une variation de la qualité des résultats.

Quel modèle choisir pour la recherche sémantique ou un bot d’assistance ?

Commencez par éliminer des candidats à partir d’une exigence concrète, avant de comparer leur qualité. La question décisive est celle de l’échec qui rendrait l’application inutilisable : ne pas trouver la réponse, perdre une information visuelle, envoyer les données à un endroit inacceptable ou répondre trop lentement.

Quels modèles privilégier pour les embeddings textuels ?

Pour une application textuelle hébergée, commencez par OpenAI small et Voyage 4. Ajoutez OpenAI large si vous souhaitez comparer au sein de l’API existante ; ajoutez Cohere lorsque la structure des documents et le déploiement privé comptent. Ne retenez une autre solution que si elle corrige les échecs rencontrés par vos utilisateurs, avec une latence et un coût total acceptables.

Pour une assistance multilingue, intégrez des exemples croisant les langues : une question en espagnol dont la réponse figure dans un article anglais, des noms de produits locaux, des messages mêlant plusieurs langues et des termes translittérés. La mention « plus de 100 langues prises en charge » ne démontre pas que votre paire de langues la plus importante fonctionne bien.

Quels modèles d’embeddings open source comparer ?

Comparez Qwen3-Embedding pour une recherche textuelle configurable, BGE-M3 lorsque les approches lexicale et sémantique comptent toutes deux, et EmbeddingGemma 2 pour des entrées multimodales en local. La licence s’applique à la version exacte du modèle. Considérez l’auto-hébergement comme un choix de déploiement au coût d’exploitation mesurable, pas comme un synonyme d’API gratuite.

Si le corpus contient des instructions photographiées, des schémas ou des démonstrations enregistrées, choisissez délibérément entre extraire le texte et préserver la modalité de la source. L’extraction textuelle peut suffire et se révéler plus facile à déboguer. La recherche multimodale se justifie lorsque l’information visuelle ou sonore perdue change la réponse.

Quels modèles d’embeddings exécuter en local ?

EmbeddingGemma 2 est ici le premier candidat multimodal local ; la plus petite variante de Qwen et BGE-M3 ont leur place dans une comparaison textuelle. Mesurez les performances sur le matériel qui servira les utilisateurs. Les résultats d’une station de développement renseignent peu sur l’ordinateur portable ou le petit serveur qui devra gérer simultanément l’indexation et les requêtes.

La règle de décision : gardez le candidat le plus simple qui satisfait vos exigences de pertinence, de latence, de déploiement et de langues. Changez lorsqu’une alternative évaluée corrige un échec important, avec un bénéfice suffisant pour justifier la migration.

Consulter MTEB, puis tester sur vos propres données

Servez-vous du classement MTEB pour repérer des candidats, sans y chercher un vainqueur universel. MTEB, pour Massive Text Embedding Benchmark, couvre notamment la recherche d’information, la classification, le clustering et la similarité. Son classement propose aussi des vues par langue, domaine et modalité. Un score issu d’un ensemble de tâches n’est pas automatiquement comparable à celui d’un autre ensemble.

Pour le RAG, examinez les résultats de recherche pertinents pour vos langues et votre domaine. Pour les sources visuelles, consultez un benchmark multimodal ou de recherche documentaire adapté. Consignez la version du benchmark et ses paramètres avant de vous appuyer sur un résultat pour décider. Aucun score chiffré de classement n’est cité ici.

Une première évaluation utile peut reposer sur un jeu annoté de 100 questions réelles, avec les passages sources censés répondre à chacune. Il s’agit d’un échantillon de départ proposé, pas d’une garantie de certitude statistique. Incluez des questions sans réponse valide, des formulations ambiguës, des identifiants exacts et les combinaisons de langues prises en charge.

Gardez les mêmes fragments sources, droits d’accès, nombre de résultats récupérés et éventuel reranker lorsque vous comparez les modèles. Sinon, vous ne pourrez pas savoir si le gain vient du modèle ou du pipeline qui l’entoure. Pour une recherche limitée à dix résultats, recall@10 mesure la part des éléments pertinents retrouvés ; nDCG@10 valorise le placement des résultats les plus pertinents en tête.

Examinez ensuite les échecs manuellement. Le bon passage était-il absent, classé trop bas, exclu par les droits d’accès ou altéré lors de l’extraction ? Un modèle plus performant ne réparera pas un passage source qui n’est jamais entré dans l’index. Mesurez séparément la latence des requêtes et le débit d’ingestion, puis rejouez les cas difficiles après toute modification des dimensions ou de la compression.

Où stocker les vecteurs et les mettre à disposition ?

Pinecone est une base vectorielle managée capable de stocker des vecteurs produits ailleurs. Elle héberge aussi certains modèles d’embeddings via son API d’inférence. Son catalogue de modèles répertorie llama-text-embed-v2, multilingual-e5-large et pinecone-sparse-english-v0 parmi les options d’embeddings par inférence. Ce choix est distinct de celui qui consiste à appeler vous-même Gemini, OpenAI ou Voyage, puis à importer leurs vecteurs.

Utilisez les embeddings intégrés si le modèle pris en charge convient à votre évaluation et si vous souhaitez confier au service la conversion du texte en vecteurs. Fournissez vos propres vecteurs pour garder la maîtrise du modèle, du prétraitement des médias ou d’un encodeur auto-hébergé. La documentation d’indexation de Pinecone distingue ces approches.

Pour un bot d’assistance, conservez le texte source, les identifiants stables, les métadonnées de contrôle d’accès et les références aux sources avec l’architecture de recherche. La similarité entre embeddings n’accorde aucun droit d’accès. Quelle que soit la base choisie, l’application doit limiter la recherche aux contenus que l’utilisateur est autorisé à consulter.

Le comparatif des meilleures bases vectorielles traite du choix de stockage ; l’article sur les tarifs de Pinecone détaille sa facture distincte. Si l’assistant décide quand rechercher, reformule les questions ou lance des recherches complémentaires, le guide du RAG agentique explique ce workflow. Le modèle d’embeddings fournit la représentation ; le système de recherche décide comment l’exploiter.

Le nombre de dimensions engage votre capacité de stockage

Choisissez les dimensions vectorielles en tenant compte de la base de données. En précision float32, chaque nombre occupe quatre octets. Pour un million de vecteurs, 1,536 dimensions nécessitent donc 6.144 GB de valeurs vectorielles brutes ; 3,072 dimensions nécessitent 12.288 GB. Ces calculs sont exprimés en gigaoctets décimaux et excluent les métadonnées, les structures d’index, les réplicas et les autres surcoûts de stockage de la base.

Voilà pourquoi réduire la taille des sorties peut compter même lorsque les tokens d’embeddings sont peu coûteux. Cela explique aussi pourquoi il faut distinguer le nombre de paramètres du modèle des dimensions vectorielles : le premier concerne l’encodeur à exécuter ; les secondes concernent chaque représentation stockée et interrogée.

Testez la réduction des dimensions avec la méthode prise en charge par le fournisseur. Ne tronquez pas arbitrairement les vecteurs d’un modèle qui ne documente pas cette possibilité. Lorsque la normalisation est requise, appliquez-la de façon cohérente. Évaluez ensuite les vecteurs réduits eux-mêmes : les économies de stockage n’ont d’intérêt que si l’application retrouve toujours les informations nécessaires.

Changer de modèle implique de migrer l’index

Prévoyez de reconstruire les vecteurs du corpus si le nouveau modèle utilise un espace vectoriel incompatible. Remplacer le nom du modèle appelé côté requêtes tout en conservant les anciens vecteurs des documents rompt généralement la correspondance, même lorsque les deux modèles produisent le même nombre de dimensions. La migration d’embedding-001 vers embedding-2 documentée par Google en est un exemple explicite.

Certaines exceptions ont un périmètre défini : la famille généraliste 4 de Voyage et le duo Embed 5 Pro/Fast de Cohere documentent des espaces communs. Ces garanties permettent des associations précises entre modèles, pas des mélanges arbitraires entre fournisseurs. Testez l’association retenue et faites correspondre les paramètres de dimensions et de représentation.

Estimez le recalcul des embeddings à partir du nombre réel de tokens en entrée. À titre d’exemple, un million de fragments de 500 tokens en moyenne contiennent 500 millions de tokens. Au tarif standard publié pour le texte de Gemini Embedding 2, cette passe de vectorisation revient à $100. Ce montant exclut les écritures en base, la coexistence des stockages, le prétraitement, les requêtes, l’ingénierie et toute remise. Source du tarif.

La facture des tokens peut être la partie la plus simple. Il faut aussi disposer des documents sources, des paramètres d’ingestion et d’une capacité suffisante pour maintenir le système en service pendant la construction de son remplaçant. Conservez avec chaque version d’index l’identifiant du modèle, les dimensions, la normalisation, la version du découpage et les instructions appliquées aux requêtes et aux documents.

1. 1

   Construire un index candidat séparé

   Recalculez les embeddings des fragments sources conservés avec la nouvelle configuration. Laissez l’index existant répondre aux requêtes. Utilisez des identifiants de documents stables pour comparer les enregistrements correspondants.

2. 2

   Rejouer l’évaluation et examiner les régressions

   Comparez le candidat sur les mêmes requêtes annotées. Vérifiez la pertinence, mais aussi les droits d’accès, les liens des citations, les documents manquants et la latence des requêtes. Tenez compte des documents modifiés pendant la reconstruction du corpus.

3. 3

   Basculer le modèle et l’index ensemble

   Faites passer les requêtes par le nouvel encodeur et l’index correspondant au moyen d’un seul changement de configuration. Conservez l’ancien couple assez longtemps pour revenir en arrière si le comportement en production diffère de celui observé pendant l’évaluation.

Comment cette sélection a été établie

Ces sept familles de modèles répondent chacune à un besoin précis dans le choix d’une solution de recherche, de RAG ou de bot d’assistance. La sélection tient compte des limites d’entrée publiées, des dimensions, des modalités, de la couverture linguistique, des options de déploiement, des licences et des tarifs actuels. Les pages des fournisseurs ont été consultées à la date de vérification ; les exemples de stockage et de coût ont été calculés à partir des hypothèses indiquées.

Aucun modèle n’a fait l’objet d’un benchmark ou d’un test de charge pour cet article. L’ordre proposé correspond à un parcours d’évaluation recommandé pour un développeur travaillant principalement sur du texte, pas à un classement de précision mesurée. Les familles spécialisées dans le code, dans un domaine particulier ou dans d’autres usages multimodaux n’ont pas reçu de fiche classée distincte. Ajoutez-les à votre propre sélection lorsque cette spécialisation détermine les besoins de l’application.

Les choix à éviter

Évitez OpenAI text-embedding-3 pour rechercher directement dans des images ou de l’audio. Cette famille traite du texte. Extraire les mots est une architecture valable, mais elle fait perdre les informations présentes uniquement dans les éléments visuels ou sonores de la source.

Évitez de choisir automatiquement les anciens modèles Voyage 3 pour un nouveau projet. La documentation actuelle de Voyage recommande la nouvelle famille. Conservez un déploiement existant déjà évalué tant qu’aucune raison ne justifie le coût d’une migration.

Évitez Qwen3-Embedding-8B comme choix par défaut sur un ordinateur portable sans l’avoir mesuré. Commencez par établir les limites de latence et de ressources de l’appareil, puis évaluez si cette version plus volumineuse justifie son coût d’exploitation.

Évitez BGE-M3 pour une « recherche hybride » si vous ne stockez que sa sortie dense. Pour bénéficier de cette capacité, l’architecture de recherche doit exploiter la représentation supplémentaire.

Évitez de considérer toutes les versions d’EmbeddingGemma comme étant sous licence Apache 2.0. La fiche actuelle d’EmbeddingGemma 2 indique Apache 2.0 ; le dépôt du modèle d’origine à 300M utilise les conditions Gemma. Les versions exactes comptent autant pour le déploiement que pour la recherche.

Questions fréquentes

Quels modèles d’embeddings choisir pour le RAG ?

Commencez par OpenAI text-embedding-3-small comme référence textuelle hébergée à faible coût, puis comparez Voyage 4 sur vos propres questions. Gemini Embedding 2 et Cohere Embed 5 ont leur place dans la comparaison lorsque la modalité des sources change la réponse. Qwen3-Embedding, BGE-M3 et EmbeddingGemma sont les candidats auto-hébergés présentés ici. Le bon modèle est celui qui retrouve de manière fiable les passages pertinents de votre jeu annoté.

Quels modèles d’embeddings peut-on essayer gratuitement ?

Pour évaluer une solution hébergée, Gemini propose une offre API gratuite, Voyage annonce des quotas initiaux de tokens et Cohere fournit des clés d’essai limitées en débit qui excluent la production et l’usage commercial. Vérifiez le quota du modèle exact et ses conditions de production avant de compter sur un accès gratuit pour une application destinée aux clients.

Quels modèles d’embeddings gratuits utiliser pour le RAG ?

Pour du RAG textuel auto-hébergé, comparez Qwen3-Embedding et BGE-M3 ; pour du RAG multimodal local, ajoutez EmbeddingGemma 2. Leurs poids téléchargeables permettent d’exploiter vous-même l’encodeur, mais l’inférence, le stockage et la maintenance consomment toujours des ressources. Associez la licence à la version exacte du modèle et intégrez ces coûts d’exploitation à la comparaison avec une API hébergée.

La prochaine étape : rassemblez les questions d’assistance que votre recherche actuelle ne résout pas et annotez les passages censés y répondre. Utilisez la checklist d’audit des workflows d’IA en entreprise pour définir le workflow et les critères de réussite avant d’engager tout le corpus.