Résumé technique : DSAgentBench

Énoncé du problème

La science des données en conditions réelles implique des flux de travail complexes à long terme qui s'étendent de la manipulation de données à l'exploration, la modélisation, la visualisation et la validation. Ces tâches nécessitent l'utilisation coordonnée de divers outils — notamment des notebooks, des IDE, des terminaux, des navigateurs et des bases de données — au sein d'un système d'exploitation fonctionnel. Bien que les progrès récents des grands modèles de langage (LLM) aient démontré des capacités de génération de code ou d'exécution de tâches analytiques isolées, les benchmarks existants ne parviennent pas à évaluer si les agents peuvent exécuter de manière autonome des flux de travail complets de science des données de bout en bout dans des environnements informatiques réalistes.

Les benchmarks actuels se répartissent en deux catégories : ceux qui évaluent la génération de code de manière isolée (par exemple, DS-1000, DSEval) sans nécessiter d'interaction avec le système, et ceux qui évaluent le contrôle général d'un ordinateur (par exemple, OSWorld, WebArena) sans évaluer le raisonnement analytique spécifique au domaine. Par conséquent, il existe un manque de cadres d'évaluation capables de tester la capacité d'un agent à naviguer dans les systèmes de fichiers, à gérer les dépendances, à interpréter les erreurs et à affiner les analyses sur la base de sorties intermédiaires au sein d'un environnement OS réel.

Méthodologie

Construction du benchmark (DSAgentBench)

Les auteurs introduisent DSAgentBench, le premier benchmark conçu pour évaluer les flux de travail autonomes de science des données à l'intérieur de véritables systèmes d'exploitation. Le benchmark se compose de 275 tâches diverses, rédigées par des humains, couvrant l'intégralité du cycle de vie de la science des données.

• Formulation des tâches : Les tâches sont définies comme des tuples $(C_i, I_i, V_i)$, où $C_i$ est la configuration initiale du système (jeux de données, structure de fichiers, bibliothèques installées), $I_i$ est une instruction en langage naturel, et $V_i$ est un évaluateur Python déterministe.
• Sourcing des données : Les jeux de données sont tirés de sources réelles hétérogènes, incluant Kaggle, OpenML, GitHub, des bases de données SQLite et des API web. Les données comprennent des modalités tabulaires (95,3 %), d'images (3,6 %) et de texte (1,1 %).
• Catégories de tâches : Les tâches sont organisées en six catégories de capacités : Acquisition de données, Analyse Exploratoire des Données (EDA), Ingénierie des caractéristiques (Feature Engineering), Modélisation, Évaluation/Déploiement, et Visualisation/Reporting.
• Protocole d'évaluation : Contra�à l'évaluation du code par les benchmarks classiques, DSAgentBench utilise des évaluateurs déterministes qui vérifient la justesse analytique, la qualité des sorties visuelles et la performance des modèles. Une tâche est considérée comme réussie uniquement si les sorties finales de l'agent satisfont aux critères de l'évaluateur (score $\ge 0,95$).
• Pipeline de construction : Le benchmark a été construit via un processus en trois étapes : sourcing des jeux de données, conception collaborative des tâches/évaluateurs par des experts humains (les LLM n'ayant été utilisés que pour l'affinement), et vérification par un double annotateur pour garantir la reproductibilité et la justesse technique.

Architecture de l'environnement

DSAgentBench étend le framework OSWorld pour créer un environnement d'exécution réaliste :

• OS : Ubuntu avec Python et les bibliothèques de science des données préinstallés.
• Outils : Visual Studio Code, Jupyter Notebook, Chrome, et accès aux API Kaggle/OpenML.
• Espace d'observation : Les agents reçoivent soit une capture d'écran 1920×1080, soit une modalité hybride Capture d'écran + Arbre d'Accessibilité (A11y), qui fournit des métadonnées d'interface structurées (rôles, boîtes englobantes, états d'interaction).
• Espace d'action : Les agents interagissent via des actions GUI (clics de souris, saisie clavier) et des méta-actions (WAIT, DONE, FAIL). L'environnement capture les transitions d'état après chaque action.

Modèles évalués

Les auteurs ont évalué 15 agents open-source et propriétaires, incluant :

