Les agents de pointe ont terminé 30 % d’un flux de travail de recherche. C’est le chiffre qui compte.

Stanford dispose d’un nouveau benchmark appelé Terminal-Bench-Science 0.1, et son résultat phare est bien moins enthousiasmant que ne l’est habituellement le marketing autour des agents. Ce benchmark a soumis 70 flux de travail de recherche rédigés par des experts à des agents de pointe. Le meilleur d’entre eux en a achevé 30 %.

Trente pour cent, c’est le chiffre à retenir. Il ne se lit ni comme un échec ni comme un triomphe. C’est une mesure honnête de l’état actuel de la technologie, publiée par des personnes qui ont écrit les tâches à la main.

Ce que le benchmark teste réellement

Les tâches sont des flux de travail scientifiques, rédigés par des experts du domaine, et les agents s’exécutent dans un terminal. Ce choix compte. Un terminal est un environnement de travail où une tâche est réelle : il faut réellement installer la dépendance, écrire le fichier, lancer l’analyse et vérifier la sortie. Aucun crédit partiel n’est accordé pour avoir décrit la bonne approche. La commande fonctionne ou elle ne fonctionne pas.

Les flux de travail sont issus de la pratique de la recherche, une cible bien plus désordonnée qu’une tâche de programmation accompagnée d’une suite de tests bien propre. Un benchmark de programmation a généralement une réponse correcte définie, ce qui permet de le noter automatiquement. Le travail de recherche, lui, n’en a souvent pas, et c’est pourquoi construire un benchmark de ce type a exigé que des experts rédigent les tâches plutôt que de les extraire d’un dépôt.

Pourquoi 30 % est le bon cadrage

Les benchmarks ont tendance à être lus comme une réussite ou un échec. Un modèle qui obtient 90 à un benchmark de programmation est considéré comme presque résolu. Un modèle qui achève 30 % des flux de travail de recherche peut, dans le même esprit, être lu comme échouant la plupart du temps.

Cette lecture manque la fonction du chiffre. Un taux d’achèvement de 30 % sur des tâches d’experts rédigées à la main signifie que les agents peuvent gérer le tiers routinier du travail de recherche : configurer des environnements, exécuter des pipelines établis, nettoyer des données, produire des sorties standard. Les 70 % restants correspondent aux cas où la tâche exige un jugement que le flux de travail n’explicite pas, ou lorsqu’une étape casse d’une manière qui nécessite qu’un humain décide de la suite.

C’est une distinction utile. Elle indique à un laboratoire où orienter un agent aujourd’hui, et à un concepteur d’outils où se situe l’écart.

Le terminal est la partie intéressante

Faire tourner des agents dans un terminal est un choix délibéré pour les tester là où le travail se fait. Les logiciels de recherche sont en grande partie des logiciels en ligne de commande. Un modèle qui ne sait qu’utiliser une fenêtre de chat n’aide pas un laboratoire. Un modèle capable de s’installer dans un shell, de lire la documentation, d’installer une chaîne d’outils et de se remettre d’un échec de compilation appartient à une autre catégorie d’utilité.

C’est aussi là que les modes de défaillance sont les plus visibles. Un terminal ne masque pas une erreur. Lorsqu’une commande renvoie un message ambigu ou qu’un script ne s’exécute qu’à moitié, l’agent doit décider s’il réessaie, change d’approche ou s’arrête. Ce point de décision est l’endroit où se perd la majeure partie des 70 %, et c’est exactement le genre de chose qu’un benchmark de programmation doté d’une suite de tests propre ne fera jamais apparaître.

En quoi cela diffère des benchmarks de programmation

La comparaison évidente est avec les benchmarks de programmation, devenus la façon standard de vanter les progrès des agents. Un benchmark de programmation est généralement livré avec un dépôt et une suite de tests, de sorte que la réponse correcte est définie et que le score est automatique. Cela le rend peu coûteux à exécuter et facile à comparer, et c’est pourquoi ces chiffres dominent la conversation.

