Évaluation comparative des modèles d'incorporation open source pour la RAG

Nous avons évalué 14 modèles d'incorporation open source, hébergés localement sur un seul H100, à l'aide de plus de 500 requêtes de récupération soigneusement sélectionnées couvrant des contrats juridiques, des notes techniques de support client et des résumés médicaux. NVIDIA Llama-Embed-Nemotron-8B est en tête en termes de précision. En matière de coût, le modèle EmbeddingGemma-300m de Google coûte environ 4 fois moins cher que Nemotron, avec une légère perte de précision.

Résultats de l'évaluation comparative des modèles d'incorporation open source

Explication des métriques

nDCG@3 : Gain cumulé actualisé normalisé à la position 3. Avec un document pertinent par requête, la valeur est 1 / log2(rang + 1) si le document attendu figure parmi les 3 premiers résultats, sinon 0. Un document en première position obtient 1,000, en deuxième position 0,631, et en troisième position 0,500. Nous utilisons le nDCG@3 comme métrique principale car les pipelines RAG en production transmettent les 3 à 5 extraits les plus pertinents au LLM, et le biais de primauté rend la première position particulièrement importante.

nDCG@10 : Même formule, avec une limite à 10.

Recall@10 : Proportion de requêtes pour lesquelles le document attendu figure parmi les 10 premiers résultats.

MRR@10 : Rang réciproque moyen à la position 10. Un document attendu en première position obtient 1,000, en deuxième position 0,500, et en dixième position 0,100. Cette métrique a une intention similaire au nDCG@3, mais avec une pénalité plus forte pour les mauvais classements.

Top-1 hit : Proportion de requêtes pour lesquelles le document pertinent attendu est le seul résultat en première position. C'est la métrique la plus stricte, la plus proche d'un workflow de recherche sans LLM.

Résultats du nDCG@3 par domaine

Le classement moyen (AVG) masque certaines inversions par domaine. Harrier gagne sur CUAD mais arrive 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. Voici les résultats du nDCG@3 par domaine :

BM25 est compétitif sur MedRAG (0,7862, surpassant PubMedBERT et le modèle multilingue Granite) mais faible sur CUAD (0,5844, où 11 des 14 modèles denses le surpassent). Les contrats juridiques contiennent un langage riche en entités 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 point en nDCG@3.

Les intervalles de confiance bootstrap à 95 % pour chaque cellule (modèle, domaine), incluant une égalité à quatre sur MedRAG et un chevauchement entre Harrier et Nemotron sur CUAD que le classement ponctuel masque, sont indiqués dans la section méthodologie de l'évaluation.

Coût par million de tokens

Le coût d'hébergement local est amorti sur le GPU : le tarif horaire divisé par le nombre de tokens traités par heure. Le pod utilisé était un H100 80GB SXM5 de RunPod sur le cloud communautaire, à 2,99 $/h. Le temps réel pour chaque modèle sur les 551 requêtes et les 3 corpus (~46,2 millions de tokens au total) donne les estimations suivantes de coût par million de tokens :

La formule :

GPU $/h = 2,99 $ (tarif du H100 80GB SXM5 de RunPod utilisé). wall_seconds = temps réel total de chaque modèle sur les 551 requêtes et les 3 corpus. total_tokens ≈ 46,22 millions (somme des 3 corpus + 551 requêtes, estimation par heuristique : nombre de caractères ÷ 4).

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

