Pour un RAG en français, le modèle de chat n’est qu’une moitié du système : l’embedding décide quels passages remontent. bge-m3, e5, nomic et d’autres familles ouvertes se valent selon le corpus. Ce test propose une épreuve concrète — une question dont la réponse est dans un PDF — et liste les échecs utiles, sans chiffres de précision inventés. IAHDF n’est partenaire d’aucun éditeur : pas de note sur cinq, pas de débit inventé, pas de classement du mois présenté comme vérité. Vous trouverez ici une méthode d’essai en français, des ordres de grandeur de matériel, une lecture de licence sur le dépôt, et une scène ancrée en Hauts-de-France. Date de rédaction : septembre 2026.
Verdict en trente secondes
Verdict utile : choisissez l’embedding qui remonte le bon passage sur votre corpus français, pas celui qui gagne un banchmark anglophone du mois. bge-m3, e5 et nomic sont des pistes ; aucune n’est sacrée.
Un embedding médiocre casse un RAG même avec un excellent LLM. Inversement, un bon retrieval permet à un modèle moyen de citer juste.
Pas de score de rappel inventé ici. Votre épreuve PDF suffit à écarter un candidat clairement inadapté.
Fiche d’identité (à vérifier sur le dépôt)
Nom courant testé : Embeddings ouverts (bge-m3, e5, nomic…). Éditeur / origine : Divers. Licence annoncée dans notre source éditoriale : Variable selon le dépôt — lire chaque carte. Ces libellés doivent être confrontés à la carte modèle et au fichier LICENSE du jour — les forks et quantifications changent les textes.
Nous ne figeons pas ici un nombre de paramètres, une longueur de contexte « garantie », ni un tag de runtime comme vérité absolue. Quand une fiche marketing annonce une architecture (MoE, dense, multimodale), relevez-la comme hypothèse de travail, puis confirmez sur le dépôt officiel ou la page Hugging Face / GitHub associée.
Pour l’essai : notez la date du téléchargement, le hash ou le commit si disponible, le nom exact du fichier de poids, et l’outil d’inférence (llama.cpp, vLLM, Ollama, LM Studio, autre). Sans cette traçabilité, votre « test Kimi » ou « test Llama » n’est pas reproductible dans six mois.
Question des lecteurs à laquelle ce protocole répond : « Peut-il tourner chez moi, et vaut-il le coup ? » — ou, pour les embeddings : « Quel embedding pour mon RAG ? ». La réponse se construit par l’essai, pas par la rumeur.
Quel matériel ? (ordres de grandeur)
Matériel indicatif pour ce test : CPU souvent suffisant ; GPU optionnel pour gros corpus. Ce sont des ordres de grandeur pour vous orienter, pas une facture d’achat ni une mesure de laboratoire IAHDF publiée au Go près.
Lisez le tableau ci-dessous comme une boussole. La quantification (compression des poids) change fortement la mémoire nécessaire et la qualité. Une quantification agressive peut faire « rentrer » un modèle — au prix d’erreurs plus fréquentes. Nous ne publions pas de tokens/s : mesurez le confort d’usage chez vous (attente avant la première réponse, fluidité perçue).
| Situation | Ce que cela permet souvent | Vigilance |
|---|---|---|
| CPU portable | Indexation de petits corpus | Patience sur des milliers de chunks |
| CPU serveur | Corpus associatif / PME | Dimensionnez le stockage des vecteurs |
| GPU | Réindexations fréquentes | Utile, pas obligatoire au début |
| GPU + gros disque | Archives régionales volumineuses | La qualité du chunking compte autant que le GPU |
Si votre machine est en dessous de la ligne « confort », préférez un modèle plus petit, un hébergeur maîtrisé, ou un essai en Maison régionale de l’IA / atelier équipé plutôt que de forcer un téléchargement voué à l’échec.
Essayer en local (sans tag inventé comme certitude)
Les noms de modèles dans Ollama, LM Studio, Hugging Face ou vLLM changent. Nous ne gravons pas ici une commande `ollama run …` présentée comme officielle et éternelle. Méthode : ouvrez la bibliothèque officielle de votre outil le jour J, cherchez le nom publié par l’éditeur ou un mirror de confiance, copiez le tag affiché, documentez-le.
Parcours générique en trois gestes : (1) créer un environnement jetable (utilisateur dédié, dossier de poids isolé) ; (2) télécharger la variante choisie depuis une source vérifiée ; (3) lancer une inférence courte avec un prompt neutre avant toute donnée métier. Si vous utilisez une interface type Open WebUI, branchez ensuite le modèle déjà stable — voir aussi IA locale / Open WebUI selon votre catalogue.
Refusez les liens « crack », les poids sans provenance, et les pages qui demandent des identifiants hors dépôt connu. Un modèle ouvert se télécharge ; il ne se « débloque » pas avec une clé douteuse.
Pas à pas d’un premier essai
Choisir la variante et la source
Écrivez le nom exact (carte modèle). Vérifiez licence et date. Écartez les forks anonymes non documentés.
Préparer la machine jetable
Espace disque, hotte thermique, compte sans droits admin inutiles. Notez versions du runtime.
Télécharger et vérifier
Contrôlez checksum si fourni. Rangez les poids hors des dossiers synchronisés grand public type cloud perso mal configuré.
Smoke test neutre
Prompt : « Réponds en une phrase : quelle est la capitale des Hauts-de-France administratives ? » puis vérifiez. Si hallucination locale, documentez-la.
Passer aux épreuves françaises
Utilisez les prompts de la section suivante, toujours sur données fictives ou publiques avant le réel.
Épreuves françaises (prompts copiables)
Protocole commun : même texte collé, température basse si le runtime le permet, une seule variable changée à la fois (le modèle). Notez réussites et ratés en français clair — pas en « score /5 ». Les prompts ci-dessous sont volontairement ancrés Hauts-de-France pour détecter inventions locales.
Épreuve embeddings — concrète : prenez un PDF public (délibération, notice d’asso, page tourisme) contenant un chiffre ou un nom propre rare. Indexez-le. Posez une question dont la réponse exacte est dans ce PDF et nulle part dans votre tête de prompt. Observez si le chunk remonté contient la réponse. Puis posez une question piège absente du corpus : le système doit échouer proprement plutôt qu’inventer.
Tu es un assistant de recherche documentaire. Tu ne réponds qu’avec les extraits fournis ci-dessous. Si l’information manque, écris exactement : INFORMATION ABSENTE DU CORPUS. Extrait(s) : « … collez ici le ou les chunks remontés … » Question : Quel est le montant / la date / le nom propre visé dans le document indexé ? Réponse attendue : citation courte + localisation (page ou section si présente).
Échecs utiles à connaître : chunk trop grand (noyade), chunk trop petit (phrase coupée), OCR absent sur scan (voir OCR avant RAG si vos PDF sont des images), embedding anglophone faible sur français administratif, question vague (« parle-moi du document ») qui remonte tout et n’importe quoi.
Qualité observée (tableau qualitatif, sans scores)
Le tableau suivant résume des observations de méthode — pas un banc d’essai chiffré IAHDF. Remplacez les cellules par vos propres constats après essai. Interdiction méthodologique : ne pas inventer de pourcentages, de tokens/s ni de notes sur cinq « pour faire scientifique ».
| Critère | Ce que nous regardons | Compte rendu type (à remplir) |
|---|---|---|
| Remontée du bon chunk | Question dont la réponse est dans le PDF | Oui / partiel / non — sans % |
| Piège hors corpus | Doit échouer proprement | Refuse / invente |
| Français admin | Vocabulaire délibération / asso | Correct / fragile |
| Coût machine | CPU vs GPU ressenti | Acceptable / trop lent |
| Licence | Usage commercial possible ? | OK / non / à relire |
Partagez ce tableau en équipe : l’objectif est un langage commun (« refuse bien », « invente des communes », « mail trop commercial ») plutôt qu’une moyenne magique.
Licence et usage : lire le dépôt, pas le titre du blog
Libellé de départ pour cet article : Variable selon le dépôt — lire chaque carte. Ce libellé ne remplace pas le fichier LICENSE ni les clauses supplémentaires (attribution, partage, seuils d’utilisateurs, usage militaire, etc.).
Méthode : téléchargez le texte de licence avec les poids, archivez-le avec la date, faites-le lire à la personne qui signe les contrats dans votre structure si l’usage est pro. « Open weights » n’égale pas toujours « open source » au sens OSI, ni « libre pour mon business ».
Scène Hauts-de-France
Maison de l’IA / médiation à Lens : atelier RAG. Chaque binôme indexe le même PDF de délibération publique et pose la question dont la réponse est une date budgétaire. On compare bge-m3, e5 et nomic à l’œil nu sur la remontée. Pas de courbe ROC : des mains levées « bon chunk / mauvais chunk ».
Angle CSV pour cet article : Question dont la réponse est dans un PDF régional indexé. Gardez des données publiques ou fictives tant que la gouvernance n’est pas écrite. Pour pratiquer en groupe, surveillez l’agenda IAHDF et l’inscription.
Pour qui ? Alternatives
Ce test s’adresse aux passionnés, techniciens, TPE/PME et collectivités qui acceptent un protocole lent. Il ne s’adresse pas à qui cherche un gagnant absolu pour un tweet.
Alternatives : changer de taille de chunk avant de changer de modèle ; OCR sur scans (OCR) ; autre famille e5/bge/nomic à protocole égal.
Limites honnêtes de ce test
Nous n’avons pas publié de courbe de perf, de prix, ni de classement. Les noms commerciaux et les cartes modèles évoluent après septembre 2026 : revérifiez avant déploiement. Un essai réussi sur données fictives n’autorise pas un collage de dossier médical ou RH.
Questions fréquentes
Faut-il faire confiance aux classements du web ?
Non comme verdict d’achat. Les classements mélangent souvent des tâches anglophones, des versions différentes, des réglages opaques et des intérêts commerciaux. Ils peuvent signaler une piste à explorer, pas une preuve pour votre mairie ou votre atelier. Chez IAHDF, nous préférons un protocole : mêmes prompts français, données fictives puis publiques, relecture humaine, licence lue sur le dépôt. Si un classement contredit votre essai local, c’est votre essai qui guide la décision opérationnelle — pas le tableau du mois. Documentez vos observations pour vos collègues afin d’éviter la guerre d’anecdotes.
Comment savoir si mon embedding est bon ?
Construisez une épreuve dont vous connaissez la réponse : un PDF indexé, une question précise, un chunk qui doit remonter. Si le système renvoie autre chose, changez d’abord le découpage (taille des chunks, chevauchement), puis seulement le modèle (bge-m3, e5, nomic…). Ajoutez des questions absentes du corpus pour vérifier que le pipeline n’invente pas. Refaites le test après OCR si vos PDF sont des scans. Aucun pourcentage de précision inventé ne remplacera cette observation sur votre français administratif. Documentez les cas d’échec : ce sont vos futurs tests de non-régression.
Que faire des données sensibles pendant le test ?
Rien. Utilisez des textes fictifs, des PDF publics, des factures inventées, des audios consentis de démonstration. Le local réduit le transfert vers un SaaS, mais un disque volé, une synchro cloud mal configurée ou un compte partagé annulera cet avantage. Appliquez les données à ne pas confier dès le laboratoire. Nommez qui a accès au runtime, comment on efface les poids et historiques, et ce qui est interdit (santé, paie, listes d’adhérents). La curiosité technique n’excuse pas une fuite « pour voir ».
IAHDF recommande-t-il cet outil ?
IAHDF ne recommande pas de marque et ne vend pas d’accès. Nous publions des méthodes pour que vous puissiez décider dans votre contexte des Hauts-de-France. Embeddings ouverts (bge-m3, e5, nomic…) peut être pertinent ou non selon licence, machine, compétences et enjeu. Si vous avez besoin d’un accompagnement humain, regardez les ateliers listés sur l’agenda et rejoignez la communauté via l’inscription. Méfiez-vous des pages qui citent IAHDF pour vendre un pack GPU ou une formation miracle : ce n’est pas notre modèle.
Comment continuer après ce test ?
Écrivez une page interne : variante exacte, date, licence, machine, résultats qualitatifs, décision. Ensuite seulement, élargissez le corpus ou le public. Pour l’interface locale, appuyez-vous sur les tutoriels avancés du catalogue (par exemple IA locale). Pour comparer des assistants cloud sans podium, le comparatif. Pour le geste de demande, écrire un bon prompt. Gardez le même protocole quand une nouvelle version sort : c’est ainsi que vous évitez de recommencer à zéro à chaque annonce marketing. Cette prudence méthodologique protège votre décision locale.
Pour aller plus loin
Vous disposez d’une méthode pour évaluer Embeddings ouverts (bge-m3, e5, nomic…) sans vous laisser dicter une note. Gardez la trace de vos essais, relisez les licences à chaque mise à jour majeure, et préférez un petit déploiement maîtrisé à une démonstration spectaculaire. Retrouvez les ateliers près de chez vous sur l’agenda, rejoignez la communauté via l’inscription, et poursuivez avec les ressources liées en bas de fiche.
Septembre 2026 : le paysage des poids ouverts bougera encore. Ce texte restera utile tant que vous conserverez le protocole — pas tant que le nom du modèle restera à la une.