Modèles embedding: OpenAI vs Gemini vs Voyage

Nous avons évalué 15 modèles d’embedding de texte en anglais et une référence BM25 sur plus de 500 requêtes sélectionnées manuellement dans trois domaines de recherche : contrats juridiques (CUAD), support client (IBM TechQA) et santé (MedRAG PubMed).

Voyage-3.5 se classe premier au classement général. Perplexity Embed V1 0.6b atteint le segment intermédiaire supérieur au prix le plus bas de notre benchmark.

Résultats du benchmark des modèles embedding

Explication des métriques

nDCG@3 : Gain cumulé actualisé normalisé au rang 3. Avec un seul document pertinent par requête, il vaut 1 / log2(rang + 1) lorsque le document de référence figure dans le top 3, et 0 sinon. Le rang 1 obtient 1.000, le rang 2 obtient 0.631, le rang 3 obtient 0.500. Nous utilisons le nDCG@3 comme métrique principale car les pipelines RAG de production transmettent les 3 à 5 meilleurs segments au LLM, et le biais de primauté fait que le rang 1 compte de manière disproportionnée.

nDCG@10 : Même formule avec un seuil de 10.

Recall@10 : Fraction des requêtes pour lesquelles le document de référence apparaît dans le top 10.

MRR@10 : Rang réciproque moyen au seuil de 10. Le document de référence au rang 1 obtient 1.000, au rang 2 0.500, et au rang 10 0.100. Intention similaire au nDCG@3, mais avec une pénalité de rang plus forte.

Top-1 hit : Fraction des requêtes pour lesquelles le document pertinent de référence est le seul premier résultat. C’est la métrique la plus stricte et la plus proche d’un flux de travail sans LLM.

nDCG@3 par domaine

Juridique (CUAD, 246 requêtes, 509 contrats) : Le juridique est le seul domaine où le modèle spécialisé voyage-law-2 l’emporte ; ses données d’entraînement adaptées à CUAD rapportent +0.040 de nDCG@3 par rapport à voyage-4-large. openai/text-embedding-3-large se classe 11e avec 0.6430, en dessous de six modèles moins chers. Plancher BM25 : 0.5844.

Support client (TechQA, 151 requêtes, 28 000 notes techniques IBM) : L’écart entre voyage-4-lite et le modèle suivant est de 0.018. gemini-embedding-001 recule à la 7e place (0.8856), 0.045 derrière son successeur plus récent sur TechQA, alors qu’il remporte les deux autres domaines. Plancher BM25 : 0.6097.

Santé (MedRAG-PubMed, 154 requêtes, 50 000 résumés) : La santé est le groupe le plus serré de notre benchmark (14 modèles dépassent 0.88) car le vocabulaire médical est dense en mots-clés, ce qui pousse la plupart des requêtes vers le groupe de tête. Plancher BM25 : 0.7862, à 0.02 du modèle dense le plus faible. gemini-embedding-001 bat aussi gemini-embedding-2-preview avec son écart le plus important ici (+0.013).

Les inversions au niveau des domaines justifient l’approche de la moyenne sur les 3 domaines : aucun domaine unique n’est un indicateur fiable pour « quel modèle est le meilleur », et un acheteur qui choisit sur la base d’un seul domaine classera mal les autres.

Les intervalles de confiance bootstrap 95 % par modèle pour chaque cellule de domaine, ainsi que les quatre égalités par paires que masquent les classements par estimation ponctuelle, sont détaillées dans la section méthodologie.

Précision vs prix : Coût par 1M tokens

Explication des métriques

Prix par 1M tokens d’entrée est le tarif public pour l’embedding de 1M tokens d’entrée, à la date du 2026-04-23. Les prix Voyage proviennent de la page de tarification directe de Voyage. Les modèles servis via OpenRouter utilisent l’instantané du catalogue OpenRouter du même jour. Les tokens de requête et de document sont facturés au même tarif chez tous les fournisseurs testés. BM25 est représenté à $0,001/M pour l’affichage en échelle logarithmique. Le coût réel en auto-hébergement est de $0.

Moyenne nDCG@3 sur les 3 domaines est la moyenne non pondérée des nDCG@3 par domaine sur les trois corpus. Chaque domaine contribue de manière égale à la moyenne, quel que soit le nombre de requêtes.

