# Quiz — Niveau Avancé, Session 8 # « Contexte, fiabilité & provenance » **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 chiffres cités (fenêtres de contexte, réduction batch de 50 %, limite de 100 000 requêtes, SLA de 24 h) reflètent la documentation au moment de la rédaction et sont **volatils** : vérifier la documentation officielle Anthropic. SLA = Service Level Agreement (engagement de niveau de service). --- ### Q1 — Nature de l'API et mémoire Un développeur s'étonne : « J'ai envoyé le dossier client au modèle il y a trois requêtes, pourquoi ne s'en souvient-il plus ? » Quelle est la bonne explication d'architecte ? - A. Le modèle a une mémoire de 30 minutes ; au-delà, il faut renvoyer les données - B. L'API est sans état (stateless) : le modèle ne voit que ce qui est renvoyé dans la requête courante ; la gestion de l'historique incombe entièrement à l'application - C. Il faut activer l'option `memory: true` dans les paramètres de la requête - D. Le prompt caching aurait conservé le dossier ; c'est son absence qui cause l'oubli **Réponse : B.** L'API Messages est stateless : aucun historique côté serveur. A et C inventent des mécanismes inexistants. D confond cache et mémoire : le cache réduit le **coût** de retraitement d'un préfixe identique renvoyé par le client — il ne dispense jamais de le renvoyer. --- ### Q2 — Arithmétique de saturation Fenêtre de 200 000 tokens ⚠. Coûts fixes (système + définitions d'outils) : 7 000 tokens. Réserve de sortie : 8 000 tokens. Chaque tour complet (échange + résultat d'outil brut) ajoute ~3 300 tokens à l'historique. Ordre de grandeur du tour de saturation ? - A. ~25 tours - B. ~56 tours - C. ~150 tours - D. Aucune saturation : les tours anciens sont éliminés automatiquement par l'API **Réponse : B.** (200 000 − 7 000 − 8 000) / 3 300 ≈ 56. D est le piège central : l'API n'élimine rien automatiquement — si le contexte dépasse la fenêtre, la requête échoue ; toute stratégie de troncature/compression est applicative. Réflexe d'architecte : ce calcul se fait **avant** d'écrire l'agent. --- ### Q3 — Choix de stratégie de contexte Un agent d'investigation de longue durée doit à la fois se souvenir de décisions prises il y a 100 tours et raisonner finement sur les 5 derniers échanges (résultats d'outils exacts inclus). Quelle stratégie ? - A. Fenêtre glissante stricte sur les 20 derniers tours : simple et sans coût de compression - B. Résumé intégral de tout l'historique à chaque tour : compacité maximale - C. Hybride : résumé cumulatif des tours anciens + N derniers tours conservés verbatim - D. Augmenter `max_tokens` pour agrandir la fenêtre de contexte **Réponse : C.** L'hybride préserve la vue d'ensemble (résumé) et le détail récent (verbatim). A perd les décisions anciennes (amnésie). B détruit la précision des tours récents et coûte un appel de compression à chaque tour. D est un piège de vocabulaire : `max_tokens` plafonne la **sortie**, il n'agrandit pas la fenêtre de contexte. --- ### Q4 — Fiabilité du résumé de contexte Dans une architecture à compression par résumé, quelle affirmation est correcte ? - A. Le résumé est sans perte si l'on utilise le même modèle que l'agent - B. Le résumé est une sortie de modèle : compression avec perte, hallucination possible ; en contexte régulé, l'historique intégral doit être conservé hors contexte (journal d'audit) - C. À température 0, le résumé est garanti fidèle à l'historique - D. Le résumé doit inclure l'intégralité des résultats d'outils bruts pour rester exploitable **Réponse : B.** Un résumé généré est intrinsèquement lossy et faillible — il se pilote (consignes de conservation : identifiants, décisions, pistes ouvertes) mais ne se certifie pas. A et C confondent paramètres d'inférence et garanties de fidélité. D est le contraire du but : réinjecter le brut annule la compression. --- ### Q5 — Hook PostToolUse et pollution de contexte Un outil `search_transactions` renvoie 40 champs par transaction et jusqu'à 10 000 lignes. L'agent en exploite 4 champs et quelques lignes signalées. Quelle est la meilleure pratique ? - A. Tout insérer au contexte : plus le modèle a d'informations, mieux il raisonne - B. Un hook PostToolUse qui journalise le résultat brut intégral (audit), puis n'insère au contexte que les champs pertinents avec un plafond de lignes - C. Supprimer le résultat brut et ne journaliser que la version filtrée, pour économiser le stockage - D. Demander au modèle, dans le prompt, d'ignorer les champs non pertinents **Réponse : B.** Double geste : brut → journal (provenance), filtré + plafonné → contexte (hygiène). A est la définition de la pollution de contexte — l'information non pertinente **dégrade** la performance (less is more) et se refacture à chaque tour. C détruit la chaîne de provenance : l'auditeur doit pouvoir comparer raw et ctx. D laisse le bruit consommer des tokens et de l'attention. --- ### Q6 — Patron scratchpad Quel est l'avantage décisif du patron « investigation-scratchpad.md » (mémoire externe persistante) par rapport au seul résumé en contexte ? - A. Il rend le résumé en contexte inutile dans tous les cas - B. Il garantit l'exactitude des faits notés, car le fichier n'est pas généré par le modèle - C. Il fournit une mémoire sélective qui survit aux compressions, redémarrages et resets, inspectable par un humain et transmissible à un autre agent - D. Il est automatiquement synchronisé avec la fenêtre de contexte par l'API **Réponse : C.** Persistance hors contexte + inspectabilité + transmissibilité : c'est ce que le résumé (éphémère, régénéré, dans le contexte) ne donne pas. A est faux : les deux se complètent (rôles différents). B est faux : le scratchpad est écrit **par** le modèle — d'où l'exigence d'y attacher les sources des « faits établis ». D invente un mécanisme : l'API ne connaît pas ce fichier ; relecture et mise à jour sont applicatives (outils). --- ### Q7 — Vérification de provenance Un rapport généré cite `{"tool": "check_sanctions", "call_id": "call_0042", "record_id": "SANC-2211-08"}`. Que doit faire l'application avant de considérer l'affirmation comme sourcée ? - A. Rien : une citation structurée produite à température 0 est fiable - B. Vérifier que le format du `record_id` respecte l'expression régulière attendue - C. Résoudre le pointeur contre le journal d'audit : le `call_id` existe, et le `record_id` figure bien dans le résultat brut de cet appel - D. Redemander au modèle de confirmer sa citation dans un second appel **Réponse : C.** Un modèle peut halluciner une citation plausible (bon format, mauvais contenu) : la citation est un **pointeur à résoudre**, pas une preuve. A et B se laissent berner par la plausibilité de surface. D fait vérifier le faussaire par lui-même — un second appel peut confirmer avec assurance une citation inventée. Une chaîne de provenance sans vérification machinale des pointeurs est du théâtre de conformité. --- ### Q8 — Reproductibilité Pour un rapport réglementaire, la direction demande la garantie de pouvoir « regénérer exactement le même rapport » à partir des mêmes entrées. Réponse correcte de l'architecte ? - A. Oui : température 0 + version de modèle épinglée + seed ⚠ garantissent des sorties identiques bit à bit - B. Non, et c'est pourquoi l'IA générative est inutilisable en secteur régulé - C. La regénération est quasi déterministe mais non garantie bit à bit (infrastructure d'inférence) ; la garantie de conformité repose sur le journal d'audit exhaustif de la sortie réellement produite et de tout son contexte - D. Oui, à condition d'utiliser la Batches API, qui est déterministe par conception **Réponse : C.** « Déterministe-ish » : fixer température, version et seed réduit la variance mais l'infrastructure d'inférence (parallélisme, batching serveur) introduit des variations résiduelles. La conformité se fonde sur ce qui a été **journalisé**, pas sur ce qu'on pourrait regénérer. A sur-promet (erreur contractuelle classique), B sur-réagit, D invente une propriété de la Batches API. --- ### Q9 — Batches API : dépouillement Votre batch de 80 000 requêtes affiche `processing_status: "ended"`. Quelle affirmation est correcte ? - A. Toutes les requêtes ont réussi ; les résultats sont dans l'ordre de soumission - B. Chaque requête a un statut individuel (`succeeded`, `errored`, `canceled`, `expired`) et l'ordre des résultats n'est pas garanti : le dépouillement se fait requête par requête, corrélé par `custom_id` - C. Les requêtes en erreur ont été automatiquement re-soumises par l'API - D. Les résultats sont poussés par webhook ; aucun dépouillement n'est nécessaire **Réponse : B.** `ended` signifie que le traitement du batch est terminé, pas que tout a réussi. Le `custom_id`, fourni par vous à la soumission, est la seule clé de corrélation fiable (ordre non garanti) — et il sert aussi l'idempotence de la reprise et la chaîne d'audit. C et D inventent des automatismes : retry et dépouillement sont à votre charge. --- ### Q10 — Optimisation économique batch + cache Retraitement nocturne non interactif de 80 000 dossiers partageant un prompt système de 3 200 tokens. Quelle configuration minimise le coût, et pourquoi ? - A. Appels synchrones avec cache : le cache est incompatible avec les batches - B. Batches API seule : la réduction de 50 % ⚠ rend le cache sans intérêt - C. Batches API avec le bloc système en `cache_control` : la réduction batch de 50 % ⚠ (entrée et sortie) se combine avec le tarif réduit des lectures de cache sur le préfixe partagé - D. Appels synchrones parallélisés : le batch est plus cher car il inclut le SLA de 24 h ⚠ **Réponse : C.** Les deux leviers se cumulent : −50 % batch sur l'ensemble, plus la remise cache sur le préfixe commun — c'est le patron « batch + cache » d'optimisation maximale pour la masse non interactive. A est faux (le cache est utilisable dans les batches ⚠ — vérifier la doc du moment pour les modalités). B laisse de l'argent sur la table : sur 80 000 requêtes, le préfixe partagé pèse lourd. D inverse la réalité : le batch est moins cher précisément parce qu'il renonce au temps réel. --- ## Grille de correction rapide | Q | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | |---|---|---|---|---|---|---|---|---|---|----| | R | B | B | C | B | B | C | C | C | B | C | **Thèmes couverts :** statelessness (Q1), budget de contexte (Q2), stratégies de compression (Q3, Q4), hygiène et hooks (Q5), mémoire externe (Q6), provenance et vérification (Q7), reproductibilité (Q8), Batches API (Q9), optimisation batch + cache (Q10).