Composer mit autoinstall bootstrappen
Ein bemerkenswerter Aspekt unserer Composer-Entwicklung ist, wie wir frühere Versionen des Modells nutzen, um den Trainingsprozess für künftige Versionen zu verbessern.
Eine der naheliegendsten Möglichkeiten für diese Art von Bootstrappen ist die Einrichtung der Umgebung. RL-Training erfordert lauffähige Umgebungen, und wenn die Umgebung zu Beginn fehlerhaft ist, verschwendet das Modell Token mit der Fehlersuche im Setup, statt zu lernen, Probleme zu lösen. Im schlimmsten Fall kann eine schlechte Umgebung ein Problem sogar vollständig unlösbar machen, was letztlich Rechenleistung ohne jedes Belohnungssignal verbrennt.
Um dieses Problem anzugehen, haben wir Composer autoinstall entwickelt, ein System, das frühere Composer-Modelle nutzt, um aus nicht konfigurierten Repository-Checkouts automatisch funktionierende RL-Umgebungen zu erstellen. Beim Training der neuesten Modellversion, Composer 2, haben wir dafür seinen Vorgänger Composer 1.5 eingesetzt, um diesen Prozess zu steuern. Wir haben festgestellt, dass moderne Coding-Modelle weit über das bloße Befolgen von Schritt-für-Schritt-Anweisungen hinausgehen, um Projekte erfolgreich zu konfigurieren, Projektabhängigkeiten zu mocken und zu überprüfen, ob das Setup funktioniert.
Bessere Umgebungen bedeuten bessere Trainingssignale
Wie viele Aspekte unserer Modellentwicklung ist autoinstall von den Cursor-Produktionssystemen inspiriert. In den Cloud-Agenten von Cursor haben wir ein Feature, das das Setup von Cloud-Umgebungen für Benutzer automatisiert, damit ihre Agenten in einer simulierten Umgebung an Projekten arbeiten können. Ausgehend von einem Git-Checkout arbeitet der Agent daran, Pakete zu installieren, Einstellungen zu konfigurieren und grundlegende Prüfungen auszuführen, um sicherzustellen, dass der Code läuft und stabil ist. So können zukünftige Anfragen mit dem richtigen Setup starten.
Für das RL-Training ist dieses Problem sogar noch zentraler, kann aber anspruchsvoll sein. Ausgehend von einem Repository ist das Ziel von autoinstall, eine lauffähige simulierte Basisversion der Codebasis zu erstellen, um ein zukünftiges, noch unbekanntes Programmierproblem zu lösen. Diese Basisumgebung ist entscheidend, weil Composer mit einem vollständigen Satz an Tools trainiert wird, einschließlich Lint-Befehlen für Programmiersprachen, Suche und der isolierten Nutzung der Shell. Wird die Umgebung nicht korrekt eingerichtet, wird das Training ineffizient und Rechenleistung kann ohne Belohnungssignal verschwendet werden.
Ein Agent definiert den Erfolg, der nächste versucht, ihn zu erreichen
Autoinstall läuft in zwei Stufen ab. In der ersten Stufe, der „Zielfestlegung“, geben wir dem Cursor-Agent die Codebasis in einem festen Checkout und bitten ihn, 10 Befehle sowie eine allgemeine Beschreibung der Ausgabe vorzuschlagen, die bei korrekt eingerichteter Umgebung ausgeführt werden sollten.
Der Agent untersucht alle Readmes oder Makefiles zur Umgebung und probiert außerdem typische sprachspezifische Befehle aus, etwa Projektmanager wie uv oder Linter wie clippy. Die Arbeit des Agenten besteht dabei in der Regel aus Setup-Befehlen, Tests, sofern vorhanden, und Startbefehlen für ausführbare Programme.
In der zweiten Stufe stellen wir einem separaten Composer-Agent den Anfangszustand der Umgebung sowie drei aus den vorgeschlagenen 10 ausgewählte Zielbefehle bereit. Der Agent untersucht dann die Codebasis und nutzt Tool-Aufrufe, um die Umgebung so einzurichten, dass die Befehle ausgeführt werden können. Anschließend prüfen wir, ob alle drei Befehle laufen und ob die Ausgabe der Zielbeschreibung des ersten Agenten entspricht. Falls nicht, starten wir die zweite Phase erneut. Wenn es dem Agenten auch nach fünf Wiederholungen dieses Prozesses nicht gelingt, die Umgebung in zufriedenstellendem Maß einzurichten, verwerfen wir die Umgebung.
Mit Autoinstall will Composer eine Umgebung so vollständig und korrekt wie möglich einrichten. Um das zu erreichen, mockt es fehlende Dateien, erstellt Platzhalterbilder oder legt sogar gefälschte Datenbanktabellen an. Einige Projekte erfordern die Installation zusätzlicher Komponenten, die zum Ausführen von Tests benötigt werden, etwa S3-Ordner oder fehlende Sidecar-Container. Auch diese mockt Composer häufig und erstellt dazu MinIO-Konfigurationen oder Docker-Container, damit sie funktionieren. Um lang laufende Prozesse zu unterstützen, haben wir Autoinstall erlaubt, ein Startskript zu erstellen, das sie zu Beginn der RL-Nutzung startet.
Autoinstall für reale Projekte
Um den Autoinstall-Prozess zu veranschaulichen, betrachten wir ein reales Experiment, bei dem wir autoinstall genutzt haben, um ein komplexes reales Projekt einzurichten. Das Projekt Celo, implementiert in celo-org/celo-monorepo, ist ein großes Blockchain-Projekt mit mehreren wichtigen Abhängigkeiten. Dieses Projekt ist ein interessanter Test für autoinstall, da dafür eine große Anzahl von Abhängigkeiten installiert und anschließend ein Authentifizierungsablauf für das Testing gemockt werden muss.
In der ersten Autoinstall-Stufe haben wir beobachtet, wie der Agent die Dokumentation und den Code des Projekts durchging, um die wichtigsten Installationsbefehle zu finden. Da die enthaltene Dokumentation des Projekts jedoch relativ knapp ist, nutzte er auch Web-Befehle, um die Dokumentationswebsite des Projekts nach weiteren Setup-Befehlen zu durchsuchen. Die meisten der identifizierten Befehle betrafen Installationen oder Tests, es war jedoch auch eine einfache minimale Anwendung enthalten, um die Software anhand der Dokumentation zu nutzen.
In der zweiten Stufe bestand die Aufgabe des Agenten darin, diese Befehle tatsächlich zum Laufen zu bringen. Obwohl die Aufgaben klar waren, wusste das Modell nicht im Voraus, auf welche Probleme es stoßen würde. In diesem speziellen Fall stellte es fest, dass es mehrere weitere Abhängigkeiten wie Foundry, ein verwandtes Repo, installieren musste. Es nutzte die Websuche, um die Dokumentation dieses erforderlichen Projekts zu lesen. Außerdem sollte es in dieser Umgebung eine minimale Anwendung ausführen. Im ersten Durchlauf dieser Stufe gelang es ihm nicht, diese Testanwendung zum Laufen zu bringen, aber im zweiten Durchlauf stellte es fest, dass es einen Mock-Benutzer erstellen konnte, um die Anwendung lokal zu starten und die Anforderung zu erfüllen.
Die nächste Generation bootstrappen.
Autoinstall ist ein interessantes Beispiel dafür, den RL-Prozess mit einem früheren Modell zu bootstrappen. Bemerkenswert ist, dass Composer 2 bei Terminal-Bench nun deutlich besser abschneidet (61,7 % gegenüber 47,9 % bei Composer 1.5) – einem Benchmark, der unter anderem testet, wie gut ein Modell Entwicklerumgebungen einrichten kann. Das deutet darauf hin, dass Composer 2 eine bessere Grundlage für autoinstall bieten wird. Wir gehen davon aus, dass frühere Composer-Instanzen in zukünftigen Runs auch in vielen anderen Bereichen des Trainingsprozesses eine große Rolle spielen werden, einschließlich Run-Management, Datenvorverarbeitung und Architektur-Tuning.