• Pour les plateformes RAG axées sur le coût, pplx-embed-v1-0.6b est le choix évident. À $0,004/M, il est 30-50x moins cher que n’importe quel modèle phare commercial et offre 92 % de la qualité de voyage-3.5 (0.8604 / 0.9429). Aucun autre modèle de notre benchmark ne rivalise à ce niveau de prix.
• Pour les RAG d’entreprise axés sur la qualité, voyage-3.5 via le SDK direct de Voyage occupe le meilleur point Pareto. Vous troquez une intégration API supplémentaire (par rapport à une pile utilisant uniquement OpenRouter) contre un modèle légèrement meilleur que le modèle phare de Voyage à moitié prix. L’instinct de « toujours choisir le plus récent et le plus gros » est faux dans le catalogue de Voyage.
• Pour les déploiements OSS / auto-hébergeables / sur site, qwen3-embedding-8b l’emporte. C’est l’encodeur non trivial le moins cher de notre benchmark à $0,010/M, il égale ou surpasse toutes les autres familles d’encodeurs OSS testées et il est livré avec des poids auto-hébergeables.
• Les modèles phares premium (openai-3-large, gemini-2-preview, voyage-4-large, gemini-001) perdent tous face à voyage-3.5 sur la moyenne des 3 domaines, même si voyage-3.5 est 2-3x moins cher que chacun d’entre eux.

Principaux enseignements du benchmark des modèles embedding

voyage-3.5 remporte la moyenne sur les 3 domaines et bat le modèle phare voyage-4-large à moitié prix

voyage-3.5 obtient en moyenne 0.9429 de nDCG@3 sur le juridique, le support client et la santé. Le modèle phare voyage-4-large obtient en moyenne 0.9416 à $0,12 par 1M tokens, soit 2x le prix de $0,06 de voyage-3.5. Le modèle phare remporte TechQA de 0.002 et remporte MedRAG de 0.032. Il perd sur CUAD de 0.037 (0.8730 vs 0.9102), ce qui place sa moyenne sur les 3 domaines en dessous de voyage-3.5. Dans la gamme de Voyage, le modèle intermédiaire plus ancien est le meilleur choix généraliste. Le modèle phare ne justifie son prix élevé que sur la santé.

Voyage a pris la première place sur les trois domaines et a réalisé le doublé sur CUAD et TechQA. Sur MedRAG, gemini-embedding-001 est entré à la 2e place (0.9814, derrière voyage-4-large et son 0.9855), devant tous les autres modèles Voyage. gemini-001 atteint aussi la troisième place sur CUAD. Aucun autre modèle non-Voyage n’atteint le top 2 dans un domaine unique.

Un ancien modèle Gemini bat son successeur « preview » sur deux des trois domaines

google/gemini-embedding-001 (publié en juin 2025) surpasse google/gemini-embedding-2-preview à la fois sur CUAD (0.8980 vs 0.8958) et sur MedRAG (0.9814 vs 0.9685). Le modèle plus récent ne remporte que TechQA (0.9301 vs 0.8856), un écart de 0.04 qui s’accompagne d’une hausse de prix de 33 % ($0,20 vs $0,15 par 1M tokens d’entrée). La présentation « mise à niveau multimodale plus récente » de Gemini 2 ne tient pas pour la recherche de texte en anglais sur les corpus juridiques ou de santé.

Pour les charges de travail RAG sur ces deux domaines aujourd’hui, gemini-embedding-001 est le bon choix Gemini. L’inversion sur MedRAG (001 à la 2e place, 2-preview à la 3e) est assez importante pour qu’un acheteur qui choisit par défaut le modèle « le plus récent » perde une qualité mesurable.

OpenAI text-embedding-3-large se situe dans le milieu de tableau en juridique et en support client

openai/text-embedding-3-large se classe 11e sur 15 modèles denses sur CUAD avec 0.6430 de nDCG@3. Huit modèles strictement moins chers le battent sur les contrats juridiques : les deux modèles phares Voyage de la série 4 à $0,12, voyage-3.5 à moitié prix, voyage-4-lite à 1/6 du prix, les deux variantes d’embedding Qwen3, intfloat/e5-large-v2 à 1/13 du prix, et perplexity/pplx-embed-v1-0.6b (0.8031) à 1/32 du prix. Le modèle phare d’OpenAI est 9e sur TechQA (0.8581) et 11e sur MedRAG (0.9296). En santé, il se retrouve dans un groupe de tête resserré (écart de la 2e à la 11e place : 0.05 de nDCG@3). Sur le juridique, l’écart est large et coûteux.