• Propriétaires : GPT-4o, GPT-5 (et mini), O4-mini, Claude Sonnet 4/4.5/4.6, Gemini 2.5 Pro, et l'Agent Informatique d'OpenAI.
• Open-source : UI-TARS (2B/7B), GUI-OWL-7B, OpenCUA-72B, et des modèles hybrides (Jedi couplé à GPT-4o).

Résultats clés

Performance globale

Les expériences révèlent un écart de capacité substantiel entre les systèmes agentiques actuels et les exigences des flux de travail réels de science des données :

• Agent le plus performant : Claude-4.6-Sonnet a obtenu la meilleure performance avec 56,70 % de succès de tâche dans le cadre Capture d'écran + Arbre A11y.
• Autres modèles propriétaires : La performance chute considérablement pour les autres modèles, avec GPT-5 à 29,81 % et d'autres (GPT-4o, Gemini-2.5-Pro) oscillant autour de 20 %.
• Modèles open-source : Tous les agents open-source ont atteint moins de 1 % de succès, échouant fréquemment dans l'orchestration d'outils, l'ancrage dans l'OS (OS grounding) et le raisonnement multi-étapes.
• Référence humaine : Les experts humains ont atteint un taux de succès de 85,09 %, soulignant l'écart restant même pour les meilleurs agents IA.

Ablation et analyse des erreurs

• Complexité des tâches : La performance se dégrade de manière monotone avec la difficulté. Les tâches "difficiles" (plus de 5 étapes) restent les plus complexes. Les flux de travail multi-étapes (56,7 % des tâches) sont nettement plus difficiles que les tâches à étape unique en raison de la nécessité de maintenir l'état et de gérer la récupération d'erreurs.
• Utilisation des outils : Les tâches exécutées dans Jupyter Notebook ont mieux réussi que celles dans VS Code, principalement en raison de moins d'erreurs liées au terminal et à l'environnement.
• Modalité d'observation : L'ajout d'informations de l'arbre A11y a généralement amélioré la performance, suggérant que les métadonnées d'interface structurées aident l'ancrage, bien que les gains varient selon le modèle.
• Modes d'échec :
  • Les agents open-source ont échoué presque exclusivement (97–98 %) en raison d'erreurs d'ancrage (incapacité à aligner les instructions avec l'état du bureau).
  • Les agents propriétaires plus forts ont présenté des échecs mixtes, incluant des erreurs de terminal, des défauts de génération de code et des déficits de raisonnement.
  • Structure temporelle : Les modèles open-source et les modèles plus faibles échouent souvent tôt (incapacité à ouvrir les terminaux), tandis que les modèles plus forts ont tendance à échouer lors des étapes ultérieures après une exploration prolongée et inefficace.
• Sensibilité au budget : Augmenter le budget d'interaction de 15 à 50 étapes n'a produit que des gains marginaux (24,54 % $\to$ 25,81 %), indiquant que les échecs ne sont pas principalement dus aux limites d'étapes mais à des problèmes fondamentaux de planification et de raisonnement.

Signification et affirmations

L'article positionne DSAgentBench comme une ressource fondamentale pour développer des agents de science des données ancrés, vérifiables et autonomes. Ses principales contributions sont :

1. Premier benchmark en environnement OS réel : C'est le premier benchmark évaluant les flux de travail autonomes de science des données à l'intérieur d'un système d'exploitation fonctionnel, couvrant l'intégralité du cycle de vie, de l'acquisition des données à la validation.
2. Évaluation basée sur l'exécution : Il déplace le paradigme d'évaluation de la "justesse du code" vers la "justesse analytique", exigeant que les agents produisent des artefacts valides (visualisations, modèles, rapports) vérifiés par des scripts déterministes.
3. Révélation de l'écart : Les résultats exposent une limitation significative des systèmes agentiques actuels, démontrant que même les modèles les plus puissants peinent avec la coordination des outils, le raisonnement à long terme et l'ancrage dans l'OS requis pour la science des données réelle.
4. Direction future : En identifiant des modes d'échec spécifiques (ancrage, planification, orchestration d'outils), le benchmark fournit une feuille de route claire pour la recherche future visant à construire des agents capables d'accomplir des tâches de science des données réelles.

Les auteurs publient le benchmark à l'adresse https://github.com/vis-nlp/DSAgentBench pour faciliter la recherche ultérieure dans ce domaine.