D1 · Solution Design & Architecture

A. Un système multi-agents avec un coordinateur et des sous-agents spécialisés pour chaque type d’e-mail. B. Un augmented-LLM ou un workflow simple : classer l’intention, appeler l’outil de statut de commande, renvoyer une réponse structurée — car les étapes sont connues et le budget SLA/coût favorise le patron le plus simple. C. Une boucle agentique avec un large catalogue d’outils pour qu’elle puisse tout gérer. D. Fine-tuner un modèle sur les e-mails historiques avant qu’aucun pipeline n’existe.

Réponse : B. Les étapes sont énumérables (classer → recherche → répondre), la latence et le coût sont contraignants, et le volume est modeste. Le patron le plus simple qui satisfait les critères l’emporte. Le multi-agent (A) et une large boucle agentique (C) sont sur-conçus, augmentant coût, latence et surface de défaillance. Le fine-tuning (D) est prématuré sans pipeline ni référentiel d’éval.

A. L’API directe Anthropic pour l’accès le plus précoce aux nouveaux modèles. B. Google Vertex AI en région UE, en héritant de l’IAM et de la résidence GCP. C. Amazon Bedrock, car il a le plus de certifications de conformité. D. Le moins cher par token, quel qu’il soit.

Réponse : B. Deux contraintes contraignantes — la résidence UE et une empreinte GCP existante (IAM, engagement). Vertex AI en région UE satisfait les deux. L’API directe (A) risque la résidence. Bedrock (C) est conforme mais ignore l’investissement GCP et le modèle d’identité existants. Le coût (D) ne peut pas primer sur une exigence légale de résidence.

A. Piloter la terminaison à partir de stop_reason (end_turn / plus de tool_use). B. Garder le plafond d’itérations, mais seulement comme filet de sécurité, pas comme contrôle principal. C. Continuer à analyser le texte à la recherche de « complete » comme signal principal. D. Supprimer toutes les limites et faire confiance au modèle pour s’arrêter. E. Baisser la température pour qu’il s’arrête plus tôt.

Réponse : A et B. Le flux de contrôle doit reposer sur stop_reason ; un plafond d’itérations est un filet de sécurité légitime contre les boucles emballées mais pas le mécanisme principal. Analyser le langage naturel (C) est fragile et non sûr. Supprimer toutes les limites (D) risque un coût emballé. La température (E) ne gouverne pas la terminaison.

A. Commencer à construire un système agentique immédiatement. B. Mener la discovery pour définir des critères de réussite mesurables par segment et énumérer les contraintes avant de concevoir. C. Choisir Opus 5 car c’est le plus capable. D. Supposer une cible de déflexion de 90 % et poursuivre.

Réponse : B. Sans critères de réussite ni contraintes, toute conception est sans ancrage. La discovery met au jour le pilier de valeur, les cibles numériques (par segment), le volume, la sensibilité des données et les contraintes. Construire (A), se replier sur le plus gros modèle (C) ou inventer une cible (D) sautent tous l’étape d’ancrage que l’examen récompense.

A. Déplacer les jobs tolérants à la latence vers la Message Batches API et ajouter un backoff exponentiel avec jitter respectant retry-after. B. Réessayer immédiatement dans une boucle serrée jusqu’à réussir. C. Demander un palier d’usage supérieur et/ou router le débordement vers un second modèle. D. Avaler le 429 et renvoyer un résultat vide comme succès. E. Basculer chaque requête sur Opus 5.

Réponse : A et C. Les plafonds ITPM/RPM sont dépassés au pic ; basculer le travail tolérant vers Batch (remise de 50 %, 24 h) plus le backoff, et augmenter le palier ou déborder vers un second modèle, sont les bons leviers de capacité. Le retry en boucle serrée (B) aggrave la tempête. Avaler les erreurs (D) est un anti-patron d’échec silencieux. Passer chaque requête à Opus (E) augmente le coût et ne corrige pas les rate limits.

A. Un pipeline de nettoyage de documents séquentiel en trois étapes avec contexte partagé. B. Une tâche de recherche qui se déploie en plusieurs investigations indépendantes avec contexte isolé, puis synthétise les résultats. C. Une seule recherche de statut de commande avec un budget de latence serré. D. N’importe quelle tâche, pour être sûr.

Réponse : B. Des sous-tâches parallèles indépendantes avec isolation de contexte et synthèse par fan-in sont le signal multi-agents classique. Le travail séquentiel à contexte partagé (A) est un workflow. Une seule recherche (C) est un augmented-LLM. « N’importe quelle tâche » (D) est le piège de la sur-ingénierie.

