Un pas de plus vers l’Explosion d’Intelligence : Les agents IA d’OpenAI peuvent désormais reproduire la recherche en IA

OpenAI vient de publier un article scientifique qui démontre que des agents d’IA peuvent reproduire des recherches de pointe en intelligence artificielle. Si l’on pousse cette logique à sa conclusion naturelle, cela signifie que les agents seront bientôt capables de s’auto-améliorer. C’est une avancée majeure qui nous rapproche du concept d’ »explosion d’intelligence » théorisé par Leopold Dasher Brener.

Présentation de PaperBench : Évaluer la capacité des IA à reproduire la recherche en IA

Plongeons directement dans l’introduction de cette étude fascinante. L’article affirme que « les agents d’IA capables de reproduire de manière autonome des articles de recherche en machine learning pourraient accélérer les progrès en apprentissage automatique ». Imaginez : des agents d’IA non seulement capables de reproduire les résultats d’autres articles, mais aussi de découvrir de nouvelles innovations en machine learning, de les appliquer à eux-mêmes, puis d’itérer infiniment sur ces améliorations.

C’est précisément ce que Leopold Dasher Brener a appelé « l’explosion d’intelligence ». À ce stade, lorsque l’IA sera capable de découvrir des moyens de s’auto-améliorer, les capacités de ces modèles vont littéralement exploser. Les chercheurs d’OpenAI reconnaissent eux-mêmes que c’est à la fois « excitant mais nécessite également une étude attentive pour garantir que les capacités de l’IA soient développées en toute sécurité ».

C’est exactement l’objectif de PaperBench.

Qu’est-ce que PaperBench exactement ?

PaperBench peut être considéré comme un framework d’agents conçu pour prendre un article de recherche, écrire et exécuter du code afin de reproduire les résultats de cet article. Ces agents d’IA ont accès :

Au web

À des terminaux bash
À des environnements Python
À la possibilité de parcourir les articles page par page

Si vous avez déjà utilisé Manis AI, ce fonctionnement devrait vous sembler familier.

Le processus est simple en théorie : on présente à l’agent le contenu de l’article et on lui demande de reproduire les contributions empiriques de l’article. L’agent dispose de tous les outils nécessaires – navigation web, écriture et exécution de code – pour accomplir cette tâche. Bien que cela puisse sembler simple, la mise en œuvre et la mesure précise des résultats sont extrêmement complexes.

Qu’implique la reproduction d’un article scientifique ?

Reproduire un article scientifique implique plusieurs étapes complexes :

Comprendre l’article en profondeur
Développer une base de code à partir de zéro pour implémenter toutes les expériences
Exécuter, surveiller et dépanner ces expériences selon les besoins

En général, chaque tâche de reproduction est extrêmement difficile et nécessite, au minimum, plusieurs jours de travail pour des experts humains. Aujourd’hui, nous avons des agents qui peuvent le faire en quelques heures seulement.

La structure de PaperBench

Le benchmark PaperBench comprend 20 articles de recherche récents dans le domaine du machine learning. Ces articles couvrent 12 sujets différents issus de l’ICML (International Conference on Machine Learning), notamment :

L’apprentissage par renforcement profond

La robustesse
Les méthodes probabilistes

Chaque article du benchmark est accompagné d’une grille d’évaluation créée manuellement. Les chercheurs ont travaillé avec les auteurs de chaque article pour créer ces grilles, garantissant ainsi la qualité et l’efficacité du benchmark. Ces grilles spécifient en détail tous les résultats nécessaires pour reproduire l’article.

Un aspect remarquable : la collaboration avec les auteurs originaux

Un élément particulièrement intéressant est que chaque grille d’évaluation de PaperBench a été co-développée avec l’un des auteurs originaux de l’article. Cela garantit une évaluation de haute qualité et précise lors de l’évaluation de la reproduction.

Noter ces articles de machine learning n’est pas une tâche facile – il faut des dizaines d’heures à un expert humain pour évaluer un seul article. C’est pourquoi les chercheurs ont développé un « juge LLM » pour cette tâche. Ils ont également élaboré des critères d’évaluation pour ce juge, abordant ainsi tous les aspects du framework.

Les chercheurs expliquent : « Nous explorons des juges basés sur les LLM et introduisons un juge d’évaluation auxiliaire (EvalJudge) qui compare les sorties des juges automatisés à un ensemble de données d’étiquettes de référence provenant de juges experts humains. »

Les modèles testés et leurs performances

