Benchmark des modèles d'embedding open source pour RAG

NVIDIA Llama-Embed-Nemotron-8B est en tête en précision. Côté coût, l’EmbeddingGemma-300m de Google est environ 4x moins cher que Nemotron, au prix d’une légère perte de précision.

Résultats du benchmark des modèles d’embedding open source

Métriques expliquées

nDCG@3 : Gain cumulé actualisé normalisé avec une coupure à 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 et le rang 3 obtient 0.500. Nous utilisons le nDCG@3 comme métrique principale parce que les pipelines RAG de production fournissent les 3 à 5 premiers segments au LLM et que le biais de primauté fait que le rang 1 compte de manière disproportionnée.

nDCG@10 : Même formule avec une coupure à 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 avec une coupure à 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 de requêtes où le document pertinent de référence est le seul premier résultat. La métrique la plus stricte et la plus proche d’un flux de recherche sans LLM.

Résultats nDCG@3 par domaine

Le classement AVG masque les inversions par domaine. Harrier remporte CUAD mais se classe septième sur TechQA. SFR-2 se classe deuxième sur TechQA mais seulement quatrième sur CUAD. KaLM-12B est cinquième sur MedRAG et neuvième sur TechQA. nDCG@3 par domaine :

BM25 est compétitif sur MedRAG (0.7862, battant PubMedBERT et le Granite multilingue) et faible sur CUAD (0.5844, où 11 des 14 modèles denses le dépassent). Les contrats juridiques contiennent un langage dense en entités, ce qui favorise la correspondance lexicale. Sur les résumés médicaux, les meilleurs modèles denses (Nemotron 0.9629, SFR-2 0.9620, jina-v5 0.9523) devancent BM25 de 0.17 à 0.18 point absolu de nDCG@3.

Les intervalles de confiance bootstrap à 95 % par cellule (modèle, domaine), y compris une égalité à quatre au sommet sur MedRAG et un chevauchement Harrier-Nemotron sur CUAD que le classement par estimation ponctuelle aplatit, sont rapportés dans la section méthodologie du benchmark.

Coût par million de tokens

Le coût auto-hébergé est amorti sur le GPU : le taux horaire divisé par les tokens traités par heure. Le pod utilisé était un H100 80GB SXM5 de la communauté RunPod à $2,99/h. Le temps horloge par modèle sur la passe de 551 requêtes et 3 corpus (~46.2M tokens au total) donne les estimations suivantes de $/1M tokens :

La formule :

GPU $/h = $2,99 (le tarif RunPod communautaire du H100 80GB SXM5 du pod que nous avons utilisé). wall_seconds = le temps horloge total de chaque modèle sur la passe de 551 requêtes et 3 corpus. total_tokens ≈ 46.22M (somme des 3 corpus + 551 requêtes, heuristique nombre de caractères ÷ 4).

Exemple de calcul, Nemotron-8B : ($2,99 / 3600) × (1247.8 × 1 000 000 / 46 220 000) = $0,0224 par 1M tokens.

Cinq modèles dominent leur tranche de coût (aucune autre ligne ne coûte moins cher tout en obtenant un score supérieur) : Granite-278m-multilingual en bas de l’échelle des coûts, puis Granite-small-r2, EmbeddingGemma-300m, jina-v5-text-small et Nemotron-8B en haut de l’échelle de qualité. Les extrémités couvrent un facteur 13x en termes de coût ($0,0017/M à $0,0224/M) et 0.23 point absolu de nDCG@3 (0.6952 à 0.9249).

Spécialistes de domaine vs généralistes

PubMedBERT, affiné sur des paires titre-résumé de PubMed, est de toute évidence le « bon outil » pour la recherche RAG médicale sur PubMed. Il obtient un nDCG@3 = 0.7084 sur MedRAG, ce qui est inférieur à la référence lexicale BM25 (0.7862) sur le même corpus. Les généralistes open source modernes le dépassent de 0.22 à 0.25 point absolu sur son domaine de données d’entraînement :

