Stop running fresh model benchmarks and start watching your agent try to cancel a subscription. The gap between those tw

Cessez de lancer de nouveaux benchmarks de modèles et commencez à observer votre agent tenter d'annuler un abonnement. C'est dans l'écart entre ces deux activités que les systèmes de production échouent. Un test sur un seul tour peut vous dire si une réponse semble agréable. Il ne peut pas vous dire si l'agent vient de rembourser le mauvais client, s'il a bouclé quatorze fois contre une API de calendrier, ou s'il a décidé de sauter entièrement le contrôle de fraude. Le texte est la chose la moins dangereuse qu'un agent produise. Les risques réels se cachent dans les outils qu'il manipule, les données qu'il modifie et les moments où il aurait dû demander de l'aide mais a continué seul.

Pourquoi les benchmarks textuels échouent en production

Les scores élevés sur les benchmarks standards sont devenus une forme de confort trompeuse. Un agent capable de rédiger une prose élégante peut tout de même représenter un risque opérationnel. Lorsque votre système prend des rendez-vous, modifie des enregistrements de base de données ou dépose des tickets de support, le texte généré n'est que la surface visible du flux de travail. En dessous, l'agent prend des décisions concrètes sur l'endpoint à appeler, la charge utile à envoyer et le moment de s'arrêter. Il peut dominer un classement de compréhension de lecture tout en vous faisant perdre de l'argent en réservant deux fois les mêmes ressources, en modifiant la mauvaise ligne ou en divulguant un état sensible dans un fichier de log. Vous devez vérifier la mécanique du travail, et pas seulement le polissage du résultat. Si un agent peut obtenir un bon score lors d'un test d'assurance qualité hors ligne et échouer tout de même dans votre flux de travail en bouclant ou en utilisant mal un outil, c'est que votre évaluation se concentre sur les mauvais signaux.

Cartographier les cinq dépendances

L'équipe de Van Data Team commence chaque évaluation par la cartographie de cinq points de contrôle spécifiques. Cela change entièrement la question. Vous ne demandez plus si un modèle est plus intelligent qu'un autre. Vous commencez à vous demander si l'agent peut réellement terminer une tâche de production sous vos contraintes réelles.

Résultats métier. Définissez ce que signifie "terminé" en termes de dollars et d'impact client. Une tâche n'est pas terminée parce que l'agent a émis un résumé. Elle est terminée lorsque l'enregistrement de l'inventaire est exact, que le rendez-vous est confirmé et que le client a reçu un numéro de suivi valide.

État mutable. Sachez exactement ce que l'agent est autorisé à modifier. Quelles tables, quels statuts, quels indicateurs de compte ? Si l'agent peut émettre des remboursements, reprogrammer des tâches ou mettre à jour des adresses de facturation, vous devez inventorier chaque champ qu'il touche.

Permissions des outils. Soyez explicite sur les endpoints d'API et les fonctions qui sont dans le périmètre. Un agent ayant accès à un outil de recherche, un outil d'écriture et un outil de notification les confondra si les limites sont floues. Associez chaque permission à un besoin opérationnel spécifique.

Récupération après échec. Décidez de ce qui se passe lorsque l'API de calendrier expire, renvoie une erreur 500 ou renvoie un JSON malformé. L'agent ne doit pas paniquer, halluciner un message de succès ou réessayer indéfiniment. Il a besoin d'un chemin de repli clair.

Points de contrôle par révision humaine. Identifiez les moments où une personne doit valider l'action avant que l'agent ne poursuive. Ce n'est pas un signe de faiblesse de l'automatisation. C'est une soupape de sécurité pour les changements à fort impact et une source d'étiquettes de vérité terrain pour vos grilles d'évaluation.

À quoi ressemble un véritable plan d'évaluation

Une fois les dépendances cartographiées, vous avez besoin d'un plan d'évaluation qui corresponde au désordre de la production. Les métriques de présentations PowerPoint ne vous aideront pas ici.

Créez des jeux de tests à partir de véritables échecs de production, et non à partir de banques de questions synthétiques. Si votre agent a échoué mardi dernier en confondant deux SKU similaires, cette confusion exacte doit devenir un cas de test permanent. Votre suite d'évaluation doit s'enrichir chaque fois qu'un incident vous enseigne quelque chose de nouveau.

