Pourquoi SWE-bench Verified ne mesure plus les capacités de codage de pointe

 (openai.com)
4 points par GN⁺ 3 일 전 | 1 commentaires | Partager sur WhatsApp
  • SWE-bench Verified, qui faisait figure d’indicateur de référence pour les tâches autonomes d’ingénierie logicielle, est désormais beaucoup moins pertinent pour mesurer les capacités des modèles de pointe
  • Alors que la progression récente des meilleures performances est restée limitée de 74,9 % à 80,9 %, il est devenu difficile de distinguer ce qui relève des limites du modèle de ce qui relève des défauts du jeu de données
  • Sur les 138 problèmes audités, des défauts majeurs dans la conception des tests ou dans l’énoncé ont été constatés dans 59,4 % des cas, et des tests trop restrictifs comme trop larges éliminent aussi des solutions pourtant fonctionnellement correctes
  • Comme l’évaluation repose sur des données et des bases de code publiques, il est difficile d’éviter la contamination des données d’entraînement, et certains modèles reproduisent presque à l’identique le gold patch à partir de la seule description de la tâche ou de son ID
  • En conséquence, le reporting des scores SWE-bench Verified a été arrêté, et l’évaluation se déplace vers SWE-bench Pro, moins affecté par la contamination, ainsi que vers des benchmarks privés

Pourquoi ce benchmark ne mesure plus correctement

  • SWE-bench Verified a été largement utilisé comme indicateur standard pour mesurer les performances des modèles sur des tâches autonomes d’ingénierie logicielle, mais il est désormais nettement moins adapté pour évaluer les capacités actuelles des modèles de pointe
  • Comme la progression des meilleures performances s’est limitée de 74,9 % à 80,9 % au cours des six derniers mois, il est devenu difficile de savoir si les échecs restants viennent des limites du modèle ou des défauts du jeu de données
  • Une nouvelle analyse montre que les tests défectueux et la contamination des données d’entraînement sont les principaux problèmes, au point que le score reflète davantage l’exposition au benchmark que la véritable capacité de codage
  • C’est pourquoi OpenAI a cessé de publier les scores SWE-bench Verified et recommande aux autres entreprises développant des modèles d’en faire autant
  • Comme alternative, l’usage de SWE-bench Pro, moins contaminé, est recommandé, tandis que de nouveaux indicateurs d’évaluation non contaminés sont en cours de création

Contexte

  • Le SWE-bench original a été publié en 2023 et associe des issues GitHub résolues à leurs PR correspondantes dans 12 dépôts Python open source
  • Pour chaque problème, il faut générer une modification de code à partir de la base de code avant correction et du texte de l’issue, puis réussir tous les tests après application du patch
    • Les tests doivent échouer avant la correction et réussir après une correction valide
    • Des tests de régression sont aussi inclus pour vérifier qu’aucune fonctionnalité existante n’a été cassée
  • L’évaluation d’origine présentait des problèmes comme des tests trop spécifiques rejetant même des correctifs valides, des spécifications insuffisantes laissant place à plusieurs interprétations, ou encore des tests échouant selon l’environnement
  • Pour réduire ces problèmes, SWE-bench Verified a été créé en 2024, avec un ensemble de 500 problèmes sélectionnés par revue experte parmi 1 699 cas
    • Chaque problème a été examiné indépendamment par 3 experts

