Séparer le signal du bruit dans les évaluations de codage

• L’évaluation des capacités de codage des modèles d’IA est directement liée aux décisions de déploiement et de sécurité, mais l’audit d’OpenAI estime qu’environ 30 % des tâches de SWE-Bench Pro sont défectueuses
• SWE-Bench Pro visait des tâches plus longues et plus réalistes, mais il devient difficile de prendre au pied de la lettre le passage du taux de réussite de 23,3 % à 80,3 % en huit mois sur 731 tâches publiques
• Les défauts se répartissent entre des tests trop stricts, des prompts sous-spécifiés, des tests à faible couverture et des prompts trompeurs, ce qui peut faire échouer des soumissions correctes ou laisser passer des correctifs incomplets
• L’audit a signalé 286 tâches potentiellement problématiques à partir des tentatives des modèles, des métadonnées des tâches et du suivi des échecs, avant de les soumettre à un agent d’enquête et à l’examen indépendant de 5 ingénieurs expérimentés
• OpenAI a retiré sa recommandation d’adopter SWE-Bench Pro, estimant que les benchmarks d’évaluation doivent fournir un signal pertinent qui ne déforme ni les capacités des modèles ni les jugements de sécurité

---

Problèmes mis au jour par l’audit de SWE-Bench Pro

• OpenAI estime, après audit de SWE-Bench Pro, qu’environ 30 % de l’ensemble des tâches sont défectueuses
• Mesurer avec précision les capacités des modèles influence aussi les décisions de déploiement et de sécurité dans le cadre du Preparedness Framework
• Des évaluations défaillantes peuvent conduire à une mauvaise compréhension des capacités réelles des modèles et perturber les jugements de sécurité ainsi que les priorités de recherche

Objectif de SWE-Bench Pro et évolution du taux de réussite

• OpenAI avait auparavant identifié des problèmes de conception et de contamination dans SWE-bench Verified, largement utilisé, et a conclu que cette évaluation ne fournissait plus de signal pertinent sur les capacités en développement logiciel
• À l’époque, OpenAI avait recommandé à la communauté de passer à SWE-Bench Pro
• SWE-Bench Pro a été conçu comme une amélioration de SWE-bench Verified afin de suivre les capacités de codage agentique sur des tâches plus longues et plus réalistes
• Les tâches sont extraites de manière programmatique de l’historique des changements fonctionnels dans des dépôts publics et privés
  • Le modèle doit implémenter une solution qui réussit les nouveaux tests de fonctionnalité sans casser les fonctionnalités existantes
  • Sur la partition publique de 731 tâches, le taux de réussite des modèles frontier est passé de 23,3 % à 80,3 % en huit mois

Pipeline d’assurance qualité

• OpenAI a mis en place un pipeline d’assurance qualité pour vérifier si chaque point de donnée reflète réellement les capacités du modèle
• Un filtre automatique initial examine les instructions données au modèle, ses tentatives de résolution et les tests de notation afin de signaler les exemples cassés ou suspects
• Ce processus a permis de signaler 286 tâches potentiellement problématiques
• Le sous-ensemble signalé a ensuite été examiné plus en profondeur selon deux voies
  • Revue d’agent supervisée par des humains : un agent d’enquête effectue des vérifications détaillées avant un jugement humain final
  • Campagne d’annotation humaine : des développeurs logiciels expérimentés examinent directement les tâches

Méthode de revue par agent et de revue humaine

• Les problèmes signalés ont été audités par un agent d’enquête basé sur Codex
  • L’agent a accès au dépôt de la tâche et à l’environnement d’exécution
  • Il peut exécuter les tests, inspecter les fichiers du dépôt et analyser les tentatives des modèles ainsi que les modes d’échec fréquents
  • Il sert à distinguer les ambiguïtés raisonnables, résolubles via le code environnant et les conventions du dépôt, des véritables cas de sous-spécification