À $0,13 par 1M tokens d’entrée, il est 32x plus cher que pplx-embed-v1-0.6b. Les équipes qui choisissent OpenAI par défaut parce que « c’est le choix sûr » paient une prime que les données sur les 3 domaines ne justifient pas.

pplx-embed-v1-0.6b atteint le haut du classement pour un trentième du prix des modèles phares comparables

perplexity/pplx-embed-v1-0.6b à $0,004 par 1M tokens obtient en moyenne 0.8604 de nDCG@3 sur les trois domaines, derrière seulement les quatre modèles Voyage, les deux variantes Gemini et qwen/qwen3-embedding-8b. Il bat tous les modèles OpenAI et OSS de la sélection. Il bat également openai/text-embedding-3-large de 0.16 de nDCG@3 sur CUAD, perd de 0.012 sur TechQA (0.8457 vs 0.8581) et gagne de 0.003 sur MedRAG. Le modèle du top-10 le moins cher suivant est qwen/qwen3-embedding-8b à $0,010 (2.5x plus cher), également servi via OpenRouter.

Pour les plateformes RAG axées sur le coût où l’embedding est un poste de dépense important, pplx-0.6b est le choix évident. L’écart de 30-50x par rapport au prix des modèles phares n’apporte rien en qualité de recherche, du moins sur ces trois domaines.

BM25 est à 0.02 du modèle dense le plus faible sur les résumés médicaux

Sur MedRAG-PubMed, BM25 obtient 0.7862 de nDCG@3 face à baai/bge-m3 (mode dense) à 0.8038, soit un écart de 0.02. La recherche lexicale se rapproche à 0.15 de sept des quinze modèles denses sur ce corpus (bge-m3, e5-base-v2, openai-3-small, e5-large-v2, openai-3-large, pplx-0.6b, qwen3-4b). La raison est structurelle : les requêtes médicales sont par nature denses en mots-clés (noms de médicaments, noms de maladies, termes de conception d’étude, symboles de gènes), et ces tokens portent l’essentiel du signal de recherche. Un scoreur de type Lucene les trouve directement sans avoir besoin de contexte sémantique.

Un reranker au-dessus de BM25 est une alternative plausible et moins chère à un encodeur dense premium pour les corpus denses en mots-clés : l’écart de recherche laissé par BM25 (0.2 de nDCG@3 par rapport au haut du classement sur MedRAG) est le type d’écart qu’un reranker Cohere ou Voyage peut combler. Sur CUAD, l’écart entre BM25 et le meilleur modèle dense est de 0.33, sur TechQA de 0.36 et sur MedRAG de 0.20. La densité du vocabulaire du domaine est le principal déterminant de l’utilité des embeddings denses.

Spécialistes par domaine vs généralistes chez les fournisseurs

Voyage tarife voyage-law-2 à $0,12/M, comme voyage-4-large. Les deux modèles partagent le fournisseur, le tokenizer, le SDK et le schéma d’invocation asymétrique. Seule l’orientation des données d’entraînement diffère. Faire tourner les deux face aux généralistes sur CUAD, TechQA et MedRAG isole l’effet de l’entraînement juridique.

Sur CUAD, voyage-law-2 se classe 1er avec 0.9126 : 0.0024 au-dessus de voyage-3.5, 0.0146 au-dessus de gemini-embedding-001, 0.040 au-dessus de voyage-4-large, 0.097 au-dessus de qwen3-embedding-8b et 0.270 au-dessus d’openai/text-embedding-3-large (0.6430). Sur TechQA, voyage-law-2 se classe 4e avec 0.9020, 0.064 derrière voyage-4-large et 0.063 derrière voyage-3.5. Sur MedRAG, il se classe 6e avec 0.9409, 0.045 derrière voyage-4-large et 0.041 derrière gemini-embedding-001. L’entraînement juridique augmente le nDCG@3 sur CUAD et le diminue sur les deux autres domaines.

