Amélioration récursive des agents d’IA : ce que montrent réellement les expériences
Un examen attentif des machines de Gödel, STOP, de l’agent de Gödel, de SICA, de la machine de Gödel darwinienne, de SEAL et des hyperagents, ainsi que des critères permettant de déterminer si un agent auto-modifiant améliore réellement les choses.
Sources: Can Artificial Intelligence Design a Better Artificial Intelligence?
Demander à un agent de codage de corriger une erreur dans votre application est aujourd’hui une pratique courante : il ouvre des fichiers, modifie quelques lignes et exécute le jeu de tests. Si l’on change l’instruction en « améliorer le logiciel que vous utilisez pour effectuer ce travail », l’objectif devient alors l’agent lui-même : la manière dont il localise les fichiers, les outils qu’il utilise, la façon dont il se remet d’une tentative infructueuse, et le fait que la version résultante puisse permettre une nouvelle amélioration. C’est cette dernière question qui constitue l’essence de l’amélioration récursive autonome (RSI). Cet article distingue la auto-modification de la véritable amélioration, présente les principaux expériements et leurs résultats, et vous propose un ensemble de questions ainsi qu’un petit schéma d’expérience pour évaluer vous-même de telles affirmations.
Auto-modification, amélioration autonome et récursivité
Prier un modèle de vérifier à nouveau sa réponse peut produire une meilleure réplique, mais cela ne rend pas le modèle plus compétent pour la tâche suivante. Seule cette sortie unique a changé. Pour raisonner clairement sur le RSI, il est nécessaire de distinguer trois niveaux :
- Auto-modification : une partie du système change.
- Auto-amélioration : ce changement procure un avantage mesurable.
- Auto-amélioration récursive : la nouvelle capacité renforce précisément le mécanisme qui permet des améliorations ultérieures.
Un exemple concret aide à comprendre. Si un agent devient plus doué pour rechercher des fichiers, il termine ses tâches plus facilement ; c’est de l’auto-amélioration. Si cette même capacité améliorée lui permet également de comprendre sa propre base de code, ce qui le rend plus apte à la modifier lui-même, l’avantage se réinjecte dans le processus d’amélioration ; c’est la partie récursive.
Il est également important de savoir à quoi fait référence le terme « soi-même ». Un système d’IA déployé n’est rarement simplement un modèle de langage. Le modèle se trouve au sein d’outils, de mémoires, d’instructions opérationnelles et de code d’orchestration, et ce système environnant peut évoluer considérablement tandis que les poids restent inchangés. L’évolution de cette couche externe constitue néanmoins une évolution, mais toute affirmation concernant l’autosuivi doit préciser quelle couche a changé : les poids, le code de l’agent, les prompts, les outils ou la procédure d’amélioration elle-même.
La machine de Gödel : prouver l’avantage avant de modifier
La machine de Gödel, proposée par Jürgen Schmidhuber, représente le cadre mathématique classique. Le système peut réécrire n’importe quelle partie de son propre logiciel, y compris la composante chargée de rechercher des preuves, mais uniquement après avoir démontré que cette réécriture augmente l’utilité attendue selon ses objectifs et hypothèses définis.
Ce garantie est plus restreinte qu’il n’y paraît. Elle ne promet pas que chaque modification soit utile dans le monde réel, quelles que soient les conditions ; elle s’applique uniquement par rapport aux axiomes choisis, au modèle de l’environnement et à la définition d’utilité. Trouver une preuve formelle du fait qu’une modification donnée est bénéfique peut également être très difficile d’un point de vue computationnel.
La plupart des expériences actuelles empruntent donc une voie empirique : au lieu de prouver à l’avance qu’une modification est bonne, elles exécutent le système modifié et mesurent ses performances. Cela est bien plus pratique, mais cela reporte la charge sur l’évaluation. La question qui se pose naturellement est de savoir si ce qui est mesuré correspond réellement au type de croissance qui nous intéresse.
ARRÊT : utilisation d’un améliorateur sur lui-même
L’Optimiseur autodidacte (STOP) part d’un « améliorateur », un programme qui fait appel à un modèle de langage pour proposer et évaluer des améliorations auprès d’autres programmes. Cet améliorateur est ensuite appliqué à son propre code source, et l’édition mise à jour est utilisée dans la phase suivante pour produire de nouvelles améliorations.
La découverte notable est que ce cycle ne se comporte pas de la même manière selon les modèles. Avec GPT-4, les performances moyennes ont augmenté au fil des itérations ; avec GPT-3.5 et Mixtral, elles ont diminué. Comme le modèle de langage sous-jacent ne change jamais, les auteurs précisent que leur travail n’est pas une RSI complète.
La leçon pour les praticiens est simple : itérer sur un processus ne garantit pas de progrès. Une méthode d’amélioration faible appliquée à elle-même peut tout aussi facilement renforcer ses propres erreurs à chaque passage.
Gödel Agent : réécrire la logique même de l’agent
Gödel Agent permet à un modèle de langage de modifier en temps réel la logique de raisonnement ainsi que le code de comportement de l’agent lui-même. Il est évalué en termes de compréhension écrite, de mathématiques et de réponse à des questions basées sur des connaissances ; l’optimisation s’effectue sur un ensemble de validation, et l’agent résultant est mesuré sur un ensemble de test distinct, ce qui constitue la méthode appropriée pour éviter une adaptation spécifique aux conditions du test.
Les chiffres présentés doivent être analysés avec soin, car les différentes variantes fonctionnent dans des conditions différentes. Sur MGSM, Meta Agent Search affiche une précision de 53,4 %, tandis que la variante basée sur Gödel mais restreinte atteint 64,2 %, ce qui représente une comparaison équivalente. La variante sans Gödel et non restreinte atteint 90,6 %, mais elle opère sous des contraintes différentes et ne devrait pas être présentée comme l’étape suivante dans cette même comparaison.
Ce qui se distingue sur le plan technique, ce n’est pas tant la note que le choix de conception : la méthode utilisée par l’agent pour résoudre les problèmes est elle-même devenue un logiciel qui peut être recherché et modifié.
SICA : un agent de codage qui édite sa propre base de code
Au cours de 50 tâches choisies au hasard, tirées du SWE-bench Verified et maintenues constantes, les performances sont passées de 17 % lors de la première itération à un pic de 53 % à l’itération 14, pour se stabiliser à 51 % lors de la dernière itération. En d’autres termes, l’amélioration n’a pas été monotone. Les auteurs estiment que 15 itérations ont coûté environ 7 000 dollars en termes d’utilisation des API.
Deux éléments nuancent ce titre. Premièrement, les auteurs soulignent qu’une limite de cinq minutes par tâche a pu abaisser la note de départ, et que une grande partie des améliorations initiales provient d’outils de modification de fichiers plus rapides qui permettent à l’agent d’accomplir davantage de travail dans cette même limite. Deuxièmement, les améliorations découvertes par l’agent ressemblent à des tâches d’utilisation ordinaire d’outils : des opérations de modification précises plutôt que la réécriture de fichiers entiers, ainsi que la recherche de fonctions et de classes en parcourant l’arbre syntaxique analysé du code plutôt qu’en effectuant une recherche sur le texte brut.
Rien de tout cela ne rend le résultat anodin, mais passer de 17 % à 53 % ne signifie pas pour autant que l’intelligence générale du système ait presque triplé. Ce qui a été mesuré, c’est la performance sur un ensemble de tâches spécifiques, sous une limite de temps donnée, et une grande partie de ces améliorations correspond exactement à ce qu’un ingénieur humain ajouterait à l’outil de travail d’un agent de codage.
Machine Darwin Gödel : un archive plutôt qu’une seule ligne
La Machine Darwin Gödel (DGM) abandonne l’idée d’une seule chaîne de versions. Elle conserve un archivage des variantes d’agents et permet à de nouvelles branches de naître à partir de n’importe laquelle d’entre elles. Une variante qui obtient de moins bons résultats aujourd’hui peut encore être la source d’une modification ultérieure plus utile, ce qui constitue l’élément évolutif et ouvert mentionné dans son nom.
D’après le papier v3, les améliorations constatées incluent une hausse de 20 % à 50 % dans l’évaluation sur le sous-ensemble SWE-bench, ainsi qu’une augmentation de 14,2 % à 30,7 % sur l’ensemble complet du benchmark Polyglot. L’étude effectue également des expériences de transfert avec d’autres modèles et benchmarks non utilisés pendant le développement. Celles-ci suggèrent que certaines de ces améliorations sont généralisables au-delà des tâches de développement, bien qu’elles ne suffisent pas à démontrer une amélioration significative dans tous les domaines. Comme pour les autres travaux au niveau des agents, les modèles de base restent inchangés ; seul le logiciel des agents qui les entourent évolue.
Le coût fait également partie de l’équation. Les auteurs estiment qu’un exécution de DGM sur SWE-bench coûte environ 22 000 dollars, contre environ 10 000 dollars pour chaque exécution de la méthode de référence. Les expériences d’ablation visant à isoler la contribution de chaque composant ne permettent donc pas de déterminer avec certitude si DGM resterait supérieur en cas de budget égal.
La leçon la plus applicable concerne la stratégie de recherche : éliminer toutes les versions qui semblent représenter un recul peut empêcher d’aboutir à un système amélioré, car de bons designs passent parfois par des étapes intermédiaires moins performantes.
Lorsque les poids, ou l’améliorateur, changent
Les expériences avec des codes d’agent ne représentent pas l’ensemble du domaine. SEAL (Self-Adapting Language Models) étudie un modèle qui génère ses propres données de fine-tuning ainsi que des directives d’actualisation, y compris des instructions sur la manière dont l’adaptation doit être effectuée. L’entraînement à l’aide de ces directives auto-générées provoque des changements durables dans les poids du modèle, ce qui montre clairement que la recherche sur l’autamélioration ne se limite pas au cadre des agents. Néanmoins, le fait que les poids changent ne dit rien en soi au sujet d’améliorations illimitées ou accélérées.
Hyperagents aborde une limitation différente. Il fusionne l’agent de tâche et le méta-agent qui le modifie en un seul programme editable, permettant ainsi de modifier le mécanisme lui-même qui produit des améliorations futures. Les auteurs indiquent que certaines de ces améliorations au niveau méta se transmettent entre différents domaines de tâches et s’accumulent au fil des exécutions. Ensemble, ces études déplacent le débat de « une IA peut-elle modifier son propre code ? » à « jusqu’où peut-elle améliorer le processus par lequel elle se développe ? »
Quatre questions pour toute affirmation du type « ça s’est amélioré »
Lorsque la courbe d’autos’amélioration monte, il est utile de se demander ce qui exactement augmente.
Mieux en quel sens ?
L’exactitude peut augmenter tandis que les coûts et les délais augmentent également. Un compromis acceptable pour un objectif de recherche peut être inacceptable dans un produit ; il convient donc d’examiner toutes les métriques, et non seulement celle qui attire l’attention.
Mieux pour quels types de tâches ?
Les améliorations sur des tâches utilisées répétitivement pour choisir la prochaine version constituent des preuves moins solides que celles obtenues sur un test final non modifié pendant le développement. Chaque fois qu’un score de test influence une autre décision de sélection, le processus tend à s’adapter à ce test.
Quelle version est la meilleure ?
Un archivage qui conserve le meilleur résultat montrera une ligne « meilleur jusqu’à présent » en hausse, même si la plupart des nouveaux candidats sont moins performants. Vérifiez la distribution des candidats, et non seulement leur valeur maximale.
Améliore-t-il réellement ses capacités ?
Résoudre davantage de tâches peut indiquer une meilleure capacité d’autos’amélioration, mais il s’agit de métriques différentes. Une expérience plus rigoureuse vérifie si une nouvelle version produit des versions successeures meilleures que celles de son prédécesseur, avec le même budget alloué.
Ces questions ne visent pas à nier les progrès. Elles permettent de définir ces progrès avec suffisamment de précision pour les reconnaître.
Une expérience d’amélioration personnelle que vous pouvez mener
Un point de départ réaliste pour un développeur individuel ou une petite équipe consiste non pas à ouvrir tout le système à la modification autonome, mais à choisir un outil de développement spécifique et à le restreindre strictement. Prenons par exemple un outil de génération de tests pour une base de code Java :
- Résoudre ce qui ne peut pas changer : l’outil ne doit pas modifier le code de l’application ni les tests d’évaluation.
- Définir ce qui peut changer : uniquement sa propre stratégie de balayage des fichiers, ses instructions et son flux de travail de génération de tests.
Considérez cela comme une conception d’expérience, et non comme une promesse de résultats. L’utilisation de modèles ouverts ou de quotas gratuits peut réduire les coûts d’exécution, mais des exécutions moins chères ne prouvent pas que les modifications sont utiles. Cherchez d’abord un avantage clairement mesurable, et n’élargissez le champ d’application qu’une fois celui-ci obtenu. La même discipline d’évaluation s’applique à tout agent que vous déployez ; notre guide sur les boucles d’agentie bornées en TypeScript aborde l’aspect lié au temps de exécution pour maintenir un contrôle sur de telles boucles.
Des agents améliorés ne représentent pas une explosion de l’intelligence
Une intelligence artificielle peut-elle donc concevoir une meilleure intelligence artificielle ? Dans les expériences présentées ci-dessus, oui, dans un sens précis : les systèmes d’IA ont contribué à créer des agents plus performants, et plusieurs d’entre eux ont appliqué ce processus à leur propre logiciel. Ce qu’ils ne montrent pas, c’est une chaîne d’améliorations qui s’accélère à chaque itération, se généralise à différents domaines et fonctionne indépendamment des choix de conception humains. Considérer ce travail comme de simple « engineering de prompts » revient à ignorer les résultats réels ; le qualifier de début d’une explosion de l’intelligence en exagère la portée.
Points clés
- Il faut toujours se demander quel niveau a changé : les poids, le code de l’agent, les prompts, les outils ou bien l’outil d’amélioration lui-même.
- Les garanties formelles, comme celles de la Machine de Gödel, ne valent que par rapport à leurs hypothèses ; les approches empiriques substituent les preuves à l’évaluation, de sorte que la qualité de cette évaluation détermine tout.
Le problème difficile n’est pas de permettre à une IA de modifier son propre code. Il s’agit plutôt de démontrer de manière fiable qu’une modification représente un véritable progrès, et de transposer ce progrès dans la prochaine phase d’amélioration.