Robustness Analysis of Agentic AI to Inconsistent and Incomplete Tool Responses

Dans le paysage moderne de l'intelligence artificielle, un nouveau type de travailleur numérique est apparu : l'agent de langage. Contrairement aux programmes antérieurs qui se contentaient de répondre à des questions basées sur une base de données statique, ces agents sont conçus pour agir. Ils peuvent naviguer sur le Web, interroger des bases de données et utiliser des logiciels pour résoudre des problèmes complexes, tout comme un assistant humain qui décroche le téléphone pour faire une réservation ou vérifie un tableur pour l'inventaire. Cependant, ces travailleurs numériques ne sont pas infaillibles. Lorsqu'ils sollicitent un outil, ils attendent une réponse propre et précise. Dans le monde réel, les outils échouent parfois, renvoyant des messages d'erreur, ou ils renvoient des données qui semblent parfaites en surface mais qui contiennent un mensonge subtil. Le défi central pour les chercheurs n'est pas seulement de construire des agents qui fonctionnent quand tout se passe bien, mais de construire des agents capables de reconnaître quand quelque chose s'est mal passé et de réagir de manière appropriante. Si un agent ne peut pas faire la différence entre un outil cassé et un outil trompeur, il appliquera le mauvais correctif, risquant ainsi de perdre du temps ou d'aggraver la situation.

Une équipe de chercheurs de l'Université d'Aalborg et de l'Université de Zhejiang s'est donné pour mission d'étudier précisément ce moment de décision. Ils voulaient savoir si une intelligence artificielle pouvait distinguer instantanément un outil qui n'a pas réussi à renvoyer des données d'un outil qui a renvoyé une réponse bien formée mais fausse. Pour tester cela, ils ont créé un environnement contrôlé simulant un scénario de service client de détail. Dans ce monde numérique, un agent agit comme un représentant du support, utilisant un ensemble de seize outils différents pour consulter les détails d'une commande, vérifier les méthodes de paiement et mettre à jour les informations de l'utilisateur. Les chercheurs ont pris une séquence d'actions standard et réussie et, à un point spécifique, ont remplacé la réponse normale de l'outil par une réponse défectueuse. Ils ont créé trois types de fautes : un échec complet où l'outil a renvoyé un message d'erreur, un statut de commande falsifié qui modifiait les règles de ce que l'agent était autorisé à faire ensuite, et un identifiant de paiement falsifié qui semblait correct mais qui n'appartenait pas au client.

Les chercheurs ne se sont pas contentés de regarder l'agent essayer de terminer la tâche pour voir s'il réussissait. Au lieu de cela, ils ont interrompu le processus à l'instant précis où les données défectueuses arrivaient. Ils ont examiné le « processus de pensée » interne du modèle, en regardant spécifiquement la probabilité qu'il génère le mot suivant de sa réponse. Ils ont mesuré deux choses distinctes. Premièrement, ils ont vérifié si les données renvoyées correspondaient au format attendu de l'outil lui-même. Deuxièmement, ils ont vérifié si ces données correspondaient à tout ce que l'agent avait déjà vu dans la conversation, y compris la demande originale de l'utilisateur et les résultats des outils précédents. Ils ont également observé le plan de l'agent pour l'étape suivante, mesurant son degré de confiance quant à l'action à entreprendre et si cette action impliquait de vérifier à nouveau l'état du système ou de progresser vers un changement.

Les résultats ont révélé une différence nette et immédiate dans la façon dont l'agent réagissait à ces différents types d'erreurs. Lorsque l'outil renvoyait un message d'erreur défectueux, l'agent reconnaissait immédiatement que les données ne correspondaient pas au format de base de l'outil. C'était un signal clair que l'outil avait échoué. Par conséquent, le plan de l'agent changeait radicalement ; il devenait très probable qu'il choisisse une action consistant à relire l'état du système, décidant essentiellement de réessayer ou de vérifier les faits. En revanche, lorsqu'un outil renvoyait une réponse bien formée mais fausse, l'agent ne voyait aucun problème de format. Les données paraissaient parfaites. Cependant, la comparaison interne de l'agent entre les nouvelles données et l'historique de la conversation a révélé un conflit. Les données fausses entraient en contradiction avec ce que l'utilisateur avait précédemment déclaré ou avec ce que la politique du système dictait.

Crucialement, les chercheurs ont découvert que la réaction de l'agent à ces fausses réponses dépendait entièrement de la nature du mensonge. Lorsque l'information falsifiée était une simple discordance, comme un identifiant de paiement qui n'appartenait pas à l'utilisateur, le plan de l'agent restait largement inchangé. Il ne devenait ni confus ni incertain ; il acceptait simplement les données fausses et passait à la suite, car le mensonge ne modifiait pas les règles fondamentales de l'interaction. Mais lorsque l'information falsifiée était un statut de commande qui changeait les règles des actions autorisées, le comportement de l'agent changeait. Il devenait incertain de la marche à suivre, et son plan changeait pour refléter la nouvelle réalité erronée. Cela a montré que l'agent pouvait distinguer un outil cassé d'un outil menteur, mais qu'il ne pouvait pas toujours distinguer un mensonge inoffensif d'un mensonge conséquent qui ferait dérailler la tâche.

L'étude a également examiné ce qui se passait après l'erreur initiale. Les chercheurs ont découvert que le type d'erreur laissait une trace durable dans le comportement futur de l'agent. L'outil cassé poussait l'agent à continuer de tenter de relire l'état du système lors des étapes suivantes, signe qu'il était coincé dans une boucle de vérification. Le statut de commande falsifié, cependant, a envoyé l'agent sur un chemin totalement différent, le menant à prendre des actions qui modifiaient l'état du système sur la base de l'information fausse. L'identifiant de paiement falsifié, que l'agent avait initialement accepté sans problème, continuait d'être accepté lors des étapes ultérieures, sans aucun signe que l'agent ait réalisé qu'il avait été trompé. Cela a démontré que la capacité de l'agent à reconnaître une erreur n'était pas un signal d'alarme unique et universel. Au contraire, c'était une collection de différents signaux. Un signal disait à l'agent que l'outil était cassé, un autre lui disait que les données étaient incohérentes avec le passé, et un troisième lui disait que les données étaient incohérentes avec les règles. Un seul signal ne pouvait pas attraper tous les types d'erreurs.

Les chercheurs ont conclu que la robustesse de ces agents ne réside pas dans une métrique unique qui signalerait toutes les mauvaises données. Elle nécessite plutôt la lecture simultanée de plusieurs canaux d'information. Un agent doit être capable de voir quand une donnée ne correspond pas à la forme d'un outil, quand elle contredit l'historique de la conversation et quand elle contredit les règles du domaine. L'étude a montré que ces différents types d'erreurs produisent des signatures distinctes dans les calculs internes de l'agent. Un outil cassé est immédiatement évident car il brise le format. Un outil menteur est plus difficile à attraper car il respecte le format mais brise l'histoire. Les mensonges les plus dangereux sont ceux qui changent les règles du jeu, car ils peuvent envoyer l'agent sur un chemin complètement erroné sans déclencher de confusion. En comprenant ces signatures spécifiques, les développeurs peuvent construire des agents mieux équipés pour diagnostiquer leurs propres erreurs et choisir le remède correct, qu'il s'agisse de réessayer un outil, de recouper un fait ou de s'arrêter pour demander des clarifications.