💬 NLP

AppWorld-UL: Benchmarking Diverse Agent-User Interactions for Tool-Use

Cet article présente AppWorld-UL, un benchmark exigeant comprenant 516 tâches réparties sur neuf applications simulées qui évalue la capacité des agents utilisant des outils à gérer diverses interactions nécessaires avec les utilisateurs, révélant que même les modèles de pointe éprouvent des difficultés significatives face à ces scénarios impliquant l'utilisateur dans la boucle.

Auteurs originaux : Junzhi Chen, Harsh Trivedi, Jane Pan, Michael JQ Zhang, Tejas Srinivasan, Niranjan Balasubramanian, Ashish Sabharwal

Publié 2026-07-24

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Junzhi Chen, Harsh Trivedi, Jane Pan, Michael JQ Zhang, Tejas Srinivasan, Niranjan Balasubramanian, Ashish Sabharwal

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous enseigniez à un robot majordome super intelligent comment faire vos courses. Vous lui dites : « Va m'acheter une chemise. » Dans le monde de l'informatique, cela s'appelle l'« utilisation d'outils » (tool use) — le robot sait comment ouvrir une application, cliquer sur des boutons et effectuer un achat. Mais voici le hic : la vraie vie est désordonnée. Et si vous aviez cinq chemises dans votre panier et que le robot ne savait pas laquelle vous vouliez dire ? Et si la chemise que vous voulez est en rupture de stock ? Et si le prix doublait soudainement, et que vous n'en achèteriez une que si l'on vous demandait votre avis pour ce changement spécifique ?

La plupart des tests pour ces robots vérifient seulement s'ils peuvent suivre une recette parfaite, étape par étape, où rien ne tourne mal. Mais les humains réels sont imprévisibles. Nous sommes vagues, nous changeons d'avis, et nous avons besoin qu'on nous demande la permission avant que le robot ne dépense notre argent. Cet article s'aventure dans ce recoin désordonné de la recherche en IA pour poser une question simple mais difficile : nos meilleurs agents d'IA sont-ils capables de nous parler quand les choses se compliquent, ou s'effondrent-ils simplement lorsque les instructions ne sont pas parfaites ?

Les chercheurs derrière cette étude, dirigés par Junzhi Chen et Harsh Trivedi, ont décidé d'arrêter de tester les robots lors de journées parfaites et imaginaires pour commencer à les tester lors de journées qui ressemblent à la vraie vie. Ils ont construit un nouveau terrain de jeu appelé AppWorld-UL (User-in-the-Loop / Utilisateur dans la boucle). Voyez cela comme une immense ville numérique simulée avec neuf applications populaires comme Amazon et Spotify, mais avec un bémol : l'« utilisateur » (une personne simulée) fait partie du jeu, et le robot doit découvrir comment lui demander de l'aide.

L'équipe n'a pas seulement inventé des problèmes au hasard ; ils ont utilisé une méthode de « perturbation » ingénieuse. Imaginez qu'ils aient pris une tâche normale, comme « Retourne la chemise Nike que j'ai achetée la semaine dernière », puis qu'ils aient secrètement modifié le monde pour le rendre complexe.

Le piège du « Lequel ? » (Sous-spécification) : Ils ont fait en sorte que le robot trouve deux chemises Nike de la semaine dernière. Maintenant, le robot ne peut pas simplement deviner ; il doit s'arrêter et demander : « Laquelle voulez-vous retourner ? »
Le piège du « C'est parti ! » (Infaisabilité) : Ils ont fait disparaître la taille « Large » de la chemise du magasin. Le robot ne peut pas simplement échouer ; il doit dire à l'utilisateur : « La taille Large a disparu. Voulez-vous une autre taille ou un remboursement ? »
Le piège du « Attendez, c'est cher ! » (Confirmation) : Ils ont fait doubler le prix de la chemise. Le robot doit faire une pause et dire : « Hé, le prix a bondi ! Voulez-vous toujours l'acheter ? »

Pour s'assurer que le test soit équitable, ils ont créé un « utilisateur simulé » qui agit comme une vraie personne mais suit des règles strictes. Cet utilisateur connaît les réponses aux questions délicates mais ne les donnera pas à moins que le robot ne pose la bonne question. C'est comme un jeu de « 20 questions » où l'utilisateur ne répondra que si vous demandez exactement ce qu'il a en tête.

Lorsqu'ils ont placé les robots les plus intelligents du monde (comme Claude Opus 4.7 et GPT-5.5) dans cette ville numérique chaotique, les résultats ont été un véritable signal d'alarme. Même le meilleur robot n'a réussi qu'environ 48,6 % de l'ensemble des tâches. Lorsque les tâches devenaient encore plus difficiles, en combinant deux ou trois de ces situations délicates à la fois, le taux de réussite chutait à seulement 35,7 %.

