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

NVIDIA Llama-Embed-Nemotron-8B domine en précision. En termes de coût, Google EmbeddingGemma-300m 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é à la 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 nDCG@3 comme métrique principale parce que les pipelines de RAG en production alimentent le LLM avec les 3 à 5 meilleurs segments, et le biais de primauté fait que le rang 1 a une importance disproportionnée.

nDCG@10 : Même formule avec une coupure à 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 à la coupure 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 seul résultat en tête. La métrique la plus stricte et celle qui se rapproche le plus d'un flux de travail de recherche sans LLM.

Résultats nDCG@3 par domaine

Le classement AVG masque les inversions de 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 surpassent). Les contrats juridiques contiennent un langage d'entités dense 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) surpassent BM25 de 0.17 à 0.18 points absolus de nDCG@3.

Les intervalles de confiance bootstrap à 95 % par cellule (modèle, domaine), y compris une égalité à quatre sur MedRAG en tête 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 tarif horaire divisé par les tokens traités par heure. Le pod que nous avons utilisé était un RunPod community-cloud H100 80GB SXM5 à $2.99/h. Le temps écoulé par modèle sur le passage de 551 requêtes et 3 corpus (~46.2M tokens au total) donne les estimations suivantes en $/1M tokens :

La formule :

GPU $/h = $2.99 (le tarif RunPod community H100 80GB SXM5 du pod que nous avons utilisé). wall_seconds = temps écoulé total de chaque modèle sur le passage 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 concret, Nemotron-8B : ($2.99 / 3600) × (1247.8 × 1 000 000 / 46 220 000) = $0.0224 par 1M tokens.

