Lorsqu’on commence à construire un système RAG local avec AnythingLLM, on se concentre souvent sur le modèle de langage utilisé pour répondre aux questions. Pourtant, dans la pratique, un autre composant joue un rôle absolument central dans la qualité des réponses : le moteur d’embedding.
C’est lui qui transforme les documents en vecteurs mathématiques afin de permettre la recherche sémantique dans la base documentaire. En clair, c’est lui qui détermine si le système retrouve les bons passages avant même que le LLM ne commence à rédiger une réponse.
Par défaut, AnythingLLM utilise un moteur d’embedding léger intégré, pensé pour fonctionner facilement sur presque n’importe quelle machine. Mais de nombreux utilisateurs avancés choisissent aujourd’hui d’utiliser des modèles externes via Ollama, notamment le très populaire BGE-M3.
Alors, quelles sont les différences concrètes ? Quels gains peut-on espérer ? Et quel est l’impact sur les performances d’un système RAG local ?
Le moteur d’embedding par défaut d’AnythingLLM
Le moteur intégré d’AnythingLLM a été conçu avec un objectif simple : proposer une expérience immédiatement fonctionnelle, légère et accessible.
Dans la plupart des installations locales, AnythingLLM utilise un petit modèle CPU-friendly de type Nomic ou équivalent, avec une empreinte mémoire réduite et une vitesse d’indexation très correcte même sur des machines modestes.
Les avantages sont évidents :
- démarrage rapide
- faible consommation mémoire
- fonctionnement sans GPU
- indexation assez rapide
- simplicité de configuration
Pour un usage simple, des documents courts ou un environnement principalement anglophone, ce moteur peut déjà fournir des résultats tout à fait satisfaisants.
Mais dès que l’on passe à des corpus réels plus complexes, certaines limites apparaissent rapidement.
Pourquoi les embeddings deviennent critiques dans un vrai RAG
Dans un laboratoire de tests RAG orienté terrain comme https://labo.ia-opensource.be/, les corpus ne ressemblent pas à des exemples académiques simplifiés.
On travaille souvent avec :
- des PDF convertis imparfaitement,
- des documents administratifs longs,
- du français technique,
- des textes multilingues,
- des procédures internes,
- des programmes scolaires,
- des tableaux et contenus semi-structurés.
Dans ce contexte, la qualité des embeddings devient fondamentale.
Un mauvais embedding ne signifie pas forcément une mauvaise réponse du LLM. Cela signifie surtout que le bon passage documentaire n’a jamais été retrouvé.
Et un excellent modèle de langage ne peut pas inventer un contexte qu’il ne reçoit pas.
BGE-M3 : une approche beaucoup plus avancée
BGE-M3 est un modèle d’embedding open source développé par BAAI. Il est aujourd’hui considéré comme l’un des meilleurs modèles open source pour la recherche documentaire multilingue.
Le nom M3 signifie :
- Multi-Functionality,
- Multi-Linguality,
- Multi-Granularity.
Concrètement, cela signifie que le modèle a été conçu pour :
- gérer plus de 100 langues,
- comprendre des documents longs,
- mieux relier les concepts entre eux,
- améliorer la recherche sémantique complexe,
- fonctionner efficacement sur des corpus hétérogènes.
Là où un embedding léger peut parfois se contenter d’une similarité de mots-clés “améliorée”, BGE-M3 va beaucoup plus loin dans la compréhension contextuelle.
Cela devient particulièrement intéressant pour les tests RAG sur des documents en français.
Les gains potentiels avec BGE-M3
Une meilleure pertinence documentaire
Le gain principal est généralement le plus important : le système retrouve des passages beaucoup plus pertinents.
Dans les tests terrain, cela se traduit souvent par : moins d’hallucinations, moins de réponses “hors sujet”, une meilleure précision, une meilleure capacité à retrouver des passages éloignés lexicalement mais proches sémantiquement.
Autrement dit : le système comprend mieux le sens réel des questions.
De meilleures performances en français
C’est probablement l’un des points les plus intéressants pour un usage européen.
Le moteur d’embedding par défaut reste souvent très optimisé pour l’anglais. BGE-M3, lui, a été explicitement conçu pour le multilingue.
Sur des corpus francophones réels, cela peut produire une différence très visible :
- meilleure compréhension des formulations naturelles,
- meilleure gestion des synonymes,
- meilleure récupération des passages pertinents,
- meilleure robustesse sur les accents et formulations administratives.
Dans certains cas, l’amélioration est immédiatement perceptible dès les premières requêtes.
Une meilleure gestion des longs documents
BGE-M3 gère efficacement des contextes allant jusqu’à 8192 tokens.
Cela devient extrêmement utile pour : des PDF volumineux, des réglementations, des programmes scolaires, des rapports techniques ou des procédures d’entreprise.
Le modèle conserve mieux les relations entre les différentes parties d’un document long.
Un meilleur comportement sur les corpus mixtes
Les vrais corpus RAG sont rarement “propres”.
On y trouve souvent du texte brut, des tableaux, des fragments HTML, des PDF convertis, des listes à puces, des annexes. BGE-M3 se montre généralement plus robuste dans ce type d’environnement.
Quel impact sur les performances ?
C’est évidemment le revers de la médaille.
BGE-M3 est beaucoup plus lourd qu’un moteur d’embedding léger intégré.
Le modèle BGE-M3 disponible via Ollama représente environ 1,2 Go et utilise environ 567 millions de paramètres.
Cela entraîne plusieurs conséquences.
Une indexation plus lente
Lors de l’import des documents :
- le CPU est davantage sollicité,
- la RAM utilisée augmente,
- le temps d’embedding est plus long.
Sur un petit mini-PC ou un laptop ancien, la différence peut être importante.
En revanche, une fois les embeddings générés, ce coût disparaît en grande partie.
Plus de consommation mémoire
Avec BGE-M3 :
- 16 Go de RAM deviennent nécessaires pour plus de confort,
- 8 Go restent possibles mais plus limités,
- un GPU peut accélérer les opérations
Cependant, contrairement aux LLMs, les embeddings restent globalement bien moins exigeants que l’inférence conversationnelle.
Des temps de recherche parfois légèrement plus élevés
Les vecteurs générés par BGE-M3 sont plus riches et plus complexes. Sur des très gros corpus, cela peut légèrement augmenter le temps de recherche vectorielle, la charge CPU et la taille de la base vectorielle.
Mais dans la plupart des usages PME, associatifs ou éducatifs, l’impact reste généralement très acceptable.
Faut-il utiliser BGE-M3 dans AnythingLLM ?
La réponse dépend surtout du type de projet.
Pour des petits tests rapides, un usage personnel simple, des corpus limités, des machines modestes, le moteur par défaut d’AnythingLLM reste une excellente solution.
En revanche, pour des corpus denses en français, des documents complexes, des usages professionnels, BGE-M3 représente aujourd’hui une évolution très pertinente.
Le gain le plus visible n’est pas forcément la vitesse ni même la “puissance”. C’est surtout la pertinence documentaire.
Et dans un système RAG, retrouver le bon contexte reste souvent plus important que générer la réponse elle-même.