--- title: "Session 4 — RAG : donner de la mémoire au modèle" author: "Applied AI · Yann Isola" theme: "Palette : ink #1A2230 · teal #0F7A6C · copper #B4612A · light #E9F6F3 · bg #F4F7F6" --- # Slide 1 — Titre ## RAG : donner de la mémoire au modèle **Applied AI · Niveau intermédiaire · Session 4 · 2 h** RAG = *Retrieval-Augmented Generation* — Génération Augmentée par la Récupération > **Notes :** Accueillir. Annoncer le fil rouge : à la fin de la séance, chacun saura dessiner un pipeline RAG complet et diagnostiquer pourquoi un RAG répond mal. Rappeler que cette session s'appuie directement sur la Session 1 (embeddings). --- # Slide 2 — Ce que vous saurez faire dans 2 heures 1. Expliquer les **trois limites** de la mémoire d'un LLM 2. Dessiner les **deux pipelines** du RAG (ingestion / requête) 3. Prendre les **décisions de chunking** (découpage) 4. Justifier la **recherche hybride** 5. **Diagnostiquer** un RAG qui échoue — sans accuser le modèle à tort > **Notes :** LLM = Large Language Model, grand modèle de langage — redéfinir même si le groupe connaît. Chaque objectif correspond à un bloc de la séance. --- # Slide 3 — Rappel Session 1 : le sens devient géométrie - Un embedding transforme un texte en **vecteur** (liste de nombres) - Textes de sens proche → **points proches** dans l'espace - « congés » et « vacances » : voisins. « congés » et « serveur SQL » : éloignés > **Notes :** Interroger le groupe 30 secondes : « qui peut me redéfinir un embedding ? ». Ce rappel est la fondation de toute la séance — la récupération vectorielle n'est QUE de la géométrie. Sans ça, la suite est du vaudou. --- # Slide 4 — Expérience de pensée ## « Combien me reste-t-il de jours de congés ? » Que répond un modèle de langage seul ? ❌ Il ne sait pas… ou pire : **il invente** > **Notes :** Laisser le groupe répondre. Les deux issues (aveu d'ignorance / invention plausible) illustrent le problème. Enchaîner : POURQUOI ne peut-il pas savoir ? → slide suivante. --- # Slide 5 — Limite n°1 : une mémoire figée - La connaissance s'arrête à la **date de coupure** de l'entraînement (*knowledge cutoff*) - Tout événement postérieur **n'existe pas** pour le modèle - Exemple : une réorganisation interne de mars 2026 est invisible pour un modèle entraîné avant > **Notes :** Analogie : un journal imprimé — excellent le jour J, jamais mis à jour ensuite. Préciser que ré-entraîner un modèle coûte des millions ⚠ : on ne le fait pas pour rafraîchir des faits. --- # Slide 6 — Limite n°2 : une mémoire publique - Entraînement sur des données **publiques** (web, livres, code…) - Vos contrats, procédures, tickets, wikis internes : **jamais vus** - Le modèle ne connaît pas votre entreprise — par construction > **Notes :** C'est la limite la plus importante en contexte professionnel. Question au groupe : « quels documents de VOTRE quotidien un modèle n'a jamais vus ? » — faire lister 3-4 exemples concrets, on les réutilisera au bloc chunking. --- # Slide 7 — Limite n°3 : une mémoire avec pertes - La connaissance est stockée **compressée, avec pertes** (*lossy*) dans les poids - Le modèle a « lu » Wikipédia… mais ne peut pas le **réciter** - Comme vous avec un livre lu il y a dix ans : l'idée reste, le texte exact non > **Notes :** C'est la limite la moins intuitive. Conséquence : même sur du public, le modèle peut déformer des détails (dates, chiffres, noms). D'où les hallucinations plausibles. Les trois limites ensemble justifient le RAG. --- # Slide 8 — Mini-démo : le mur **Question au modèle (sans RAG) :** « Quelle est la procédure de remboursement des frais chez [entreprise fictive] ? » Réponse : générique, inventée, ou refus. **Le modèle passe un examen à mémoire fermée.** > **Notes :** Démo en direct si un modèle est disponible hors ligne, sinon captures dans le support. Installer l'expression « examen à mémoire fermée » — le RAG sera « à livre ouvert ». --- # Slide 9 — L'idée du RAG ## Transformer chaque question en examen à livre ouvert **RAG = Retrieval-Augmented Generation** (Génération Augmentée par la Récupération) Au lieu de compter sur la mémoire du modèle : on **retrouve** les bons documents, on les **donne** au modèle, il **répond avec**. > **Notes :** LA slide pivot. On ne modifie pas le modèle, on ne le ré-entraîne pas : on enrichit son prompt au moment de la question. Le modèle reste le même — c'est son contexte qui change. --- # Slide 10 — Pourquoi pas tout mettre dans le prompt ? - Fenêtre de contexte **limitée** (et vos documents = des milliers de pages) - Contexte très long = qualité qui **se dégrade** + coût par requête qui explose - Le RAG **sélectionne** : seuls les passages pertinents entrent dans le prompt > **Notes :** Objection fréquente à désamorcer tout de suite. Analogie : pour répondre à une question d'examen, on n'apporte pas la bibliothèque entière — on apporte les 3 bonnes fiches. --- # Slide 11 — Vue d'ensemble : deux pipelines | | **Ingestion** | **Requête** | |---|---|---| | Quand | Hors ligne, en amont | En ligne, à chaque question | | Fréquence | Une fois + mises à jour | Des milliers de fois par jour | | Rôle | Préparer la bibliothèque | Consulter la bibliothèque | > **Notes :** Séparation temporelle fondamentale — les participants les confondent systématiquement. L'ingestion se fait SANS utilisateur ; la requête se joue en quelques centaines de millisecondes ⚠. --- # Slide 12 — Pipeline d'ingestion (1/3) : découper **Documents → chunks** (morceaux) - Un document entier = trop gros, trop hétérogène - On le découpe en fragments de **300 à 800 tokens ⚠** - Chaque chunk = idéalement **une unité de sens** > **Notes :** Rappel : 1 token ≈ 0,75 mot en anglais, un peu moins en français ⚠. Le mot « chunk » restera en anglais (standard du métier) — le traduire une fois : « morceau ». Les décisions fines de découpage arrivent au bloc C. --- # Slide 13 — Pipeline d'ingestion (2/3) : vectoriser **Chaque chunk → un embedding** - Le sens de chaque chunk devient un **point dans l'espace** (Session 1) - Chunks de sens proche → points voisins > **Notes :** Insister : c'est le MÊME mécanisme qu'en Session 1, appliqué à chaque morceau de document. Un corpus de 10 000 chunks = 10 000 points dans un espace de plusieurs centaines de dimensions ⚠. --- # Slide 14 — Pipeline d'ingestion (3/3) : indexer **Les vecteurs → un index vectoriel** - Base spécialisée pour répondre vite à : « quels sont les k points les plus proches de celui-ci ? » - Résultat de l'ingestion : une **bibliothèque interrogeable par le sens** > **Notes :** Ne pas entrer dans les détails d'implémentation des bases vectorielles — hors périmètre. Retenir la fonction : recherche des plus proches voisins, rapide, à grande échelle. --- # Slide 15 — Pipeline de requête (1/2) **À chaque question :** 1. **Vectoriser la question** — avec le *même* modèle d'embedding que les chunks 2. **Récupérer** les **k chunks** les plus proches (k ≈ 3 à 10 ⚠) > **Notes :** Point conceptuel clé : question et chunks doivent vivre dans le MÊME espace, sinon « proche » ne veut rien dire. Deux modèles d'embedding différents = deux espaces incompatibles. Sur k : petit = risque de rater l'info ; grand = bruit + coût. --- # Slide 16 — Pipeline de requête (2/2) 3. **Assembler le prompt** : ``` Instruction : « Réponds uniquement à partir du contexte. » + Contexte : [chunk 1] [chunk 2] [chunk 3] + Question de l'utilisateur ``` 4. **Générer** : le modèle répond **à livre ouvert**, en citant ses sources > **Notes :** Montrer qu'il n'y a AUCUNE magie : le RAG, c'est de l'assemblage de prompt. Le modèle ne « se connecte » à rien — il lit ce qu'on lui met sous les yeux, rien de plus. --- # Slide 17 — Démo : le simulateur de pipeline 🖥️ `webpage/index.html` — onglet **Simulateur de pipeline RAG** Question → embedding → récupération top-3 → prompt assemblé → réponse citée > **Notes :** 5 minutes. Taper « Combien de jours de télétravail par semaine ? ». Avant chaque étape, demander au groupe de PRÉDIRE ce qui va sortir. Terminer par la question piège « politique tarifaire pour les ONG » → refus élégant (teasing du bloc D). Puis pause. --- # Slide 18 — Le chunking : le levier n°1 ## La qualité d'un RAG se joue d'abord au découpage 4 décisions : **taille** · **chevauchement** · **structure** · **tables** > **Notes :** Reprise après pause. Annoncer la couleur : un RAG médiocre a presque toujours un chunking médiocre. Analogie fil rouge : découper un livre en fiches de révision. --- # Slide 19 — Décision 1 & 2 : taille et chevauchement - **Trop petit** : « Il doit être validé avant. » — qui, « il » ? Le chunk a perdu son contexte - **Trop grand** : plusieurs sujets mélangés → embedding « moyen », flou, mal récupéré - **Bonne plage : 300–800 tokens ⚠** - **Chevauchement de 10–20 % ⚠** : aucune info ne meurt coupée à la frontière > **Notes :** Faire la démo au visualiseur de chunking (onglet 2) : taille fixe minuscule → phrases orphelines ; puis activer le chevauchement et montrer la zone surlignée cuivre. --- # Slide 20 — Décision 3 : découper sur la structure - Couper sur **titres, sections, paragraphes** — jamais en pleine phrase - Un chunk = une unité de sens **autonome** - Astuce : préfixer chaque chunk de son fil d'Ariane (« Chapitre 4 > Export > Formats supportés ») > **Notes :** Le fil d'Ariane rend le chunk compréhensible seul ET améliore sa récupération (les mots du titre comptent dans l'embedding). Montrer la stratégie « structurelle » dans le visualiseur : les sections restent entières. --- # Slide 21 — Décision 4 : les tables restent entières Une ligne coupée de son en-tête : > « 130 € / nuit | Facture nominative » — **de quoi parle-t-on ?** **Règle : un tableau = jamais coupé.** Tableau entier + sa phrase d'introduction = un chunk. > **Notes :** Exemple volontairement frappant. Dans le visualiseur, la stratégie « taille fixe » coupe le tableau des barèmes en plein milieu — le montrer. Cas réels : grilles tarifaires, matrices de compatibilité, barèmes RH. --- # Slide 22 — Les métadonnées : l'étiquette de chaque chunk Chaque chunk transporte : **source · section · date · niveau d'accès** | Usage | Exemple | |---|---| | **Filtrage** | « chercher uniquement dans les docs RH ≥ 2024 » | | **Citations** | la réponse pointe le document source — vérifiable | | **Sécurité** | un commercial ne récupère pas les chunks du dossier paie | > **Notes :** Insister sur la sécurité : le filtre par niveau d'accès s'applique À LA RÉCUPÉRATION, jamais après génération (si le chunk entre dans le prompt, l'info peut fuiter dans la réponse). Les citations = condition de la confiance en entreprise. Lancer l'exercice 1 juste après cette slide. --- # Slide 23 — Les vecteurs ratent les codes exacts Cherchez « erreur **REF-2024-8812** » : - Sémantiquement, ce code ne « veut rien dire » - Son embedding ≈ celui de **REF-2024-8811**, **ERR-4471**, n'importe quel code - La recherche vectorielle renvoie… n'importe quoi > **Notes :** Démo choc à l'explorateur de similarité (onglet 3) : cliquer ERR-4471 vs ERR-4472 → similarité quasi 1 alors qu'ils désignent des choses différentes. Autres victimes : noms propres rares, références produit, numéros d'articles de loi. --- # Slide 24 — La solution : recherche hybride **Vecteurs** (le sens) **+ mots-clés** (l'exact) → fusion des résultats - Vectoriel : « congés paternité » trouve « congé de naissance » - Lexical (type BM25) : « ERR-4471 » trouvé **exactement**, à coup sûr - Le standard des RAG sérieux : **les deux, combinés** > **Notes :** BM25 = algorithme classique de recherche par mots-clés (le citer sans le détailler). Message : vectoriel et lexical ne sont pas concurrents mais complémentaires — chacun rattrape les angles morts de l'autre. --- # Slide 25 — Quand le RAG échoue… qui est coupable ? ## Réflexe erroné : « le modèle hallucine, changeons de modèle » ## Réflexe correct : **inspecter d'abord les chunks récupérés** Dans la majorité des cas ⚠, la faute est à la **récupération**, pas au modèle. > **Notes :** LE message opérationnel de la session. Analogie du cuisinier et du commis : si le commis apporte du sel au lieu du sucre, changer de cuisinier ne sauvera pas le dessert. --- # Slide 26 — Mode d'échec 1 : mauvais chunks récupérés - Question ambiguë, chunking défaillant, ou k trop petit - Le modèle reçoit un contexte **hors sujet** → répond hors sujet - **Le modèle a bien travaillé… avec de mauvais ingrédients** Correctifs : re-découper, ajuster k, reformuler, hybride > **Notes :** Exemple : question « délai de rétractation » → chunks récupérés sur la signature électronique et l'archivage. La réponse sera fatalement mauvaise, quel que soit le modèle. C'est l'incident A de l'exercice 3. --- # Slide 27 — Mode d'échec 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 - Exemple : l'avenant congés 2025 jamais indexé → le RAG cite l'accord périmé de 2022 Correctifs : processus de mise à jour de l'index, métadonnée date, alerte sur l'âge des sources > **Notes :** Cas vicieux : la réponse semble sourcée et propre — elle est juste périmée. D'où l'importance des métadonnées de date et d'un processus de ré-ingestion à chaque mise à jour documentaire. --- # Slide 28 — Le cadrage et le refus élégant **Instruction :** « Réponds **uniquement** à partir du contexte fourni. Si la réponse ne s'y trouve pas, **dis-le**. » - Coupe l'accès à la mémoire interne → moins d'hallucinations - « Je ne trouve pas cette information dans les documents fournis » = **une bonne réponse** ## Un refus honnête vaut mieux qu'une invention plausible. > **Notes :** En entreprise, le refus élégant est un critère de qualité, pas un échec. Il déclenche la bonne action humaine : vérifier si le document existe, l'ingérer, reformuler. Relier à la démo « question ONG » du simulateur. --- # Slide 29 — Synthèse : les 5 idées à retenir 1. Mémoire du LLM : **figée, publique, avec pertes** → RAG = livre ouvert 2. **Deux pipelines** : ingestion (hors ligne) / requête (en ligne) 3. **Chunking = levier n°1** : 300–800 tokens ⚠, chevauchement, structure, tables entières 4. **Hybride** : vecteurs (sens) + mots-clés (exact) 5. Échec ? **Inspecter les chunks d'abord** — la récupération avant le modèle > **Notes :** Faire reformuler chaque point par un participant différent. Ce sont les 5 réponses attendues aux exit tickets. --- # Slide 30 — Quiz, exit tickets & prochaine session - 📝 Quiz : 10 questions, 6 minutes - 🎫 Exit ticket : 1 question, 2 phrases, à rendre en sortant - **Session 5 :** évaluer et améliorer un RAG — mesurer la qualité de la récupération, reranking, pièges avancés > **Notes :** Distribuer quiz puis tickets. Teasing session 5 : « vous savez construire un RAG ; la prochaine fois, vous saurez prouver qu'il marche — et le réparer quand il ne marche pas. » Ramasser les tickets à la porte.