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 :

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).
Distinguer erreur syntaxique (JSON malformé) et erreur sémantique (JSON valide mais contenu faux), et associer à chacune la bonne parade.
Démystifier la température : température 0 = déterministe, PAS = correct. Elle contrôle la variabilité, pas la véracité.
Décrire la pile d’évaluation à 4 étages : assertions → golden set → juge LLM (Large Language Model, grand modèle de langage) → évaluation humaine.
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) :

{
  "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).

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.
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.
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.
É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 :

Le schéma garantit la forme, jamais le fond.
Température 0 = reproductible, pas correct.
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) :

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.
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é.
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.
Citez les 4 étages de la pile d’évaluation, dans l’ordre coût croissant. Attendu : assertions → golden set → juge LLM → évaluation humaine.
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.