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

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

Voyage-3.5 se classe premier toutes catégories. Perplexity Embed V1 0.6b atteint le niveau intermédiaire supérieur au prix le plus bas de notre benchmark.

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

Métriques expliquées

nDCG@3 : Gain cumulatif normalisé et actualisé au rang 3. Avec un seul document pertinent par requête, il vaut 1 / log2(rang + 1) lorsque le document de référence apparaît dans le top 3, et 0 sinon. Le rang 1 vaut 1.000, le rang 2 vaut 0.631, le rang 3 vaut 0.500. Nous utilisons nDCG@3 comme métrique principale car les pipelines de RAG en production fournissent les 3 à 5 meilleurs chunks 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 cutoff à 10.

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

MRR@10 : Rang réciproque moyen au cutoff 10. Le document de référence au rang 1 vaut 1.000, au rang 2 0.500, et au rang 10 0.100. Intention similaire à nDCG@3 mais avec une pénalité de rang plus sévère.

Top-1 hit : Fraction de requêtes pour lesquelles le document pertinent de référence est le premier résultat. La métrique la plus stricte et celle qui se rapproche le plus 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 spécialiste voyage-law-2 l'emporte ; ses données d'entraînement optimisées pour CUAD rapportent +0.040 de nDCG@3 par rapport à voyage-4-large. openai/text-embedding-3-large se classe 11ème avec 0.6430, derrière six modèles moins chers. Plancher BM25 : 0.5844.

Support client (TechQA, 151 requêtes, 28,000 technotes IBM) : L'écart entre voyage-4-lite et le modèle suivant est de 0.018. gemini-embedding-001 chute à la 7ème place (0.8856), 0.045 derrière sa version plus récente sur TechQA, bien qu'il l'emporte sur les deux autres domaines. Plancher BM25 : 0.6097.

Santé (MedRAG-PubMed, 154 requêtes, 50,000 résumés) : La santé est le cluster 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 place la plupart des requêtes dans le cluster de tête. Plancher BM25 : 0.7862, à moins de 0.02 du modèle dense le plus faible. gemini-embedding-001 bat également gemini-embedding-2-preview avec la marge la plus large ici (+0.013).

Les inversions au niveau des domaines justifient l'approche de la moyenne sur 3 domaines : aucun domaine unique n'est un proxy fiable pour savoir « quel modèle est le meilleur », et un acheteur qui se base sur un seul domaine fera une erreur de classement sur 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 les classements ponctuels cachent, sont détaillés dans la section méthodologie.

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

Métriques expliquées

Prix par 1M tokens d’entrée est le prix catalogue pour l'embedding de 1M tokens d’entrée, en date du 04-23 2026. 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 tarifés au même taux chez tous les fournisseurs testés. BM25 est tracé à $0.001/M pour le rendu sur l'axe logarithmique. Le véritable coût en auto-hébergement est de 0 $.

La moyenne nDCG@3 sur 3 domaines est la moyenne non pondérée du nDCG@3 par domaine sur les trois corpus. Chaque domaine contribue de manière égale à la moyenne, indépendamment du 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 à 50 fois moins cher que tous les fleurons commerciaux 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 le RAG d'entreprise axé sur la qualité, voyage-3.5 via le SDK direct de Voyage atteint le meilleur point Pareto. Vous troquez une intégration API supplémentaire (par rapport à une pile uniquement OpenRouter) pour un modèle marginalement meilleur que le fleuron de Voyage, à la moitié du prix. L'instinct de « toujours choisir le dernier et le plus gros » est erroné dans le catalogue Voyage.

• Pour les déploiements OSS / auto-hébergés / 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 que nous avons testées, et il est livré avec des poids auto-hébergeables.

• Les fleurons premium (openai-3-large, gemini-2-preview, voyage-4-large, gemini-001) sont tous battus par voyage-3.5 sur la moyenne des 3 domaines, même si voyage-3.5 est 2 à 3 fois moins cher que n'importe lequel d'entre eux.

Principaux enseignements du benchmark d'embedding

voyage-3.5 remporte la moyenne sur 3 domaines et bat le fleuron voyage-4-large à la moitié du prix

