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

Depuis que nous avons lancé 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 d’ingénierie logicielle autonome. Après son lancement, 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 le critère de 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⁠(ouverture dans une nouvelle fenêtre).

Après des progrès initiaux, les avancées de pointe sur SWE-bench Verified ont ralenti, s’améliorant⁠(ouverture dans une nouvelle fenêtre) de 74.9 % à 80.9 % au cours des six 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 relatifs à l’ensemble Verified, qui indiquent que ce critère de référence n’est plus adapté pour mesurer les progrès des capacités d’ingénierie logicielle autonome pour des 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 comportaient des cas de test défectueux qui rejetaient des soumissions fonctionnellement correctes, malgré tous nos efforts pour améliorer ce point lors de la création initiale de SWE-bench Verified.
2. Entraînement sur des solutions : étant donné que 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 avec des élèves, avant l’épreuve, les problèmes et les solutions d’un test à venir : ils ne mémoriseront peut-être pas la réponse, mais les élèves qui auront déjà vu les réponses s’en sortiront certainement mieux que ceux qui ne les auront pas vues. Les problèmes utilisés dans SWE-bench proviennent de dépôts open source 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 bug original, rédigé par un humain, utilisé comme référence de vérité terrain, connu sous le nom de correctif gold, ou des éléments spécifiques de l’énoncé du problème au mot près pour certaines tâches, ce qui indique qu’ils ont tous rencontré au moins une partie des problèmes et des solutions pendant l’entraînement.

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

Cela signifie que les améliorations sur SWE-bench Verified ne reflètent plus les améliorations significatives des capacités de développement logiciel des modèles dans le monde réel. Au contraire, elles reflètent de plus en plus le degré d’exposition du modèle au critère de 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 de faire de même.

Nous mettons au point de nouvelles évaluations non contaminées afin de mieux suivre les capacités de codage, et nous pensons qu’il s'agit d’un domaine important sur lequel la communauté des chercheurs au sens large doit se pencher. En attendant, OpenAI recommande de rapporter les résultats pour SWE-bench Pro.

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

• Des tests qui échouent sur la base de code non modifiée mais réussissent si le problème est correctement corrigé.
• Des tests de régression qui réussissent à la fois avant et après la correction afin de s’assurer 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 ne disposant que du texte original du problème et de l’état du dépôt avant le correctif. Il ne valide 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 conduire à une sous-estimation de la capacité des modèles.

• Certains tests unitaires étaient trop spécifiques ou mal alignés sur la tâche, de sorte que des correctifs valides pouvaient être rejetés.
• De nombreux énoncés de tâches n’étaient pas suffisamment précis, ce qui pouvait donner lieu à plusieurs interprétations valables, alors que les tests n’en couvraient qu’une seule.
• Selon la configuration de l’environnement (par exemple Linux ou Windows, ou la version de Python), certains tests pourraient échouer de manière sporadique.

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 ceux qui présentaient ces problèmes. Chaque problème a été examiné indépendamment par trois experts. Ce processus d’examen a abouti à SWE-bench Verified, un ensemble sélectionné de 500 problèmes.

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

Nous avons constaté que 59,4 % des 138 problèmes contenaient des problèmes importants dans la conception du test ou dans la description du problème, ce qui les rendait 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 spécifiques, invalidant de nombreuses soumissions pourtant fonctionnellement correctes, que nous appelons cas de test étroits.
• 18,8 % des tâches auditées ont des tests qui vérifient des fonctionnalités supplémentaires qui n’étaient pas spécifiées dans la description du problème, que nous appelons cas de test larges.
• Les 5,1 % de tâches restantes présentaient des problèmes divers qui n’étaient pas bien regroupés dans cette taxonomie.