On pourrait penser qu’OpenAI, en publiant cet article, mettrait en avant les performances supérieures de ses propres modèles. Mais ce n’est pas nécessairement le cas. Ils ont testé plusieurs modèles différents avec ce framework, rendant le framework agnostique au modèle, et ont observé leurs performances.

Il est important de noter que l’intelligence brute de ces modèles est incroyable et probablement suffisante pour la majorité des tâches que les humains peuvent imaginer. Ce qui transforme réellement ces modèles d’une simple intelligence en quelque chose d’agentique capable d’accomplir des tâches du monde réel, c’est l’échafaudage qui les entoure. Cet échafaudage, également connu sous le nom d’agents ou de frameworks agentiques, leur donne des outils, la capacité d’écrire et d’exécuter du code, de rechercher sur le web, d’avoir une mémoire – essentiellement tout le code déterministe écrit autour des LLM bruts.

Le meilleur juge basé sur LLM utilise GPT-3.5 Mini avec un échafaudage personnalisé (pensez simplement à un agent) et atteint un score F1 de 0,83 sur l’évaluation auxiliaire, ce qui suggère que ce juge est un substitut raisonnable à un juge humain.

Le modèle le plus performant : une surprise

Le modèle le plus performant dans cette étude était en fait Claude 3.5 Sonnet d’Anthropic, et non un modèle d’OpenAI. Ils ont également testé Claude 3.7, mais il n’a pas réussi à terminer les tests en raison de limites de taux d’API que je détaillerai plus tard.

Notablement, ils n’ont pas testé Gemini 2.5 Pro de Google, ce qui aurait été intéressant car, selon l’expérience de l’auteur, Gemini 2.5 Pro est de loin la meilleure IA de codage disponible actuellement.

Le flux de travail de PaperBench

Examinons comment fonctionne réellement le flux de travail de PaperBench :

L’article est donné à l’agent
L’agent commence à travailler, avec ses pensées et son utilisation d’outils visibles :
Lecture de l’article

Écriture du code initial
Exécution d’expériences avec les paramètres v1

Ce processus est très similaire à celui de Manis AI. Il crée un environnement, peut lire et écrire des fichiers dans cet environnement, et peut écrire et exécuter du code.

C’est pourquoi les récentes avancées en apprentissage par renforcement qui continuent d’améliorer ces modèles pour le codage sont si excitantes. Les modèles de codage semblent être les types de modèles les plus importants actuellement, car si vous pouvez écrire du code, vous pouvez pratiquement tout faire.

De plus, l’exécution du code offre une récompense vérifiable – si vous écrivez du code et que vous recherchez un certain résultat, vous pouvez facilement vérifier si ce résultat est atteint. Cette vérification sert de récompense pour améliorer le modèle en matière de codage, et elle ne nécessite pas d’humain dans la boucle, ce qui la rend essentiellement infiniment évolutive dans cette boucle de rétroaction de récompense.

Lorsque l’agent a terminé d’écrire tout le code, il exécute un script reproduce.sh qui lance tous les fichiers et tente de reproduire les résultats de l’article. Les résultats sont ensuite soumis au juge pour évaluation. Le système de notation n’est pas simplement réussite ou échec, mais utilise un mécanisme d’évaluation sophistiqué que nous allons détailler.

Résultats préliminaires

Claude 3.5 Sonnet avec un simple échafaudage agentique a obtenu un score de 21% sur PaperBench. Ce n’est pas extraordinaire, mais c’est tout de même impressionnant pour une première itération.

Sur un sous-ensemble de trois articles, la référence humaine (des doctorants en machine learning, meilleur des trois tentatives) a atteint 41,4% après 48 heures d’effort, contre 26,6% atteints par GPT-4o sur le même sous-ensemble. C’est très intéressant – déjà environ la moitié du score des doctorants humains.

Comme l’a souvent souligné l’auteur, c’est le pire que l’IA sera jamais.

Détails de la tâche et méthodologie

Comment fonctionne exactement cette tâche ? L’agent évalué reçoit l’article et un addendum de clarifications. Le candidat doit produire une soumission qui consiste en un dépôt comprenant tout le code nécessaire pour reproduire les résultats empiriques de l’article. Ce code doit être dans un fichier appelé reproduce.sh à la racine du dépôt, qui sert de point d’entrée pour exécuter tout le code nécessaire à la reproduction des résultats.

Restrictions importantes pour garantir l’originalité

Un aspect crucial : bien que l’agent ait accès à la recherche web, il ne devrait pas pouvoir simplement se rendre sur le site web de l’auteur de l’article et télécharger leur code (car généralement, les auteurs incluent leur code sur leur site). Il existe donc une liste noire de sites web que l’agent n’est pas autorisé à visiter pour chaque article de PaperBench.

