Étude de cas : EmbeddingGemma ou BGE-M3 pour un RAG local avec Qdrant

Ce que cet article présente :

Le choix entre les deux dépend du type de documents (FAQ courtes vs. manuels longs), des besoins en précision (recherche par mots-clés exacts) et des contraintes matérielles (mémoire vive, GPU), sans solution universelle.
Une validation pratique via Qdrant est recommandée : tester les deux modèles sur un échantillon représentatif de documents et requêtes avant de finaliser le choix, en mesurant temps de réponse, précision et consommation de ressources.
Changer de modèle après mise en production nécessite une réindexation complète des documents, car chaque modèle génère un espace vectoriel distinct incompatible avec les embeddings préexistants.

Dans un système RAG, le modèle d’intelligence artificielle qui rédige la réponse est souvent la partie la plus visible. Pourtant, la qualité du résultat dépend d’abord d’un composant plus discret : le modèle d’embedding chargé de transformer les documents et les questions en vecteurs numériques.

Un mauvais choix peut provoquer des réponses incomplètes, des documents introuvables ou des sources peu pertinentes, même lorsque le modèle génératif utilisé est performant. À l’inverse, un modèle d’embedding correctement sélectionné permet à Qdrant de retrouver les informations réellement utiles avant de les transmettre à Mistral, Llama, Gemma ou à un autre LLM local.

Dans cette étude de cas, Internet Creative Center compare deux modèles multilingues pouvant être installés sur une infrastructure locale : EmbeddingGemma, développé par Google, et BGE-M3, développé par BAAI.

EmbeddingGemma privilégie la légèreté, la souplesse des dimensions et le fonctionnement sur des équipements disposant de ressources limitées. BGE-M3 propose une architecture plus lourde, mais également plus complète, capable d’associer recherche sémantique, recherche lexicale et interaction multivecteur.

La question n’est donc pas de déterminer quel modèle est universellement le meilleur. Il faut identifier lequel correspond réellement aux documents de l’entreprise, aux recherches effectuées par les utilisateurs et aux ressources disponibles sur le serveur d’IA local.

EmbeddingGemma ou BGE-M3 : quel modèle d’embedding choisir pour un RAG local ?

Le contexte : améliorer la recherche documentaire d’un serveur d’IA local

Une entreprise souhaite mettre à disposition de ses collaborateurs un assistant documentaire fonctionnant entièrement sur un serveur local. L’objectif est d’interroger différents types de contenus internes sans transmettre les données à un service d’intelligence artificielle distant.

L’architecture retenue repose sur :

un serveur Linux hébergé dans l’entreprise ;
Qdrant pour le stockage et la recherche des vecteurs ;
n8n pour automatiser l’importation et la mise à jour des documents ;
un modèle d’embedding exécuté localement ;
un modèle Mistral, Llama ou Gemma pour produire les réponses ;
une interface métier accessible uniquement aux utilisateurs autorisés.

Le corpus documentaire présente cependant plusieurs difficultés. Il contient des procédures courtes, des fiches commerciales, des documents techniques en français et en anglais, des références précises, des noms de produits, des numéros de version et des manuels particulièrement longs.

Les utilisateurs ne reprennent pas toujours les termes exacts présents dans les documents. Ils peuvent demander :

Comment réinitialiser le serveur après une interruption ?

alors que la procédure interne utilise l’expression :

Protocole de reprise du service après arrêt non planifié.

Dans ce premier cas, le système doit comprendre que les deux formulations expriment une intention proche. Il s’agit d’une recherche sémantique classique.

D’autres recherches portent au contraire sur des termes extrêmement précis :

une référence produit comme « MED-8520-B » ;
une version logicielle comme « QDRANT-1.15.3 » ;
un numéro de dossier ;
un code d’erreur ;
le nom exact d’une procédure ;
une adresse IP interne ;
un article réglementaire.

Dans ce second cas, une recherche fondée uniquement sur la proximité sémantique peut manquer le document pertinent. Le système doit également tenir compte de la correspondance exacte des mots, des chiffres et des identifiants.

