SWE-bench: Modelos de Linguagem Conseguem Resolver Problemas Reais do GitHub?

O artigo CodeAct apresentou um argumento convincente para o Python como o formato de ação correto para agentes de LLM. Mas escolher o formato de ação certo é apenas metade do problema — você também precisa demonstrar que os agentes conseguem lidar com a complexidade de tarefas do mundo real, não apenas benchmarks selecionados. O SWE-bench (arXiv:2310.06770), publicado por Carlos Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press e Karthik Narasimhan de Princeton e apresentado no ICLR 2024, é o artigo que forçou o campo a enfrentar essa lacuna diretamente.

O artigo

"SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" constrói um benchmark de 2.294 instâncias de tarefas extraídas de pull requests reais mesclados em 12 repositórios Python populares — astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy e xarray. Cada instância apresenta ao modelo um snapshot da base de código e uma descrição de problema do GitHub; o modelo deve produzir um patch que faça um conjunto designado de testes que falhavam anteriormente passarem, sem quebrar os testes existentes. O benchmark foi construído minerando cerca de 90.000 PRs, filtrando aqueles que resolviam um problema vinculado e adicionavam novos testes, e então verificando as transições de aprovação/falha baseadas em execução. Essa construção disciplinada evita o problema típico de benchmarks com verdades fundamentais (ground truth) ambíguas ou facilmente manipuláveis.

Ideias principais

• O Claude 2, o modelo com melhor desempenho na publicação, resolve apenas 1,96% dos problemas usando recuperação esparsa BM25 — o cenário de implantação realista onde o modelo deve encontrar arquivos relevantes por conta própria.
• Com a recuperação oráculo (oracle) — onde o modelo recebe exatamente os arquivos de que precisa — o Claude 2 melhora para 4,80%, confirmando que o gargalo é em parte a recuperação, mas principalmente a edição: mesmo com contexto perfeito, as taxas de sucesso permanecem abaixo de 5%.
• O GPT-4 resolve 0,00% dos problemas com recuperação BM25 (avaliado em um subconjunto de 25% por razões de orçamento) e 1,74% com oráculo. A queda do oráculo para o BM25 no Claude 2 é severa; para o GPT-4, é total.
• Os patches gerados são sistematicamente curtos demais: os patches bem-sucedidos do Claude 2 têm em média 19,6 linhas, contra 74,5 linhas dos patches humanos de referência. Os modelos encontram correções locais simples; os humanos escrevem soluções abrangentes que abrangem vários arquivos.
• Mais contexto ativamente atrapalha. O BM25 com 50k tokens recupera mais arquivos do oráculo do que com 13k tokens, mas as taxas de resolução geralmente diminuem. O efeito "lost in the middle" (perdido no meio) — modelos ignorando evidências relevantes enterradas em contextos longos — é um modo de falha real e documentado aqui.
• O SWE-Llama 13b, ajustado em contextos recuperados por oráculo, atinge 4,00% com oráculo, mas apenas 0,70% com BM25. O treinamento em contexto perfeito cria agentes frágeis que colapsam quando a recuperação é realista.

O que se sustenta — e o que não

A construção do benchmark é rigorosa. A avaliação baseada em execução — testes realmente executados, passando ou falhando — é a verdade fundamental correta para tarefas de edição de código. É objetiva, automatizável e difícil de manipular. A decisão de exigir transições de falha para aprovação (não apenas a aplicação bem-sucedida do patch) é particularmente importante: ela evita patches trivialmente corretos, como operações nulas ou exclusões.

Os resultados se mantiveram notavelmente bem. O SWE-bench foi publicado em outubro de 2023 e rapidamente se tornou a avaliação de fato para agentes de codificação. A linha de base inicial de 1,96% é genuinamente informativa, não escolhida a dedo. O SWE-agent, publicado em 2024 por um grupo relacionado, elevou o patamar para 12,47% ao redesenhar a interface agente-computador — uma melhoria de 6x que, por si só, confirma o quanto a linha de base original deixou a desejar.

Duas coisas que o artigo não trata bem: Primeiro, o benchmark é apenas para Python. Essa é uma necessidade prática, mas cria um risco real de ajuste excessivo às convenções do Python. Segundo, o artigo propõe apenas linhas de base de geração aumentada por recuperação (RAG) e explicitamente adia para trabalhos futuros as abordagens baseadas em agentes. Esse adiamento foi apropriado em 2023, mas significa que o artigo em si não fornece nenhum sinal sobre quais arquiteturas de agentes ajudam.

A configuração "oráculo" também é um limite superior mais fraco do que parece. Fornecer o contexto perfeito do arquivo não resolve a localização do código dentro desses arquivos e não ajuda com o raciocínio de arquivos múltiplos sobre interações entre módulos. O Claude 2 com 4,8% no oráculo significa que mesmo com os arquivos certos no contexto, o modelo falha em 95% das vezes. O problema não é primariamente a recuperação.

Por que isso é importante para a IA nas finanças

O Beancount é um projeto Python hospedado no GitHub. Um agente de write-back para o Beancount é, em essência, um agente que precisa passar em tarefas no estilo SWE-bench: dado um arquivo de livro-razão (ledger) e uma instrução ("adicione esta transação", "corrija esta discrepância de saldo"), produzir uma edição que passe no bean-check sem quebrar as asserções existentes.

A falha de recuperação é diretamente análoga ao problema de localização no livro-razão. Quando um usuário diz "corrija o excesso de lançamentos em suprimentos de escritório no terceiro trimestre", o agente deve primeiro encontrar as entradas relevantes em um arquivo que pode conter milhares de linhas — a mesma tarefa de localização de arquivo onde o BM25 falha em 40–50% das instâncias do SWE-bench. A degradação "lost in the middle" aplica-se igualmente a arquivos .beancount longos, onde entradas com datas anteriores têm a mesma probabilidade de serem ignoradas.

A assimetria no comprimento do patch é um aviso prático. Os modelos aplicam patches de forma muito estreita. Na contabilidade, isso se traduz em corrigir uma entrada enquanto esquece a entrada de contrapartida, ou atualizar a linha de despesa enquanto deixa o saldo acumulado desatualizado. Um agente Beancount de produção precisa de uma camada de validação — bean-check, asserções de saldo ou uma etapa de reconciliação explícita — que force o agente a ver a consequência total de sua edição, não apenas sua plausibilidade local.

A lacuna entre oráculo/BM25 também é um lembrete de que a qualidade da recuperação não é separável da qualidade do agente. Um agente que não consegue identificar de forma confiável quais contas ou arquivos são relevantes para a pergunta de um usuário falhará na etapa de navegação do livro-razão antes mesmo de tentar uma edição.

O que ler a seguir

• SWE-agent (arXiv:2405.15793, NeurIPS 2024) — a continuação direta; passa de 1,96% para 12,47% ao redesenhar a interface agente-computador. Os princípios de design para navegação de arquivos e busca de código são diretamente aplicáveis às ferramentas de agentes Beancount.
• Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — remove a complexidade do agente e mostra que um pipeline simples de localização + reparo sem estrutura de suporte pode ser competitivo; um contraponto útil para abordagens pesadas em interface.
• MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — aborda o problema do contexto longo diretamente com gerenciamento de memória em camadas; diretamente relevante para agentes que devem raciocinar sobre livros-razão Beancount de vários anos.