L’agent peut naviguer sur le web, mais il ne peut pas simplement télécharger le code de recherche existant. Cela garantit que l’on mesure la capacité des agents à coder et à exécuter des expériences complexes à partir de zéro, plutôt que leur capacité à utiliser du code de recherche existant.

Processus de reproduction et d’évaluation

Une soumission n’est considérée comme ayant reproduit un résultat que lorsque ce résultat est reproduit en exécutant la soumission dans une configuration fraîche. Voici quelques détails sur cet environnement :

La soumission est copiée dans une nouvelle VM exécutant une image Ubuntu 24.04 avec accès à un GPU A10
Le script de reproduction de la soumission est exécuté pour générer des résultats à partir d’un démarrage propre

Le dossier de soumission mis à jour qui en résulte est appelé « soumission exécutée »

Système de notation sophistiqué

L’évaluation de la reproduction est probablement la partie la plus difficile de tout ce processus. Comment savoir si la reproduction est précise, et à quel point elle l’est ?

Chaque article du benchmark est accompagné d’une grille qui spécifie les critères d’évaluation pour une réplication complète. Cette grille est rédigée par l’un des co-auteurs principaux de l’article, garantissant ainsi sa précision.

Le système de notation ressemble à un arbre. Au sommet, nous avons réussite ou échec. En descendant l’arbre avec tous les nœuds, il note des parties de plus en plus granulaires de l’article. Plutôt que de simplement dire « oui, ils ont pu reproduire l’article » ou « non, ils n’ont pas pu », c’est plus comme « ont-ils pu reproduire cette partie spécifique ? » puis cette partie plus grande, et ainsi de suite.

C’est donc un sous-ensemble dans un sous-ensemble dans un sous-ensemble, et chacun d’eux est noté. Les scores des enfants sont moyennés, puis la moyenne est attribuée au parent. Le parent remonte ensuite à son parent, et ainsi de suite. Le nœud supérieur reçoit le score moyen global d’achèvement.

Types de critères d’évaluation

Chaque nœud feuille a l’un des trois types d’exigences possibles :

Correspondance de résultat : évalue si la soumission exécutée contient des preuves de la reproduction d’un résultat particulier de l’article
Exécution : évalue si un résultat d’exécution particulier s’est produit lors de l’exécution du script reproduce.sh
Développement de code : évalue si le code source du candidat semble contenir une implémentation correcte de certaines exigences

Pourquoi OpenAI a-t-il décidé de diviser l’évaluation de cette façon ? N’auraient-ils pas pu simplement tester l’ensemble pour voir s’il était précis ou non ?

Il aurait été possible d’avoir une grille composée uniquement de nœuds de correspondance de résultats, puisque la correspondance des résultats reproduit l’article par définition. Cependant, ils incluent des nœuds d’exécution et de développement de code pour attribuer un crédit partiel à la réalisation de résultats, garantissant ainsi que les performances des agents sur PaperBench s’améliorent progressivement.

Cela rappelle les récompenses basées sur le processus par rapport aux récompenses basées sur les résultats. Les récompenses basées sur les résultats récompensent un modèle pour avoir obtenu une solution correcte ou incorrecte. Peu importe s’il a réussi 9 étapes sur 10 et échoué à la dernière – dans une récompense basée sur les résultats, la récompense n’est pas là, c’est un échec.

En revanche, avec les récompenses basées sur le processus, chaque étape est récompensée séparément. Si le modèle réussit 9 étapes sur 10 mais échoue à la dernière, la solution entière n’est pas correcte, mais il a tout de même réussi ces 9 étapes et apprend que ces premières étapes étaient réellement bonnes et précises. Il apprend à les refaire, il apprend qu’il a été récompensé pour celles-ci.

Intuitivement, cela semble beaucoup plus logique. Lorsque nous notons le travail humain, nous disons généralement : « Tu as réussi toutes ces étapes, mais tu t’es trompé sur celle-ci, alors améliorons celle-là, mais n’oublie pas que tu as réussi celles-ci, alors continue comme ça. » C’est donc très humain, et c’est ce qu’ils ont fait avec PaperBench.

Règles et contraintes du benchmark

Examinons les règles que les agents doivent suivre pour qu’une soumission soit valide :

