Modèles d'embedding: OpenAI vs Gemini vs Voyage

Nous avons évalué 15 modèles d'embedding de texte anglais et une baseline BM25 sur plus de 500 requêtes organisées manuellement dans trois domaines de recherche documentaire : contrats juridiques (CUAD), support client (IBM TechQA) et santé (MedRAG PubMed).

Voyage-3.5 arrive en tête du classement général. Perplexity Embed V1 0.6b atteint le niveau moyen-supérieur au prix le plus bas de notre benchmark.

Résultats du benchmark des modèles d'embedding

Explication des métriques

nDCG@3 : Gain cumulé actualisé normalisé avec un seuil à 3. Avec un document pertinent par requête, il vaut 1 / log2(rang + 1) lorsque le document de référence se classe 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 nDCG@3 comme métrique principale car les pipelines de production RAG fournissent les 3 à 5 meilleurs segments au LLM, et le biais de primauté rend le rang 1 disproportionnellement important.

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

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

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

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

nDCG@3 par domaine

Juridique (CUAD, 246 requêtes, 509 contrats) : Le domaine juridique est le seul 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 11 avec 0.6430, derrière 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 au rang 7 (0.8856), 0.045 derrière son modèle plus récent sur TechQA, même s'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 dans le groupe de tête. Plancher BM25 : 0.7862, à 0.02 du modèle dense le plus faible. gemini-embedding-001 bat également gemini-embedding-2-preview avec son écart le plus important ici (+0.013).

Les inversions au niveau des domaines justifient le cadrage de la moyenne sur 3 domaines : aucun domaine unique ne reflète équitablement « quel modèle est le meilleur », et un acheteur qui se base sur un seul domaine classera mal les autres.

Les intervalles de confiance bootstrap par modèle de 95 % pour chaque cellule de domaine, ainsi que les quatre égalités par paires que les classements par estimation ponctuelle masquent, sont détaillés 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 prix catalogue pour l'embedding de 1M tokens d'entrée, en date du 2026-04-23. Les prix Voyage proviennent de la page de tarification directe de Voyage. Les modèles servis par OpenRouter utilisent un 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 sur axe logarithmique. Le coût réel en auto-hébergement est de $0.

Moyenne nDCG@3 sur 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 à coût prioritaire, pplx-embed-v1-0.6b est le choix évident. À $0.004/M, il est 30-50x moins cher que n'importe quel modèle commercial phare 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 la RAG d'entreprise orientée qualité, voyage-3.5 via le SDK direct Voyage occupe le meilleur point Pareto. Vous échangez une intégration API supplémentaire (par rapport à une pile exclusivement OpenRouter) contre un modèle légèrement meilleur que le produit phare de Voyage à moitié prix. L'instinct de « toujours choisir le plus récent et le plus gros » est inadapté au 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 bat 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.

Principales conclusions du benchmark d'embedding

voyage-3.5 remporte la moyenne des 3 domaines et bat le produit phare voyage-4-large à moitié prix

voyage-3.5 obtient en moyenne 0.9429 de nDCG@3 dans les domaines juridique, du support client et de la santé. Le produit phare voyage-4-large obtient en moyenne 0.9416 à $0.12 par 1M tokens, soit 2x le prix de voyage-3.5 ($0.06). Le produit phare remporte TechQA de 0.002 et MedRAG de 0.032. Il perd sur CUAD de 0.037 (0.8730 vs 0.9102), ce qui suffit à placer sa moyenne sur 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 produit phare ne justifie son prix premium que sur la santé.

Voyage a occupé la première place sur les trois domaines et a réalisé un doublé sur CUAD et TechQA. Sur MedRAG, gemini-embedding-001 s'est hissé à la 2nd place (0.9814, derrière voyage-4-large avec 0.9855), devant tous les autres modèles Voyage. gemini-001 atteint également la troisième place sur CUAD. Aucun autre modèle non-Voyage n'atteint le top 2 sur un domaine donné.

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 l'emporte que sur 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). Le cadrage « mise à niveau multimodale plus récente » de Gemini 2 ne tient pas en recherche textuelle anglaise sur des 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 2nd place, 2-preview à la 3rd place) est suffisamment nette 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 en milieu de classement en juridique et en support client

