# Quiz — Niveau Avancé, Session 7 # « Prompt engineering avancé » **Programme :** Applied AI — Yann Isola **Format :** 10 QCM (QCM = Questionnaire à Choix Multiples), niveau certification *Claude Certified Architect* **Durée :** 20 minutes — une seule réponse correcte par question sauf mention contraire **Seuil :** 7/10 > ⚠ Les comportements d'API décrits (prefilling, extended thinking, stop_sequences) reflètent la documentation au moment de la rédaction et sont volatils : vérifier la documentation officielle Anthropic. --- ### Q1 — Quand le Chain of Thought nuit Une équipe ajoute « Réfléchis étape par étape » à un prompt qui **copie verbatim** un numéro d'IBAN (IBAN = International Bank Account Number) depuis un document. L'exactitude baisse. Quelle est l'explication la plus probable ? - A. Le CoT augmente la température effective du modèle - B. Le modèle « sur-raisonne » et paraphrase au lieu de copier ; le CoT est contre-productif sur l'extraction verbatim - C. Le CoT n'a aucun effet possible sur l'exactitude, le problème vient d'ailleurs - D. Le CoT dépasse le budget `max_tokens`, tronquant systématiquement l'IBAN **Réponse : B.** Le CoT aide les tâches de raisonnement multi-étapes ; sur une copie verbatim, l'étape de raisonnement introduit des reformulations et des erreurs. A est faux : le CoT ne modifie pas la température. D est possible mais pas « le plus probable » sans indication de troncature. Réflexe d'architecte : le CoT se mesure, il ne se présume pas. --- ### Q2 — Conception d'un jeu few-shot Vous disposez d'un budget de 6 exemples few-shot pour une classification. Quelle composition maximise la fiabilité ? - A. 6 exemples du cas le plus fréquent en production, pour coller à la distribution réelle - B. 6 exemples couvrant chacun une classe différente, tous parfaitement nominaux - C. 1-2 cas nominaux, 2-3 cas limites ambigus, 1 cas hors-périmètre/refus, en variant les attributs de surface - D. Le maximum d'exemples possible : la fiabilité croît linéairement avec leur nombre **Réponse : C.** Le modèle gère déjà bien les cas nominaux ; c'est sur les cas limites qu'il a besoin d'être guidé, et le cas de refus définit la frontière du périmètre. Varier les attributs de surface évite les biais parasites (p. ex. « virement → P1 »). A sur-apprend le cas facile ; B ignore les ambiguïtés ; D est faux — la redondance n'apporte rien et gonfle le coût de prompt. --- ### Q3 — Prefilling : comportement API exact Vous envoyez `{"role": "assistant", "content": ""}` en dernier message avec `stop_sequences: [""]`. Le modèle génère `42…`. Que contient `response.content` et que vaut `stop_reason` ? - A. `42` — `stop_reason: "end_turn"` - B. `42` — `stop_reason: "stop_sequence"` - C. `42` — `stop_reason: "stop_sequence"` - D. `42` — `stop_reason: "stop_sequence"` **Réponse : B.** Le texte du prefill **n'est pas répété** dans la sortie (la réponse commence après lui), et la stop_sequence déclenchée **n'est pas incluse** dans le texte retourné ; `stop_reason` vaut `"stop_sequence"` et le champ `stop_sequence` de la réponse indique laquelle a déclenché. C'est le patron d'extraction canonique : la sortie ne contient que la valeur utile. --- ### Q4 — Piège prefill Lequel de ces prefills provoque une **erreur API** ? - A. `{"role": "assistant", "content": "{"}` - B. `{"role": "assistant", "content": "Voici l'analyse : "}` - C. `{"role": "assistant", "content": "[ANALYSTE]"}` - D. `{"role": "assistant", "content": ""}` **Réponse : B.** Un prefill ne peut pas se terminer par un **espace final** (trailing whitespace) : l'API rejette la requête. Les trois autres sont valides. Piège de certification récurrent — et un bug sournois en production, car l'espace est invisible à la relecture. --- ### Q5 — Contexte long : placement des instructions Prompt de 80 000 tokens : trois contrats en pièces jointes et une consigne d'analyse critique. Quel placement maximise le respect de la consigne ? - A. Consigne au début uniquement — le modèle lit dans l'ordre - B. Consigne au milieu, entre les documents, au plus près des données - C. Documents balisés en XML au début ; consigne critique énoncée au début **et** répétée à la fin - D. Peu importe : l'attention est uniforme sur toute la fenêtre de contexte **Réponse : C.** L'attention favorise le début (primauté) et la fin (récence) du prompt ; le milieu est la zone faible (« lost in the middle »). Placer les gros documents en tête (bonus : maximise les hits de prompt caching sur les blocs stables) et doubler la consigne critique début + fin est la pratique recommandée. B place la consigne dans la zone la plus faible ; D est factuellement faux. --- ### Q6 — Exemples vs instructions Un prompt système exige « réponds uniquement en JSON », mais deux des cinq exemples few-shot contiennent une phrase d'explication avant le JSON. En production, le modèle ajoute souvent une phrase avant son JSON. Quel diagnostic ? - A. Bug du modèle : les instructions système priment toujours sur les exemples - B. Température trop élevée : la baisser à 0 suffira - C. Conflit exemples/instructions : le modèle imite les exemples, qui l'emportent souvent sur l'instruction contraire — corriger les exemples - D. Il faut ajouter « TRÈS IMPORTANT » devant l'instruction JSON **Réponse : C.** Les exemples montrent, les instructions décrivent — et en cas de conflit, la démonstration l'emporte fréquemment sur la description. Premier réflexe d'audit d'un prompt défaillant : vérifier la cohérence exemples/instructions. A est faux ; B réduira la variance mais pas le biais appris des exemples ; D est l'anti-patron de « l'incantation ». --- ### Q7 — Patron de production canonique Dans le patron `classification → routage → génération spécialisée → validation`, quelle affirmation est correcte ? - A. Le routage doit être confié à un appel LLM dédié pour plus de flexibilité - B. Le routage est du code déterministe (switch sur la sortie structurée de la classification) ; on ne paie pas un modèle pour un `if` - C. La validation doit toujours être un LLM juge, jamais des règles programmatiques - D. La classification et la génération doivent impérativement utiliser le même modèle pour garantir la cohérence **Réponse : B.** La classification produit une sortie structurée ; le routage qui la consomme est un simple branchement logiciel — déterministe, gratuit, testable. C est faux : la validation combine règles programmatiques (schéma JSON, regex) pour le vérifiable mécaniquement et LLM juge pour le qualitatif (ton, engagement contractuel). D est faux : adapter le modèle par maillon (rapide pour classer, capable pour générer) est précisément un avantage du chaining. ⚠ Noms de modèles volatils. --- ### Q8 — Negative prompting Pourquoi « Si une information manque, utilise la valeur "inconnu" » est-il plus fiable que « N'invente jamais d'informations » seul ? - A. Les modèles ne comprennent pas la négation grammaticale française - B. L'instruction négative décrit un vide sans définir le comportement de remplacement ; l'instruction positive spécifie exactement quoi faire dans le cas problématique - C. Les instructions négatives sont ignorées par le prompt système, elles ne fonctionnent qu'en message utilisateur - D. Aucune différence mesurable : c'est une préférence stylistique **Réponse : B.** Le negative prompting n'est pas inutile, mais il est réputé **moins fiable** que l'équivalent positif : interdire sans proposer d'alternative laisse le modèle choisir lui-même le comportement de repli. Règle pratique : chaque « ne fais pas X » s'accompagne d'un « fais Y à la place ». A et C sont faux ; D contredit les observations d'évaluation. --- ### Q9 — Température et Chain of Thought Pour un pipeline d'extraction avec CoT structuré, quel réglage de température et pourquoi ? Et dans quel cas ferait-on volontairement l'inverse ? - A. Température élevée toujours : le CoT a besoin de créativité pour explorer - B. Température basse (souvent 0) pour des chemins de raisonnement reproductibles ; l'inverse — échantillonner plusieurs CoT à température plus élevée puis vote majoritaire (self-consistency) — se réserve aux décisions critiques car coûteux - C. La température n'a aucun effet quand un CoT est présent dans le prompt - D. Température 0 rend le CoT inutile puisque le modèle devient déterministe **Réponse : B.** La température diversifie aussi les chemins de raisonnement : en extraction/classification on la veut basse pour la reproductibilité. La self-consistency exploite délibérément cette diversité (N échantillons, vote), au prix de N fois le coût. C et D confondent déterminisme d'échantillonnage et utilité de l'espace de raisonnement. Piège de certification classique. --- ### Q10 — Le prompt système « contrat » Un prompt système de production pour un agent de tri de tickets doit, au minimum, contenir quatre clauses. Lesquelles ? - A. Persona détaillée, historique de l'entreprise, exemples de tickets, signature - B. Règles explicites (périmètre, sources), format de sortie exact, politique de refus avec formulation imposée, déclencheurs d'escalade vers l'humain - C. Température, max_tokens, stop_sequences, nom du modèle - D. Instructions positives uniquement — toute mention de refus dégrade les performances **Réponse : B.** Le « system prompt as contract » spécifie le comportement comme on spécifie une API : ce que le composant fait (règles), ce qu'il produit (format), ce qu'il refuse (avec la formulation exacte — un refus improvisé est un risque juridique et de marque), et quand il passe la main (escalade). C confond prompt et paramètres d'API. D est faux : la politique de refus explicite est précisément une clause obligatoire du contrat. --- ## Grille de correction rapide | Q1 | Q2 | Q3 | Q4 | Q5 | Q6 | Q7 | Q8 | Q9 | Q10 | |----|----|----|----|----|----|----|----|----|-----| | B | C | B | B | C | C | B | B | B | B | **Analyse des erreurs fréquentes :** - Q3/Q4 ratées ensemble → refaire la démo prefill + stop_sequences (bloc 3 du guide) ; - Q1/Q9 ratées → revoir « quand le CoT aide / quand il nuit » et l'interaction température (blocs 1 et 8) ; - Q6/Q8 ratées → revoir la hiérarchie exemples/instructions et le positif > négatif (blocs 2 et 6).