Amazon AWS transforme l’évaluation des agents en garde-fou de production avec Strands et AgentCore

Amazon AWS et Motorway ont mis en place une chaîne d’évaluation qui a fait passer les résultats incorrects des agents d’une requête sur huit à une sur 50. Le système a également réduit le délai de détection des problèmes, de quelques heures à quelques minutes, selon les deux entreprises.

Ces progrès ne proviennent pas simplement du remplacement du modèle sous-jacent. Motorway a plutôt modifié la manière dont son agent de recherche de stock pour concessionnaires est testé, mis en production et surveillé. La chaîne combine le SDK Strands Agents et Amazon Bedrock AgentCore Evaluations, du développement à la production.

Cette distinction est importante, car des réponses fluides peuvent dissimuler des actions défaillantes. Un agent peut présenter une liste de véhicules convaincante après avoir sélectionné le mauvais outil, envoyé des paramètres incorrects ou perdu une contrainte précédente. Les tests logiciels traditionnels capturent rarement toutes les réponses valides, tandis que l’examen manuel détecte les défaillances trop lentement.

Le cas Motorway fait passer l’évaluation des agents d’un contrôle qualité final à une boucle opérationnelle. Strands teste des scénarios contrôlés avant le déploiement. AgentCore évalue des traces de production échantillonnées après le déploiement. Les échecs deviennent ensuite de nouveaux cas de régression pour la version suivante.

Le résultat met sous pression les équipes qui évaluent encore les agents à l’aune de démonstrations, de notes moyennes attribuées par les utilisateurs ou de quelques invites scénarisées. Il soulève aussi une question plus délicate pour AWS : quelle confiance les acheteurs doivent-ils accorder à des évaluations qui reposent souvent sur un autre modèle de langage ?

Amazon AWS intègre l’évaluation dans la chaîne de livraison

Le changement important n’est pas un nouveau tableau de scores. L’évaluation détermine désormais si un agent atteint la production et à quelle vitesse les équipes détectent ensuite les régressions.

Motorway exploite une place de marché en ligne qui met en relation des vendeurs de véhicules et des concessionnaires professionnels. Son agent de recherche de stock pour concessionnaires traite des demandes en langage naturel portant sur les caractéristiques des véhicules, la géographie, le kilométrage, le prix et d’autres contraintes.

Une demande peut sembler réussie tout en étant incorrecte sur le plan opérationnel. L’agent peut interroger la mauvaise source d’inventaire, omettre un filtre ou transmettre une valeur mal formée à un outil. Sa réponse finale peut rester suffisamment soignée pour que ni l’utilisateur ni une simple vérification textuelle ne le remarquent immédiatement.

Motorway et AWS ont comblé cette lacune avec un modèle d’évaluation à trois couches. La première vérifie la sélection des outils et les paramètres. La deuxième examine la trajectoire de raisonnement de l’agent, c’est-à-dire la séquence de décisions et d’appels d’outils à l’origine d’une réponse. La troisième évalue la qualité et la conformité aux politiques de la sortie finale.

Cette séparation est importante, car une réponse acceptable ne prouve pas que l’agent a suivi un chemin sûr ou reproductible. Une réponse heureuse peut masquer une mauvaise trajectoire. À l’inverse, un agent peut choisir les bons outils tout en produisant une réponse finale confuse.

AWS indique que la précision de la sélection d’outils chez Motorway est passée de 87 % à 98 %. L’achèvement des tâches est passé de 82 % à 96 %, tandis que la rétention du contexte sur plusieurs tours est passée de 71 % à 94 %.

Les incidents mensuels en production sont tombés de 12 à deux. Le délai moyen de détection est passé de quelques heures à quelques minutes. AWS affirme que les concessionnaires effectuent désormais leurs recherches de véhicules en quelques minutes au lieu d’y consacrer des heures.

Il s’agit de résultats communiqués par les entreprises pour un seul déploiement, et non d’une référence sectorielle indépendante. Ils montrent toutefois pourquoi les équipes d’agents ont besoin de davantage qu’un unique indicateur de précision.

L’architecture attribue des seuils distincts à différentes catégories de défaillances. AWS recommande un usage des outils supérieur à 95 %, un raisonnement supérieur à 85 % et une qualité de sortie supérieure à 90 % dans son plan de production.

