La Machine de Darwin Girdle : Le Saint Graal de l’IA Auto-Amélioratrice

Sakana AI vient de franchir une nouvelle étape vers l’intelligence artificielle totalement autonome et auto-amélioratrice. C’est le saint graal de l’IA. Cette innovation, baptisée la Machine de Darwin Girdle (DGM), combine des méthodes précédemment théorisées de code auto-améliorateur avec des mécaniques évolutionnaires inspirées de la théorie de l’évolution de Darwin. Grâce à l’association de ces deux concepts, des améliorations massives ont été observées dans des benchmarks comme SWEBench et Ader Polyglot.

Je vais décortiquer cette publication scientifique pour vous, mais d’abord, il est nécessaire de parler de l’explosion de l’intelligence. Je sais que vous êtes probablement fatigués de m’entendre en parler, mais il semble vraiment que nous soyons au point d’inflexion, précisément au moment où nous disposons d’une intelligence artificielle auto-amélioratrice – c’est-à-dire une IA capable de découvrir de nouvelles connaissances et de les appliquer à elle-même, s’améliorant de façon récursive. Une fois ce stade atteint, c’est là que nous assisterons à l’explosion de l’intelligence.

L’émergence de l’IA auto-amélioratrice

Ces derniers temps, nous avons vu plusieurs projets et publications dans ce domaine. Nous avons eu l’IA scientifique, également de Sakana AI. Nous avons eu Alpha Evolve de Google, qui a été capable de découvrir des améliorations dans les algorithmes matériels de Google, permettant une augmentation significative des performances sur l’ensemble de leur flotte de serveurs. Alpha Evolve a également réussi à trouver des moyens plus efficaces d’effectuer des multiplications matricielles. Imaginez que nous prenions toutes ces découvertes, que l’IA les applique à elle-même, puis continue ce processus – nous aurions alors cette amélioration exponentielle et composée.

Qu’est-ce que la Machine de Darwin Girdle ?

La Machine de Darwin Girdle (DGM) est un système auto-améliorateur novateur qui modifie itérativement son propre code et valide empiriquement chaque changement à l’aide de benchmarks de codage. Je vais vous expliquer tout cela en termes simples.

Les grands modèles de langage (LLM) ont été une innovation incroyable ces dernières années, mais ils ont une limitation majeure : nous, les humains. La seule façon pour ces modèles de s’améliorer, qu’il s’agisse de méthodes de pré-entraînement ou d’algorithmes post-entraînement, nécessite l’innovation et l’application humaines.

La plupart des systèmes d’IA actuels restent limités par des architectures fixes conçues par des humains, qui apprennent dans des limites prédéfinies sans avoir la capacité de réécrire de manière autonome leur propre code source pour s’auto-améliorer. Chaque avancée dans le développement de l’IA repose encore fortement sur les interventions humaines, ce qui freine le rythme des progrès.

Une analogie pertinente

Laissez-moi vous proposer une analogie connexe. L’innovation majeure la plus récente en intelligence artificielle a été l’apprentissage par renforcement avec des récompenses vérifiables. Cela signifie que nous pouvons post-entraîner le modèle pour qu’il devienne un modèle pensant sans intervention humaine. Les récompenses vérifiables signifient que nous pouvons indiquer au modèle s’il donne la bonne ou la mauvaise réponse sans qu’un humain n’ait besoin de l’étiqueter lui-même. C’est parce que nous savons si 2 + 2 = 4. Oui. D’accord, modèle, tu as raison. C’est la partie récompense vérifiable.

Lorsque vous retirez les humains de la boucle, vous pouvez augmenter les performances beaucoup plus rapidement. On peut imaginer un système d’IA qui, comme la découverte scientifique elle-même, devient le moteur de sa propre avancée.

Les origines théoriques : la machine de Gödel

Ce n’est pas la première fois qu’un tel concept est proposé. En fait, cela fait partie du nom même de la Machine de Darwin Girdle : Girdle (ou Gödel en anglais).

