Asuka-Bench: Benchmarking Code Agents on Underspecified User Intent and Multi-Round Refinement
L'article présente Asuka-Bench, un nouveau benchmark conçu pour évaluer les agents de code sur des tâches de développement web en simulant des cycles de raffinement multi-tours réels où les agents améliorent de manière itérative des projets sous-spécifiés à partir de tests d'interface utilisateur automatisés et de retours en langage naturel, révélant ainsi des écarts de performance significatifs parmi les modèles actuels.
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 engagiez un architecte brillant mais légèrement littéral pour construire une maison.
L'ancienne méthode (Benchmarks existants)
Par le passé, tester ces architectes revenait à leur donner un plan parfait de 50 pages listant chaque clou, chaque fil électrique et chaque couleur de peinture. Vous disiez : « Construisez ceci », et ils vous rendaient une maison terminée. Si la maison correspondait au plan, ils obtenaient un A. Si elle ne correspondait pas, ils obtenaient un F.
Le problème est que la vie réelle ne fonctionne pas ainsi. Les vrais clients n'ont que rarement un plan parfait de 50 pages. Ils disent généralement : « Je veux une maison avec une cuisine et un endroit pour dormir », puis, une fois qu'ils voient le premier jet, ils réalisent : « Oh, je voulais en fait que la cuisine soit plus grande », ou « Attendez, la porte s'ouvre du mauvais côté ».
La nouvelle méthode (Asuka-Bench)
Le document présente Asuka-Bench, une nouvelle façon de tester les « Agents de Code » (des programmes d'IA qui écrivent des logiciels). Au lieu de donner à l'IA un plan parfait, les chercheurs lui donnent une requête vague et désordonnée, du type : « Créez un site de vente en ligne avec une liste de produits et un panier. »
Ensuite, ils ne se contentent pas de noter le premier résultat. Ils mettent en place une équipe de trois personnes pour simuler un cycle de développement réel :
- Le Bâtisseur (Agent de Code) : C'est l'IA qui essaie de construire le site web en se basant sur la demande vague.
- L'Inspecteur (Agent d'Interface Utilisateur) : C'est un robot qui visite réellement le site web dans un navigateur. Il ne lit pas le code ; il agit comme un utilisateur humain. Il clique sur des boutons, essaie d'acheter des articles et vérifie si les pages se chargent. C'est comme un inspecteur de contrôle qualité qui parcourt la maison pour voir si les portes s'ouvrent.
- Le Client (LLM Utilisateur) : C'est une autre IA qui observe l'Inspecteur. Si l'Inspecteur trouve un problème (ex: « Le bouton "Acheter" ne fonctionne pas »), le Client traduit cela en une note polie pour le Bâtisseur : « Hé, le bouton est cassé. Merci de le réparer. »
Le Bâtisseur corrige ensuite le site web, et le cycle se répète. Cela se produit jusqu'à trois tours.
L'analogie du « DAG »
Les chercheurs ont également inventé une manière intelligente de donner des commentaires appelée DAG (Graphe Orienté Acyclique). Voyez cela comme une recette.
- Si vous essayez de faire un gâteau, vous ne pouvez pas le glacer avant de l'avoir cuit.
- Dans les anciennes méthodes de test, si le gâteau était brûlé, l'inspecteur pouvait aussi se plaindre que le glaçage manquait, même si vous ne pouviez pas glacer un gâteau brûlé.
- Avec Asuka-Bench, le système connaît l'ordre des étapes. Si l'étape de la « cuisson » échoue, le système empêche l'inspecteur de vérifier l'étape du « glaçage ». Il ne dit au Bâtisseur que : « Vous n'avez pas cuit le gâteau. » Cela évide que le Bâtisseur soit confus par des plaintes concernant des choses qui n'ont pas encore eu lieu.
Ce qu'ils ont découvert
Les chercheurs ont testé 8 modèles d'IA différents avec cette méthode. Voici ce qu'ils ont découvert :
- Certaines IA sont meilleures pour réparer que d'autres : Le fait qu'une IA soit douée pour construire le premier jet ne signifie pas qu'elle est douée pour corriger les erreurs. Certains modèles construisaient une excellente première version mais ne parvenaient pas à comprendre les notes du « Client » pour corriger les erreurs. D'autres commençaient de manière désordonnée mais s'amélioraient à chaque tour de feedback.
- L'écart est énorme : Les meilleurs modèles pouvaient achever environ 52 % des projets parfaitement après trois tours de correction. Les moins bons n'en achevaient que 8 %. C'est une différence massive.
- C'est toujours difficile : Même l'IA la plus intelligente n'a pas pu terminer chaque projet parfaitement. Cela montre que, bien que l'IA progresse, elle éprouve encore des difficultés avec la nature désordonnée et interactive des demandes humaines réelles.
En résumé
Asuka-Bench est un nouvel « examen du permis de conduire » pour les codeurs IA. Au lieu de leur demander de conduire une voiture sur une piste parfaitement droite et déserte (un plan parfait), on leur demande de conduire dans le trafic urbain, de recevoir des indications d'un passager lorsqu'ils font fausse route, et de corriger leur trajectoire. Il s'avère que être capable d'écouter et de corriger ses erreurs est une compétence totalement différente de celle de simplement savoir conduire en ligne droite.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.