# Quiz — Session 4 : RAG, donner de la mémoire au modèle

**Programme :** Applied AI — Yann Isola · Niveau intermédiaire
**11 questions · une seule bonne réponse par question · corrigé commenté en fin de document**

Rappel : RAG = *Retrieval-Augmented Generation*, c'est-à-dire Génération Augmentée par la Récupération.

---

**Q1.** Parmi les affirmations suivantes sur la connaissance d'un LLM (Large Language Model, grand modèle de langage) utilisé **sans** RAG, laquelle est FAUSSE ?

- A. Sa connaissance s'arrête à la date de coupure de son entraînement.
- B. Il n'a jamais vu les documents internes de votre entreprise.
- C. Il stocke sa connaissance de manière compressée et avec pertes dans ses poids.
- D. Il peut réciter mot pour mot n'importe quel document public de son entraînement.

**Q2.** L'analogie centrale du RAG vue en cours est :

- A. Donner des lunettes à un modèle myope.
- B. Transformer un examen à mémoire fermée en examen à livre ouvert.
- C. Remplacer le cerveau du modèle par une base de données.
- D. Apprendre une nouvelle langue au modèle.

**Q3.** Quelle est la bonne séquence du pipeline d'**ingestion** (hors ligne) ?

- A. Embedding des documents → découpage en chunks → indexation.
- B. Découpage en chunks → embedding de chaque chunk → indexation des vecteurs.
- C. Indexation des documents → découpage → génération.
- D. Embedding de la question → récupération → génération.

**Q4.** Dans le pipeline de **requête** (en ligne), pourquoi vectorise-t-on la question avec le **même modèle d'embedding** que celui utilisé pour les chunks ?

- A. Pour économiser de la mémoire.
- B. Parce que c'est plus rapide.
- C. Pour que question et chunks vivent dans le même espace géométrique, condition pour que la proximité mesure la similarité de sens.
- D. Parce que les modèles d'embedding ne fonctionnent que sur des questions.

**Q5.** Un chunk beaucoup trop grand (par exemple 5 000 tokens) pose principalement quel problème ?

- A. Il mélange plusieurs sujets : son embedding devient une « moyenne » floue, moins discriminante à la recherche.
- B. Il est illégal dans la plupart des bases vectorielles.
- C. Il rend le modèle d'embedding plus lent à entraîner.
- D. Aucun : plus le chunk est grand, meilleure est la récupération.

**Q6.** Pourquoi ajoute-t-on un **chevauchement** (overlap) entre chunks consécutifs ?

- A. Pour augmenter artificiellement la taille de l'index.
- B. Pour éviter qu'une information à cheval sur une frontière de découpage soit perdue ou coupée en deux.
- C. Pour que le modèle génère des réponses plus longues.
- D. Pour compresser les documents.

**Q7.** Lors du découpage, la règle concernant les **tableaux** est :

- A. Les couper en lignes individuelles pour des chunks plus petits.
- B. Les supprimer, car les modèles ne lisent pas les tableaux.
- C. Les garder entiers dans un seul chunk : une ligne séparée de son en-tête devient inintelligible.
- D. Les convertir systématiquement en image.

**Q8.** Un utilisateur cherche « erreur REF-2024-8812 » et le RAG purement vectoriel ne trouve rien de pertinent. Quelle est l'explication la plus probable et la solution ?

- A. Le modèle de génération est trop petit ; il faut un modèle plus grand.
- B. Les codes exacts ont peu de contenu sémantique : leur embedding ne les distingue pas bien. Solution : recherche hybride, combinant vecteurs et recherche par mots-clés.
- C. La fenêtre de contexte est saturée ; il faut la vider.
- D. Le code est trop récent pour l'embedding ; il faut ré-entraîner le modèle.

**Q9.** Votre RAG répond à côté de la question. Vous inspectez et constatez que les chunks récupérés sont hors sujet. Le diagnostic correct est :

- A. Le modèle de génération hallucine ; il faut le remplacer.
- B. La récupération a échoué : le modèle a travaillé correctement avec de mauvais ingrédients. Il faut corriger le découpage, l'index ou la recherche.
- C. L'utilisateur a posé une mauvaise question ; rien à corriger.
- D. C'est un bug aléatoire, relancer la requête suffira.