Une équipe juridique qui utilise une recherche de type CUAD avec openai/text-embedding-3-large fonctionne à 0.6430 de nDCG@3 contre voyage-law-2 à 0.9126, soit un écart de 0.27. Une équipe santé ou support qui choisit voyage-law-2 parce qu’il est premier sur CUAD perd 0.045 face à voyage-4-large sur MedRAG et 0.064 sur TechQA. Les modèles d’embedding spécialisés par domaine ne sont pas des améliorations directes pour la recherche générique. Une seule recommandation de « meilleur modèle » entre secteurs se trompe dans au moins une direction.

Quand choisir voyage-law-2 : pour la recherche de contrats sur des corpus juridiques commerciaux qui ressemblent structurellement à CUAD. Quand ne pas le choisir : tout le reste de ce benchmark. voyage-3.5 est à $0,06/M, se situe 0.0024 en dessous de voyage-law-2 sur CUAD et le surpasse à la fois sur TechQA et MedRAG.

Comment le pipeline de recherche par embedding a été évalué

Chaque modèle encode un vecteur de requête et N vecteurs de documents via un bi-encodeur. Nous calculons la similarité cosinus entre le vecteur de requête et chaque vecteur de document, puis trions les top-k pour cette requête. Avec un seul document de référence par requête et une pertinence binaire, l’évaluateur vérifie si le document de référence apparaît dans le top-k et à quel rang. Ce rang alimente le nDCG@3 (notre métrique principale), le nDCG@10 (pour la comparabilité BEIR/MTEB), le Recall@10 et le taux de réussite Top-1.

Les encodeurs de requête et de document ne sont pas toujours la même fonction. Certains modèles sont entraînés de manière asymétrique : le côté requête applique une transformation, le côté document une autre. Invoquer ces modèles de manière symétrique (« il suffit de passer le texte ») dégrade silencieusement la qualité de recherche de 0.05-0.45 de nDCG@10. Notre sélection se répartit en quatre modes :

Pourquoi le nDCG@3 comme métrique principale. Les pipelines RAG de production transmettent les 3 à 5 meilleurs segments au LLM, pas le top 10. Le biais de primauté chez les LLM à long contexte rend le rang 1 plus important que le rang 3, et chaque distracteur qui arrive au-dessus du document de référence dans le contexte du LLM est un candidat à la confabulation. Les rerankers atténueraient cet effet, mais la plupart des RAG de production s’en passent pour des raisons de coût et de latence, de sorte que le rang de l’encodeur EST le rang final.

Sur MedRAG, le Recall@10 a atteint le plafond de 1.000 pour trois modèles Voyage et pour qwen3-8b ; le nDCG@3 a conservé un écart de 0.10 sur les mêmes requêtes. Le nDCG@10 conserve la comparabilité BEIR mais atténue les différences en tête de liste qui comptent sur le plan opérationnel.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Méthodologie du benchmark des modèles embedding

Corpus (sélection des domaines et justification)

Nous avons choisi trois domaines qui sollicitent des propriétés de recherche différentes et qui couvrent les trois usages de RAG d’entreprise les plus courants. Chaque corpus est épinglé par SHA256, de sorte que tout lecteur peut reproduire la cellule exacte que nous avons exécutée.

PM209 (manuels de fabrication) a été abandonné : seulement 209 documents, trop peu pour éviter le problème de raccourci par entité de BM25 à 150 requêtes.

Génération de requêtes : protocole de consensus à 3 LLM

Nos requêtes sont générées par des LLM selon une séparation rédacteur-validateur : le LLM qui rédige une requête ne juge jamais sa propre cible de recherche, ce qui exclut structurellement le biais d’auto-évaluation. Seuls les deux validateurs non rédacteurs, qui voient les 20 candidats mélangés sans aucune indication du document d’ancrage du rédacteur, décident de l’acceptation. En plus du consensus des LLM, nous avons révisé manuellement environ 25 % de l’ensemble des requêtes acceptées (examen par l’auteur du caractère naturel de la requête, de l’alignement avec le document cible et de la conformité R9, indépendamment du vote des validateurs).

Chaque requête est passée par le pipeline suivant avant d’entrer dans l’ensemble de production :

