SwingArena: Competitive Programming Arena for Long-context GitHub Issue Solving

O artigo apresenta o SwingArena, um novo framework de avaliação competitiva para modelos de linguagem grande que simula fluxos de trabalho reais de desenvolvimento de software, utilizando um módulo de geração de código aumentado por recuperação para resolver problemas de longo contexto no GitHub e comparar o desempenho de diferentes modelos na geração de correções e validação de testes.

O essencial

Imagine que você tem um grupo de robôs superinteligentes (chamados de Modelos de Linguagem ou LLMs) que aprendem a programar lendo milhões de livros de código. Até agora, para ver se eles eram bons, os cientistas faziam testes parecidos com provas de matemática de escola: davam um problema pequeno, isolado, e perguntavam: "O robô conseguiu escrever a resposta certa?".

O problema é que programar no mundo real não é como fazer uma prova de matemática sozinha. É como construir um prédio gigante, onde você precisa conversar com outros engenheiros, seguir regras de segurança, e lidar com materiais que mudam o tempo todo.

Aqui entra o SWINGARENA, o novo "campo de batalha" criado pelos pesquisadores para testar esses robôs de uma forma muito mais realista.

O Que é o SWINGARENA? (A Analogia da Arena de Boxe)

Pense no SWINGARENA como uma arena de boxe, mas em vez de socos, eles trocam códigos de computador e testes.

1. Dois Papéis, Um Jogo: Em vez de um robô trabalhando sozinho, o sistema coloca dois robôs para brigar (ou colaborar):

   • O "Atacante" (Submitter): Ele recebe um problema (ex: "O botão de login não funciona") e tenta consertar o código.
   • O "Defensor" (Reviewer): Ele olha o conserto do Atacante e tenta criar um teste difícil para ver se o conserto quebra algo ou se esconde um erro. É como um fiscal de obras que tenta encontrar rachaduras na parede que o pedreiro acabou de pintar.

2. O Árbitro (CI Pipeline): Existe um juiz automático que não deixa ninguém trapacear. Ele pega o conserto e o teste e roda em um ambiente seguro (como um laboratório isolado). Se o código der erro, o robô perde pontos. Se o teste for muito fácil ou não funcionar, o robô que criou o teste perde pontos.

3. O Ciclo Infinito: Eles não param na primeira tentativa. O Atacante tenta, o Defensor critica, o Atacante melhora, o Defensor tenta de novo. Isso simula exatamente como os programadores humanos trabalham em empresas grandes: enviando correções, recebendo críticas e melhorando até ficar perfeito.

O Grande Desafio: A Biblioteca Infinita

Um dos maiores problemas para esses robôs é que os projetos de software reais são gigantescos. Imagine tentar consertar um vazamento em um navio, mas você precisa procurar qual é a válvula certa em meio a 10.000 mapas diferentes espalhados por um oceano.

Se você der todo o oceano para o robô ler de uma vez, ele se afoga (o computador fica lento ou confuso).

Para resolver isso, o SWINGARENA usa um Sistema de Busca Inteligente (RACG):

• É como se o robô tivesse um bibliotecário mágico.
• Quando o robô precisa consertar um problema, ele pergunta ao bibliotecário: "Onde está a parte do código que lida com login?".
• O bibliotecário não entrega os 10.000 mapas. Ele entrega apenas 5 páginas que são realmente importantes para aquele problema específico. Isso permite que o robô foque no que importa, sem se perder.

O Que Eles Descobriram?

Os pesquisadores testaram robôs famosos (como GPT-4, Claude, Gemini e DeepSeek) nessa arena e descobriram coisas interessantes:

• Alguns são agressivos, outros são cautelosos: O robô GPT-4 é como um jogador de futebol que chuta muito forte e tenta marcar gol a qualquer custo. Ele cria correções arriscadas, mas que muitas vezes funcionam. Já o DeepSeek e o Gemini são mais como defensores: eles fazem correções mais seguras e que raramente quebram o sistema, mesmo que demorem um pouco mais.
• Nenhum é perfeito: Mesmo os robôs mais inteligentes falham quando o problema exige mudar muitas partes do código ao mesmo tempo ou quando precisam entender regras de segurança complexas.
• A importância do "Defensor": O robô que cria os testes (o Defensor) é tão importante quanto o que conserta. Se o Defensor for "preguiçoso" e criar testes fáceis, o Atacante ganha pontos falsos. O SWINGARENA força os robôs a serem rigorosos.

Por Que Isso Importa?

Antes, os robôs de programação eram como estudantes que tiravam 10 na prova, mas não conseguiam fazer uma redação. O SWINGARENA mostra que, para o futuro, precisamos de robôs que não só escrevam código, mas que saibam trabalhar em equipe, seguir regras e lidar com problemas grandes e complexos como um engenheiro humano faria.

Em resumo: O SWINGARENA transformou o teste de robôs de "fazer a lição de casa" para "trabalhar no dia a dia de uma empresa de tecnologia", garantindo que, quando usarmos esses robôs no futuro, eles não vão quebrar nossos softwares, mas sim ajudar a construí-los com segurança.

Resumo técnico

Resumo Técnico: SWINGARENA

1. O Problema

Os benchmarks atuais para avaliar Grandes Modelos de Linguagem (LLMs) em engenharia de software (como HumanEval, MBPP e até o SWE-Bench) apresentam limitações críticas ao tentar simular o desenvolvimento de software do mundo real:

• Natureza Estática: A maioria foca na correção funcional de trechos de código isolados ou em testes unitários estáticos, ignorando o fluxo iterativo e colaborativo do desenvolvimento.
• Falta de Adversarialidade: Eles não simulam a dinâmica de "submissão e revisão" onde um desenvolvedor propõe uma correção e outro (ou o sistema) tenta encontrar falhas, edge cases ou violações de estilo.
• Ignorância de Pipelines CI/CD: Poucos benchmarks exigem que o código passe por pipelines completos de Integração Contínua (CI), incluindo linters, verificações de segurança, testes de regressão e validação de compatibilidade com bases de código massivas.
• Desafio de Contexto Longo: LLMs frequentemente falham ao analisar repositórios grandes onde a informação necessária está dispersa em milhares de linhas e múltiplos arquivos, e as soluções atuais de recuperação de contexto são muitas vezes insuficientes ou não integradas a avaliações adversariais.

2. Metodologia

O SWINGARENA propõe um novo paradigma de avaliação baseado em um ambiente adversarial dinâmico que simula o fluxo de trabalho real de um repositório GitHub.

• Arquitetura Dual (Submissora vs. Revisora):
  • O framework emparelha dois agentes LLM: um atua como Submissora (gera patches para corrigir issues) e o outro como Revisora (cria casos de teste para desafiar a correção e verificar a robustez).
  • Eles alternam de papéis em múltiplas rodadas, criando um ciclo de feedback iterativo semelhante ao de desenvolvedores humanos.
• Validação via Integração Contínua (CI):
  • Diferente de testes simulados, o SWINGARENA executa os patches e testes gerados dentro de containers Docker isolados, replicando exatamente os pipelines CI nativos do repositório (ex: GitHub Actions, Travis CI).
  • O sistema verifica compilação, testes unitários, linters, e regras de estilo. O sucesso é definido pela capacidade do patch de passar em todos os gates do CI, não apenas em um teste específico.
• Módulo RACG (Retrieval-Augmented Code Generation):
  • Para lidar com o contexto longo, o sistema utiliza um pipeline de recuperação aprimorado:
    1. File Retriever: Usa BM25 para filtrar arquivos relevantes lexicalmente.
    2. CodeChunker: Decompõe arquivos em blocos sintáticos (funções, classes) usando análise de AST e heurísticas regex para múltiplas linguagens.
    3. CodeReranker: Usa CodeBERT para reranking denso semântico.
    4. Gestão de Orçamento de Tokens: Empacota dinamicamente os chunks mais relevantes dentro da janela de contexto do modelo.