Défauts de conception des tests

  • OpenAI a audité 138 problèmes qu’o3 n’a pas réussi à résoudre de manière cohérente même après 64 exécutions indépendantes, chaque cas étant examiné séparément par au moins 6 ingénieurs logiciel expérimentés
  • Résultat : dans 59,4 % des 138 cas, les tests ou l’énoncé comportaient des défauts majeurs, rendant le problème très difficile voire impossible à résoudre, même pour un excellent modèle ou un humain
  • 35,5 % des tâches auditées contenaient des tests restrictifs imposant des détails d’implémentation précis
    • Plusieurs solutions pourtant correctes sur le plan fonctionnel peuvent ainsi être invalidées
  • 18,8 % des tâches auditées contenaient des tests trop larges exigeant des fonctionnalités supplémentaires absentes de la description du problème
  • Les 5,1 % restants relevaient d’autres problèmes ne rentrant pas clairement dans ces deux catégories

  • Cas de tests restrictifs

    • Dans pylint-dev__pylint-4551, le test de PR importe directement la fonction get_annotation, alors que ce nom n’apparaît pas dans la spécification du problème
    • Ainsi, même une solution fonctionnellement correcte peut échouer aux tests avec une erreur d’import si elle n’implémente pas ce nom de fonction précis

  • Cas de tests trop larges

    • sympy__sympy-18199 provient en réalité d’une PR corrigeant simultanément trois issues : #17373, #17377 et #18212
    • Mais la description de la tâche dans SWE-bench Verified ne couvre que #18212, si bien qu’une implémentation fidèle à l’énoncé peut tout de même échouer sur des tests vérifiant les deux autres issues

Problème de contamination

  • SWE-bench Verified, ainsi que les bases de code et notes de version des dépôts concernés, sont publics, largement utilisés et souvent discutés, ce qui rend l’évitement de la contamination des données très difficile
  • OpenAI a aussi observé des signes de contamination dans ses propres modèles, notamment des cas où GPT‑5.2 a résolu 31 tâches jugées presque impossibles à résoudre sans contamination
  • Dans django__django-14725, les tests exigent un paramètre edit_only absent de l’énoncé, et GPT‑5.2 a même identifié correctement dans son raisonnement que ce paramètre a été introduit dans Django 4.1
  • Pour évaluer la gravité de la contamination, OpenAI a mis en place un environnement de test red team automatisé
    • Pour chaque problème SWE-bench Verified, GPT‑5 a enquêté sur une éventuelle contamination de GPT‑5.2‑Chat, Claude Opus 4.5 et Gemini 3 Flash Preview
    • GPT‑5 recevait l’ID de la tâche, sa description, le gold patch et les tests de PR, avec la possibilité de modifier ses prompts et stratégies d’induction pendant 15 tours au total
    • Après chaque tour, un modèle d’évaluation classait la gravité de la contamination de nulle à forte selon la quantité de nouvelles informations spécifiques à la tâche révélées
    • Les cas de forte contamination étaient ensuite vérifiés par un modèle d’évaluation supplémentaire pour mesurer l’ampleur de la fuite d’information, puis examinés manuellement

Cas graves de contamination selon les modèles

  • GPT‑5.2

    • Dans django__django-11451, il a produit le gold patch exact à partir d’un simple court extrait de description de tâche
    • Il a reproduit la condition de retour anticipé lorsque username is None or password is None dans ModelBackend.authenticate(), ainsi que le chemin du fichier et le nom de la méthode

  • Claude Opus 4.5

    • Dans astropy__astropy-13236, il a cité mot pour mot le chemin du fichier à corriger astropy/table/table.py, la méthode _convert_data_to_col, et même les commentaires inline du diff
    • Il a aussi restitué exactement les 4 lignes de code qui convertissaient automatiquement un ndarray structuré en NdarrayMixin

  • Gemini 3 Flash

    • Dans django__django-11099, alors qu’il ne disposait presque d’aucune information supplémentaire au-delà de l’ID de la tâche, il a affiché mot pour mot la description de la tâche et l’intégralité du gold patch
    • Il a reproduit jusqu’au contenu du changement de regex de validation des noms d’utilisateur, de r'^[\\w.@+-]+$' à r'^[\\w.@+-]+\\Z', ainsi que le diff ligne par ligne