Pourquoi comparer EmbeddingGemma et BGE-M3 ?

EmbeddingGemma est un modèle d’embedding multilingue de 308 millions de paramètres fondé sur la famille Gemma 3. Il a été entraîné sur plus de 100 langues et peut produire des vecteurs dont la dimension varie de 768 à 128 grâce au principe Matryoshka Representation Learning. Sa fenêtre d’entrée atteint 2 048 tokens. Google indique également qu’une version quantifiée peut fonctionner avec moins de 200 Mo de mémoire vive, ce qui le rend particulièrement intéressant pour les installations locales légères.

BGE-M3 compte environ 569 millions de paramètres et génère par défaut des vecteurs denses de 1 024 dimensions. Il accepte des entrées allant jusqu’à 8 192 tokens et prend en charge trois méthodes de recherche : la recherche dense, la recherche sparse ou lexicale et la recherche multivecteur de type ColBERT. Sa documentation indique également une prise en charge de plus de 100 langues.

Ces caractéristiques laissent apparaître deux orientations différentes :

EmbeddingGemma cherche à fournir un excellent rapport entre qualité, vitesse et consommation de ressources ;
BGE-M3 cherche à couvrir plusieurs modes de recherche au sein d’un même modèle, y compris les documents longs et les recherches lexicales précises.

Mais les fiches techniques ne suffisent pas. Un modèle performant dans un benchmark général peut être moins adapté au vocabulaire particulier d’une entreprise. Internet Creative Center a donc défini un protocole permettant de comparer les deux solutions sur les usages réels du futur serveur RAG.

Le protocole de test : confronter les deux modèles aux mêmes documents

Pour éviter une comparaison théorique, les deux modèles doivent être testés dans des conditions identiques. Les documents sont découpés selon la même stratégie, puis indexés dans deux espaces vectoriels séparés.

Une collection Qdrant est créée pour EmbeddingGemma et une seconde pour BGE-M3. Les deux collections utilisent les mêmes contenus, les mêmes métadonnées, les mêmes filtres et la même distance de similarité.

Il est important de ne pas mélanger directement les vecteurs des deux modèles. EmbeddingGemma peut produire des vecteurs de 768, 512, 256 ou 128 dimensions, tandis que BGE-M3 utilise des vecteurs denses de 1 024 dimensions. Une collection vectorielle doit être configurée pour la dimension du modèle qui l’alimente. Qdrant permet également d’utiliser des vecteurs nommés pour préparer progressivement une migration entre plusieurs modèles.

Test 1 : retrouver une information formulée différemment

Le premier test mesure la capacité du modèle à comprendre une intention, même lorsque la question ne reprend aucun des termes principaux du document.

Document indexé :

En cas d’arrêt non planifié, exécuter le protocole de reprise du service depuis la console d’administration.

Question posée :

Comment remettre l’application en fonctionnement après une coupure ?

Les deux modèles sont conçus pour la recherche sémantique multilingue et peuvent établir un rapprochement entre ces formulations. EmbeddingGemma est particulièrement adapté aux applications de recherche, de classification, de regroupement et de similarité sémantique. Google précise également qu’il peut utiliser des instructions distinctes selon que le texte représente une requête ou un document.

Orientation observée : pour des FAQ, des procédures courtes et des questions exprimées en langage naturel, EmbeddingGemma constitue une solution légère et cohérente. BGE-M3 reste également performant dans ce scénario, mais ses fonctionnalités supplémentaires ne sont pas nécessairement exploitées.

Test 2 : rechercher une référence exacte

Document indexé :

Le module MED-8520-B doit être utilisé avec le connecteur CNX-21-USB.

Question posée :

Quel connecteur faut-il pour MED-8520-B ?

Une recherche dense peut comprendre le sens général de la question, mais les références contenant des lettres, des chiffres et des tirets sont parfois difficiles à différencier sémantiquement.

BGE-M3 peut produire simultanément une représentation dense et une représentation sparse. La représentation dense recherche le sens général, tandis que la représentation sparse renforce la correspondance lexicale avec les termes exacts. Qdrant peut fusionner ces deux résultats afin de combiner recherche sémantique et recherche par mots-clés.