La raison de la sous-performance du spécialiste tient à son ancienneté et à sa recette. PubMedBERT est un BERT de 2022 doté de 110M paramètres, avec un mean pooling symétrique et sans préfixe d’instruction. Les généralistes 2024-2026 reposent sur des backbones plus gros, des préfixes asymétriques requête et document, et des objectifs de retrieval réglés par instructions. L’écart architectural importe davantage que l’adéquation au domaine : un fine-tune vieux de 4 ans ne peut pas rivaliser avec un retriever de génération actuelle, même sur le corpus d’entraînement du fine-tune lui-même.

La règle pour l’acheteur est de tester un spécialiste de domaine face à un généraliste moderne sur des requêtes représentatives avant de le déployer. L’hypothèse « le spécialiste gagnera sur son domaine » n’est plus sûre pour les modèles d’embedding open source en 2026.

Enseignements du benchmark d’embedding open source

L’avance de Nemotron-8B sur TechQA est statistiquement distincte de la deuxième place

Nemotron-8B obtient un nDCG@3 moyen = 0.9249. Par domaine, il atteint 0.8602 sur CUAD, 0.9515 sur TechQA et 0.9629 sur MedRAG. Le résultat TechQA (0.9515 0.923, 0.977) ne chevauche pas la deuxième place, SFR-Embedding-2_R (0.9109 0.869, 0.949). Les intervalles de confiance bootstrap sont nettement séparés. La base 8B Llama-3.1, réglée par instructions pour le retrieval avec un préfixe Instruct: …\nQuery: … côté requête et un préfixe symétrique côté document, produit une avance absolue de 0.04 point de nDCG@3 sur la ligne suivante sur les charges de travail de support de documents longs.

Les deux domaines où Nemotron gagne nettement (TechQA, MedRAG) sont les corpus de documents longs où l’asymétrie des préfixes d’instruction importe le plus. CUAD est le seul domaine où il n’est pas en tête : le modèle de Microsoft, Harrier-oss-v1-0.6b (0.8720), dépasse Nemotron (0.8602) sur les contrats juridiques bien qu’il soit 13x plus petit, même si les intervalles de confiance se chevauchent et que l’avance n’est pas statistiquement séparée à cette taille d’échantillon.

Un modèle 0.6B de Microsoft Harrier surpasse tous les modèles ouverts de moins de 7B paramètres

Microsoft Harrier-oss-v1-0.6b (publié en 2026-04 avec une base Qwen3-0.6B et une licence MIT) obtient un nDCG@3 moyen = 0.8911, quatrième au classement général. Il surpasse le KaLM-Gemma3 12B de Tencent (0.8057, licence communautaire Tencent), le modèle 7B de Salesforce SFR-Embedding-2_R sur CUAD (0.8421 contre 0.8720 pour Harrier), et Google EmbeddingGemma-300m (0.8706). Dans une comparaison à architecture identique, Harrier-0.6b (0.8911) se situe 0.074 point de nDCG@3 au-dessus de Qwen3-Embedding-0.6B (0.8168), construit sur la même base Qwen3-0.6B. Le corpus d’entraînement et la recette d’instruction ont creusé l’écart, pas le nombre de paramètres.

Pour les acheteurs, Harrier est la ligne open source la mieux classée qui soit livrée avec une licence adaptée à un usage commercial sans restriction. SFR-2 (CC-BY-NC), Nemotron (NSCL-v1) et jina-v5 (CC-BY-NC) le dépassent dans le classement AVG, mais tous trois sont réservés à la recherche ou non commerciaux.

Un embedder spécialisé en médecine perd face à BM25

PubMedBERT-base-embeddings de NeuML a été affiné sur des paires titre-résumé de PubMed. C’est de toute évidence le « bon outil » pour un benchmark RAG médical sur PubMed. Il obtient un nDCG@3 = 0.7084 sur MedRAG, soit 0.078 point absolu de moins que la référence lexicale BM25 (0.7862) sur le même corpus. Les meilleurs généralistes open source sur MedRAG se situent bien au-dessus des deux : Nemotron-8B 0.9629, SFR-Embedding-2_R 0.9620, Harrier-oss 0.9605, jina-v5 0.9523, KaLM-Gemma3-12B 0.9453.