Enseignements clés

  • Les benchmarks extraits de ressources publiquement accessibles comportent un risque de contamination, et l’exposition aux données d’entraînement peut gonfler les scores de manière difficile à détecter
  • Lorsqu’un benchmark est construit à partir de données publiques collectées, les développeurs de modèles doivent effectuer des tests supplémentaires pour vérifier l’existence d’une contamination
  • Comme les benchmarks et leurs réponses publiés peuvent finir eux aussi dans les données d’entraînement, il faut accorder une attention particulière à la fois au mode de diffusion du jeu de données et au filtrage des données d’entraînement
    • Des mécanismes de contrôle de diffusion comme la protection par mot de passe sont mentionnés
    • Des méthodes de filtrage comme le respect strict des chaînes canari sont également évoquées
  • Le scoring automatique doit être assez robuste pour ne pas être perturbé par des différences d’implémentation sans importance, tout en restant suffisamment solide pour empêcher les contournements, ce qui est extrêmement difficile à concilier
  • Détecter ce type de défauts a nécessité plusieurs vagues de labellisation manuelle à grande échelle

Orientation future de l’évaluation

  • Ces derniers mois, OpenAI a décidé de publier les résultats sur les données d’évaluation publiques de SWE-bench Pro, et recommande aux autres développeurs de modèles d’adopter la même démarche
  • SWE-bench Pro n’est pas parfait non plus, mais empiriquement il semble moins affecté par la contamination que SWE-bench Verified
    • Quelques cas de contamination ont été détectés dans le pipeline interne de vérification
    • Ils étaient toutefois beaucoup plus rares et moins graves que pour SWE-bench Verified
    • Aucun modèle n’a réussi à générer un gold patch totalement identique mot pour mot
  • À l’avenir, l’objectif est de continuer à investir dans des benchmarks originaux rédigés en privé
  • Dans GDPVal, des experts métier rédigent les tâches en privé et des évaluateurs formés notent les solutions de façon globale
  • Cette approche consomme davantage de ressources, mais elle devient de plus en plus indispensable pour mesurer de véritables gains de capacité

À lire aussi

