WebArena : le benchmark de 812 tâches qui mesure ce que les agents web peuvent et ne peuvent pas réellement faire

Le benchmark de 812 tâches de WebArena est le prédécesseur direct de WorkArena, que j'ai abordé hier. Les lire l'un après l'autre clarifie une distinction clé : WorkArena mesure le travail intellectuel en entreprise sur une seule plateforme (ServiceNow), tandis que WebArena établit le plancher de capacité général des agents web sur des logiciels ouverts et réalistes. Je veux comprendre ce plancher avec précision avant de réfléchir aux agents Beancount qui finiront par opérer dans des environnements de navigation.

L'article

Zhou et al. (ICLR 2024, arXiv:2307.13854) introduisent WebArena, un benchmark reproductible de 812 tâches réparties sur quatre sites web auto-hébergés : une boutique en ligne Magento, un forum social Postmill, une instance GitLab et un portail d'administration CMS Magento, complétés par un miroir OpenStreetMap et une copie hors ligne de Wikipédia. Contrairement aux tâches synthétiques et simplistes de MiniWoB++, chaque site de WebArena exécute de véritables logiciels open-source avec une échelle authentique : environ 90 000 produits, 95 sous-reddits avec plus de 127 000 publications et 300 dépôts Git répartis sur 1 000 comptes de développeurs. Les tâches couvrent trois catégories — recherche d'informations, navigation sur le site et modifications de contenu/configuration — et sont évaluées sur la correction fonctionnelle : si le résultat escompté apparaît dans la base de données ou correspond à une réponse exacte/floue, et non si l'agent a suivi la séquence d'actions attendue.

Idées clés

• GPT-4 atteint 14,41 % ; les humains atteignent 78,24 %. L'écart est de 63,8 points de pourcentage. GPT-3.5 obtient un score de 8,75 %, et la référence Google Text-Bison-001 ne marque que 5,05 %. Le prompting par chaîne de pensée (Chain-of-thought) ajoute environ 2,3 points pour GPT-4 — utile, mais pas transformateur.
• L'échec le plus courant est la fausse impossibilité. GPT-4 a incorrectement qualifié environ 54,9 % des tâches réalisables (428 sur 812) d'infaisables, renvoyant [N/A] au lieu de les tenter. C'est le mode d'échec dominant, bien avant les séquences d'actions bruitées ou les erreurs d'outils.
• Correction fonctionnelle, et non rejeu de trajectoire. L'évaluation vérifie quatre types de preuves : correspondance exacte, vérification de mots-clés obligatoires, correspondance floue basée sur un LLM et validation programmatique via des requêtes de base de données ou du JavaScript. Cela rend la métrique robuste à la paraphrase mais toujours sensible aux spécifications de tâches ambiguës.
• L'auto-hébergement conteneurisé permet la reproductibilité. Les quatre sites sont livrés sous forme de conteneurs Docker, ce que les benchmarks ultérieurs (WorkArena, OSWorld) reproduisent. Vous pouvez réinitialiser l'état et garantir des conditions de départ identiques, ce qui est impossible avec du web scraping en direct.
• Les modèles de tâches évitent la mémorisation aveugle. 241 modèles génèrent 812 tâches instanciées (3,3 variantes chacune), ce qui aide un peu mais n'empêche pas un modèle déterminé d'apprendre les motifs des modèles plutôt que les principes de navigation web.
• La complexité réelle du DOM est supérieure de plusieurs ordres de grandeur à celle de MiniWoB++. Une page typique de WebArena se sérialise en milliers de jetons ; des travaux connexes rapportent des arbres DOM dépassant les 100 000 jetons pour des vues de portail complexes.

Ce qui tient la route — et ce qui ne la tient pas

La méthodologie de base est solide : de vrais logiciels, une évaluation basée sur les résultats et des environnements reproductibles sont exactement ce qu'il faut. Le chiffre de 14,41 % s'est avéré durable à travers des reproductions indépendantes, et la taxonomie des échecs (fausse infaisabilité, comportements en boucle, refus timide) a été confirmée par plusieurs articles ultérieurs.

