Benchmark · agentic
Multi-SWE-bench
O Multi-SWE-bench mede se um agente de codificação com IA consegue resolver issues reais do GitHub em muitos repositórios e linguagens de programação, não apenas Python. A métrica principal é a taxa de resolução (resolution rate): a porcentagem de instâncias cuja correção faz o conjunto de testes oculto passar.
Saiba mais
- Exemplo
- Uma tarefa representativa: dado um relato de bug ou pedido de funcionalidade real de um projeto de código aberto escrito em uma linguagem como Java, Go, Rust, TypeScript, JavaScript, C ou C++, junto com o repositório no commit anterior à correção, o agente deve gerar um patch que resolva o problema descrito.
- Pontuação
- Cada instância é avaliada como aprovada/reprovada por execução. O patch do agente é aplicado ao repositório e os testes do projeto são executados; a instância conta como resolvida apenas se os testes designados FAIL_TO_PASS agora passarem e todos os testes PASS_TO_PASS continuarem passando. A pontuação reportada é a taxa de resolução (instâncias resolvidas ÷ total), normalmente em pass@1, e pode ser detalhada por linguagem e por dificuldade anotada por especialistas (easy/medium/hard).
- Verificação
- A aceitação é totalmente baseada em execução dentro de uma imagem Docker por instância que reproduz exatamente o conjunto de ferramentas da linguagem e as dependências. O patch gerado deve aplicar-se sem conflitos e então os testes fail-to-pass e pass-to-pass são executados; não há avaliação por LLM nem comparação textual com o patch de referência do desenvolvedor.
- Por que importa
- O SWE-bench foi influente, mas cobre apenas Python, enquanto a engenharia de software real abrange muitas linguagens. O Multi-SWE-bench testa se os agentes de codificação generalizam entre linguagens em issues autênticos, com rótulos de dificuldade de especialistas, oferecendo um sinal mais difícil, realista e menos saturado da capacidade prática de engenharia de software.
Exemplo resolvido
Tarefa
Instância ilustrativa no formato do Multi-SWE-bench — linguagem: Go, uma pequena biblioteca de coleções genéricas. problem_statement: «Stack.Pop() em uma pilha vazia retorna o valor zero com um erro nil, ocultando silenciosamente bugs em quem chama; em vez disso, deveria retornar o sentinela ErrEmpty». Você recebe o repositório no commit base com o bug e o teste que falha. FAIL_TO_PASS: TestPopEmptyReturnsError. PASS_TO_PASS: TestPushThenPop, TestLen. Envie um patch que faça o teste que falha passar sem quebrar os testes que passam.
Solução
--- a/stack.go
+++ b/stack.go
@@ func (s *Stack[T]) Pop() (T, error) {
+ if len(s.items) == 0 {
+ var zero T
+ return zero, ErrEmpty
+ }
n := len(s.items)
v := s.items[n-1]
s.items = s.items[:n-1]
return v, nil
}Explicação
A correção adiciona ao Pop uma verificação de vazio que retorna o sentinela ErrEmpty (junto com o valor zero do tipo) exatamente como o TestPopEmptyReturnsError espera, deixando o caminho normal de remoção inalterado para que TestPushThenPop e TestLen continuem passando. A avaliação é puramente por execução: o harness aplica o patch na imagem Docker da instância e a marca como resolvida apenas se o teste FAIL_TO_PASS passar a aprovar e nenhum teste PASS_TO_PASS regredir.
Ainda não há pontuações verificadas para este benchmark.