Module 1 — Pourquoi ancrer un modèle dans des documents
Les cours 16 et 17 ont montré ce qu'un grand modèle de langage sait faire et comment lui parler. Ce module explique pourquoi, dès qu'on l'installe en entreprise, ce savoir ne suffit plus, et pourquoi on doit lui apprendre à répondre en s'appuyant sur des documents qu'il n'a jamais vus à l'entraînement.
Le problème pratique : la connaissance figée
Un modèle de langage est entraîné à une date donnée, sur un corpus terminé. Passé cette date, il ne sait rien. Son savoir est également statistique : il connaît très bien ce qui a été beaucoup écrit, et mal ce qui l'a été peu. Or les documents qui comptent en entreprise — le règlement intérieur, la procédure d'onboarding d'un stagiaire, la note de service du 14 mars sur les congés — ont exactement le profil inverse : peu abondants, spécifiques, et fréquemment modifiés.
Poser la question « quelle est la durée de la période d'essai pour un cadre chez nous ? » à un modèle ordinaire produit l'un des trois résultats suivants, et il faut savoir les distinguer.
D'abord un aveu d'ignorance honnête : « je ne connais pas les règles internes de votre entreprise ». C'est le cas rare et souhaitable. Ensuite une réponse générique fondée sur la moyenne du Code du travail français, plausible mais fausse pour votre convention collective particulière. Enfin, le plus dangereux, une hallucination : le modèle invente un chiffre, souvent avec assurance, parce que le mécanisme de génération privilégie la fluidité sur la vérification.
La solution RAG en une phrase
Retrieval-Augmented Generation — génération augmentée par recherche documentaire — consiste à insérer, avant chaque appel au modèle, une étape qui va chercher dans un corpus interne les quelques passages les plus pertinents pour la question posée, puis à demander au modèle de répondre uniquement à partir de ces passages.
L'architecture d'ensemble tient en cinq boîtes :
question --> [ recherche ] --> passages --> [ consigne ] --> modele --> reponse + citations
^
|
[ index vectoriel + lexical ]
^
|
[ decoupage ] <-- [ extraction ] <-- documents
Les modules suivants remplissent chaque boîte. Ce module vous explique pourquoi cette architecture est presque toujours préférable aux deux alternatives auxquelles on pense d'abord : l'affinage et le contexte long.
RAG contre affinage
L'affinage — continuer à entraîner le modèle sur vos documents — semble intuitif : ce qui a marché pour construire le modèle général devrait marcher pour l'adapter. En pratique, ce n'est pas le bon outil pour ce problème-là.
| Critère | Affinage | RAG |
|---|---|---|
| Ajout d'un nouveau document | Réentraînement partiel ou complet | Réindexation d'un fichier |
| Suppression (droit à l'oubli) | Techniquement très difficile | Suppression de lignes de l'index |
| Citation vérifiable du passage source | Impossible | Naturelle |
| Coût par mise à jour | Élevé (heures d'accélérateur) | Faible (secondes) |
| Ce qu'on adapte | Style, vocabulaire, format de réponse | Faits, contenu |
La règle empirique tient en une phrase : on affine pour un style, on ancre pour un fait. Un modèle qui doit répondre dans le ton officiel de la maison gagne à être affiné. Un modèle qui doit citer la note du 14 mars gagne à être ancré. Les deux se combinent, mais confondre les deux besoins conduit à réentraîner sans arrêt un modèle qui aurait dû simplement chercher.
RAG contre contexte long
L'autre tentation est plus récente : les modèles acceptent aujourd'hui des fenêtres de plusieurs centaines de milliers de jetons. Pourquoi ne pas simplement leur donner tout le corpus à chaque requête ? Trois raisons rendent cela impraticable dès que le corpus dépasse quelques dizaines de pages.
D'abord le coût. La facture d'un appel est proportionnelle au nombre de jetons envoyés. Un corpus de 300 documents représente typiquement dix à cinquante millions de jetons ; envoyer l'ensemble à chaque question multiplie la note par mille par rapport à un envoi de cinq passages pertinents.
Ensuite la qualité. Contrairement à l'intuition, un contexte plus long ne donne pas toujours une meilleure réponse. Les modèles montrent une baisse mesurable de précision au milieu d'un long contexte — l'effet dit « perdu au milieu » — et sont sensibles à la présence de passages distracteurs qui ressemblent à la réponse sans l'être.
Enfin la confidentialité et le contrôle. Un système RAG peut appliquer les permissions au moment de la recherche : un stagiaire ne verra pas remonter les documents réservés à la direction. Un envoi en bloc du corpus fait perdre ce contrôle.
Si la réponse tient dans un ou deux paragraphes bien identifiés du corpus, RAG est le bon outil. Si la question exige de synthétiser des centaines de documents en même temps — audit exhaustif, comparaison à grande échelle — un long contexte ou une chaîne de traitement dédiée peuvent devenir pertinents.
Ce qu'ancrer ne résout pas
RAG déplace le problème de fond de la mémoire du modèle vers la qualité de la recherche, mais ne le fait pas disparaître. Trois échecs restent possibles et méritent d'être nommés dès maintenant, car chaque module suivant sera une réponse à l'un d'entre eux.
Premièrement, la recherche peut manquer le bon passage : il existe dans le corpus mais l'index ne l'a pas remonté. Cause typique : découpage qui coupe la phrase clef en deux (module 3), ou vocabulaire de la question trop éloigné de celui du document (module 5).
Deuxièmement, la génération peut trahir le contexte : les passages étaient bons mais le modèle a répondu autre chose, souvent parce que sa mémoire d'entraînement l'a emporté sur les documents fournis. C'est le manque de fidélité, mesuré au module 8.
Troisièmement, le corpus lui-même peut contenir des contradictions : deux notes de service disent des choses opposées, la plus récente n'est pas identifiée. Le module 7 explique comment gérer ce cas.
Un système RAG mal réglé hallucine différemment d'un modèle nu : il invente moins, mais peut affirmer une fausseté qu'il croit tirer d'un passage réel. Ce type d'erreur est plus difficile à détecter, car la citation qui l'accompagne inspire faussement confiance. La contre-mesure — vérifier que chaque affirmation de la réponse est attestée dans un passage cité — occupe l'ensemble du module 8.
En résumé
- Un modèle de langage a une connaissance figée et statistique, incompatible avec les documents rares, spécifiques et changeants qui font le quotidien d'une entreprise.
- RAG insère une étape de recherche avant la génération et demande au modèle de répondre à partir des seuls passages retrouvés, avec citation vérifiable.
- On affine pour un style, on ancre pour un fait ; le contexte long ne remplace pas l'ancrage dès que le corpus dépasse quelques dizaines de pages, à cause du coût, de la baisse de précision au milieu et des permissions.
- Ancrer ne supprime pas les hallucinations : il les rend plus rares mais aussi plus insidieuses, ce qui rend l'évaluation de fidélité indispensable.
Module suivant : extraire proprement le texte des PDF, HTML et documents bureautiques, avant même de penser à l'index.