A. Tout basculer sur Haiku 4.5 et accepter une justesse moindre. B. Introduire une cascade : tenter d’abord Haiku 4.5 / Sonnet 5, escalader vers Opus 5 seulement quand les vérifications de confiance/validation échouent, et ajouter du prompt caching pour le préfixe stable. C. Réduire le nombre d’utilisateurs. D. Supprimer la suite d’évals pour économiser du calcul.

Réponse : B. Les cascades routent le moins cher d’abord et escaladent en cas d’échec, réduisant le coût tout en préservant la qualité sur les cas difficiles ; le caching amortit le préfixe stable. Haiku partout (A) sacrifie la justesse. Réduire les utilisateurs (C) ou les évals (D) ne traite pas l’économie unitaire de façon responsable.

A. Renvoyer une erreur à chaque utilisateur jusqu’au rétablissement. B. Réessayer avec backoff ; si l’échec persiste, replier sur un modèle/fournisseur secondaire et journaliser la requête comme servie en mode dégradé. C. Renvoyer silencieusement des réponses cachées mais périmées comme si elles étaient fraîches. D. Basculer immédiatement vers un modèle bien plus ancien dans une session de thinking Fable 5.1 active.

Réponse : B. Le retry-puis-repli avec journalisation explicite du mode dégradé maintient le système disponible et observable. L’échec dur (A) est une mauvaise HA. Faire passer des réponses périmées pour fraîches (C) est un échec silencieux. Faire basculer une session Fable 5.1 active vers un modèle plus ancien (D) supprime les thinking blocks et corrompt la session.

A. Construire un runtime Agent SDK et un sandbox sur mesure de zéro. B. Utiliser des managed agents (Anthropic héberge la boucle et le sandbox) pour réduire la charge d’exploitation et tenir l’échéance. C. Reporter le projet jusqu’à l’embauche d’une équipe de plateforme ML. D. Acheter le produit d’un concurrent sans support de Claude.

Réponse : B. Pas de capacité d’exploitation, échéance serrée, capacité de commodité → buy/managé. Les managed agents suppriment l’exploitation de la boucle et du sandbox. Construire (A) contredit les contraintes ; reporter (C) échoue à l’échéance ; (D) abandonne l’exigence.

A. Des exécutions d’éval offline contre un golden set à chaque release. B. Des métriques online, des traces et de la télémétrie de coût qui informent les changements de prompt/modèle/récupération. C. La normalisation initiale de la requête et la validation de la charge utile. D. La définition du schéma de sortie structurée. E. Le load balancer devant l’API.

Réponse : A et B. L’étape de rétroaction ferme la boucle des signaux de production vers les prompts, le routage et la récupération du système — les évals offline et la télémétrie/les traces online font exactement cela. La normalisation d’entrée (C) et la définition de schéma (D) relèvent des étapes d’entrée/sortie ; le load balancer (E) est de l’infrastructure, pas de la rétroaction.

A. Opus 5 avec effort xhigh pour une qualité maximale. B. Haiku 4.5 (ou Sonnet 5), possiblement avec fast mode, un minimum d’allers-retours d’outils et du prompt caching — car la latence et le volume sont les piliers contraignants et la barre de justesse est modeste. C. Un pipeline multi-agents pour la robustesse. D. Le bourrage en long-context de toute la base de connaissances par requête.

Réponse : B. Le pilier contraignant est la latence à fort volume avec seulement un besoin de justesse modeste — le modèle le moins cher/le plus rapide qui franchit la barre, avec moins d’allers-retours et du caching. Opus + xhigh (A) maximise la latence et le coût face au SLA. Le multi-agent (C) ajoute de la latence. Le bourrage en long-context (D) gonfle les tokens, le coût et la latence.

A. Pour satisfaire un quota de documentation. B. Pour capturer le contexte, les alternatives rejetées et leurs raisons, et l’arbitrage accepté, afin que la décision puisse être revue et reconsidérée à mesure que les contraintes changent. C. Parce que les ADR remplacent les évals. D. Parce qu’un système agentique ne peut pas être construit sans.

Réponse : B. Un ADR rend le raisonnement et les arbitrages explicites et revisables — exactement l’altitude que l’examen récompense. Ce n’est pas une formalité (A), ne remplace pas l’évaluation (C), et n’est pas un prérequis technique (D).

