Distinguer le signal du bruit dans les évaluations de code

Mesurer avec exactitude les capacités de nos modèles est essentiel pour prendre de bonnes décisions de déploiement et de sécurité, y compris dans le cadre du cadre de préparation⁠(s'ouvre dans une nouvelle fenêtre) d’OpenAI. À chaque lancement de modèle, nous publions des résultats sur divers bancs d’essai externes et internes afin de suivre les progrès des modèles. Lorsque les évaluations comportent des lacunes qui influencent les résultats, elles peuvent donner une fausse idée des capacités, fausser les dossiers de sécurité et influer sur les priorités de recherche.

Nous avons récemment examiné comment SWE-bench Verified, l’un des bancs d’essai de programmation les plus utilisés, présentait des problèmes fondamentaux de conception et de contamination, et avons constaté que cette évaluation ne fournissait plus de signal utile sur les capacités de développement logiciel. À ce moment-là, nous avions encouragé l’ensemble de la communauté à passer à SWE-Bench Pro.

SWE-Bench Pro⁠(s'ouvre 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 tirées de manière 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 briser les fonctionnalités existantes. Sur le volet public 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.

Depuis, nous avons effectué un audit similaire de SWE-Bench Pro, en examinant le jeu de données à l’aide d’un pipeline d’analyse des points de données. Le pipeline a examiné les tentatives des modèles pour la tâche, les métadonnées de la tâche et les traces d’échec afin de signaler les failles d’évaluation probables. Chaque tâche signalée a ensuite été évaluée au moyen de plusieurs passages d’agents enquêteurs, puis examinée indépendamment par cinq ingénieurs logiciels expérimentés; les désaccords ont été transmis pour enquête supplémentaire.

Les problèmes se répartissaient principalement en quatre catégories :

• Les tests trop stricts¹ imposent des détails d’implémentation précis qui ne sont pas indiqués dans l’invite, ce qui invalide de nombreuses soumissions fonctionnellement correctes.
• Les invites insuffisamment précisées² omettent des exigences appliquées par les tests cachés et qui ne sont pas raisonnablement déductibles.
• Les tests à faible couverture vérifient insuffisamment la fonctionnalité demandée, de sorte que des correctifs incomplets peuvent réussir.
• Une invite trompeuse oriente les modèles vers le mauvais comportement ou contredit ce que les tests exigent.

Nos constats montrent à quel point il est difficile de constituer des bancs d’essai exigeants mais équitables, et soulignent l’utilité croissante des agents pour effectuer des contrôles de qualité des données à grande échelle. À la lumière de ces résultats, nous estimons qu’environ 30 % des tâches de SWE-bench Pro sont défaillantes 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 reflètent des solutions complètes et valides aux exigences de l’invite. 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 fidèlement les capacités des modèles.

Un filtre automatisé initial examine les instructions données au modèle, les tentatives du modèle pour résoudre la tâche et les tests utilisés pour noter ces tentatives, afin de signaler les exemples probablement défaillants ou problématiques. Ce filtre a signalé 286 tâches potentiellement défaillantes. Nous avons ensuite mené un examen plus approfondi de ce sous-ensemble de deux façons : un examen par agents sous supervision humaine, qui effectue des vérifications poussées avec des agents enquêteurs et produit 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é par des agents enquêteurs basés sur Codex, qui ont 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, souvent résoluble 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 examiner les tentatives des modèles ainsi que leurs modes d’échec courants sur la tâche. Après plusieurs répétitions indépendantes de ces audits approfondis, un chercheur a examiné les résumés, rendu 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 banc d’essai, à 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 réviseurs ont formulé un jugement indépendant à partir de l’énoncé visible du problème, des cas de test et de la solution de référence véridique (appelée « correctif de référence ») avant d’utiliser l’analyse du pipeline ou la transcription comme contexte d’appui. Les réviseurs ont ensuite attribué une étiquette et une cote de gravité en fonction de preuves concrètes, et ont transmis les désaccords ou les cas peu sûrs pour examen supplémentaire.

Les réviseurs humains étaient plus susceptibles que les agents enquêteurs de marquer des tâches comme défaillantes. Il y avait aussi certains désaccords sur les catégories entre les deux méthodes d’examen, mais pour aucune tâche signalée, l’étiquette humaine la plus fréquente n’était « non défaillante ». Parmi les catégories signalées par le pipeline d’agents, les jugements des réviseurs se recoupaient dans 74 % des cas.

Comparativement au pipeline d’agents, les réviseurs humains étaient également plus susceptibles de choisir plusieurs étiquettes pour une tâche, ce qui indique qu’ils jugeaient que des tâches étaient défaillantes de plusieurs façons ou ne cadraient pas nettement avec une seule catégorie. Cela laisse penser que le pipeline combinant agents et réviseurs a produit un étiquetage prudent : il a saisi les mêmes grands modes d’échec que ceux relevés par les humains, tout en sous-comptant les cas où les réviseurs voyaient des problèmes supplémentaires ou chevauchants. L’écart le plus important concernait les tests à faible couverture, que les humains ont choisis comme problème le plus courant pour 9,4 % du banc d’essai, contre 4,1 % avec le pipeline d’agents.

Les problèmes que nous avons relevés, ajoutés à des cas similaires dans SWE-bench Verified, soulignent l’importance de vérifier rigoureusement les bancs d’essai. Les tickets et les pull requests issus de dépôts à code source ouvert ont été créés à l’origine pour la collaboration humaine, souvent à travers de longs échanges entre responsables de la maintenance 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 nettes 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 pour résoudre la tâche.

Parallèlement, les failles d’évaluation sont maintenant plus faciles à détecter qu’elles ne l’auraient été même il y a peu de temps. À mesure que les capacités des modèles s’améliorent, nous pouvons utiliser ces modèles pour examiner les invites, les tests, les correctifs, les traces et les cas limites avec beaucoup plus de profondeur et de constance, ce qui aide à faire ressortir des problèmes de bancs d’essai auparavant coûteux ou impraticables à trouver à grande échelle.

Nous espérons que la communauté de l’évaluation dans son ensemble développera de nouveaux bancs d’essai conçus par des développeurs logiciels expérimentés précisément pour tester les capacités des modèles. Cette approche peut préserver le niveau d’exigence élevé 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 par cette analyse, nous retirons notre recommandation antérieure d’adopter SWE-Bench Pro.

En définitive, une évaluation devrait fournir un signal utile au moyen de bancs d’essai difficiles à manipuler, faciles à juger fiables et véritablement représentatifs de la capacité ou de l’alignement des modèles. Comme ces résultats éclairent les décisions de déploiement et de sécurité d’OpenAI, les évaluations que nous suivons doivent être valides et informatives.