Applied AI · Intermédiaire 🟡 · Session 4
✏️ Exercices
← Retour au programme 📄 Source .md

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

Programme : Applied AI — Yann Isola · Niveau intermédiaire Rappel : RAG = Retrieval-Augmented Generation, c’est-à-dire Génération Augmentée par la Récupération.

Exercice 1 — Stratégie de découpage (chunking) sur document réel

Durée : 10 minutes · Format : binômes · Matériel : papier ou éditeur de texte

Contexte

Vous devez ingérer le document suivant dans un système RAG d’entreprise. Votre travail : décider où couper, et justifier chaque choix.

Document à découper

Politique de remboursement des frais professionnels — v3.2 (mise à jour : mars 2026)

1. Principes généraux Tout collaborateur peut demander le remboursement des frais engagés dans le cadre de ses missions. Les demandes se font via l’outil NotaFrais dans un délai de 30 jours après la dépense. Passé ce délai, la demande est refusée sauf dérogation du manager.

2. Barèmes de remboursement

Type de frais Plafond Justificatif requis
Repas (déplacement) 25 € / repas Ticket ou facture
Hôtel (France) 130 € / nuit Facture nominative
Hôtel (étranger) 180 € / nuit Facture nominative
Kilomètres (véhicule perso) 0,52 € / km Relevé de trajet

Ces plafonds sont révisés chaque année en janvier. Les dépassements exceptionnels doivent être validés avant la dépense par le responsable de service.

3. Cas particuliers Les invitations de clients suivent une procédure distincte : le formulaire REP-07 doit être joint à la demande, avec la liste nominative des invités. Le plafond est de 60 € par convive. Toute invitation dépassant 500 € au total requiert la validation du directeur commercial.

4. Contact Pour toute question : service comptabilité, comptes@exemple.fr, poste 4412.

Questions

  1. Proposez un découpage en chunks. Pour chaque chunk : indiquez son contenu (par numéros de section ou de paragraphe) et sa taille approximative.
  2. Justifiez : pourquoi ces frontières et pas d’autres ?
  3. Le tableau des barèmes : que faites-vous ? Pourquoi ?
  4. Métadonnées : listez au moins 4 métadonnées que vous attacheriez à chaque chunk, et donnez pour chacune un usage concret (filtrage, citation, sécurité…).
  5. Question piège : un utilisateur demande « quel est le plafond pour un hôtel à Berlin ? ». Quel(s) chunk(s) doivent sortir ? Votre découpage le permet-il ?

Corrigé indicatif

  1. Découpage recommandé (4 chunks) :
    • Chunk A : Section 1 entière (principes généraux) — une unité de sens complète, ~80 tokens ⚠.
    • Chunk B : Section 2 entière avec le tableau intact et son introduction + les deux phrases qui suivent (révision annuelle, dépassements) — le tableau et ses règles associées forment un tout, ~120 tokens ⚠.
    • Chunk C : Section 3 (cas particuliers / invitations clients) — sujet distinct, ~90 tokens ⚠.
    • Chunk D : Section 4 (contact) — très court ; acceptable de le fusionner avec le chunk C ou de le garder seul avec de bonnes métadonnées. Les deux réponses se défendent.
  2. Justification : découpe sur la structure (les titres de section), jamais au milieu d’une phrase ; chaque chunk est autonome — compréhensible sans lire les autres. Le document est court : inutile de viser 800 tokens, on privilégie l’unité de sens.
  3. Tableau : jamais coupé. Une ligne « 130 € / nuit | Facture nominative » séparée de son en-tête et de la colonne « Type de frais » est inexploitable. On garde le tableau entier dans un seul chunk, avec la phrase d’introduction. Astuce avancée : préfixer le chunk d’un résumé (« Barèmes de remboursement des frais : repas, hôtel, kilomètres »).
  4. Métadonnées attendues : source (Politique de remboursement v3.2) → citation dans la réponse ; section (1, 2, 3, 4) → citation précise ; date (mars 2026) → filtrage des versions périmées ; version (3.2) → détection de doublons entre versions ; niveau_acces (tous collaborateurs) → filtrage de sécurité à la récupération ; type (politique interne / RH-finance) → filtrage thématique.
  5. « Hôtel à Berlin » doit sortir le chunk B (barèmes, ligne « Hôtel (étranger) : 180 € »). Piège : « Berlin » n’apparaît nulle part dans le document — c’est l’embedding qui doit rapprocher « Berlin » de « étranger ». Si le tableau a été coupé de son contexte, la récupération échoue. C’est exactement le genre de cas qui justifie de garder tableau + contexte ensemble.

Exercice 2 — Conception complète d’un pipeline RAG ⭐ (exercice central)

Durée : 25 minutes · Format : groupes de 3–4 · Matériel : grande feuille ou document partagé

Contexte

Vous êtes l’équipe chargée de concevoir « AssistDoc », un assistant interne pour le support client d’un éditeur de logiciels. Corpus disponible :

Les agents du support poseront des questions comme : « Le client a l’erreur ERR-4471 sur la version 12.3, que faire ? » ou « Est-ce que le module export est compatible avec le SSO ? » (SSO = Single Sign-On, authentification unique).

Votre mission — concevez le pipeline en répondant aux 6 volets

Volet 1 — Ingestion. Dessinez le pipeline d’ingestion (hors ligne) de bout en bout : quelles étapes, dans quel ordre, pour quels documents ?

Volet 2 — Chunking différencié. Le même découpage pour les 5 types de documents serait une erreur. Proposez une stratégie par type de document (taille, frontières, cas des tableaux, cas des tickets question/réponse, cas des codes d’erreur).

Volet 3 — Métadonnées. Définissez le schéma de métadonnées : quels champs, et pour quel usage (filtrage, citation, gestion des contradictions entre changelogs et fiches anciennes) ?

