Resumo Técnico: DeNovoSWE

Declaração do Problema

Embora agentes de código baseados em Grandes Modelos de Linguagem (LLMs) tenham demonstrado proficiência na correção de bugs localizados em bases de código existentes (ex: SWE-bench), suas capacidades em tarefas de engenharia de software de longo horizonte — especificamente o arquétipo e implementação de repositórios de software completos a partir de especificações de alto nível — permanecem subdesenvolvidas. Benchmarks atuais frequentemente falham em testar rigorosamente essas habilidades de raciocínio e implementação de longo horizonte, e os conjuntos de dados de treinamento existentes são predominantemente centrados em correções de problemas únicos, em vez de geração de repositórios inteiros.

O principal gargalo é a escassez de dados de geração de repositórios inteiros em larga escala e verificáveis. A construção de tais dados apresenta três desafios centrais:

1. Construção de Documentação: A documentação de repositórios existentes é frequentemente incompleta ou desalinhada com o comportamento executável, tornando-a insuficiente para definir tarefas de geração de documento-para-repositório.
2. Design de Avaliação: Há uma falta de protocolos objetivos e escaláveis para avaliar diversos repositórios através de testes executáveis.
3. Execução Livre de Vazamentos (Leakage-Free): Agentes modernos operando em ambientes interativos podem explorar canais não pretendidos (ex: recuperação de rede, histórico do git) para acessar implementações de referência, necessitando de um sandboxing robusto.

Metodologia: O Framework DeNovoSWE

Os autores introduzem o DeNovoSWE, um dataset de larga escala composto por 4.818 instâncias de alta qualidade onde agentes devem gerar um repositório completo do zero com base em documentação gerada. O dataset é construído via um fluxo de trabalho agente de sandbox automatizado empregando uma estratégia de "dividir para conquistar" acoplada a um mecanismo iterativo de crítico-reparo.

1. Arquitetura do Pipeline Automatizado

O processo de construção é dividido em duas fases principais:

• Fase de Divisão (Decomposição):

  • Perfilamento de Repositório: O sistema executa testes unitários para capturar rastros de execução (runtime traces), categorizando unidades de implementação em componentes diretos (explicitamente testados), indiretos essenciais (necessários para o comportamento) e indiretos não essenciais (detalhes internos).
  • Particionamento de Capacidade: Um escritor de visão geral gera um resumo de alto nível, seguido por um escritor de capacidades que decompõe o repositório em distintas capacidades funcionais.
  • Mapeamento: Um classificador baseado em LLM mapeia funções e classes específicas a essas capacidades, garantindo que a documentação esteja fundamentada em unidades de implementação reais.

• Fase de Conquista (Refinamento Iterativo):

  • Agente de Rascunho (Draft Agent): Gera a documentação inicial para cada capacidade, inspecionando o código-fonte dentro de um ambiente de sandbox.
  • Agente Crítico (Critic Agent): Avalia o rascunho quanto à organização estrutural, cobertura de componentes diretos/indiretos essenciais e especificidade da API. Ele identifica omissões ou detalhes subespecificados sem vazar o comportamento específico dos testes.
  • Agente de Reparo (Repair Agent): Refina iterativamente a documentação com base no feedback do crítico, inspecionando o repositório de origem para resolver inconsistências.
  • Fusão (Merging): Os documentos finais de nível de capacidade são fundidos com a visão geral do repositório para formar a documentação completa da tarefa.

2. Avaliação e Prevenção de Vazamento

Para garantir a validade da tarefa "documento-para-repositório", o framework impõe um confinamento estrito:

