L’un des aspects marquants de notre façon de développer Composer est la manière dont nous utilisons les versions précédentes du modèle pour améliorer le processus d’entraînement des suivantes.

L’une des applications les plus évidentes de ce type d’amorçage est la configuration de l’environnement. L’entraînement RL nécessite des environnements opérationnels, et si l’environnement est défectueux dès le départ, le modèle gaspille des token à déboguer la configuration au lieu d’apprendre à résoudre des problèmes. Dans les cas les plus extrêmes, un environnement défaillant peut rendre un problème complètement insoluble, ce qui finit par consommer des ressources de calcul sans aucun signal de récompense.

Pour remédier à cela, nous avons développé autoinstall pour Composer, un système qui utilise des versions antérieures de Composer pour créer automatiquement des environnements RL fonctionnels à partir de dépôts Checkout mais non configurés. Lors de l’entraînement de la version la plus récente du modèle, Composer 2, nous avons utilisé son prédécesseur, Composer 1.5, pour gérer ce processus. Au-delà de la simple exécution d’instructions étape par étape, nous avons constaté que les modèles de codage modernes sont capables d’aller très loin pour configurer correctement un projet, simuler ses dépendances et vérifier que l’installation a bien réussi.

#De meilleurs environnements produisent de meilleurs signaux d’entraînement

Comme beaucoup d’aspects du développement de nos modèles, autoinstall s’inspire des systèmes de production de Cursor. Dans les Agents Cloud de Cursor, nous proposons une fonctionnalité qui automatise la configuration des environnements cloud pour les utilisateurs, afin de permettre à leurs agents de travailler sur des projets dans un environnement simulé. À partir d’un checkout Git, l’agent installe les paquets, configure les paramètres et exécute des vérifications de base pour s’assurer que le code fonctionne correctement et reste stable. Les requêtes ultérieures peuvent ainsi démarrer à partir d’une configuration correcte.

Pour l’entraînement RL, le sujet est encore plus central, mais aussi plus difficile. À partir d’un dépôt, l’objectif d’autoinstall est de créer une version de base simulée et exécutable de la base de code afin de pouvoir résoudre plus tard un problème de codage inédit. Cet environnement de base est essentiel, car Composer est entraîné avec un ensemble complet d’outils, notamment des commandes de lint propres au langage, la recherche et l’utilisation sandbox du shell. Si l’environnement n’est pas correctement configuré, l’entraînement devient inefficace et peut gaspiller des ressources de calcul sans produire de signal de récompense.

#Un agent définit la réussite, le suivant tente de l’atteindre

L’autoinstall se déroule en deux étapes. Dans la première étape, dite de « définition de l’objectif », nous donnons à l’agent Cursor la base de code à un Checkout fixe et lui demandons de proposer 10 commandes, ainsi qu’une description générale du résultat attendu si l’environnement était correctement configuré.

L’agent explore les README et Makefile de l’environnement, et essaie également des commandes courantes propres au langage, comme des gestionnaires de projet tels que uv ou des linters comme clippy. Le travail de l’agent consiste généralement en commandes d’installation, tests s’ils sont disponibles, et commandes de lancement pour les exécutables.

Dans la seconde étape, nous fournissons à un agent Composer distinct l’état initial de l’environnement ainsi que trois commandes cibles sélectionnées parmi les 10 proposées. L’agent explore alors la base de code, en utilisant des appels d’outils pour configurer l’environnement afin que les commandes puissent s’exécuter. Ensuite, nous vérifions que les trois commandes s’exécutent bien et que la sortie correspond à la description cible du premier agent. Sinon, nous relançons la seconde phase. Si, après cinq répétitions de ce processus, l’agent n’a pas réussi à configurer l’environnement de manière satisfaisante, nous écartons l’environnement.

Grâce à l’autoinstall, Composer vise à configurer correctement un environnement de la manière la plus complète possible. Pour y parvenir, il peut simuler des fichiers manquants, créer des images factices, ou même créer de fausses tables de base de données. Certains projets nécessitent l’installation de composants supplémentaires pour exécuter les tests, comme des dossiers S3 ou des conteneurs sidecar manquants. Composer les simule souvent aussi, en créant des configurations MinIO ou des conteneurs Docker pour les faire fonctionner. Pour prendre en charge les processus de longue durée, nous avons permis à l’autoinstall de créer un script de démarrage afin de les lancer au début de l’utilisation en RL.

#Autoinstall pour des projets réels

Pour illustrer le processus d’autoinstall, nous nous appuyons sur une expérience réelle dans laquelle nous avons utilisé autoinstall pour configurer un projet complexe en conditions réelles. Le projet, Celo, implémenté dans celo-org/celo-monorepo, est un vaste projet blockchain avec plusieurs dépendances majeures. Ce projet constitue un test intéressant pour autoinstall, car il faut gérer un grand nombre de dépendances pour l’installation, puis simuler un flux d’authentification pour le testing.

Lors de la première étape d’autoinstall, nous avons observé l’agent parcourir la documentation et le code du projet afin d’identifier les principales commandes d’installation. Cependant, la documentation incluse dans le projet est relativement limitée ; il a donc aussi utilisé des commandes Web pour chercher d’autres commandes d’installation sur le site de documentation du projet. La plupart des commandes identifiées concernaient des installations ou des tests, mais il a également retenu une application minimale permettant d’utiliser le logiciel à partir de la documentation.

Lors de la deuxième étape, l’agent avait pour mission d’exécuter concrètement ces commandes. Même si l’ensemble des tâches était clair, le modèle ne savait pas à l’avance quels problèmes il allait rencontrer. Dans ce cas précis, il a déterminé qu’il devait installer plusieurs dépendances supplémentaires, comme Foundry, un dépôt connexe. Il a utilisé la recherche Web pour consulter la documentation de ce projet requis. Il devait aussi exécuter une application minimale dans cet environnement. Lors de la première itération de cette étape, il n’est pas parvenu à lancer cette application de test, mais à la deuxième, il a trouvé qu’il pouvait créer un utilisateur fictif pour démarrer l’application en local et remplir cette exigence.

#Amorçage de la prochaine génération.

Autoinstall offre un exemple intéressant d’amorçage du processus de RL à partir d’un modèle précédent. Composer 2 obtient notamment un score nettement plus élevé sur Terminal-Bench (61,7 % contre 47,9 % pour Composer 1.5), un benchmark qui comprend des tests mesurant la capacité d’un modèle à configurer des environnements de développement. Cela indique que Composer 2 fournira une base améliorée pour autoinstall. Nous prévoyons que, lors des prochains cycles, les versions précédentes de Composer joueront un rôle important dans bien d’autres aspects du processus d’entraînement, notamment la gestion des exécutions, le prétraitement des données et l’optimisation de l’architecture.

En savoir plus sur Composer 2