Une build qui passe sous ces seuils n’est pas promue. L’évaluation devient ainsi un élément du contrôle des livraisons, comparable à un test d’intégration ou à une vérification de sécurité. La surveillance en production vérifie ensuite si le comportement approuvé résiste au contact des utilisateurs réels.

C’est là que réside la tension centrale de l’article. L’évaluation des agents promet une fiabilité mesurable, mais les comportements les plus utiles ne peuvent pas toujours être vérifiés au moyen d’assertions déterministes. La chaîne combine donc des contrôles exacts et des juges probabilistes.

Pourquoi la fiabilité des agents met les équipes de production sous pression

Les équipes qui développent des agents sont désormais responsables de décisions et d’actions, et non seulement du texte généré, ce qui rend les tests de modèles classiques incomplets.

Un chatbot renvoie généralement du texte qu’une personne peut examiner. Un agent peut récupérer des enregistrements, appeler des systèmes métier, modifier des données ou déclencher un autre workflow. Le risque opérationnel passe d’une phrase imparfaite à une action incorrecte.

Ce changement met sous pression les responsables de l’ingénierie, les responsables produit et les acheteurs en entreprise. Ils doivent savoir si un agent a choisi le bon outil, fourni des paramètres valides, respecté les instructions précédentes et achevé la tâche prévue.

Un score moyen unique ne peut pas répondre à ces questions. Deux versions peuvent afficher la même note de qualité de sortie tout en présentant des comportements très différents vis-à-vis des outils. L’une peut échouer sans gravité dans sa formulation, tandis que l’autre récupère des enregistrements obsolètes ou non pertinents.

Le caractère non déterministe aggrave le problème. Les modèles de langage peuvent emprunter des chemins différents pour une même demande. Un test qui réussit une fois ne garantit pas que l’agent reproduira ce résultat.

AWS illustre ce problème avec pass^k, une mesure de fiabilité qui demande si une tâche réussit lors d’essais répétés. Si une tâche réussit 75 % du temps, la probabilité de trois succès consécutifs n’est que d’environ 42 %.

Ce calcul change la manière dont les équipes doivent interpréter les démonstrations. Une démonstration réussie prouve qu’un système peut accomplir une tâche. Elle ne montre pas que le système l’accomplit avec une régularité suffisante pour la production.

La difficulté s’accroît dans les conversations à plusieurs tours. Un utilisateur peut d’abord demander des véhicules électriques, puis restreindre les résultats selon la distance, avant de ne demander que les annonces récentes. L’agent doit préserver le contexte pertinent sans conserver les contraintes que l’utilisateur a retirées.

Strands Evals traite cela comme un problème de session plutôt que comme une notation d’invites isolées. Ses évaluateurs peuvent examiner les sorties, les trajectoires, les appels d’outils individuels et les conversations complètes. Le guide d’évaluation du framework recommande également de suivre la précision, l’achèvement des tâches, le temps de réponse, les hallucinations, l’utilisation des tokens et la satisfaction des utilisateurs.

Les équipes de production subissent également une pression organisationnelle. Une défaillance d’agent peut traverser les frontières entre l’application, le modèle, les données et l’infrastructure. Un responsable produit voit un résultat incorrect, alors que la cause première peut être une modification d’invite, un schéma d’outil, un index obsolète, un délai d’expiration ou une mise à jour de modèle.

Sans traces, les équipes débattent de la réponse visible. Avec des traces structurées, elles peuvent examiner quels outils étaient disponibles, ce que l’agent a sélectionné, quels paramètres il a envoyés et comment chaque étape a contribué à la réponse.

C’est pourquoi l’évaluation et l’observabilité doivent fonctionner ensemble. L’évaluation détermine si le comportement respecte une norme définie. L’observabilité enregistre les éléments nécessaires pour comprendre pourquoi il a réussi ou échoué.

Les résultats de Motorway suggèrent que cette approche combinée peut réduire le délai de détection. Ils n’établissent pas que chaque organisation constatera la même amélioration. Les bénéfices dépendent de la qualité des traces, de la conception de l’évaluation, des schémas de trafic et des conséquences associées à un score insuffisant.