C’est l’inversion qui devrait changer la façon dont un acheteur choisit un spécialiste de domaine. PubMedBERT est un BERT de 2022 doté de 110M paramètres, avec un mean pooling symétrique et aucun préfixe d’instruction. Le champ des généralistes 2024 à 2026 repose sur des backbones plus gros, des préfixes asymétriques requête et document, et des objectifs de retrieval réglés par instructions. Sur les requêtes MedRAG qui contiennent déjà un vocabulaire médical, la correspondance lexicale de BM25 est naturellement forte, et la spécialisation de PubMedBERT n’apporte rien de plus.

La conclusion pratique est de ne pas choisir un embedder spécialisé sur la seule base de son nom. Évaluez-le sur vos propres requêtes avant de vous engager.

Snowflake Arctic varie de 0.32 nDCG@3 selon les domaines

Snowflake-arctic-embed-l-v2.0 (568M, Apache-2.0, dérivé de bge-m3-retromae, multilingue) obtient un nDCG@3 = 0.5846 sur les contrats juridiques CUAD et 0.9053 sur les résumés médicaux MedRAG. Même modèle, même recette, même format de requête, avec un écart de 0.32 point entre deux domaines. D’autres modèles du panel varient moins : SFR-2 s’étend de 0.8421 à 0.9620 (écart 0.12), Nemotron de 0.8602 à 0.9629 (écart 0.10), Harrier de 0.8408 à 0.9605 (écart 0.12).

Le mécanisme est la composition des données d’entraînement. Arctic a été réglé sur BEIR, MIRACL et CLEF ; les contrats juridiques n’y sont pas représentés. Pour une charge de travail de retrieval vertical, les données d’entraînement du domaine comptent plus que le nombre de paramètres ou la longueur de contexte.

Comment fonctionne l’inférence d’embedding open source

Les modèles d’embedding open source tournent sur deux backends dans ce benchmark : sentence-transformers (12 modèles) et vLLM (4 modèles). La séparation ne porte pas sur la qualité ; elle concerne l’efficacité d’exécution sur les modèles de 8B et plus, où la boucle d’inférence Python par défaut de sentence-transformers est trop lente pour être exploitable.

La recette propre à chaque modèle compte davantage que le choix du backend. Les modèles de retrieval modernes utilisent des préfixes asymétriques : le côté requête est enveloppé dans un prompt de style Instruct (Instruct: Given a question, retrieve passages...\nQuery: <text>) tandis que le côté document est brut. Le type de pooling varie : les modèles dérivés de BERT utilisent le CLS pooling ; les modèles dérivés de LLM (Llama, Mistral, Qwen3, base Gemma3) utilisent le last-token pooling ; les modèles multilingues utilisent souvent le mean pooling. La carte HuggingFace de chaque modèle fait foi pour la combinaison correcte de préfixe et de pooling.

Niveau de backend :

• vLLM : Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small
• sentence-transformers : Qwen3-0.6B, EmbeddingGemma-300m, trio Granite, SFR-2, Conan-v1, PubMedBERT, GIST, Snowflake Arctic, Microsoft Harrier

Modèles de préfixes asymétriques observés :

• Instruct + Query/Document : SFR-2, KaLM-Gemma3, Nemotron-8B, Qwen3-Embedding
• encode_query / encode_document intégré : EmbeddingGemma, KaLM-Gemma3, Nemotron-8B
• task / prompt_name (paramètre sentence-transformers) : jina-v5, Snowflake Arctic, Harrier
• Aucun préfixe (symétrique) : trio Granite, Conan, PubMedBERT, GIST

Type de pooling par architecture de base :

• CLS pooling : trio Granite r2, Snowflake Arctic
• Last-token pooling : Nemotron, KaLM-Gemma3, SFR-2, jina-v5, Qwen3-Embedding, Harrier
• Mean pooling : EmbeddingGemma, Granite-multilingual, Conan, PubMedBERT, GIST

