Composer autoinstall: comment les anciennes versions aident à entraîner les nouvelles

Cursor a présenté Composer autoinstall — un système qui utilise les versions antérieures du modèle Composer pour préparer automatiquement les environnements à l'entraînement par apprentissage par renforcement. Lors du développement de Composer 2, l'équipe a utilisé la version 1.5 pour gérer ce processus. L'idée est basée sur l'expérience des Cursor cloud agents, mais appliquée à l'entraînement RL des modèles eux-mêmes.

Pourquoi les environnements cassés tuent l'apprentissage

L'entraînement RL nécessite des environnements fonctionnels. Si un projet ne compile pas, les dépendances ne s'installent pas ou que la configuration refuse de s'exécuter, le modèle gaspille les tokens sur le débogage au lieu d'apprendre à résoudre des problèmes de programmation réels. Dans les pires cas, un environnement cassé rend la tâche complètement insoluble — le modèle ne reçoit aucun signal de récompense et gaspille simplement le calcul en vain. C'est coûteux et inefficace.

Processus d'amorçage en deux étapes

Autoinstall fonctionne selon un schéma simple mais ingénieux. Étape 1 : L'agent éclaireur détermine l'objectif. La première version du modèle (Composer 1.

5) reçoit un référentiel dans un état fixe. Elle doit proposer 10 commandes et une description de haut niveau de leur sortie si l'environnement est correctement configuré. Le modèle étudie README et Makefile, essaie des commandes spécifiques à la langue (`uv`, `npm install`, `clippy`, `pytest`), et explore la structure du projet.

Le résultat est une liste de commandes de configuration, de tests et de scripts d'exécution. Étape 2 : Le second agent l'implémente. La deuxième version (Composer 2) reçoit l'état initial du projet plus trois commandes cibles sélectionnées parmi les dix proposées.

Sa tâche est d'appeler des outils (recherche, compilation, linter), d'explorer le code et de configurer l'environnement afin que les trois commandes s'exécutent et que leur sortie corresponde à la description de l'étape 1. Si ce n'est pas le cas — le processus se répète. Après cinq tentatives échouées, l'environnement est rejeté.

• Le modèle explore le code et exécute les outils de recherche
• Installe les dépendances via le gestionnaire de paquets
• Effectue la configuration (configuration, variables d'environnement)
• Vérifie la sortie par rapport à la description cible
• Répète jusqu'au succès ou limite de tentatives

Comment le modèle surmonte les composants manquants

Composer est prêt à aller loin pour réaliser un environnement fonctionnel. Le modèle simule les fichiers manquants, crée des stubs pour les images, même des tables fictives dans les bases de données. Si un projet a besoin de services cloud comme S3 ou de conteneurs sidecar, Composer crée leurs équivalents — des configurations MinIO pour S3, des conteneurs Docker pour les services. Pour les processus de longue durée, le système génère un script de démarrage qui lance ces composants au début de la session RL.

"Les modèles de langage modernes feront de grands efforts pour configurer avec succès un environnement, simuler les dépendances et tester que la configuration fonctionne", déclare l'équipe

Cursor.

Ce que cela signifie pour l'avenir

L'idée est simple, mais revêt une importance énorme. Composer utilise sa propre version antérieure comme aide pour préparer la base fonctionnelle de la nouvelle version. Cela non seulement économise le calcul, mais améliore aussi le signal pour l'apprentissage par renforcement. Chaque nouvelle version du modèle repose maintenant sur les épaules de ses prédécesseurs. Il est logique de supposer que à l'avenir, un tel amorçage deviendra un standard dans l'entraînement des grands modèles de langage.