Néanmoins, la charge de la preuve a changé de camp. Les équipes qui déploient des agents dans des workflows clients ont de plus en plus besoin d’éléments reproductibles, et non d’une collection de transcriptions convaincantes.

Comment fonctionne le mécanisme Strands et AgentCore

Strands gère l’évaluation contrôlée avant la livraison, tandis qu’AgentCore étend le même modèle de qualité à un échantillon du trafic de production.

Le SDK Strands Agents fournit le framework utilisé pour construire et instrumenter l’agent. Strands Evals organise les tests en cas, expériences, fonctions de tâche et évaluateurs.

Un cas définit un scénario, y compris l’entrée et toute sortie ou trajectoire d’outil attendue. Une expérience regroupe des cas et exécute un ou plusieurs évaluateurs. Une fonction de tâche relie ces cas à un agent actif ou à des données d’exécution précédemment capturées.

Cette structure prend en charge deux modèles de test. Les tests en ligne invoquent l’agent pendant une exécution d’évaluation, ce qui convient au développement et à l’intégration continue. Les tests hors ligne évaluent des traces enregistrées, ce qui aide à comparer des versions ou à étudier le comportement historique en production.

La chaîne de Motorway commence par des scénarios sélectionnés qui représentent les recherches courantes des concessionnaires et des cas limites connus. Chaque exécution capture la réponse de l’agent et le chemin suivi pour la produire.

La couche des outils demande si l’agent a sélectionné la bonne capacité et fourni des paramètres appropriés. Cette couche peut détecter une demande de recherche envoyée vers la mauvaise source de données ou un filtre exprimé dans un format invalide.

La couche de raisonnement examine la trajectoire. Elle recherche des décisions cohérentes sur l’ensemble de la séquence plutôt que de juger chaque appel d’outil indépendamment. Cela est important lorsqu’un résultat valide exige plusieurs actions dépendantes.

La couche de sortie évalue la réponse présentée à l’utilisateur. Elle peut évaluer des qualités telles que la pertinence, l’exhaustivité, la sécurité et l’ancrage dans les sources. Cette dernière couche reste nécessaire, car une exécution interne correcte peut tout de même produire une réponse peu claire.

Ces contrôles de développement agissent comme des garde-fous de livraison. L’équipe peut comparer une modification proposée du modèle, de l’invite, de la définition d’outil ou de l’orchestration à un jeu de tests établi. Une régression bloque la promotion avant que les clients ne la rencontrent.

Après le déploiement, AgentCore Evaluations lit les traces OpenTelemetry. OpenTelemetry est une norme ouverte permettant d’enregistrer les opérations dans des applications distribuées. Ses conventions d’IA générative peuvent capturer les invites, les complétions, les paramètres de modèle, les appels d’outils et les détails d’exécution associés.

Ce format de trace commun réduit la dépendance à un seul framework d’agents. La documentation AWS indique qu’AgentCore prend en charge les agents Strands et LangGraph instrumentés avec OpenTelemetry ou OpenInference.

AgentCore propose des évaluations à la demande et en ligne. L’évaluation à la demande note des traces ou sessions sélectionnées durant le développement et les tests de livraison. L’évaluation en ligne échantillonne le trafic réel et envoie les résultats vers des workflows de surveillance.

Le service peut appliquer des évaluateurs intégrés, des juges personnalisés fondés sur des modèles de langage, des comparaisons avec une vérité terrain ou des évaluateurs de code basés sur Lambda. La documentation AgentCore indique que les traces sont converties dans un format unifié avant la notation.

Les juges fondés sur des modèles de langage traitent des qualités qui résistent à la correspondance exacte. Ils peuvent évaluer si une réponse répond à l’objectif de l’utilisateur ou reste fidèle au contexte disponible.

Les évaluateurs de code traitent les exigences déterministes. Une fonction peut vérifier un identifiant précis, un champ obligatoire, une plage de paramètres ou un schéma de réponse. Cette approche est souvent plus prévisible que de demander à un autre modèle d’examiner des valeurs exactes.

La chaîne achemine ensuite les scores vers des tableaux de bord et des alertes CloudWatch. Une baisse de qualité peut créer un incident, déclencher une revue humaine ou alimenter un processus de rollback.

