English

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

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. Choisir une amélioration robuste : multi-query, HyDE, reranking ou porte de preuve
  6. Diagnostiquer un RAG qui échoue — sans accuser le modèle à tort

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

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

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

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

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

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.

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.

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

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

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

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

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

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 ⚠)

Slide 16 — Pipeline de requête (2/2)

  1. Assembler le prompt :
Instruction : « Réponds uniquement à partir du contexte. »
+ Contexte : [chunk 1] [chunk 2] [chunk 3]
+ Question de l'utilisateur
  1. Générer : le modèle répond à livre ouvert, en citant ses sources

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

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

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

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 »)

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.

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

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

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

Slide 25 — Du RAG vanilla au RAG robuste

Un mauvais résultat ne justifie pas d'empiler toutes les techniques.

Échelle d'intervention :
question faible → multi-query / HyDE → récupération large → reranking → porte de preuve → réponse ou refus

Slide 26 — Étape 1 : mieux formuler la recherche

  • Multi-query : produire 2–4 reformulations, récupérer pour chacune, puis fusionner et dédupliquer
  • HyDE (Hypothetical Document Embeddings) : générer un document-réponse hypothétique, puis utiliser son embedding pour chercher
  • HyDE sert de sonde de recherche : le texte hypothétique n'est ni une source ni une réponse

Slide 27 — Étape 2 : récupérer large, puis reranker

  1. Le bi-encodeur récupère vite un ensemble large de candidats
  2. Un cross-encoder lit chaque paire question–chunk
  3. Le reranking garde les quelques passages les mieux étayés

Pourquoi deux étages ? rappel large d'abord, précision ensuite.

Slide 28 — Étape 3 : la porte de preuve

Avant de générer, vérifier :

  • les passages répondent-ils réellement à la question ?
  • les sources sont-elles autorisées, actuelles et non contradictoires ?
  • chaque affirmation importante pourra-t-elle être citée ?

Preuve suffisante → répondre. Preuve insuffisante → reformuler ou refuser.

Slide 29 — Le coût de la robustesse

Chaque étape supplémentaire peut ajouter :

  • latence : plusieurs recherches et appels de modèle ;
  • coût : reformulations, HyDE et cross-encoder ;
  • risque de confidentialité : une recherche web ne doit jamais recevoir des données privées sans politique explicite ;
  • complexité d'évaluation : plus de routes, donc plus de modes d'échec.

Slide 30 — 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 de nombreux incidents, la faute est à la récupération, pas au modèle.

Slide 31 — 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
  • Correctifs gradués : re-découper, hybride, multi-query, puis reranking si les candidats utiles sont présents mais mal classés

Slide 32 — 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 : mise à jour de l'index, métadonnée date, alerte sur l'âge des sources

Slide 33 — 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. »

  • Réduit le recours à la mémoire interne, sans garantir zéro hallucination
  • « Je ne trouve pas cette information dans les documents fournis » = une bonne réponse

Un refus honnête vaut mieux qu'une invention plausible.

Slide 34 — Synthèse : les 6 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 : chevauchement, structure, tables entières
  4. Hybride : vecteurs (sens) + mots-clés (exact)
  5. Robuste : reformuler → récupérer → reranker → vérifier la preuve
  6. Échec ? Inspecter les chunks d'abord, puis répondre ou refuser

Slide 35 — Quiz, exit tickets & prochaine session

  • 📝 Quiz : 11 questions, 7 minutes
  • 🎫 Exit ticket : 1 question, 2 phrases, à rendre en sortant
  • Session 5 : outils et appels de fonctions — permettre au modèle d'agir via des interfaces contrôlées

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).

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.

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.

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.

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.

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.

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.

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 ».

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.

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.

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 ⚠.

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.

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 ⚠.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Notes: « RAG vanilla » désigne ici le pipeline simple vu jusqu'à présent. La suite est une boîte à outils conditionnelle : on ajoute une étape seulement lorsqu'un jeu de test montre le problème qu'elle corrige.

Notes: Exemple : « Comment ça marche pour les nouveaux ? » devient « conditions de télétravail des nouveaux embauchés », « ancienneté requise pour le télétravail » et « exceptions d'éligibilité ». HyDE peut aider lorsque la question est très courte, mais peut aussi injecter un mauvais angle : toujours comparer sur un jeu de test.

Notes: Le cross-encoder est plus précis mais plus lent : on ne l'applique pas à tout le corpus. Ne pas promettre qu'il améliore toujours le système ; mesurer rappel, précision, latence et coût sur les mêmes requêtes.

Notes: Une note produite par le même modèle n'est pas une preuve externe. La décision doit être calibrée sur un jeu de test annoté : réponses attendues, absences attendues et contradictions connues. Situer les familles sans les confondre : **Corrective RAG** évalue les passages et relance la récupération ; **Adaptive RAG** choisit une route selon la question ; **Self-RAG** produit des signaux de réflexion. Dans les trois cas, une auto-note reste un **signal de routage**, jamais une preuve externe.

Notes: Le bon pipeline n'est pas le plus complexe. C'est le plus simple qui atteint les seuils de qualité, sécurité, latence et coût définis sur un jeu de test représentatif.

Notes: Analogie du cuisinier et du commis : si le commis apporte du sel au lieu du sucre, changer de cuisinier ne sauvera pas le dessert. Éviter un pourcentage non sourcé : l'origine doit être établie incident par incident.

Notes: Ne pas appliquer HyDE ou reranking par réflexe. Si le document n'est pas dans l'index, aucune de ces étapes ne peut le recréer.

Notes: Une réponse propre et citée peut rester périmée. La fraîcheur du corpus est une propriété du système, pas du modèle.

Notes: La porte de preuve décide si l'on peut répondre ; le prompt encadre ensuite la génération. Une auto-évaluation du modèle ne remplace ni les citations vérifiables ni le jeu de test externe.

Notes: Faire reformuler les points 4 à 6 : technique, preuve attendue et coût associé.

Notes: Ne plus annoncer une session RAG inexistante. Le perfectionnement RAG est inclus dans cette session sous forme d'échelle d'intervention et d'exercice diagnostique.