Objectifs pédagogiques
- Énoncer, pour n’importe quelle requête, ce que contient réellement la fenêtre de contexte : la question, les sources injectées, les fichiers joints et la mémoire persistante.
- Prédire quel mode de défaillance produit une surface donnée : rappel périmé, résumé infidèle, ou calcul non vérifié.
- Choisir la surface la moins coûteuse capable de répondre correctement, au lieu de se rabattre par défaut sur la plus puissante.
- Vérifier une réponse adossée à la recherche en ouvrant ses citations et en qualifiant chaque affirmation : étayée, non étayée, ou invérifiable.
- Lire un programme émis comme l’artefact vérifiable d’un calcul, plutôt que de faire confiance au nombre affiché.
- Estimer le coût relatif d’un tour à contexte long et expliquer pourquoi coller un document entier est rarement gratuit.
- Auditer la mémoire persistante et les instructions personnalisées comme une surface de confidentialité, et non comme un simple confort d’usage.
Matériel nécessaire
- Un appareil par participant, avec accès à au moins deux surfaces LLM différentes (un chat simple et une surface avec recherche).
- Une question dont la bonne réponse a changé au cours des six derniers mois — préparée à l’avance par le formateur.
- L’outil interactif tokenizer (lié depuis la page cours) pour le segment sur le budget de contexte.
- Un petit tableau de nombres ou fichier CSV pour l’atelier d’exécution de code (20 à 40 lignes suffisent).
- Un tableau blanc pour le schéma « qu’y a-t-il dans la fenêtre ? ».
- Repli hors ligne : captures d’écran préparées d’une réponse avec sa liste de citations, pour que l’atelier de vérification fonctionne sans réseau.
Déroulé minute par minute
| Temps | Durée | Séquence |
|---|---|---|
| 0:00 | 10 min | Cadrage : le même modèle, quatre surfaces différentes — qu’est-ce qui change vraiment ? |
| 0:10 | 15 min | Concept 1 : une surface est une politique de contexte. Schéma de la fenêtre au tableau. |
| 0:25 | 20 min | Atelier A : l’expérience de la date de coupure (sans recherche puis avec recherche). |
| 0:45 | 10 min | Concept 2 : la recherche déplace le mode de défaillance. Débriefing de l’atelier A. |
| 0:55 | 5 min | Pause. |
| 1:00 | 20 min | Atelier B : calcul délégué — lire le programme, pas le nombre. |
| 1:20 | 15 min | Concept 3 : coût d’exploitation, budget de contexte et outil tokenizer. |
| 1:35 | 15 min | Concept 4 : persistance et confidentialité. Audit d’un panneau mémoire en direct. |
| 1:50 | 10 min | Bilan : la règle de sélection de surface et la limite honnête. |
Messages clés à faire passer
- Le modèle est souvent le même ; c’est la surface qui décide de ce qui entre dans la fenêtre de contexte. Choisir une surface est une décision d’ingénierie, pas une préférence d’interface.
- La recherche ne rend pas une réponse vraie. Elle échange le risque de rappel périmé contre celui de mauvaises sources et de résumé infidèle.
- Une citation est une promesse, pas une preuve. L’affirmation n’est vérifiée qu’une fois la source ouverte par un humain.
- Quand une surface exécute du code, l’artefact vérifiable est le programme. Un nombre d’apparence correcte peut sortir d’un code faux.
- Le contexte est facturé au compteur. Les fenêtres longues coûtent plus cher et décodent plus lentement : bornez ce que vous collez.
- La mémoire et les instructions personnalisées survivent à la session. Révisez-les comme n’importe quelle donnée personnelle stockée.
Pièges fréquents
Les participants concluent que « celle avec la recherche est simplement meilleure ».
Imposez un contre-exemple : posez un fait stable et bien connu où la recherche ajoute latence, coût et source médiocre sans améliorer la réponse. L’enjeu est l’adéquation, pas le classement.
La démonstration de la date de coupure réussit silencieusement parce que le chat « simple » a aussi la recherche activée.
Vérifiez la configuration des surfaces avant la session et désactivez explicitement les outils. Si c’est impossible, utilisez les captures préparées plutôt que d’improviser.
Les participants vérifient les citations en lisant seulement l’extrait affiché dans la réponse.
Exigez l’ouverture de la source dans un nouvel onglet. L’extrait est du texte généré ; la page est la preuve.
L’atelier d’exécution de code se transforme en séance de débogage.
Gardez un jeu de données minuscule et une tâche arithmétique. L’objectif est de lire le programme émis, pas d’en écrire un.
Les comparaisons entre éditeurs prennent toute la séance.
Annoncez d’emblée que les fonctionnalités grand public changent tous les mois et que toute comparaison est datée. Enseignez les critères de choix, pas le palmarès du moment.
Des participants collent des données confidentielles dans une surface à mémoire persistante pendant les ateliers.
Annoncez avant l’atelier A que toutes les entrées doivent être non sensibles, et montrez où désactiver ou effacer la mémoire.