Benchmark de modèles d'embedding open source pour RAG
Nous avons benchmarké 14 modèles d'embedding open source, auto-hébergés sur un seul H100, à travers plus de 500 requêtes de recherche organisées manuellement couvrant des contrats juridiques, des notes techniques de support client et des résumés médicaux. NVIDIA Llama-Embed-Nemotron-8B mène en précision. Côté coût, 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 cumulatif actualisé normalisé au seuil 3. Avec un document pertinent par requête, il vaut 1 / log2(rang + 1) lorsque le document d'or se trouve dans le top 3, et 0 sinon. Le rang 1 donne 1.000, le rang 2 donne 0.631 et le rang 3 donne 0.500. Nous utilisons nDCG@3 comme métrique principale car les pipelines de RAG en production fournissent les 3 à 5 meilleurs fragments au LLM, et le biais de primauté rend le rang 1 disproportionnellement important.
nDCG@10 : Même formule avec un seuil de 10.
Recall@10 : Fraction de requêtes où le document d'or apparaît dans le top 10.
MRR@10 : Rang réciproque moyen au seuil 10. L'or au rang 1 donne 1.000, le rang 2 donne 0.500 et le rang 10 donne 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 d'or pertinent est le tout premier résultat. La métrique la plus stricte et la plus proche d'un flux de travail de recherche sans LLM.
Résultats nDCG@3 par domaine
Le classement moyen cache des 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 dense en entités qui récompense 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), incluant 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 taux horaire divisé par les tokens traités par heure. Le pod que nous avons utilisé était un H100 80GB SXM5 du cloud communautaire RunPod à $2.99/h. Le temps réel 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 taux RunPod du H100 80GB SXM5 du pod communautaire que nous avons utilisé). wall_seconds = le temps réel 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 concret, Nemotron-8B : ($2.99 / 3600) × (1247.8 × 1,000,000 / 46,220,000) = $0.0224 par 1M tokens.
Cinq modèles mènent leur palier de coût (aucune autre ligne n'est à la fois moins chère et mieux notée) : Granite-278m-multilingue 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êmes couvrent 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 le « bon outil » évident pour la recherche RAG médicale sur PubMed. Il obtient nDCG@3 = 0.7084 sur MedRAG, ce qui est inférieur à la baseline 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 son domaine de données d'entraînement :
La raison pour laquelle le spécialiste sous-performe est l'âge et la recette. PubMedBERT est un BERT de 110M paramètres de 2022 avec un mean pooling symétrique et sans préfixe d'instruction. Les généralistes de 2024-2026 sont construits sur des backbones plus grands, des préfixes de requête et de document asymétriques, et des objectifs de recherche affinés par instruction. L'écart architectural importe plus que la correspondance de domaine : un affinage vieux de 4 ans ne peut pas rivaliser avec un moteur de recherche affiné par instruction de génération actuelle, même sur le corpus d'entraînement de l'affinage lui-même.
La règle pour l'acheteur est de tester un spécialiste de domaine contre 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.
Conclusions 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 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 le deuxième SFR-Embedding-2_R (0.9109 0.869, 0.949). Les IC bootstrap sont nettement séparés. La base 8B Llama-3.1, affinée par instruction pour la recherche avec un préfixe côté requête Instruct: …\nQuery: … et un préfixe côté document symétrique, produit une avance absolue de 0.04 nDCG@3 sur la ligne suivante pour les charges de travail 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 ne mène pas : Harrier-oss-v1-0.6b de Microsoft (0.8720) surpasse Nemotron (0.8602) sur les contrats juridiques bien qu'étant 13x plus petit, bien que les IC se chevauchent et que l'avance ne soit pas statistiquement séparée à cette taille d'échantillon.
Un modèle Harrier 0.6B de Microsoft surpasse tous les modèles ouverts de moins de 7B paramètres
Harrier-oss-v1-0.6b de Microsoft (publié en 2026-04 avec une base Qwen3-0.6B et une licence MIT) atteint un nDCG@3 moyen = 0.8911, quatrième au classement général. Il surpasse le 12B KaLM-Gemma3 de Tencent (0.8057, licence communautaire Tencent), le 7B SFR-Embedding-2_R de Salesforce sur CUAD (0.8421 vs Harrier 0.8720), et EmbeddingGemma-300m de Google (0.8706). Sur une comparaison de même architecture, 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 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 au classement moyen, 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 le « bon outil » évident pour un benchmark RAG médical sur PubMed. Il obtient nDCG@3 = 0.7084 sur MedRAG, soit 0.078 absolu en dessous de la baseline 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 110M paramètres de 2022, avec un mean pooling symétrique et sans préfixe d'instruction. Le champ des généralistes de 2024 à 2026 est construit sur des backbones plus grands, des préfixes de requête et de document asymétriques, et des objectifs de recherche affinés par instruction. Sur les requêtes MedRAG qui incluent déjà du vocabulaire médical, la correspondance lexicale de BM25 est naturellement forte, et la spécialisation de PubMedBERT n'y ajoute rien.
La conclusion pratique est de ne pas choisir un embedder spécialiste uniquement sur son nom. Benchmarkez-le sur vos propres requêtes avant de vous engager.
Snowflake Arctic oscille de 0.32 nDCG@3 entre les domaines
snowflake-arctic-embed-l-v2.0 de Snowflake (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, même recette, même format de requête, avec une oscillation de 0.32 point entre deux domaines. D'autres modèles du panel oscillent moins : SFR-2 couvre 0.8421 à 0.9620 (écart 0.12), Nemotron couvre 0.8602 à 0.9629 (écart 0.10), Harrier couvre 0.8408 à 0.9605 (écart 0.12).
Le mécanisme est la composition des données d'entraînement. Arctic a été ajusté 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 importent 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 fonctionnent avec deux backends dans ce benchmark : sentence-transformers (12 modèles) et vLLM (4 modèles). La distinction ne porte pas sur la qualité mais sur l'efficacité d'exécution sur les modèles de 8B paramètres et plus, où la boucle d'inférence Python par défaut de sentence-transformers est trop lente pour être praticable.
La recette par modèle importe 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 type Instruct (Instruct: Given a question, retrieve passages...\nQuery: <text>) tandis que le côté document est simple. 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 mean pooling. La fiche HuggingFace de chaque modèle est la source de vérité pour savoir quelle combinaison de préfixe et de pooling est correcte.
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 + Requête/Document : SFR-2, KaLM-Gemma3, Nemotron-8B, Qwen3-Embedding
- encode_query / encode_document intégrés : 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 :
- Pooling CLS : trio Granite r2, Snowflake Arctic
- Pooling du dernier token : Nemotron, KaLM-Gemma3, SFR-2, jina-v5, Qwen3-Embedding, Harrier
- Mean pooling : EmbeddingGemma, Granite-multilingue, Conan, PubMedBERT, GIST
Utiliser la mauvaise recette dégrade silencieusement la qualité de recherche sans planter. Tout benchmark d'embedders open source devrait inclure un plancher de santé (un Recall@10 inférieur à 0.5 sur tous les domaines pour un modèle est un signal d'alarme de mauvaise configuration, pas un résultat).
Ajouter comme source préféréeMéthodologie du benchmark des modèles d'embedding open source
Trois domaines de recherche ont été évalués : contrats juridiques CUAD (246 requêtes, 509 contrats), notes techniques de support client TechQA (151 requêtes, 28000 notes techniques IBM), 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édent benchmark de modèles d'embedding en anglais : génération de requêtes par consensus de 3 LLM selon le Protocole-A (pool de rédacteurs tournant, évaluateur fixe, deux validateurs non-rédacteurs par tentative), épinglage de corpus par hachage SHA-256, listes blanches de tokens interdits par entité de domaine pour prévenir les raccourcis lexicaux BM25, accord inter-évaluateurs κ de Cohen rapporté par paire de validateurs, rangs de baseline 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 les systèmes de RAG en production consomment) ; 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 le cloud communautaire RunPod
- Template 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 fiche 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 des caractères à
max_seq_length x 4caractè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é dans la fiche HF. Aucun préfixe 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é sur l'ensemble du panel.
- Clé de cache d'embedding : inclut préfixe + tâche + prompt_name + max_seq + backend, pour qu'un échange de préfixe en cours d'exécution ne puisse pas charger silencieusement des embeddings périmés.
- Protocole statistique : 10K rééchantillonnages bootstrap par cellule (modèle, domaine, métrique), IC à 95% par percentile, seed=2026.
Modèles testés
Triés 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 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 au niveau des requêtes intra-exécution, 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 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, 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 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 une passe de 3 exécutions inter-sessions est nécessaire pour déterminer s'il s'agit d'une séparation plutôt que d'un chevauchement.
Limites
Exécution unique par cellule (modèle, domaine). Le tableau des IC bootstrap ci-dessus capture la variance au niveau des requêtes intra-exécution (10K rééchantillonnages, méthode des percentiles, seed=2026), mais la variance d'initialisation du modèle entre sessions n'est pas mesurée. Une passe de 3 exécutions inter-minuit est prévue pour la v2.1. Les égalités plus serrées mises en évidence par le tableau des 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 de la passe multi-exécutions.
Facteur confondant de la longueur de contexte par modèle. Les modèles avec des fenêtres de contexte de 512 tokens (Granite-278m-multilingue, PubMedBERT, Conan, GIST) ne voient que les premiers ~2K caractères de chaque document. Les modèles avec un contexte de 8K ou 32K (Nemotron, KaLM-12B, jina-v5, Harrier, Granite r2 anglais) 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, possiblement Granite-278m-multilingue, possiblement 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 recherche.
Conan-v1 est entraîné en chinois. L'inclure sur des domaines exclusivement en anglais est 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 les données montrent.
Conclusion
NVIDIA Llama-Embed-Nemotron-8B mène avec un nDCG@3 moyen = 0.9249 avec des victoires statistiquement séparées sur TechQA et MedRAG. Le choix open source le mieux classé sous licence sans restrictions (MIT) est Microsoft Harrier-oss-v1-0.6b avec une moyenne de 0.8911. Google EmbeddingGemma-300m fonctionne à un coût environ 4x inférieur pour une légère perte de précision.
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 des bases de données vectorielles pour le RAG : Qdrant vs Weaviate vs Pinecone
- Benchmark des rerankers : Top 8 des modèles comparés
- 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 = {{Benchmark de modèles d'embedding open source pour RAG}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/open-source-embedding-models}},
note = {AIMultiple. Consulté le 3 Juillet 2026}
}Résultats et horodatages de 15 points de données. Téléchargez les données utilisées dans cet article sous forme de fichier ZIP contenant un fichier CSV et un README.
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.