AWS recommande de commencer la surveillance en production avec un échantillonnage de 1 %. Les équipes peuvent accroître la couverture après avoir compris les coûts des évaluateurs, la latence et la qualité du signal. Les opérations à haut risque peuvent justifier des contrôles déterministes plus étendus, même lorsque l’évaluation par modèle de langage demeure échantillonnée.

Les échecs en production réintègrent la suite de développement. Une expression rare utilisée par un concessionnaire, un schéma de délai d’attente ou une relance inattendue devient un nouveau cas. L’ensemble de tests s’enrichit donc à partir des comportements réels, au lieu de rester une collection figée de prompts synthétiques.

Cette boucle de rétroaction est le mécanisme à l’origine de l’amélioration rapportée. Aucun évaluateur isolé ne produit de la fiabilité. La fiabilité vient de la conversion répétée des échecs observés en critères de publication mesurables.

Le véritable enjeu : les preuves face à l’intuition

Le pipeline Motorway remet en question une habitude fréquente du développement d’agents : modifier les prompts à l’intuition et les valider à l’aide d’une poignée d’exemples favorables.

L’itération sur les prompts est rapide, ce qui encourage les revues informelles. Un développeur repère une réponse faible, ajuste une instruction, teste quelques prompts et déploie l’amélioration apparente.

Ce processus peut corriger le cas visible tout en dégradant un autre comportement. Une instruction plus stricte peut améliorer la sélection des outils tout en réduisant l’accomplissement des tâches. Un prompt plus long peut préserver le contexte, mais augmenter la latence ou encourager des appels inutiles.

L’adversaire principal du blueprint Amazon AWS n’est donc pas un autre fournisseur de cloud. C’est le développement d’agents guidé par l’intuition, où les équipes manquent de références stables et découvrent les régressions à travers les plaintes des clients.

Les expérimentations Strands offrent une comparaison contrôlée. Les équipes peuvent exécuter les mêmes cas sur deux versions et examiner les changements par couche d’évaluation. Les compromis deviennent ainsi visibles avant une mise en production.

AgentCore étend cette comparaison à la production. Les utilisateurs réels introduisent une terminologie spécifique, des demandes incomplètes, des contraintes contradictoires et des conditions de timing que les jeux de données sélectionnés couvrent rarement. L’évaluation en mode shadow peut noter ces interactions sans modifier immédiatement le système visible par l’utilisateur.

Ce modèle ressemble à une livraison logicielle mature sur un point important. Les critères de qualité deviennent exécutables et reproductibles. Toutefois, l’évaluation des agents ne peut pas simplement copier les pratiques de tests unitaires, car de nombreuses sorties peuvent être valides.

Une assertion traditionnelle peut vérifier qu’une fonction a renvoyé une valeur précise. Un évaluateur d’agent doit souvent déterminer si une réponse est suffisamment utile, fondée ou complète. Ces critères impliquent une interprétation.

Le pipeline résout ce conflit en choisissant l’évaluateur selon l’affirmation à vérifier. Les règles exactes de données et de format sont confiées au code. Les qualités sémantiques sont confiées à des juges basés sur des modèles de langage. Les parcours d’outils peuvent recourir à des trajectoires attendues, à un jugement contextuel, ou aux deux.

Cette distinction devrait influencer les décisions d’achat. Une plateforme qui fournit un seul score de qualité combiné peut masquer la catégorie de défaillance qui a changé. Les acheteurs d’entreprise devraient demander s’ils peuvent examiner les scores aux niveaux de l’outil, de la trace et de la session.

Ils devraient également demander si les évaluations peuvent accompagner l’application d’un environnement à l’autre. Un benchmark de développement qui disparaît après le déploiement ne peut pas détecter les changements de comportement causés par les données de production ou les usages des utilisateurs.

AWS présente AgentCore comme la couche managée assurant cette continuité. Selon sa présentation de l’évaluation, le service gère les modèles d’évaluation, l’infrastructure d’inférence, le traitement des données et le passage à l’échelle.

Cette organisation réduit le travail d’infrastructure, mais accroît aussi la dépendance aux services AWS pour l’évaluation, la télémétrie, les tableaux de bord et les contrôles de déploiement. Les équipes qui opèrent déjà sur AWS peuvent considérer cette intégration comme un avantage.