Rédigez des grilles d'évaluation qui définissent la réussite en termes opérationnels. Les critères vagues comme "utile" ou "précis" sont inutiles. Une grille utile stipule qu'une tâche de remboursement n'est réussie que si l'ID de paiement original a été référencé, que le montant correspond à la demande, qu'un e-mail de confirmation a été mis en file d'attente et que l'ID de transaction a été enregistré.

Définissez des spécifications de traçage pour les appels d'outils et les tentatives de réessai. Vous avez besoin d'une observabilité sur ce que l'agent a planifié, ce qu'il a réellement appelé, le nombre de tentatives de réessai et si la stratégie de réessai était appropriée. Une trace sans granularité au niveau de l'outil n'est qu'un joli récit.

Établissez des politiques pour savoir quand alerter un humain. L'agent doit connaître ses propres limites. Si une requête dépasse un seuil monétaire, fait référence à un compte VIP ou rencontre un état qu'il n'a jamais vu auparavant, il doit escalader l'information plutôt que de deviner.

Installez des portes de déploiement pour bloquer les mauvaises mises à jour de modèles. Une nouvelle version n'est une amélioration que si elle améliore vos résultats spécifiques. Si elle hallucine davantage les arguments des outils, augmente la latence ou introduit de nouveaux risques de sécurité, elle ne doit pas être déployée. La porte de déploiement maintient la stabilité de la production, même lorsque le fournisseur du modèle de base publie une nouvelle version.

Évaluation au runtime : surveiller l'agent en action

Anthropic pousse l'industrie à dépasser les tests hors ligne pour passer à l'évaluation au runtime. Au lieu de juger une transcription après coup, l'évaluation au runtime permet à un système de juger le travail de l'agent pendant que la tâche est encore en cours. Cela permet de détecter les erreurs avant qu'elles ne se transforment en problèmes réels.

L'ajout d'un évaluateur coûte des tokens et de la latence. Vous ne pouvez pas vous permettre d'évaluer chaque petite étape. L'emplacement de chaque évaluateur est une décision de conception. Placez-les là où les erreurs coûtent cher. Les points de contrôle les plus précieux se situent juste avant de valider un changement d'état dans une base de données, juste avant d'effectuer un paiement et juste avant d'envoyer un message à un client. Ce sont les moments où une mauvaise décision devient une action irréversible.

Attention à un angle mort spécifique. Si le même modèle effectue le travail et l'évalue également, il risque de passer à côté des mêmes erreurs. Le raisonnement qui a produit une erreur peut facilement la rationaliser lors de la révision. Pour les tâches à fort impact, maintenez une révision humaine dans la boucle. Laissez des humains valider le jugement de l'évaluateur, surtout lorsque l'argent ou la confiance des clients est en jeu.

L'objectif ici est le contrôle opérationnel. Connectez vos données d'incident, vos rubriques de tâches et vos traces au runtime dans un cycle de rétroaction unique. Évaluez l'ensemble du parcours : le plan, l'utilisation des outils, le comportement de récupération et le résultat final. Utilisez des tests hors ligne pour détecter les erreurs connues et reproductibles avant le déploiement. Utilisez les traces au runtime pour identifier les nouvelles défaillances que vous n'aviez pas anticipées. Utilisez la révision humaine pour découvrir où vos rubriques sont trop naïves et nécessitent d'être affinées.

Alors posez-vous la question : où placeriez-vous un évaluateur au runtime dans votre flux de travail ? Avant un appel d'outil, après un appel d'outil, ou seulement avant un changement risqué ? La plupart des équipes commencent de manière trop large, en évaluant tout, puis finissent par s'arrêter net sous le poids des coûts. Commencez de manière ciblée. Choisissez l'action unique qui ferait le plus de dégâts en cas d'erreur. Placez un évaluateur là en premier.

Commencez par une seule erreur coûteuse

L'évaluation opérationnelle n'est pas un exercice de recherche. C'est un moyen de mieux dormir une fois que l'agent est en production. Vous n'avez pas besoin d'un framework parfait dès le premier jour. Vous avez besoin d'un flux de travail unique et bien défini, d'une rubrique rédigée en termes métier simples et d'un évaluateur placé au moment exact où une erreur devient coûteuse. Réussissez cela, et vous aurez une base sur laquelle vous pourrez réellement compter.

Si vous souhaitez approfondir l'évaluation des agents et l'évaluation au runtime avec une communauté de praticiens, vous pouvez trouver la communauté d'apprentissage GyaanSetu sur https://t.me/GyaanSetuAi.