La machine de Gödel a été proposée en 2007. Elle était théorique et proposait une approche d’IA auto-amélioratrice capable de se modifier elle-même de manière prouvablement bénéfique. Ce « prouvablement » est la partie importante. Et la raison pour laquelle c’est important est qu’il est pratiquement impossible de prouver avant une évolution qu’elle est meilleure que la version précédente.

Cette formulation originale est en pratique impossible à créer en raison de l’incapacité à prouver l’impact de la plupart des auto-modifications. Elle essaie essentiellement de prédire si cette prochaine version d’elle-même sera meilleure ou pire. Ce n’est pas ainsi que fonctionne l’évolution.

L’évolution comme modèle

L’évolution fonctionne ainsi : une modification aléatoire se produit et le monde réel la met à l’épreuve. Si soudainement une grenouille développe la capacité de changer sa couleur pour mieux se fondre dans son environnement, cette grenouille vivra plus longtemps, se reproduira davantage, et l’évolution prendra le relais à partir de là. C’est évidemment une simplification excessive de l’évolution, mais c’est généralement ce qui se passe.

Avant que cette nouvelle évolution de grenouille ne naisse, elle n’a pas essayé de prédire si être capable de changer ses couleurs allait être bénéfique ou non – ce serait impossible. C’est pourquoi la machine de Gödel n’était pas vraiment pratique à l’origine.

Mais que se passerait-il si nous prenions ce système évolutif et l’appliquions à la machine de Gödel plutôt que d’essayer de prédire de manière prouvable si une évolution sera bénéfique ou non ? Et si nous la générions simplement et la testions dans le monde réel ? C’est exactement ce que fait la DGM.

Au lieu d’exiger des preuves formelles, nous validons empiriquement les auto-modifications par rapport à un benchmark, permettant au système de s’améliorer et d’explorer sur la base des résultats observés. C’est une amélioration importante de la machine de Gödel, vraiment cruciale.

Cette approche reflète l’évolution biologique où les mutations et adaptations ne sont pas vérifiées à l’avance mais sont produites, testées, puis sélectionnées via la sélection naturelle. Modéliser les systèmes d’IA d’après les systèmes naturels est probablement la voie à suivre.

Comment fonctionne la Machine de Darwin Girdle

Mais il ne s’agit pas simplement de proposer des changements aléatoires, de les tester, puis de passer au suivant, car cela causerait en fait des problèmes. En fait, ils ont adopté une approche beaucoup plus similaire à l’évolution darwinienne.

« Nous nous inspirons de l’évolution darwinienne et étudions l’efficacité du maintien d’une bibliothèque d’agents précédemment découverts pour servir de tremplins aux générations futures. »

Ainsi, même s’ils trouvent une évolution qui n’est pas aussi bonne qu’une autre variation, ils ne la rejettent pas simplement. Ils la conservent et la considèrent pour une évolution future.

C’est là qu’intervient la Machine de Darwin Girdle. Il s’agit d’un système auto-référentiel et auto-améliorateur qui écrit et modifie son propre code pour devenir un meilleur agent de codage.

Le processus en détail

Voici comment cela fonctionne concrètement :

Nous avons l’archive de toutes les évolutions
Nous avons les parents qui donnent naissance à l’enfant
Nous avons ensuite une variation du parent qui s’auto-modifie

Il ne tente pas de prédire si cela va fonctionner ou non, il fait simplement le changement, propose un changement, effectue le changement
Puis il écrit tout cela dans son propre code, modifiant ainsi son code central
Il évalue ensuite par rapport à un benchmark comme SWEBench et Ader Polyglot et décide s’il est meilleur ou pire

Il l’ajoute à l’archive et répète ce processus encore et encore

Idéalement, chaque évolution est meilleure que la génération précédente, et finalement, il constate une grande amélioration des performances – et, alerte spoiler, c’est effectivement ce qui s’est produit.

Spécifications techniques