L'étude suggère que le problème n'est pas que les robots ne savent pas utiliser les applications ; ils sont en fait plutôt doués pour cliquer sur des boutons. La véritable difficulté réside dans la conversation. Lorsque les chercheurs ont donné aux robots une « fiche de triche » contenant toutes les informations manquantes à l'avance (pour qu'ils n'aient pas à interroger l'utilisateur), le taux de réussite est passé à 78,1 %. Cela prouve que la difficulté vient de la nécessité d'interagir, et non de la complexité des applications elles-mêmes.

L'article a également révélé que lorsque les robots échouaient, c'était généralement parce qu'ils ne posaient pas les bonnes questions. Soit ils devinaient la réponse (hallucination), soit ils posaient des questions vagues qui confondaient l'utilisateur, soit ils oubliaient ce que l'utilisateur venait de leur dire. C'est comme un robot qui entend « Je veux la chemise rouge » mais qui achète ensuite la bleue parce qu'il a oublié de vérifier.

En résumé, cet article montre que si nos agents d'IA deviennent très bons pour accomplir des tâches, ils apprennent encore à être de bons partenaires de conversation. Ils doivent apprendre que parfois, la meilleure façon de résoudre un problème n'est pas de se précipiter, mais de s'arrêter, de regarder l'humain et de demander : « Attendez, laquelle vouliez-vous dire ? » Tant qu'ils ne maîtriseront pas cette danse de l'échange, ils seront peut-être prêts pour une simple course aux courses, mais ils ne sont pas encore tout à fait prêts à gérer le chaos d'une journée humaine réelle.

Résumé Technique : AppWorld-UL

Énoncé du Problème

Les benchmarks actuels pour l'évaluation des agents d'utilisation d'outils basés sur les LLM se concentrent largement sur des tâches entièrement spécifiées et autonomes, où les objectifs sont clairs, complets et fixes dès le départ. Cependant, la résolution de tâches numériques dans le monde réel est intrinsèquement « avec l'utilisateur dans la boucle » (user-in-the-loop) : les utilisateurs fournissent souvent des instructions vagues, sous-spécifiées ou même irréalisables, ce qui nécessite que les agents affinent l'intention de manière itérative par l'interaction. Les benchmarks interactifs existants ne parviennent pas à capturer la diversité et la complexité de ces interactions. Ils sont limités par :

Des types d'interaction étroits : La plupart restreignent les interactions à de simples questions de clarification, omettant des schémas critiques comme la gestion de l'infaisabilité ou la recherche d'approbation pour des actions à coût élevé.
Une simulation d'utilisateur déséquilibrée : Les travaux antérieurs oscillent entre des utilisateurs rigides, basés sur des règles (manquant de flexibilité) et des simulateurs de LLM non contraints (introduisant de l'instabilité et rendant l'attribution des échecs difficile).
Des environnements de petite taille : Beaucoup opèrent dans des environnements limités avec peu d'API, souvent sans changement d'état, échouant à tester la planification à long terme dans des systèmes complexes et dotés d'états.

Par conséquent, il manque un banc d'essai principled pour évaluer les agents qui doivent combiner efficacement l'utilisation d'outils avec une communication utilisateur diversifiée et adaptative.

Méthodologie

Les auteurs introduisent AppWorld-UL, un benchmark construit sur le cadre existant AppWorld (qui simule 9 applications populaires comme Amazon et Spotify avec environ 475 API). L'innovation centrale est une méthodologie basée sur la perturbation qui transforme systématiquement les tâches autonomes bien définies en variantes avec l'utilisateur dans la boucle.

1. Transformation de Tâche par Perturbation

Au lieu de construire des scénarios interactifs de toutes pièces, les auteurs modifient les tâches autonomes existantes en introduisant des lacunes spécifiques et connues dans l'instruction ( $I$ ) ou l'état initial ( $S_0$ ) qui ne peuvent être résolues que par l'interaction avec l'utilisateur. Cela crée un tuple de tâche $T = (I, S_0, E, K)$ , où $K$ est l'Ensemble de Connaissances de l'Utilisateur — des informations détenues exclusivement par l'utilisateur.

Les perturbations ciblent trois types d'interaction spécifiques :

