SWE-Bench Verified : ce qu’un résultat mesure réellement et pourquoi il ne suffit pas pour choisir un agent de code

À quelle question SWE-Bench Verified répond, et à laquelle il ne répond pas

SWE-Bench est une évaluation fondée sur des incidents GitHub historiques et sur les modifications correctives qui leur sont associées. Son sous-ensemble Verified contient 500 instances examinées par des personnes afin d’améliorer la fiabilité de l’évaluation. En pratique, il pose une question délimitée : à partir du contexte fourni pour un incident dans un dépôt donné, un système peut-il proposer un correctif qui réussit les tests définis pour cette tâche dans un environnement reproduit ?

Cette réponse est précieuse parce qu’elle relie la génération de code à un résultat exécutable, et non seulement à une préférence humaine ou à une correspondance textuelle avec une solution attendue. Un agent doit parcourir une base de code, interpréter une description, modifier des fichiers et produire un changement compatible avec les tests de l’environnement. La métrique résume toutefois ce processus en une proportion de tâches qui satisfont un critère binaire de résolution.

Elle ne permet pas, à elle seule, de savoir si un agent peut fonctionner de manière responsable et autonome dans un dépôt réel. Elle n’établit pas qu’il sait prioriser une file d’incidents, demander des précisions sur des exigences ambiguës, décider qu’il ne faut pas modifier le code, examiner une contribution tierce, gérer des secrets, coordonner un déploiement, répondre à une alerte opérationnelle ou assumer la responsabilité d’une régression. Ces activités dépendent de personnes, de politiques, de systèmes et de contextes qui ne sont pas représentés de façon complète par une instance fermée.

Il faut donc lire un score comme un élément de preuve relatif à une capacité évaluée selon un protocole précis, et non comme un classement général d’outils d’ingénierie. Dans les sections Benchmarks, Comparer et Découvrir, il peut être raisonnable de l’employer comme un signal parmi d’autres, à condition de conserver ses conditions d’obtention et de ne pas transformer un chiffre isolé en promesse de résultats opérationnels.

Anatomie d’une tâche : d’un incident historique à un correctif évalué

La construction initiale de SWE-Bench part de problèmes résolus sur GitHub dans 12 dépôts Python open source et les relie à la demande de modification correspondante. Une instance réunit, au minimum sur le plan conceptuel, l’incident, l’état historique du dépôt sur lequel le travail sera réalisé et la modification de référence du projet. Le benchmark transforme ce matériau historique en une tâche qu’un système peut tenter de résoudre par une modification de code.

Il convient de distinguer la modification de référence de la condition de réussite. L’objectif n’est pas nécessairement de reproduire le correctif humain d’origine, caractère par caractère. Un correctif alternatif peut être accepté s’il satisfait, une fois appliqué à l’environnement de l’instance, les tests de correction prévus et s’il ne casse pas les tests de préservation. Cette distinction importe : elle évite de considérer le benchmark comme un exercice de récupération exacte d’une réponse.

Verified ajoute une couche de filtrage humain aux instances de SWE-Bench. La documentation du projet décrit l’ensemble comme un sous-ensemble de 500 instances validé par des personnes. La sélection vise à retirer les cas dont l’évaluation n’est pas suffisamment fiable ; elle ne transforme toutefois pas chaque problème en représentation exhaustive de l’ingénierie logicielle et ne supprime pas toute ambiguïté d’interprétation possible.

Une exécution reproductible exige davantage que le texte de l’incident. Elle doit préciser la révision des données, l’identifiant de chaque instance, l’image ou la définition de l’environnement, la version du harness, le correctif produit et les limites d’exécution. La distribution de données consultée est servie depuis une branche susceptible de changer ; citer uniquement le nom de cette branche ne fixe donc pas le même ensemble pour des répétitions ultérieures. Il faut immobiliser une révision complète et enregistrer la date de consultation.

Comment une résolution est définie, et pourquoi le pourcentage final masque des choix méthodologiques

Selon la description de l’évaluation, l’agent ne voit pas les tests. Le harness évalue le correctif au moyen de deux groupes : les tests FAIL_TO_PASS et les tests PASS_TO_PASS. Les premiers représentent le comportement que la modification doit corriger ; les seconds servent à vérifier que l’édition n’a pas involontairement cassé des parties non liées de la base de code. Pour qu’une modification soit considérée comme une résolution complète, les deux groupes doivent réussir.

Cette définition est plus exigeante que de vérifier que le code compile ou qu’un seul nouveau test réussit. Elle permet aussi de comparer des correctifs fonctionnellement différents sans imposer l’égalité avec le changement historique. Pourtant, un pourcentage final masque encore des décisions : combien d’instances sont incluses dans le dénominateur, comment sont traitées les erreurs d’infrastructure, combien de temps est accordé à chaque tâche, combien d’échantillons sont générés et quelle politique sert à choisir l’un d’entre eux.

Le harness officiel documente des paramètres permettant de sélectionner l’ensemble et les instances, de définir un délai d’expiration et de séparer les exécutions. Il applique également les correctifs, exécute les tests et calcule les résultats. Dès lors, communiquer uniquement un taux de résolution sans publier la commande ou une configuration équivalente rend difficile la vérification que deux chiffres ont utilisé les mêmes tâches, les mêmes limites et le même mécanisme d’évaluation.

Il faut éviter la conclusion inverse, tout aussi simpliste, selon laquelle une métrique binaire serait inutile parce qu’elle ne couvre pas tout le cycle de développement. Cette métrique peut apporter une preuve concrète concernant la réparation d’incidents dans des conditions définies. L’enjeu est d’en délimiter la portée et d’exiger une traçabilité suffisante pour qu’une autre personne puisse inspecter les conditions de l’affirmation.

Les sept champs minimaux pour comparer deux résultats publiés

Un tableau responsable n’a pas besoin d’exposer chaque détail interne d’un système, mais il doit permettre de distinguer une exécution d’une autre. Le premier champ est l’identité exacte de l’ensemble : nom, variante, révision figée et liste des instances ou règle de sélection. « SWE-Bench Verified » ne suffit pas si le résultat a été produit sur un échantillon, une copie modifiée ou une version différente des données.

Le deuxième champ est le modèle : fournisseur, nom, version ou date identifiable lorsqu’elle existe, ainsi que les paramètres d’inférence qui affectent le résultat. Le troisième est l’échafaudage de l’agent : framework, version et stratégie de planification ou d’édition. Un même modèle peut obtenir des résultats différents si la boucle d’outils, le format du contexte, la gestion des erreurs ou le critère d’arrêt changent.

Le quatrième champ décrit les outils activés : terminal, recherche locale, édition de fichiers, exécution de tests, accès réseau et toute récupération externe. Le cinquième déclare le budget : limite de pas, appels au modèle, jetons lorsqu’ils sont disponibles, temps par instance et ressources de calcul. Le sixième indique le protocole : nombre d’échantillons, température ou autre configuration de génération, relances et règle de sélection. Le septième fournit les artefacts permettant de contrôler le résultat : configuration, journaux suffisants, correctifs ou prédictions et sortie du harness lorsqu’ils peuvent être partagés.

La page du projet distingue un classement général qui réunit des systèmes hétérogènes d’une comparaison de modèles dans une configuration commune fondée sur mini-SWE-agent. Cette distinction est un avertissement méthodologique : un classement de systèmes complets n’isole pas l’effet du modèle, alors qu’une configuration commune peut aider dans cette comparaison particulière. Le projet avertit également que les versions 1.x et 2.x de mini-SWE-agent ne sont pas nécessairement comparables.

Toutes ces informations ne seront pas forcément disponibles dans une note de version. Dans ce cas, le résultat n’est pas automatiquement réfuté, mais il doit être étiqueté comme incomplètement spécifié. La réponse rigoureuse ne consiste pas à combler les lacunes par des hypothèses sur le fournisseur ni à classer des chiffres hétérogènes comme s’ils provenaient d’une expérience contrôlée.

Ce qui peut augmenter ou limiter un score

La sélection des tâches est le premier facteur. Un sous-ensemble choisi selon la difficulté, la disponibilité de l’environnement ou des succès antérieurs ne conserve pas nécessairement la même distribution que l’ensemble complet. Il importe aussi de savoir si les instances qui dépassent le temps imparti, échouent lors de la construction de l’image ou présentent des problèmes d’infrastructure sont exclues. Un rapport doit distinguer autant que possible une défaillance de l’agent d’une défaillance de l’environnement, et expliquer l’effet des deux sur le résultat agrégé.

Les relances et les échantillons multiples méritent une attention spécifique. Essayer plusieurs correctifs par incident peut être une décision technique légitime, notamment si cela reflète l’usage prévu du système, mais cela change l’unité pratique de l’évaluation : on ne mesure plus le succès d’une tentative unique. Il faut publier le nombre maximal de tentatives, préciser si l’agent est redémarré et indiquer si les exécutions en échec sont relancées.

Les informations accessibles au système modifient la nature de la tâche. Les tests cachés réduisent une voie directe d’adaptation à la réponse attendue, mais n’éliminent pas d’autres différences : selon le protocole, l’agent peut disposer de recherche, d’outils d’exécution, de documentation locale ou d’un accès externe. Une comparaison valide suppose de connaître les ressources activées et de vérifier qu’elles étaient identiques pour tous les systèmes comparés.

Une incertitude temporelle demeure aussi. OpenAI a exposé sa position selon laquelle SWE-Bench Verified ne mesure plus les capacités de programmation de pointe et a signalé le risque de contamination lié à la disponibilité publique des problèmes et des solutions historiques. Il s’agit d’une évaluation et d’une recommandation d’OpenAI, non d’une mesure indépendante permettant de quantifier la contamination de chaque modèle. Elle impose néanmoins de la prudence lorsqu’une amélioration récente est interprétée comme un progrès général sans examen de l’exposition potentielle aux données.

L’analyse d’Epoch AI soulève une autre limite : le benchmark se concentre sur des dépôts connus et des correctifs relativement circonscrits. C’est une interprétation secondaire, non une propriété à présenter comme un fait définitif de chaque instance. Elle aide néanmoins à poser une question utile : le portefeuille de maintenance de l’organisation ressemble-t-il matériellement à ces tâches historiques de dépôts Python ? Dans le cas contraire, le transfert attendu du signal sera limité et incertain.

Pourquoi un incident résolu ne démontre pas une maintenance autonome

Dans un dépôt réel, résoudre un incident commence avant l’écriture d’un correctif. Il faut faire le triage, reproduire le problème, estimer l’impact, identifier les dépendances, négocier les exigences et décider des priorités. Une tâche de benchmark fournit une formulation historique et un critère de test préparé ; en exploitation normale, ces entrées peuvent manquer, être contradictoires ou évoluer pendant l’enquête.

Après le correctif, un taux de résolution ne couvre pas suffisamment d’autres activités : revue par les pairs, analyse de sécurité, licences, rétrocompatibilité, migrations, performance, observabilité, approbation des changements et déploiement. Les tests de préservation du benchmark constituent une protection importante à l’intérieur de l’instance, mais ils ne sont pas équivalents à toutes les validations d’une organisation ni aux effets de l’intégration d’un changement avec les branches, les services et les utilisateurs actuels.

La responsabilité opérationnelle est une autre limite. Un agent peut générer une modification qui réussit les tests du harness tout en nécessitant une supervision humaine pour décider si elle doit être fusionnée, quand elle doit être déployée et comment elle doit être annulée. L’achat, l’adoption ou l’autorisation d’écriture d’un outil ne devrait donc pas dépendre uniquement d’un pourcentage SWE-Bench Verified. La décision doit intégrer des contrôles d’accès, une revue, une traçabilité, une isolation et des tests propres à l’environnement concerné.

Cela ne rend pas le benchmark sans intérêt pour les responsables de l’ingénierie. Il peut aider à sélectionner des hypothèses pour un essai ultérieur : par exemple, si un système montre une capacité à modifier et valider des correctifs sur des tâches historiques, il peut mériter une évaluation contrôlée sur des incidents internes à faible risque. La bonne transition va de la preuve issue du benchmark à l’expérience locale, et non du benchmark à l’autonomie en production.

Comment transposer le signal à un essai bref dans son propre dépôt

Il n’est pas nécessaire de reproduire l’intégralité de SWE-Bench pour obtenir des informations plus proches de la réalité locale. Un essai bref peut employer un petit ensemble d’incidents déjà clos ou de modifications préparées spécifiquement, à condition que les responsables définissent à l’avance les critères d’inclusion, les accès autorisés et la méthode d’évaluation. L’objectif n’est pas de fabriquer un nouveau tableau public, mais de réduire l’incertitude liée à une décision technique précise.

La conception doit séparer les tâches de développement des tâches d’évaluation. La personne ou l’équipe qui prépare les cas peut conserver des tests d’acceptation invisibles pour l’agent, lorsque cela est faisable et approprié. Chaque cas doit inclure un environnement isolé, un état de dépôt figé et des limites explicites de temps, de coût et d’outils. Il ne faut pas donner au système accès à des identifiants de production ni l’autoriser à effectuer des changements en dehors de l’environnement contrôlé.

Mesurez plusieurs dimensions. Outre la réussite des tests, consignez le temps jusqu’au correctif, le nombre d’interventions humaines, la qualité de l’explication, le respect des conventions du dépôt, les constats de revue et les incidents de sécurité ou de processus. Un petit échantillon ne permet pas des inférences générales ; il peut néanmoins révéler des incompatibilités évidentes, des coûts inattendus ou des catégories de tâches dans lesquelles le système demande une supervision excessive.

La comparaison la plus utile maintient le protocole constant. Si deux systèmes sont testés, veillez à leur fournir les mêmes cas, la même fenêtre temporelle, le même accès aux outils et les mêmes limites. Si l’agent est modifié ou si un budget plus élevé est accordé à l’un d’eux, communiquez ce changement comme partie intégrante du résultat au lieu d’attribuer toute différence au modèle.

Fiche finale : ce qui peut être affirmé avec rigueur

Une affirmation solide adopte une forme limitée : « Dans la révision déclarée de SWE-Bench Verified, avec ce modèle, cette version d’agent, ces outils, ce budget et ce protocole, l’exécution a obtenu ce taux d’instances satisfaisant le critère du harness. » Si les artefacts sont disponibles, on peut ajouter que le résultat est auditable ou reproductible dans les conditions publiées. S’ils manquent, il convient d’indiquer que l’affirmation ne peut pas être entièrement vérifiée avec les informations disponibles.

Il n’est pas rigoureux de transformer cette affirmation en « le modèle résout ce pourcentage de vrais bugs », « c’est le meilleur agent de code » ou « il peut maintenir un dépôt sans supervision ». Ces conclusions élargissent la population, le contexte et les responsabilités sans preuve équivalente. Même une exécution irréprochable du benchmark ne répond qu’aux tâches et au protocole effectivement évalués.

La documentation primaire fournit des bases claires à cette lecture : Verified est un sous-ensemble humain de 500 instances ; une résolution exige de réussir les tests de correction et de préservation ; et la configuration du harness fait partie intégrante de l’exécution. Des incertitudes persistent néanmoins : la disponibilité publique des tâches peut affecter la validité temporelle pour certains modèles, les configurations d’agents évoluent et une tâche historique ne reproduit pas tous les mécanismes sociaux et opérationnels de la maintenance.

La décision pratique consiste à conserver ces deux idées. SWE-Bench Verified peut être un signal technique utile et plus concret qu’une démonstration anecdotique. Ce n’est pas une garantie d’autonomie, de sécurité, de productivité nette ni d’adéquation à un dépôt particulier. Toute personne qui publie, compare ou achète à partir de ces résultats doit rendre visibles les conditions qui transforment un chiffre en preuve, ainsi que les incertitudes qui empêchent de le transformer en promesse.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.