# Quiz — Session 3 (Niveau intermédiaire) # Sortie structurée, température & évaluations **Programme :** Applied AI — Yann Isola **10 questions — une seule bonne réponse par question, sauf mention contraire.** **Barème suggéré : 1 point par question. Seuil de validation : 7/10.** --- ### Q1. En production, votre pipeline traite 20 000 documents/jour. Le modèle renvoie du JSON (JavaScript Object Notation) syntaxiquement valide « 99,5 % du temps ». Quelle est la lecture correcte ? - A. C'est excellent : 99,5 % est un très bon score, le pipeline est fiable. - B. C'est environ 100 échecs de parsing par jour ⚠ : il faut éliminer structurellement cette classe d'erreur, pas l'accepter. - C. Il suffit d'ajouter « réponds uniquement en JSON » au prompt pour atteindre 100 %. - D. Il faut baisser la température à 0 pour garantir un JSON toujours valide. **Réponse : B.** À volume élevé, un petit pourcentage d'échec devient un flux quotidien de pannes. Les instructions de prompt (C) améliorent sans garantir ; la température (D) contrôle la variabilité, pas la validité syntaxique. La bonne réponse est la contrainte structurelle (function calling / sortie contrainte par schéma). --- ### Q2. Quel mécanisme rend l'erreur *syntaxique* structurellement impossible dans la sortie du modèle ? - A. Un retry automatique tant que le JSON ne parse pas. - B. Une regex qui extrait le bloc JSON de la réponse. - C. Le function calling / tool use : le décodage est contraint par un schéma JSON déclaré. - D. Un exemple de JSON bien formé dans le prompt (few-shot). **Réponse : C.** Avec le function calling, le fournisseur contraint la génération : les tokens ne peuvent former qu'un document conforme au schéma. A et B sont des rustines curatives ; D améliore la probabilité sans garantie. --- ### Q3. Le reçu indique « quarante-deux euros ». Le modèle renvoie `{"montant": 402, "devise": "EUR"}` — JSON parfaitement conforme au schéma. De quel type d'erreur s'agit-il, et qui peut la détecter ? - A. Syntaxique — le validateur de schéma la rejettera. - B. Sémantique — le validateur de schéma la laisse passer ; il faut des règles métier, un recoupement, un juge ou un humain. - C. Syntaxique — le function calling l'aurait empêchée. - D. Ce n'est pas une erreur : 402 est un nombre valide. **Réponse : B.** Le schéma garantit la *forme*, jamais le *fond*. Un JSON valide peut être factuellement faux : c'est la définition de l'erreur sémantique, invisible pour le validateur. --- ### Q4. Dans le pattern « validation → retry avec feedback », quel élément est indispensable pour que le retry ait des chances de converger ? - A. Augmenter la température à chaque tentative pour explorer d'autres réponses. - B. Renvoyer exactement le même prompt, le modèle finira par tomber juste. - C. Inclure un feedback **spécifique** décrivant l'erreur détectée (ex. « le montant 402 ne figure nulle part dans le document »), avec un plafond de tentatives et une escalade humaine. - D. Supprimer le schéma pour laisser le modèle s'exprimer librement. **Réponse : C.** Un retry aveugle (B) ne converge presque jamais ; sans plafond, on paie des boucles infinies. Le feedback ciblé donne au modèle l'information nécessaire pour corriger. --- ### Q5. Laquelle de ces affirmations sur la température 0 est correcte ? - A. Elle garantit que le modèle ne commet plus d'erreurs factuelles. - B. Elle rend les sorties (quasi) reproductibles : si le token le plus probable est faux, l'erreur sera reproduite à l'identique. - C. Elle force le modèle à répondre plus lentement mais plus précisément. - D. Elle n'a d'effet que sur les sorties JSON, pas sur le texte libre. **Réponse : B.** La température contrôle la **variabilité** de l'échantillonnage, pas l'**exactitude**. T = 0 produit un comportement quasi déterministe — y compris des erreurs parfaitement reproductibles. --- ### Q6. Pour une tâche d'extraction structurée en production, quel réglage de température est le plus indiqué ? - A. 1,2 — pour que le modèle trouve des solutions créatives aux documents difficiles. - B. 0 à 0,2 ⚠ (repère usuel) — la variabilité n'apporte rien à une tâche d'extraction, la reproductibilité facilite le débogage et les évals. - C. 0,7 — le « juste milieu » recommandé pour tous les usages. - D. La température n'a aucun impact sur les tâches d'extraction. **Réponse : B.** Extraction et classification bénéficient d'une variabilité minimale. La créativité (A) est utile en brainstorming, pas pour lire un reçu. --- ### Q7. Que signifie la thèse « la suite d'évals EST la spec » ? - A. Il faut écrire la spécification avant les évaluations, comme en cycle en V. - B. Le comportement d'un système LLM (Large Language Model, grand modèle de langage) n'étant pas spécifiable par le code, la seule définition opérationnelle de « ça marche » est l'ensemble des cas d'évaluation qui passent. - C. Les évals remplacent la documentation utilisateur. - D. Un produit avec 100 % d'évals réussies n'a plus besoin de supervision humaine. **Réponse : B.** Un comportement non couvert par une éval est un comportement inconnu. « Ça avait l'air bien dans la démo » = 5 cas choisis par la personne qui voulait que ça marche. D est fausse : l'évaluation humaine reste l'étage qui recalibre tout le reste. --- ### Q8. Ordonnez les 4 étages de la pile d'évaluation du moins cher / plus rapide au plus coûteux / plus lent. - A. Juge LLM → assertions → golden set → évaluation humaine. - B. Golden set → juge LLM → assertions → évaluation humaine. - C. Assertions (code) → golden set (50–500 exemples ⚠) → juge LLM → évaluation humaine. - D. Évaluation humaine → juge LLM → golden set → assertions. **Réponse : C.** Les assertions sont du code déterministe, gratuit, exécuté à chaque changement ; le golden set mesure un taux de réussite sur des cas validés ; le juge LLM note à l'échelle (après calibration) ; l'humain est la vérité terrain, coûteuse et lente. --- ### Q9. Quelle précaution est indispensable avant de faire confiance à un juge LLM (LLM-as-judge) ? - A. Utiliser le même modèle comme générateur et comme juge, pour la cohérence. - B. Le calibrer contre des jugements humains sur un échantillon, mesurer l'accord, et recalibrer périodiquement. - C. Lui donner une température élevée pour qu'il soit plus nuancé. - D. Aucune : un LLM est par nature plus objectif qu'un humain. **Réponse : B.** Un juge non calibré est une opinion automatisée, pas une métrique. On mesure l'accord juge/humains avant de déployer, puis on ré-échantillonne régulièrement. --- ### Q10. Après une mise à jour de prompt, le taux d'escalade vers les humains de votre assistant chute de 18 % à 4 % ⚠. Quelle est la réaction professionnelle ? - A. Célébrer : moins d'escalades = système plus autonome, c'est mécaniquement une amélioration. - B. Revenir immédiatement à l'ancien prompt : toute variation brutale est un bug. - C. Suspendre le jugement et auditer un échantillon des cas qui ne sont plus escaladés : le modèle résout-il vraiment mieux, ou répond-il avec assurance sur des cas qu'il rate ? - D. Supprimer la métrique d'escalade, devenue inutile à 4 %. **Réponse : C.** Une métrique isolée qui « s'améliore » brutalement est un signal d'alerte. Le risque classique : le modèle devient trop confiant et envoie ses erreurs aux clients au lieu de les envoyer aux humains. Seul un audit humain sur échantillon tranche. --- ## Grille de correction rapide | Q1 | Q2 | Q3 | Q4 | Q5 | Q6 | Q7 | Q8 | Q9 | Q10 | |----|----|----|----|----|----|----|----|----|-----| | B | C | B | C | B | B | B | C | B | C |