Utiliser la mauvaise recette dégrade silencieusement la qualité du retrieval sans provoquer de plantage. Tout benchmark d’embedders open source devrait inclure un seuil de contrôle (un Recall@10 inférieur à 0.5 sur tous les domaines pour n’importe quel modèle est un signal d’alarme indiquant une mauvaise configuration, pas un résultat).

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 open source

Trois domaines de retrieval ont été évalués : les contrats juridiques CUAD (246 requêtes, 509 contrats), les notes techniques de support client TechQA (151 requêtes, 28 000 notes techniques IBM), et les résumés médicaux MedRAG-PubMed (154 requêtes, 50 000 résumés). Total de 551 requêtes.

La méthodologie de construction du dataset est partagée avec notre précédent benchmark de modèles d’embedding en anglais : génération de requêtes par consensus Protocol-A à 3 LLM (groupe de rédacteurs tournants, évaluateur fixe, deux validateurs non rédacteurs par tentative), épinglage des corpus par hachage SHA-256, listes blanches de tokens interdits par entité et par domaine pour empêcher les raccourcis lexicaux de BM25, accord inter-évaluateurs κ de Cohen rapporté par paire de validateurs, rangs de référence BM25 synthétisés à partir du champ bm25_rank_at_target déjà présent dans chaque JSON de requête (équivalent Pyserini). Métrique principale : nDCG@3 (réaliste pour le RAG, ce que consomment les systèmes RAG de production) ; métriques secondaires : nDCG@10, Recall@10, Recall@100, MRR@10, Top-1 hit.

Spécifications propres à l’open source :

• GPU : 1 x NVIDIA H100 80GB SXM5 via le cloud communautaire RunPod
• Modèle de pod : runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
• Stack : PyTorch 2.10.0+cu128, vLLM 0.19.1, transformers 5.6.2, sentence-transformers 5.4.1
• Répartition par modèle : chemin principal de la carte HF. ST pour 12 modèles, vLLM pour Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small.
• Découpage par modèle : troncature au niveau caractère à max_seq_length x 4 caractères par token, puis le tokenizer du modèle tronque jusqu’à sa longueur de séquence maximale réelle.
• Retrieval asymétrique : chaque modèle qui le prend en charge reçoit le préfixe requête et documenté dans la carte HF. Aucun préfixe n’est la valeur par défaut documentée pour certains.
• Normalisation L2 : appliquée uniformément après le pooling. Certains modèles le font en interne. Nous re-normalisons pour garantir la parité dans le panel.
• Clé de cache d’embedding : comprend préfixe + tâche + prompt_name + max_seq + backend, afin qu’un changement de préfixe en cours d’exécution ne puisse pas charger silencieusement des embeddings obsolètes.
• Protocole statistique : 10K rééchantillonnages bootstrap par cellule (modèle, domaine, métrique), IC à 95 % par percentile, seed=2026.

Modèles testés

Trié par rang nDCG@3 moyen. Colonne backend : ST = sentence-transformers, vLLM = vLLM 0.19.

Résultats des intervalles de confiance bootstrap à 95 %

Le classement complet ci-dessus repose sur une seule exécution par cellule (modèle, domaine). La variance d’initialisation des modèles entre les sessions n’est pas mesurée. Pour capturer la variance intra-exécution au niveau des requêtes, nous rééchantillonnons le vecteur de rangs par requête pour chaque cellule (modèle, domaine) 10 000 fois avec remise (méthode des percentiles, seed=2026, tailles d’échantillon CUAD n=246, TechQA n=151, MedRAG n=154). IC bootstrap à 95 % par domaine sur le nDCG@3 :