voyage-3.5 obtient une moyenne de 0.9429 nDCG@3 sur les domaines juridique, support client et santé. Le fleuron voyage-4-large obtient en moyenne 0.9416 à $0.12 par 1M tokens, soit 2x le prix de voyage-0.06 3.5. Le fleuron l'emporte sur TechQA de 0.002 et sur MedRAG de 0.032. Il perd sur CUAD de 0.037 (0.8730 vs 0.9102), ce qui fait que sa moyenne sur 3 domaines se situe en dessous de voyage-3.5. Dans la gamme Voyage, le modèle intermédiaire plus ancien est le meilleur choix polyvalent. Le fleuron ne justifie son surcoût que sur le domaine de la santé.

Voyage a pris la première place sur les trois domaines et a réalisé un doublé sur CUAD et TechQA. Sur MedRAG, gemini-embedding-001 est entré en 2ème position (0.9814, derrière les 0.9855 de voyage-4-large), 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 en « preview » sur deux domaines sur trois

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 augmentation de prix de 33% ($0.20 vs $0.15 par 1M tokens d'entrée). Le positionnement « mise à niveau multimodale plus récente » de Gemini 2 ne tient pas pour la recherche de texte en anglais 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 2ème place, 2-preview à la 3ème) est suffisamment importante pour qu'un acheteur qui choisirait par défaut le « dernier » modèle perde une qualité mesurable.

OpenAI text-embedding-3-large est de milieu de tableau en juridique et en support client

openai/text-embedding-3-large se classe 11ème 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 fleurons Voyage 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 fleuron d'OpenAI est 9ème sur TechQA (0.8581) et 11ème sur MedRAG (0.9296). Le domaine de la santé le place dans un cluster de tête serré (écart du 2ème au 11ème : 0.05 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 3 domaines ne justifient pas.

pplx-embed-v1-0.6b atteint le premier niveau au trentième du prix des fleurons comparables

perplexity/pplx-embed-v1-0.6b à $0.004 par 1M tokens obtient en moyenne 0.8604 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 gamme. Il bat également openai/text-embedding-3-large de 0.16 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 suivant le moins cher dans le top-10 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 représente un poste de dépense important, pplx-0.6b est le choix évident. L'écart de 30 à 50 fois par rapport aux prix des fleurons n'apporte aucun gain en qualité de récupération, essentiellement dans ces trois domaines.

BM25 se situe à moins de 0.02 du modèle dense le plus faible sur les résumés médicaux

Sur MedRAG-PubMed, BM25 obtient 0.7862 nDCG@3 contre baai/bge-m3 (mode dense) à 0.8038, soit un écart de 0.02. La recherche lexicale s'approche à moins de 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 récupération. Un scorer de type Lucene les fait correspondre directement sans avoir besoin de contexte sémantique.

Un reranker par-dessus BM25 est une alternative plausible et moins chère à un encodeur dense premium pour les corpus riches en mots-clés : l'écart de récupération laissé par BM25 (0.2 nDCG@3 par rapport au premier niveau sur MedRAG) est le genre 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, sur MedRAG de 0.20. La densité du vocabulaire du domaine est le principal déterminant de l'utilité des embeddings denses.

Spécialistes de domaine vs généralistes chez les différents fournisseurs

Voyage facture voyage-law-2 à $0.12/M, comme voyage-4-large. Les deux modèles partagent le même fournisseur, le même tokenizer, le même SDK et le même schéma d'invocation asymétrique. Seule l'accentuation des données d'entraînement diffère. Exécuter les deux contre des 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 4ème avec 0.9020, 0.064 derrière voyage-4-large et 0.063 derrière voyage-3.5. Sur MedRAG, il se classe 6ème avec 0.9409, 0.045 derrière voyage-4-large et 0.041 derrière gemini-embedding-001. L'entraînement juridique améliore le nDCG@3 sur CUAD mais le dégrade sur les deux autres domaines.

Une équipe juridique qui ferait de la recherche de type CUAD avec openai/text-embedding-3-large obtient 0.6430 de nDCG@3 contre 0.9126 pour voyage-law-2, soit un écart de 0.27. Une équipe santé ou support qui choisirait voyage-law-2 parce qu'il est premier sur CUAD perdrait 0.045 par rapport à 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 » pour tous les secteurs se trompe dans au moins un sens.

Quand choisir voyage-law-2 : recherche de contrats sur des corpus juridiques commerciaux ressemblant 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 récupération 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 nous 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 nDCG@3 (notre métrique principale), nDCG@10 (pour la comparabilité BEIR/MTEB), Recall@10 et le taux de hit 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 : la partie requête applique une transformation, la partie 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 récupération de 0.05 à 0.45 de nDCG@10. Notre sélection se divise en quatre catégories :

Pourquoi nDCG@3 comme métrique principale. Les pipelines de RAG en production fournissent les 3 à 5 meilleurs chunks au LLM, pas les top 10. Le biais de primauté dans les LLM à long contexte fait que le rang 1 compte plus que le rang 3, et chaque distracteur qui se place au-dessus du document de référence dans le contexte du LLM est candidat à la confabulation. Les rerankers atténueraient cet effet, mais la plupart des RAG en production fonctionnent sans pour des raisons de coût et de latence, donc 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 ; nDCG@3 a conservé un écart de 0.10 sur les mêmes requêtes. nDCG@10 conserve la comparabilité BEIR mais adoucit les différences en tête de liste qui importent sur le plan opérationnel.

Découvrez davantage de nos benchmarks et analyses basées sur les données dans la recherche Google.

Ajouter comme source préférée

Méthodologie du benchmark des modèles d'embedding

Corpus (choix du domaine et justification)

Nous avons choisi trois domaines qui sollicitent différentes propriétés de récupération et qui couvrent les trois types 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 LLM selon une séparation rédacteur-validateur : le LLM qui rédige une requête ne juge jamais sa propre cible de récupération, 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 indication du document d'ancrage du rédacteur, décident de l'acceptation. En plus du consensus des LLM, nous avons examiné ponctuellement environ 25% de l'ensemble des requêtes acceptées à la main (examen par l'auteur du 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 a passé 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é 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. Scorer (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, pas seulement une correspondance de 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 un seul).
3. Vérification des négatifs durs : Nous extrayons les 19 meilleurs documents distracteurs BM25 plus la cible et exécutons une porte de Jaccard de quasi-doublon (> 0.5 → rejeter la requête entière comme vérité terrain ambiguë).
4. Validateurs (2 modèles, 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 l'emplacement exact de la cible, sinon la requête est rejetée. « Aucune de ces réponses » 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), donc 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 l'accord observé po et l'accord attendu par hasard pe, calculé sur les requêtes acceptées plus tous les rejets consensus_fail où les deux validateurs sont parvenus à 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 que chaque paire a jugées ; il ne s'agit pas en soi d'une valeur de kappa pour un ensemble de données groupé, et l'IC correspondant devrait être calculé par bootstrap au niveau des requêtes (reporté à la v2.1).

Nous avons utilisé le kappa de Cohen (et non le kappa de Fleiss ou l'alpha de Krippendorff) car chaque requête avait exactement 2 évaluateurs : le cadre naturel ici est constitué de 3 calculs de Cohen par paire, 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 seul chiffre mais mélangerait les trois paires et masquerait la variance au niveau des paires.

En ce qui concerne CUAD spécifiquement : Claude × Qwen atteint κ=0.974 tandis que Claude × Gemini et Gemini × Qwen se situent autour de κ=0.86, ce qui isole Gemini-3-flash-preview comme le juge le plus bruité sur les contrats juridiques. Cette information est un signal méthodologique qui mérite d'être mis en évidence, et non d'être noyé dans une moyenne.

Nous avons promu un domaine en production après que le kappa moyen pondéré par n a dépassé 0.85. Les trois l'ont dépassé. Le 0.986 de MedRAG est effectivement 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é lié mais non conforme à l'étalon-or.

Ensemble de règles d'anonymisation des entités R9 (par domaine)

R9 est une contrainte stricte au moment de la génération des requêtes. Sans cela, BM25 s'élève au-dessus de 0.97 nDCG@10 parce que les entités nommées agissent comme des raccourcis parfaits par mots-clés ; 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 récupération 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 : industrie + rôle + ère temporelle + fourchette monétaire + portée géographique. Le plafond BM25 est passé de 0.97 à 0.591 après l'application de R9.
• TechQA Option X. Noms de produits IBM autorisés (ils sont le principal signal de récupération 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, ère de version, contexte de déploiement). Noms de clients, États américains, personnel toujours interdits. Plafond BM25 : 0.664.
• MedRAG assoupli pour le médical + protection contre les hallucinations. Noms de médicaments, termes de maladies, anatomie, symboles de gènes conservés tels quels à partir de la source, car substituer des étiquettes de classe de médicament risque de provoquer une hallucination pharmacologique (« 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 que la simple correspondance par mot-clé du nom du médicament ne détermine pas le résultat. Plafond BM25 : 0.809 (propriété structurelle du domaine, pas un défaut méthodologique).

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 technotes TechQA, ou 50,000 résumés PubMed) qui répond effectivement à la requête. La tâche de récupération consiste à : intégrer la requête, calculer la similarité cosinus avec chaque document du corpus, et les classer. Si le document de référence arrive en première position, la requête obtient 1.000 sur nDCG@3 ; en deuxième position, 0.631 ; en troisième position, 0.500 ; en dessous des trois premiers, 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 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 récupération est la structure industrie + temporel + jalon.

TechQA (support client)

Requête :

Document de référence (1 sur 28,000 technotes IBM) : swg1IY43185, qui documente exactement ce bogue WebSEAL et nomme le correctif qui le résout. Le nom de produit IBM (WebSEAL) est autorisé dans le cadre de notre variante R9 pour TechQA, mais le discriminateur est le modèle comportemental du bogue et l'ancre d'ordre des requêtes, pas le nom du produit seul.

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 souffrant d'infections urinaires. Les noms de médicaments sont conservés car la comparaison médicament contre médicament est le signal de récupération, mais la requête ajoute la population de patients + la durée du traitement + le cadre des événements indésirables afin qu'une simple correspondance BM25 par nom de médicament n'atteigne pas la cible à elle seule.

Protocole statistique

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

Une seule exécution par cellule (modèle, domaine). Une couche de variance inter-session sur 3 exécutions est reportée à la v2.1 pour des raisons de coût. Les appels API d'embedding intra-session sont déterministes à quelques parties par million près de la différence cosinus, vérifiée par des contrôles ponctuels ; l'IC 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 chaque document du corpus une fois ; la similarité cosinus est calculée directement dans NumPy comme un 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èle et non des artefacts de ANN.

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

L'invocation de récupération asymétrique 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 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 récupération par embedding a été évalué » ci-dessus pour le tableau par famille.

Framework d'évaluation : ranx comme moteur de métrique principal ; sortie compatible trec_eval pour les soumissions au classement MTEB. IC 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 sont en date du 04-23 2026, provenant du catalogue OpenRouter et de la page de tarification directe de Voyage.

nDCG@3 par modèle avec IC bootstrap à 95%

Intervalles de confiance bootstrap à 95% calculés via 10,000 rééchantillonnages du vecteur de métrique par requête (méthode des percentiles, seed=2026). Les largeurs d'IC de 0.03 à 0.07 pour ces tailles d'échantillon (n=154-246) signifient que les écarts d'estimation ponctuelle inférieurs à ~0.03 sont dans le 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 ponctuels ne sont pas significatifs à l'IC 95% :

Limites

Révision humaine par un auteur : Un auteur a examiné ponctuellement environ 25% des requêtes finales acceptées pour vérifier le naturel, l'alignement avec la cible et la conformité R9.

Pour aller plus loin

Explorez d'autres benchmarks RAG, tels que :

• Top 10 des modèles d'embedding multilingues pour le RAG
• Top 16 des 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 : Comparaison des 8 meilleurs modèles
• Modèles d'embedding multimodaux : Apple vs Meta vs OpenAI
• RAG hybride : Améliorer la précision du RAG
• Graph RAG vs Vector 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 chez AIMultiple, spécialisé dans l'automatisation intelligente, les GPU, les agents IA et les frameworks RAG.

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