Habr AI : Pourquoi les systèmes d'agents ont besoin de nouvelles métriques de contrôle et de sécurité

La transition des chatbots aux systèmes d'agents change fondamentalement ce qui doit être contrôlé : alors qu'il était autrefois suffisant de comprendre dans quelle mesure une réponse d'un modèle était utile et correcte pour une requête, il est désormais nécessaire d'évaluer toute la chaîne d'actions que le système construit par lui-même. Un agent ne se contente pas de générer du texte, mais planifie des étapes, sélectionne des outils, demande des données, peut déléguer du travail à d'autres agents et prendre des décisions intermédiaires. Dans une telle architecture, une belle réponse finale ne garantit plus que le système a fonctionné de manière fiable, sûre et économe.

Pour un chatbot classique, les métriques principales étaient généralement la qualité de la réponse, la précision de la formulation, la pertinence et la satisfaction de l'utilisateur. Pour un agent, cela est insuffisant, car une erreur peut apparaître bien avant le message final. Le système peut décomposer incorrectement une tâche en étapes, sélectionner un outil inadapté, terminer le scénario prématurément, rester bloqué dans des actions répétitives ou, au contraire, effectuer des étapes inutiles et consommer trop de tokens, de temps et de requêtes externes.

Par conséquent, l'attention se déplace non seulement sur le résultat, mais aussi sur la trajectoire par laquelle l'agent y est parvenu. Cela élargit l'ensemble des métriques. En premier lieu se trouve la proportion de tâches complétées avec succès : non seulement si l'agent a fourni une réponse plausible, mais s'il a atteint l'objectif de l'utilisateur sans intervention manuelle.

Viennent ensuite les indicateurs de qualité de planification—dans quelle mesure les étapes ont été choisies logiquement, combien d'entre elles sont vraiment nécessaires, à quelle fréquence le plan doit être révisé lors de l'exécution. Séparément, il est important de mesurer la correction de l'invocation d'outils : l'agent a-t-il sélectionné la bonne API, transmis des paramètres valides, obtenu le résultat attendu et géré correctement les erreurs ? Pour les systèmes multi-agents, des métriques de coordination sont ajoutées : les agents ne dupliquent-ils pas le travail les uns des autres, ne perdent-ils pas le contexte et ne créent-ils pas d'actions conflictives ?

Tout aussi importants sont le coût et l'observabilité. Les systèmes d'agents sont presque toujours plus coûteux qu'un dialogue ordinaire, car chaque étape supplémentaire, chaque appel au modèle ou service externe a un coût. Ainsi, le contrôle doit prendre en compte le nombre moyen d'itérations par tâche, la consommation de tokens, la fréquence des nouvelles tentatives, la durée d'exécution et la proportion d'actions sans sens.

En parallèle, les exigences de traçabilité augmentent : l'équipe doit voir quelle décision l'agent a prise à chaque étape, sur quelles données elle s'est appuyée, pourquoi elle a sélectionné un outil particulier et à quel moment elle s'est écartée du scénario attendu. Sans cette transparence, il est impossible de déboguer le comportement, d'enquêter sur les défaillances ou de prouver la conformité avec les politiques internes. De là découle un changement dans les exigences de sécurité.

Si un chatbot risquait principalement de produire du texte incorrect ou dangereux, un agent peut déjà exécuter une action indésirable : envoyer une requête au mauvais endroit, obtenir un accès non intentionnel aux données, modifier un enregistrement dans un système ou utiliser un outil en dehors de son contexte autorisé. Par conséquent, l'architecture d'agent nécessite un contrôle d'accès granulaire, une approche sandbox pour les outils, des politiques strictes sur l'exécution des actions, des limites d'autonomie et des mécanismes d'arrêt si le système exhibe un comportement suspect. La sécurité ici cesse d'être un filtre en entrée et en sortie et devient une partie de la boucle opérationnelle.

Un autre changement concerne les opérations. Pour un système d'agent, il est important non seulement d'exécuter une tâche dans un scénario idéal, mais aussi de se dégrader en toute sécurité en cas de défaillance. Les métriques de récupération deviennent utiles : à quelle fréquence l'agent peut-il corriger sa propre erreur, quand transfère-t-il une tâche à un humain, combien d'incidents nécessitent une enquête manuelle et à quelle vitesse l'équipe peut-elle reproduire le problème à partir des journaux ?

En pratique, cela signifie que les équipes produit et plateforme doivent concevoir non seulement l'intelligence de l'agent, mais aussi ses modes de défaillance, la surveillance et les procédures d'intervention. La conclusion principale est que les systèmes d'agents ne peuvent pas être évalués selon les mêmes règles que les interfaces de chat ordinaires. Les entreprises doivent passer de la vérification de la qualité des réponses à une ingénierie d'exécution complète : mesurer la réalisation des tâches, la robustesse des plans, la correction de l'invocation d'outils, le coût, la traçabilité et le respect des règles de sécurité.

Plus une LLM devient autonome, plus son contrôle se rapproche du monitoring d'un service logiciel complexe plutôt que de l'édition d'énoncés réussis ou échoués.