Guide du formateur — Session 4 (Niveau intermédiaire)

RAG : donner de la mémoire au modèle

Programme : Applied AI — Yann Isola Durée : 2 h 00 Public : professionnels ayant suivi les sessions 1 à 3 (embeddings, fenêtre de contexte, prompting) Module source : Module 3, partie 1

1. Objectifs pédagogiques

À la fin de la session, chaque participant doit être capable de :

Expliquer pourquoi la connaissance d’un LLM (Large Language Model, grand modèle de langage) est limitée : figée à la date de coupure, publique uniquement, stockée de manière compressée et avec pertes dans les poids du modèle.
Décrire le principe du RAG (Retrieval-Augmented Generation, c’est-à-dire Génération Augmentée par la Récupération) : transformer chaque question en « examen à livre ouvert ».
Dessiner les deux pipelines : ingestion (hors ligne) et requête (en ligne), avec leurs étapes respectives.
Prendre des décisions de découpage (chunking) : taille de chunk, chevauchement, découpe sur la structure, tables entières.
Diagnostiquer un échec de RAG : distinguer une erreur de récupération (mauvais chunks, document manquant) d’une erreur de génération (hallucination du modèle).

2. Prérequis et matériel

Élément	Détail
Prérequis participants	Session 1 (embeddings : le sens devient géométrie), Session 2-3 (contexte, prompting)
Matériel formateur	Vidéoprojecteur, slides de la session, page web interactive `webpage/index.html` (fonctionne hors ligne)
Matériel participants	Ordinateur portable recommandé pour les exercices 2 et 3 (papier possible)
Documents à imprimer	Feuille d’exercices (1 par personne), quiz (1 par personne), 5 exit tickets

Vérification avant la séance : ouvrir webpage/index.html dans un navigateur, tester le simulateur de pipeline RAG et le visualiseur de chunking. Aucune connexion Internet requise.

3. Déroulé minuté (120 minutes)

Bloc A — Le problème : une mémoire figée (0:00 → 0:20, 20 min)

Temps	Activité	Slides
0:00–0:05	Accueil + rappel express Session 1 : « le sens devient géométrie » (embeddings)	1–3
0:05–0:15	Les trois limites de la mémoire d’un LLM	4–7
0:15–0:20	Mini-démo : question sur un fait interne fictif → le modèle ne peut pas savoir	8

Notes formateur :

Ouvrir avec une question au groupe : « Si je demande à un modèle le montant de vos congés restants, que va-t-il répondre ? » Réponses attendues : il ne sait pas, ou pire, il invente. Les deux cas illustrent le problème.
Marteler les trois limites :
1. Figée : la connaissance s’arrête à la date de coupure d’entraînement (knowledge cutoff). Tout ce qui est postérieur n’existe pas pour le modèle.
2. Publique : le modèle a été entraîné sur des données publiques. Vos documents internes, contrats, procédures, tickets — jamais vus.
3. Avec pertes : même la connaissance publique est stockée de façon lossy (compressée avec pertes) dans les poids. Analogie : le modèle a « lu » Wikipédia mais ne peut pas le réciter mot pour mot — comme vous après avoir lu un livre il y a dix ans.
Analogie centrale à installer dès maintenant : examen à mémoire fermée vs examen à livre ouvert. Le LLM seul = étudiant qui passe l’examen de mémoire. Le RAG = on lui donne le droit d’apporter les bons documents.
Piège fréquent : des participants pensent que le fine-tuning (ré-entraînement partiel) est la solution pour injecter des connaissances. Noter l’objection au tableau, y revenir en fin de bloc B : le fine-tuning apprend des comportements (style, format), pas des faits fiables et à jour ; il est coûteux et doit être refait à chaque mise à jour documentaire. Le RAG met à jour l’index en quelques secondes.

Bloc B — Le principe du RAG et les deux pipelines (0:20 → 0:55, 35 min)

Temps	Activité	Slides
0:20–0:30	Définition du RAG + vue d’ensemble des deux pipelines	9–11
0:30–0:40	Pipeline d’ingestion (hors ligne) : découper → vectoriser → indexer	12–14
0:40–0:50	Pipeline de requête (en ligne) : vectoriser la question → récupérer k chunks → assembler le prompt → générer	15–17
0:50–0:55	Démo interactive : simulateur de pipeline sur la page web	17

Notes formateur :

Définir chaque terme à la première utilisation — règle du cours :
- RAG = Retrieval-Augmented Generation, Génération Augmentée par la Récupération.
- Chunk = fragment de document (on gardera le mot anglais, standard dans le métier, en le traduisant une fois : « morceau »).
- Embedding = plongement vectoriel, vu en Session 1 : un texte devient un point dans un espace géométrique où la proximité = similarité de sens.
- Top-k = les k résultats les plus proches (k est un nombre qu’on choisit, souvent 3 à 10 ⚠).
Insister sur la séparation temporelle des deux pipelines :
- Ingestion : se fait une fois (puis à chaque mise à jour des documents), hors ligne, sans utilisateur. C’est la préparation de la bibliothèque.
- Requête : se fait à chaque question, en ligne, en quelques centaines de millisecondes ⚠. C’est la consultation de la bibliothèque.
Schéma au tableau (le refaire à la main, même s’il est dans les slides — le geste aide la mémorisation) :

