WhatWorkedBench évalue si les agents d’IA peuvent anticiper les effets des changements expérimentaux

La question : l’agent comprend-il ce qui a provoqué un changement ?

Un agent de recherche peut exécuter du code, choisir des paramètres et communiquer un score. Mais ces actions ne suffisent pas, à elles seules, à montrer qu’il comprend comment la modification d’un composant influe sur le résultat. WhatWorkedBench propose de mesurer cette capacité au moyen de prédictions sur des changements expérimentaux : à partir d’un flux de travail et de ses options, l’agent peut-il anticiper les résultats que produiraient différentes configurations ?

Le projet se présente comme un benchmark de compréhension expérimentale. Au lieu d’évaluer uniquement si un agent accomplit une tâche ou obtient un score élevé, il lui demande de construire une réponse couvrant les configurations possibles d’un flux de travail. La mesure centrale porte donc sur la qualité de ses prédictions concernant les effets des changements, comparées à des résultats de référence.

Cette distinction est importante. Obtenir un score élevé pour une configuration ne prouve pas nécessairement que l’agent puisse expliquer quel composant en est à l’origine, ni prévoir ce qui se passerait si on le modifiait. À l’inverse, un agent pourrait estimer les effets de façon assez juste sans pour autant identifier la configuration optimale lorsque le nombre de nouvelles mesures est limité. Ces capacités sont liées, mais ne sont pas identiques.

Comment se déroule l’évaluation

Selon le résumé du préprint, les agents inspectent le code, choisissent les mesures à réaliser dans la limite d’un budget et produisent une surface de réponse : un tableau qui prédit le score de chaque configuration des composants. La tâche ne s’arrête donc pas à l’exécution d’une seule expérience ; l’agent doit extrapoler à partir des observations disponibles et représenter les variations possibles des résultats.

Pour établir les références, les auteurs exécutent de manière exhaustive les configurations sur CPU. Ils calculent ensuite l’effet de la modification de chaque composant en maintenant les autres fixes. Le résumé indique que l’analyse prend aussi en compte les combinaisons de changements entre composants. Cette référence permet de comparer les prédictions aux résultats observés pour l’ensemble des configurations.

Cette procédure fournit une base quantitative au benchmark, mais elle suppose que les exécutions exhaustives et les configurations définies représentent correctement chaque tâche. La comparaison renseigne sur ces flux de travail et ces options précis ; elle ne supprime pas l’incertitude qui peut apparaître lorsqu’on transpose les conclusions à d’autres codes, objectifs ou contextes expérimentaux.

Échelle et composition décrites dans le préprint

Le résumé du préprint fait état de 36 tâches, construites à partir de 30 sources de données et réparties entre huit types de flux de travail. Il décrit également 1 248 enregistrements de configuration. Pour l’évaluation principale, il mentionne 4 206 enregistrements de contrôle numérique couvrant les huit familles et 108 épisodes d’agents correspondant aux six familles initiales.

Ces chiffres désignent des unités différentes : les tâches, les sources de données, les types de flux, les configurations, les enregistrements de contrôle et les épisodes ne sont pas interchangeables. En particulier, le nombre d’épisodes ne doit pas être automatiquement interprété comme le nombre d’agents, pas plus que les enregistrements de contrôle ne doivent être assimilés à des expériences indépendantes menées par des agents. Les éléments disponibles ici ne donnent pas une ventilation complète de chaque chiffre par tâche.

Le dépôt public du projet est présenté comme une ressource complémentaire pour examiner les tâches, l’évaluateur, les contrôles numériques, les épisodes enregistrés, les guides et les tests. Il peut ainsi aider à vérifier la structure du projet et à repérer les éléments utiles à sa reproduction. Toutefois, l’existence d’un dépôt ne suffit pas à confirmer que tous les chiffres peuvent être reproduits sans dépendances, données ou conditions d’exécution supplémentaires.

Résultats rapportés et manière de les interpréter

Le résumé indique qu’avec huit nouvelles mesures, une méthode appelée « pair-effect ridge » a sélectionné une configuration optimale pour 15 des 22 sources. Il indique également que, pour trois sources, toutes les erreurs d’effet sont restées inférieures ou égales à 10 % de l’étendue des scores. Ces résultats concernent des sous-ensembles et des conditions précis ; ils ne signifient pas que la méthode ait trouvé l’optimum pour toutes les sources ni qu’elle ait respecté ce seuil d’erreur de manière générale.