Un exemple illustratif du premier mode de défaillance est pylint-dev__pylint-4551⁠(ouverture dans une nouvelle fenêtre), où la requête d’extraction 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 large est sympy__sympy-18199⁠(ouverture 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 », à savoir #17373⁠(ouverture dans une nouvelle fenêtre), #17377⁠(ouverture dans une nouvelle fenêtre) et #18212⁠(ouverture dans une nouvelle fenêtre). La description de la tâche SWE-bench Verified, cependant, ne couvre que l’incident final #18212⁠(ouverture dans une nouvelle fenêtre). Cela crée une incohérence : les tests de la requête d’extraction couvrent les trois problèmes, tandis que la description n’en détaille qu’un seul. Lors de nos exécutions, les modèles mettent souvent correctement en œuvre 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 open source 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⁠(ouverture dans une nouvelle fenêtre) les tests nécessitent un nouveau paramètre spécifique « edit_only » qui n’est pas explicitement requis 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 modifications apportées à 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 mis en place une configuration automatisée d’exercices d’équipe rouge. Pour chaque question SWE-bench Verified, nous avons chargé GPT‑5 de sonder un GPT‑5.2‑Chat, Claude Opus 4.5 et Gemini 3 Flash Preview pour la contamination. Ces modèles ont été choisis afin d’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 éventuelle contamination, GPT‑5 a reçu : l’ID, la description, le correctif gold et les tests de requête d’extraction de la tâche SWE-bench Verified. Sur plus de 15 tours, nous avons permis à GPT‑5 de faire varier le prompt système/développeur, le prompt utilisateur et le préremplissage de l’assistant, ainsi que 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 apparues et chaque réponse a été étiquetée selon la gravité de la contamination, de « none » (aucune) à « strong » (forte). GPT‑5 a été autorisé à adapter sa stratégie en fonction des tours précédents afin de récupérer de manière itérative des détails propres à la tâche. Pour chaque exemple de contamination importante, 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 vérifié manuellement les exemples « strong » qui constituent les transcriptions de cet article.

Voici des exemples de forte contamination entre différents fournisseurs de modèles.

À partir d’un court extrait de la description de la tâche, GPT‑5.2 produit le correctif gold exact. 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⁠(ouverture dans une nouvelle fenêtre)

Opus est capable non seulement de se souvenir exactement de la modification fonctionnelle en quatre lignes introduite par la requête d’extraction, ainsi que du nom de fichier et de la méthode spécifiques qu’elle a affectés, mais aussi de citer mot pour mot le commentaire dans le texte qui faisait partie du diff. 

ID de tâche : astropy__astropy-13236⁠(ouverture 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’ID, est capable de restituer mot pour mot des détails issus de la description de la tâche et du correctif gold. 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⁠(ouverture dans une nouvelle fenêtre)

À partir de cet audit de SWE-bench Verified, nous tirons deux enseignements plus généraux pour la conception des évaluations. Tout d’abord, les critères de références issus de documents accessibles au public présentent un risque de contamination, car l’exposition aux données d’entraînement peut gonfler discrètement les scores. Si des données explorées publiquement sont utilisées dans la construction d’un critère de référence, les développeurs de modèles doivent effectuer des tests supplémentaires pour détecter toute contamination. Les critères de référence, et même leurs solutions, publiés publiquement peuvent se retrouver dans des données d’entraînement. Il convient de faire preuve d’une vigilance particulière, tant dans la manière dont les ensembles de données sont publiés (c.-à-d. protégés par mot de passe) que dans le filtrage des données d’entraînement (c.-à-d. le respect strict des chaînes canary). 

Deuxièmement, la notation automatisée est difficile à réussir ; les cas de test parfaits devraient vérifier pleinement le bon fonctionnement, en étant à la fois indépendants des détails d’implémentation spécifiques et non importants, et également 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’annotation humaine. 

Nous avons intégré ces conclusions à nos récents efforts d’évaluation. Ces derniers mois, nous avons choisi de communiquer les résultats issus 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, empiriquement, semble moins souffrir de problèmes de contamination. Notre pipeline de contamination a détecté quelques cas de contamination, mais ces cas étaient nettement plus rares et moins graves que dans SWE-bench Verified, et aucun modèle n’a été en mesure de produire un correctif gold complet au mot près.

Nous continuerons à investir dans des critères de référence originaux, rédigés en interne, et solliciterons l’aide du secteur et du monde académique pour qu’ils en fassent de même. Dans GDPVal⁠, les tâches sont rédigées de manière privée par des experts du domaine, réduisant ainsi le risque d’exposition ; de plus les solutions sont évaluées globalement par des évaluateurs formés. Cette approche est exigeante en ressources, mais elle devient de plus en plus nécessaire pour mesurer de véritables améliorations des capacités.