Senior SWE-Bench : un benchmark open source pour évaluer des agents de niveau ingénieur senior

 (senior-swe-bench.snorkel.ai)
4 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Senior SWE-Bench est un benchmark conçu pour évaluer les agents de code non pas sur des tâches de niveau junior excessivement nettoyées, mais sur des développements de fonctionnalités, des corrections de bugs et des problèmes de performance plus proches de ce que gère réellement un ingénieur senior
  • Les tâches de fonctionnalité utilisent des consignes réalistes qui se lisent comme des messages en langage naturel, et la fiabilité de l’évaluation est renforcée par un agent de validation qui génère des tests comportementaux adaptés à la solution soumise
  • Les tâches de bug sont tirées de PR partant de rapports utilisateurs et exigeant une investigation en exécution comme le lancement du service, les logs, les données de profiling ou les étapes de reproduction
  • Le score combine la cohérence à l’exécution avec des indicateurs de qualité fondés sur les pratiques du codebase afin d’évaluer un tasteful solve, et des pratiques importantes absentes des consignes peuvent aussi être vérifiées
  • Même Claude Opus 4.8, meilleur modèle du leaderboard, n’atteint que 24.0% de pass@1 avec le réglage Mini-SWE-Agent max, ce qui signifie que même les meilleurs modèles échouent dans plus de 75% des cas à produire une solution au niveau senior, à la fois correcte et élégante

Des tâches conçues au plus près de vrais PR

  • Senior SWE-Bench est un benchmark visant à réduire l’écart entre l’usage réel des agents de code, souvent comme des ingénieurs seniors, et des évaluations encore construites comme des exercices pour juniors
  • Les tâches proviennent de PR de différents dépôts, depuis des bibliothèques jusqu’à des applications multi-services, et ciblent des PR créées par des ingénieurs ayant rédigé des centaines de commits dans chaque dépôt
  • Les principaux types de tâches se divisent en deux catégories
    • des PR de fonctionnalité couvrant plusieurs étapes et plusieurs stacks
    • des PR de bug ou de performance ayant nécessité une importante investigation en exécution
  • Le benchmark comprend 50 tâches publiques et 50 tâches privées
  • Exemples de dépôts inclus

Tâches de fonctionnalité : des consignes proches du langage naturel

  • Les tâches de fonctionnalité emploient des consignes réalistes qui se lisent comme des messages en langage naturel, plutôt que des exigences excessivement détaillées
  • Pour évaluer ce type de tâches de manière fiable, le benchmark introduit un agent de validation (validation agent)
    • il utilise des recettes conçues par des experts
    • il rédige des tests comportementaux adaptés à la solution soumise
  • Les consignes reflètent une communication naturelle avec un agent, et leur longueur médiane ne représente que 31% de celle de SWE-Bench Pro

Tâches de bug : du rapport utilisateur à l’investigation en exécution

  • Les tâches de bug reflètent des rapports utilisateurs complexes, et exigent davantage une investigation des causes et du processus de reproduction qu’une simple modification de code
  • Elles peuvent inclure des travaux tels que
    • démarrer le service
    • déboguer des problèmes subtils en exécution
    • consulter les logs
    • exploiter des données de profiling
    • suivre des étapes de reproduction
  • Elles proviennent de PR dont la résolution a exigé une investigation en exécution substantielle

Critères d’évaluation : mesurer à la fois la correction et le goût

  • Senior SWE-Bench combine des tests de cohérence à l’exécution avec plusieurs indicateurs de qualité pour noter un tasteful solve
  • Les indicateurs de qualité s’appuient sur les pratiques observées dans le codebase
  • Le vérificateur et l’agent de validation peuvent tester des pratiques importantes du codebase, même si elles ne figurent pas explicitement dans les consignes
  • Les conditions de solve du leaderboard incluent les éléments suivants
    • Verifiers pass
    • Validation pass
    • Rubric > 0.5
    • Bloat < 2×
    • Practice > 2/5
    • Rel. taste > 2/5

Leaderboard : même les meilleurs modèles ont un pass@1 faible

  • Le leaderboard présente les résultats selon le Tasteful solve rate (pass@1)
  • Principaux résultats
    • Claude Opus 4.8, Mini-SWE-Agent max : 24.0%
    • Claude Sonnet 5, Mini-SWE-Agent max : 19.4%
    • GPT-5.5, Mini-SWE-Agent xhigh : 16.0%
    • Claude Opus 4.7, Mini-SWE-Agent max : 14.1%
    • GPT-5.4, Mini-SWE-Agent xhigh : 14.0%
    • GLM-5.2, Mini-SWE-Agent max : 12.5%
    • Kimi K2.6, Mini-SWE-Agent default : 8.2%
    • Claude Sonnet 4.6, Mini-SWE-Agent high : 8.2%
    • Gemini 3.1 Pro, Mini-SWE-Agent high : 6.1%
    • Gemini 3.5 Flash, Mini-SWE-Agent medium : 3.0%
  • Même les modèles de pointe les plus puissants ne parviennent pas à accomplir plus de 75% des tâches demandant une solution de niveau senior, à la fois correcte et avec du goût

Portée des tâches et caractéristiques du benchmark

  • Les types de tâches sont indiqués comme feature, bug, perf et migrat
  • Les stacks incluent notamment Py Svc, Elixir, Go, SQL, TS Lib, Py Lib, Rust et TS FE
  • Les tâches de fonctionnalité peuvent couvrir plusieurs services et modifient en moyenne 11 fichiers par tâche
  • Elles sont conçues pour imposer de longs flux de travail, au point que même les agents les plus puissants ont besoin de centaines d’étapes
  • Le SLOC et le nombre de fichiers des solutions de référence sont mesurés de la même manière sur les trois benchmarks
  • La longueur des consignes exclut le boilerplate du harness
  • Le nombre de tokens et d’étapes des autres benchmarks repose sur les métriques auto-déclarées de chaque benchmark

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Hacker News

  • D’après ce que j’ai vu sur Twitter, dans un cours de machine learning de Tsinghua University, il y aurait eu un examen où l’on demandait aux étudiants de créer des quiz faisant échouer le plus grand nombre possible de LLM.
    Je me demande ce que donnerait un benchmark construit de cette façon, avec un score ELO. Les modèles s’affronteraient en se proposant mutuellement des questions, des bugs ou des implémentations incomplètes, que l’adversaire devrait résoudre, corriger ou compléter.

    • On pourrait appeler ça un réseau antagoniste génératif (GAN) :)
      https://en.wikipedia.org/wiki/Generative_adversarial_network
    • Le problème, c’est comment empêcher les stratégies dégénérées. Par exemple, donner un hash SHA256 et demander de retrouver l’entrée d’origine permettrait de fabriquer trop facilement un problème impossible.
      Dans un cours, on pourrait imposer qu’au moins un LLM puisse donner la réponse, mais je ne sais pas comment gérer ça dans un duel en un contre un.
    • Il me semble que ce n’était pas Tsinghua, mais Fudan.

  • Je me demande comment ce benchmark pourra rester pertinent dans le temps.
    Si le benchmark consiste à implémenter des fonctionnalités dans des projets open source, un LLM pourrait avoir ces changements dans ses données d’entraînement et fournir la réponse telle quelle, ou légèrement modifiée.
    À l’inverse, si l’on n’inclut dans le benchmark que des changements de code postérieurs à la date de coupure des connaissances du modèle, les problèmes aux instants T et T+1 ne seront plus les mêmes, ce qui nuit à la comparabilité dans le temps.

  • Avec Staff SWE Bench, le LLM commencerait probablement par douter que cela doive être fait, remettrait en cause tout le projet, refuserait de fusionner le code mais accepterait volontiers de le supprimer.

    • Ça ressemble à une blague, mais en réalité, le refus est au cœur du travail. Il ne s’agit pas simplement de dire « non, va-t’en », mais de prendre du recul, d’exiger une vision d’ensemble, et de vérifier si toute l’organisation a réellement besoin de ce projet sur le long terme et peut l’assumer. C’est presque une étape minimale avant de commencer.
      Les LLM pourraient sans doute faire cela suffisamment bien, peut-être même mieux que nous, mais il faudrait les entraîner spécifiquement pour ça. Je ne vois toutefois pas très bien où trouver ce type de données d’entraînement.
    • La version Principal serait similaire, mais elle dirait aussi que la seule approche acceptable est celle qu’on utilisait dans l’entreprise précédente.

  • Cela explique pourquoi j’ai toujours eu l’impression qu’Opus 4.8 était très loin devant GPT 5.5. Il est vraiment excellent pour recevoir des exigences incomplètes et combler les blancs d’une manière raisonnable pour le projet.

    • Je ne comprends déjà pas pourquoi on fournirait des exigences incomplètes. Les deux modèles sont capables d’examiner les hypothèses et les cas limites, et de poser des questions de clarification, mais ils semblent ne le faire que lorsqu’on le leur demande explicitement, par exemple avec des techniques comme le « brainstorming ».
      À mon avis, ces deux méthodes d’évaluation n’incitent pas suffisamment le modèle à remettre en question toutes les hypothèses et à poser des questions. Peut-être parce que cela pourrait agacer l’utilisateur, mais cette étape me paraît presque indispensable.
      Toute la famille GPT-5 était très méticuleuse, ce qui s’est révélé utile pour la revue de code et les mathématiques. C’est important dans mon travail, mais cela semble nuire au code « esthétique » : par exemple, le modèle essaie de se protéger contre tous les cas limites, même très improbables.
      Il semble aussi y avoir un compromis entre flexibilité et respect des instructions. D’après mon expérience, Opus ignore parfois les consignes, mais comble mieux les blancs, tandis que GPT-5.5 suit mieux les instructions, au prix d’une certaine rigidité.
    • Le meilleur benchmark, c’est celui que l’on construit soi-même.
      D’après mon expérience, Opus n’était pas massivement en tête ni clairement meilleur. Quoi qu’il en soit, GPT 5.5 existe en Instant, Medium, High, Extra High et Pro ; le tableau semble le comparer à Extra High, donc je me demande s’il ne faudrait pas plutôt le comparer à Pro.
    • Je ne sais pas si je vis dans une bulle étrange, mais pour moi, GPT 5.5 est nettement meilleur qu’Opus 4.8. Au point que je me demande comment les autres l’évaluent et sur quels types de tâches.
      Il y a certains cas où Opus est meilleur, comme le développement frontend et le design, mais pour le reste, 5.5 l’écrase tout simplement.
    • C’est peut-être mieux pour les vibe coders qui sous-spécifient toujours. Mais la question est de savoir à partir de quel moment le modèle décide que « les exigences ne sont pas assez explicites » et finit par implémenter quelque chose qui dépasse en réalité une spécification déjà suffisamment claire.
    • J’ai fait le même constat. Opus 4.8 était beaucoup plus mature, et posait des questions ou s’opposait quand une demande lui semblait douteuse. GPT 5.5, lui, acquiesçait volontiers et faisait ce qu’on lui demandait, mais il fallait souvent le relancer plusieurs fois.
      4.8 nécessite aussi parfois plus d’un prompt, mais la qualité de sortie est bien meilleure et il apporte davantage d’insights.
      Cela dit, Fable 5 est encore autre chose.

  • Le meilleur taux de résolution actuel est de 24 % avec Opus 4.8 ; quel score un humain compétent devrait-il obtenir ?

    • Probablement plus que ça, puisque l’humain pourrait aussi utiliser ce qu’utilise le meilleur modèle.
      À l’inverse, je me demande quel score le modèle obtiendrait s’il pouvait commander librement à un humain.
    • Si l’on part du principe que tous ces problèmes ont déjà été résolus, j’imagine que ce serait 100 %. Bien sûr, ce n’est sans doute pas une seule et même personne qui les a tous résolus, mais le modèle doit être bon sur de nombreuses bases de code, alors qu’un humain peut se spécialiser et apprendre un produit donné.
      Le comparer à une personne habituée à travailler sur le produit me semble juste.
      Je suis plus curieux de voir ce que donnera Fable.

  • La valeur d’un rôle senior réside dans l’application de solutions et de stratégies connues à des problèmes nouveaux. Je ne sais pas si un benchmark qui ne change jamais pourra rester longtemps un nouveau défi.
    Un bon benchmark devrait commencer par utiliser tout TRIZ pour créer un énorme ensemble de problèmes, puis vérifier si l’IA infère la solution optimale.

  • C’est une bonne chose que Snorkel publie un nouveau benchmark public. Ils font un travail assez sophistiqué de ce côté-là.

  • Il est intéressant de voir que Sonnet 5 se rapproche pas mal d’Opus 4.8.

  • Si cette approche fonctionne, cela ne voudrait-il pas dire qu’on peut aussi automatiser les entretiens techniques ?

  • L’approche consistant à faire exercer un jugement subjectif à un LLM avec une formule du genre « You are a senior SWE-Bench reviewer, make no mistakes. » me semble fondamentalement défectueuse.
    Je ne sais pas quelle serait une meilleure méthode tout en restant faisable.

    • Plus important encore, cela peut réellement nuire au travail. Si le LLM fait une erreur, il peut être incité à la minimiser et passer à autre chose plutôt qu’à l’admettre et la corriger.
    • Cette méthode revient en fait à injecter du contexte sur la manière dont le LLM doit se comporter. « senior reviewer » correspond au style de réponse souhaité, et « SWE-Bench » au contexte et au domaine dans lesquels le LLM doit opérer.
      C’est une approche courante dans les prompts système, et elle cadre la réponse.
      Par exemple, « un pirate qui écrit un chant de marin sur la programmation », « un journaliste qui écrit un article de physique », ou « un ingénieur logiciel senior qui connaît parfaitement PostgreSQL » produiront chacun des réponses différentes.
      Dans le premier cas, on pourrait obtenir, sur un ton à la Wellerman, quelque chose comme « There once was a program that was set to C ... ».
      En revanche, la partie « make no mistakes » me paraît suspecte. Il serait intéressant de comparer les résultats avec et sans cette formule, et de tester d’autres moyens d’obtenir le même comportement souhaité.
    • L’injonction « make no mistakes » a l’air assez ridicule. Elle a déjà été beaucoup moquée sur YouTube, mais on peut facilement imaginer un mécanisme par lequel elle fonctionnerait, par exemple si elle est simplement interprétée comme « relis ton travail ».
      Bien sûr, il ne semble pas y avoir d’endroit qui effectue publiquement ce type de comparaison de mesures pour arriver à une conclusion raisonnable.