# 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 (mauvais chunks, document manquant) d'une erreur de génération (hallucination du modèle).

---

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

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

| Temps | Activité | Slides |
|---|---|---|
| 1:30–1:38 | Recherche hybride : vecteurs + mots-clés | 23–24 |
| 1:38–1:48 | Modes d'échec : la faute à la récupération, pas au modèle | 25–27 |
| 1:48–1:50 | « Réponds uniquement à partir du contexte » + refus élégant | 28 |

**Notes formateur :**

- **Recherche hybride** : les embeddings capturent le *sens*, mais ratent les *chaînes exactes*. Exemple frappant à donner : chercher « erreur REF-2024-8812 » — sémantiquement, ce code ne « veut rien dire », son embedding est proche de n'importe quel autre code. Une recherche par mots-clés (type BM25, algorithme classique de recherche lexicale) le trouve instantanément. Autres cas : noms propres rares, références produit, numéros d'article de loi. **Solution : combiner les deux** et fusionner les résultats.
- **Modes d'échec — le message le plus important de la session :** quand un RAG répond mal, le réflexe est d'accuser le modèle. Dans la majorité des cas ⚠, c'est la *récupération* qui a échoué :
  1. **Mauvais chunks récupérés** : la question était ambiguë, ou les chunks mal découpés, ou k trop petit. Le modèle génère à partir d'un contexte hors sujet → réponse hors sujet. Le modèle a fait son travail avec de mauvais ingrédients.
  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.
  - Analogie : le cuisinier (modèle) et le commis (récupération). Si le plat est raté parce que le commis a apporté du sel au lieu du sucre, changer de cuisinier ne résoudra rien.
  - Conséquence pratique : **toujours inspecter les chunks récupérés avant d'accuser le modèle.** C'est le premier réflexe de débogage d'un RAG.
- **L'instruction de cadrage** : « Réponds uniquement à partir du contexte fourni. Si la réponse ne s'y trouve pas, dis-le. » Deux effets :
  - Réduit fortement les hallucinations (le modèle ne comble plus avec sa mémoire interne).
  - Permet le **refus élégant** : « Je ne trouve pas cette information dans les documents fournis » est une *bonne* réponse — infiniment meilleure qu'une invention plausible. Le dire explicitement : dans un RAG d'entreprise, un refus honnête est un succès, pas un échec.

---

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

| Temps | Activité |
|---|---|
| 1:50–1:56 | Quiz (10 QCM, correction collective rapide ou en autonomie) |
| 1:56–1:59 | Synthèse : les 5 idées à retenir |
| 1:59–2:00 | Exit tickets |

**Les 5 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 : 300–800 tokens ⚠, chevauchement, découpe structurelle, tables entières.
4. Hybride = vecteurs (sens) + mots-clés (codes exacts).
5. Quand le RAG échoue, suspecter d'abord la récupération — inspecter les chunks avant d'accuser le modèle.

---

## 4. Exit tickets (5 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 (découpage, embedding, indexation), une fois / à chaque mise à jour ; requête = en ligne, à chaque question (embedding de la question, récupération, assemblage du prompt, génération).*

**Ticket 3.** Pourquoi ne faut-il jamais couper un tableau en deux lors du chunking ? Donnez un exemple de ce qui se passerait.
*Attendu : une ligne séparée de son en-tête devient inintelligible ; ex. « 42 | 15 % » sans savoir ce que représentent les colonnes.*

**Ticket 4.** Votre RAG donne une réponse fausse. Quel est votre premier réflexe de diagnostic, et pourquoi ?
*Attendu : inspecter les chunks récupérés ; la cause la plus fréquente est une récupération défaillante (mauvais chunks ou document absent de l'index), pas le modèle.*

**Ticket 5.** Pourquoi combine-t-on recherche vectorielle et recherche par mots-clés (recherche hybride) ? Donnez un exemple de requête que les vecteurs seuls rateraient.
*Attendu : les vecteurs capturent le sens mais ratent les chaînes exactes ; ex. un code produit « REF-2024-8812 », un nom propre rare, un numéro d'article.*

---

## 5. Difficultés anticipées et parades

| Difficulté | Parade |
|---|---|
| « Pourquoi pas juste mettre tous les documents dans le prompt ? » | Fenêtre de contexte limitée et coûteuse ; qualité qui se dégrade avec un contexte très long ; coût par requête. Le RAG sélectionne le pertinent. |
| Confusion embedding de chunk / embedding de question | Rappeler : même modèle d'embedding, même espace. C'est la condition pour que la proximité ait un sens. |
| « Le fine-tuning ferait pareil » | Fine-tuning = comportement, pas faits ; coûteux ; obsolète à chaque mise à jour documentaire ; pas de citations ; pas de contrôle d'accès. |
| Participants perdus sur « lossy » | Analogie du livre lu il y a dix ans : on retient l'idée, pas le texte exact. |
| Sur-optimisme (« le RAG résout les hallucinations ») | Non : il les réduit avec un bon cadrage, mais une mauvaise récupération produit de mauvaises réponses. Le RAG déplace le problème vers la qualité de la récupération. |

---

## 6. Prolongements (si le groupe est rapide)

- Discuter le choix de k : petit k = risque de rater l'info ; grand k = bruit dans le contexte et coût. Valeurs courantes 3–10 ⚠.
- Évoquer le *reranking* (ré-ordonnancement des chunks récupérés par un second modèle) comme amélioration classique — sera approfondi en session suivante.
- Question ouverte : « Quels documents de votre entreprise mettriez-vous dans un RAG en premier, et quelles métadonnées seraient critiques ? »