Les IC modifient bien les inversions que les données soutiennent. Sur CUAD, Harrier (0.8720, [0.836, 0.906]) et Nemotron (0.8602, [0.821, 0.897]) se chevauchent, de sorte que l’avance de Harrier sur CUAD n’est pas nettement séparée à cette taille d’échantillon. Sur TechQA, Nemotron (0.9515, [0.923, 0.977]) et SFR-2 (0.9109, [0.869, 0.949]) ne se chevauchent pas, de sorte que l’avance de Nemotron sur TechQA est statistiquement séparée. Sur MedRAG, les quatre premiers (Nemotron 0.9629, SFR-2 0.9620, Harrier 0.9605, jina-v5 0.9523) sont dans les IC les uns des autres et forment une égalité statistique à quatre. L’inversion PubMedBERT-en-dessous-de-BM25 sur MedRAG (0.7084 [0.641, 0.772] contre BM25 0.7862) est à la marge du chevauchement. La tendance centrale place clairement le spécialiste en dessous de BM25, mais une passe de 3 exécutions inter-sessions est nécessaire pour déterminer si elle est séparée plutôt que chevauchante.

Limitations

Une seule exécution par cellule (modèle, domaine). Le tableau des IC bootstrap ci-dessus capture la variance intra-exécution au niveau des requêtes (10K rééchantillonnages, méthode des percentiles, seed=2026), mais la variance d’initialisation des modèles entre sessions n’est pas mesurée. Une passe de 3 exécutions réparties de part et d’autre de minuit est prévue pour la v2.1. Les égalités plus étroites révélées par le tableau des IC (par exemple l’égalité à quatre au sommet sur MedRAG, le chevauchement Harrier-Nemotron sur CUAD, l’inversion marginale PubMedBERT contre BM25) bénéficieraient le plus de la passe multi-exécutions.

Facteur de confusion lié à la longueur de contexte par modèle. Les modèles avec des fenêtres de contexte de 512 tokens (Granite-278m-multilingual, PubMedBERT, Conan, GIST) ne voient que les ~2K premiers caractères de chaque document. Les modèles avec un contexte de 8K ou 32K (Nemotron, KaLM-12B, jina-v5, Harrier, Granite r2 english) voient le document complet. Cela favorise les modèles à long contexte sur TechQA (notes techniques longues) et MedRAG (résumés longs).

Risque de contamination des données d’entraînement MedRAG. Plusieurs des modèles évalués ont été entraînés sur des données dérivées de PubMed (PubMedBERT par définition, peut-être Granite-278m-multilingual, peut-être la base Qwen3). Une partie du gain de nDCG@3 sur MedRAG peut refléter un chevauchement des données d’entraînement plutôt que la qualité du retrieval.

Conan-v1 est entraîné en chinois. L’inclure sur des domaines uniquement en anglais constitue un point de donnée instructif sur le décalage linguistique, plutôt qu’une comparaison équitable de la qualité du retrieval en anglais. Nous attendons à une sous-performance par rapport à ses pairs entraînés en anglais, et c’est ce que montrent les données.

Pour aller plus loin

Explorez d’autres benchmarks RAG, tels que :

• Top 10 des modèles d’embedding multilingues pour le RAG
• Modèles d’embedding : OpenAI vs Gemini vs Voyage
• Top base de données vectorielle pour le RAG : Qdrant vs Weaviate vs Pinecone
• Benchmark de rerankers : les 8 meilleurs 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  = {{Benchmark des modèles d'embedding open source pour RAG}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/open-source-embedding-models}},
  note   = {AIMultiple. Consulté le 10 Août 2026}
}

Journal des modifications

4 mises à jour

Toutes4Général3Méthodologie1

1. 202625 Avr

   Le benchmark Top-K de 16 modèles sur les avis Amazon a été remplacé par un benchmark de 14 modèles avec nDCG@3 et coûts sur CUAD, TechQA et MedRAG.

2. 8 Jan

   Ajout de la section Licence et utilisation commerciale à l'aperçu des modèles d'intégration open source.

3. 6 Jan

   Le benchmark a été étendu pour inclure cinq modèles open source supplémentaires.

4. 6 Jan

   Matériel, taille de lot et précision mis à jour dans la configuration d'évaluation.

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