Cinq modèles sont en tête de leur catégorie de coût (aucun autre modèle n'est à la fois moins cher et plus performant) : 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 la qualité. Ces modèles s'étendent sur un facteur 13 en coût (0,0017 $/M à 0,0224 $/M) et 0,23 point en nDCG@3 (0,6952 à 0,9249).

Spécialistes par domaine contre généralistes

PubMedBERT, affiné sur des paires titre-résumé de PubMed, semble être l'outil idéal pour la récupération RAG médicale sur PubMed. Il obtient un nDCG@3 = 0,7084 sur MedRAG, ce qui est inférieur au modèle lexical de base BM25 (0,7862) sur le même corpus. Les généralistes open source modernes le surpassent de 0,22 à 0,25 point en nDCG@3 sur son propre domaine d'entraînement :

La raison de cette sous-performance du spécialiste est son âge et sa méthode. PubMedBERT est un modèle BERT de 2022, avec 110 millions de paramètres, utilisant un regroupement moyen symétrique et aucun préfixe d'instruction. Les généralistes de 2024 à 2026 reposent sur des architectures plus grandes, des préfixes asymétriques pour les requêtes et les documents, et des objectifs de récupération affinés par instruction. L'écart architectural est plus déterminant que la correspondance de domaine : un affinage datant de 4 ans ne peut pas rivaliser avec un récupérateur actuel affiné par instruction, même sur son propre corpus d'entraînement.

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'incorporation open source en 2026.

Conclusions tirées de l'évaluation comparative des modèles d'incorporation open source

La première place de Nemotron-8B sur TechQA est statistiquement distincte de la deuxième

Nemotron-8B obtient un nDCG@3 moyen de 0,9249. Par domaine, il atteint 0,8602 sur CUAD, 0,9515 sur TechQA et 0,9629 sur MedRAG. Le résultat sur TechQA (0,9515 [0,923, 0,977]) ne chevauche pas celui du deuxième, SFR-Embedding-2_R (0,9109 [0,869, 0,949]). Les intervalles de confiance bootstrap sont clairement séparés. La base Llama-3.1 8B, affinée pour la récupération avec un préfixe asymétrique côté requête (Instruct : …\nQuery : …) et un préfixe symétrique côté document, permet une avance de 0,04 point en nDCG@3 sur la deuxième place pour les tâches de récupération sur de longs documents.

Les deux domaines où Nemotron gagne clairement (TechQA, MedRAG) sont ceux des corpus de longs documents, où l'asymétrie des préfixes d'instruction est la plus déterminante. CUAD est le seul domaine où il ne mène pas : le modèle Harrier-oss-v1-0.6b de Microsoft (0,8720) devance Nemotron (0,8602) sur les contrats juridiques malgré une taille 13 fois inférieure, bien que les intervalles de confiance se chevauchent et que l'avance ne soit pas statistiquement distincte à cette taille d'échantillon.

Un modèle Harrier de Microsoft de 0,6 milliard de paramètres surpasse tous les modèles ouverts de moins de 7 milliards de paramètres

Le modèle Harrier-oss-v1-0.6b de Microsoft (sorti en 2026-04, basé sur Qwen3-0.6B, licence MIT) atteint un nDCG@3 moyen de 0,8911, quatrième au classement général. Il surpasse le modèle KaLM-Gemma3 de 12B de Tencent (0,8057, licence communautaire Tencent), le modèle SFR-Embedding-2_R de Salesforce sur CUAD (0,8421 contre 0,8720 pour Harrier) et le modèle EmbeddingGemma-300m de Google (0,8706). En comparaison d'architecture équivalente, Harrier-0.6b (0,8911) devance de 0,074 point en nDCG@3 Qwen3-Embedding-0.6B (0,8168), construit sur la même base Qwen3-0.6B. C'est la base d'entraînement et la méthode d'instruction qui ont fait la différence, pas le nombre de paramètres.

Pour les acheteurs, Harrier est la meilleure ligne open source classée qui est livrée avec une licence adaptée à une utilisation commerciale sans restrictions. SFR-2 (CC-BY-NC), Nemotron (NSCL-v1) et jina-v5 (CC-BY-NC) le surpassent au classement moyen, mais les trois sont destinés à la recherche uniquement ou à un usage non commercial.

Un intégrateur spécialisé en médecine perd face à BM25

Le modèle PubMedBERT-base-embeddings de NeuML a été affiné sur des paires titre-résumé de PubMed. Il semble être l'outil idéal pour un benchmark RAG médical sur PubMed. Il obtient un nDCG@3 = 0,7084 sur MedRAG, soit 0,078 point en dessous du modèle lexical de base BM25 (0,7862) sur le même corpus. Les meilleurs généralistes open source sur MedRAG sont 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.

Cette inversion devrait changer la manière dont un acheteur choisit un intégrateur spécialisé par domaine. PubMedBERT est un modèle BERT de 2022 avec 110 millions de paramètres, utilisant un regroupement moyen symétrique et aucun préfixe d'instruction. Le champ des généralistes de 2024 à 2026 repose sur des architectures plus grandes, des préfixes asymétriques pour les requêtes et les documents, et des objectifs de récupération affinés par instruction. Sur les requêtes MedRAG qui contiennent déjà du vocabulaire médical, la correspondance lexicale de BM25 est naturellement forte, et la spécialisation de PubMedBERT n'ajoute rien de plus.

La conclusion pratique est de ne pas choisir un intégrateur spécialisé uniquement par son nom. Testez-le sur vos propres requêtes avant de vous engager.

Snowflake Arctic varie de 0,32 point en nDCG@3 selon les domaines

Le modèle snowflake-arctic-embed-l-v2.0 de Snowflake (568M, licence 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. Le même modèle, la même méthode, le même format de requête, avec une variation de 0,32 point entre deux domaines. D'autres modèles varient moins : SFR-2 de 0,8421 à 0,9620 (écart de 0,12), Nemotron de 0,8602 à 0,9629 (écart de 0,10), Harrier de 0,8408 à 0,9605 (écart de 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 récupération verticale, les données d'entraînement par domaine sont plus importantes que le nombre de paramètres ou la longueur de contexte.

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

Fonctionnement de l'inférence d'incorporation open source

Les modèles d'incorporation open source ont été exécutés sur deux backends dans cette évaluation : sentence-transformers (12 modèles) et vLLM (4 modèles). Cette répartition ne concerne pas 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 utilisable.

La méthode par modèle importe plus que le choix du backend. Les modèles modernes de récupération utilisent des préfixes asymétriques : le côté requête est encadré par un prompt de type Instruct (Instruct: Given a question, retrieve passages...\nQuery: <text>), tandis que le côté document est brut. Le type de regroupement varie : les modèles dérivés de BERT utilisent le regroupement CLS ; les modèles dérivés de LLM (Llama, Mistral, Qwen3, base Gemma3) utilisent le regroupement du dernier token ; les modèles multilingues utilisent souvent le regroupement moyen. La fiche HuggingFace de chaque modèle est la référence pour connaître la combinaison correcte de préfixe et de regroupement.

Catégories de backend :

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

Modèles de préfixe asymétrique 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) : la trilogie Granite, Conan, PubMedBERT, GIST

Type de regroupement selon l'architecture de base :

• Regroupement CLS : la trilogie Granite r2, Snowflake Arctic
• Regroupement du dernier token : Nemotron, KaLM-Gemma3, SFR-2, jina-v5, Qwen3-Embedding, Harrier
• Regroupement moyen : EmbeddingGemma, Granite-multilingual, Conan, PubMedBERT, GIST

L'utilisation d'une mauvaise méthode dégrade silencieusement la qualité de récupération sans provoquer d'erreur. Toute évaluation comparative de modèles d'incorporation open source devrait inclure un seuil de vérification (un Recall@10 inférieur à 0,5 sur tous les domaines pour un modèle est un signal d'alerte indiquant une mauvaise configuration, pas un résultat).

Méthodologie de l'évaluation comparative des modèles d'incorporation open source

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

La méthodologie de construction des données est la même que celle de notre benchmark précédent des modèles d'incorporation anglais : protocole A de génération de requêtes par consensus de 3 LLM (pool d'auteurs rotatif, correcteur fixe, deux validateurs non auteurs par tentative), verrouillage du corpus par hachage SHA-256, listes blanches de jetons interdits par domaine pour éviter les raccourcis lexicaux de BM25, accord inter-juges κ de Cohen rapporté par paire de validateurs, classements de base BM25 synthétisés à partir du champ bm25_rank_at_target déjà présent dans chaque requête JSON (équivalent Pyserini). Métrique principale : nDCG@3 (réaliste pour la RAG, ce que les systèmes RAG en production utilisent) ; métriques secondaires : nDCG@10, Recall@10, Recall@100, MRR@10, Top-1 hit.

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

• GPU : 1 × NVIDIA H100 80GB SXM5 via le cloud communautaire RunPod

• Modèle de pod : runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404

• Pile technique : 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 4 caractères par token, puis le tokenizer du modèle tronque à sa longueur de séquence maximale réelle.

• Récupération asymétrique : chaque modèle qui le prend en charge reçoit le préfixe requête/document documenté sur la fiche HF. L'absence de préfixe est le paramètre par défaut documenté pour certains.

• Normalisation L2 : appliquée uniformément après regroupement. Certains modèles le font en interne. Nous normalisons à nouveau pour garantir l'équité entre tous les modèles.

• Clé du cache d'incorporation : inclut préfixe + task + prompt_name + max_seq + backend, afin qu'un changement de préfixe en cours d'exécution ne puisse pas charger silencieusement des incorporations obsolètes.

• Protocole statistique : 10 000 rééchantillonnages bootstrap par cellule (modèle, domaine, métrique), intervalle de confiance à 95 % par méthode des percentiles, graine=2026.

Modèles testés

Classé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 basé sur une seule exécution 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 dans une même exécution, nous rééchantillonnons 10 000 fois avec remise le vecteur de rang par requête pour chaque cellule (modèle, domaine) (méthode des percentiles, graine=2026, tailles d'échantillon : CUAD n=246, TechQA n=151, MedRAG n=154). Intervalle de confiance bootstrap à 95 % par domaine sur le nDCG@3 :

Les IC modifient 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 distincte. 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é à quatre. L'inversion PubMedBERT en dessous de BM25 sur MedRAG (0,7084 [0,641, 0,772] contre BM25 0,7862) est à la limite du chevauchement. La tendance centrale place clairement le spécialiste en dessous de BM25, mais une passe sur 3 sessions est nécessaire pour déterminer si l'écart est réellement distinct ou simplement chevauchant.

Limites

Une seule exécution par cellule (modèle, domaine). Le tableau des IC bootstrap ci-dessus capture la variance au niveau des requêtes dans une même exécution (10 000 rééchantillonnages, méthode des percentiles, graine=2026), mais la variance d'initialisation du modèle entre sessions n'est pas mesurée. Une passe sur 3 sessions à des moments différents est prévue pour la version 2.1. Les égalités plus serrées mises en évidence par le tableau des IC (par exemple, l'égalité à quatre sur MedRAG, le chevauchement Harrier-Nemotron sur CUAD, l'inversion marginale PubMedBERT contre BM25) bénéficieraient le plus d'une passe multi-session.

Confound par longueur de contexte du modèle. Les modèles avec une fenêtre de contexte de 512 tokens (Granite-278m-multilingual, PubMedBERT, Conan, GIST) ne voient que les premiers ~2000 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 (longues notes techniques) et MedRAG (longs résumés).

Risque de contamination des données d'entraînement sur MedRAG. Plusieurs modèles évalués ont été entraînés sur des données dérivées de PubMed (PubMedBERT par définition, éventuellement Granite-278m-multilingual, éventuellement la base Qwen3). Une partie du gain en nDCG@3 sur MedRAG pourrait refléter un chevauchement des données d'entraînement plutôt qu'une qualité de récupération.

Conan-v1 est entraîné sur du chinois. L'inclure sur des domaines uniquement en anglais est un point de données instructif sur le désaccord linguistique, pas une comparaison équitable de la qualité de récupération en anglais. Nous nous attendons à une sous-performance par rapport aux homologues entraînés en anglais, et c'est ce que montrent les données.

Pour aller plus loin

Découvrez d'autres benchmarks RAG, tels que :

• Les 10 meilleurs modèles d'incorporation multilingues pour la RAG
• Modèles d'incorporation : OpenAI contre Gemini contre Voyage
• Meilleure base de données vectorielle pour la RAG : Qdrant contre Weaviate contre Pinecone
• Benchmark des rerankers : comparaison des 8 meilleurs modèles
• Modèles d'incorporation multimodaux : Apple contre Meta contre OpenAI
• Hybride RAG : améliorer la précision de la RAG
• Graph RAG contre 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{sar2026,
  author = {Sarı, Ekrem},
  title  = {{Évaluation comparative des modèles d'incorporation open source pour la RAG}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/open-source-embedding-models}},
  note   = {AIMultiple. Consulté le 3 Juillet 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