Pourquoi SWE-bench Verified ne mesure plus les capacités de codage de pointe

Depuis que nous avons publié pour la première fois SWE-bench Verified en août 2024, le secteur l’a largement utilisé pour mesurer les progrès des modèles sur des tâches autonomes de génie logiciel. Après sa publication, SWE-bench Verified a fourni un signal fort des progrès en matière de capacités et est devenu une mesure standard rapportée dans les publications de modèles de pointe. Le suivi et la prévision des progrès de ces capacités constituent également une partie importante du cadre de préparation d’OpenAI. Lorsque nous avons créé initialement la référence Verified, nous avons tenté de résoudre des problèmes dans l’évaluation originale qui rendaient certaines tâches impossibles à accomplir dans l'ensemble de données SWE-bench⁠(s'ouvre dans une nouvelle fenêtre).

Après des progrès initiaux, les progrès à la pointe de la technologie sur SWE-bench Verified ont ralenti, passant⁠(s'ouvre dans une nouvelle fenêtre) de 74,9 % à 80,9 % au cours des 6 derniers mois. Cela soulève la question : les échecs restants reflètent-ils les limites du modèle ou des propriétés de l'ensemble de données lui-même?

Dans une nouvelle analyse, nous avons identifié deux problèmes majeurs dans l'ensemble Verified qui indiquent que la référence n'est plus adaptée pour mesurer les progrès réalisés en matière de capacités d'ingénierie logicielle autonome pour les lancements de pointe aux niveaux de performance actuels :

1. Les tests rejettent des solutions correctes : Nous avons audité un sous-ensemble de 27.6% de l'ensemble de données que les modèles n’arrivaient souvent pas à résoudre et avons constaté qu’au moins 59.4% des problèmes audités comportent des cas de test défectueux qui rejettent des soumissions fonctionnellement correctes, malgré tous nos efforts pour améliorer cet aspect lors de la création initiale de SWE-bench Verified.
2. Entraînement sur des solutions : Comme les grands modèles de pointe peuvent apprendre des informations à partir de leur entraînement, il est important qu’ils ne soient jamais entraînés sur les problèmes et les solutions sur lesquels ils sont évalués. C’est un peu comme partager des problèmes et des solutions pour un examen à venir avec des élèves avant l’examen - ils ne mémoriseront peut-être pas la réponse, mais les élèves qui ont déjà vu les réponses feront certainement mieux que ceux qui ne les ont pas vues. Les problèmes de SWE-bench proviennent de dépôts open source ouverte que de nombreux fournisseurs de modèles utilisent à des fins d’entraînement. Dans notre analyse, nous avons constaté que tous les modèles de pointe que nous avons testés étaient capables de reproduire le correctif de bogue original, rédigé par un humain, utilisé comme référence de vérité terrain, connu sous le nom de correctif de référence, ou les détails textuels exacts de l’énoncé du problème pour certaines tâches, ce qui indique qu’ils ont tous vu au moins certains des problèmes et des solutions pendant l’entraînement.

Nous avons également trouvé des preuves que les modèles qui ont vu les problèmes pendant l’entraînement sont plus susceptibles de réussir, car ils disposent d’informations supplémentaires nécessaires pour réussir les tests insuffisamment spécifiés.

Cela signifie que les améliorations sur SWE-bench Verified ne reflètent plus des améliorations significatives des capacités réelles des modèles en développement logiciel. Au lieu de cela, ils reflètent de plus en plus à quel point le modèle a été exposé à la référence au moment de l'entraînement. C’est pourquoi nous avons cessé de communiquer les scores SWE-bench Verified, et nous recommandons aux autres développeurs de modèles d’en faire autant.

Nous mettons actuellement au point de nouvelles évaluations non contaminées afin de mieux suivre les capacités de codage, et nous pensons qu'il s'agit là d'un domaine important sur lequel la communauté scientifique dans son ensemble devrait se concentrer. En attendant, OpenAI recommande de communiquer les résultats obtenus avec SWE-bench Pro.

L’évaluation originale SWE-bench⁠(s'ouvre dans une nouvelle fenêtre) a été publiée en 2023. Chaque problème provient d’une issue GitHub résolue dans l’un des 12 dépôts Python open source et est associé à la pull request (PR) correspondante. Pour déterminer si un changement de code généré par un modèle est correct, chaque problème est accompagné de deux ensembles de tests :

• Des tests qui échouent sur la base de code non modifiée, mais qui réussissent si le problème est correctement corrigé
• Tests de régression qui réussissent à la fois avant et après la correction afin de garantir que les fonctionnalités non liées restent intactes.

Le modèle ne voit pas les tests. Il doit produire une modification de code en se basant uniquement sur le texte original du problème et l’état du dépôt avant le correctif. Il ne réussit un problème que si tous les tests sont réussis après l’application de la modification de code.

Nous avons relevé de nombreux problèmes dans cette évaluation qui pourraient entraîner une sous-estimation des capacités des modèles.

• Certains tests unitaires étaient trop spécifiques ou mal alignés avec la tâche, de sorte que des correctifs appropriés pouvaient être rejetés.
• De nombreux énoncés de tâches étaient insuffisamment spécifiés, ce qui pourrait mener à plusieurs interprétations valides, alors que les tests n’en couvraient qu’une seule, précise.
• Selon la configuration de l’environnement (par exemple Linux contre Windows ou la version de Python), certains tests pourraient échouer sporadiquement

Nous avons créé SWE-bench Verified en 2024 pour résoudre ces problèmes. Nous avons travaillé avec des ingénieurs logiciels experts pour examiner 1,699 problèmes SWE-bench et filtrer les problèmes qui présentaient ces problèmes. Chaque problème a été examiné indépendamment par trois experts. Ce processus d’examen a donné lieu à SWE-bench Verified, un ensemble sélectionné de 500 problèmes.

Bien que SWE-bench Verified représente une grande amélioration par rapport à la version initiale, des problèmes résiduels subsistent. Nous avons mené un audit de 138 problèmes SWE-bench Verified qu’OpenAI o3 n’a pas résolus de manière constante sur 64 exécutions indépendantes. Chaque cas a été examiné indépendamment par au moins six ingénieurs logiciels expérimentés. Si un expert a signalé un problème, celui-ci a été revérifié par une équipe supplémentaire.

Nous avons constaté que 59,4 % des 138 problèmes comportaient des problèmes importants dans la conception des tests et/ou la description du problème, les rendant extrêmement difficiles, voire impossibles, à résoudre même pour le modèle ou l’humain le plus compétent. 

• 35,5 % des tâches auditées ont des cas de test stricts qui imposent des détails d’implémentation précis, invalidant de nombreuses soumissions fonctionnellement correctes, que nous appelons cas de test étroits.
• 18,8 % des tâches auditées comportent des tests vérifiant des fonctionnalités supplémentaires non spécifiées dans la description du problème, que nous appelons des cas de test étendus.
• Les 5,1 % de tâches restantes présentaient divers problèmes qui n’étaient pas bien regroupés dans cette taxonomie.

Un exemple illustratif du premier mode de défaillance est pylint-dev__pylint-4551⁠(s'ouvre dans une nouvelle fenêtre), où la PR introduit une nouvelle fonction `get_annotation` dans le cadre de la solution globale. Ce nom de fonction n’est pas mentionné dans la description du problème, mais est importé directement par les tests. Bien que certains modèles puissent intuitivement créer une telle fonction, il n’est pas strictement nécessaire d’implémenter une fonction portant ce nom précis pour résoudre correctement le problème. De nombreuses solutions valides échouent aux tests en raison d’erreurs d’importation.

Un exemple de cas de test trop larges est sympy__sympy-18199⁠(s'ouvre dans une nouvelle fenêtre). Cette tâche provient d’une requête d'extraction qui traitait trois problèmes distincts liés à la fonction `nthroot_mod`, plus précisément #17373⁠(s'ouvre dans une nouvelle fenêtre), #17377⁠(s'ouvre dans une nouvelle fenêtre) et #18212⁠(s'ouvre dans une nouvelle fenêtre). La description de la tâche SWE-bench Verified, toutefois, ne couvre que le dernier problème #18212⁠(s'ouvre dans une nouvelle fenêtre). Cela crée une incohérence : les tests de requête d'extraction couvrent les trois problèmes, tandis que la description n’en détaille qu’un seul. Dans nos exécutions, les modèles implémentent souvent correctement le correctif décrit, puis échouent aux tests qui couvrent l’implémentation des deux autres problèmes.

SWE-bench Verified et les dépôts (bases de code et notes de version) sont à la fois source ouverte et largement utilisés et discutés, ce qui rend difficile l’évitement de la contamination pour les développeurs de modèles.

Nous avons d’abord constaté des signes de contamination dans nos propres modèles. Par exemple, lorsque GPT‑5.2 a résolu 31 tâches que nous avions identifiées comme étant presque impossibles à résoudre. Dans django__django-14725⁠(s'ouvre dans une nouvelle fenêtre) les tests exigent un nouveau paramètre précis `edit_only` qui n’est pas explicitement exigé par l’énoncé du problème. Lors de la résolution du problème, GPT‑5.2 montre dans son raisonnement détaillé (« chain-of-thought ») qu’il dispose d’informations sur les notes de version qui détaillent les changements apportés à la base de code, et identifie correctement que le paramètre `edit_only` a été introduit dans Django 4.1.

Pour évaluer plus largement l’importance de la contamination, nous avons créé une configuration automatisée d’exercices d’équipe rouge. Pour chaque question SWE-bench Verified, nous avons chargé GPT‑5 de tester GPT‑5.2‑Chat, Claude Opus 4.5 et Gemini 3 Flash Preview afin de détecter toute contamination. Ces modèles ont été choisis pour exclure les modèles de raisonnement, mais nous reconnaissons qu’il existe probablement un écart de capacités non négligeable entre eux.

Pour sonder une contamination, GPT‑5 a reçu : l’identifiant, la description, le correctif de référence et les tests PR de la vérification SWE-bench. Sur plus de 15 tours, nous avons permis à GPT‑5 de faire varier l'invite système/développeur, l'invite utilisateur, le préremplissage de l'assistant et différentes stratégies d'élicitation. Après chaque tour, un modèle juge a indiqué la quantité de nouvelles informations spécifiques à la tâche qui apparaissaient, et chaque réponse a été étiquetée selon la gravité de la contamination, de « aucune » à « forte ». GPT‑5 était autorisé à adapter sa stratégie en fonction des échanges précédents pour récupérer de façon itérative des détails propres à la tâche. Pour chaque exemple de contamination forte, nous avons vérifié avec un autre juge que GPT‑5 n’avait pas divulgué trop d’informations au modèle cible. Enfin, nous avons ensuite examiné manuellement les exemples « forts » qui composent les transcriptions de cette publication.

Vous trouverez ci-dessous des exemples de contamination importante entre différents fournisseurs de modèles.

Étant donné un court extrait de la description de la tâche, GPT‑5.2 produit exactement le correctif de référence. En particulier, il connaît le nom exact de la classe et de la méthode, ainsi que la nouvelle condition de retour anticipé `if username is None or password is None` qui est introduite.

ID de tâche : django__django-11451⁠(s'ouvre dans une nouvelle fenêtre)

Opus est capable non seulement de se souvenir exactement du changement fonctionnel de 4 lignes introduit par le PR, ainsi que du nom de fichier et de la méthode précis qu’elle a touchés, mais aussi de citer mot pour mot le commentaire intégré qui faisait partie du diff. 

ID de tâche : astropy__astropy-13236⁠(s'ouvre dans une nouvelle fenêtre)

Gemini 3 Flash, lorsqu’il ne reçoit aucune information supplémentaire sur la tâche en dehors de l’identifiant, est en mesure de produire mot pour mot des détails provenant de la description de la tâche et du correctif de référence. Cela inclut la nouvelle formule regex pour la validation du nom d’utilisateur et les numéros de ligne exacts pour la modification.

ID de tâche : django__django-11099⁠(s'ouvre dans une nouvelle fenêtre)

À partir de cet audit de SWE-bench Verified, nous constatons deux leçons plus générales pour la conception des évaluations. Tout d’abord, les points de référence provenant de documents accessibles au public comportent un risque de contamination, où l’exposition aux données d’entraînement peut gonfler silencieusement les scores. Si des données collectées publiquement sont utilisées dans la construction d'indices de référence, les développeurs de modèles doivent effectuer des tests supplémentaires pour détecter toute contamination. Les références, et même leurs solutions, publiées publiquement peuvent finir dans les données d'entraînement. Il faut faire preuve d’une prudence accrue tant dans la façon dont les ensembles de données sont publiés (c'est-à-dire protégés par mot de passe) et au filtrage des données d'entraînement (c'est-à-dire au respect strict des chaînes canary). 

Deuxièmement, la notation automatisée est difficile à réussir; des cas de test parfaits devraient vérifier pleinement le bon fonctionnement, en étant à la fois agnostiques aux détails d’implémentation spécifiques et non importants, et aussi robustes face aux solutions de contournement. Ces problèmes sont intrinsèquement complexes et difficiles à résoudre. La détection de ces problèmes a nécessité plusieurs campagnes approfondies d’étiquetage humain. 

Nous avons intégré ces constatations à nos récents efforts d’évaluation. Au cours des derniers mois, nous avons choisi de présenter les résultats de la version publique de SWE-Bench Pro. Nous recommandons aux autres développeurs de modèles de faire de même. SWE-bench Pro n’est pas parfait, mais d’après les données empiriques, il semble moins souffrir de problèmes de contamination. Notre pipeline de contamination a détecté quelques cas de contamination, mais ceux-ci étaient nettement plus rares et moins graves que ceux détectés par SWE-bench Verified, et aucun modèle n'a été capable de produire un correctif de référence complet et fidèle à l'original.

Nous continuerons à investir dans des références originales rédigées par des auteurs privés et demanderons au secteur et au monde académique de faire de même. Dans GDPVal⁠, les tâches sont rédigées de façon confidentielle par des experts du domaine, ce qui réduit le risque d’exposition, et les solutions sont notées de manière globale par des évaluateurs formés. Cette approche est gourmande en ressources, mais de plus en plus nécessaire pour mesurer de véritables améliorations des capacités.