Les limites sont cependant réelles. Premièrement, 812 tâches dérivées de 241 modèles signifient que le benchmark est fini et peut être couvert systématiquement ; un agent qui mémorise les structures des modèles pourrait faire du surapprentissage sans généraliser. WebArena Verified (2024–2025) a découvert et réparé des vérifications d'évaluation mal alignées, ce qui signifie qu'une partie du chiffre original de 14,41 % peut refléter un bruit d'évaluation plutôt qu'une pure capacité. Deuxièmement, les quatre types de sites web — e-commerce, forum, hébergement de code, CMS — sont plausibles mais ne constituent pas un échantillon raisonné du web. Il n'y a pas de SaaS d'entreprise, pas de portail gouvernemental lourd en formulaires, pas d'interface bancaire. Troisièmement, le benchmark ignore totalement la sécurité et la fiabilité : un agent qui réussit à « supprimer ce message » obtient le même score qu'il supprime le bon message ou dix autres. ST-WebAgentBench (2024) a été spécifiquement conçu pour combler cette lacune.

Le constat de fausse infaisabilité est le résultat le plus intéressant et le moins apprécié. Il suggère que les LLM sont calibrés pour éviter l'action en cas d'incertitude — un a priori raisonnable pour des modèles entraînés sur des retours humains — mais que ce calibrage conservateur est précisément inadapté pour des tâches d'agents où ne pas agir est en soi une erreur coûteuse.

Pourquoi cela est important pour l'IA financière

L'écart entre 14,41 % et 78,24 % calibre directement ce qu'un agent de navigation Beancount peut accomplir aujourd'hui sans ingénierie spécialisée. Si GPT-4 ne peut pas accomplir de manière fiable des tâches web de routine — commander un produit, créer un ticket GitLab, publier sur un forum — on ne peut certainement pas lui faire confiance pour naviguer dans l'interface web de Fava sans supervision. Ce n'est pas un message de désespoir ; cela motive la création d'interfaces dédiées et d'espaces d'action structurés, comme SWE-agent l'a démontré pour l'édition de code. La leçon à retenir est que la capacité brute du LLM mesurée sur des tâches génériques n'est pas ce qui importe ; ce qui importe, c'est à quel point l'environnement est conçu pour soutenir l'agent.

Le problème de la fausse infaisabilité a un analogue direct en comptabilité : un agent qui répond « je ne peux pas déterminer si cette transaction est un doublon » au lieu de vérifier échoue exactement de la même manière conservatrice mais erronée. Les agents ayant une capacité d'écriture ont besoin d'une étape explicite de vérification de faisabilité qui force l'engagement plutôt que l'abstention, associée à des filets de sécurité de type « rollback » afin qu'un engagement incorrect soit récupérable.

Pour Beancount spécifiquement, la partie CMS + portail d'administration de WebArena (Magento admin) est l'analogue structurel le plus proche de l'interface web de Fava : une interface d'administration multipage avec des formulaires complexes, une navigation imbriquée et un état qui persiste entre les sessions. Le plafond de 14,41 % sur cette classe de tâches est ce que je devrais considérer comme l'hypothèse par défaut jusqu'à ce que nous démontrions quelque chose de mieux.

Lectures complémentaires

• VisualWebArena (Koh et al., 2024, arXiv:2401.13649) — étend WebArena aux agents multimodaux utilisant des captures d'écran, ce qui est important pour Fava car tout l'état pertinent n'est pas dans le DOM.
• OSWorld (Xie et al., NeurIPS 2024, arXiv:2404.07972) — benchmark d'environnement de bureau complet ; 12,24 % pour le meilleur modèle multimodal contre 72,36 % pour l'humain, étendant l'écart de capacité à l'automatisation de l'interface graphique au-delà du navigateur.
• ST-WebAgentBench (arXiv:2410.06703) — traite directement la lacune de sécurité dans WebArena, en mesurant si les agents web respectent les contraintes de politique tout en accomplissant les tâches.