Dans un RAG, le LLM attire la lumière, mais l’embedding décide quels passages il verra. Sur des documents français — guides d’aides, règlements, délibérations — un mauvais choix se traduit par des réponses à côté malgré un excellent modèle de chat. Ce tutoriel pose le rôle de l’embedding, présente des familles candidates (bge-m3, multilingual-e5, nomic-embed et autres), et détaille un protocole de test que vous pouvez rejouer sur votre corpus. Pas de scores recall inventés : une méthode pour trancher chez vous, à Lille, Amiens ou Valenciennes.
Rôle de l’embedding dans le RAG
Un embedding transforme un texte en vecteur numérique. Deux textes proches en sens devraient avoir des vecteurs proches. Au moment de la question, on embedde la requête, on cherche les chunks voisins, on les passe au LLM. Si la notion de proximité de l’embedding colle mal à votre français administratif, le retrieval rate le paragraphe utile — et le chat « hallucine » pour combler.
L’embedding n’est pas le reranker, ni le LLM, ni l’OCR. Clarifier ces rôles évite de remplacer Qwen parce que bge (ou un autre) n’a pas été ré-indexé après un changement de paramètres. Pour les curseurs autour, voir réglages RAG Open WebUI ; pour la chaîne complète, tuto Qwen + RAG.
- Embedding
- Modèle qui encode textes et questions dans un espace vectoriel pour la recherche par similarité.
- Retrieval
- Étape qui sélectionne les chunks candidats avant génération.
- Multilingue
- Entraîné pour plusieurs langues ; indispensable dès que votre corpus et vos questions sont en français.
- Ré-indexation
- Reconstruction des vecteurs après changement d’embedding ou de découpage ; souvent obligatoire.
Candidats fréquents (à vérifier le jour J)
Les familles évoluent. Au moment où vous lisez ces lignes, des noms comme bge-m3, des variantes multilingual-e5, nomic-embed et d’autres modèles open source circulent dans les stacks RAG. Ce ne sont pas des « gagnants officiels IAHDF » : ce sont des pistes à confronter à votre corpus. Pour chaque candidat, notez : fiche Hugging Face ou tag Ollama exact, licence, langue, taille indicative, et s’il est présenté pour le retrieval.
Évitez les embeddings purement anglophones sur un fonds documentaire de la Région ou d’une ville de la Baie de Somme. Évitez aussi de changer de candidat chaque semaine : chaque bascule coûte une ré-indexation et casse la comparabilité. Deux finalistes suffisent pour une campagne sérieuse.
| Critère | Ce que vous notez |
|---|---|
| Identifiant exact | URL ou tag copié le jour J |
| Licence | Compatible avec votre structure ? |
| Langues annoncées | Français / multilingue clair ? |
| Usage prévu | Retrieval / similarité documentés ? |
| Coût mémoire | CPU possible ou GPU requis ? |
| Intégration | Open WebUI / Ollama / autre |
Préparer un corpus français réaliste
Visez des PDF textuels déjà publics : guide d’aides, FAQ, règlement de service, compte rendu publié. Dix à trente documents bien choisis battent un dumping de scans illisibles. Anonymisez tout ce qui ne serait pas publiable. Nommez les fichiers clairement. Sur un atelier à Arras, un corpus « trop propre » trompe : gardez quelques mises en page difficiles (tableaux, listes) pour voir qui résiste.
Construisez ensuite un jeu de questions : formulations exactes tirées du texte, paraphrases, questions à sigles locaux, questions hors sujet. Pour chaque question, indiquez le fichier et le passage attendu. C’est votre vérité terrain — pas un leaderboard externe.
Pas à pas : protocole de comparaison
Figer le reste de la pile
Même découpage de chunks, même top-k, même LLM, même prompt système. Seul l’embedding change entre deux runs. Sinon vous comparez dix variables à la fois. Notez aussi la version d’Open WebUI ou de l’outil d’indexation. Sur un serveur d’association à Boulogne, cette discipline évite les débats stériles en réunion. Si quelque chose échoue, arrêtez-vous et notez le message exact avant de retenter. Une capture d’écran des logs vaut mieux qu’une reformulation de mémoire, surtout quand un collègue de Douai ou Arras reprendra le dossier le lendemain.
Indexer le corpus avec le candidat A
Installez ou sélectionnez le modèle A via le mécanisme de votre stack (menu documents Open WebUI, pull Ollama, etc.). Lancez l’indexation complète. Vérifiez l’absence d’erreurs fichier par fichier. Sauvegardez un export ou une copie de l’état si l’outil le permet. Chronométrez approximativement : un embedding très lent peut être disqualifié pour un usage guichet. Gardez un bloc-notes ouvert : commande tapée, résultat attendu, résultat obtenu. Cette trace courte accélère le dépannage et évite de croire qu’« on a déjà essayé » sans preuve.
Jouer le jeu de questions et noter le rang du bon passage
Pour chaque question, observez si le bon chunk apparaît parmi les premiers résultats affichés (top-5 mental, par exemple). Notez OK / partiel / KO, sans inventer de pourcentages publics. Repérez les familles d’échecs : paraphrase, sigle, tableau. Ces motifs guident le choix mieux qu’une moyenne opaque. Vérifiez aussi l’environnement : VPN, proxy, antivirus, espace disque. Beaucoup d’échecs attribués au modèle viennent d’un réseau d’entreprise à Lille ou d’un disque plein après plusieurs pulls. Complétez par un test de non-régression : refaites le même geste après avoir fermé puis rouvert l’outil, afin de confirmer que la configuration survit au redémarrage et reste compréhensible pour un collègue qui n’a pas suivi toute la session.
Ré-indexer entièrement avec le candidat B
Supprimez ou isolez l’index A selon vos possibilités, basculez vers B, ré-indexez tout le corpus. Ne réutilisez jamais des vecteurs A avec un modèle B. Rejouez exactement les mêmes questions dans les mêmes conditions de top-k. La fatigue de la ré-indexation fait partie du coût réel du candidat. Quand l’étape réussit, marquez-la explicitement dans votre checklist. Les bascules trop rapides vers l’étape suivante masquent des configs demi-installées qui cassent plus tard en démo publique.
Comparer motif par motif, pas « au feeling global »
Dites : B gagne sur les paraphrases, A sur les sigles exacts — alors l’hybride mots-clés (réglages) peut compléter A, etc. Impliquez une personne métier (agent d’accueil à Laon, responsable associatif à Douai) pour valider que les KO restants sont acceptables. Un embedding « geek-approuvé » qui rate les questions usagers n’est pas choisi. Si vous travaillez à deux, faites reformuler le geste par la personne la moins technique. Ce qui n’est pas dit clairement maintenant reviendra en ticket flou après l’atelier.
Figer, documenter, planifier le réexamen
Écrivez l’identifiant gagnant, la date, le corpus, la version logicielle. Planifiez une revue quand le corpus change massivement ou quand une nouvelle famille d’embeddings devient facilement intégrable. Résistez à la tentation de retester chaque lundi : la stabilité est une qualité de service. Testez une fois « à froid » après redémarrage de la machine. Un service qui ne survit pas au reboot n’est pas prêt pour une permanence à Valenciennes ou Amiens. Ajoutez une vérification métier : demandez à une personne du terrain de reformuler le besoin en une phrase, puis vérifiez que votre réglage répond vraiment à cette phrase, pas seulement au scénario technique imaginé au départ.
Comment lire vos résultats sans vous mentir
Un candidat qui gagne sur les questions « copie exacte » mais perd sur les paraphrases sera fragile en conditions réelles : les usagers ne citent pas le PDF. Un candidat inverse peut manquer un code interne rare : l’hybride BM25 / mots-clés corrigera souvent ce cas. Les questions hors sujet doivent rester hors sujet : si un embedding + LLM « trouve » toujours quelque chose, regardez le prompt et le top-k, pas seulement l’embedding.
N’extrapolez pas à toute la francophonie. Un corpus de délibérations de Cambrai n’est pas un corpus médical ni un corpus de code. La conclusion honnête se limite à : « sur ce fonds, à cette date, avec cette pile, nous retenons X ».
Ce que vous pouvez conclure
Des observations locales actionnables.
- Tel motif de question réussit mieux avec A ou B
- Tel candidat est trop lent sur votre CPU
- Tel candidat s’intègre mal à votre UI
Ce que vous ne devez pas inventer
Des absolutismes marketing.
- Un recall@k « officiel » non mesuré proprement
- Un classement universel des embeddings
- Une équivalence garantie entre versions
Intégration Open WebUI / Ollama
Dans Open WebUI, l’embedding se choisit côté administration des documents (libellé variable). Si le téléchargement passe par Ollama, copiez le tag exact depuis la library. Après sélection, lancez une mini-indexation test (deux fichiers) avant le corpus entier. En cas d’échec, lisez les logs plutôt que de basculer immédiatement vers un troisième candidat.
Mémoire : certains embeddings tiennent en CPU confortablement ; d’autres préfèrent le GPU. Sur une machine déjà chargée par un 27B, faire tourner un embedding lourd concurrent peut dégrader tout le service. Testez la coexistence réelle, pas seulement chaque pièce isolée.
Date : Outil (Open WebUI version / autre) : Candidat A (identifiant exact) : Candidat B (identifiant exact) : Chunk size / overlap / top-k (figés) : Corpus (nb fichiers, origine) : Décision : Motifs gagnants / perdants :
Recommandations pratiques (qualitatives)
Pour un premier RAG français en collectivité ou TPE : choisissez un embedding multilingue explicitement présenté pour le retrieval, validez-le sur paraphrases et sigles, activez éventuellement la recherche hybride, et ne changez plus tant que le corpus n’a pas muté. bge-m3 et d’autres familles citées plus haut sont des points d’entrée fréquents — à confirmer par votre protocole, pas par cette phrase seule.
Si votre contrainte est le CPU d’un petit serveur à Abbeville, ajoutez la latence comme critère de disqualification. Si votre contrainte est la licence, élaguez la shortlist avant même les tests de qualité. Si votre contrainte est la simplicité d’ops, privilégiez le candidat que votre UI télécharge sans bricolage.
Pièges classiques
- Comparer deux embeddings avec des chunk sizes différents
- Oublier de ré-indexer après bascule
- Juger sur trois questions amicales seulement
- Mélanger documents périmés et en vigueur
- Publier un « % de réussite » hors contexte comme vérité scientifique
- Changer d’embedding la veille d’une démo publique
Autre piège : croire que le « meilleur embedding Twitter » battra un embedding moyen branché sur un corpus propre et un hybride bien réglé. La qualité documentaire reste le levier n°1 en Hauts-de-France comme ailleurs.
Faire vivre le choix dans l’équipe
Documentez pour les non-spécialistes : « nous utilisons tel embedding parce qu’il retrouvait mieux les dispositifs paraphrasés sur notre guide d’aides ». Formez un référent capable de ré-indexer. Branchez cette discipline à votre instance Open WebUI (install) et à vos réglages (RAG). L’embedding n’est plus un mystère de data scientist : c’est un paramètre de service.
Dans une Maison de l’IA ou un atelier mobile entre Lens et Liévin, emportez un corpus USB déjà indexé sur la machine de démo plutôt que de ré-embarquer un pull d’embedding sur place. La logistique fait partie du choix technique : un candidat excellent mais pénible à déployer hors ligne perd des points opérationnels.
Améliorer le corpus avant de changer d’embedding
Avant de condamner un modèle, vérifiez OCR, doublons, documents obsolètes, fichiers scannés à l’envers, pages blanches indexées. Un passage d’une demi-journée sur le fonds documentaire d’une mairie de Saint-Quentin rapporte souvent plus qu’une semaine à comparer des vecteurs. L’embedding magnifie la qualité du texte : il ne remplace pas le ménage.
Ajoutez des métadonnées utiles dans les noms de fichiers ou champs supportés par votre outil : année, type (dél mel / guide / FAQ), statut (vigueur / archive). Même imparfaites, elles aident l’humain à auditer les sources affichées par le RAG — et parfois la recherche hybride.
- Supprimer les doublons et brouillons
- OCR sur les scans importants
- Séparer archives et documents en vigueur
- Ajouter un mini-glossaire des sigles locaux
- Puis seulement relancer une campagne embedding A/B
Limites honnêtes de tout comparatif
Votre test ne dit pas quel embedding gagnera sur un autre fonds, ni dans six mois, ni avec une autre version d’Open WebUI. Il dit lequel rend mieux service ici et maintenant. Affichez cette limite dans votre README : cela protège l’équipe contre le syndrome du benchmark absolu et contre les pressions marketing de modèles « meilleurs partout ».
IAHDF n’est rémunéré par aucun éditeur d’embedding. Aucun lien affilié, aucun PDF « résultats secrets ». Si vous publiez un retour d’expérience local, décrivez protocole et corpus ; évitez les pourcentages sortis de leur contexte.
Questions fréquentes
Quel embedding pour des documents en français ?
Un modèle multilingue documenté pour le retrieval, validé sur votre corpus avec paraphrases et sigles. Les familles du type bge-m3, e5 multilingue ou nomic-embed sont des candidats à tester — pas des trophées à coller sans essai. La réponse responsable est toujours locale : identifiant exact, date, protocole, décision écrite. Pour trancher chez vous, reproduisez le scénario sur la machine réelle avec un protocole court écrit à l’avance. Une conclusion d’atelier à Roubaix ne se transfère pas telle quelle sur un portable différent.
Puis-je réutiliser un embedding anglais « parce que le français ressemble » ?
C’est risqué sur de l’administratif riche en formulations spécifiques. Vous pouvez l’essayer dans un protocole A/B, mais partez avec un avantage hypothétique pour le multilingue. Si l’anglais gagne vraiment sur vos questions, gardez la preuve dans votre grille — l’exception documentée vaut mieux que le dogme. Gardez une fiche datée : question, hypothèse, test, résultat. Cette hygiène évite les débats sans fin et construit une mémoire utile pour la prochaine personne référente. Documentez le contournement éventuel (petit modèle, localhost, hors VPN) pour ne pas rester bloqué en démonstration publique : un plan B écrit vaut mieux qu’une improvisation sous le regard d’un public à Lille ou Amiens.
Faut-il un GPU pour l’embedding ?
Pas toujours. Beaucoup d’équipes embarquent l’embedding en CPU pour réserver le GPU au LLM. Mesurez la latence d’indexation et de requête. Si l’indexation d’un lot devient un frein opérationnel, envisagez le GPU ou un modèle plus léger. L’ordre de grandeur dépend de votre volume de fichiers. Si deux camps s’opposent dans l’équipe, imposez un A/B sur la même batterie de prompts plutôt qu’un vote d’opinion. Le terrain tranche plus vite que les digressions de salon.
Pourquoi vous ne publiez pas un tableau recall@5 ?
Parce qu’un chiffre sorti de son corpus, de sa version et de son protocole induit en erreur. Nous préférons vous donner une méthode reproductible. Vous pouvez compter des OK en interne pour décider ; nous refusons d’inventer un palmarès figé qui serait déjà obsolète en septembre 2026. Méfiez-vous des captures hors contexte trouvées en ligne. Sans connaître quantification, contexte et charge machine, un chiffre spectaculaire ne dit rien de votre poste à Beauvais. Mesurez aussi le confort subjectif (bruit, chaleur, temps d’attente ressenti) : un réglage « correct » sur le papier mais pénible au quotidien ne sera pas adopté par une équipe de collectivité ou d’association.
Que faire après avoir choisi ?
Figer l’identifiant, ré-indexer proprement, régler hybride et top-k ([[ta07]]), former l’équipe, et ne plus toucher sans motif. Enchaînez sur des questions usagers réelles pendant deux semaines, notez les nouveaux KO, et décidez si le problème est embedding, chunking ou corpus manquant. Quand le problème semble intermittent, journalisez l’heure, la température perçue et les autres apps ouvertes. Les coïncidences thermiques et mémoire sont fréquentes sur machines partagées. Si le résultat est ambigu, changez une seule variable et rejouez immédiatement le même protocole : c’est la seule façon d’apprendre quelque chose d’exploitable plutôt que d’empiler des impressions contradictoires.