1. Rédacteur rédige une requête unique ancrée dans un document échantillonné aléatoirement. Le rédacteur alterne entre Claude Sonnet 4.6, Qwen3.6-plus et Gemini 3 Flash preview afin qu’aucun modèle ne domine l’empreinte linguistique.
2. Scoreur (fixe : Claude Sonnet 4.6) évalue la requête selon une grille de spécificité. Nous avons exigé semantic_bridge ≥ 4 (la requête doit décrire sémantiquement ce que le document affirme, et non pas seulement correspondre au nom) et unique_referent entre 3 et 5 (les ancrages descriptifs doivent identifier environ un à cinq documents candidats dans le corpus, ni des milliers ni exactement un).
3. Vérification des négatifs difficiles : nous récupérons les 19 premiers documents distracteurs selon BM25 plus la cible et appliquons un seuil de Jaccard de quasi-duplication (>0.5 → rejet de toute la requête comme vérité terrain ambiguë).
4. Validateurs (2 modèles, n’incluant jamais le rédacteur) choisissent indépendamment le document cible dans l’ensemble mélangé de 20 candidats. Les deux validateurs doivent s’accorder sur la position cible exacte, sinon la requête est rejetée. « Aucune des réponses ci-dessus » et « plusieurs réponses correctes » sont des réponses valides des validateurs et entraînent également le rejet de la requête.
5. Kappa de Cohen calculé pour chaque paire de validateurs. Chaque requête avait exactement 2 évaluateurs (les non-rédacteurs du pool de 3 modèles), si bien que les 3 paires possibles excluant le rédacteur nous donnent 3 valeurs de kappa distinctes par domaine. Nous les rapportons individuellement et sous forme de moyenne pondérée par n.

Kappa de Cohen par paire avec accord observé po et accord aléatoire attendu pe, calculé sur les requêtes acceptées plus tous les rejets consensus_fail où les deux validateurs ont pris une décision. Les cellules indiquent n / po / pe / κ :

La moyenne pondérée par n est un résumé descriptif, pas une statistique inférentielle. Elle condense les trois kappas par paires en un seul nombre pondéré par le nombre de requêtes que chaque paire a jugées ; ce n’est pas en soi une valeur de kappa pour un jeu de données agrégé, et un intervalle de confiance sur ce nombre devrait être calculé par rééchantillonnage bootstrap au niveau des requêtes (reporté à la v2.1).

Nous avons utilisé le kappa de Cohen (et non le kappa de Fleiss ni l’alpha de Krippendorff) car chaque requête comptait exactement 2 évaluateurs : le cadrage naturel est ici 3 calculs de Cohen par paires, puisque nous voulons savoir si deux modèles précis sont d’accord, et non si un panel de 3 évaluateurs est cohérent. L’alpha de Krippendorff donnerait un seul nombre, mais mélangerait les trois paires et masquerait la variance au niveau des paires.

Sur CUAD en particulier : Claude × Qwen atteint κ=0.974 tandis que Claude × Gemini et Gemini × Qwen se situent autour de κ=0.86, ce qui désigne Gemini-3-flash-preview comme le juge le plus bruyant sur les contrats juridiques. Cette information est un signal méthodologique qu’il vaut mieux faire remonter plutôt que d’effacer par une moyenne.

Nous avons promu un domaine en production après que la moyenne pondérée par n du kappa a dépassé 0.85. Les trois l’ont dépassée. Le score de 0.986 de MedRAG est pratiquement un plafond : les deux désaccords sur 156 tentatives portaient sur des cibles médicalement ambiguës où les deux validateurs étaient cohérents en interne, mais où l’un a choisi un résumé lié mais non pertinent.

Règles R9 d’anonymisation des entités (par domaine)

R9 est une contrainte stricte au moment de la génération des requêtes. Sans elle, BM25 dépasse les 0.97 de nDCG@10 car les entités nommées servent de raccourcis par mots-clés parfaits ; les embeddings denses n’ont alors plus aucun avantage sémantique mesurable. La règle est adaptée à chaque domaine afin que les ancrages qui portent réellement le signal de recherche dans ce domaine restent utilisables :

