Si vous ne pouvez pas mettre un chiffre sur le fait qu'un changement a rendu votre agent meilleur ou pire, vous ne l'ingénierez pas, vous devinez avec des étapes en plus. La raison la plus courante pour laquelle les projets d'agents stagnent n'est pas un modèle faible, c'est l'absence d'un harnais d'évaluation. Sans ça, chaque ajustement de prompt, chaque changement d'outil, chaque changement de modèle est évalué par quelqu'un qui regarde une poignée de sorties et déclare que « ça semble mieux », ce qui est la façon de livrer une régression et de l'apprendre par un utilisateur. Le tableau de score doit exister avant l'agent, parce qu'on ne peut pas améliorer ce qu'on ne peut pas noter.

Le recadrage : un jeu d'évaluation est votre suite de tests pour du code probabiliste. Vous ne refactoreriez pas un service sans tests et ne le livreriez pas sur la seule impression qu'il a l'air correct. Un agent est plus difficile à raisonner que ce service, pas plus facile, donc il a besoin du tableau de score encore plus, pas moins.

Construisez le harnais avant l'agent

Un harnais d'évaluation est peu glamour et petit au départ : un ensemble d'entrées représentatives, une définition de ce qu'est une bonne sortie pour chacune, et un moyen de faire tourner le système actuel sur toutes et d'obtenir un score. Vingt à cinquante exemples réels, tirés du trafic réel ou attendu, valent mieux que mille exemples synthétiques. L'idée, c'est une jauge fixe, pour que « nous avons amélioré l'agent » devienne une affirmation vérifiable plutôt qu'une impression.

Une fois qu'il existe, le workflow s'inverse. Chaque changement, nouveau prompt, nouvel outil, nouveau modèle, tourne d'abord sur le harnais. Un changement qui fait monter le score part en production ; un changement qui le fait descendre n'y part pas, peu importe à quel point il semblait astucieux. Sur Bedrock, Model Evaluation vous donne un chemin managé pour ça, avec des métriques automatiques et une revue humaine, et c'est passé en disponibilité générale bien avant que vous n'en ayez besoin ici. L'outil compte moins que la discipline : noter, puis décider.

LLM-juge, et où il vous ment

Noter des sorties ouvertes à la main ne passe pas à l'échelle, donc le mouvement standard consiste à utiliser un modèle comme juge : donner à un modèle solide l'entrée, la sortie de l'agent et une grille, et lui demander de noter. Bedrock Model Evaluation supporte exactement ça. C'est vraiment utile, et c'est aussi un composant qui peut se tromper, ce que les équipes oublient dès qu'il se met à émettre des chiffres bien rangés.

Le juge a des modes de défaillance prévisibles, et il faut concevoir autour :

  • Biais de position et de verbosité. Les juges ont tendance à préférer la première option présentée et la réponse la plus longue et la plus sûre d'elle-même, indépendamment de sa justesse. Randomisez l'ordre et contrôlez la longueur.
  • Préférence de soi. Un juge de la même famille de modèle peut noter plus haut les sorties de sa propre famille. Là où ça compte, utilisez un juge d'une famille différente du modèle testé.
  • Dérive de la grille. Une grille vague (« est-ce que cette réponse est bonne ») produit des scores vagues et instables. Une grille précise (« la réponse cite-t-elle la section de la politique, et la section citée est-elle correcte ») produit des scores exploitables.
  • Accord confiant avec une mauvaise réponse. Si l'entrée contient une prémisse fausse, le juge peut récompenser une sortie qui va dans son sens. Incluez des cas adversariaux où le bon comportement est de refuser ou de corriger.

Le juge n'est pas la vérité terrain. C'est une approximation rapide et bon marché de la vérité terrain que vous calibrez sur un petit ensemble étiqueté par des humains. Si le juge et vos humains ne sont pas d'accord sur cet ensemble, corrigez la grille avant de faire confiance au juge sur le reste.

Notez la trajectoire, pas seulement la réponse

Pour les agents en particulier, la réponse finale n'est que la moitié de ce qui compte. Un agent peut produire une bonne réponse par un mauvais chemin : appeler un outil qu'il n'aurait pas dû appeler, dépenser dix étapes sur une tâche à deux étapes, ou faire fuiter des données dans un log en cours de route. Évaluez la trajectoire autant que la sortie. A-t-il utilisé les outils attendus ? Est-il resté dans ses actions autorisées ? A-t-il terminé en un nombre raisonnable d'étapes ? Un agent qui obtient la bonne réponse en appelant une API de suppression qu'il n'était jamais censé toucher a échoué l'éval, quoi que dise le texte final.

À retenir

L'ordre n'est pas négociable : harnais d'évaluation d'abord, agent ensuite. Le harnais est un petit ensemble fixe d'entrées réelles avec des bonnes sorties définies et un score reproductible, et il transforme chaque changement d'un test au feeling en une décision mesurée. Utilisez un LLM-juge pour faire passer la notation à l'échelle, mais traitez-le comme un composant faillible : contrôlez ses biais, donnez-lui une grille précise, et calibrez-le sur des étiquettes humaines. Notez le chemin, pas seulement le résultat. On ne peut pas livrer ce qu'on ne peut pas noter, et les équipes qui livrent des agents fiables sont celles qui ont construit le tableau de score avant de construire le joueur.

À lire ensuite

Pour le côté plateforme de câbler des évals dans un pipeline de livraison, les notes de terrain cloud vivent sur ercan.cloud, et le hub est sur ercanermis.com.