Modèles d'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 récupération : contrats juridiques (CUAD), support client (IBM TechQA) et santé (MedRAG PubMed).
Voyage-3.5 se classe premier dans l'ensemble. Perplexity Embed V1 0.6b atteint le milieu de gamme 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é décimal normalisé à la limite 3. Avec un document pertinent par requête, il est égal à 1 / log2(rank + 1) lorsque le document de référence se trouve 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 alimentent les 3 à 5 premiers blocs dans le LLM, et le biais de primauté rend le rang 1 disproportionnément important.
nDCG@10 : Même formule avec une limite de 10.
Recall@10 : Fraction de requêtes où le document de référence apparaît dans le top 10.
MRR@10 : Rang réciproque moyen à la limite 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 de requêtes où le document pertinent est le seul résultat en tête. La métrique la plus stricte et celle la plus proche d'un flux de travail de recherche sans LLM.
nDCG@3 par domaine
Juridique (CUAD, 246 requêtes, 509 contrats) : Le juridique est le seul domaine où le spécialiste voyage-law-2 gagne ; ses données d'entraînement adaptées à CUAD paient avec +0,040 nDCG@3 par rapport à voyage-4-large. openai/text-embedding-3-large se classe 11e à 0,6430, en dessous de six modèles moins chers. Plancher BM25 : 0,5844.
Support client (TechQA, 151 requêtes, 28 000 IBM technotes) : L'écart entre voyage-4-lite et le modèle suivant est de 0,018. gemini-embedding-001 chute à la 7e place (0,8856), à 0,045 de son frère cadet plus récent sur TechQA, même s'il gagne 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 obtiennent plus de 0,88) car le vocabulaire médical est riche en mots-clés, ce qui pousse la plupart des requêtes vers le groupe principal. Plancher BM25 : 0,7862, à moins de 0,02 du modèle dense le plus faible. gemini-embedding-001 bat également gemini-embedding-2-preview ici avec son plus large écart (+0,013).
Les inversions au niveau du domaine justifient le cadre de la moyenne sur 3 domaines : aucun domaine unique n'est un proxy équitable pour « quel modèle est le meilleur », et un acheteur choisissant un seul domaine se trompera 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 basés sur l'estimation ponctuelle cachent, sont détaillés dans la section méthodologie.
Précision vs prix : Coût par 1M de tokens
Explication des métriques
Prix par 1M de tokens d'entrée est le prix de liste pour l'embedding de 1M de tokens d'entrée, en date du 2026-04-23. Les prix de Voyage proviennent de la page de tarification directe de Voyage. Les modèles servis par 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 taux chez tous les fournisseurs testés. BM25 est tracé à 0,001 $/M pour le rendu en échelle logarithmique. Le vrai coût auto-hébergé est de 0 $.
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 également à la moyenne, indépendamment du nombre de requêtes.
- Pour les plateformes RAG axées sur les coûts, pplx-embed-v1-0.6b est le choix évident. À 0,004 $/M, il est 30 à 50 fois moins cher que n'importe lequel des 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 à son prix.
- Pour les entreprises RAG axées sur la qualité, voyage-3.5 via le SDK direct de Voyage prend le point Pareto supérieur. Vous échangez 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 « choisissez toujours le plus récent et le plus grand » est faux dans le catalogue de Voyage.
- Pour les déploiements OSS / auto-hébergeables / sur site, qwen3-embedding-8b gagne. 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 est livré avec des poids auto-hébergeables.
- Les fleurons 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 à 3 fois moins cher que n'importe lequel d'entre eux.
Principales conclusions 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 moyenne 0,9429 nDCG@3 sur le juridique, le support client et la santé. Le fleuron voyage-4-large moyenne 0,9416 à 0,12 $ par 1M de tokens, soit 2 fois le prix de 0,06 $ de voyage-3.5. Le fleuron gagne TechQA de 0,002 et gagne MedRAG de 0,032. Il perd CUAD de 0,037 (0,8730 contre 0,9102), suffisamment pour que sa moyenne sur 3 domaines soit inférieure à celle de voyage-3.5. Dans la gamme de Voyage, l'ancien modèle de milieu de gamme est le meilleur choix polyvalent. Le fleuron ne justifie sa prime que dans le domaine de la santé.
Voyage a pris la première place sur les trois domaines et a balayé le top-2 sur CUAD et TechQA. Sur MedRAG, gemini-embedding-001 est entré en 2e place (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 seul domaine.
Un modèle Gemini legacy bat son frère « preview » plus récent sur deux des trois domaines
google/gemini-embedding-001 (sorti en juin 2025) surpasse google/gemini-embedding-2-preview à la fois sur CUAD (0,8980 contre 0,8958) et MedRAG (0,9814 contre 0,9685). Le modèle plus récent ne gagne que TechQA (0,9301 contre 0,8856), un écart de 0,04 qui s'accompagne d'une augmentation de prix de 33 % (0,20 $ contre 0,15 $ par 1M de tokens d'entrée). Le cadre « mise à jour multimodale plus récente » de Gemini 2 ne tient pas pour la récupération 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 en 2e, 2-preview en 3e) est suffisamment grande pour qu'un acheteur se fiant au modèle « le plus récent » perde une qualité mesurable.
OpenAI text-embedding-3-large est de milieu de gamme en juridique et en support client
openai/text-embedding-3-large se classe 11e sur 15 modèles denses sur CUAD à 0,6430 nDCG@3. Huit modèles strictement moins chers le battent sur les contrats juridiques : les deux fleurons de la série Voyage 4 à 0,12 $, voyage-3.5 à la moitié du 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 de OpenAI est 9e sur TechQA (0,8581) et 11e sur MedRAG (0,9296). La santé le place dans un groupe serré (écart du 2e au 11e : 0,05 nDCG@3). Sur le juridique, l'écart est large et coûteux.
À 0,13 $ par 1M de tokens d'entrée, il est 32 fois plus cher que pplx-embed-v1-0.6b. Les équipes qui se tournent par défaut vers OpenAI 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 haut de gamme à un trentième du prix des fleurons comparables
perplexity/pplx-embed-v1-0.6b à 0,004 $ par 1M de tokens 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 contre 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,5 fois plus), également servi via OpenRouter.
Pour les plateformes RAG axées sur les coûts où l'embedding est une ligne importante, pplx-0.6b est le choix évident. L'écart de 30 à 50 fois par rapport aux prix des fleurons n'achète rien en qualité de récupération, essentiellement sur ces trois domaines.
BM25 est à 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, un écart de 0,02. La recherche lexicale est à 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 riches 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 la majeure partie du signal de récupération. Un scoreur de style Lucene les correspond 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 récupération laissé par BM25 (0,2 nDCG@3 par rapport au haut de gamme sur MedRAG) est du 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 0,36, sur MedRAG 0,20. La densité du vocabulaire du domaine est le plus grand déterminant de l'aide apportée par les embeddings denses.
Spécialistes du domaine vs généralistes chez tous les fournisseurs
Voyage facture voyage-law-2 à 0,12 $/M, identique à voyage-4-large. Les deux modèles partagent le fournisseur, le tokenizer, le SDK et le schéma d'appel asymétrique. Seule l'accentuation des données d'entraînement diffère. L'exécution des 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 à 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 de openai/text-embedding-3-large (0,6430). Sur TechQA, voyage-law-2 se classe 4e à 0,9020, à 0,064 derrière voyage-4-large et à 0,063 derrière voyage-3.5. Sur MedRAG, il se classe 6e à 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 lançant une récupération de style CUAD sur openai/text-embedding-3-large fonctionne à 0,6430 nDCG@3 contre voyage-law-2 à 0,9126, un écart de 0,27. Une équipe de santé ou de support qui choisit voyage-law-2 parce qu'il a été classé premier sur CUAD perd 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 mises à jour plug-and-play pour la récupération générique. Une seule recommandation de « meilleur modèle » à travers les industries se trompe dans au moins une direction.
Quand choisir voyage-law-2 : récupération de contrats sur des corpus juridiques commerciaux qui ressemblent structurellement à CUAD. Quand ne pas le choisir : tout le reste dans ce benchmark. voyage-3.5 est à 0,06 $/M, se classe à 0,0024 en dessous de voyage-law-2 sur CUAD, et le surpasse à la fois sur TechQA et MedRAG.
Ajouter comme source préféréeComment 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 requête et chaque vecteur de document, puis trions le 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 nDCG@3 (notre principal), nDCG@10 (pour la comparabilité BEIR/MTEB), Recall@10 et le taux de Top-1 hit.
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 en applique une autre. L'appel de ces modèles de manière symétrique (« passez simplement le texte ») dégrade silencieusement la qualité de récupération de 0,05 à 0,45 nDCG@10. Notre gamme se divise en quatre :
Pourquoi nDCG@3 comme principal. Les pipelines de production RAG alimentent les 3 à 5 premiers blocs dans le LLM, pas le top 10. Le biais de primauté dans les LLM à contexte long rend le rang 1 plus important que le rang 3, et chaque distracteur qui se trouve au-dessus du document de référence dans le contexte du LLM est un candidat pour la confabulation. Les rerankers aplatisraient cet effet, mais la plupart des RAG de production fonctionnent sans l'un pour des raisons de coût et de latence, donc le rang de l'encodeur EST le rang final.
Sur MedRAG, Recall@10 a atteint le plafond de 1,000 pour trois modèles Voyage et pour qwen3-8b ; nDCG@3 a préservé un écart de 0,10 sur les mêmes requêtes. nDCG@10 conserve la comparabilité BEIR mais adoucit les différences en haut de liste qui comptent opérationnellement.
Méthodologie du benchmark des modèles d'embedding
Corpus (sélection du domaine + pourquoi)
Nous avons choisi trois domaines qui stressent différentes propriétés de récupération et qui couvrent les trois RAG d'entreprise les plus courants. Chaque corpus est ancré 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 petits pour empêcher le problème de raccourci d'entité 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 sous 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 est structurellement exclu. Seuls les deux validateurs non-rédacteurs, voyant les 20 candidats mélangés sans indice sur lequel était le document d'ancrage du rédacteur, décident de l'acceptation. En plus du consensus LLM, nous avons examiné manuellement environ 25 % de l'ensemble de requêtes acceptées (révision par l'auteur de la naturalité de la requête, de l'alignement sur le document cible et de la conformité R9, indépendamment du vote du validateur).
Chaque requête a passé le pipeline suivant avant d'entrer dans l'ensemble de production :
- Rédacteur rédige une seule requête ancrée dans un document échantillonné au hasard. Le rédacteur tourne entre Claude Sonnet 4.6, Qwen3.6-plus, et Gemini 3 Flash preview afin qu'aucun modèle unique ne domine l'empreinte linguistique.
- Scoreur (fixe : Claude Sonnet 4.6) note la requête sur une grille de spécificité. Nous avons requis semantic_bridge ≥ 4 (la requête doit décrire sémantiquement ce que le document affirme, pas seulement correspondre au nom) et unique_referent dans 3-5 (les ancres descriptives doivent identifier environ un à cinq documents candidats dans le corpus, pas des milliers ou exactement un).
- Vérification des faux négatifs : Nous récupérons les 19 documents distracteurs top-19 de BM25 plus la cible et exécutons une porte Jaccard de quasi-duplication (>0,5 → rejeter toute la requête comme vérité terrain ambiguë).
- Validateurs (2 modèles, n'incluant jamais le rédacteur) choisissent indépendamment le document cible parmi l'ensemble mélangé de 20 candidats. Les deux validateurs doivent être d'accord sur l'emplacement exact de la cible ou la requête est rejetée. « Aucun des deux » et « plusieurs bonnes réponses » sont des réponses de validateur valides et rejettent également la requête.
- Cohen's kappa calculé par 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 kappa séparées par domaine. Nous les rapportons individuellement et comme une moyenne pondérée par n.
Cohen's kappa par paire avec accord observé po et 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 montrent 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 ; ce n'est pas elle-même une valeur kappa pour un ensemble de données regroupé, et l'IC à ce sujet devrait être calculé par rééchantillonnage bootstrap au niveau de la requête (reporté à v2.1).
Nous avons utilisé Cohen's kappa (pas Fleiss' kappa ou Krippendorff's alpha) car chaque requête avait exactement 2 évaluateurs : le cadre naturel ici est 3 calculs Cohen par paires car nous voulons savoir si deux modèles spécifiques s'accordent, pas si un panel de 3 évaluateurs est cohérent. Krippendorff's alpha donnerait un seul nombre mais mélangerait les trois paires et cacherait la variance au niveau de la paire.
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 bruyant sur les contrats juridiques. Cette information est un signal de méthodologie qui vaut la peine d'être mis en avant, pas moyenné.
Nous avons promu un domaine en production après que la moyenne κ pondérée par n ait dépassé 0,85. Les trois l'ont dépassé. Les 0,986 de MedRAG sont essentiellement au plafond : les deux désaccords sur 156 tentatives portaient sur des cibles médicalement ambiguës où les deux validateurs étaient intérieurement cohérents mais l'un a choisi un résumé lié mais non-or.
Jeu de règles d'anonymisation des entités R9 (par domaine)
R9 est une contrainte stricte au moment de la génération de requêtes. Sans cela, BM25 monte au-dessus de 0,97 nDCG@10 car les entités nommées agissent comme des raccourcis de mots-clés parfaits ; les embeddings denses n'ont aucun avantage sémantique à mesurer. La règle est adaptée par 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 + gamme monétaire + portée géographique. Le plafond BM25 est tombé de 0,97 à 0,591 après l'application de R9.
- TechQA Option X. Noms de produits IBM autorisés (ils sont le signal de récupération principal pour un administrateur système) SI la requête contient également une ancre descriptive secondaire non-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 médical-assoupli + sûr contre les hallucinations. Noms de médicaments, termes de maladie, anatomie, symboles de gènes conservés à l'identique de la source car la substitution de labels de classe de médicaments risque l'hallucination pharmacologique (« p-chloroamphetamine » est un relâcheur de sérotonine de classe amphetamine, mais les traductions de labels LLM de médicaments plus rares échouent silencieusement). La requête doit contenir ≥2 ancres non-médicaments afin que la correspondance de mots-clés purement nom de médicament ne porte 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 fournissons au modèle d'embedding. Le document de référence est l'élément unique dans le corpus (sur 509 contrats CUAD, 28 000 technotes TechQA, ou 50 000 résumés PubMed) qui répond réellement à la requête. La tâche de récupération est : encoder la requête, calculer la similarité cosinus contre chaque document dans le corpus, et les classer. Si le document de référence atterrit au rang 1, la requête obtient 1,000 sur nDCG@3 ; le rang 2 obtient 0,631 ; le rang 3 obtient 0,500 ; en dessous du top-3 obtient 0.
CUAD (juridique)
Requête :
Document de référence (1 sur 509 contrats CUAD) : ANIXABIOSCIENCESINC_06_09_2020-EX-10.1-COLLABORATION AGREEMENT. C'est une collaboration de 2020 entre une firme allemande et une biotech américaine pour la découverte de médicaments contre le COVID-19 ; le contrat spécifie 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 l'industrie + temporel + structure d'étape.
TechQA (support client)
Requête :
Document de référence (1 sur 28 000 IBM technotes) : swg1IY43185, qui documente exactement ce bug WebSEAL et nomme le correctif qui le résout. Le nom de produit IBM (WebSEAL) est autorisé sous notre variante TechQA R9, mais le discriminateur est le comportement du bug et l'ancre de commande de demande, pas le nom de 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 dus aux réactions indésirables entre la céphradine et le pivmecillinam chez les 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 + durée du traitement + cadre d'événement indésirable afin qu'une correspondance BM25 purement nom de médicament ne place pas la cible 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 signification par paires entre le modèle A et le modèle B (la revendication nécessite ≥95 % des rééchantillonnages où A > B).
Exécution unique par cellule (modèle, domaine). Une couche de variance de 3 exécutions inter-sessions est reportée à v2.1 pour des raisons de coût. Les appels d'API d'embedding intra-session sont déterministes à quelques parties par million de différence cosinus, vérifiés sur échantillon ; l'IC bootstrap capture donc le bruit au niveau de la requête qui est la source de variance dominante à n=150-246.
Indexation et notation
Pas de base de données vectorielle. Chaque modèle encode chaque document de 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 ANN.
Règle de découpage par modèle : modèles 512-ctx découpent 512+64 chevauchement ; modèles 8K-20K-ctx découpent jusqu'au contexte sans chevauchement ; modèles 32K+-ctx ingèrent le document complet lorsqu'il rentre (la longue traîne de 9 % de CUAD dépasse la fenêtre de contexte de chaque modèle non-Nemotron et revient au découpage ; l'équité inter-modèle est préservée en appliquant la même politique par taille de contexte à chaque modèle).
L'appel de récupération asymétrique par modèle est le détail de méthodologie le plus impactant et mérite une section dédiée. C'est la raison pour laquelle gemini-embedding-2-preview obtient 0,46 nDCG@10 sous l'exemple de code documenté de OpenRouter contre 0,91 sous le format Vertex AI 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 de style trec_eval compatible avec les soumissions de classement MTEB. IC bootstrap calculé par scripts/bootstrap_ci.py sur les tableaux de métriques par requête enregistrés lors du passage d'évaluation.
Modèles testés
Les prix sont en date du 2026-04-23 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 à 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és par moyenne nDCG@3 sur 3 domaines :
Quatre égalités statistiques où les classements basés sur l'estimation ponctuelle ne sont pas significatifs à 95 % CI :
Limitations
Révision humaine par un auteur : Un auteur a examiné manuellement environ 25 % des requêtes finales acceptées pour la naturalité, l'alignement sur la cible et la conformité R9.
Conclusion
voyage-3.5 moyenne 0,9429 nDCG@3 sur le juridique, le support client et la santé, battant le propre fleuron de Voyage à la moitié du prix et OpenAI's text-embedding-3-large de 0,13 nDCG@3 à moins de la moitié du prix.
Choisissez pplx-embed-v1-0.6b à 0,004 $/M si le coût d'embedding doit être une erreur d'arrondi. Choisissez voyage-3.5 à 0,060 $/M pour le point Pareto supérieur. Choisissez qwen/qwen3-embedding-8b à 0,010 $/M pour rester OSS. Utilisez voyage-law-2 uniquement pour la récupération juridique adjacente à CUAD, où il achète +0,04 nDCG@3 sur CUAD et rien ailleurs.
Pour aller plus loin
Explorez d'autres benchmarks RAG, tels que :
- Top 10 des modèles d'embedding multilingues pour RAG
- Top 16 des modèles d'embedding open source pour RAG
- Top des bases de données vectorielles pour RAG : Qdrant vs Weaviate vs Pinecone
- Benchmark de reranker : Top 8 modèles comparés
- Modèles d'embedding multimodaux : Apple vs Meta vs OpenAI
- RAG hybride : Amélioration de la précision RAG
- RAG graphique vs RAG vectoriel
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{sar2026,
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}
}
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.