# Exercices — Niveau Avancé, Session 8 # « Contexte, fiabilité & provenance » **Programme :** Applied AI — Yann Isola **Public :** Architectes solutions — préparation *Claude Certified Architect* **Durée totale estimée :** 3 h 30 à 4 h 30 (individuel ou binôme) **Prérequis :** clé API Anthropic, Python 3.10+, SDK (SDK = Software Development Kit) `anthropic`, la session 8 suivie, la page web interactive de la session pour vérifier vos calculs. > ⚠ Tous les chiffres de tarification, tailles de fenêtres, quotas et SLA (SLA = Service Level Agreement, engagement de niveau de service) utilisés ci-dessous sont **volatils**. Notez systématiquement la date et la source de la grille tarifaire que vous utilisez — c'est même une exigence explicite de l'exercice 1. --- ## Exercice 1 — Calculateur de budget de contexte (60-75 min) ### Contexte Votre équipe déploie « ComplianceScan », l'agent d'investigation de conformité vu en session. Avant toute ligne de code d'agent, l'architecte que vous êtes doit répondre à trois questions : **combien de tours l'agent peut-il tenir ? combien coûte une investigation ? quelle stratégie de contexte s'impose ?** Vous allez construire l'outil qui répond — un calculateur de budget de contexte réutilisable. ### Données d'entrée (profil de charge) | Poste | Valeur | |-------|--------| | Fenêtre de contexte du modèle | 200 000 tokens ⚠ | | Prompt système + politique de conformité | 3 200 tokens | | Définitions d'outils (12 outils) | 4 100 tokens | | Tour utilisateur/agent moyen (question + raisonnement + appel d'outil) | 800 tokens | | Résultat d'outil brut moyen | 2 500 tokens | | Résultat d'outil filtré par hook PostToolUse | 400 tokens | | Réserve de sortie (`max_tokens`) | 8 000 tokens | | Investigation type | 150 tours, 1 appel d'outil par tour | ### Travail demandé 1. **Modèle de calcul.** Écrivez un module Python `context_budget.py` avec une fonction `simulate(profile, strategy) -> Report` qui simule tour par tour la taille du contexte et retourne : le tour de saturation (ou `None`), le total de tokens d'entrée facturés cumulés sur l'investigation (rappel : à chaque tour, **tout le contexte est renvoyé et refacturé**), et la répartition finale par poste (système / outils / historique / résultats d'outils). 2. **Scénario A — brut, sans stratégie.** Résultats d'outils bruts, aucun filtrage, aucune compression. À quel tour l'agent sature-t-il ? L'investigation de 150 tours est-elle possible ? 3. **Scénario B — hook PostToolUse.** Résultats filtrés (400 tokens au lieu de 2 500). Nouveau tour de saturation ? Facteur de gain ? 4. **Scénario C — hybride (hook + résumé + fenêtre glissante).** En plus du filtrage : tous les 30 tours, les tours au-delà des 10 derniers sont compressés en un résumé de 1 500 tokens (le résumé précédent est absorbé dans le nouveau). Modélisez aussi le **coût de l'appel de compression** lui-même. L'investigation de 150 tours passe-t-elle ? Avec quelle marge ? 5. **Chiffrage économique.** Pour chaque scénario faisable, calculez le coût d'une investigation complète, puis de 200 investigations/jour, en utilisant la grille tarifaire officielle **du jour** (datez et sourcez ⚠). Bonus : ajoutez la variante « prompt système + définitions d'outils en cache » et quantifiez l'économie. 6. **Note d'architecture (1 page max).** Votre recommandation : quelle stratégie, quels seuils (palier de compression, taille de fenêtre verbatim, plafonds du hook), quels risques résiduels (que perd-on dans les résumés ? comment le scratchpad compense-t-il ?). ### Critères de réussite - [ ] Le simulateur est paramétrique (aucune constante en dur dans la logique). - [ ] Le scénario A démontre chiffres à l'appui l'impossibilité des 150 tours. - [ ] Le coût des appels de compression du scénario C est compté (l'oublier est l'erreur classique). - [ ] Les tarifs utilisés sont datés et sourcés. - [ ] La note d'architecture arbitre explicitement coût / capacité / risque de perte d'information. ### Pour aller plus loin Comparez vos estimations heuristiques (~4 caractères/token en anglais, ratio différent en français) avec l'endpoint officiel de comptage de tokens sur 5 messages réels. Quel écart ? Quelle marge de sécurité en déduisez-vous pour votre simulateur ? --- ## Exercice 2 — Conception d'une chaîne de provenance (75-90 min) ### Contexte L'équipe conformité accepte de déployer ComplianceScan **à une condition** posée par l'audit interne : *« Pour tout rapport généré, nous devons pouvoir remonter de chaque affirmation jusqu'à sa source primaire, reconstituer ce que le modèle a vu, et savoir quelle version du système a produit quoi. »* Vous concevez et prototypez la chaîne de provenance complète. ### Travail demandé 1. **Schéma de sortie avec attribution.** Définissez un schéma JSON (JSON = JavaScript Object Notation) de rapport où chaque `finding` porte : l'affirmation, un pointeur de source résoluble (`tool`, `call_id`, `record_id(s)`), un niveau de confiance (`établi` / `à vérifier` / `inféré`), et où l'enveloppe porte : `prompt_version` (hash + identifiant sémantique), identifiant de modèle complet, température, horodatage, identifiant de corrélation d'investigation. 2. **Prompt de génération.** Écrivez le prompt (système + structure XML d'injection séparant ``, ``, ``) qui contraint le modèle à produire ce schéma, avec la règle explicite : *aucune affirmation sans pointeur de source ; en l'absence de source, l'affirmation passe en `inféré` avec justification.* 3. **Journal d'audit.** Implémentez un `AuditLog` (fichiers JSON dans une arborescence `audit///`) qui journalise : prompt système (avec hash), chaque message, chaque appel d'outil — **arguments, résultat brut, résultat filtré entré au contexte** (le triplet args/raw/ctx), et le manifeste final (modèle, version, paramètres, hashes). 4. **Vérificateur de citations.** Écrivez `verify_provenance(report, audit_log) -> VerificationResult` qui, pour chaque `finding` : (a) vérifie que le `call_id` existe dans le journal ; (b) vérifie que les `record_id` cités apparaissent bien dans le **résultat brut** de cet appel ; (c) signale toute citation orpheline. Testez-le en corrompant volontairement un rapport (inventez un `record_id` plausible — simulez l'hallucination de citation) et vérifiez que le contrôle le détecte. 5. **Scénario d'audit à blanc.** En binôme : l'un joue l'auditeur et choisit une affirmation au hasard dans un rapport généré ; l'autre doit, en moins de 5 minutes et uniquement avec le journal, produire : la source primaire, ce que le modèle a réellement vu (ctx vs raw), et la version du prompt. Documentez ce qui a manqué ou ralenti. 6. **Question de fond (10 lignes).** Votre direction demande : « Peut-on garantir la regénération à l'identique d'un rapport pour prouver son origine ? » Rédigez la réponse honnête de l'architecte : ce que température 0 + version épinglée + seed ⚠ garantissent, ce qu'ils ne garantissent pas (« déterministe-ish »), et pourquoi le journal d'audit — pas la regénération — est la véritable garantie de conformité. ### Critères de réussite - [ ] Le schéma distingue provenance des **données** (sources) et provenance du **générateur** (prompt, modèle, paramètres). - [ ] Le vérificateur détecte la citation hallucinée du test de corruption. - [ ] Le journal permet de répondre « qu'a vu le modèle exactement ? » (ctx ≠ raw). - [ ] L'audit à blanc aboutit en < 5 min. - [ ] La réponse sur la reproductibilité ne sur-promet pas. ### Pour aller plus loin Ajoutez un chaînage d'intégrité : chaque entrée du journal inclut le hash de l'entrée précédente (chaîne de hachage). Que gagne-t-on face à un auditeur ? Que ne prouve-t-on toujours pas ? --- ## Exercice 3 — Pipeline de traitement batch (60-90 min) ### Contexte Nouvelle politique de conformité v3.3 : les **80 000 dossiers clients** doivent être re-notés cette semaine. Appels synchrones = trop lent, trop cher, rate limits. Vous construisez le pipeline complet sur la **Message Batches API** : soumission, suivi, dépouillement, reprise sur erreur — avec optimisation batch + cache et chiffrage à l'appui. *(Pour l'exercice, travaillez sur 200 dossiers synthétiques ; le code doit être dimensionné pour 80 000.)* ### Travail demandé 1. **Génération du jeu.** Script `make_dossiers.py` : 200 dossiers synthétiques JSON (id, pays, activité déclarée, liste de transactions, drapeaux divers) — dont ~10 volontairement malformés (champ manquant, encodage douteux) pour tester la robustesse aval. 2. **Soumission.** Script `submit_batch.py` : - construit les requêtes avec un **`custom_id` robuste** (convention à documenter : p. ex. `v33-{dossier_id}-{hash_court_du_contenu}` — justifiez chaque composant) ; - place la politique de conformité (bloc système long et identique) en **cache** (`cache_control`) ; - découpe en lots si nécessaire (limite de 100 000 requêtes/batch ⚠ — votre code doit gérer le découpage même si le jeu de test tient en un lot) ; - persiste localement le manifeste de soumission : `batch_id`, liste des `custom_id`, horodatage, version de prompt (provenance !). 3. **Suivi.** Script `poll_batch.py` : interroge le statut à intervalle raisonnable (backoff progressif, pas de boucle serrée), journalise les transitions `in_progress` → `ended`. 4. **Dépouillement et reprise.** Script `collect_results.py` : - dépouille les résultats en rattachant chaque résultat à son dossier via `custom_id` (rappel : **l'ordre n'est pas garanti**) ; - route par type : `succeeded` → base de résultats ; `errored` → file de retry avec le détail d'erreur ; `expired` / `canceled` → file de re-soumission ; - est **idempotent** : relançable après plantage à mi-course sans double-traitement (justifiez le mécanisme — marqueurs de progression, upsert par `custom_id`...) ; - produit un rapport de complétude : soumis / réussis / échoués / manquants, avec la liste nominative des manquants. 5. **Chiffrage comparatif.** Avec la grille tarifaire du jour (datée, sourcée ⚠), calculez pour 80 000 dossiers (système partagé 3 200 tokens, entrée variable ~900 tokens, sortie ~350 tokens) le coût dans 4 configurations : synchrone sans cache / synchrone + cache / batch sans cache / **batch + cache**. Présentez le tableau et le facteur d'économie total. Vérifiez vos ordres de grandeur avec le calculateur de la page web de la session. 6. **Note d'exploitation (½ page).** SLA 24 h ⚠ : quelles conséquences sur la planification (fenêtre de nuit, marge, criticité) ? Que se passe-t-il si 3 % des requêtes expirent ? Quel est votre critère de « campagne terminée » ? ### Critères de réussite - [ ] La convention de `custom_id` est documentée et permet corrélation + idempotence + audit. - [ ] Le dépouillement traite les 4 statuts terminaux et survit aux 10 dossiers malformés. - [ ] `collect_results.py` relancé deux fois de suite ne double-traite rien. - [ ] Le chiffrage montre le cumul batch + cache, tarifs datés et sourcés. - [ ] Le rapport de complétude désigne nominativement tout dossier manquant. ### Pour aller plus loin Branchez la sortie de l'exercice 2 : chaque résultat de batch alimente le journal d'audit et le schéma de provenance. Un `custom_id` devient alors le fil qui relie dossier → requête → réponse → rapport → audit. C'est exactement l'architecture attendue d'un *Claude Certified Architect* : les trois briques de la session n'en font qu'une. --- ## Barème indicatif (si évaluation notée) | Exercice | Points | Dont | |----------|--------|------| | 1 — Budget de contexte | 30 | Simulateur 12, scénarios 10, note d'architecture 8 | | 2 — Chaîne de provenance | 40 | Schéma 8, journal 10, vérificateur 12, audit à blanc 5, reproductibilité 5 | | 3 — Pipeline batch | 30 | Soumission 8, dépouillement/reprise 12, chiffrage 6, exploitation 4 | Seuil de validation : 60/100. La détection de la citation hallucinée (ex. 2.4) et l'idempotence du dépouillement (ex. 3.4) sont **éliminatoires** si absentes : ce sont les deux réflexes non négociables du métier.