• CUAD strict. Interdire toutes les entités nommées : noms de parties, noms d’États américains, personnel, montants monétaires en dollars exacts, noms de produits spécifiques. Forcer l’unicité descriptive : secteur + rôle + époque + fourchette monétaire + périmètre géographique. Le plafond de BM25 est passé de 0.97 à 0.591 après l’application de R9.
• TechQA Option X. Les noms de produits IBM sont autorisés (ils constituent le principal signal de recherche pour un administrateur système) SI la requête contient aussi un ancrage descriptif secondaire non lié au produit (classe de symptôme, famille de codes d’erreur, époque de version, contexte de déploiement). Les noms de clients, les États américains et le personnel restent interdits. Plafond BM25 : 0.664.
• MedRAG assoupli sur le médical + sans hallucination. Les noms de médicaments, les termes de maladies, l’anatomie et les symboles de gènes sont conservés tels quels depuis la source, car remplacer les étiquettes de classes de médicaments risque des hallucinations pharmacologiques (« la p-chloroamphetamine est un libérateur de sérotonine de la classe des amphétamines », mais les traductions d’étiquettes par LLM de médicaments plus rares échouent silencieusement). La requête doit contenir ≥ 2 ancrages non médicamenteux afin qu’une correspondance purement par nom de médicament n’emporte pas le résultat. Plafond BM25 : 0.809 (propriété structurelle du domaine, pas un défaut de méthodologie).

Exemples de requêtes

Pour chaque exemple, la requête est le texte que nous transmettons au modèle d’embedding. Le document de référence est l’élément unique du corpus (parmi 509 contrats CUAD, 28 000 notes techniques TechQA ou 50 000 résumés PubMed) qui répond réellement à la requête. La tâche de recherche consiste à : encoder la requête, calculer la similarité cosinus avec chaque document du corpus et les classer. Si le document de référence arrive au rang 1, la requête obtient 1.000 de nDCG@3 ; au rang 2, elle obtient 0.631 ; au rang 3, 0.500 ; au-delà du top 3, 0.

CUAD (juridique)

Requête :

Document de référence (1 sur 509 contrats CUAD) : ANIXABIOSCIENCESINC_06_09_2020-EX-10.1-COLLABORATION AGREEMENT. Il s’agit d’une collaboration de 2020 entre une entreprise allemande et une biotech américaine pour la découverte de médicaments contre la COVID-19 ; le contrat prévoit un paiement d’étape lorsque le premier patient entre en phase I d’un essai clinique. La requête ne contient aucun nom de partie, aucun montant monétaire et aucune géographie au-delà de deux tokens de pays ; le signal de recherche est sectoriel + temporel + structure d’étape.

TechQA (support client)

Requête :

Document de référence (1 sur 28 000 notes techniques IBM) : swg1IY43185, qui documente exactement ce bug WebSEAL et nomme le correctif qui le résout. Le nom de produit IBM (WebSEAL) est autorisé dans notre variante R9 TechQA, mais le critère discriminant est le schéma comportemental du bug et l’ancrage d’ordre des requêtes, pas le seul nom de produit.

MedRAG (santé)

Requête :

Document de référence (1 sur 50 000 résumés PubMed) : PMID:231299, un essai clinique comparant les taux d’abandon pour effets indésirables entre la céphradine et la pivmécillinam chez des femmes enceintes atteintes d’infections urinaires. Les noms de médicaments sont conservés parce que la comparaison médicament contre médicament est le signal de recherche, mais la requête ajoute la population de patients + la durée du traitement + le cadrage des événements indésirables afin qu’une correspondance BM25 purement par nom de médicament n’atteigne pas la cible toute seule.

Protocole statistique

Les intervalles de confiance bootstrap à 95 % utilisent 10 000 rééchantillonnages, la méthode des percentiles, seed=2026 sur le vecteur de métrique par requête. Bootstrap apparié sur les mêmes indices de requêtes pour la significativité par paires entre le modèle A et le modèle B (une affirmation exige ≥95 % des rééchantillonnages où A > B).

Une seule exécution par cellule (modèle, domaine). Une couche de variance inter-sessions sur 3 exécutions est reportée à la v2.1 pour des raisons de coût. Les appels API d’embedding au sein d’une session sont déterministes à quelques parties par million près en différence cosinus, vérifié par des contrôles ponctuels ; l’intervalle de confiance bootstrap capture donc le bruit au niveau des requêtes, qui est la source de variance dominante à n=150-246.