Les flux de travail de recherche résistent à ce traitement. Souvent, il n’existe pas de sortie correcte unique, et la qualité d’un résultat dépend d’un jugement sur ce qu’il faut mesurer et comment. C’est pourquoi les tâches présentées ici ont été rédigées par des experts plutôt que récupérées automatiquement depuis un dépôt, et pourquoi le benchmark rapporte un taux d’achèvement plutôt qu’un taux de réussite aux tests.

Le compromis est celui de la couverture contre le réalisme. Un benchmark de programmation peut être exécuté des milliers de fois par jour et produire un chiffre précis. Un benchmark de flux de travail est plus lent et plus bruité, mais il teste l’environnement où une grande part du travail technique se produit réellement. Les deux sont utiles, et un seul d’entre eux était largement disponible auparavant.

Pourquoi le chiffre est mesuré ainsi

L’achèvement est une mesure grossière, et les auteurs l’ont choisie à dessein. Un flux de travail se termine ou non, et c’est un fait qu’un observateur extérieur peut vérifier sans juger la qualité du résultat. L’élégance n’est pas notée. La justesse ne fait pas débat. L’agent a soit produit la sortie attendue par le flux de travail, soit il s’est arrêté avant.

Cette grossièreté est justement le but. Les benchmarks qui tentent de noter la qualité sur des tâches de recherche ouvertes ont tendance à se réduire au goût de leur auteur. En notant l’achèvement, celui-ci échange de la nuance contre de la reproductibilité. Deux laboratoires exécutant le même flux de travail obtiennent la même réponse, et c’est ce qui rend un chiffre digne d’être cité.

Le coût, c’est qu’il ne peut pas distinguer un agent qui a presque terminé d’un agent qui a échoué immédiatement. Les deux comptent comme des échecs. C’est une limite, et une future version pourra peut-être y remédier, mais un chiffre grossier sur lequel tout le monde s’accorde vaut mieux qu’un chiffre fin que personne ne croit.

Ce que le résultat dit du travail scientifique

Le benchmark est une réponse discrète à une affirmation bruyante : les agents feront bientôt de la recherche. Ce qu’il montre, c’est que les agents peuvent exécuter de la recherche, c’est-à-dire mettre en œuvre une procédure qu’un humain a déjà mise au point, sur une part croissante d’étapes routinières. Ils ne peuvent pas encore faire la partie où la procédure est inconnue et où quelqu’un doit l’inventer.

Cet écart n’est pas un petit détail d’ingénierie. Le travail routinier occupe une grande part du temps d’un scientifique, et l’automatiser permet d’économiser de l’argent et des heures bien réels. Ce n’est pas non plus la partie qui produit des découvertes. La distinction compte pour quiconque veut prévoir ce que l’IA fera à la science dans les prochaines années.

Comment lire ce genre de benchmark

Deux mises en garde s’appliquent à tout nouveau benchmark. La première concerne le numéro de version. Il s’agit de la 0.1, ce qui signifie que l’ensemble des tâches changera à mesure que les auteurs apprendront quelles tâches sont bien posées et lesquelles sont ambiguës. Les scores de versions différentes ne sont pas directement comparables.

La seconde est qu’un benchmark mesure les flux de travail que ses auteurs ont choisis. Soixante-dix tâches issues de domaines scientifiques constituent un échantillon, pas un recensement. Le chiffre de 30 % est un bon signal de la forme générale de la capacité des agents sur le travail de recherche. Ce n’est pas un nombre précis qui survivra à la prochaine révision.

Ce qu’il faut surveiller

Le progrès à surveiller n’est pas la hausse du pourcentage phare. C’est de savoir quelles tâches commencent à être réussies. Si les agents commencent à franchir des flux de travail qui exigent une récupération en plusieurs étapes, c’est une véritable avancée. Si le gain ne vient que des tâches plus faciles de configuration et de nettoyage de données, le plafond est plus bas que ne le suggère le titre.

Un benchmark qui rapporte honnêtement un chiffre faible est plus utile qu’un benchmark qui rapporte un chiffre élevé que personne ne peut reproduire. Celui-ci fait la première chose, et le domaine a besoin qu’on en fasse plus souvent autant.