Les organisations ayant des exigences multi-cloud doivent examiner la portabilité. OpenTelemetry fournit un format de trace transférable, mais les tableaux de bord, configurations d’évaluateurs, politiques IAM et réponses automatisées peuvent rester spécifiques à une plateforme.

Les frameworks ouverts proposent une autre voie. LangSmith, Arize Phoenix, Braintrust et d’autres systèmes d’observabilité des agents combinent également traces, jeux de données, expérimentations et évaluateurs. La comparaison pertinente ne porte pas sur le nombre de juges disponibles.

La meilleure question est de savoir si un système relie les échecs de production à des tests reproductibles et à des décisions de publication. C’est cette boucle fermée que le déploiement Motorway affirme avoir améliorée.

Les équipes ont aussi besoin de connaissances opérationnelles rigoureuses. Les résultats d’évaluation, explications d’incidents et règles métier deviennent plus utiles lorsque les ingénieurs peuvent les retrouver à côté des traces et des cas de test. Une base de connaissances d’ingénierie consultable peut préserver ce contexte d’une version à l’autre.

Ce que les gains de précision rapportés ne démontrent pas

Les améliorations rapportées sont significatives, mais elles n’éliminent ni la variabilité des juges, ni les lacunes d’échantillonnage, ni le biais des benchmarks, ni la dépendance à la plateforme.

La première limite concerne l’attribution. Motorway a mis en place un pipeline d’évaluation, puis a rapporté de meilleures performances. Les résultats publics n’isolent pas la part de l’amélioration attribuable aux nouveaux tests, aux modifications de prompts, aux corrections d’outils, à l’attention opérationnelle ou à AgentCore lui-même.

La deuxième limite concerne la construction des benchmarks. Les suites d’évaluation reflètent les scénarios que les équipes choisissent d’inclure. Un taux de réussite élevé peut coexister avec une couverture faible si les cas sous-représentent le langage ambigu, les états rares de l’inventaire ou des parcours de conversation inhabituels.

Les retours de production réduisent ce risque sans l’éliminer. Les utilisateurs peuvent abandonner une interaction défaillante sans signaler le problème. L’organisation a alors besoin de signaux métier, comme le raffinement de recherche ou l’abandon de tâche, pour détecter les échecs cachés.

La troisième limite est l’échantillonnage. Un taux de surveillance de 1 % maîtrise le coût des évaluations, mais des défaillances rares peuvent échapper à l’observation. Les politiques d’échantillonnage devraient refléter le volume de trafic et les conséquences, et pas seulement un pourcentage initial universel.

La quatrième limite est la fiabilité des juges. Un LLM-as-a-judge utilise un modèle de langage pour évaluer le comportement d’un autre modèle au regard d’une grille. Il peut introduire un biais de position, une notation incohérente ou des préférences liées au style de réponse.

Une explication détaillée ne garantit pas un jugement correct. Les équipes devraient calibrer les juges basés sur des modèles par rapport à des exemples revus par des humains et mesurer périodiquement leur concordance. Des évaluations répétées peuvent révéler une variabilité qu’un score unique dissimule.

Les grilles d’évaluation ont elles aussi besoin d’un contrôle de version. Modifier les instructions de l’évaluateur peut faire évoluer les scores sans aucun changement de l’agent. Les tableaux de bord devraient distinguer les régressions produit des changements de mesure.

AWS reconnaît cette charge opérationnelle plus large dans ses recommandations AgentOps. Le modèle recommandé place des vérifications à la demande avant la publication et une surveillance en ligne après le déploiement. Son framework AgentOps sépare également la télémétrie du framework, des services, de l’infrastructure et du métier.

La cinquième limite concerne l’interprétation des métriques. Porter la précision de sélection des outils à 98 % laisse encore des échecs. Le taux résiduel acceptable dépend de ce que fait l’outil.

Un filtre de véhicule manqué crée une mauvaise expérience de recherche. Une action incorrecte impliquant un paiement, un dossier médical ou une politique d’accès comporte un risque différent. Les équipes devraient fixer les seuils en fonction des conséquences plutôt que de reproduire sans changement les objectifs de Motorway.

La rétention du contexte exige également une définition rigoureuse. AWS rapporte une hausse de 71 % à 94 %, mais les résumés publics ne fournissent pas assez de détails pour comparer ce score au benchmark d’une autre entreprise.