openai/text-embedding-3-large se classe 11 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 produits phares Voyage Série 4 à $0.12, voyage-3.5 à moitié prix, voyage-4-lite à 1/6 du prix, les deux variantes Qwen3 embedding, intfloat/e5-large-v2 à 1/13 du prix, et perplexity/pplx-embed-v1-0.6b (0.8031) à 1/32 du prix. Le produit phare d'OpenAI est 9 sur TechQA (0.8581) et 11 sur MedRAG (0.9296). Le domaine de la santé le place dans un groupe de tête resserré (écart de la 2nd à la 11 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 un supplément 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 produits 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 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 à coût prioritaire où l'embedding représente un poste de coût important, pplx-0.6b est le choix évident. L'écart de 30-50x par rapport aux prix des produits phares n'apporte rien en qualité de recherche documentaire, du moins dans 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 est à 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 denses en mots-clés par conception (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 associe 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 riches 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 facteur qui détermine l'apport des embeddings denses.

Spécialistes du domaine vs généralistes selon 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. Seul l'accent des données d'entraînement diffère. Comparer les deux à des généralistes sur CUAD, TechQA et MedRAG isole l'effet de l'entraînement juridique.

Sur CUAD, voyage-law-2 se classe 1st 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 4 avec 0.9020, 0.064 derrière voyage-4-large et 0.063 derrière voyage-3.5. Sur MedRAG, il se classe 6 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 déploie une recherche type CUAD sur openai/text-embedding-3-large obtient 0.6430 de nDCG@3 face à voyage-law-2 à 0.9126, soit un écart de 0.27. Une équipe santé ou support qui choisit voyage-law-2 parce qu'il s'est classé 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 documentaire générique. Une recommandation unique de « meilleur modèle » pour tous les secteurs se trompe dans au moins une direction.

Quand choisir voyage-law-2 : pour la recherche contractuelle sur des corpus juridiques commerciaux qui ressemblent structurellement à CUAD. Quand ne pas le choisir : pour 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 la requête et chaque vecteur de document, puis trions les top-k pour cette requête. Avec un 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 Top-1 hit.

Les encodeurs de requêtes et de documents 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 en applique 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 divise en quatre cas :

Pourquoi nDCG@3 comme métrique principale. Les pipelines de production RAG fournissent les 3 à 5 meilleurs segments au LLM, pas le top 10. Le biais de primauté dans 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 d'embedding

Corpus (sélection des domaines + justification)

Nous avons choisi trois domaines qui sollicitent différentes propriétés de recherche documentaire et couvrent les trois principaux cas de RAG d'entreprise. Chaque corpus est épinglé par SHA256, afin que tout lecteur puisse reproduire la cellule exacte que nous avons exécutée.

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

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

Nos requêtes sont générées par LLM selon une séparation rédacteur-validateur : le LLM qui rédige une requête ne juge jamais sa propre cible de recherche, de sorte que le biais d'auto-évaluation est structurellement exclu. Seuls les deux validateurs non rédacteurs, qui voient les 20 candidats mélangés sans indice sur le document source du rédacteur, décident de l'acceptation. En plus du consensus LLM, nous avons vérifié manuellement environ 25 % des requêtes acceptées (revue par l'auteur de la naturalité 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 fondée sur un document échantillonné au hasard. 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) note 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, pas seulement correspondre au nom) et unique_referent entre 3 et 5 (les ancres descriptives doivent identifier environ un à cinq documents candidats dans le corpus, ni des milliers ni exactement un).
3. Contrôle des négatifs difficiles : nous récupérons les 19 meilleurs documents distracteurs BM25 plus la cible et appliquons un filtre de quasi-doublons par Jaccard (>0.5 → rejette toute la requête comme vérité terrain ambiguë).
4. Validateurs (2 modèles, sans jamais inclure le rédacteur) choisissent indépendamment le document cible parmi l'ensemble mélangé de 20 candidats. Les deux validateurs doivent s'accorder sur l'emplacement exact de la cible, sinon la requête est écartée. « Aucun de ceux-ci » et « plusieurs réponses correctes » sont des réponses de validateur valides qui écartent également la requête.
5. Kappa de Cohen calculé pour chaque paire de validateurs. Chaque requête comptait exactement 2 évaluateurs (les non-rédacteurs du pool de 3 modèles), donc les 3 paires possibles excluant le rédacteur 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 attendu par hasard 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 paire en un seul nombre pondéré par le nombre de requêtes jugées par chaque paire ; elle n'est pas en soi une valeur de kappa pour un ensemble de données agrégé, et son intervalle de confiance 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, car nous voulons savoir si deux modèles spécifiques sont d'accord, et non si un panel de 3 évaluateurs est cohérent. L'alpha de Krippendorff donnerait un nombre unique mais mélangerait les trois paires et masquerait la variance au niveau des paires.

Plus précisément sur CUAD : 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 mettre en évidence plutôt que de lisser.

Nous avons promu un domaine en production après que le kappa moyen pondéré par n a dépassé 0.85. Les trois domaines l'ont dépassé. Le 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 l'un a choisi un résumé apparenté 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 0.97 de nDCG@10 car les entités nommées agissent comme des raccourcis de mots-clés parfaits ; les embeddings denses n'ont alors aucun avantage sémantique à mesurer. La règle est adaptée à chaque domaine afin que les ancres qui portent réellement le signal de recherche dans ce domaine restent utilisables :

• CUAD strict. Interdiction de 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. Imposition d'une unicité descriptive : secteur + rôle + époque + fourchette monétaire + portée géographique. Le plafond BM25 est passé de 0.97 à 0.591 après 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 également une ancre descriptive secondaire non liée au produit (classe de symptôme, famille de codes d'erreur, période de version, contexte de déploiement). Les noms de clients, les États américains et le personnel restent interdits. Plafond BM25 : 0.664.
• MedRAG relâchement médical + protection contre les hallucinations. 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 de provoquer des hallucinations pharmacologiques (« la p-chloroamphétamine 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 ancres non médicamenteuses afin qu'une correspondance par mot-clé sur le seul nom du médicament ne suffise pas à obtenir 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 fournissons 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, puis les classer. Si le document de référence arrive au rang 1, la requête obtient 1.000 en nDCG@3 ; au rang 2, elle obtient 0.631 ; au rang 3, elle obtient 0.500 ; en dessous du top 3, elle obtient 0.

CUAD (juridique)

Requête :

Document de référence (1 parmi 509 contrats CUAD) : ANIXABIOSCIENCESINC_06_09_2020-EX-10.1-COLLABORATION AGREEMENT. Il s'agit d'une collaboration en 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 dû 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 le secteur + l'époque + la structure d'étape.

TechQA (support client)

Requête :

Document de référence (1 parmi 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 discriminant est le schéma comportemental du bug et l'ancre d'ordonnancement des requêtes, pas le seul nom de produit.

MedRAG (santé)

Requête :

Document de référence (1 parmi 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 car la comparaison médicament contre médicament est le signal de recherche, mais la requête ajoute la population de patientes + la durée du traitement + le cadrage des événements indésirables afin qu'une correspondance BM25 sur le seul nom du médicament ne fasse pas ressortir la cible à elle seule.

Protocole statistique

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

Une seule exécution par cellule (modèle, domaine). Une couche de variance inter-sessions à 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 de différence de cosinus près, 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 scoring

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 comme un produit matriciel dense d'embeddings normalisés L2. C'est exact et non approximatif, de sorte que les égalités de rang sont de véritables égalités de modèles et non des artefacts ANN.

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

L'invocation asymétrique de la recherche par 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 selon l'exemple de code documenté d'OpenRouter, contre 0.91 selon 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étriques principal ; sortie de type trec_eval compatible avec les soumissions au classement MTEB. Les intervalles de confiance bootstrap sont calculés 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 ainsi que de la page de tarification directe de Voyage.

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

Les intervalles de confiance bootstrap à 95 % sont calculés via 10 000 rééchantillonnages du vecteur de métriques 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 la marge de bruit et doivent être traités comme des égalités. Trié par nDCG@3 moyen sur 3 domaines :

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

Limites

Revue humaine par un auteur : Un auteur a vérifié par sondage environ 25 % des requêtes finales acceptées pour la naturalité, l'alignement avec la cible et la conformité R9.

Pour aller plus loin

Découvrez 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
• RAG hybride : améliorer la précision du RAG
• Graphe RAG vs Vecteur RAG

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 d'embedding: OpenAI vs Gemini vs Voyage}},
  year   = {2026},
  month  = apr,
  howpublished    = {\url{https://aimultiple.com/embedding-models}},
  note   = {AIMultiple. Consulté le 25 Avril 2026}
}

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA et analyste de 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