• Pré-limpeza (Pre-cleanup): O código e as suítes de teste do repositório alvo são removidos, mantendo apenas as configurações de build.
• Purga de Vazamentos (Leak Purging): O processo apaga site-packages, caches do pip e artefatos de compilação transitórios.
• Sanitização de Git: O diretório .git é destruído e reinicializado para evitar que agentes realizem engenharia reversa do histórico via git reflog.
• Restrições de Tempo de Execução: Containers Docker impõem restrições de comando para bloquear a recuperação via rede (ex: pip install, curl) do pacote alvo, suplementado por auditoria via LLM dos rastros de execução.

3. Filtragem de Trajetória Consciente de Dificuldade

Reconhecendo que trajetórias totalmente bem-sucedidas são difíceis de obter para repositórios complexos, os autores propõem uma estratégia de filtragem de trajetória consciente de dificuldade em vez de usar um limiar global fixo.

• Pontuação de Dificuldade: O framework estima a dificuldade da tarefa usando sinais estruturais (contagens de linhas executáveis) e julgamentos qualitativos baseados em LLM.
• Limiares Adaptativos: Os limiares de filtragem são ajustados com base na dificuldade estimada. Tarefas mais fáceis exigem altas taxas de sucesso (ex: 0,90), enquanto tarefas mais difíceis aceitam taxas menores (ex: 0,60) para reter sucessos parciais informativos. Isso equilibra a qualidade dos dados com a diversidade de instâncias desafiadoras.

Principais Contribuições

1. Dataset DeNovoSWE: Um dataset de larga escala de 4.818 instâncias de geração de documento-para-repositório, construído automaticamente via um pipeline multi-agente em sandbox. É aproximadamente 46× maior que benchmarks anteriores de geração de repositório como o NL2Repo.
2. Pipeline de Construção Automatizado: Um fluxo de trabalho inovador que combina decomposição de dividir-para-conquistar com mecanismos iterativos de crítico-reparo para sintetizar documentação abrangente e alinhada aos testes sem anotação humana.
3. Filtragem Consciente de Dificuldade: Uma estratégia para curar trajetórias de treinamento que equilibra fidelidade de execução com diversidade de tarefas, evitando a exclusão de instâncias difíceis valiosas enquanto filtra o ruído de tarefas fáceis.
4. DeNovoSWE-Agent: Um modelo ajustado (fine-tuned) que demonstra melhorias substanciais em capacidades de SWE de longo horizonte.

Resultados Experimentais

Os autores avaliaram o impacto do DeNovoSWE ajustando (fine-tuning) os modelos Qwen3-30B-A3B e Qwen3.5-35B-A3B no dataset.

• Ganhos de Desempenho: O ajuste fino do Qwen3-30B-A3B no DeNovoSWE elevou sua pontuação no benchmark BeyondSWE-Doc2Repo de 5,8% para 47,2%.
• Comparação com Modelos Proprietários: O modelo ajustado DeNovoSWE-Agent-35A3B alcançou 50,0% no BeyondSWE-Doc2Repo, diminuindo a lacuna para modelos de fronteira proprietários (ex: dentro de 2,0 pontos percentuais do Gemini3-Pro), apesar de usar um backbone de pesos abertos menor.
• Estudos de Ablação: Experimentos confirmaram que a filtragem consciente de dificuldade supera os limiares globais fixos. Um limiar fixo de 0,95 resultou em desempenho inferior (48,1%) comparado à estratégia adaptativa (50,0%), destacando a importância de reter trajetórias diversas e desafiadoras.

Significância

O artigo afirma que o DeNovoSWE aborda uma lacuna crítica em dados de treinamento de SWE de longo horizonte verificáveis. Ao mudar o foco de correções de problemas localizados para a geração de repositórios inteiros, o dataset permite o treinamento de agentes capazes de construção de repositórios em nível de arquiteto. Os resultados sugerem que dados de treinamento de alta qualidade e longo horizonte são um fator decisivo para melhorar a capacidade de um agente de gerar sistemas de software completos do zero, potencialmente diminuindo a lacuna de desempenho entre modelos de pesos abertos e modelos de fronteira proprietários em tarefas complexas de engenharia de software.