INGESTION (hors ligne, une fois)
Documents → Découpage en chunks → Embedding de chaque chunk → Index vectoriel

REQUÊTE (en ligne, à chaque question)
Question → Embedding de la question → Recherche des k chunks les plus proches
        → Assemblage du prompt (instruction + chunks + question) → Génération

Point clé conceptuel : la question et les chunks vivent dans le même espace géométrique. C’est pour ça que « chercher les chunks proches de la question » a un sens. Relier explicitement à la Session 1.
Exemple concret à dérouler oralement de bout en bout : « Quelle est la politique de télétravail pour les nouveaux embauchés ? »
1. La question devient un vecteur.
2. L’index renvoie 4 chunks : deux extraits du règlement intérieur, un extrait de l’accord télétravail 2025, un extrait du guide d’onboarding.
3. Le prompt assemblé : « Réponds uniquement à partir du contexte suivant. [4 chunks] Question : … »
4. Le modèle génère une réponse citant l’accord télétravail.
Démo (5 min) : projeter webpage/index.html, onglet « Simulateur de pipeline ». Taper une question, faire dérouler les 4 étapes une à une. Demander au groupe de prédire quels chunks vont sortir avant de cliquer.

Pause (0:55 → 1:05, 10 min)

Bloc C — Les décisions de chunking et les métadonnées (1:05 → 1:30, 25 min)

Temps	Activité	Slides
1:05–1:15	Chunking : taille, chevauchement, structure, tables	18–21
1:15–1:20	Métadonnées : source, section, date, niveau d’accès	22
1:20–1:30	Exercice 1 en binômes : stratégie de découpage d’un document réel	—

Notes formateur :

Le chunking est le levier n°1 de qualité d’un RAG. Le dire tel quel.
Les quatre décisions :
1. Taille : typiquement 300 à 800 tokens ⚠ (rappel : 1 token ≈ 0,75 mot en anglais, un peu moins en français ⚠). Trop petit = le chunk perd son contexte (« il » — qui ça, « il » ?). Trop grand = le chunk mélange plusieurs sujets et son embedding devient une moyenne floue.
2. Chevauchement (overlap) : faire se recouvrir les chunks de 10 à 20 % ⚠ pour ne pas couper une information pile à la frontière.
3. Découper sur la structure : titres, sections, paragraphes — jamais au milieu d’une phrase. Un chunk = idéalement une unité de sens.
4. Tables entières : ne jamais couper un tableau en deux. Une ligne de tableau sans son en-tête est illisible (exemple : « 42 | 15 % | oui » — de quoi parle-t-on ?).
Analogie : découper un livre en fiches de révision. Une bonne fiche est autonome (compréhensible seule), ni trop courte ni trop longue, et ne coupe pas un tableau de conjugaison en deux.
Métadonnées : chaque chunk transporte une étiquette — source (quel document), section, date, niveau d’accès. Trois usages :
- Filtrage avant recherche : « ne chercher que dans les documents RH postérieurs à 2024 ».
- Citations : la réponse peut pointer vers le document source — indispensable pour la confiance et la vérification.
- Sécurité : un commercial ne doit pas récupérer des chunks du dossier paie. Le filtre par niveau d’accès se fait à la récupération, pas après génération.
Exercice 1 (10 min, binômes) : voir feuille d’exercices. Distribuer l’extrait de document fourni. Circuler entre les binômes. Débrief express : 2 binômes présentent leur découpage, comparer les choix sur le tableau intégré.

Bloc D — Recherche hybride et modes d’échec (1:30 → 1:50, 20 min)

Temps	Activité	Slides
1:30–1:38	Recherche hybride : vecteurs + mots-clés	23–24
1:38–1:48	Modes d’échec : la faute à la récupération, pas au modèle	25–27
1:48–1:50	« Réponds uniquement à partir du contexte » + refus élégant	28

Notes formateur :