La sixième limite est la corrélation entre évaluateurs. Plusieurs juges peuvent récompenser la même qualité superficielle tout en manquant un angle mort commun. AWS recommande des critères distincts, afin que chaque évaluateur couvre une dimension de qualité séparée.

La revue humaine reste importante pour les échecs à fort impact et les scores contestés. Les personnes peuvent déterminer si une grille représente réellement l’exigence métier, ce qu’un juge automatisé ne peut pas décider de manière indépendante.

La dernière limite concerne les incitations. Lorsqu’une métrique devient une porte de déploiement, les équipes peuvent optimiser pour la suite de tests. Les cas de production, les ensembles de défis renouvelés et les évaluations masquées aident à éviter qu’un système ne s’améliore uniquement sur des prompts familiers.

Aucun de ces points n’invalide les résultats de Motorway. Ils définissent les conditions nécessaires pour les interpréter de façon responsable. L’évaluation est un système de mesure, et les systèmes de mesure ont besoin de leurs propres tests.

Ce qu’il faut suivre après le blueprint Amazon AWS

Le prochain test consiste à déterminer si ce pipeline maintient ses gains avec de nouvelles versions d’agents, une croissance du trafic réel et des coûts d’évaluation.

Le premier signal est la tendance des incidents chez Motorway. La baisse rapportée de 12 incidents mensuels à deux établit une référence. Une performance durable étayerait l’affirmation selon laquelle l’évaluation continue détecte les régressions, plutôt que de simplement refléter un nettoyage ponctuel.

La composition de ces incidents compte autant que leur nombre. Si les échecs restants se concentrent autour d’un langage inédit ou d’un contexte multi-tour, Motorway peut étendre ses cas et ses juges. Des erreurs répétées d’outils ou de paramètres affaibliraient la confiance dans les portes de publication.

Le deuxième signal est la performance pass^k sur de nouveaux modèles et prompts. Les équipes devraient vérifier si la fiabilité sur exécutions répétées reste stable lorsque Motorway modifie les versions de modèles, les schémas d’outils ou la logique d’orchestration.

Une version peut améliorer la précision moyenne tout en devenant moins cohérente. La publication du succès sur essais répétés révélerait cette différence plus clairement qu’un simple taux de réussite.

Le troisième signal est l’élargissement de l’échantillonnage en production. AWS recommande de commencer à 1 %, puis d’augmenter progressivement. Une couverture plus large sans coût d’évaluateur ingérable renforcerait l’argument en faveur du service managé.

Il faudra observer si les organisations combinent des jugements sémantiques échantillonnés avec des vérifications plus larges fondées sur le code. Cette conception hybride peut réserver les modèles de langage aux questions de qualité ambiguës tout en appliquant une validation déterministe à chaque action critique.

L’adoption d’AgentCore au-delà de Strands testera également la valeur de son architecture fondée sur les traces. La prise en charge des données standard OpenTelemetry n’a d’importance que si les équipes peuvent migrer leurs agents et préserver un historique d’évaluation utile.

La leçon principale est déjà claire. Les agents en production ont besoin d’une boucle qualité qui commence avant la publication et se poursuit après l’arrivée des utilisateurs. Tests, traces, alertes, analyse d’incidents et nouveaux cas de régression devraient former un processus unique et connecté.

Pour les développeurs, l’action pratique consiste à choisir un workflow à forte valeur et à définir ses modes de défaillance avant de sélectionner les évaluateurs. Suivez séparément le choix de l’outil, les paramètres, l’accomplissement de la tâche, le contexte, la latence et la sortie finale. Répétez ensuite les mêmes cas sur plusieurs essais.

Les acheteurs d’entreprise devraient demander ces éléments de preuve lors des revues d’agents. Demandez quels comportements bloquent le déploiement, comment le trafic de production est échantillonné, qui valide la précision des juges et comment les échecs deviennent de futurs tests.

Les travailleurs du savoir devraient s’y intéresser, car ces contrôles déterminent si un agent peut être digne de confiance pour un travail aux conséquences importantes. Lors de l’évaluation d’un déploiement d’agent Amazon AWS, ne vous arrêtez pas à la fluidité des réponses. Demandez la trace, le résultat sur exécutions répétées et la boucle de rétroaction de production qui les sous-tend.