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

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

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.