Orientation observée : BGE-M3 possède un avantage architectural lorsque le corpus contient de nombreuses références produit, des numéros de dossier, des codes d’erreur, des versions logicielles ou des noms propres peu fréquents.

EmbeddingGemma peut néanmoins être associé à un moteur lexical séparé, par exemple BM25. Cette solution conserve la légèreté du modèle, mais ajoute un composant et une étape de fusion supplémentaires dans le workflow.

Test 3 : interroger un document long

Le troisième test porte sur un manuel dont certaines sections dépassent largement la longueur habituelle d’une fiche produit ou d’une procédure.

EmbeddingGemma accepte jusqu’à 2 048 tokens en entrée, contre 8 192 tokens pour BGE-M3. Ce dernier peut donc traiter des blocs plus longs sans devoir les diviser aussi rapidement.

Cela ne signifie pas qu’il faut systématiquement créer des blocs de 8 192 tokens. Un bloc trop long peut contenir plusieurs sujets et réduire la précision de la recherche. La fenêtre étendue de BGE-M3 offre surtout davantage de souplesse pour les textes juridiques, les rapports, les notices et les documents dont le découpage naturel produit de longues sections.

Le travail de recherche publié avec BGE-M3 montre que l’association de plusieurs modes de récupération améliore particulièrement les résultats sur les documents longs. Les auteurs précisent toutefois que les performances observées sur les benchmarks doivent encore être confirmées sur des corpus réels présentant d’autres caractéristiques.

Orientation observée : BGE-M3 est généralement plus adapté lorsque l’entreprise souhaite indexer de longs documents et exploiter plusieurs stratégies de recherche. EmbeddingGemma reste suffisant lorsque les documents sont correctement découpés en passages courts et cohérents.

Test 4 : évaluer les ressources du serveur local

Le choix d’un modèle d’embedding ne dépend pas uniquement de la pertinence des résultats. Il faut également mesurer :

le temps nécessaire pour indexer les documents ;
le temps de réponse à chaque requête ;
l’utilisation du processeur et du GPU ;
la mémoire vive mobilisée ;
la taille de l’index Qdrant ;
le nombre de requêtes simultanées supportées ;
la durée d’une réindexation complète.

EmbeddingGemma peut réduire sa dimension de sortie de 768 jusqu’à 128. Cette souplesse permet d’adapter la taille des vecteurs au volume documentaire et aux capacités du serveur. Une dimension plus petite réduit le stockage et la mémoire nécessaires, mais doit être validée par des tests afin de vérifier que la qualité de récupération reste suffisante pour le corpus concerné.

BGE-M3 est plus volumineux, mais ses besoins supplémentaires peuvent être justifiés lorsqu’une seule exécution doit produire les représentations dense, sparse et multivecteur.

Test 5 : vérifier le français, l’anglais et les recherches croisées

Les deux modèles sont multilingues. EmbeddingGemma a été entraîné sur des données couvrant plus de 100 langues. BGE-M3 prend également en charge plus de 100 langues, même si sa documentation précise que la quantité de données varie selon les langues et que les résultats peuvent donc être inégaux.

Le test doit notamment vérifier les situations suivantes :

question française et document français ;
question anglaise et document anglais ;
question française et document anglais ;
question anglaise et document français ;
sigles techniques identiques dans les deux langues ;
termes métier propres à l’entreprise.

Aucun résultat global publié ne remplace cette validation. Une entreprise travaillant principalement avec des notices techniques anglaises n’obtiendra pas nécessairement le même classement qu’une organisation indexant des documents administratifs rédigés uniquement en français.

Synthèse de la comparaison

Critère	EmbeddingGemma	BGE-M3
Nombre de paramètres	Environ 308 millions	Environ 569 millions
Longueur maximale	2 048 tokens	8 192 tokens
Dimension dense	768 à 128	1 024
Recherche dense	Oui	Oui
Recherche sparse native	Non présentée comme fonction native	Oui
Interaction multivecteur	Non présentée comme fonction native	Oui, type ColBERT
Multilingue	Plus de 100 langues	Plus de 100 langues
Documents longs	Découpage plus fréquent	Fenêtre plus étendue
Faibles ressources	Très favorable	Plus exigeant
Références exactes	Recherche dense ou ajout d’un moteur lexical	Recherche hybride native possible
Complexité d’intégration	Faible en recherche dense	Plus importante si les trois modes sont exploités