Cinq modèles dominent leur niveau de coût (aucune autre ligne ne coûte moins cher et n'obtient un meilleur score) : 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 s'étendent sur 13x en coût ($0.0017/M à $0.0224/M) et 0.23 nDCG@3 absolu (0.6952 à 0.9249).

Spécialistes de domaine vs généralistes

PubMedBERT, affiné sur des paires titre-résumé de PubMed, est l'« outil approprié » évident pour la recherche de RAG médicale sur PubMed. Il obtient 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 surpassent de 0.22 à 0.25 points absolus sur le domaine de ses données d'entraînement :

La raison de la sous-performance du spécialiste est l'âge et la recette. PubMedBERT est un BERT de 110M paramètres datant de 2022 avec un pooling moyen symétrique et sans préfixe d'instruction. Les généralistes de 2024-2026 reposent sur des backbones plus grands, des préfixes de requête et de document asymétriques et des objectifs de recherche affinés par instructions. L'écart architectural compte plus que l'adéquation au domaine : un modèle affiné il y a 4 ans ne peut pas rivaliser avec un retrieveur affiné par instructions de la génération actuelle, même sur le corpus d'entraînement du modèle affiné.

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

Résultats du benchmark d'embedding open source

L'avance de Nemotron-8B sur TechQA est statistiquement séparée de la deuxième place

Nemotron-8B AVG nDCG@3 = 0.9249. Par domaine, il obtient 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 celui du second SFR-Embedding-2_R (0.9109 0.869, 0.949). Les intervalles de confiance bootstrap sont clairement séparés. La base 8B Llama-3.1, affinée par instructions pour la recherche avec un préfixe côté requête Instruct: …\nQuery: … et un préfixe symétrique côté document, produit une avance absolue de 0.04 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 compte le plus. CUAD est le seul domaine où il ne domine pas : Microsoft Harrier-oss-v1-0.6b (0.8720) surpasse 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 tout modèle open source 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 AVG nDCG@3 = 0.8911, quatrième au classement général. Il surpasse le 12B Tencent KaLM-Gemma3 (0.8057, licence communautaire Tencent), le 7B Salesforce SFR-Embedding-2_R sur CUAD (0.8421 vs Harrier 0.8720), et Google EmbeddingGemma-300m (0.8706). Sur une comparaison d'architecture identique, Harrier-0.6b (0.8911) se situe 0.074 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 restrictions. SFR-2 (CC-BY-NC), Nemotron (NSCL-v1) et jina-v5 (CC-BY-NC) le surpassent dans l'échelle AVG, mais tous trois sont réservés à la recherche ou non commerciaux.

Un embedder spécialiste médical perd face à BM25

PubMedBERT-base-embeddings de NeuML a été affiné sur des paires titre-résumé de PubMed. C'est l'« outil approprié » évident pour un benchmark de RAG médical sur PubMed. Il obtient nDCG@3 = 0.7084 sur MedRAG, ce qui est 0.078 absolu en dessous de la référence lexicale BM25 (0.7862) sur le même corpus. Les généralistes open source de premier plan 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 110M paramètres datant de 2022, avec un pooling moyen symétrique et sans préfixe d'instruction. Le champ des généralistes de 2024 à 2026 repose sur des backbones plus grands, des préfixes de requête et de document asymétriques et des objectifs de recherche affinés par instructions. Sur les requêtes MedRAG qui incluent déjà un vocabulaire médical, la correspondance lexicale de BM25 est naturellement forte, et la spécialisation de PubMedBERT n'ajoute rien par-dessus.

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

Snowflake Arctic varie de 0.32 nDCG@3 selon les domaines

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

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

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

Les modèles d'embedding open source s'exécutent dans deux backends dans ce benchmark : sentence-transformers (12 modèles) et vLLM (4 modèles). La distinction ne concerne pas la qualité, mais 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 praticable.

La recette propre à chaque modèle compte plus que le choix du backend. Les modèles de recherche 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 pooling CLS ; les modèles dérivés de LLM (Llama, Mistral, Qwen3, base Gemma3) utilisent le pooling du dernier token ; les modèles multilingues utilisent souvent le pooling moyen. La carte HuggingFace de chaque modèle fait foi quant à 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

Patrons 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
• Pas de préfixe (symétrique) : trio Granite, Conan, PubMedBERT, GIST

Type de pooling par architecture de base :

• Pooling CLS : trio Granite r2, Snowflake Arctic
• Pooling du dernier token : Nemotron, KaLM-Gemma3, SFR-2, jina-v5, Qwen3-Embedding, Harrier
• Pooling moyen : EmbeddingGemma, Granite-multilingue, Conan, PubMedBERT, GIST

Utiliser la mauvaise recette dégrade silencieusement la qualité de la recherche sans provoquer de crash. Tout benchmark d'embedders open source devrait inclure un plancher 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 de 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 recherche ont été évalués : les contrats juridiques CUAD (246 requêtes, 509 contrats), les notes techniques de support client TechQA (151 requêtes, 28000 notes techniques IBM), les résumés médicaux MedRAG-PubMed (154 requêtes, 50000 résumés). Total de 551 requêtes.

La méthodologie de construction du dataset est partagée avec notre précéden benchmark des modèles d'embedding en anglais : génération de requêtes par consensus Protocol-A à 3 LLM (pool de rédacteurs rotatif, évaluateur fixe, deux validateurs non rédacteurs par tentative), épinglage du corpus par hachage SHA-256, listes blanches de tokens bannis par entité et par domaine pour empêcher les raccourcis lexicaux 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 (RAG-réaliste, ce que consomment les systèmes de RAG en production) ; métriques secondaires nDCG@10, Recall@10, Recall@100, MRR@10, Top-1 hit.

Spécifications spécifiques à l'open source :

• GPU : 1 x NVIDIA H100 80GB SXM5 via RunPod community cloud
• 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.
• Troncature par modèle : troncature au niveau des caractères à max_seq_length x 4 caractères par token, puis le tokenizer du modèle tronque à sa longueur de séquence maximale réelle.
• Recherche asymétrique : chaque modèle qui la prend en charge reçoit le préfixe de requête et de documenté sur la carte HF. Certains ont par défaut documenté l'absence de préfixe.
• Normalisation L2 : appliquée uniformément après le pooling. Certains modèles le font en interne. Nous re-normalisons pour garantir la parité sur l'ensemble.
• Clé de cache d'embedding : inclut préfixe + tâche + prompt_name + max_seq + backend, de sorte 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 percentile 95 %, seed=2026.

Modèles testés

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

Résultats des intervalles de confiance bootstrap à 95 %

Le classement complet ci-dessus est une exécution unique par cellule (modèle, domaine). La variance d'initialisation du modèle entre sessions n'est pas mesurée. Pour capturer la variance intra-exécution au niveau des requêtes, nous rééchantillonnons le vecteur de rang 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 nDCG@3 :

Les IC changent effectivement 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, donc l'avance de Harrier sur CUAD n'est pas clairement 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, donc 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] vs BM25 0.7862) est à la limite du chevauchement. La tendance centrale place clairement le spécialiste en dessous de BM25, mais un passage de 3 exécutions inter-sessions est nécessaire pour trancher entre séparation et chevauchement.

Limites

Une seule exécution par cellule (modèle, domaine). Le tableau d'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 du modèle entre sessions n'est pas mesurée. Un passage de 3 exécutions inter-nuits est prévu pour la v2.1. Les égalités plus serrées mises en évidence par le tableau d'IC (par exemple, l'égalité à quatre sur MedRAG en tête, le chevauchement Harrier-Nemotron sur CUAD, l'inversion marginale PubMedBERT-vs-BM25) bénéficieraient le plus du passage 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é de la recherche.

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

Pour aller plus loin

Explorez d'autres benchmarks de RAG, tels que :

• Top 10 modèles d'embedding multilingues pour RAG
• Modèles d'embedding : OpenAI vs Gemini vs Voyage
• Meilleure base de données vectorielle pour 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
• Hybride RAG : 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  = {{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}
}

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