Indexation et notation

Pas de base de données vectorielle. Chaque modèle encode une fois chaque document du corpus ; la similarité cosinus est calculée directement dans NumPy sous forme de produit matriciel dense d’embeddings normalisés L2. C’est exact, pas approximatif, donc les égalités de rang sont de véritables égalités de modèles et non des artefacts ANN.

Règle de découpage par modèle : les modèles à contexte de 512 découpent avec un chevauchement de 512+64 ; les modèles à contexte de 8K-20K découpent selon le contexte sans chevauchement ; les modèles à contexte de 32K et plus ingèrent le document complet lorsqu’il tient (les 9 % de queue longue de CUAD dépassent toutes les fenêtres de contexte non-Nemotron et basculent sur le découpage ; l’équité entre modèles est préservée en appliquant la même politique selon la taille de contexte à chaque modèle).

L’invocation asymétrique de recherche propre à chaque modèle est le détail méthodologique le plus important et mérite une section dédiée. C’est la raison pour laquelle gemini-embedding-2-preview obtient 0.46 de nDCG@10 avec l’exemple de code documenté d’OpenRouter, contre 0.91 avec le format Vertex IA de Google. Voir « Comment le pipeline de recherche par embedding a été évalué » ci-dessus pour le tableau par famille.

Framework d’évaluation : ranx comme moteur de métrique principal ; sortie de type trec_eval compatible avec les soumissions au classement MTEB. Intervalle de confiance bootstrap calculé par scripts/bootstrap_ci.py sur les tableaux de métriques par requête sauvegardés lors de la passe d’évaluation.

Modèles testés

Les prix datent du 2026-04-23 et proviennent du catalogue OpenRouter et de la page de tarification directe de Voyage.

nDCG@3 par modèle avec intervalle de confiance bootstrap à 95 %

Intervalles de confiance bootstrap à 95 % calculés par 10 000 rééchantillonnages du vecteur de métrique par requête (méthode des percentiles, seed=2026). Des largeurs d’intervalle de 0.03-0.07 à ces tailles d’échantillon (n=154-246) signifient que les écarts d’estimation ponctuelle inférieurs à environ 0.03 sont dans le bruit et doivent être traités comme des égalités. Trié par nDCG@3 moyen sur les 3 domaines :

Quatre égalités statistiques où les classements par estimation ponctuelle ne sont pas significatifs à un intervalle de confiance de 95 % :

Limites

Revue humaine par un seul auteur : Un auteur a révisé ponctuellement environ 25 % des requêtes finales acceptées pour vérifier le caractère naturel, l’alignement avec la cible et la conformité R9.

Pour approfondir

Explorez d’autres benchmarks RAG, tels que :

• Top 10 modèles d’embedding multilingues pour le RAG
• Top 16 modèles d’embedding open source pour le RAG
• Meilleure base de données vectorielle pour le RAG : Qdrant vs Weaviate vs Pinecone
• Benchmark des rerankers : Top 8 modèles comparés
• Modèles d’embedding multimodaux : Apple vs Meta vs OpenAI

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Modèles embedding: OpenAI vs Gemini vs Voyage}},
  year   = {2026},
  month  = apr,
  howpublished    = {\url{https://aimultiple.com/embedding-models}},
  note   = {AIMultiple. Consulté le 25 Avril 2026}
}

Journal des modifications

5 mises à jour

1. 202629 Juin

   Ajout de la définition de la métrique Top-1 hit à la méthodologie du benchmark d'embeddings.

2. 24 Avr

   Remplacé le benchmark par 15 modèles et une référence BM25 testés sur des corpus juridiques, de support client et de santé.

3. 202525 Nov

   Ajout de la section Raisons potentielles des différences de performance du modèle d'intégration.

4. 18 Juil

   La section Conclusion a été mise à jour avec de nouvelles recommandations de modèles.

5. 10 Juil

   Google a été remplacé par Gemini dans l'introduction.

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA et scientifique des données chez AIMultiple. Il conçoit et exécute des benchmarks pratiques pour les systèmes d'IA et de LLM.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire