Resumo Técnico: Composer 2 – Relatório da Equipe de Pesquisa Cursor

1. Introdução e Problema

O Composer 2 é um modelo especializado em engenharia de software agêntica, projetado para demonstrar forte capacidade de planejamento de longo prazo e inteligência de codificação, mantendo a eficiência para uso interativo.

O problema central abordado pelo relatório é a desconexão entre benchmarks públicos de codificação e a utilidade no mundo real. Os autores argumentam que benchmarks existentes (como SWE-bench e Terminal-Bench) frequentemente falham em capturar a complexidade real do desenvolvimento de software devido a:

• Mismatch de Domínio: Foco excessivo em correção de bugs isolada em vez de fluxos de trabalho completos.
• Especificação Excessiva de Prompts: Benchmarks públicos tendem a ter prompts altamente detalhados, enquanto solicitações reais de desenvolvedores são ambíguas e exigem interpretação.
• Contaminação de Dados: O risco de overfitting devido à presença de dados de benchmarks públicos nas misturas de treinamento.
• Escopo de Avaliação Restrito: A maioria mede apenas a correção funcional, ignorando qualidade de código, latência, custo e comportamento interativo.

2. Metodologia

O treinamento do Composer 2 segue uma abordagem de duas fases, combinando pré-treinamento contínuo e aprendizado por reforço (RL) em larga escala, tudo executado dentro de uma infraestrutura que emula fielmente o ambiente de produção do Cursor.

2.1. Pré-treinamento Contínuo

• Modelo Base: Seleção do Kimi K2.5 (um modelo MoE de 1,04T de parâmetros totais e 32B ativos) como base.
• Estratégia: O modelo passou por um pré-treinamento contínuo em uma mistura de dados dominada por código.
  • Fases: 32k tokens (maior parte do compute), extensão para 256k tokens (contexto longo) e uma fase curta de SFT (Supervised Fine-Tuning) em tarefas de codificação direcionadas.
  • Multi-Token Prediction (MTP): Adição de camadas MTP treinadas do zero para acelerar a inferência via speculative decoding.
• Objetivo: Melhorar o conhecimento base de codificação e a capacidade latente antes do RL.

2.2. Aprendizado por Reforço (RL) Assíncrono

O RL é o núcleo da melhoria de desempenho, focado em resolver problemas de engenharia de software complexos.

• Ambiente de Treinamento: Utiliza o mesmo harness (ferramentas e estrutura) do Cursor em produção, incluindo edição de arquivos, execução de comandos shell, busca semântica e navegação na web.
• Distribuição de Tarefas: Baseada em casos de uso reais (depuração, novas funcionalidades, refatoração, testes), com uma distribuição que inclui tarefas de longo horizonte.
• Algoritmo:
  • Uso de gradientes de política com múltiplas amostras por prompt.
  • Regime de single-epoch (cada prompt é treinado apenas uma vez).
  • RL Assíncrono: Separação completa entre geradores de rollouts (inferência) e trabalhadores de treinamento, com sincronização rápida de pesos para minimizar a divergência off-policy.
  • Regularização: Uso do estimador padrão $k_1 = -\log r$ para Divergência KL, evitando a variância explosiva de outros estimadores quando as distribuições divergem.
• Auto-Resumo (Self-Summarization): Técnica para permitir que o agente opere em horizontes longos, condensando o histórico de interações em resumos que são recompensados, permitindo o processamento de mais informações dentro de uma janela de contexto limitada.
• Penalidades Não Lineares: Introdução de penalidades de comprimento não lineares para incentivar eficiência (respostas rápidas em tarefas fáceis) sem sacrificar o raciocínio em tarefas difíceis.

2.3. Infraestrutura de Treinamento

• Paralelismo: Uso de Context Parallelism (CP) como eixo principal para contexto longo, combinado com Expert Parallelism (EP) e Data Parallelism (FSDP).
• Precisão: Treinamento em MXFP8 e NVFP4 (usando GPUs NVIDIA Blackwell).
  • Forward pass em NVFP4 (para estabilidade e compatibilidade com inferência).
  • Backward pass em MXFP8 (para estabilidade numérica no cluster de treinamento).
• Escalabilidade: Pipeline assíncrono distribuído em múltiplas regiões (3 regiões para GPU, 4 para CPU), utilizando Ray e PyTorch, com checkpointing a nível de rollout para tolerância a falhas.

3. Contribuições Chave

1. CursorBench: Uma nova suite de avaliação interna derivada de sessões reais de codificação da equipe de engenharia do Cursor.
   • Diferencia-se por ter prompts menos especificados (ambiguidade real) e exigir mudanças de código muito mais extensas (médiana de 181 linhas vs. 7-10 linhas em SWE-bench).
   • Elimina a contaminação de dados de treinamento.
2. Pipeline de RL Assíncrono em Larga Escala: Uma arquitetura robusta que permite treinamento estável com geradores de rollout e treinadores desacoplados, utilizando sincronização de pesos em voo e replay de roteamento de especialistas (MoE) para garantir consistência.
3. Otimização de Kernel e Precisão: Implementação de kernels proprietários (CUDA, ThunderKittens) otimizados para MoE em baixa precisão (NVFP4/MXFP8), garantindo estabilidade numérica e eficiência computacional.
4. Prova de Conceito de Especialização: Demonstra que um modelo generalista pode ser transformado em um especialista de ponta (frontier-level) através de pré-treinamento contínuo focado e RL, superando modelos generalistas maiores em tarefas específicas de codificação com menor custo.

4. Resultados

O Composer 2 alcançou desempenho competitivo com os modelos de ponta (SOTA) em diversas métricas:

• CursorBench:
  • Acurácia: 61,3% (uma melhoria de 37% relativa sobre o Composer 1.5 e 61% sobre o Composer 1).
  • Eficiência: Alcança desempenho de ponta com um custo de inferência significativamente menor do que modelos maiores (como GPT-5 ou Opus), ocupando uma fronteira de Pareto ótima entre custo e precisão.
• Benchmarks Públicos:
  • SWE-bench Multilingual: 73,7% (melhoria de 7,8% sobre o Composer 1.5).
  • Terminal-Bench: 61,7% (melhoria de 13,8% sobre o Composer 1.5).
• Comparação com a Base: O Composer 2 supera drasticamente seu modelo base (Kimi K2.5), validando a eficácia do pipeline de pré-treinamento e RL.
• Comportamento: O modelo demonstra melhoria tanto no desempenho médio quanto no desempenho "best-of-K" (melhor tentativa entre várias), indicando que o RL não apenas repondera trajetórias existentes, mas expande a cobertura de soluções corretas.

5. Significado e Conclusão

O relatório do Composer 2 estabelece um novo paradigma para o desenvolvimento de agentes de software:

• Validação da Especialização: Confirma que a especialização profunda em um domínio (codificação) via RL e pré-treinamento contínuo pode superar modelos generalistas massivos em tarefas complexas, com custos operacionais reduzidos.
• Importância do Ambiente Real: A ênfase em treinar e avaliar em ambientes que espelham fielmente o uso real (mesmas ferramentas, mesma ambiguidade) é crucial para o progresso real, superando a otimização excessiva para benchmarks artificiais.
• Escalabilidade Futura: Os resultados sugerem que há muito espaço para melhorias através de escalamento adicional, especialmente no manejo de problemas de horizonte extremamente longo (horas de trabalho humano), indicando que a próxima geração de agentes de IA será capaz de assumir tarefas de engenharia de software autônomas muito mais complexas.

Em suma, o Composer 2 não é apenas uma melhoria incremental, mas uma demonstração de como a engenharia de infraestrutura, a seleção cuidadosa de dados e o treinamento por reforço em larga escala podem criar agentes de codificação altamente eficazes e economicamente viáveis.