SWE-rebench abre 13 337 tarefas de RL corrigidas: Qwen3.5-9B passa a aprender com 70% das tarefas em vez de 55%

Imagine que você está ensinando um modelo a corrigir bugs. Você dá a ele uma tarefa: consertar uma função em um repositório real e verificar o resultado com testes. Só que os testes checam algo totalmente diferente do que está escrito na descrição do bug, ou a solução já está no Docker-image.

Nesse caso, o modelo sempre falha ou sempre "acerta", e não tem do que aprender. Foi esse o problema que os autores do SWE-rebench encontraram, e por isso eles publicaram o SWE-rebench V2.1 RL: 13 337 ambientes de RL gratuitos (ou seja, tarefas prontas, com ambiente e verificação) para treinar agentes de código.

Em um teste com 100 tarefas, o número daquelas em que o Qwen3.5-9B realmente aprende algo subiu de 55 para 70. Se você trabalha com pós-treinamento por RL, essa é uma forma de não gastar GPU com dados ruins.

O que há no conjunto

São tarefas de repositórios reais do GitHub, em 20 linguagens de programação. Elas seguem o formato Harbor, então podem ser conectadas ao seu pipeline de RL sem empacotamento manual. O conjunto está disponível em acesso aberto em hub.harborframework.com.

A principal diferença em relação a muitos datasets abertos está na verificação. Cada tarefa passou por agentes de código que procuraram falhas e as corrigiram. O custo médio desse trabalho é de $0,24 por tarefa. Multiplicando pelo tamanho do conjunto, chega-se a cerca de 3,2 mil dólares para todo o volume. Essa é uma estimativa nossa, não um valor informado pelos autores, mas a ordem de grandeza fica clara: limpar os dados sai mais barato do que gastar computação em execuções inúteis.

Por que tarefas quebradas prejudicam o treinamento

No RL, o modelo resolve a mesma tarefa muitas vezes e compara as tentativas bem-sucedidas com as que falharam. É como um treinador que compara as melhores e as piores execuções de um atleta. Se o exercício é impossível de cumprir, ou se qualquer movimento é aceito, não há o que comparar.

Tarefas de código costumam apresentar três tipos de falha:

• os testes não batem com a descrição da tarefa, e a solução correta não passa neles;
• o ambiente não sobe: as dependências não são instaladas ou o build falha;
• a resposta vaza para o Docker-image, e o modelo pode encontrá-la em vez de elaborá-la.

Nos dois primeiros casos, todas as tentativas falham e não há diferença entre elas. No terceiro, todas as tentativas têm sucesso, e também não há o que aprender. Nas duas situações, os recursos computacionais são desperdiçados. Segundo os autores, há muitas tarefas assim nos datasets abertos.

O que o experimento mostrou

O teste foi feito nas mesmas 100 tarefas. Antes da correção, o Qwen3.5-9B aprendia em 55 delas, ou seja, naquelas em que há diferença relevante entre as tentativas. Depois da correção, passaram a ser 70. O ganho é de 15 tarefas, ou cerca de um quarto a mais de material útil com o mesmo tamanho de amostra.

A conclusão prática é simples: antes de uma execução cara de RL, vale estimar a fatia de tarefas em que o modelo recebe sinal de aprendizado. Se ela for baixa, sai mais barato limpar o conjunto primeiro do que aumentar o número de execuções.

Limitações e o que fazer

Os números 55 e 70 vêm de uma amostra de 100 tarefas e de um único modelo de 9B. No post, os autores não informam quanto a qualidade final do agente melhoraria nos benchmarks após o treinamento completo. Vemos o aumento da fatia de tarefas úteis, mas não uma melhora direta nos resultados de testes do tipo SWE. Vale validar isso nos seus próprios modelos e na sua infraestrutura.

Quem pode se beneficiar:

• equipes que fazem pós-treinamento por RL para agentes de código e não querem montar ambientes do zero;
• pesquisadores que precisam de um conjunto reproduzível em várias linguagens, e não apenas em Python;
• quem constrói os próprios datasets: a abordagem em que o agente verifica e corrige a tarefa por $0,24 pode ser adotada.

Os autores também prometem novos lançamentos para a comunidade open source. Se os próximos conjuntos tiverem a mesma qualidade, haverá bem mais dados abertos para treinar agentes, e a distância para os laboratórios fechados diminuirá, ao menos na preparação do ambiente.