• Après plusieurs audits indépendants approfondis, des chercheurs examinent les synthèses puis attribuent le jugement final et les labels de problème
• En parallèle, dans la campagne d’annotation humaine, des ingénieurs logiciels expérimentés examinent les tâches après avoir été formés aux objectifs du benchmark, à la classification des problèmes et aux cas limites
• Chaque tâche est examinée par 5 ingénieurs
  • Les examinateurs rendent d’abord un jugement indépendant à partir de la description visible du problème, des cas de test et du gold patch, la solution de référence
  • Ils utilisent ensuite l’analyse du pipeline ou les journaux comme contexte complémentaire
  • Ils attribuent un label et un niveau de gravité sur la base d’éléments concrets, et transmettent pour examen complémentaire les cas de désaccord ou de faible confiance

Quatre types d’échec

• Les problèmes identifiés lors de l’audit se répartissent principalement en quatre catégories
  • Tests trop stricts : ils imposent des détails d’implémentation spécifiques absents du prompt et invalident des soumissions pourtant correctes sur le plan fonctionnel
  • Prompts sous-spécifiés : ils omettent des exigences imposées par des tests cachés mais difficiles à déduire raisonnablement
  • Tests à faible couverture : ils ne vérifient pas suffisamment la fonctionnalité demandée, ce qui peut laisser passer des correctifs incomplets
  • Prompts trompeurs : ils orientent le modèle vers un comportement incorrect ou contredisent les exigences des tests
• Dans certaines tâches, le prompt exigeait une implémentation particulière alors que les tests cachés attendaient un autre comportement

Différences entre revue humaine et revue par agent

• Les examinateurs humains étaient plus enclins que l’agent d’enquête à marquer une tâche comme défectueuse
• Même s’il existait des écarts de catégorisation entre les deux voies d’examen, aucun des cas signalés n’avait pour label humain majoritaire « non défectueux »
• La catégorie signalée par le pipeline d’agent et le jugement des examinateurs humains se recoupaient dans 74 % des cas
• Les examinateurs humains sélectionnaient aussi plus souvent plusieurs labels pour une même tâche
  • C’est le signe qu’une tâche pouvait être défectueuse de plusieurs façons ou ne pas entrer proprement dans une seule catégorie
  • Un pipeline combinant agent et examinateurs captait l’éventail large des modes d’échec relevés par les humains, mais comptabilisait de manière conservatrice moins de problèmes supplémentaires ou redondants
• L’écart le plus important apparaissait sur les tests à faible couverture
  • Les humains les ont jugés comme le problème le plus fréquent sur 9,4 % du benchmark
  • Le pipeline d’agent les a signalés dans 4,1 % des cas

Pourquoi il est difficile de construire un benchmark

• Les cas de SWE-Bench Pro et de SWE-bench Verified montrent qu’un benchmark doit être validé de manière rigoureuse
• Les issues et pull requests des dépôts open source sont à l’origine conçues pour la collaboration humaine, pas pour l’évaluation des modèles
• Dans des contextes où les allers-retours entre mainteneurs et contributeurs sont nombreux, la description du problème, le code fusionné et les tests unitaires ne constituent pas toujours des tâches propres et indépendantes pour évaluer un modèle
• Les tests inclus dans une pull request servent parfois à valider un changement précis et peuvent donc imposer une implémentation particulière plutôt qu’un critère de résolution indépendant de l’implémentation

Orientation future des évaluations

• À mesure que les capacités des modèles progressent, les défauts des évaluations deviennent eux aussi plus faciles à détecter qu’auparavant
• Des modèles plus avancés peuvent inspecter plus profondément et plus systématiquement les prompts, les tests, les patchs, les traces d’exécution et les cas limites, révélant ainsi des problèmes de benchmark qui étaient auparavant difficiles ou coûteux à identifier à grande échelle
• OpenAI espère que la communauté élargie de l’évaluation développera de nouveaux benchmarks conçus explicitement par des développeurs logiciels expérimentés pour tester les capacités des modèles
• Une telle approche permettrait de conserver le haut niveau de difficulté et le réalisme recherchés, tout en rendant possible une meilleure supervision humaine tout au long du processus
• En raison des problèmes mis en évidence par cette analyse, OpenAI retire sa recommandation antérieure en faveur de l’adoption de SWE-Bench Pro
• Les évaluations doivent être difficiles à manipuler, faciles à vérifier et fournir un signal pertinent qui reflète réellement les capacités des modèles ou leur niveau d’alignement

[GN⁺]

Avis sur Hacker News

• Il faut un nouveau benchmark. Une bonne approche serait de mesurer ce qu’un modèle peut accomplir sur un ensemble de benchmarks avec 100 dollars de coûts d’API.
  Il faut mesurer à la fois l’efficacité et l’intelligence. Les petits modèles peuvent employer des stratégies comme utiliser l’ordinateur pour tester les résultats, rester plus longtemps sur un problème ou valider leurs sorties, tandis que les grands modèles peuvent manquer de budget pour leurs propres tests ; cela pourrait créer des différences tactiques intéressantes.
  • Il s’agit probablement du benchmark Intelligence vs Cost d’Artificial Analysis.
    https://artificialanalysis.ai/?cost=intelligence-vs-cost-per...
  • La question est de savoir sur les tarifs de quelle entreprise il faut se baser.
  • C’est la question de fond, et je trouve intéressant qu’il n’existe pas, sur le site d’OpenAI, de tableau de bord montrant proprement comment cet indicateur a évolué au fil des versions.
    Toby Ord a fait ce qu’il a pu avec des données publiques, mais les résultats ne semblent pas très bons.
    https://www.tobyord.com/writing/hourly-costs-for-ai-agents
• Terminal Bench 2 contient pas mal de résultats bidon pour diverses raisons. Une excellente équipe, dont Ryan/Alex, a récemment nettoyé beaucoup de soumissions suspectes, mais de nombreux labos publient des résultats obtenus en contournant ce que certaines tâches sont censées mesurer, en modifiant les limites de temps ou la configuration matérielle.
  À cela s’ajoutent aussi de la triche au niveau du harness d’exécution, du reward hacking par les modèles, etc. Ce qui continue de me déranger, même plusieurs mois plus tard, c’est la soumission officielle de gpt-5.5, en particulier cette tâche : https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0...
  D’après https://github.com/harbor-framework/terminal-bench-2/blob/ma..., les limites de temps de la tâche sont de 1200 secondes pour le verifier, 1200 secondes pour l’agent et 600 secondes pour le build de l’environnement, donc aucun agent ne devrait dépasser 3000 secondes. Or, dans le lien ci-dessus, 2 des 5 tentatives ont largement dépassé 3000 secondes, en prenant respectivement 75 et 80 minutes. Même si elles ont échoué, le fait qu’elles aient tourné aussi longtemps est suspect. C’est un exemple de la loi de Goodhart à l’œuvre.
  • Même si personne n’a « triché » selon une définition donnée, le benchmark fait déjà partie, quelque part, d’une immense descente de gradient structurelle. À un certain niveau, les modèles sont des machines à maximiser les scores de benchmarks ; les benchmarks eux-mêmes paraissent donc intrinsèquement assez peu utiles.
    Benchmarker des humains ne marche pas très bien non plus. Les compétences en code ne peuvent être évaluées correctement qu’en interagissant directement avec la personne. Si les modèles sont en pratique des simulateurs d’humains, il serait plutôt étrange de s’attendre à ce que les benchmarks restent utiles à mesure que la simulation devient plus précise. Au fond, c’est simplement une version plus longue de la « loi de Goodhart » mentionnée plus haut, et elle fonctionne vraiment comme une loi.
• Au fond, la conclusion n’est-elle pas que les tâches données aux développeurs logiciels sont souvent incomplètes, contradictoires ou pires encore, qu’elles soient confiées à des humains ou à des modèles ? Comme cet outil doit fonctionner précisément dans ce monde-là, je n’ai pas beaucoup de sympathie pour lui.
  • D’accord. Présenter des prompts insuffisants comme des échecs de l’outil n’est pas très convaincant. Même un stagiaire peut comprendre une demande ambiguë avec un peu d’aide, et sait quand il faut s’arrêter pour poser une question plutôt que continuer à foncer. Avant même la fin d’un stage, beaucoup gèrent assez indépendamment des tâches ambiguës.
    Dans ce cas, l’argument serait-il que les modèles de pointe ne sont même pas des ingénieurs juniors, mais des stagiaires de premier mois incapables de dépasser ce niveau ?
  • Dans un vrai travail, on pourrait regarder les cas de test qui échouent et corriger le code, ou, plus probablement, corriger les tests mal écrits. Si l’on autorisait simplement cette première étape aux LLM récents, ils feraient énormément mieux sur ce benchmark précis.
    Ce qui est intéressant, c’est de comprendre comment les LLM arrivent à dépasser 70 % sur ce type de benchmark, ou à répondre correctement à certaines questions très mal construites. Ont-ils appris implicitement le style des auteurs des tests ? Les solutions ont-elles fuité dans les données d’entraînement ?
    Cela dit, il est rassurant que même Fable plafonne autour de 72 % sur l’ensemble caché sur lequel OpenAI n’a pas lancé cette analyse. Il ne semble donc pas avoir appris directement le benchmark lui-même, sauf de manière très indirecte.
    Les petits modèles open source ne peuvent absolument pas apprendre ces travers particuliers, donc il est vraiment important de disposer d’une bonne méthode pour juger les modèles équitablement. Par ailleurs, OpenAI brouille un peu les pistes : seuls environ 20 % des problèmes sont cassés d’une manière défavorable à l’agent, tandis que 4 à 10 % le sont dans un sens favorable ; le plafond du benchmark est donc probablement plus proche de 80 à 85 %.
  • Le point plus subtil est l’écart entre la tâche et la vérification. Par exemple, avec un prompt ouvert ou insuffisamment spécifié, le vérificateur doit être capable de gérer toutes les solutions possibles.
    Des prompts de tâches très étroits sont donc faciles à vérifier, mais risquent d’être trop simples comme défi. À l’inverse, des prompts plus réalistes sont beaucoup plus difficiles à vérifier, et il devient aussi difficile de construire un vérificateur robuste et de l’exécuter à faible coût.
  • J’avais la même impression, surtout pour les exigences invisibles qui ne sont pas précisées au départ et n’apparaissent que dans les tests. Il faudrait retravailler la solution pour gérer des exigences dont personne ne nous a parlé ? C’est effectivement ce que je fais dans la vraie vie.
    Bien sûr, cela revient à tester autre chose que ce que le benchmark prétend mesurer, mais cela peut aussi, par hasard, tester quelque chose de plus proche de la réalité qu’un benchmark bien propre, ce qui a sa propre valeur.
    À condition toutefois que l’agent puisse voir les tests échoués et itérer. Sinon, c’est juste un problème. Et c’est encore pire quand les tests figent les détails d’implémentation d’une solution donnée et exigent une structure interne arbitraire. Dans la réalité, on ne rencontre pas ce genre de situation.
• D’après les chiffres ici, l’ensemble du benchmark semble compter moins de 800 tâches. C’est une taille que quelques ingénieurs peuvent passer en revue en une semaine, et c’est finalement ce qu’OpenAI a fait ici.

D’un côté, avoir effectivement fait ce travail mérite d’être salué. De l’autre, c’est littéralement le principe du « garbage in, garbage out ». C’est un peu embarrassant que les auteurs originaux ne l’aient pas réellement vérifié, et tout aussi embarrassant que personne en aval ne l’ait fait. À lire l’article, le LLM a bien trouvé des problèmes, mais il avait tendance à sous-estimer ceux repérés par un ingénieur logiciel expérimenté.

