❓ Quiz — advanced/session-08

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

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

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

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

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

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

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

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

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

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 ⚠

Quiz — Niveau Avancé, Session 8

« Contexte, fiabilité & provenance »