Distinguer le signal du bruit dans les évaluations de code

Mesurer avec précision les capacités de nos modèles est essentiel pour prendre de bonnes décisions de déploiement et de sécurité, y compris au titre du cadre de préparation⁠(ouverture dans une nouvelle fenêtre) d’OpenAI. À chaque lancement de modèle, nous publions des résultats sur divers benchmarks externes et internes afin de suivre les progrès des modèles. Lorsque les évaluations présentent des défauts qui affectent les résultats, elles peuvent donner une vision erronée des capacités, fausser les dossiers de sécurité et influencer les priorités de recherche.

Nous avons récemment étudié l’un des benchmarks de programmation les plus utilisés, SWE-bench Verified, et constaté qu’il présentait des problèmes fondamentaux de conception et de contamination, au point que l’évaluation ne fournissait plus de signal significatif sur les capacités de développement logiciel. À l’époque, nous avions encouragé la communauté à adopter SWE-Bench Pro.

SWE-Bench Pro⁠(ouverture dans une nouvelle fenêtre) a été conçu pour améliorer SWE-bench Verified en testant les modèles sur des horizons plus longs et des tâches de programmation plus réalistes, afin de mieux suivre les capacités de programmation agentique. Comme dans SWE-bench Verified, les tâches sont extraites de façon programmatique de l’historique des changements de fonctionnalités dans un ensemble de dépôts publics et privés. Les modèles doivent implémenter une solution qui réussit de nouveaux tests pour une fonctionnalité, sans casser les fonctionnalités existantes. Sur la partition publique de 731 tâches, les modèles de pointe sont passés d’un taux de réussite de 23,3 % à 80,3 % en huit mois.

Nous avons depuis réalisé un audit similaire de SWE-Bench Pro, en examinant le jeu de données au moyen d’un pipeline d’analyse des points de données. Le pipeline a examiné les tentatives des modèles sur la tâche, les métadonnées de la tâche et les traces d’échec afin de signaler les défauts d’évaluation probables. Chaque tâche signalée a ensuite été évaluée au moyen de plusieurs passes d’investigation par agent et examinée indépendamment par cinq ingénieurs logiciels expérimentés, les désaccords étant transmis pour une analyse plus poussée.

Les problèmes relevaient principalement de quatre catégories :

• Les tests trop stricts¹ imposent des détails d’implémentation précis qui ne sont pas indiqués dans le prompt, invalidant de nombreuses soumissions fonctionnellement correctes.
• Les prompts insuffisants² omettent des exigences imposées par les tests masqués et qui ne sont pas raisonnablement déductibles.
• Les tests à faible couverture vérifient insuffisamment la fonctionnalité demandée, si bien que des correctifs incomplets peuvent réussir.
• Un prompt trompeur oriente les modèles vers le mauvais comportement ou contredit ce que les tests exigent.

Nos conclusions montrent combien il est difficile de constituer des benchmarks exigeants mais équitables, et combien les agents deviennent utiles pour effectuer des contrôles de qualité des données à grande échelle. Au vu de ces résultats, nous estimons qu’environ 30 % des tâches de SWE-bench Pro sont défectueuses, et recommandons aux développeurs de modèles d’examiner les résultats avec soin.

Notre objectif est de faire en sorte que les échecs aux tâches reflètent de véritables limites des modèles, et que les réussites correspondent à des solutions complètes et valides aux exigences du prompt. Pour vérifier la qualité des données utilisées dans l’évaluation, nous avons créé un pipeline d’assurance qualité afin d’évaluer si chaque point de données reflète correctement les capacités des modèles.

Un premier filtre automatisé examine les instructions données au modèle, ses tentatives pour résoudre la tâche et les tests utilisés pour noter ces tentatives, afin de signaler les exemples probablement défectueux ou problématiques. Ce filtre a signalé 286 tâches potentiellement défectueuses. Nous avons ensuite mené un examen plus approfondi de ce sous-ensemble de deux façons : un examen par agent supervisé par des humains, qui effectue des vérifications poussées avec des agents enquêteurs et aboutit à un jugement humain final ; et une campagne d’annotation humaine menée avec des développeurs logiciels expérimentés.