**Q10.** Quel est le rôle de l'instruction « Réponds uniquement à partir du contexte fourni ; si la réponse ne s'y trouve pas, dis-le » ?

- A. Accélérer la génération.
- B. Réduire le coût des requêtes.
- C. Empêcher le modèle de combler les trous avec sa mémoire interne, et permettre un refus honnête plutôt qu'une invention plausible.
- D. Forcer le modèle à toujours répondre, même sans information.

**Q11.** Une « auto-correction » demande au même modèle d'affirmer que sa réponse est bien fondée. Pourquoi cela ne suffit-il pas à ouvrir la porte de preuve ?

- A. Parce qu'un modèle ne peut jamais relire sa réponse.
- B. Parce que la même erreur peut être répétée : il faut des citations vérifiables et des seuils calibrés sur un jeu de test externe.
- C. Parce que seul HyDE peut vérifier une réponse.
- D. Parce que le reranking remplace toute évaluation.

---

## Corrigé commenté

**Q1 — D.** La connaissance est stockée *avec pertes* (lossy) : le modèle retient l'idée générale, pas le texte exact — comme vous après un livre lu il y a dix ans. A, B, C sont précisément les trois limites vues en cours (figée, publique, avec pertes).

**Q2 — B.** Le LLM seul passe l'examen de mémoire ; le RAG l'autorise à apporter les bons documents. On ne remplace pas le modèle (C) et on ne le ré-entraîne pas (D) : on enrichit son prompt au moment de la question.

**Q3 — B.** Ingestion : découper → vectoriser chaque chunk (le sens devient géométrie, cf. Session 1) → indexer les vecteurs. La réponse D décrit le pipeline de *requête*, pas d'ingestion.

**Q4 — C.** La recherche des « k chunks les plus proches de la question » n'a de sens que si tout le monde est dans le même espace. Deux modèles d'embedding différents produisent des espaces incompatibles : les distances n'y signifient rien.

**Q5 — A.** Un chunk fourre-tout a un embedding « moyen » qui ne ressemble fortement à aucune question précise. Il gaspille aussi la fenêtre de contexte à la génération. La bonne plage est typiquement 300–800 tokens ⚠, découpée sur la structure.

**Q6 — B.** Sans chevauchement (typiquement 10–20 % ⚠), une phrase clé à cheval sur deux chunks peut n'être entière dans aucun des deux — donc introuvable.

**Q7 — C.** « 130 € / nuit | Facture nominative » sans l'en-tête ni la colonne « Type de frais » est inexploitable. Le tableau entier + sa phrase d'introduction = un chunk.

**Q8 — B.** `REF-2024-8812` est une chaîne arbitraire : sémantiquement proche de n'importe quel autre code. La recherche lexicale (par mots-clés, type BM25) le trouve exactement. D'où la recherche **hybride** : vecteurs pour le sens, mots-clés pour l'exact.

**Q9 — B.** Réflexe n°1 du débogage RAG : inspecter les chunks. Ici la preuve est faite — c'est la récupération. Changer de modèle (A) ne servirait à rien : le cuisinier ne peut rien faire si le commis apporte les mauvais ingrédients.

**Q10 — C.** Ce cadrage réduit fortement les hallucinations et rend possible le **refus élégant** : « je ne trouve pas cette information dans les documents fournis » est une bonne réponse — bien meilleure qu'une invention crédible. D est l'exact opposé du comportement recherché.

**Q11 — B.** Une auto-correction peut être utile comme signal de routage, mais le même modèle peut confirmer sa propre erreur. La porte de preuve exige des citations vérifiables et des seuils calibrés sur un **jeu de test externe** ; ni HyDE ni le reranking ne remplacent cette preuve.

---

### Barème indicatif

| Score | Lecture |
|---|---|
| 10–11 | Excellente maîtrise — sait choisir une amélioration RAG et exiger une preuve externe. |
| 8–9 | Solide. Revoir les questions ratées avec le corrigé. |
| 6–7 | Relire les pipelines, la cascade robuste et les modes d'échec. |
| < 6 | Refaire les exercices 2 et 4, puis repasser le quiz. |