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 d’une erreur de génération.
Choisir et évaluer une amélioration robuste — multi-query, HyDE, reranking ou porte de preuve — sans ignorer latence, coût ni confidentialité.

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), 6 exit tickets

Vérification avant la séance : ouvrir webpage/index.html dans un navigateur ; tester le simulateur, le visualiseur de chunking et la cascade « RAG robuste ». 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, RAG robuste et modes d’échec (1:30 → 1:50, 20 min)

Temps	Activité	Slides
1:30–1:35	Recherche hybride : vecteurs + mots-clés	23–24
1:35–1:44	Échelle RAG robuste + cascade interactive	25–29
1:44–1:49	Diagnostic, porte de preuve et refus	30–33
1:49–1:50	Décision : répondre, reformuler ou refuser	33

Notes formateur :

Recherche hybride : les embeddings capturent le sens, mais ratent les chaînes exactes. Exemple : REF-2024-8812 a peu de sens lexical ; BM25 le retrouve exactement. Combiner les candidats vectoriels et lexicaux avant classement.
Échelle d’intervention — ne pas tout activer par défaut :
1. Multi-query : produire 2–4 reformulations, rechercher pour chacune, fusionner puis dédupliquer.
2. HyDE (Hypothetical Document Embeddings) : générer un document hypothétique, utiliser son embedding comme sonde de recherche. Ce texte n’est jamais une source.
3. Récupération large : favoriser le rappel afin de ne pas exclure trop tôt un passage utile.
4. Reranking : un cross-encoder lit chaque paire question–chunk et reclasse seulement les candidats. Il est plus coûteux et plus lent que le bi-encodeur initial.
5. Porte de preuve : répondre uniquement si les passages autorisés, actuels et non contradictoires étayent la réponse ; sinon reformuler ou refuser.
Nommer les boucles sans les vendre comme des garanties : Corrective RAG évalue les passages puis reformule ou relance la récupération ; Adaptive RAG choisit entre recherche simple, cascade ou refus selon la question ; Self-RAG demande au modèle des signaux de réflexion pendant la génération. Ces auto-évaluations sont des signaux de routage, pas une preuve externe.
Mesurer avant d’ajouter : comparer chaque variante sur le même jeu de test annoté. Suivre au minimum rappel/précision de récupération, affirmation soutenue par citation, refus correct, latence et coût. Une auto-note du modèle n’est pas une preuve externe.
Confidentialité : une recherche web est une nouvelle frontière de données. Ne jamais envoyer une question ou un extrait confidentiel à un service externe sans politique, filtrage et autorisation explicites.
Diagnostic : inspecter les chunks récupérés avant d’accuser le modèle. Si le document est absent de l’index, multi-query, HyDE et reranking ne peuvent pas le recréer.
Refus honnête : « Je ne trouve pas cette information dans les documents fournis » est un résultat attendu lorsque la porte de preuve reste fermée.

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

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

Les 6 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 : chevauchement, découpe structurelle, tables entières.
Hybride = vecteurs (sens) + mots-clés (exact).
Robuste = reformuler → récupérer large → reranker → vérifier la preuve.
Quand le RAG échoue, inspecter d’abord les chunks, puis répondre ou refuser.

4. Exit tickets (6 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 ; requête = en ligne, à chaque question.

Ticket 3. Pourquoi ne faut-il jamais couper un tableau en deux lors du chunking ? Attendu : une ligne séparée de son en-tête devient inintelligible.

Ticket 4. Votre RAG donne une réponse fausse. Quel est votre premier réflexe de diagnostic ? Attendu : inspecter les chunks récupérés et vérifier que le document attendu existe dans l’index.

Ticket 5. Pourquoi combine-t-on recherche vectorielle et recherche par mots-clés ? Attendu : les vecteurs capturent le sens ; le lexical retrouve les codes et chaînes exactes.

Ticket 6. Pourquoi une auto-évaluation positive du modèle ne suffit-elle pas à ouvrir la porte de preuve ? Attendu : le même modèle peut répéter son erreur ; il faut des citations vérifiables et des seuils calibrés sur un jeu de test externe.

5. Difficultés anticipées et parades

Difficulté	Parade
« Pourquoi pas juste mettre tous les documents dans le prompt ? »	Fenêtre limitée, bruit, latence et coût. Le RAG sélectionne le pertinent.
Confusion embedding de chunk / embedding de question	Même modèle d’embedding, même espace géométrique.
« Le fine-tuning ferait pareil »	Fine-tuning = comportement, pas faits actualisables avec citations et contrôle d’accès.
« Plus d’étapes = meilleur RAG »	Faux : chaque étape doit corriger un échec mesuré et respecter les budgets de latence, coût et confidentialité.
« Le modèle dit que sa réponse est fondée »	Une auto-évaluation n’est pas une preuve externe : exiger citations, vérification et jeu de test annoté.
Sur-optimisme (« le RAG résout les hallucinations »)	Il les réduit ; une mauvaise récupération ou génération reste possible.

6. Prolongements (si le groupe est rapide)

Comparer k petit et k grand, puis observer rappel, bruit, latence et coût.
Exécuter la cascade robuste dans webpage/index.html et demander à chaque groupe quelle étape il conserverait après évaluation.
Question ouverte : « Quels documents de votre entreprise mettriez-vous dans un RAG en premier, et quelles métadonnées seraient critiques ? »
Suite du programme — Session 5 : outils et appels de fonctions, pour permettre au modèle d’agir via des interfaces contrôlées.