Chaque problème signalé est audité avec des agents enquêteurs basés sur Codex, qui ont reçu l’accès au dépôt et à l’environnement de la tâche. Cela les aide à distinguer l’ambiguïté raisonnable d’une tâche, qui peut souvent être levée en étudiant le code voisin et les conventions du dépôt, d’une véritable sous-spécification. L’agent peut exécuter des tests, inspecter des fichiers dans le dépôt et analyser les tentatives des modèles ainsi que leurs modes de défaillance courants sur la tâche. Après plusieurs répétitions indépendantes de ces audits approfondis, un chercheur a examiné les synthèses, porté un jugement final et étiqueté les problèmes probables.

En parallèle, nous avons mené une campagne d’annotation humaine sur le sous-ensemble signalé. Nous avons travaillé avec des ingénieurs logiciels expérimentés, formés aux objectifs du benchmark, à la taxonomie des problèmes et aux cas limites avant d’examiner les tâches. Chaque tâche a été examinée par cinq ingénieurs.

Les évaluateurs se sont d’abord forgé un jugement indépendant à partir de l’énoncé visible du problème, des cas de test et de la solution de référence réelle (appelée gold patch), avant d’utiliser l’analyse du pipeline ou la transcription comme contexte complémentaire. Les évaluateurs ont ensuite attribué une étiquette et une note de gravité sur la base d’éléments concrets, et transmis les désaccords ou les cas de faible confiance pour un examen supplémentaire.

Les évaluateurs humains étaient plus susceptibles que les agents enquêteurs de marquer les tâches comme défectueuses. Les deux parcours d’examen présentaient aussi certains désaccords sur les catégories, mais pour aucune tâche signalée, « non défectueuse » n’a été l’étiquette humaine la plus fréquente. Pour les catégories signalées par le pipeline d’agents, les jugements des évaluateurs se recoupaient dans 74 % des cas.

Par rapport au pipeline d’agents, les évaluateurs humains étaient aussi plus susceptibles de sélectionner plusieurs étiquettes pour une tâche, ce qui indique qu’ils estimaient que certaines tâches étaient défectueuses de plusieurs façons ou n’entraient pas clairement dans une seule catégorie. Cela suggère que le pipeline associant agent et évaluateur a produit un étiquetage conservateur : il a capturé les mêmes grands modes de défaillance que ceux identifiés par les humains, tout en sous-estimant les cas où les évaluateurs voyaient des problèmes supplémentaires ou qui se recoupaient. L’écart le plus important concernait les tests à faible couverture, que les humains ont sélectionnés comme problème le plus courant pour 9,4 % du benchmark, contre 4,1 % dans le pipeline d’agents.

Les problèmes que nous avons identifiés, ainsi que des cas similaires dans SWE-bench Verified, soulignent l’importance de vérifier rigoureusement les benchmarks. Les issues et pull requests de dépôts open source ont été créées à l’origine pour la collaboration humaine, souvent au fil de longs échanges entre mainteneurs et contributeurs. Par conséquent, les descriptions de problèmes, le code fusionné et les tests unitaires ne s’alignent pas toujours pour former des tâches propres et isolées permettant d’évaluer les modèles de façon fiable. En particulier, les tests inclus dans les pull requests peuvent être trop stricts, car ils sont écrits pour valider un changement précis plutôt que pour définir une norme indépendante de l’implémentation afin de résoudre la tâche.

Dans le même temps, les défauts d’évaluation sont aujourd’hui plus faciles à détecter qu’ils ne l’auraient été il y a encore peu de temps. À mesure que les capacités des modèles progressent, nous pouvons utiliser ces modèles pour inspecter prompts, tests, correctifs, traces et cas limites avec bien plus de profondeur et de cohérence, ce qui aide à faire émerger des problèmes de benchmarks qu’il était auparavant coûteux ou impraticable de trouver à grande échelle.

Nous espérons que la communauté de l’évaluation dans son ensemble développera de nouveaux benchmarks conçus par des développeurs logiciels expérimentés, spécifiquement pour tester les capacités des modèles. Cette approche peut préserver le niveau d’exigence et le réalisme nécessaires pour mesurer les capacités des modèles, tout en permettant une meilleure supervision humaine tout au long du processus. Compte tenu des problèmes mis au jour dans cette analyse, nous retirons notre recommandation précédente d’adopter SWE-Bench Pro.

En définitive, une évaluation doit fournir un signal significatif au moyen de benchmarks difficiles à détourner, faciles à juger fiables et reflétant réellement les capacités ou l’alignement des modèles. Comme ces résultats éclairent les décisions d’OpenAI en matière de déploiement et de sécurité, les évaluations que nous suivons doivent être valides et informatives.