• Les benchmarks sont généralement assez médiocres quand on regarde sous le capot
  Pour donner le contexte, je fais évoluer par itérations un agent superviseur destiné à remplacer les diverses procédures fastidieuses nécessaires quand on utilise Codex/Claude Code, et je l’ai récemment fait tourner sur Terminal Bench 2.1.
  Au début, j’étais content. Le superviseur basé sur les spécifications faisait mieux que Codex de base sur plusieurs tâches. Mais en regardant de plus près, les tâches elles-mêmes avaient énormément de problèmes.
  Le cœur du problème, c’est que les instructions sont souvent ambiguës alors que les cas de test sont excessivement spécifiques. Par exemple, dans configure-git-webserver, des formulations comme « so that I can run » brouillent la frontière entre ce que l’agent doit fournir et ce qu’il doit retirer. Un agent qui réfléchit trop configure le serveur, puis estime que si l’utilisateur exécute la même commande, cela provoquera un conflit, et supprime donc exactement les fichiers que le vérificateur contrôle.
  Dans make-mips-interpreter, la phrase « I will check that you booted doom correctly » a conduit le superviseur à interpréter que l’utilisateur vérifierait le résultat du boot effectué par l’agent, et non que Doom démarrait de manière autonome ; il a donc laissé le fichier /tmp/frame.bmp généré. Le vérificateur se termine s’il existe déjà un /tmp/frame.bmp, il ne parvient donc pas à lancer Doom et ne vérifie pas non plus s’il est recréé pendant le démarrage[0].
  Dans mcmc-sampling-stan, l’agent superviseur arrivait souvent aux bonnes valeurs, mais produisait la sortie numérique propre au domaine en notation scientifique plutôt qu’en simple nombre décimal. Le vérificateur analysait alors le résultat incorrectement et échouait[1].
  Ce ne sont que quelques exemples de ces décalages ; c’est pourquoi je considère que Terminal Bench 2.1 est déjà saturé, et que les résultats de GPT-5.6 et de Mythos, respectivement 88,8 % et 88 %, sont presque à la limite supérieure atteignable. Le plus gros problème est que la plupart des benchmarks sont des exécutions ponctuelles et testent très peu le couple modèle+harnais sur de longues boucles itératives, qui sont pourtant la principale façon dont les vrais utilisateurs se servent des outils.
  [0] https://github.com/harbor-framework/terminal-bench-2-1/issue...
  [1] https://github.com/harbor-framework/terminal-bench-2-1/issue...

• Tout le monde ne savait-il pas dès le départ que SWE-Bench dans son ensemble était défectueux ? Même ses auteurs en ont reconnu les limites et sont passés depuis longtemps à l’étape suivante.

  • SWE-Bench Pro a été créé pour remplacer SWE-Bench et corriger ce type de problèmes.

• Je comprends pourquoi cela peut en faire un mauvais benchmark, mais si le problème est que des tests trop stricts imposent des détails d’implémentation précis qui ne sont pas explicités dans le prompt et invalident des soumissions fonctionnellement correctes, que des prompts insuffisants omettent des exigences imposées par des tests cachés mais impossibles à déduire raisonnablement, que des tests à faible couverture vérifient trop peu la fonctionnalité demandée et laissent passer des corrections incomplètes, ou que des prompts trompeurs orientent le modèle vers un mauvais comportement ou entrent en conflit avec les exigences des tests, alors, si l’objectif est de comparer de vrais ingénieurs logiciel et des modèles, c’est une situation assez réaliste.
  C’est un peu comme si, après avoir conçu un examen d’infirmier, on signalait certaines questions au motif qu’il aurait fallu demander au médecin responsable des informations supplémentaires absentes du dossier, ou que la famille du patient n’avait pas suffisamment expliqué les antécédents médicaux de la grand-mère âgée. On peut souhaiter un benchmark plus rigoureux, mais si OpenAI a promis ses modèles comme substituts à de vrais travailleurs, ce n’est pas une bonne image. Au contraire, on devrait vouloir tester ce genre de choses.