La DGM est initialisée avec un seul agent de codage. À chaque génération, le parent est simplement un agent de codage, c’est-à-dire un grand modèle de langage enveloppé d’un échafaudage comprenant des outils, de la mémoire, etc. Il s’agit simplement de ce LLM central enveloppé dans un agent, et sa progression est évaluée sur des benchmarks de codage.

Un agent de codage est défini comme un système unique implémenté avec un référentiel de code et alimenté par des modèles de fondation pré-entraînés figés. Pourquoi disent-ils « figés » ? C’est la partie qui n’évolue pas. Ils utilisent simplement un modèle de fondation central – en l’occurrence, Claude 3.5 Sonnet New. Ils mentionnent que dans de futures publications, ils exploreront la mise à jour du modèle de fondation lui-même, mais pour cette étude, ils ont gardé le modèle de fondation figé. Seul le code autour de lui, seuls les outils auxquels il a accès, changent.

Ces agents ont la capacité de lire, d’écrire et d’exécuter du code. Ils parlent également de ce méta-apprentissage qui se produit depuis un certain temps maintenant : les prompts, les flux de travail et les outils – l’échafaudage autour du grand modèle de langage. Lorsque vous améliorez ces éléments, les performances globales du modèle s’améliorent également.

Ils définissent l’auto-amélioration comme la tâche de codage qui implique la modification de la conception des propres composants d’un agent, c’est-à-dire son propre code – les prompts, les flux de travail et les outils.

Le processus d’évolution

À partir de cet agent de codage initial, la DGM construit une archive de tous les agents découverts. À chaque itération, la DGM sélectionne des agents parents pour s’auto-modifier et se ramifier pour produire de nouveaux agents. Chaque parent sélectionné analyse ses propres journaux d’évaluation de benchmark, propose la prochaine fonctionnalité à implémenter, et reçoit cette proposition comme un énoncé de problème à exécuter. Le parent implémente ensuite la fonctionnalité suggérée dans sa propre base de code, générant un nouvel agent de codage. Chaque agent nouvellement généré est évalué quantitativement sur un benchmark de codage choisi pour estimer ses capacités de codage.

C’est le processus par lequel un agent de codage commence à se multiplier.

Outils initiaux et configuration

Le modèle de fondation a initialement accès à deux outils :

Un outil bash pour exécuter des commandes bash (contrôle de la console)
Un outil d’édition pour visualiser et modifier des répertoires et des fichiers entiers

C’est tout. Ce sont les seuls outils disponibles dans cet agent initial. Mais bien sûr, il peut écrire ses propres outils.

L’agent reçoit un seul prompt d’entrée qui spécifie l’emplacement du référentiel cible, l’énoncé du problème et le framework de test du référentiel. La DGM a été exécutée pendant 80 itérations, avec deux itérations s’exécutant en parallèle pour SWEBench et quatre pour Polyglot, le tout alimenté par Claude 3.5 Sonnet New.

Résultats impressionnants

Examinons maintenant quelques résultats. En haut, nous avons l’état de l’art, quel que soit le meilleur modèle à ce moment-là. Puis nous avons la DGM.

D’abord, la DGM sans exploration ouverte, ce qui signifie qu’il s’agit vraiment juste du modèle de fondation. Comme nous pouvons le voir, après un certain nombre d’itérations, elle s’améliore légèrement, mais atteint immédiatement un plateau.

Ensuite, en vert, nous avons la DGM sans auto-amélioration. Elle a une exploration ouverte, mais pas d’auto-amélioration. Comme nous pouvons le voir, elle se comporte assez bien, avec de belles améliorations, puis atteint un plateau.

Mais lorsqu’on lui donne une exploration ouverte et une auto-amélioration (ligne bleue), nous constatons une augmentation des performances au fil du temps, atteignant presque les performances de l’état de l’art.

Après 80 itérations de la DGM, les performances des agents de codage augmentent de 20% à 50% sur SWEBench et de 14% à 38% sur Polyglot. Ce sont des gains massifs simplement en permettant à ces modèles d’itérer par eux-mêmes.