Le travail compare aussi les prédictions ajustées par un processus gaussien aux observations recueillies par les agents. Dans la cohorte Flash initiale, la récupération des effets passe de 0,632 à 0,698 ; dans une cohorte supplémentaire, elle passe de 0,621 à 0,720. Le résumé présente également une analyse de six soumissions achevées pour des tâches de détection de battements et de graphes : l’ajustement du même type de modèle aux observations des agents fait passer la récupération macro par famille de 0,303 à 0,455.

Dans une autre analyse, consacrée à six flux de travail comportant chacun six options binaires et un budget de 20 nouvelles mesures, le fait d’encoder les équivalences de code — c’est-à-dire les configurations ayant un comportement identique — fait passer la récupération du processus gaussien de 0,248 à 0,462. L’interprétation raisonnable est que l’exploitation de la structure connue du programme peut améliorer les prédictions dans ce scénario. Ces chiffres ne permettent pas de conclure que la même hausse se reproduirait dans d’autres flux de travail ou avec d’autres budgets.

Les comparaisons citées dépendent des métriques, des cohortes et des épisodes définis dans l’étude. Ces chiffres constituent des éléments probants pour ce protocole expérimental, et non un classement universel des agents. Pour évaluer les différences entre systèmes, il faudrait également connaître les modèles testés, leur mode de sélection et la répartition des tâches.

Ce qui manque pour évaluer les modèles et la reproductibilité

Le résumé disponible fournit des chiffres agrégés et nomme certaines méthodes, mais il ne précise pas ici le nom de tous les agents et modèles évalués, ni l’ensemble de leurs résultats comparatifs. Il ne suffit pas non plus à reconstituer les paramètres, les partitions, les conditions d’exécution ou les étapes exactes de chaque analyse. Le préprint complet est indiqué comme la source permettant de consulter le protocole et les modèles, tandis que le dépôt contient, d’après sa description, des ressources de mise en œuvre et de reproduction.

L’indication selon laquelle les références proviennent d’exécutions exhaustives sur CPU décrit la manière dont les effets de référence ont été obtenus. Pour les reproduire, il faudrait vérifier dans le code et les journaux quelles configurations ont été exécutées, comment les métriques ont été calculées et quelles données ou dépendances sont requises pour chaque tâche. Il ne faut pas supposer qu’une exécution exhaustive sur un espace de configurations défini équivaut à explorer toutes les interventions possibles dans un problème scientifique réel.

Le travail est présenté comme la version 1 d’un préprint sur arXiv. Les informations fournies ne documentent pas de processus d’évaluation par les pairs. Il est donc plus juste de le considérer comme une recherche préliminaire diffusée publiquement, et non comme un résultat déjà validé par une publication évaluée par les pairs. Cette situation n’invalide pas le benchmark, mais elle compte lorsqu’on évalue le degré de confiance à lui accorder et qu’on attend des confirmations indépendantes.

Conclusion : un outil circonscrit pour étudier les agents expérimentaux

WhatWorkedBench s’attaque à une question précise et utile : après un nombre limité de mesures, un agent peut-il anticiper les effets des changements apportés aux composants de flux expérimentaux ? Son protocole traduit cette question en prédictions comparables à des références obtenues par exécution exhaustive, et l’étude rapporte, dans certains scénarios, des améliorations associées aux méthodes d’ajustement et à l’utilisation des équivalences de code.

La portée des conclusions doit rester liée au benchmark. Prédire correctement une surface de réponse pour des tâches définies ne revient pas à formuler des hypothèses scientifiques, à choisir des problèmes pertinents, à reconnaître des résultats fallacieux ou à mener des recherches de manière autonome. Cela ne permet pas non plus de prévoir les performances sur des flux de travail qui ne figurent pas parmi les tâches évaluées.

Pour les lecteurs qui suivent l’évaluation des systèmes d’IA, l’apport principal est une manière plus précise de demander ce qu’un agent sait faire : non seulement s’il obtient un résultat, mais aussi s’il peut prédire comment celui-ci variera lorsque des composants de la procédure changent. Les chiffres rapportés sont encourageants dans certaines analyses, mais une comparaison complète des modèles, une reproduction indépendante et l’évaluation du travail par les pairs restent importantes pour en déterminer la portée.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.