SWE-rebench abre 13 337 tareas de RL reparadas: Qwen3.5-9B aprende con el 70% en lugar del 55%

Imagine que está enseñando a un modelo a corregir errores. Le da una tarea: arreglar una función en un repositorio real, y comprueba el resultado con pruebas. Pero las pruebas verifican algo muy distinto de lo que dice la descripción del error, o la solución ya está dentro de la imagen de Docker.

Entonces el modelo siempre fracasa o siempre «acierta», y en ambos casos no tiene nada de lo que aprender. Con este problema se encontraron los autores de SWE-rebench, que han publicado SWE-rebench V2.1 RL: 13 337 entornos de RL gratuitos (es decir, tareas listas con su entorno y su verificación) para entrenar agentes de programación.

En una prueba con 100 tareas, el número de aquellas en las que Qwen3.5-9B realmente aprende algo subió de 55 a 70. Si trabaja en post-entrenamiento con RL, es una forma de no gastar GPU en datos basura.

Qué contiene el conjunto de datos

Son tareas de repositorios reales de GitHub en 20 lenguajes de programación. Están en formato Harbor, así que se pueden conectar al pipeline de RL propio sin empaquetarlas a mano. El conjunto está disponible en abierto en hub.harborframework.com.

La principal diferencia con muchos datasets abiertos es la verificación. Cada tarea pasó por agentes de programación que buscaron fallos y los repararon. El coste medio de este trabajo es de $0,24 por tarea. Multiplicado por el tamaño del conjunto, sale en torno a 3,2 mil dólares para todo el volumen. Es una estimación nuestra, no una cifra declarada por los autores, pero el orden de magnitud está claro: limpiar los datos es más barato que gastar cómputo en ejecuciones inútiles.

Por qué las tareas rotas hacen daño

En RL, el modelo resuelve la misma tarea muchas veces y compara los intentos exitosos con los fallidos. Es como un entrenador que compara los mejores y los peores intentos de un deportista. Si el ejercicio es imposible de completar, o se da por válido cualquier movimiento, no hay nada que comparar.

En las tareas de código aparecen tres fallos típicos:

• las pruebas no coinciden con la descripción de la tarea, y la solución correcta no las pasa;
• el entorno no arranca: no se instalan las dependencias o falla la compilación;
• la respuesta se filtra en la imagen de Docker, y el modelo puede encontrarla en lugar de elaborarla.

En los dos primeros casos todos los intentos fracasan y no hay diferencia entre ellos. En el tercero todos los intentos tienen éxito, y tampoco hay de qué aprender. En ambos casos los recursos de cómputo se pierden. Según los autores, en los datasets abiertos hay muchas tareas así.

Qué mostró el experimento

La comprobación se hizo con las mismas 100 tareas. Antes de la reparación, Qwen3.5-9B aprendía en 55 de ellas, es decir, en aquellas donde hay una diferencia sustancial entre los intentos. Tras la reparación, esas tareas pasaron a ser 70. El aumento es de 15 tareas, o aproximadamente una cuarta parte más de material útil con el mismo tamaño de muestra.

La conclusión práctica es sencilla: antes de lanzar un RL costoso conviene estimar la proporción de tareas en las que el modelo recibe señal. Si es baja, resulta más barato limpiar primero el conjunto que aumentar el número de ejecuciones.

Limitaciones y qué hacer

Las cifras 55 y 70 se obtuvieron con una muestra de 100 tareas y con un solo modelo de tamaño 9B. En su publicación, los autores no indican cuánto mejoraría la calidad final del agente en benchmarks tras un entrenamiento completo. Vemos un aumento en la proporción de tareas útiles, pero no una mejora directa de los resultados en pruebas del tipo SWE. Conviene comprobarlo con los modelos y la infraestructura propios.

A quién le puede servir:

• equipos que hacen post-entrenamiento con RL para agentes de programación y no quieren construir entornos desde cero;
• investigadores que necesitan un conjunto reproducible en varios lenguajes, y no solo en Python;
• quienes construyen sus propios datasets: el enfoque de «el agente verifica y repara la tarea» por $0,24 se puede adoptar.

Los autores también prometen nuevas publicaciones para la comunidad de código abierto. Si los siguientes conjuntos mantienen esta calidad, habrá bastantes más datos abiertos para entrenar agentes, y la brecha con los laboratorios cerrados se reducirá, al menos en la preparación del entorno.