Um aspecto importante de como desenvolvemos o Composer é a forma como usamos versões anteriores do modelo para aprimorar o processo de treinamento das próximas.

Uma das oportunidades mais claras para esse tipo de inicialização está na configuração do ambiente. O treinamento de RL exige ambientes prontos para execução e, se o ambiente estiver com problemas logo no início, o modelo desperdiça tokens depurando a configuração em vez de aprender a resolver problemas. Nos piores casos, um ambiente ruim pode até tornar um problema insolúvel, consumindo recursos computacionais sem gerar nenhum sinal de recompensa.

Para resolver isso, desenvolvemos o autoinstall do Composer, um sistema que usa modelos anteriores do Composer para criar automaticamente ambientes de RL funcionais a partir de checkouts de repositórios ainda não configurados. Durante o treinamento da versão mais recente do modelo, o Composer 2, usamos seu predecessor, o Composer 1.5, para conduzir esse processo. Além de simplesmente seguir instruções passo a passo, constatamos que os modelos de código modernos fazem um grande esforço para configurar tudo corretamente, simular dependências do projeto e verificar se a configuração foi concluída com sucesso.

#Ambientes melhores geram melhores sinais de treinamento

Como muitos aspectos do desenvolvimento dos nossos modelos, o autoinstall é inspirado nos sistemas de produção do Cursor. Nos agentes na nuvem do Cursor, temos um recurso que automatiza a configuração de ambientes na nuvem para os usuários, permitindo que seus agentes trabalhem em projetos em um ambiente simulado. Partindo de um checkout do Git, o agente instala pacotes, configura ajustes e executa verificações básicas para garantir que o código esteja rodando de forma estável. Isso permite que requisições futuras partam da configuração correta.

No treinamento de RL, esse problema é ainda mais central, mas pode ser desafiador. Partindo de um repositório, o objetivo do autoinstall é criar uma versão base simulada e executável da base de código para resolver um problema de programação futuro e ainda desconhecido. Esse ambiente base é crítico porque o Composer é treinado com um conjunto completo de ferramentas, incluindo comandos de lint da linguagem de programação, busca e uso isolado do shell. Quando o ambiente não é configurado corretamente, o treinamento se torna ineficiente e pode desperdiçar recursos computacionais sem gerar nenhum sinal de recompensa.

#Um agente define o sucesso, o próximo tenta alcançá-lo

O autoinstall ocorre em duas etapas. Na primeira, de "definição de objetivo", damos ao agente do Cursor a base de código em um checkout fixo e pedimos que proponha 10 comandos e uma descrição geral da saída esperada caso o ambiente estivesse configurado corretamente.

O agente explora qualquer readme ou makefile do ambiente, além de experimentar comandos típicos da linguagem, como gerenciadores de projeto como uv ou linters como clippy. Em geral, o trabalho do agente consiste em comandos de configuração, testes, quando disponíveis, e comandos de inicialização de executáveis.

Na segunda etapa, fornecemos a um agente Composer separado o estado inicial do ambiente, bem como três comandos-alvo selecionados entre os 10 propostos. O agente então explora a base de código, fazendo chamadas de ferramenta para configurar o ambiente de modo que os comandos possam ser executados. Depois, verificamos se os três comandos são executados e se a saída corresponde à descrição-alvo do primeiro agente. Caso contrário, reiniciamos a segunda fase. Se, após cinco repetições desse processo, o agente ainda não tiver conseguido configurar o ambiente de forma satisfatória, descartamos o ambiente.

Por meio do autoinstall, o Composer busca configurar corretamente um ambiente da forma mais completa possível. Para isso, ele pode simular arquivos ausentes, criar imagens placeholder ou até mesmo criar tabelas falsas no banco de dados. Alguns projetos exigem a instalação de componentes adicionais necessários para executar testes, como pastas S3 ou contêineres sidecar ausentes. O Composer também costuma simulá-los, criando configurações do MinIO ou contêineres Docker para fazê-los funcionar. Para dar suporte a processos de longa duração, permitimos que o autoinstall criasse um script de inicialização para executá-los no começo do uso de RL.

#Autoinstall para projetos reais

Para ilustrar o processo de autoinstall, vamos considerar um experimento real que conduzimos, no qual usamos o autoinstall para configurar um projeto real complexo. O projeto, o Celo, implementado em celo-org/celo-monorepo, é um grande projeto de blockchain com várias dependências importantes. Esse projeto é um teste interessante para o autoinstall porque exige gerenciar um grande conjunto de dependências para a instalação e depois simular um fluxo de autenticação para Testing.

Durante a primeira etapa do autoinstall, observamos o agente percorrer a documentação e o código do projeto para encontrar os principais comandos de instalação. No entanto, a documentação incluída no projeto é relativamente escassa, então ele também usou comandos web para buscar mais comandos de configuração no site de documentação do projeto. A maioria dos comandos identificados envolvia instalações ou testes, mas também incluía uma aplicação mínima básica para usar o software com base na documentação.

Na segunda etapa, o agente recebeu a tarefa de realmente executar esses comandos. Embora o conjunto de tarefas fosse claro, o modelo não sabia de antemão quais problemas encontraria. Nesse caso específico, ele identificou que precisava instalar várias outras dependências, como Foundry, um repositório relacionado. Ele usou busca na web para ler a documentação desse projeto necessário. Também recebeu a tarefa de executar uma aplicação mínima nesse ambiente. Na primeira iteração dessa etapa, ele não conseguiu executar essa aplicação de teste, mas, em uma segunda iteração, percebeu que podia criar um usuário simulado para iniciar a aplicação localmente e atender ao requisito.

#Construindo a próxima geração.

O Autoinstall é um exemplo interessante de como impulsionar o processo de RL com um modelo anterior. Notavelmente, o Composer 2 agora tem uma pontuação significativamente mais alta no Terminal-Bench (61,7% versus 47,9% do Composer 1.5), um benchmark que inclui testes da capacidade de um modelo de configurar ambientes de desenvolvedor. Isso indica que o Composer 2 fornecerá uma base melhor para o autoinstall. Prevemos que, em execuções futuras, versões anteriores do Composer terão um papel importante em muitos outros aspectos do processo de treinamento, incluindo gerenciamento de execuções, pré-processamento de dados e ajuste de arquitetura.

Saiba mais sobre o Composer 2