• Construção do Dataset:
  • Coletado a partir de 2.300 issues reais do GitHub com soluções validadas (Pull Requests mesclados).
  • Filtro rigoroso: Passagem por CI, verificação de clareza e dificuldade via LLM-as-a-Judge e validação final por especialistas humanos.
  • Suporte a quatro linguagens: C++, Python, Rust e Go.

3. Contribuições Principais

1. Protocolo de Avaliação Adversarial CI: Um framework padronizado que avalia LLMs não apenas na geração de código, mas na capacidade de interagir em um ciclo de revisão, gerando patches robustos e testes que expõem falhas.
2. Pipeline RACG Multi-linguagem: Uma solução robusta e reprodutível para recuperação de contexto em bases de código grandes, projetada especificamente para suportar avaliações em ambientes de CI, servindo como baseline forte.
3. Dataset Curado e Grounded em CI: Um conjunto de dados de alta qualidade com 400 instâncias de avaliação (100 por linguagem) e um split de ablação, focado em problemas reais de desenvolvimento com validação automática.
4. Análise de Comportamento Modelar: Revelação de tendências comportamentais distintas entre modelos (ex: agressividade na geração vs. estabilidade no CI).

4. Resultados Experimentais

Os experimentos foram realizados com modelos proprietários (GPT-4o, Claude-3.5, Gemini-2.0, DeepSeek-V3) e open-source.

• Desempenho Adversarial:
  • GPT-4o demonstrou superioridade na geração de patches "agressivos" (alta taxa de vitória em batalhas), mas com variabilidade na correção absoluta (SPR/RPR mais baixos comparados a outros).
  • DeepSeek e Gemini mostraram maior estabilidade e taxas de aprovação no CI (SPR/RPR mais altos), priorizando correção e robustez sobre a agressividade na resolução.
  • Auto-consistência: Modelos tendem a ter altas taxas de vitória quando revisam seus próprios patches (ex: Claude 1.00, GPT-4o 0.97), indicando alinhamento interno entre geração de código e teste.
• Impacto do RACG:
  • A inclusão do módulo RACG melhorou consistentemente o desempenho (Best@3 e Win Rate) em todas as linguagens.
  • Exemplo: Em C++, o RACG aumentou o Best@3 de 0.38 para 0.42 e a taxa de vitória de 0.77 para 0.84.
  • A recuperação baseada em chunks (nível de classe/bloco) superou significativamente o BM25 puro na localização de arquivos corretos (Top-10 hit rate saltou de 20.7% para 48.7%).
• Padrões de Falha:
  • A análise de falhas revelou quatro categorias principais: inconsistência entre arquivos (31%), testes não determinísticos (19%), violação de requisitos não funcionais (estilo/segurança) (24%) e limitações na recuperação de contexto (26%).

5. Significado e Impacto

O SWINGARENA representa um avanço significativo na avaliação de LLMs para engenharia de software:

• Realismo: Move a avaliação de "código que passa em um teste" para "código que sobrevive a um pipeline de CI e revisão de pares", alinhando-se com as expectativas da indústria.
• Descoberta de Trade-offs: Permite identificar que modelos podem ser excelentes em gerar soluções criativas, mas falhar em estabilidade, ou vice-versa, fornecendo métricas mais nuanceadas do que apenas "acerto/falha".
• Escalabilidade: Oferece uma metodologia escalável para testar a capacidade de raciocínio de longo contexto e a robustez de modelos em cenários colaborativos complexos.
• Futuro: O framework destaca a necessidade de melhorar o raciocínio arquitetural (para mudanças multi-arquivo) e a integração de requisitos não funcionais (segurança, estilo) no processo de geração de código.

Em suma, o SWINGARENA preenche uma lacuna crítica ao fornecer um "arena" onde LLMs são testados não apenas como geradores de código, mas como engenheiros de software capazes de navegar, corrigir e validar sistemas complexos em ambientes adversariais dinâmicos.