Agnosticisme du framework : PaperBench est conçu pour être agnostique à l’échafaudage de l’agent. Non seulement PaperBench est agnostique au LLM sous-jacent (vous pouvez brancher n’importe quel LLM), mais aussi à l’échafaudage de l’agent.
Restrictions web : L’agent peut naviguer sur Internet, mais des listes noires par article existent. L’agent ne peut pas simplement télécharger le code de l’auteur et l’exécuter, car c’est de la triche. La liste noire pour chaque article inclut le propre dépôt de code de l’auteur et toute autre réplication en ligne.
Ressources disponibles : Les ressources disponibles pour l’agent, comme le temps d’exécution et la puissance de calcul, ne sont pas restreintes. Vous pouvez utiliser n’importe quel environnement.

Clés API : Les développeurs doivent fournir aux agents des clés API pour les services en ligne nécessaires, comme HuggingFace. L’obtention d’accès à des comptes en ligne ne fait pas partie des compétences que PaperBench vise à évaluer.

Considérations de coût

L’exécution de PaperBench est assez coûteuse. Ces agents peuvent fonctionner pendant 12 heures, et ce coût s’accumule rapidement. Imaginez un agent traitant des centaines et des centaines de tokens pendant 12 heures – nous parlons de centaines de dollars.

Pour réduire ces coûts, ils ont créé PaperBench CodeV. Cette version réduit la tâche d’évaluation au seul développement de code, en ignorant l’accent mis sur l’exécution du code pour vérifier que les résultats sont reproduits. Cela élimine le besoin de matériel GPU coûteux généralement nécessaire pour les déploiements d’agents et l’étape de reproduction dans PaperBench.

Ils réduisent également le coût de la notation. Avec GPT-3.5 Mini comme juge, ils constatent que le coût de la notation est réduit d’environ 85%.

Dans le grand schéma des choses, si nous parlons de 1 000 $ pour reproduire un article, puis peut-être quelques milliers ou dizaines de milliers de dollars pour qu’un agent écrive éventuellement son propre article, cela semble trivial. N’importe quelle entreprise serait prête à financer cela si cela signifiait une intelligence artificielle auto-améliorante.

Création des grilles d’évaluation et juges LLM

Comme mentionné, chaque grille a été créée avec l’un des co-auteurs principaux de l’article et a pris plusieurs semaines par article, de la lecture initiale à la création, en passant par la révision, l’itération et l’approbation finale. Avec 20 articles, on peut imaginer le temps considérable que cela a pris.

La notation manuelle par des experts humains prenait des dizaines d’heures par article, ils avaient donc besoin d’une méthode automatisée – c’est là qu’intervient le juge LLM. Fait important, ils s’attendent à ce que la qualité des juges automatisés s’améliore avec le temps.

Voici comment fonctionne l’implémentation du juge LLM :

Pour un nœud feuille spécifique, le juge reçoit le markdown de l’article, le JSON complet de la grille, l’exigence du nœud feuille et la soumission. Comme la soumission complète est souvent trop longue pour tenir entièrement dans le contexte d’un modèle, ils filtrent la base de code en faisant classer les fichiers par pertinence par le juge et n’incluent que les 10 meilleurs fichiers dans son contexte – essentiellement un système RAG.

Ils estiment que leur juge utilisant GPT-3.5 Mini coûte environ 66 $ en crédits API OpenAI pour noter une seule soumission – un coût négligeable pour la valeur créée. Pour PaperBench CodeV, le coût tombe à environ 10 $ par article. Leur juge LLM est significativement moins cher et plus rapide que l’embauche d’un expert humain pour la notation.

Résultats des tests de modèles

Ils ont évalué GPT-4o, GPT-4 (01), GPT-3.5 Mini, DeepSeek R1, Claude 3.5 Sonnet et Gemini 2.0 Flash. Comme mentionné précédemment, il manque notablement Gemini 2.5 Pro et Claude 3.7 Sonnet.

Ils voulaient tester Claude 3.7 Sonnet mais n’ont pas pu terminer les expériences en raison des limites de taux avec l’API Anthropic. Ils accordent aux agents un temps d’exécution maximum de 12 heures, et ils se heurtaient constamment à des limites de taux, donc ils n’ont pas pu tester la version 3.7.

Les performances les plus prometteuses étaient celles de Claude 3.5 Sonnet avec 21%. GPT-4 (01) a obtenu des performances plus faibles avec 13,2%, et les autres modèles testés ont obtenu de mauvais résultats avec des scores inférieurs à 10%.

Pourquoi ces performances variées ?

À l’exception de Claude 3.5 Sonnet, les autres modèles terminaient souvent tôt, affirmant qu’ils avaient soit terminé toute la réplication, soit rencontré un problème qu’ils ne pouvaient pas résoudre. Tous les agents ont échoué à élaborer une stratégie sur la meilleure façon de reproduire l’article compte tenu du temps limité dont ils disposaient.

