# Quiz — Niveau Avancé, Session 2 # « Tool use avancé » **Programme :** Applied AI — Yann Isola **Format :** 10 QCM (Questions à Choix Multiples), niveau certification Claude Certified Architect **Barème conseillé :** 1 point par question, seuil de maîtrise : 8/10 **Durée :** 20 min Les corrigés commentés sont en fin de document. --- ### Q1 — Cycle de vie Votre application reçoit une réponse de l'API Messages avec `stop_reason: "tool_use"`. Que signifie ce champ et quelle est la prochaine étape correcte ? - A. Le modèle a exécuté un outil ; il faut lire le résultat dans `response.content`. - B. Le modèle demande l'exécution d'un ou plusieurs outils ; votre code doit exécuter chaque bloc `tool_use` et renvoyer les `tool_result` dans un message `role: "user"`. - C. Le modèle a rencontré une erreur d'outil ; il faut réessayer la requête avec les mêmes messages. - D. La conversation est terminée ; l'assistant a utilisé un outil interne pour produire sa réponse finale. --- ### Q2 — Format du tool_result Quel message est **valide** pour renvoyer un résultat d'outil à l'API Anthropic ? - A. `{"role": "tool", "content": [{"type": "tool_result", "tool_use_id": "toolu_01A", "content": "42"}]}` - B. `{"role": "user", "content": [{"type": "tool_result", "tool_use_id": "toolu_01A", "content": "42"}]}` - C. `{"role": "assistant", "content": [{"type": "tool_result", "tool_use_id": "toolu_01A", "content": "42"}]}` - D. `{"role": "user", "content": [{"type": "tool_output", "id": "toolu_01A", "content": "42"}]}` --- ### Q3 — Historique de conversation Après avoir reçu un bloc `tool_use`, un développeur construit la requête suivante en n'incluant que : le message utilisateur initial + un message user avec le `tool_result`. Que se passe-t-il ? - A. L'API accepte : le `tool_use_id` suffit à faire le lien. - B. L'API accepte mais le modèle ignore le résultat. - C. L'API renvoie une erreur 400 : le message assistant contenant le bloc `tool_use` correspondant doit figurer dans l'historique. - D. L'API renvoie une erreur 429 (rate limit). --- ### Q4 — tool_choice Vous construisez un routeur d'intentions : chaque message utilisateur doit obligatoirement être classé par UN des 5 outils de routage disponibles, au choix du modèle. Quel `tool_choice` est le plus adapté ? - A. `{"type": "auto"}` - B. `{"type": "any"}` - C. `{"type": "tool", "name": "route_intent"}` - D. Omettre `tool_choice` et l'exiger dans le system prompt. --- ### Q5 — Sortie structurée Quel est l'avantage principal du pattern « faux outil » (outil jamais exécuté + `tool_choice: {"type": "tool", ...}`) par rapport à la consigne « réponds uniquement en JSON » dans le prompt ? - A. Il réduit la latence, car le modèle génère moins de tokens. - B. Il garantit sémantiquement que les valeurs extraites sont exactes. - C. Il garantit une sortie conforme au schéma (JSON parsé, champs et types contraints), éliminant le texte parasite et les erreurs de format. - D. Il est moins coûteux, car les définitions d'outils ne consomment pas de tokens d'entrée. --- ### Q6 — Taxonomie des erreurs Un pipeline d'extraction retourne un JSON valide et conforme au schéma, mais classe systématiquement les tickets « remboursement » dans la catégorie `technique` au lieu de `facturation`. Quelle est la nature de l'erreur et le remède prioritaire ? - A. Syntaxique → réessayer l'appel (retry) avec la même requête. - B. Syntaxique → augmenter `max_tokens`. - C. Sémantique → affiner le prompt : enrichir la description de l'outil et des valeurs d'enum, ajouter des exemples. - D. Sémantique → réessayer l'appel : la température introduira de la variabilité corrective. --- ### Q7 — is_error Votre outil `get_invoice` lève une exception « facture introuvable ». Quelle est la meilleure pratique ? - A. Interrompre la boucle et afficher l'exception à l'utilisateur final. - B. Renvoyer un `tool_result` avec `is_error: true` et un message actionnable (ex. « Facture INV-123 introuvable, vérifier l'identifiant »), puis laisser le modèle décider de la suite. - C. Ne rien renvoyer pour ce `tool_use` et laisser le modèle réessayer spontanément. - D. Renvoyer la stack trace complète dans `content` pour que le modèle ait le maximum d'information. --- ### Q8 — Multi-outils Une réponse du modèle contient deux blocs `tool_use` (ids `toolu_A` et `toolu_B`). Quelle est la manière correcte de renvoyer les résultats ? - A. Deux messages `role: "user"` successifs, un par `tool_result`. - B. Un seul message `role: "user"` contenant les deux blocs `tool_result`, chacun avec son `tool_use_id`. - C. Un seul `tool_result` concaténant les deux sorties, avec l'id du premier bloc. - D. Exécuter seulement le premier outil : le modèle redemandera le second au tour suivant. --- ### Q9 — Sécurité Laquelle de ces affirmations décrit correctement le modèle de sécurité du tool use ? - A. Le modèle exécute les outils dans un bac à sable (sandbox) hébergé par Anthropic, avec les permissions déclarées dans `input_schema`. - B. Le modèle n'exécute rien : les outils tournent dans votre code avec vos authentifications ; la validation des entrées et le contrôle d'accès relèvent donc entièrement de votre application. - C. L'API valide les `input` contre le schéma et bloque toute valeur dangereuse (injection SQL, chemins de fichiers) avant de vous les transmettre. - D. Fournir des `enum` dans le schéma suffit à garantir que les valeurs reçues sont sûres pour une requête SQL. --- ### Q10 — max_tokens et tool_use Une réponse arrive avec `stop_reason: "max_tokens"` alors que le dernier bloc de `content` est un `tool_use` dont l'`input` semble incomplet. Quelle analyse est correcte ? - A. C'est impossible : un bloc `tool_use` est toujours émis intégralement ou pas du tout. - B. Erreur sémantique : le modèle a mal compris le schéma ; il faut réécrire la description de l'outil. - C. Erreur syntaxique due à la troncature : le JSON de l'appel a été coupé ; il faut relancer avec un `max_tokens` plus élevé et vérifier `stop_reason` avant tout parsing. - D. Comportement normal : l'API complètera l'`input` à la requête suivante grâce au `tool_use_id`. --- --- ## Corrigés commentés **Q1 → B.** `stop_reason: "tool_use"` = demande d'exécution, jamais une exécution déjà faite (A/D faux : le modèle n'exécute rien). C est faux : réessayer sans renvoyer de `tool_result` ne fait pas avancer le protocole. **Q2 → B.** Chez Anthropic, le `tool_result` est un bloc de contenu dans un message `role: "user"` (piège classique pour qui vient de l'API OpenAI, où il existe un rôle `tool`). D invente un type `tool_output` inexistant. **Q3 → C.** Chaque `tool_result` doit être précédé, dans l'historique, du message assistant contenant le `tool_use` de même id — sinon rejet 400. Le message assistant se renvoie tel quel (avec tous ses blocs). **Q4 → B.** `any` force l'appel d'un outil tout en laissant le choix duquel : exactement un routeur. A n'offre aucune garantie d'appel ; C force UN outil précis (il n'y en a pas un seul ici) ; D repose sur l'obéissance au prompt, sans garantie structurelle. **Q5 → C.** La garantie est **syntaxique** : JSON bien formé, types et enums respectés, pas de prose autour, et le SDK fournit `input` déjà parsé. B est le piège : aucune garantie **sémantique** (le modèle peut se tromper de valeur en respectant le schéma). D est faux : les définitions consomment des tokens d'entrée. **Q6 → C.** Format valide + contenu faux = erreur **sémantique**. Le retry (A, D) reproduit généralement la même erreur, car elle reflète la compréhension du modèle, pas un aléa de génération. Le remède : descriptions plus riches, exemples, éventuellement redécoupage de la tâche. **Q7 → B.** `is_error: true` + message actionnable = le modèle peut se rattraper (corriger l'id, demander une précision, expliquer l'échec). A casse inutilement l'expérience ; C produit un `tool_use` orphelin → erreur 400 au tour suivant ; D gaspille des tokens et peut fuiter des détails internes. **Q8 → B.** Un `tool_result` par `tool_use`, tous regroupés dans le message user suivant, corrélés par `tool_use_id`. A/C/D violent le protocole ou perdent de l'information (C mélange les corrélations, D laisse un `tool_use` sans réponse). **Q9 → B.** Principe cardinal : exécution côté client, avec vos identifiants. L'API ne valide pas la sûreté métier des valeurs (C faux) ; les `enum` contraignent le modèle mais un architecte traite tout `input` comme non fiable et paramètre ses requêtes SQL (D insuffisant) ; il n'existe pas de sandbox d'exécution côté Anthropic pour vos outils client (A faux). **Q10 → C.** La génération peut être coupée en plein JSON d'`input` quand le budget `max_tokens` est épuisé — troncature = erreur **syntaxique**. Réflexe d'architecte : toujours tester `stop_reason` avant de parser ; remède : augmenter `max_tokens` et relancer. D invente un mécanisme de complétion inexistant. --- ## Grille d'interprétation | Score | Lecture | |---|---| | 9-10 | Prêt pour les questions tool use de la certification | | 7-8 | Solide ; revoir les corrigés des questions manquées (souvent Q3, Q5, Q10) | | ≤ 6 | Refaire l'exercice 2 (débogage) et relire les blocs 1 et 5 du guide |