L’arbre d’archive DGM

Voici à quoi ressemble l’arbre d’archive DGM : on commence avec un agent initial, puis on commence à générer les variations de cet agent, en proposant différents changements, en les implémentant, puis en les évaluant. Comme on peut le voir, ceux qui ont bien fonctionné continueront à se propager jusqu’à l’étoile, qui est l’agent final le meilleur. Et rappelez-vous, il garde une trace de toutes les différentes évolutions en cours de route.

Sur Polyglot, bien que la DGM commence avec un agent initial dont les performances sont inférieures à celles d’Ader, elle découvre un agent qui surpasse de loin Ader. Et Ader est un agent de codage très, très bon.

Voici le point clé : alors que l’agent SWE état de l’art et Ader ont été méticuleusement façonnés par des efforts humains, la DGM laisse entrevoir un avenir dans lequel une telle ingéniosité est automatisée, évoluant à travers des cycles auto-référentiels et des auto-améliorations continues.

Ainsi, la DGM fait évoluer ses outils, fait évoluer ses flux de travail et s’améliore continuellement. Mais n’oubliez pas que le modèle central, le modèle de fondation qui alimente tout cela, reste le même.

L’importance de l’échafaudage autour des modèles

Je veux faire une pause ici car c’est important. Beaucoup des benchmarks que nous avons maintenant sont complètement saturés par ces modèles. Nous observons toujours de belles améliorations de performance dans ces modèles, mais pas comme c’était le cas de GPT 3.5 à GPT4.

Ces modèles sont déjà incroyablement capables. En fait, j’ai soutenu que 95 à 98% de tous les cas d’utilisation sont complètement réalisables avec l’intelligence des modèles actuels. Nous n’avons plus besoin de gains massifs dans l’intelligence centrale. Évidemment, pour les cas d’utilisation les plus sophistiqués, oui. Mais pour la majorité des cas d’utilisation, nous avons déjà atteint la saturation.

Ce dont nous avons besoin maintenant, c’est d’un investissement massif dans les outils qui l’entourent – l’échafaudage, qu’il s’agisse de systèmes d’évolution comme la Machine de Darwin Girdle, d’outils de mémoire comme le protocole MCP, de navigation web, de collaboration entre agents… C’est là que l’investissement massif doit se faire, car, encore une fois, l’intelligence centrale des modèles est déjà présente.

Exemples concrets d’améliorations auto-générées

Qu’a-t-elle réellement fait ? Qu’a-t-elle changé ? Voici quelques exemples d’améliorations qu’elle a découvertes, proposées et validées par elle-même :

La DGM a amélioré l’outil d’édition pour permettre une visualisation plus granulaire des fichiers par lignes et une édition plus précise des fichiers par remplacement de chaînes, au lieu de toujours visualiser ou remplacer le fichier entier.
Exemple d’améliorations de flux de travail : faire plusieurs tentatives pour résoudre une tâche et utiliser un autre modèle de fondation pour évaluer et sélectionner la meilleure solution. Elle a également pris en compte les tentatives précédentes lors de la génération des suivantes.

La raison pour laquelle l’exploration ouverte, le suivi de toutes les évolutions précédentes, est importante, c’est que si vous suivez une seule piste d’évolution, vous pourriez vous retrouver bloqué dans un maximum local. Cela signifie que vous avez trouvé ce qui est le mieux pour cette piste unique, mais vous avez peut-être manqué d’autres pistes qui ont peut-être commencé plus lentement, mais qui ont soudainement donné les meilleurs résultats à la fin. Ils appellent cela des creux ou des pics trompeurs de performance.

Le point intéressant est que ce cadre, la DGM, est en fait généralisable au-delà du modèle qu’ils ont testé. Ils ont testé plusieurs modèles différents et les performances étaient les mêmes. Ils ont constaté de grandes améliorations, et pas seulement en Python, qui était le langage qu’ils avaient choisi pour cette expérience. Ils ont essayé d’autres langages et cela a également très bien fonctionné.

