BGE-M3 : des embeddings qui parlent vraiment français

#Le problème français

Un modèle d'embedding apprend sa notion de similarité de son corpus d'entraînement. Si ce corpus est à 90 % anglophone, le modèle place correctement les textes anglais les uns par rapport aux autres et beaucoup moins finement les textes français. En pratique, sur un corpus documentaire français, cela se traduit par des passages pertinents qui ne remontent pas, et par des passages hors sujet qui remontent — sans aucun message d'erreur, sans avertissement dans les journaux, et souvent sans que personne ne le remarque avant qu'un utilisateur ne signale une réponse à côté de la plaque.

C'est la raison pour laquelle la question « quel modèle d'embedding » n'a pas la même réponse selon la langue. Les classements publics (type MTEB) sont largement dominés par des tâches anglophones ; ils ne prédisent pas ce qui se passera sur vos documents, ni sur votre vocabulaire spécialisé. C'est précisément pour ce cas que le laboratoire chinois BAAI (Beijing Academy of Artificial Intelligence) a conçu BGE-M3 : le nom signifie Multi-Functionality, Multi-Linguality, Multi-Granularity — trois fonctions de recherche, plus de 100 langues, et des entrées de la phrase courte au document long, réunies dans un seul modèle plutôt que dispersées entre plusieurs outils.

#Ce que BGE-M3 apporte

Multilingue de conception

Le modèle prend en charge plus de 100 langues de travail, selon sa fiche officielle ; il traite le français correctement et permet aussi d'interroger en français un corpus anglais.

Contexte long : 8 192 tokens

Il accepte des passages nettement plus longs que la plupart des modèles d'embedding (souvent limités à 512 tokens), ce qui laisse de la liberté sur la taille des morceaux indexés.

Trois représentations à la fois

Dense, lexicale et multi-vecteur, produites en une seule passe, sans coût de calcul additionnel selon BAAI.

Licence MIT

Utilisable en entreprise sans restriction particulière ; vérifiez toujours la fiche du modèle au moment de l'intégrer, une licence pouvant évoluer d'une version à l'autre.

Pas d'instruction à ajouter

Contrairement à d'autres modèles BGE plus anciens, BGE-M3 ne demande plus d'ajouter une instruction dans les requêtes : on l'utilise directement, ce qui simplifie l'intégration.

#Dense, lexical, multi-vecteur : à quoi ça sert

L'intérêt est de pouvoir faire de la recherche hybride sans faire tourner deux modèles séparés : la fiche officielle recommande explicitement le duo recherche hybride + reclassement, en s'appuyant sur les poids lexicaux obtenus « sans coût additionnel » en même temps que l'embedding dense. La partie lexicale rattrape précisément les échecs de la partie dense, et la partie multi-vecteur sert à reclasser la vingtaine de candidats retenus. Toutes les bases vectorielles ne savent pas exploiter les trois sorties, mais la dense seule suffit déjà pour un usage classique — c'est d'ailleurs la configuration la plus simple à mettre en œuvre pour démarrer, avant d'ajouter la couche lexicale si la précision manque encore.

#L'utiliser en local

Le moyen le plus rapide de tester BGE-M3 en local est Ollama, qui distribue une version quantifiée du modèle sous le nom bge-m3:567m — 567 millions de paramètres, pour un téléchargement d'environ 1,2 Go et une fenêtre de contexte de 8 000 tokens annoncée sur la fiche du modèle. C'est un modèle bâti sur XLM-RoBERTa-large, dont la longueur de contexte a d'abord été étendue à 8 192 tokens par un pré-entraînement dédié (RetroMAE), avant un affinage unifié pour les trois tâches de récupération en une seule étape d'entraînement, plutôt que trois modèles séparés à maintenir.

ollama pull bge-m3
ollama run bge-m3 "Quel est le délai de rétractation légal en France ?"