Volet 4 — Requête. Dessinez le pipeline de requête (en ligne) pour la question « Le client a l’erreur ERR-4471 sur la version 12.3, que faire ? ». Pourquoi une recherche purement vectorielle risque-t-elle d’échouer sur cette question précise ? Que proposez-vous ?

Volet 5 — Cadrage du prompt. Rédigez l’instruction système que vous donneriez au modèle au moment de la génération (3–5 lignes), en incluant : la restriction au contexte fourni, l’exigence de citations, et le comportement en cas d’absence de réponse.

Volet 6 — Plan de test. Proposez 3 questions de test qui vérifieraient chacune un risque différent (une pour les codes exacts, une pour les contradictions de version, une pour l’absence d’information).

Corrigé indicatif

Volet 1. Collecte → conversion en texte propre (PDF → texte, en conservant la structure des titres et des tableaux) → découpage en chunks selon la stratégie du volet 2 → attachement des métadonnées → calcul de l’embedding de chaque chunk (le sens devient géométrie) → indexation dans la base vectorielle + index lexical (mots-clés) en parallèle. Ré-ingestion planifiée à chaque nouvelle note de version.

Volet 2.

Volet 3. source_type (fiche / ticket / manuel / changelog / code_erreur), produit, version_produit, date, chapitre_section, code_erreur (si applicable), qualite (pour les tickets). Usages : filtrer par version (« ne récupérer que les documents ≤ 12.3 » ou privilégier les plus récents), citer la source exacte dans la réponse, résoudre les contradictions en donnant priorité au changelog le plus récent — règle exprimable grâce à date + source_type.

Volet 4. Question → embedding → recherche vectorielle top-k + recherche par mots-clés sur ERR-4471 (et filtre métadonnée version_produit) → fusion des résultats → assemblage du prompt → génération. Risque du vectoriel pur : ERR-4471 est une chaîne arbitraire sans contenu sémantique ; son embedding est quasi indistinguable de celui d’ERR-4472. La recherche lexicale (exacte) trouve le bon code à coup sûr → recherche hybride indispensable ici.

Volet 5. Exemple attendu :

« Tu es l’assistant du support client. Réponds uniquement à partir des extraits fournis ci-dessous. Cite systématiquement la source de chaque affirmation (nom du document et section). Si les extraits ne contiennent pas la réponse, réponds : “Je ne trouve pas cette information dans la documentation fournie” et suggère de reformuler ou de vérifier le document source. En cas de contradiction entre deux extraits, privilégie le plus récent et signale la contradiction. »

Volet 6. Exemples :

  1. Code exact : « Que signifie ERR-4471 ? » → vérifie que l’hybride retrouve le bon code (et pas ERR-4417).
  2. Contradiction : « Le module export est-il compatible SSO ? » quand une fiche de 2024 dit non et le changelog 12.2 dit oui → vérifie la priorité au plus récent et le signalement.
  3. Absence : « Quelle est la politique tarifaire pour les ONG ? » (absente du corpus) → vérifie le refus élégant au lieu d’une invention.

Exercice 3 — Autopsie d’un RAG qui échoue

Durée : 15 minutes · Format : individuel puis mise en commun

Contexte

Vous auditez le RAG interne d’une entreprise. Pour chaque incident ci-dessous, on vous donne : la question, les chunks récupérés (résumés), et la réponse générée. Diagnostiquez : la faute est-elle à la récupération ou à la génération ? Que corriger ?

Incident A

Incident B

Incident C

Incident D

Questions

  1. Pour chaque incident : récupération ou génération ? Justifiez en une phrase.
  2. Pour chaque incident : une action corrective concrète.
  3. Question de synthèse : quel réflexe systématique de débogage ces quatre cas illustrent-ils ?

Corrigé indicatif

Incident A — Récupération défaillante + cadrage absent. Les chunks sont hors sujet ; le modèle a répondu depuis sa mémoire interne (la réponse est juste par chance, mais le système est incontrôlable). Corrections : améliorer la récupération (le document juridique pertinent est-il indexé ? le découpage est-il bon ?) et ajouter l’instruction « réponds uniquement à partir du contexte » — sans elle, on ne peut pas distinguer une réponse sourcée d’une réponse inventée.

Incident B — Génération défaillante. La récupération a parfaitement fonctionné (le chunk 2 contient la bonne procédure) ; le modèle a mal restitué. C’est le cas le plus rare mais il existe. Corrections : renforcer le prompt (exiger la citation textuelle de la procédure), tester un modèle plus capable, réduire le bruit dans le contexte (le chunk 3 était-il utile ?).

Incident C — Récupération défaillante : document manquant. Le modèle a correctement utilisé les chunks fournis — qui étaient tous périmés. Aucun modèle ne peut retrouver un avenant jamais ingéré. Corrections : processus de mise à jour de l’index (ré-ingestion à chaque nouvel accord) ; métadonnée date + privilégier les documents récents ; alerte sur l’âge des sources citées.

Incident D — Récupération partiellement défaillante + génération fautive. La récupération a mélangé deux produits (chunk BetaSync récupéré pour une question AlphaSync) et le modèle a fusionné les informations sans distinguer les sources. Corrections : métadonnée produit + filtrage à la récupération ; instruction de génération exigeant d’attribuer chaque affirmation à sa source ; test de non-confusion entre produits aux noms proches.

Synthèse attendue : avant d’accuser le modèle, toujours inspecter les chunks récupérés. Trois incidents sur quatre viennent de la récupération (hors sujet, périmée, ou mal filtrée). Le débogage d’un RAG commence côté récupération : les bons documents sont-ils dans l’index, bien découpés, bien filtrés, et effectivement récupérés ?