Sous-spécification : Suppression de détails critiques (ex: « renvoyez la chemise que j'ai achetée la semaine dernière » alors que plusieurs chemises existent) pour forcer l'agent à interroger l'utilisateur pour clarification.
Infaisabilité : Modification de l'état ou des contraintes de sorte que l'objectif original est inatteignable (ex: l'article demandé est en rupture de stock), nécessitant que l'agent communique l'échec et propose des alternatives.
Recherche de Confirmation : Introduction de conséquences à coût élevé (ex: une hausse de prix) pour une action auparavant à faible risque, nécessant à l'agent de solliciter une approbation explicite avant de procéder.

Ces perturbations sont également composées pour créer des tâches nécessitant plusieurs types d'interaction simultanément.

2. Simulation d'Utilisateur Contrainte

Pour remédier à l'instabilité des simulateurs d'utilisateurs précédents, AppWorld-UL emploie un utilisateur basé sur un LLM contraint.

Limites de Connaissance : Le simulateur d'utilisateur est incité par un ensemble spécifique de paires questions-réponses ( $K$ ) dérivées du processus de perturbation.
Réponse Contrôlée : Le LLM utilisateur est instruit de répondre uniquement si la question de l'agent correspond à une paire dans $K$ . Si la question est hors de $K$ , l'utilisateur dévie ou redirige (ex: « Décidez-le vous-même »).
Fiabilité : Cette approche garantit la reproductibilité (en limitant les connaissances de l'utilisateur) tout en maintenant un flux conversationnel naturel, évitant la rigidité des systèmes basés sur des règles et l'imprévisibilité des LLM non contraints.

3. Évaluation Programmatique

Le benchmark introduit l'Achèvement de l'Objectif de Tâche Interactive (I-TGC) et l'Achèvement de l'Objectif de Scénario Interactive (I-SGC). Contrairement aux mesures standards, celles-ci incluent un test unitaire vérifiant que l'agent a réussi à obtenir toutes les informations nécessaires auprès de l'utilisateur (c'est-à-dire qu'il a posé toutes les questions de $K$ ). Cela permet d'évaluer la qualité de l'interaction (rappel des informations requises) parallèlement au succès de la tâche.

Principales Contributions

Cadre de Perturbation : Une méthode systématique pour générer des tâches diverses avec l'utilisateur dans la boucle en injectant des lacunes d'information spécifiques dans des tâches autonomes, permettant un contrôle précis sur les exigences d'interaction.
Benchmark AppWorld-UL : Un ensemble de données de 516 tâches exigeantes à travers 9 applications, comprenant :
- 306 tâches nécessitant exactement un type d'interaction (sous-spécification, infaisabilité ou confirmation).
- 210 tâches compositionnelles nécessitant des combinaisons de deux ou trois types d'interaction.
Simulateur d'Utilisateur Contraint : Un mécanisme de simulation robuste qui équilibre la flexibilité et la fiabilité de l'évaluation en définissant strictement les limites de connaissance de l'utilisateur.
Preuve Empirique : Démonstration que l'interaction correcte est un moteur primaire de la difficulté et du succès des tâches, distinct de la complexité de l'environnement.

Résultats Expérimentaux

Les auteurs ont évalué des agents de pointe (Agents de Code et Agents d'Appel de Fonctions) utilisant divers LLM de pointe (incluant Claude Opus 4.7, GPT-5.5, Qwen 3.7 Max, et d'autres).

Performance Globale : Même le système le plus performant (Agent de Code avec Claude Opus 4.7) n'a atteint que 48,6 % d'I-TGC et 30,2 % d'I-SGC sur l'ensemble du benchmark.
Difficulté Compositionnelle : La performance chute significativement sur les tâches compositionnelles, le meilleur système n'atteignant que 35,7 % d'I-TGC et 21,3 % d'I-SGC.
Corrélation d'Interaction : Il existe une forte corrélation entre la qualité de l'interaction et le succès de la tâche. Les agents performants ont atteint environ 100 % de rappel et 80-91 % de précision dans le fait de poser les questions requises, tandis que les agents ayant échoué présentaient des métriques drastiquement plus basses (37-40 % de rappel).
Étude d'Ablation :
- Connaissance Cachée : Lorsque le simulateur d'utilisateur refusait de fournir toute information, la performance s'effondrait (TGC : 12,8 %), confirmant que les agents ne peuvent pas résoudre ces tâches par le seul raisonnement environnemental.
- Connaissance Oracle : Lorsque toute la connaissance de l'utilisateur ( $K$ ) était fournie au préalable dans le prompt, la performance s'améliorait significativement (TGC : 78,1 %), indiquant que l'exigence d'interaction elle-même représente la majeure partie de la difficulté. Cependant, la performance restait inférieure à celle des tâches autonomes originales, suggérant des défis supplémentaires dans l'intégration d'informations fragmentées.

Signification

AppWorld-UL fournit un banc d'essai rigoureux pour faire progresser la recherche sur les agents d'utilisation d'outils avec l'utilisateur dans la boucle. L'article affirme que les modèles actuels éprouvent des difficultés substantielles avec les nuances de l'interaction réelle, telles que la reconnaissance de la sous-spécification, la gestion de l'infaisabilité et la recherche d'approbation. En isolant les exigences d'interaction de la complexité de l'environnement, ce benchmark révèle que la capacité à communiquer efficacement avec les utilisateurs est un goulot d'étranglement critique pour le déploiement des agents. Ce travail vise à soutenir le développement d'agents qui ne sont pas seulement capables d'utiliser des outils, mais qui se comportent comme des partenaires collaboratifs capables d'interroger, de confirmer et de s'adapter à l'intention de l'utilisateur dans des environnements numériques réalistes et dotés d'états.