Ils ont observé que GPT-3.5 Mini avait fréquemment des difficultés avec l’utilisation des outils. Ce sont tous des problèmes liés aux agents – les frameworks agentiques eux-mêmes s’amélioreront, la capacité des modèles à utiliser des outils s’améliorera. C’est pourquoi l’auteur est si enthousiaste à propos de certains de ces nouveaux modèles qui intègrent l’appel de fonctions et la formation aux outils. Il semble que chaque jour qui passe, ce type de capacité devient beaucoup plus important dans ces modèles.

Ils affirment toujours que « ces modes d’échec suggèrent une faiblesse des modèles actuels dans la capacité à mener des tâches à long horizon ». Bien que des projets comme DeepResearch puissent suggérer des progrès, nous sommes encore loin de pouvoir donner une tâche à un agent et qu’il puisse simplement l’accomplir sans aucune intervention humaine sur une longue période.

L’auteur a utilisé Manis assez souvent – parfois avec succès, mais souvent le système échoue.

Le rôle crucial des frameworks agentiques

La partie la plus importante de leurs conclusions : « Nous pensons que des travaux supplémentaires sur les échafaudages agentiques conduiraient à de meilleurs résultats sur PaperBench. » Cela signifie que ce sont les frameworks d’agents eux-mêmes qui doivent s’améliorer, pas l’intelligence sous-jacente des LLM.

Les scores moyens de réplication montrent Claude 3.5 Sonnet à 21%, bien meilleur que tous les autres modèles testés. Ils ont également créé un « agent itératif » qui supprime la capacité de l’agent à terminer tôt. Si l’agent disait « OK, j’ai terminé » ou « Je ne peux pas continuer », ils écrivaient essentiellement des prompts qui poussaient et encourageaient ce modèle à continuer à travailler, à continuer à chercher des solutions.

Avec cette approche, GPT-3.5 Mini a atteint 8,5%, Claude 3.5 Sonnet 16,1% et GPT-4 (01) 24,4% avec une limite prolongée de 36 heures. Très intéressant – avec juste un peu d’encouragement supplémentaire disant « ne t’arrête pas ici, continue à travailler », les performances se sont considérablement améliorées.

Limitations et défis

Avec tous ces résultats, quelles sont les limitations qu’ils ont identifiées ?

Taille du jeu de données : PaperBench ne comprend actuellement que 20 articles et devrait idéalement capturer une portion encore plus grande de la production de la communauté de recherche en ML. Mais comme mentionné précédemment, se concentrer sur le nombre d’articles peut être trompeur – chaque grille est composée de centaines de nœuds, et PaperBench évalue les agents sur des milliers d’exigences individuelles différentes.

Contamination : Bien que le code original de l’auteur existe en ligne et qu’ils aient une liste noire, il n’est pas complètement fou de penser que les modèles dans les données d’entraînement avaient certains de ces articles. En raison de la récence des articles et de la date limite de connaissance des modèles, ils ne pensent pas que les articles aient été effectivement utilisés dans les données d’entraînement, mais ce pourrait ne pas toujours être le cas pour les modèles futurs.
Difficulté de création : Créer ces jeux de données est également très difficile. Il faut l’article, le co-auteur pour créer la grille, et c’est extrêmement laborieux, nécessitant plusieurs jours complets pour un expert humain.
Précision du juge : Le juge basé sur LLM n’est pas encore aussi précis qu’un juge humain.

Coût : Ils estiment qu’il coûte en moyenne 400 $ en crédits API pour exécuter un déploiement d’agent itératif GPT-4 (01) de 12 heures sur un seul article dans PaperBench. Pour 20 articles, cela représente 8 000 $. La notation coûte 66 $ supplémentaires par article avec le juge simple GPT-3.5 Mini. Ce n’est pas bon marché, mais encore une fois, dans le grand schéma des choses, cela vaut largement l’investissement.

Conclusion : L’aube de l’explosion d’intelligence ?

Il reste encore du chemin à parcourir. Ces modèles sont bons, ils peuvent reproduire une partie du travail, mais ils n’y sont pas encore tout à fait. Cependant, au rythme auquel les modèles s’améliorent, au rythme auquel l’échafaudage et les frameworks agentiques autour des modèles s’améliorent, nous y arriverons assez rapidement.

Et une fois que cela se produira, ce sera l’explosion d’intelligence – le moment où les IA pourront non seulement comprendre et reproduire des recherches complexes, mais aussi les améliorer et s’améliorer elles-mêmes dans un cycle vertueux d’auto-amélioration qui pourrait transformer fondamentalement notre monde.