A. Environ $0.027 ; le plus gros levier unique est le prompt caching sur le préfixe stable. B. Environ $0.27 ; basculer tout le monde sur Opus 5. C. Environ $0.003 ; ne rien faire. D. Le coût est inconnaissable sans un test de charge.

Réponse : A. 6k×\$2/1e6 + 1.5k×\$10/1e6 = \$0.012 + \$0.015 = \$0.027. Avec un préfixe stable, le prompt caching (lecture ≈ 0,1× de l’entrée) supprime l’essentiel du coût d’entrée — le plus grand levier ici. Opus (B) augmente le coût unitaire ; $0.003 (C) est décalé d’un ordre de grandeur ; le coût est directement calculable (D).

A. Ajouter un coordinateur et trois sous-agents pour la robustesse. B. Utiliser un modèle plus petit/rapide ou le fast mode, raccourcir/streamer la sortie, et baisser l’effort là où c’est suffisant — car la génération est le terme dominant. C. Augmenter k dans la récupération pour améliorer la qualité. D. Déplacer le chemin interactif vers la Batch API.

Réponse : B. Le budget de latence est dominé par la génération, donc réduisez le modèle/la sortie/l’effort ou streamez. Le multi-agent (A) ajoute de la latence ; un k plus grand (C) ajoute du temps de récupération ; Batch (D) a une latence pouvant aller jusqu’à 24 h et ne peut pas servir un SLA p95 interactif.

A. L’ITPM est la limite contraignante (ITPM de pic ≈ 7,2M > 4M). B. Le RPM est la limite contraignante ; rien d’autre ne compte. C. Basculer le trafic tolérant à la latence vers Batch et/ou demander un palier supérieur ou déborder le surplus vers un second modèle. D. L’ignorer ; les rafales sont rares. E. Envoyer tout vers Opus 5 pour être sûr.

Réponse : A et C. peak_ITPM = 20×60×6,000 = 7.2M, ce qui dépasse le plafond de 4M, donc l’ITPM contraint en premier. Le correctif est de réduire l’ITPM interactif via Batch, un palier supérieur ou un routage de débordement. RPM seul (B) fait mal le calcul ; ignorer les rafales (D) cause des tempêtes de 429 ; Opus pour tout (E) augmente le coût et l’ITPM.

A. Déployer sur Microsoft Foundry en région UE pour la résidence et l’IAM existant. B. Router l’auto-refus de fraude directement vers le modèle pour gagner du temps d’expert. C. Insérer un point de contrôle d’approbation humaine obligatoire avant tout refus (action irréversible, réglementée). D. Utiliser l’API directe Anthropic pour le modèle le plus récent. E. Fixer une seule cible de justesse agrégée sur tous les types de sinistres.

Réponse : A et C. Résidence UE + Azure existant → Foundry UE ; une action réglementée irréversible requiert un point de contrôle humain. L’auto-refus (B) supprime le point de contrôle obligatoire ; l’API directe (D) risque la résidence ; une seule cible agrégée (E) masque la défaillance par type de sinistre.

A. Augmenter le plafond d’itérations. B. Ne replier que vers un modèle à parité fonctionnelle (support du thinking égal ou plus récent), journaliser le mode dégradé, et ne jamais rétrograder silencieusement une session de thinking. C. Désactiver les retries pour échouer vite. D. Analyser le texte de sortie pour détecter la corruption.

Réponse : B. Le repli doit préserver la parité fonctionnelle — les thinking blocks ne sont lisibles que par le modèle producteur ou plus récent — et le mode dégradé doit être journalisé, non silencieux. Les plafonds d’itérations (A) et l’analyse de texte (D) ne traitent pas la parité fonctionnelle ; désactiver les retries (C) nuit à la disponibilité.

A. Choisir le modèle le plus capable pour que la qualité ne soit jamais en question. B. Calculer le coût par requête, puis combiner le prompt caching sur le préfixe stable, une cascade cheap-first escaladant en cas d’échec de validation, et Batch pour le trafic tolérant à la latence jusqu’à ce que le calcul passe sous le budget. C. Deviner une conception et l’ajuster après le lancement. D. Supprimer l’évaluation pour réduire le coût de calcul.

Réponse : B. La rentabilité sous un budget énoncé est un exercice de calcul : cache + cascade + batch superposés jusqu’à coût < budget, avec la qualité préservée sur les cas difficiles via la cascade. Le tout-capable (A) surdépense ; deviner (C) est sans ancrage ; supprimer les évals (D) retire la garde de qualité.