Les caractéristiques techniques synthétisées dans ce tableau proviennent des documentations officielles de Google et de BAAI. Elles permettent d’orienter la sélection, mais pas de désigner automatiquement un vainqueur pour tous les projets.

Le résultat : choisir le modèle selon les usages réels de l’entreprise

À l’issue de cette étude de cas, le choix ne repose pas sur une simple comparaison de scores publics. Il dépend du niveau de précision recherché, des documents concernés et de l’infrastructure disponible.

Choisir EmbeddingGemma pour un RAG local léger

EmbeddingGemma est particulièrement pertinent lorsque l’entreprise recherche :

un modèle compact et rapide à déployer ;
une exécution locale sur un serveur modeste ;
une faible consommation de mémoire ;
un index Qdrant plus compact ;
une recherche sémantique sur des FAQ et des documents courts ;
une architecture simple à administrer ;
un système pouvant fonctionner hors connexion ;
une adaptation de la dimension des vecteurs aux ressources disponibles.

Il peut constituer un excellent choix pour une PME souhaitant interroger des procédures, des fiches de formation, des contenus WordPress, des courriers, des modes opératoires ou une documentation interne correctement segmentée.

Son principal avantage réside dans son rapport entre performance et ressources. Le modèle peut être utilisé sans mobiliser une carte graphique importante uniquement pour la génération des embeddings. Cette caractéristique facilite également les réindexations régulières déclenchées par n8n lors de l’ajout ou de la modification d’un document.

Choisir BGE-M3 pour une recherche plus avancée

BGE-M3 devient plus intéressant lorsque le projet nécessite :

l’indexation de documents longs ;
une recherche combinant sens général et mots exacts ;
la reconnaissance de références techniques ;
la recherche dans des catalogues produits ;
l’exploitation de documents multilingues ;
un système de recherche dense et sparse unifié ;
un reranking multivecteur plus précis ;
une architecture RAG destinée à un volume documentaire important.

Il est particulièrement adapté aux bases documentaires contenant des références de pièces, des noms de médicaments, des codes réglementaires, des versions logicielles, des numéros de formation ou des identifiants qui doivent être retrouvés sans approximation.

Qdrant est capable de stocker plusieurs vecteurs nommés pour un même document et d’effectuer des recherches hybrides associant vecteurs denses, vecteurs sparse et reranking. Cette architecture permet d’exploiter les trois modes proposés par BGE-M3, mais elle nécessite un workflow plus élaboré et des tests de pondération entre les différents résultats.

La solution intermédiaire : tester les deux modèles

Dans de nombreux projets, la meilleure méthode consiste à ne pas choisir immédiatement.

Internet Creative Center peut créer temporairement deux collections Qdrant contenant les mêmes documents :

une collection indexée avec EmbeddingGemma ;
une collection indexée avec BGE-M3 ;
éventuellement une troisième configuration hybride ;
un jeu commun de questions représentatives ;
une grille de notation identique.

Chaque réponse est alors évaluée selon plusieurs indicateurs :

le document attendu apparaît-il dans les premiers résultats ?
la bonne section du document est-elle retrouvée ?
les références exactes sont-elles préservées ?
la recherche fonctionne-t-elle avec une reformulation ?
le résultat reste-t-il pertinent dans une autre langue ?
combien de résultats inutiles sont remontés ?
quel est le temps de réponse ?
quelles ressources sont consommées ?

Cette démarche évite de sélectionner un modèle uniquement parce qu’il est récent, populaire ou bien classé sur un benchmark général.

Ne pas oublier le coût d’un changement de modèle

Le choix doit idéalement être validé avant la mise en production. Passer ultérieurement d’EmbeddingGemma à BGE-M3 implique de recalculer les embeddings de tous les documents.

