# 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 : 1. **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. 2. **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 ». 3. **Dessiner** les deux pipelines : ingestion (hors ligne) et requête (en ligne), avec leurs étapes respectives. 4. **Prendre des décisions de découpage (chunking)** : taille de chunk, chevauchement, découpe sur la structure, tables entières. 5. **Diagnostiquer** un échec de RAG : distinguer une erreur de récupération d'une erreur de génération. 6. **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) :** 1. La mémoire d'un LLM est figée, publique et avec pertes → le RAG rend l'examen « à livre ouvert ». 2. Deux pipelines : ingestion (hors ligne) et requête (en ligne). 3. Le chunking est le levier n°1 : chevauchement, découpe structurelle, tables entières. 4. Hybride = vecteurs (sens) + mots-clés (exact). 5. Robuste = reformuler → récupérer large → reranker → vérifier la preuve. 6. 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.