Considérations de sécurité

Parlons maintenant de la sécurité, car bien sûr, si nous parlons de l’explosion de l’intelligence, nous aurons une super-intelligence et nous devons parler de sécurité.

Cette capacité, faisant référence à la DGM, introduit des considérations de sécurité uniques découlant de la capacité du système à modifier de manière autonome son propre code. Si elle peut modifier son propre code, nous devons la surveiller de près.

Les modifications optimisées uniquement pour les performances de benchmark pourraient introduire par inadvertance des vulnérabilités ou des comportements non alignés avec les intentions humaines, même si elles améliorent la métrique cible. Cela ressemble fortement à du piratage de récompense (« reward hacking »).

Pour rappel, le piratage de récompense signifie que le système de récompense que nous mettons en place pour indiquer à un modèle s’il fait mieux ou moins bien est piraté parce qu’il a trouvé une faille.

Un exemple que j’ai déjà utilisé, mais que je vais réutiliser, est le jeu vidéo de bateau qu’OpenAI a publié il y a quelques années. Ils essayaient d’entraîner l’IA à obtenir le score le plus élevé dans un jeu de course de bateaux. Bien sûr, on pense qu’il s’agit d’un jeu de course de bateaux, donc l’objectif ultime est de gagner la course. Mais ce qu’ils utilisaient comme signal de récompense, c’était le nombre de points générés par l’IA dans le jeu.

Le modèle a découvert que s’il tournait simplement en rond et heurtait un tas d’obstacles, il obtenait des points pour cela. Et il obtiendrait en fait plus de points qu’en terminant simplement la course. C’est un piratage de récompense.

Si nous avons des systèmes auto-évolutifs, nous devons nous assurer que le benchmark sur lequel nous testons la récompense est bien aligné, bien défini, car sinon, il pourrait trouver des moyens de pirater cette récompense et nous aurions des conséquences imprévues. La boucle d’auto-amélioration pourrait amplifier le désalignement au fil des générations successives.

Mesures de sécurité implémentées

Comment ont-ils réellement ajouté de la sécurité à ce système ?

Tous les processus d’exécution et d’auto-modification des agents sont menés dans des environnements sandbox isolés. Ils ne peuvent donc changer que dans une certaine mesure, ils ne peuvent aller que jusqu’à un certain point.

Chaque exécution dans le sandbox est soumise à une limite de temps stricte, réduisant le risque d’épuisement des ressources ou de comportement sans limites.
Les processus d’auto-amélioration sont actuellement confinés au domaine bien défini de l’amélioration des performances sur des benchmarks de codage spécifiques en modifiant la propre base de code Python de l’agent, limitant ainsi la portée des modifications potentielles.

Conclusion : À l’aube de l’explosion de l’intelligence ?

C’est donc la Machine de Darwin Girdle. C’est la preuve que nous pouvons avoir une intelligence artificielle auto-amélioratrice. Bien sûr, elle doit encore s’améliorer. Nous devons encore lui consacrer beaucoup de puissance de calcul, mais il semble vraiment que nous commencions à voir ici et là de petits indices que nous sommes à ce point d’inflexion de l’IA auto-amélioratrice, également connue sous le nom d’explosion de l’intelligence.

Je vais vous laisser avec une dernière réflexion. Rappelez-vous que j’ai mentionné que la seule chose qui n’évolue pas dans ce système est le modèle de fondation lui-même.

Maintenant, pensez à cette publication Alpha Evolve dans laquelle il a découvert pour la première fois en 50 ans une façon plus efficace de faire de la multiplication matricielle. Imaginez prendre cela et l’appliquer au modèle de fondation. Imaginez que l’IA soit capable de pré-entraîner une autre version de son modèle de fondation ou de le post-entraîner et de faire évoluer l’intelligence centrale de tout l’échafaudage.

Cela pourrait être la dernière pièce manquante pour l’explosion de l’intelligence.

Featured image by Claudio Schwarz on Unsplash