# Guide enseignant — Session 3 (Niveau intermédiaire) # Sortie structurée, température & évaluations **Programme :** Applied AI — Yann Isola **Durée :** 2 h 00 **Prérequis :** Sessions 1–2 (anatomie d'un prompt, contexte, rôles system/user, notions d'API — Application Programming Interface, interface de programmation applicative) **Module source :** Module 2, partie 2 --- ## 1. Objectifs pédagogiques À la fin de la session, chaque participant doit être capable de : 1. **Expliquer** pourquoi une sortie JSON (JavaScript Object Notation, format d'échange de données structurées) « généralement valide » est inacceptable en production, et citer le mécanisme qui garantit la validité syntaxique (function calling / sortie structurée contrainte par schéma). 2. **Distinguer** erreur *syntaxique* (JSON malformé) et erreur *sémantique* (JSON valide mais contenu faux), et associer à chacune la bonne parade. 3. **Démystifier** la température : température 0 = déterministe, PAS = correct. Elle contrôle la variabilité, pas la véracité. 4. **Décrire** la pile d'évaluation à 4 étages : assertions → golden set → juge LLM (Large Language Model, grand modèle de langage) → évaluation humaine. 5. **Construire** un prompt d'extraction robuste qui survit aux cas limites (montants en lettres, tentatives d'injection, chaînes vides) — c'est le labo de la session. **Thèse centrale de la session (à marteler) :** *« La suite d'évaluation EST la spécification. »* Un produit IA sans évals, c'est un produit dont personne ne connaît le comportement réel. « Ça avait l'air bien dans la démo » est la cause de mortalité n°1 des produits IA. --- ## 2. Matériel - Vidéoprojecteur + slides (`slides/slides.md`) - Page interactive (`webpage/index.html`) — fonctionne **hors ligne**, à ouvrir dans un navigateur ; contient le validateur de schéma JSON, le simulateur de dashboard d'évals et le comparateur de température - Feuilles d'exercices imprimées ou partagées (`exercises/exercises.md`) - Accès à un playground LLM (Claude, ChatGPT, Mistral… peu importe) pour le labo — 1 poste pour 2 participants suffit - Quiz (`quiz/quiz.md`) — à faire en fin de séance ou en asynchrone --- ## 3. Déroulé minuté (120 min) ### Bloc A — Accroche : le JSON qui casse tout (0:00 → 0:15, 15 min) **Ouverture choc (5 min).** Racontez l'histoire type : une équipe déploie un extracteur de factures. En démo, le modèle renvoie du JSON parfait 50 fois de suite. En production, à la 3 412ᵉ facture, il renvoie : ``` Voici le JSON demandé : ```json {"montant": 1250, "devise": "EUR" ``` Virgule manquante, préambule verbeux, bloc de code non fermé. Le parseur crashe, le pipeline s'arrête à 2 h du matin. **Question à la salle :** « Qui a déjà vu un LLM ajouter du texte avant le JSON alors qu'on lui a dit "réponds UNIQUEMENT en JSON" ? » (Les mains se lèvent — c'est universel.) **Message clé (10 min).** « Généralement valide » × volume = échec certain. Si le modèle produit du JSON valide 99 % du temps et que vous traitez 10 000 documents/jour, vous avez **~100 crashs par jour** ⚠ (chiffre illustratif — le taux réel varie selon modèle et prompt). La solution n'est pas un meilleur prompt, c'est une **contrainte structurelle**. > **Note enseignant :** résistez à la tentation de montrer la solution tout de suite. Laissez les participants proposer leurs rustines habituelles (regex, retry aveugle, « je lui redemande gentiment »). Vous les démonterez au bloc B. --- ### Bloc B — Sortie structurée : function calling & schémas (0:15 → 0:45, 30 min) **B1. Les rustines et pourquoi elles fuient (5 min).** - Regex pour extraire le JSON du texte → fragile, casse sur les JSON imbriqués. - « Réponds uniquement en JSON » dans le prompt → améliore, ne garantit pas. - Retry aveugle → coûte des tokens, ne converge pas toujours. **B2. La vraie solution : tool_use / function calling (15 min).** Expliquez le mécanisme : au lieu de demander du texte « qui ressemble à du JSON », on déclare un **outil** (tool) avec un **schéma JSON** (JSON Schema : standard de description de la structure attendue — types, champs obligatoires, énumérations). Le fournisseur du modèle **contraint le décodage** : les tokens générés ne peuvent former qu'un document conforme au schéma. L'erreur syntaxique devient structurellement impossible. Exemple à projeter (extraction de note de frais) : ```json { "name": "extraire_note_de_frais", "description": "Extrait les champs d'une note de frais", "input_schema": { "type": "object", "properties": { "montant": { "type": "number", "description": "Montant TTC en valeur numérique" }, "devise": { "type": "string", "enum": ["EUR", "USD", "GBP", "CHF"] }, "date": { "type": "string", "description": "Format ISO 8601 : AAAA-MM-JJ" }, "categorie": { "type": "string", "enum": ["transport", "repas", "hebergement", "autre"] } }, "required": ["montant", "devise", "date", "categorie"] } } ``` Points d'insistance : - `enum` : le modèle ne peut PAS inventer une catégorie hors liste. - `required` : les champs obligatoires seront présents (syntaxiquement). - Tous les grands fournisseurs offrent une variante : *tool use* (Anthropic), *function calling* et *structured outputs* (OpenAI), *function calling* (Google, Mistral). Les noms diffèrent, le principe est identique. **B3. La limite fondamentale (10 min) — transition vers le bloc C.** Écrivez au tableau, en grand : > **Le schéma garantit la FORME, jamais le FOND.** Exemple concret : le reçu dit « quarante-deux euros ». Le modèle renvoie `{"montant": 402, "devise": "EUR", ...}` — JSON **parfaitement valide**, contenu **faux**. C'est une **erreur sémantique**. Le validateur de schéma ne la verra jamais. **Démo interactive :** ouvrez `webpage/index.html`, onglet « Validateur de schéma ». Faites valider un JSON syntaxiquement correct mais sémantiquement faux — le validateur dit ✅. Effet garanti. --- ### Bloc C — Erreurs sémantiques : valider, réessayer, corriger (0:45 → 1:05, 20 min) **C1. Taxonomie (5 min).** Tableau à deux colonnes : | | Erreur syntaxique | Erreur sémantique | |---|---|---| | **Exemple** | Virgule manquante, champ absent | Montant faux, date hallucinée, catégorie plausible mais erronée | | **Détection** | Parseur / validateur de schéma | Règles métier, recoupement, juge LLM, humain | | **Parade** | Function calling (élimination structurelle) | Validation + retry avec feedback + garde-fous métier | **C2. Le pattern « validate → retry with feedback » (10 min).** Pseudo-code à projeter : ``` resultat = appel_llm(document, schema) erreurs = valider_metier(resultat) # ex : montant > 0, date <= aujourd'hui, # devise cohérente avec le pays si erreurs: resultat = appel_llm(document, schema, feedback="Ta réponse précédente contenait : " + erreurs + ". Corrige et renvoie.") si toujours en erreur après N tentatives: escalader_vers_humain(document) ``` Points clés : - Le feedback doit être **spécifique** (« le montant 402 ne correspond à aucun nombre du document ») — un retry aveugle sans feedback ne converge presque jamais. - **Toujours** un plafond de tentatives (2–3) et une voie d'escalade humaine. Boucle infinie = facture API infinie. - Les validations métier sont du code classique, déterministe, gratuit : elles attrapent une énorme part des erreurs sémantiques (montants négatifs, dates futures, totaux incohérents). **C3. Mini-exercice éclair (5 min).** À l'oral : « Pour un extracteur de notes de frais, citez 3 règles de validation métier. » Attendus : montant > 0 ; date pas dans le futur ; date pas antérieure à N années ; devise ∈ liste autorisée ; TVA ≤ montant TTC ; etc. --- ### PAUSE (1:05 → 1:15, 10 min) --- ### Bloc D — Température : déterminisme ≠ exactitude (1:15 → 1:30, 15 min) **D1. Ce que fait vraiment la température (7 min).** Le modèle produit une distribution de probabilité sur le prochain token. La température **remodèle cette distribution** : - **T = 0** : on prend (quasi) toujours le token le plus probable → sorties très reproductibles. - **T élevée (0.8–1.2)** : les tokens moins probables sont davantage tirés → variété, créativité, mais aussi dérive. **Le piège à détruire (à dire mot pour mot) :** « Température 0 ne rend pas le modèle plus intelligent ni plus factuel. Si le token le plus probable est faux, T = 0 vous donne **la même erreur, à chaque fois, avec une régularité parfaite**. Vous obtenez un mensonge reproductible, pas une vérité. » La température contrôle la **variabilité**, pas l'**exactitude**. > **Note enseignant :** précisez aussi que même à T = 0, le déterminisme absolu n'est pas garanti chez tous les fournisseurs (parallélisme GPU — Graphics Processing Unit, processeur graphique —, mises à jour de modèles). « Quasi-déterministe » est le terme honnête. **D2. Réglages pratiques (3 min).** | Cas d'usage | Température conseillée ⚠ (repères usuels, à ajuster) | |---|---| | Extraction, classification, sortie structurée | 0 – 0.2 | | Rédaction assistée, reformulation | 0.5 – 0.8 | | Brainstorming, créativité | 0.9 – 1.2 | **D3. Démo (5 min).** Ouvrez l'onglet « Comparateur de température » de la page interactive : même prompt simulé à T = 0 (3 sorties identiques, dont une erreur reproduite 3 fois) vs T = 1 (3 sorties différentes). Faites verbaliser : « Que remarquez-vous sur l'erreur à T = 0 ? » --- ### Bloc E — Les évaluations : la suite d'évals EST la spec (1:30 → 1:50, 20 min) **E1. La thèse (5 min).** En logiciel classique, la spec dit ce que le code doit faire, et les tests le vérifient. Avec les LLM, le comportement est **non déterministe et non spécifiable par le code** : la seule définition opérationnelle de « ça marche » est **la suite d'évaluation**. D'où la thèse : > **« La suite d'évals EST la spec. »** > Si un comportement n'est pas couvert par une éval, vous ne savez pas s'il fonctionne. « Ça avait l'air bien dans la démo » = vous avez testé 5 cas choisis par la personne qui voulait que ça marche. **E2. La pile d'évaluation à 4 étages (10 min).** 1. **Assertions** (code, gratuit, instantané) : le JSON parse-t-il ? Les champs requis sont-ils là ? Le montant est-il > 0 ? → attrape le grossier, tourne à chaque commit. 2. **Golden set** (50 à 500 exemples ⚠ ordre de grandeur usuel) : paires entrée → sortie attendue, validées par un humain. Inclut délibérément les **cas limites** et les **cas adverses**. On mesure un taux de réussite ; toute modification de prompt ou de modèle repasse le golden set. 3. **Juge LLM (LLM-as-judge)** : un second modèle note les sorties selon une grille (fidélité, complétude, ton). Scalable, mais le juge a ses propres biais → il faut **calibrer le juge contre des jugements humains** avant de lui faire confiance. 4. **Évaluation humaine** : échantillonnage régulier en production, revue des cas escaladés. Coûteux, lent, mais c'est la vérité terrain qui recalibre tout le reste. **E3. Métriques selon le type de système (5 min).** - **RAG (Retrieval-Augmented Generation, génération augmentée par récupération de documents)** : **fidélité** (*faithfulness*) — la réponse est-elle soutenue par les documents récupérés, sans invention ? - **Agents** : **taux de complétion de tâche** — la tâche est-elle réellement terminée, pas juste « une réponse a été produite » ? - **Systèmes avec humain dans la boucle** : **taux d'escalade** — quelle proportion part vers un humain ? Trop haut = système inutile ; trop bas = vérifier qu'il n'avale pas des cas qu'il devrait escalader. **Démo :** onglet « Dashboard d'évals » de la page interactive. Lancez le prompt v1 (naïf) contre le jeu de test : les cas limites échouent. Passez au prompt v3 (durci) : le taux monte. Le message : **on ne compare pas des impressions, on compare des taux de réussite sur le même jeu de test.** --- ### Bloc F — Labo : l'extracteur de notes de frais indestructible (1:50 → 2:00, 10 min en séance + suite en exercices) Lancez l'exercice 3 (labo). En séance : présentation du jeu de test piégé (montants en lettres, injection, chaîne vide) et premier tour d'itération. La suite se fait en autonomie ou en début de session suivante. **Clôture (2 min).** Les 3 phrases à retenir : 1. Le schéma garantit la forme, jamais le fond. 2. Température 0 = reproductible, pas correct. 3. Pas d'éval = pas de spec = pas de produit. Distribuez le quiz (ou lien) + exit tickets. --- ## 4. Notes pédagogiques & pièges fréquents - **Piège 1 :** des participants concluent « avec function calling, plus besoin de valider ». Faux — recadrez immédiatement avec l'exemple « quarante-deux → 402 ». - **Piège 2 :** confusion température / top-p / top-k. Restez sur la température ; mentionnez juste que d'autres paramètres d'échantillonnage existent et qu'on ne les cumule pas au hasard. - **Piège 3 :** « 50–500 exemples, c'est trop de travail ». Réponse : commencez à 20, enrichissez avec chaque bug de production. Un golden set vivant vaut mieux qu'un golden set parfait jamais construit. - **Piège 4 :** le juge LLM présenté comme oracle. Rappelez : un juge non calibré, c'est une opinion automatisée. - **Public hétérogène :** les non-développeurs peuvent faire tout le labo dans un playground sans écrire de code — le schéma se colle dans l'interface d'outils, les validations métier se raisonnent sur papier. --- ## 5. Exit tickets (5 questions, 5 min en fin de séance) Chaque participant répond par écrit (papier ou formulaire) : 1. **Expliquez en une phrase pourquoi « le modèle renvoie du JSON valide 99 % du temps » est un problème en production.** *Attendu : à volume élevé, 1 % d'échec = pannes quotidiennes ; seule la contrainte par schéma (function calling) élimine la classe d'erreur.* 2. **Le modèle renvoie `{"montant": 402}` pour un reçu de « quarante-deux euros ». Syntaxique ou sémantique ? Quelle parade ?** *Attendu : sémantique ; validation métier / recoupement + retry avec feedback spécifique, escalade humaine si échec répété.* 3. **Vrai ou faux : « À température 0, le modèle ne fait plus d'erreurs factuelles. » Justifiez.** *Attendu : Faux. T = 0 rend l'erreur reproductible, pas absente. La température contrôle la variabilité, pas l'exactitude.* 4. **Citez les 4 étages de la pile d'évaluation, dans l'ordre coût croissant.** *Attendu : assertions → golden set → juge LLM → évaluation humaine.* 5. **Votre assistant RAG répond avec fluidité mais invente des références. Quelle métrique surveiller, et par quel étage de la pile la mesurer en continu ?** *Attendu : la fidélité (faithfulness) ; juge LLM calibré (avec échantillonnage humain périodique).* --- ## 6. Liens avec le reste du programme - **Session 2** (contexte & prompts) : les techniques de prompt restent nécessaires — le schéma contraint la forme, le prompt guide le fond. - **Session 4** (RAG) : la métrique de fidélité introduite ici devient centrale. - **Sessions agents** : le taux de complétion de tâche et l'escalade y seront instrumentés en pratique.