• Ça se lit comme : « nous avons fait tout le travail nécessaire pour corriger le benchmark, puis nous avons finalement décidé de l’abandonner ». Les données de base sont-elles à ce point précieuses qu’on ne puisse pas les patcher ? À la fin, l’article propose une approche un peu plus sélective pour générer des benchmarks, mais j’ai l’impression que corriger équitablement des tests désordonnés et incomplets issus de données réelles serait aussi une voie assez solide.

  • J’ai l’impression qu’il y a une autre raison de s’éloigner de SWE Bench Pro, mais qu’ils ne veulent pas dire laquelle. Au tout début de l’article, ils disent qu’« environ 30 % des tâches sont cassées », ce qui veut dire qu’environ 70 % ne le sont pas, et ça me paraît plutôt correct.
    Ça aurait aussi été utile de dire « voici la liste des instances cassées » ou « voici le sous-ensemble de SWE Bench Pro que nous utiliserons à l’avenir ». Ils laissent le parfait être l’ennemi du bien.
  • Signaler un problème, par exemple dire que des tests cachés supposent un détail d’implémentation étroit, est beaucoup plus facile que de créer des tests qui fonctionnent quel que soit le choix d’implémentation.
  • Si on corrige ça, ce ne serait plus vraiment SWE-Bench Pro, non ? Ce serait « SWE-Bench-Pro-Fixed-OpenAI ». Vu l’image d’indépendance d’un benchmark, il me semblerait préférable qu’un tiers le modifie et publie une version améliorée plutôt que l’équipe d’OpenAI ne le corrige elle-même.
    Cela dit, OpenAI a précisément fait ce genre de chose en publiant SWE-Bench Verified, donc je raconte peut-être n’importe quoi.

• Quel est aujourd’hui l’état de l’art des benchmarks SWE ?

  • Selon les objectifs et les besoins de chacun, je dirais DeepSWE[0] ou FrontierCode[1]. Le second m’intéresse davantage personnellement, car il est conçu pour évaluer fortement la fusionnabilité, c’est-à-dire si la sortie fournie est facile à relire et si un développeur sérieux peut facilement la comprendre et accepter de la merger.
    Depuis un bon moment, dans ma réflexion et mes évaluations personnelles, je considère que même si le plafond potentiel d’un modèle est plus élevé, sa valeur reste limitée si je ne me sens pas réellement capable d’approuver son code.
    [0] https://deepswe.datacurve.ai/
    [1] https://cognition.com/blog/frontier-code-1.1
  • Dans l’ensemble, j’ai trouvé que DeepSWE[0] correspondait assez bien à la réalité.
    [0]: https://deepswe.datacurve.ai/

• Il y a https://cognition.ai/blog/frontier-code. Pour être transparent, j’ai fait partie de cette équipe, mais nous y avons aussi traité les problèmes swebench pro/deepswe

  • FrontierBench

• Atteindre l’AGI devrait être plus que réussir tous les benchmarks, et devrait aussi prendre en compte les problèmes inconnus

  • À moins qu’il n’y ait, au sein du labo, quelque chose de très éloigné du produit actuel, l’AGI n’est pas vraiment un sujet de discussion et relève presque uniquement de l’exagération marketing
  • L’AGI est encore très loin. À moins qu’il n’existe un terme marketing LLM absurde que je ne connaisse pas et qu’on appelle « AGI ». L’intelligence artificielle à vocation générale est tellement différente des LLM ou de l’IA d’image qu’on ne peut même pas vraiment les comparer, si ce n’est qu’il s’agit dans tous les cas d’artefacts. L’AGI doit faire bien plus que prédire des tokens
  • Cela rejoint le compromis biais-variance (https://en.wikipedia.org/wiki/Bias%E2%80%93variance_tradeoff), courant lorsqu’on construit des modèles qui ne sont pas des LLM
    Les seules solutions consistent soit a) à rendre les LLM plus petits à performance comparable pour les empêcher de mémoriser ou d’optimiser les benchmarks, soit b) à créer un benchmark couvrant l’ensemble des données du monde réel, mais cette dernière option est irréalisable