Un aspecto destacado de cómo desarrollamos Composer es cómo usamos versiones anteriores del modelo para mejorar el proceso de entrenamiento de las siguientes.

Una de las oportunidades más claras para este tipo de arranque es la configuración del entorno. El entrenamiento con RL requiere entornos ejecutables, y si el entorno está roto desde el principio, el modelo desperdicia tokens depurando la configuración en lugar de aprender a resolver problemas. En los peores casos, un mal entorno puede hacer que un problema sea completamente irresoluble, lo que termina consumiendo cómputo sin ninguna señal de recompensa.

Para resolver esto, creamos Composer autoinstall, un sistema que usa modelos anteriores de Composer para crear automáticamente entornos de RL funcionales a partir de checkouts de repositorios sin configurar. Durante el entrenamiento de la versión más reciente del modelo, Composer 2, usamos su predecesor, Composer 1.5, para gestionar este proceso. Más allá de limitarse a seguir instrucciones paso a paso, vimos que los coding models modernos hacen grandes esfuerzos para configurar correctamente el entorno, simular las dependencias del proyecto y comprobar que la configuración se haya realizado con éxito.

#Mejores entornos significan una mejor señal de entrenamiento

Como en muchos otros aspectos del desarrollo de nuestros modelos, autoinstall está inspirado en sistemas de Cursor en producción. En los agentes Cloud de Cursor, contamos con una función que automatiza la configuración de entornos Cloud para los usuarios, de modo que sus agentes puedan trabajar en proyectos dentro de un entorno simulado. A partir de un checkout de git, el agente se encarga de instalar paquetes, configurar la configuración y ejecutar comprobaciones básicas para garantizar que el código se ejecute correctamente y sea estable. Esto permite que las solicitudes futuras partan de la configuración adecuada.

En el entrenamiento de RL, este problema es aún más central, aunque también puede ser difícil. A partir de un repositorio, el objetivo de autoinstall es crear una versión base simulada y ejecutable del codebase para poder resolver un problema de programación futuro y desconocido. Este entorno base es fundamental porque Composer se entrena con un conjunto completo de herramientas, incluidos comandos de lint para lenguajes de programación, búsqueda y uso del shell en sandbox. Si el entorno no se configura correctamente, el entrenamiento se vuelve ineficiente y puede desperdiciar cómputo sin generar ninguna señal de recompensa.

#Un agente define el éxito; el siguiente intenta alcanzarlo

La autoinstall ocurre en dos etapas. En la primera, de "definición del objetivo", le proporcionamos al agente de Cursor la codebase en un checkout fijo y le pedimos que proponga 10 comandos y una descripción general del resultado que debería producirse si el entorno estuviera correctamente configurado.

El agente explorará cualquier README o Makefile del entorno, además de probar comandos típicos del lenguaje, como gestores de proyectos como uv o linters como clippy. El trabajo del agente normalmente consistirá en comandos de configuración, pruebas si están disponibles y comandos de inicio para ejecutables.

En la segunda etapa, proporcionamos a un agente de Composer independiente el estado inicial del entorno, así como tres comandos objetivo seleccionados de los 10 propuestos. Luego, el agente explorará la codebase y realizará llamadas a herramienta para configurar el entorno de modo que los comandos puedan ejecutarse. Después, comprobamos que los tres comandos se ejecuten y que el resultado coincida con la descripción objetivo del primer agente. Si no es así, reiniciamos la segunda fase. Si, después de cinco repeticiones de este proceso, el agente no ha logrado configurar el entorno de forma satisfactoria, descartamos el entorno.

Mediante la autoinstall, Composer busca configurar correctamente un entorno de la manera más completa posible. Para lograrlo, puede simular archivos faltantes, crear imágenes de marcador de posición o incluso crear tablas de base de datos falsas. Algunos proyectos requieren instalar componentes adicionales necesarios para ejecutar pruebas, como carpetas de S3 o contenedores sidecar faltantes. Composer también suele simular estos elementos, creando configuraciones de MinIO o contenedores de Docker para que funcionen. Para admitir procesos de larga duración, permitimos que la autoinstall creara un script de inicio para ponerlos en marcha al comienzo del uso de RL.

#autoinstall para proyectos reales

Para ilustrar el proceso de autoinstall, tomemos un experimento real que realizamos, en el que usamos autoinstall para configurar un proyecto real y complejo. El proyecto, Celo, implementado en celo-org/celo-monorepo, es un gran proyecto de blockchain con varias dependencias importantes. Este proyecto es una prueba interesante de la autoinstall porque requiere gestionar un gran conjunto de dependencias para la instalación y luego simular un flujo de autenticación para Testing.

Durante la primera etapa de la autoinstall, observamos al agente revisar la documentación y el código del proyecto para encontrar los comandos clave de instalación. Sin embargo, la documentación incluida del proyecto es relativamente escasa, por lo que también usó comandos web para buscar más instrucciones de configuración en el sitio de documentación del proyecto. La mayoría de los comandos identificados eran de instalación o prueba, pero también incluían una aplicación mínima básica para usar el software a partir de la documentación.

En la segunda etapa, se le encargó al agente ejecutar realmente estos comandos. Aunque el conjunto de tareas estaba claro, el modelo no sabía de antemano qué problemas encontraría. En este caso concreto, descubrió que necesitaba instalar otras dependencias, como Foundry, un repositorio relacionado. Usó la búsqueda web para leer la documentación de este proyecto necesario. También se le encargó ejecutar una aplicación mínima en este entorno. En la primera iteración de esta etapa, no logró poner en marcha esta aplicación de prueba, pero en una segunda iteración descubrió que podía crear un usuario simulado para iniciar la aplicación localmente y cumplir el requisito.

#Arranque de la próxima generación.

Autoinstall representa un ejemplo interesante de arranque del proceso de RL a partir de un modelo anterior. En particular, Composer 2 ahora obtiene una puntuación significativamente más alta en Terminal-Bench (61,7 % frente al 47,9 % de Composer 1.5), un benchmark que incluye pruebas de la capacidad de un modelo para configurar entornos de desarrollo. Esto indica que Composer 2 proporcionará una base mejorada para autoinstall. Anticipamos que, en futuras ejecuciones, instancias anteriores de Composer desempeñarán un papel importante en muchos otros aspectos del proceso de entrenamiento, incluida la gestión de ejecuciones, el preprocesamiento de datos y el ajuste de la arquitectura.

Más información sobre Composer 2