SWE-rebench ouvre 13 337 tâches RL réparées : Qwen3.5-9B apprend sur 70% des tâches au lieu de 55%

Imaginez que vous entraîniez un modèle à corriger des bugs. Vous lui donnez une tâche : corriger une fonction dans un dépôt réel, puis vous vérifiez le résultat avec des tests. Seulement, les tests vérifient tout autre chose que ce que décrit le bug, ou la solution se trouve déjà dans l'image Docker.

Le modèle échoue alors systématiquement, ou réussit systématiquement, et dans les deux cas il n'a rien à apprendre. C'est précisément le problème auquel les auteurs de SWE-rebench se sont heurtés. Ils publient SWE-rebench V2.

1 RL : 13 337 environnements RL gratuits (c'est-à-dire des tâches prêtes à l'emploi, avec leur environnement et leur vérification) pour entraîner des agents de code. Lors d'un test sur 100 tâches, le nombre de tâches sur lesquelles Qwen3.5-9B apprend réellement quelque chose est passé de 55 à 70.

Si vous faites du post-entraînement RL, c'est un moyen de ne pas gaspiller de GPU sur des données inutilisables.

Ce que contient le jeu de données

Il s'agit de tâches issues de dépôts GitHub réels, couvrant 20 langages de programmation. Elles sont au format Harbor, ce qui permet de les brancher à son propre pipeline RL sans packaging manuel. Le jeu de données est en accès libre sur hub.harborframework.com.

La principale différence avec bien des jeux de données ouverts tient à la vérification. Chaque tâche est passée entre les mains d'agents de code, chargés de repérer les défauts et de les corriger. Ce travail coûte en moyenne $0,24 par tâche. En multipliant par la taille du jeu, on arrive à environ 3,2 mille dollars pour l'ensemble. Il s'agit de notre estimation, pas d'un montant annoncé par les auteurs, mais l'ordre de grandeur est clair : nettoyer les données coûte moins cher que de dépenser du calcul sur des exécutions inutiles.

Pourquoi les tâches défectueuses sont nuisibles

En RL, le modèle résout la même tâche de nombreuses fois et compare les tentatives réussies aux échecs. C'est comme un entraîneur qui compare les meilleurs et les pires essais d'un sportif. Si l'exercice est impossible à réaliser, ou si n'importe quel mouvement est validé, il n'y a rien à comparer.

Sur les tâches de code, on rencontre trois défauts typiques :

• les tests ne correspondent pas à la description de la tâche, et la solution correcte ne les passe pas ;
• l'environnement ne démarre pas : les dépendances ne s'installent pas, le build plante ;
• la réponse fuite dans l'image Docker, et le modèle peut la trouver au lieu de la produire.

Dans les deux premiers cas, toutes les tentatives échouent et il n'y a aucune différence entre elles. Dans le troisième, toutes les tentatives réussissent, et là encore il n'y a rien à apprendre. Dans les deux situations, les ressources de calcul sont gaspillées. Selon les auteurs, les jeux de données ouverts contiennent beaucoup de telles tâches.

Ce que montre l'expérience

La vérification a été menée sur les mêmes 100 tâches. Avant la réparation, Qwen3.5-9B apprenait sur 55 d'entre elles, c'est-à-dire celles où les tentatives présentent une différence significative. Après la réparation, ces tâches sont au nombre de 70. Le gain est de 15 tâches, soit environ un quart de matériel utile en plus pour une taille d'échantillon identique.

La conclusion pratique est simple : avant de lancer un coûteux entraînement RL, mieux vaut évaluer la part des tâches sur lesquelles le modèle reçoit un signal. Si elle est faible, il est moins cher de nettoyer d'abord le jeu de données que d'augmenter le nombre d'exécutions.

Limites et marche à suivre

Les chiffres 55 et 70 proviennent d'un échantillon de 100 tâches et d'un seul modèle de taille 9B. Les auteurs ne précisent pas, dans leur publication, de combien la qualité finale de l'agent progresserait sur les benchmarks après un entraînement complet. Nous constatons une hausse de la part de tâches utiles, mais pas une amélioration directe des résultats sur des tests de type SWE. Cela mérite d'être vérifié sur vos propres modèles et votre propre infrastructure.

À qui cela peut servir :

• aux équipes qui font du post-entraînement RL pour des agents de code et ne veulent pas construire les environnements de zéro ;
• aux chercheurs qui ont besoin d'un jeu de données reproductible couvrant plusieurs langages, et pas seulement Python ;
• à ceux qui construisent leurs propres jeux de données : l'approche « un agent vérifie et répare la tâche » pour $0,24 peut être reprise.

Les auteurs promettent aussi de nouvelles publications pour l'open source. Si les prochains jeux de données sont de la même qualité, les données ouvertes pour entraîner des agents seront nettement plus nombreuses, et l'écart avec les laboratoires fermés se réduira, ne serait-ce que sur la préparation des environnements.