Les vecteurs existants ne peuvent pas être simplement convertis d’un modèle à l’autre. Chaque modèle construit son propre espace mathématique. Une question vectorisée avec EmbeddingGemma doit donc être comparée à des documents vectorisés avec le même modèle.

Une migration correctement préparée comprend :

la création d’un nouvel espace vectoriel ;
la réindexation progressive des documents ;
le maintien temporaire de l’ancien modèle ;
des tests comparatifs en parallèle ;
la bascule vers le nouveau moteur ;
la conservation d’une procédure de retour arrière ;
la suppression de l’ancien index après validation.

Qdrant documente notamment deux approches : la création d’une nouvelle collection compatible avec le nouveau modèle ou l’utilisation de vecteurs nommés afin d’ajouter progressivement une nouvelle représentation aux documents existants.

La conclusion technique de l’étude de cas

EmbeddingGemma est recommandé lorsque la priorité porte sur la légèreté, la simplicité, la vitesse d’indexation et la réduction des ressources.

BGE-M3 est recommandé lorsque la priorité porte sur les documents longs, les références exactes, la recherche hybride et la précision d’une architecture multivecteur.

Pour une base composée principalement de textes courts et de questions en langage naturel, la complexité supplémentaire de BGE-M3 peut être inutile.

Pour un corpus technique, réglementaire ou commercial comprenant de nombreux identifiants précis, utiliser uniquement une recherche dense avec EmbeddingGemma peut nécessiter l’ajout d’une recherche lexicale complémentaire.

La meilleure solution peut également consister à associer plusieurs techniques plutôt qu’à opposer les modèles. Une recherche dense légère peut couvrir les demandes courantes, tandis qu’une recherche sparse ou un reranker peut être activé pour les requêtes nécessitant davantage de précision.

Pour conclure sur : " Étude de cas : EmbeddingGemma ou BGE-M3 pour un RAG local avec Qdrant "

Le modèle d’embedding constitue la véritable porte d’entrée d’un système RAG. Si le document pertinent n’est pas retrouvé, le modèle génératif ne pourra pas produire une réponse fiable, quelle que soit sa puissance.

EmbeddingGemma et BGE-M3 répondent à deux besoins différents. Le premier privilégie une architecture locale compacte, rapide et économique. Le second offre une boîte à outils plus étendue pour associer recherche sémantique, correspondance lexicale et analyse multivecteur.

Il serait donc trompeur d’affirmer que l’un est systématiquement supérieur à l’autre. Le choix doit dépendre :

des documents réellement utilisés ;
des formulations des utilisateurs ;
de la présence de références exactes ;
de la longueur des contenus ;
des langues traitées ;
du volume de la base ;
des performances du serveur local ;
du niveau de complexité acceptable.

Internet Creative Center conçoit et déploie des serveurs d’intelligence artificielle locaux intégrant n8n, Qdrant, Ollama et des modèles d’embedding open source.

Avant la mise en production, nous pouvons comparer EmbeddingGemma et BGE-M3 directement sur vos documents, vos procédures, vos références et vos questions métier. Vous obtenez ainsi une décision fondée sur des résultats reproductibles plutôt que sur une simple fiche technique.

Le test peut inclure :

l’installation locale des deux modèles ;
la création des collections Qdrant ;
l’importation automatisée par n8n ;
la définition d’un jeu de questions ;
la mesure de la pertinence des résultats ;
la comparaison des temps de réponse ;
le contrôle de la mémoire et du stockage ;
la recommandation d’une architecture finale ;
le plan de migration et de réindexation.

Vous disposez déjà d’une base documentaire ou d’un premier système RAG ? Apportez quelques documents représentatifs et les questions auxquelles votre IA doit réellement répondre. Nous testerons devant vous la qualité de la recherche et les différences entre les deux modèles.

Demander un test EmbeddingGemma contre BGE-M3

Les performances d’un modèle d’embedding dépendent du corpus, de la stratégie de découpage, des paramètres de recherche, des métadonnées et des questions utilisées. Un benchmark général ne remplace pas une validation effectuée sur les données de l’entreprise.