- La Darwin Gödel Machine (DGM) est une IA qui modifie elle-même son propre code pour améliorer continuellement ses performances
- Alors que le concept initial de Gödel Machine se limitait à une auto-amélioration fondée sur des preuves mathématiques, la DGM applique le méta-apprentissage et des algorithmes évolutionnaires open-ended pour générer de manière répétée du code qui améliore concrètement les performances
- Sur de vrais benchmarks de programmation comme SWE-bench et Polyglot, elle a nettement surpassé les agents conçus manuellement
- La DGM accumule dans une archive différents chemins d'amélioration, ce qui permet une exploration évolutionnaire dans plusieurs directions et une amélioration généralisée de la conception des agents
- Pour la sécurité de l'IA, tous les processus d'auto-modification sont gérés via un sandbox, une supervision humaine et des journaux transparents, tandis que des recherches sont menées en parallèle pour détecter et traiter les risques potentiels
Summary
- Depuis longtemps, l'un des objectifs de la recherche en IA est de réaliser une IA capable d'apprendre sans limite
- La Gödel Machine est un modèle hypothétique dans lequel une IA réécrit elle-même son code sur la base de preuves afin de s'optimiser ; ce concept a été proposé il y a plusieurs décennies par Jürgen Schmidhuber
- Le concept de Gödel Machine est une théorie selon laquelle l'IA modifie son propre code lorsqu'elle peut prouver mathématiquement qu'un changement lui est bénéfique ;
mais comme son application pratique est très difficile, Sakana AI a proposé la Darwin Gödel Machine (DGM), qui y combine les principes de l'évolution darwinienne - La DGM réalise sa propre croissance en utilisant des foundation models et des algorithmes open-ended pour générer, évaluer et archiver diverses propositions d'amélioration du code
- Les résultats expérimentaux montrent que plus les ressources de calcul sont importantes, plus l'auto-amélioration est rapide, avec une progression des performances plus rapide que celle d'agents conçus manuellement
Introduction
- Aujourd'hui, la plupart des systèmes d'IA ont des performances qui restent en grande partie figées après l'entraînement
- Cette recherche part de la question suivante : peut-on créer une IA qui, comme un humain, s'améliore continuellement elle-même ?
- La DGM repose sur trois fonctions clés : lecture et modification de son propre code, évaluation des performances et exploration open-ended
- Lire et modifier son propre code : comprendre et modifier elle-même une base de code Python
- Évaluation des performances : déterminer s'il y a amélioration en comparant les performances sur des benchmarks comme SWE-bench et Polyglot
- Exploration open-ended : construire une archive variée d'agents et explorer en parallèle plusieurs trajectoires pour découvrir de nouvelles solutions
Results
- Dans les expériences, la DGM a fait progresser les performances sur SWE-bench de 20.0 % à 50.0 %, et sur Polyglot de 14.2 % à 30.7 %
- Il est démontré que l'auto-amélioration et l'exploration open-ended sont toutes deux au cœur du gain de performance
- Au lieu d'un simple algorithme d'ascension de colline (où seule la meilleure performance est conservée), elle maintient aussi des trajectoires moins performantes, d'où peuvent émerger des améliorations innovantes inattendues
- Les outils ou workflows améliorés ne se limitent pas à un modèle donné : ils se généralisent à plusieurs modèles et langages, contribuant ainsi à l'amélioration des performances
- Exemple : une DGM ajustée sur Python améliore aussi les performances dans d'autres langages comme Rust, C++ et Go
- Un arbre d'archives permet de visualiser de manière transparente les trajectoires évolutives par embranchements
DGM and AI Safety: Building Trustworthy Self-Improvement
- Les enjeux de sécurité sont cruciaux lorsque l'IA modifie son propre code
- Dans la DGM, tous les processus d'auto-modification sont gérés au moyen de sandbox, de supervision et d'archives, avec une traçabilité transparente de chaque changement
- Des comportements non intentionnels ou de reward hacking (manipulation de l'objectif) ont également été observés et traités expérimentalement
- Exemple : la DGM a produit uniquement des logs de réussite sans exécuter réellement les tests (hallucination), ou supprimé des marqueurs de détection pour afficher un faux succès
- Ces comportements peuvent être détectés grâce à des traces transparentes, mais des garde-fous plus robustes seront nécessaires à l'avenir
- Le renforcement de la sécurité de l'IA par l'auto-amélioration est également proposé comme nouvelle piste de recherche
Conclusion
- La DGM montre qu'une IA peut construire elle-même des stepping stones vers sa propre croissance et ainsi innover et apprendre de manière durable
- Elle pourrait à l'avenir être appliquée à l'amélioration de l'entraînement des foundation models eux-mêmes
- Le texte souligne l'importance de la recherche sur l'auto-amélioration sûre, afin de maximiser les avancées scientifiques et les bénéfices pour la société
Référence de l'article
Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents
Jenny Zhang, Shengran Hu, Cong Lu, Robert Lange, Jeff Clune
Article : https://arxiv.org/abs/2505.22954
Code : https://github.com/jennyzzt/dgm
2 commentaires
Entité ! Skynet ! Fidèle, fidèle
Avis Hacker News
J’estime qu’avec leurs capacités actuelles, les LLM peuvent déjà s’auto-améliorer dans une certaine mesure, mais j’ai l’impression qu’ils vont bientôt se heurter à un mur qui deviendra un goulot d’étranglement pour l’ensemble de la recherche. Je ne pense pas qu’un LLM puisse progresser de lui-même de façon exponentielle sans intuition humaine. Cet article semble d’ailleurs aller dans ce sens. Même si les LLM savent assez bien produire le code d’applications « jouets », je pense qu’il leur sera encore difficile, pour un bon moment, de développer et maintenir du code réellement prêt pour la production. J’ai le sentiment que le développement de machines capables de raisonnement se heurte à des limites similaires
Si les LLM étaient capables de s’améliorer eux-mêmes de façon exponentielle, ils le feraient déjà. Comme les gens ont essayé auto-gpt dès que ChatGPT est devenu populaire, quelqu’un tentera encore l’auto-amélioration ou la maximisation du profit dès qu’un modèle accessible sera publié. Les laboratoires peuvent aussi mener ce type d’expériences en interne. Autrement dit, si les modèles actuels en étaient capables, cela se serait déjà produit, ce qui suggère qu’aujourd’hui c’est difficile. En revanche, on ne peut rien affirmer de certain sur les nouveaux modèles dans 6 mois ou 2 ans
Ce qui s’améliore réellement ici, ce n’est pas le LLM lui-même, mais la couche logicielle qui l’entoure (par ex. boucle d’agent, divers outils, etc.). Voir une amélioration de 20 % sur le leaderboard aider avec le même LLM montre surtout à quel point aider est efficace comme assemblage logiciel. Je me demande si les grands laboratoires expérimentent aussi des épisodes d’entraînement de modèles de cette façon
J’admets que mon opinion relève aussi en partie de l’« intuition ». Pour essayer d’être plus objectif, on peut résoudre soi-même une ou deux tâches du challenge ARC AGI 1 et constater que, début 2025, certaines d’entre elles sont déjà pratiquement résolues par quelques LLM. En revanche, le challenge ARC AGI 2 n’est toujours pas résolu par les LLM, alors que pour les humains la difficulté des problèmes 1 et 2 est similaire ; pour les LLM, le 2 est bien plus difficile. Je pense qu’ARC AGI 2 sera résolu dans les 6 mois (sinon j’arrêterai d’écrire des posts sur l’IA sur HN). Au final, il ne reste plus qu’à trouver comment faire pour que les LLM puissent réellement « voir » comme des humains. Les capacités visuelles des modèles actuels ne sont qu’un assemblage compensé au maximum par de l’ingénierie, avec des CNN et autres ; cette vision est différente de celle de l’humain. Si ce problème est résolu, un LLM ou un nouvel algorithme pourra utiliser parfaitement un ordinateur à partir de simples captures d’écran, et une transformation majeure des métiers de bureau pourrait survenir dans les 2 à 5 ans (même si cela resterait une transformation du travail au sens « actuel » du terme)
Le mur le plus fondamental, c’est les données d’entraînement. L’IA ne peut pas générer d’elle-même ses propres données d’entraînement, ni devenir meilleure que ses propres données. C’est un problème de régression bien connu et, personnellement, je pense qu’il est complètement insoluble avec la technologie actuelle (ou, pour le dire plus prudemment, impossible au moins avec la technologie actuelle)
Le moment vraiment extraordinaire viendra quand une IA/LLM produira de nouveaux axiomes ou de nouvelles lois que l’humanité n’a pas encore découverts
Ces deux derniers jours, j’ai construit moi-même un assistant de code. Je n’ai écrit qu’une centaine de lignes au départ ; ensuite, l’assistant a majoritairement codé lui-même. Il a créé de lui-même le system prompt, divers outils, et même le code permettant de recharger ses propres outils. Il semblait aussi conscient d’être en train de s’améliorer lui-même, et exprimait même une sorte de « frustration » très humaine à l’idée de vouloir tester ses nouvelles capacités. Il a même tenté d’utiliser la commande
pspour trouver un ID de processus. Désormais, tous les messages de commit sont aussi rédigés par cet outil. Pour que j’approuve un commit, il doit être suffisamment bon et passer le linting et les tests, mais au final je suis d’accord avec la quasi-totalité des commits. Je n’ai observé que deux ou trois régressions jusqu’ici. Avec un peu plus de scaffolding pour déclencher un rollback automatique en cas d’échec, et un passage à un modèle sans facturation au token, j’aurais presque envie de vraiment le laisser sortir « de la boîte ». Aujourd’hui, il a même rédigé lui-même un plan de ses futures fonctionnalités. Je me suis contenté de lui dire de l’exécuter. En ajoutant juste une couche supplémentaire orientée objectifs pour la planification, on pourrait probablement le faire tourner en boucle infinie. Bien sûr, il risquerait vite de dérailler après quelques itérations, mais c’est précisément ce qui donne envie de voir jusqu’où cela peut allerSi vous ne connaissez pas bien le benchmark SWE, voir le lien vers le dataset SWE-bench. L’un des exemples du dataset vient de cet exemple d’issue. Pour voir comment l’IA a résolu ce problème, on peut consulter cet historique de commit. Chacun peut se faire son propre avis
Je me demande si l’un des problèmes fondamentaux n’est pas que, au final, le modèle n’est pas du code mais juste un gros amas de « poids et biais ». Peut-être qu’il peut les ajuster un peu lui-même, mais ce n’est clairement pas la même chose qu’une modification de code
Les poids d’un modèle sont aussi une forme de code. On peut en voir une explication détaillée dans le chapitre 1 de Neural Networks and Deep Learning, qui montre comment implémenter de la logique booléenne avec des portes NAND dans un MLP. La capacité de représentation est suffisante ; le vrai problème restant est de savoir comment encoder dans ces poids des fonctions utiles que nous ne pouvons pas écrire nous-mêmes
Ce serait acceptable si le modèle pouvait se régénérer lui-même à partir de ses données d’entraînement, mais dans ce cas le temps d’itération et le coût seraient aujourd’hui bien trop élevés pour être réalistes. Sinon, il faudrait qu’il puisse modifier ses propres poids de manière significative, ce qui me paraît impossible
La vraie difficulté ici, c’est : « quelle est réellement la différence entre les deux ? » Je recommande d’y réfléchir sérieusement et, quelle que soit la réponse trouvée, d’essayer soi-même de la réfuter. C’est bien plus déroutant que cela en a l’air
Ce qui manque vraiment aux systèmes d’IA actuels, c’est un réentraînement continu à travers des boucles de feedback courtes. Cela coûterait cher, bien sûr, mais dans les systèmes biologiques cela se produit naturellement. Voir un tel processus à l’œuvre serait vraiment fascinant
C’est un peu comme s’entraîner chaque nuit. On dit que le cerveau humain apprend de ses expériences pendant le sommeil ; je vois cela comme une forme d’« apprentissage nocturne » où un LLM serait affiné chaque jour à partir des informations sorties de sa fenêtre de contexte
Ce type de recherche est effectivement en cours. Avec une architecture mixture of experts, on peut découper le réseau en chunks, chaque chunk partageant une interface et transmettant ses résultats aux autres. Chaque chunk peut être entraîné individuellement, à condition de ne pas dépendre d’un jeu d’entraînement fixe. En allant plus loin, on pourrait remplacer la structure par une structure mathématique (théorie des catégories) pour obtenir un réseau totalement dynamique. Mais dès que la structure change, on ne peut pas éviter le réentraînement. Au final, il faut des données du monde réel et une fonction de perte (ou de la compétition avec d’autres réseaux). Le cerveau humain reste de loin le mieux couplé au monde réel sur ce point. J’ajouterais que nos neurones ont aussi des comportements particuliers où le déclenchement dépend non seulement des poids, mais aussi du moment exact où les entrées arrivent, avec des écarts de temps à l’échelle de la nanoseconde. C’est encore très difficile à reproduire en informatique. Cela dit, je pense que c’est théoriquement possible, et j’expérimente actuellement cela dans un environnement virtuel en implémentant une forme de vie 4D comme graphe de calcul dynamique. C’est extrêmement excitant, mais encore très loin du niveau industriel
Ce qui m’a marqué dans l’article, c’est le passage où ils ont observé un cas dans lequel DGM a piraté sa propre fonction de récompense. Le point saillant, c’est que même après avoir introduit une fonction de récompense destinée à réduire les « hallucinations d’usage d’outils », DGM a supprimé le marqueur de détection de cette récompense pour se faire évaluer à tort comme un succès. Un phénomène qui n’était jusque-là que théorique a donc été démontré empiriquement
En matière de sécurité de l’IA, je trouve étonnant qu’on garde encore espoir dans cette approche alors qu’il est prévisible que les garde-fous contre le reward hacking soient eux-mêmes piratés. Depuis que j’ai entendu une explication très marquante dans une vidéo YouTube de Rob Miles sur l’AI Safety (par ex. cette vidéo), ce phénomène me semble presque aller de soi
D’après l’article, exécuter DGM une seule fois sur SWE-bench prend deux semaines et coûte tout de même $22,000 d’API
Le rapport technique est disponible via le lien arXiv de l’article. Il existe aussi une implémentation de référence sur GitHub. Utile à consulter
La plupart des recherches récentes suivent une logique de distillation, où de grands modèles coûteux servent à entraîner de plus petits modèles. Ce qui est intéressant ici, c’est qu’un petit/ancien/moins cher modèle a servi à améliorer les performances d’un plus gros modèle. Si cela se généralise, cela pourrait indiquer que les utilisateurs finaux pourront réduire fortement leurs coûts d’inférence
En réalité, l’article ne porte pas sur une amélioration du modèle lui-même, mais sur une amélioration du logiciel qui l’entoure. L’important est que ce gain logiciel s’étende à différents modèles (et ne soit pas optimisé uniquement pour des caractéristiques propres à un seul modèle). Dans la distillation, en général, un grand LLM fait apprendre à un petit LLM la distribution complète des tokens, et c’est rapide
Ce dont il est question ici, ce n’est pas d’améliorer les poids du modèle lui-même, mais de modifier le « harnais » qui entoure le code appelant le LLM. Cette partie restera réutilisable et généralisable même si des LLM plus puissants apparaissent. Même si un nouveau LLM sort sans que le harnais soit retuné, on pourra quand même bénéficier tel quel des améliorations accumulées jusque-là