Recherche hybride : les embeddings capturent le sens, mais ratent les chaînes exactes. Exemple frappant à donner : chercher « erreur REF-2024-8812 » — sémantiquement, ce code ne « veut rien dire », son embedding est proche de n’importe quel autre code. Une recherche par mots-clés (type BM25, algorithme classique de recherche lexicale) le trouve instantanément. Autres cas : noms propres rares, références produit, numéros d’article de loi. Solution : combiner les deux et fusionner les résultats.
Modes d’échec — le message le plus important de la session : quand un RAG répond mal, le réflexe est d’accuser le modèle. Dans la majorité des cas ⚠, c’est la récupération qui a échoué :
1. Mauvais chunks récupérés : la question était ambiguë, ou les chunks mal découpés, ou k trop petit. Le modèle génère à partir d’un contexte hors sujet → réponse hors sujet. Le modèle a fait son travail avec de mauvais ingrédients.
2. Document manquant : l’information n’a jamais été ingérée. Aucun modèle ne peut retrouver ce qui n’est pas dans l’index.
- Analogie : le cuisinier (modèle) et le commis (récupération). Si le plat est raté parce que le commis a apporté du sel au lieu du sucre, changer de cuisinier ne résoudra rien.
- Conséquence pratique : toujours inspecter les chunks récupérés avant d’accuser le modèle. C’est le premier réflexe de débogage d’un RAG.
L’instruction de cadrage : « Réponds uniquement à partir du contexte fourni. Si la réponse ne s’y trouve pas, dis-le. » Deux effets :
- Réduit fortement les hallucinations (le modèle ne comble plus avec sa mémoire interne).
- Permet le refus élégant : « Je ne trouve pas cette information dans les documents fournis » est une bonne réponse — infiniment meilleure qu’une invention plausible. Le dire explicitement : dans un RAG d’entreprise, un refus honnête est un succès, pas un échec.

Bloc E — Quiz, synthèse, exit tickets (1:50 → 2:00, 10 min)

Temps	Activité
1:50–1:56	Quiz (10 QCM, correction collective rapide ou en autonomie)
1:56–1:59	Synthèse : les 5 idées à retenir
1:59–2:00	Exit tickets

Les 5 idées à retenir (à projeter ou dicter) :

La mémoire d’un LLM est figée, publique et avec pertes → le RAG rend l’examen « à livre ouvert ».
Deux pipelines : ingestion (hors ligne) et requête (en ligne).
Le chunking est le levier n°1 : 300–800 tokens ⚠, chevauchement, découpe structurelle, tables entières.
Hybride = vecteurs (sens) + mots-clés (codes exacts).
Quand le RAG échoue, suspecter d’abord la récupération — inspecter les chunks avant d’accuser le modèle.

4. Exit tickets (5 questions)

Distribuer un ticket par participant (une seule question chacun, en tournant), réponse en 1–2 phrases, ramassage à la sortie. Objectif : mesurer la compréhension réelle, pas noter.

Ticket 1. Citez les trois limites de la connaissance d’un modèle de langage seul, sans RAG. Attendu : figée à la date de coupure ; uniquement publique ; stockée avec pertes dans les poids.

Ticket 2. Quelle est la différence entre le pipeline d’ingestion et le pipeline de requête ? Quand chacun s’exécute-t-il ? Attendu : ingestion = hors ligne, préparation (découpage, embedding, indexation), une fois / à chaque mise à jour ; requête = en ligne, à chaque question (embedding de la question, récupération, assemblage du prompt, génération).

Ticket 3. Pourquoi ne faut-il jamais couper un tableau en deux lors du chunking ? Donnez un exemple de ce qui se passerait. Attendu : une ligne séparée de son en-tête devient inintelligible ; ex. « 42 | 15 % » sans savoir ce que représentent les colonnes.

Ticket 4. Votre RAG donne une réponse fausse. Quel est votre premier réflexe de diagnostic, et pourquoi ? Attendu : inspecter les chunks récupérés ; la cause la plus fréquente est une récupération défaillante (mauvais chunks ou document absent de l’index), pas le modèle.

Ticket 5. Pourquoi combine-t-on recherche vectorielle et recherche par mots-clés (recherche hybride) ? Donnez un exemple de requête que les vecteurs seuls rateraient. Attendu : les vecteurs capturent le sens mais ratent les chaînes exactes ; ex. un code produit « REF-2024-8812 », un nom propre rare, un numéro d’article.

5. Difficultés anticipées et parades

Difficulté	Parade
« Pourquoi pas juste mettre tous les documents dans le prompt ? »	Fenêtre de contexte limitée et coûteuse ; qualité qui se dégrade avec un contexte très long ; coût par requête. Le RAG sélectionne le pertinent.
Confusion embedding de chunk / embedding de question	Rappeler : même modèle d’embedding, même espace. C’est la condition pour que la proximité ait un sens.
« Le fine-tuning ferait pareil »	Fine-tuning = comportement, pas faits ; coûteux ; obsolète à chaque mise à jour documentaire ; pas de citations ; pas de contrôle d’accès.
Participants perdus sur « lossy »	Analogie du livre lu il y a dix ans : on retient l’idée, pas le texte exact.
Sur-optimisme (« le RAG résout les hallucinations »)	Non : il les réduit avec un bon cadrage, mais une mauvaise récupération produit de mauvaises réponses. Le RAG déplace le problème vers la qualité de la récupération.

6. Prolongements (si le groupe est rapide)

Discuter le choix de k : petit k = risque de rater l’info ; grand k = bruit dans le contexte et coût. Valeurs courantes 3–10 ⚠.
Évoquer le reranking (ré-ordonnancement des chunks récupérés par un second modèle) comme amélioration classique — sera approfondi en session suivante.
Question ouverte : « Quels documents de votre entreprise mettriez-vous dans un RAG en premier, et quelles métadonnées seraient critiques ? »