1 commentaires

 
GN⁺ 3 일 전
Commentaires sur Hacker News

  • En tant que co-créateur de SWE-bench, pour résumer : SWE-bench Verified est désormais presque saturé à 93,9 %, et Anthropic mérite d’être félicité
    Cela dit, les équipes qui n’ont pas encore atteint ce niveau ont encore de la marge pour progresser
    SWE-bench Multilingual et SWE-bench Multimodal ne sont pas encore saturés, et la version Multimodal devrait être publiée en open source d’ici le mois prochain
    Tous les benchmarks finissent par saturer, donc nous continuons à créer les benchmarks de l’étape suivante, et il en existe déjà comme https://codeclash.ai/ ou https://algotune.io/

    • Dire que c’est saturé ne veut pas dire qu’il ne faut plus utiliser SWE-bench Verified
      Le point essentiel, c’est qu’un nombre important de tests sont inexacts, si bien que des solutions réellement correctes sont malgré tout notées comme fausses
      Il est aussi très probable que les modèles de pointe aient déjà lu et mémorisé les PR à l’origine des problèmes
      Certains problèmes sont même pratiquement impossibles à résoudre sans mémoriser la solution ; par exemple, il faut parfois exposer exactement le nom d’une fonction helper précise qui n’apparaît même pas dans l’énoncé pour réussir les tests
      Si les modèles de pointe réussissent ce genre de cas, c’est apparemment parce qu’ils se souviennent qu’il faut ce nom précis
      Si la prochaine génération de benchmarks ne corrige pas cela, le même problème subsistera, qu’il y ait saturation ou non
    • Si l’article est exact, ils ont audité le sous-ensemble de 27,6 %, et parmi celui-ci 59,4 % avaient des tests défectueux qui rejetaient des soumissions fonctionnellement correctes
      Si on fait le calcul, 0.191 * 0.594 > 1 - 0.936, donc on peut se demander si le sous-ensemble audité n’était pas représentatif, ou si Anthropic a obtenu ce score élevé d’une manière un peu suspecte
    • SPECint et SPECfp ont traversé exactement le même cycle
      On crée un benchmark, il sature, on le retire, on le remplace, puis on recommence
      Au final, ce treadmill lui-même finit par ressembler à un produit, et même si je n’ai pas la solution, ça donne une impression de répétition historique
    • En attendant, il semble aussi y avoir https://SWE-rebench.com comme alternative
      Si j’ai bien compris, cela ressemble à une variation intéressante autour de SWE-bench
    • SWE-bench lui-même me paraît excellent
      Le fait qu’il soit aujourd’hui soumis à une vérification aussi intense me semble être l’effet en retour de son adoption large et de son succès

  • Il semble beaucoup trop évident que tout nouveau benchmark finit rapidement dans les données d’entraînement et devient presque immédiatement obsolète
    Même uniquement pour le marketing, il y aura toujours une incitation à optimiser pour un benchmark donné, et même avec une date de cutoff d’entraînement, on ne parle souvent que de 3 à 6 mois d’écart avec la date de publication
    La vraie difficulté des benchmarks de code consiste donc à créer des problèmes entièrement nouveaux, qu’on puisse garantir absents des données d’entraînement, sans reprendre des benchmarks existants
    Dans cette optique, un benchmark créé avant la sortie d’un modèle ne semble pas vraiment représentatif des performances de ce modèle, et l’incitation financière à injecter des données pour promouvoir de petites améliorations est trop forte
    Franchement, il vaudrait mieux retirer complètement les benchmarks des supports marketing, laisser les modèles parler d’eux-mêmes et laisser la communauté juger, mais les entreprises avec de l’argent en jeu ne feront probablement jamais cela

    • C’est pour ça que j’ai créé Zork bench
      Le jeu d’aventure textuel Zork est présent dans les données d’entraînement des LLM et il est déterministe, donc en théorie ils devraient pouvoir y jouer facilement et le terminer
      En pratique, ce n’est pas le cas, et c’est précisément ce que Zork bench cherche à comprendre
      https://github.com/mnky9800n/zork-bench
    • Quand on dit qu’il faut laisser la communauté juger, il reste déjà à savoir de quelle communauté on parle
      On y trouve aussi bien des experts qui utilisent les LLM depuis plus de 10 ans que des vibe coders qui n’ont jamais écrit de code, et en ligne certains voient GPT 5.5 comme un sauveur tandis que d’autres le jugent plus bête que 5.4
      Moi non plus, je n’ai pas le temps de construire un benchmark privé pour chaque nouveau modèle, donc je finis par m’appuyer sur des benchmarks private ou semi-private pour estimer le niveau d’amélioration, puis je m’abonne et je teste par moi-même
      C’est au moins un peu plus fiable que l’ambiance produite par des utilisateurs aléatoires ou des bots sur Reddit
    • Une manière simple de redonner du sens aux benchmarks de code serait de commencer par remplir le contexte du modèle avec 200 000 tokens de bruit ou de contenu hors sujet
      Ou alors d’exécuter les tests de façon séquentielle dans le même contexte afin de voir combien de temps le modèle tient avant de perdre le fil du contexte
      Les benchmarks actuels reposent toujours sur des problèmes greenfield, alors qu’en pratique on veut des modèles capables de gérer un contexte pourri
    • J’ai toujours l’impression qu’on regarde un niveau en dessous de l’essentiel
      Le goulet d’étranglement actuel, ce n’est pas la capacité en soi, mais ce que le modèle peut voir en production
      La structure du contexte, la qualité du retrieval, le tool use et la capacité à composer l’état sur plusieurs tours sont importants, et SWE-bench n’inclut presque rien de tout cela
      SWE-bench ressemble à une série de problèmes one-shot, mais le travail de code de pointe ne ressemble déjà plus à cela
      Même si l’on créait un benchmark parfait, totalement exempt de contamination des données, il mesurerait probablement encore le mauvais axe dans la plupart des cas
      Sur des problèmes isolés, on a déjà atteint le niveau d’un doctorant humain, et l’effet de levier se joue désormais dans la manière dont le modèle fonctionne à l’intérieur d’un système plus large
      Mais cela relève presque du goût ou de la préférence, donc c’est extrêmement difficile à mesurer objectivement
    • La communauté en ligne elle-même est beaucoup trop astroturfée
      Anthropic paie des influenceurs pour pousser Claude Code et semble aussi faire tourner énormément de bots, ce qui rend difficile toute confiance dans le consensus en ligne
      Même en supposant que tout le monde agisse de bonne foi, les différences de domaine peuvent déjà produire des écarts de perception énormes
      Par exemple, l’IA peut être bien meilleure en frontend ou sur des bibliothèques très répandues
      Au final, il faut tester les modèles soi-même, mais recommencer cela pour chaque nouveau modèle est épuisant et de toute façon pas suffisamment exhaustif

  • Les benchmarks/evals ont toujours été difficiles, et ils le deviennent encore plus quand les incitations à les manipuler existent à l’échelle de toute l’industrie
    ELT-Bench en est un exemple récent : c’était le premier benchmark sérieux pour les charges de travail de data engineering, sorti il y a environ un an
    Mais il y a quelques jours, un article de suivi incluant l’un des auteurs originaux a audité le benchmark lui-même et a conclu que ses résultats étaient biaisés à cause de problèmes structurels
    L’article est ici : https://arxiv.org/abs/2603.29399
    En réalité, ce n’est même pas nouveau, et les secteurs précédents ont déjà vécu tout cela à plus petite échelle
    Il existe aussi un article sur la ressemblance frappante entre la situation actuelle et les benchmarketing wars des bases de données
    https://www.typedef.ai/blog/from-benchmarketing-to-benchmaxx...

    • Au final, le plus difficile reste de séparer le benchmark des données d’entraînement
      On observe des problèmes similaires sur BrowseComp plus et d’autres jeux de données de deep research ; ce n’est pas forcément parce que les frontier labs cherchent à tricher, mais simplement parce qu’ils entraînent leurs modèles sur l’ensemble du web
      Il faut donc produire de nouveaux jeux de données en continu, de façon permanente
    • Les benchmarks de bases de données relèvent de la même famille
      En construisant moi-même un classifier, j’ai constaté que, sur certaines tâches, le modèle était systématiquement meilleur que les humains, au point qu’il devenait impossible de mesurer la précision elle-même
      À ce moment-là, ce classifier devient de fait le benchmark state-of-the-art, sans autre point de comparaison que lui-même
      Si cela arrive déjà sur des tâches complexes moins logiques et demandant moins de raisonnement prolongé que le code, il se peut qu’un jour les benchmarks calibrés et indépendants de l’objet mesuré disparaissent complètement
    • Je me demande donc si le fait de créer un nouveau benchmark chaque mois pourrait résoudre ce problème

  • Au final, on récolte surtout les benchmarks qu’on mérite
    Une grande partie des PR validées par SWE-bench ne seraient probablement pas fusionnées en pratique : https://news.ycombinator.com/item?id=47341645
    Et les scores SWE-bench des meilleurs modèles ont peut-être été faussés par des fuites d’historique git : https://news.ycombinator.com/item?id=45214670

  • Je me demande même s’il ne vaudrait pas mieux demander directement aux meilleurs modèles de créer eux-mêmes les benchmarks
    Blague à part, ce que j’attends vraiment, c’est ARC-AGI-3, et après avoir tenté une simulation humaine j’ai eu l’impression que la part de raisonnement y était vraiment très forte
    Le leaderboard est ici : https://arcprize.org/leaderboard
    À l’heure actuelle, la plupart des meilleurs modèles ne dépassent même pas 5 %

    • Ici, on accorde beaucoup d’importance à la minimisation du nombre de coups, et aucun harness n’est autorisé, donc le niveau d’exigence est extrêmement élevé
      Même Claude Opus 4.6, actuellement le meilleur modèle vérifié, n’est qu’à environ 0,45 %
      Cela dit, c’est tellement récent que j’espère de vrais progrès avec la prochaine génération de modèles
    • L’idée de faire créer les benchmarks par les meilleurs modèles n’est pas complètement absurde
      Il suffirait de faire interviewer le nouveau modèle par le modèle précédent, puis de demander aux deux — ou à un troisième modèle arbitre — de décider lequel est le plus intelligent, et de répéter cela 100 fois en changeant la seed
      On pourrait prendre comme score le taux auquel les deux côtés reconnaissent la victoire du nouveau modèle
    • Des benchmarks à forte composante de raisonnement semblent aller dans une meilleure direction
      C’est probablement le type le plus difficile à manipuler
    • On peut même se demander si une IA est capable d’écrire des problèmes qu’aucune IA ne sait résoudre
      Dit comme ça, c’est plutôt amusant

  • De meilleurs benchmarks devraient reposer sur une notation objective, une largeur multidisciplinaire et la scalabilité, tout en évitant les formats à réponse unique
    Ce que nous avons conçu chez https://gertlabs.com va dans ce sens, et reste globalement lié à la résolution de problèmes par le code

    • Ce benchmark me paraît plus fidèle que les autres classements que j’ai vus jusqu’ici
      D’après mon ressenti, gpt 5.4/5.5 est techniquement presque irréprochable, et quand il y a un problème c’est généralement parce que l’entrée est ambiguë
      Il gère aussi plutôt bien les problèmes rencontrés pendant un correctif ou une implémentation, et il a tendance à mener la tâche à son terme sans laisser de trous
      À l’inverse, je pense qu’Opus est quelque peu surévalué sur le plan des capacités techniques
      Il a un meilleur instinct de designer/développeur pour produire une belle UX, mais pour la vérification du travail je finis toujours par confier cela à gpt 5.5
      Le résultat le plus surprenant a été celui de Xiao-Mi ; je ne l’ai pas encore utilisé, mais cela me donne envie d’essayer
      Bravo à l’équipe pour avoir créé un repère utile au milieu de cette course folle de l’IA
    • Il est intéressant de voir que la famille Claude Code reste nettement au-dessus des autres modèles en C++ et en Java, alors que GPT 5.5 ressort davantage en Python, JS, etc.
      Cela semble révéler soit un biais dans les jeux de données d’entraînement, soit une différence de focus go-to-market, peut-être liée au fait qu’Anthropic cible davantage les clients enterprise qu’OpenAI
      Cela correspond aussi à mon ressenti en utilisant Opus sur du C++
      En revanche, les résultats en C# sont absents ; @gertlabs, y a-t-il une ETA ?
    • Dans ce benchmark, Deepseek V4 pro semble moins performant que Deepseek V4 flash, ce qui est un résultat assez intrigant
      J’aimerais bien avoir un commentaire sur les raisons possibles

  • Que ce soit de manière organique ou non, cela devait finir par arriver
    Il est très facile de glisser vers une logique où il suffit d’obtenir de bons scores de benchmark, sans que cela se généralise forcément hors de ce cadre
    Cela me fait penser au concept de Graduate student descent
    https://sciencedryad.wordpress.com/2014/01/25/grad-student-d...

  • Avec le recul, SWE-bench n’était peut-être pas si extraordinaire que ça au départ
    Pendant toute l’année 2025, la proportion de bon code produite par les modèles ne s’est en réalité presque pas améliorée ; il serait plus juste de dire qu’ils se sont surtout améliorés pour passer les tests automatisés
    https://entropicthoughts.com/no-swe-bench-improvement

    • J’ai du mal à accepter l’idée qu’il n’y aurait eu aucune amélioration de la qualité du code
      En janvier 2025, les modèles dominants étaient Claude 3.5 Sonnet, Gemini 1.5 Pro et GPT-4o côté OpenAI ; pour avoir utilisé ceux-là ainsi que les modèles de pointe actuels, il est clair pour moi que les modèles actuels ont franchi un cap important
    • Cette interprétation a de bonnes chances d’être correcte
      La qualité des modèles semble stagner, et trouver un nouveau vecteur d’amélioration n’a rien d’évident
      Même l’élargissement de la largeur des modèles, qui a jusqu’ici porté le rythme des progrès, semble approcher de ses limites ; je me demande donc quelles en seront les implications
      À long terme, ce que l’on peut résoudre uniquement par le tooling a aussi ses limites
    • Malgré tout, la hausse du taux de réussite aux tests automatisés est une source énorme de productivité en code
      C’est aussi l’une des raisons pour lesquelles Anthropic est valorisée à plusieurs dizaines de milliards de dollars
      Si SWE-bench a été utile dans le domaine du code, c’est notamment parce que l’ingénierie logicielle dispose d’une tradition et d’une infrastructure très solides pour créer et exploiter des tests automatisés
    • C’est peut-être aussi pour cela que les modèles tarifaires des entreprises sont en ce moment plus restrictifs et plus coûteux

  • Ce que dit l’article, c’est qu’en auditant le sous-ensemble de 27,6 % des cas que le modèle échouait souvent à résoudre, ils ont constaté qu’au moins 59,4 % d’entre eux comportaient des tests défectueux rejetant des soumissions pourtant fonctionnellement correctes
    Si c’est bien vrai, cela donne l’impression qu’une grosse partie des problèmes et des réponses attendues était fausse depuis le début, ce qui soulève de vraies questions sur la validité de la mesure
    Quand on lit la description du processus de création du benchmark, le niveau d’exigence paraît pourtant élevé, donc j’ai du mal à comprendre comment une procédure pareille a pu aboutir à une qualité de données aussi médiocre
    C’est louable d’avoir mis le problème en lumière soi-même, mais cela laisse encore beaucoup de questions ouvertes

    • Cela ne veut pas dire qu’un quart de l’ensemble était faux, mais plutôt que, dans le sous-ensemble de 27,6 %, 59,4 % comportaient des tests défectueux
      Et pour des raisons pratiques, un benchmark n’est par nature représentatif ni de votre cas d’usage, ni de tous les cas d’usage
      Il n’est valable que pour mesurer ce qu’il contient, ni plus ni moins
      C’est d’ailleurs pour cela que je ne comprends pas l’obsession de l’écosystème pour les benchmarks publics
      Par exemple, si Qwen 3.5 est 50 % meilleur que Qwen 2.5 sur le Benchmark X, cela ne garantit presque en rien qu’il sera 50 % meilleur sur mes tâches réelles
      Je construis depuis longtemps mes benchmarks privés en continu, en ajustant les prompts à partir des cas d’échec rencontrés en usage réel
      Et même lorsqu’un nouveau modèle sort, je ne vois généralement que 2 à 3 % de variation sur mes benchmarks, alors que les benchmarks publics mettent en avant des hausses de 30 à 40 %, ce qui rend difficile de croire à l’absence de contamination par les données d’entraînement
    • ImageNet est lui aussi l’un des jeux de données les plus célèbres au monde, mais un nombre non négligeable d’images y sont mal étiquetées
      Dans les cas extrêmes, on peut même atteindre une zone où, pour obtenir un meilleur score, il faut en fait se caler sur la mauvaise réponse
      Au fond, la réponse est que le machine learning est un domaine qui finit souvent par fonctionner malgré tout, si bien qu’il peut aller étonnamment loin même avec des défauts
      C’est aussi pour cela que repérer des défauts que personne d’autre n’a vus peut déboucher sur une vraie percée
    • Si le but est simplement de distinguer quel modèle est meilleur, il suffit que le score du benchmark soit corrélé aux performances réelles
      Tant que la majorité des tâches est correctement notée, la direction générale peut rester valable
      Par exemple, même un benchmark médiocre où 49 % des labels sont faux peut encore classer correctement les modèles si un modèle qui répond toujours juste obtient 51 % et un modèle qui répond toujours faux obtient 49 %
      Beaucoup de benchmarks en machine learning comportent un nombre non trivial de mauvais labels, mais si l’objectif est de différencier des modèles, il est souvent plus utile de collecter un dataset plus grand que de consacrer le temps nécessaire à garantir une notation parfaite
    • En résumé, cela semble vouloir dire qu’il y a un problème sur environ 16 % des tâches