Pour un pipeline RAG complet, seule la sortie dense est directement exploitable par la plupart des bases vectorielles standard (Qdrant, Milvus, pgvector) sans configuration spécifique ; les sorties lexicale et multi-vecteur demandent un moteur qui sait les combiner, ce que documentent par exemple les intégrations Milvus et Vespa citées par BAAI.

Dans une chaîne RAG classique avec un LLM local, BGE-M3 remplace simplement le modèle d'embedding par défaut : on encode chaque morceau de document une fois à l'indexation, on encode la question de l'utilisateur à chaque requête, puis on transmet les meilleurs passages retrouvés au LLM (Qwen, Mistral, Llama…) chargé sous Ollama ou LM Studio. Le choix du modèle d'embedding et celui du modèle de génération sont deux décisions indépendantes : rien n'oblige à prendre un modèle de la même famille pour les deux étapes, et c'est même rarement le cas en pratique.

#Vérifier sur vos propres documents

Un « plus de 100 langues » de fiche produit n'est pas une garantie de qualité uniforme : c'est une couverture, pas un score par langue. BAAI évalue BGE-M3 sur MIRACL (recherche multilingue) et sur MLDR, un jeu de données de récupération de documents longs couvrant 13 langues que le laboratoire a publié spécifiquement pour ce modèle, avec le pipeline d'évaluation correspondant en accès libre. Ces évaluations donnent une tendance générale, mesurée sur des corpus de recherche standardisés ; elles ne remplacent pas un test sur votre propre corpus, dans votre propre domaine, avec votre propre vocabulaire technique et vos propres formulations de questions.

1. 01
   Constituer un petit échantillon représentatif

   Vingt à trente documents réels du corpus visé, avec leur diversité habituelle de longueur et de vocabulaire, pas une sélection triée sur le volet.
2. 02
   Écrire des questions comme les poseraient vos utilisateurs

   Dix à vingt questions réelles, y compris des questions qui utilisent des synonymes ou une formulation différente de celle du document source.
3. 03
   Comparer deux ou trois modèles sur le même échantillon

   BGE-M3 face à un modèle anglophone réputé et, si possible, un autre modèle multilingue. Noter combien de fois le bon passage sort dans les trois premiers résultats.
4. 04
   Trancher avant l'import massif

   Le test coûte une demi-journée ; changer de modèle après indexation d'un corpus complet impose de tout réencoder, comme rappelé plus haut.

#Ce que ça coûte

C'est un modèle d'embedding plus lourd que les petits modèles anglophones à la mode : ses 567 millions de paramètres et son téléchargement d'1,2 Go en font un poids moyen pour la catégorie, loin des modèles à quelques dizaines de millions de paramètres qui dominent les classements de vitesse pure. Il encode plus lentement et occupe davantage de mémoire. Sur l'indexation initiale d'un gros corpus, cela se voit ; sur une question isolée, la différence est imperceptible face au temps de génération du modèle de langage qui suit.

Autre conséquence : ses vecteurs denses ont une dimension de 1 024, donc l'index occupe plus de place que des modèles à 384 ou 768 dimensions. Sur un million de passages, l'arithmétique n'est plus négligeable, et c'est le moment de regarder les options de compression de votre base vectorielle.

Le contraste est net : à dimension égale (1 024), BGE-M3 accepte seize fois plus de tokens par passage que bge-large-en-v1.5, et couvre plus de 100 langues là où toute la famille « en » de BAAI se limite à l'anglais. C'est le prix à payer, en taille de téléchargement et en temps d'encodage, pour ne pas avoir à choisir un modèle différent par langue de corpus, ni à maintenir plusieurs index séparés selon la langue des documents entrants.

#Quand le choisir, quand s'en passer

• Le panorama des modèles d'embedding pour le français
• Faire tourner un modèle d'embedding en local
• Reclasser les candidats pour gagner en précision
• Stocker ces vecteurs dans PostgreSQL avec pgvector
• Source : fiche officielle BGE-M3 sur Hugging Face
• Source : bge-m3 dans la bibliothèque Ollama
• Source : dépôt et code officiel BGE-M3 (FlagEmbedding)

#FAQ