OpenMOSS a publié SWE-bench Science, un benchmark qui pose une question différente de celle posée jusqu'ici par la famille SWE-bench. Là où SWE-bench Verified et ses successeurs vérifient si le correctif d'un agent fait passer une suite de tests retenue, SWE-bench Science vérifie si le correctif d'un agent préserve la justesse spécifique au domaine dont dépend réellement un dépôt de logiciel scientifique — unités, systèmes de coordonnées, invariants numériques, sémantique des formats de fichiers, hypothèses physiques, et les flux de travail qui les relient. Un correctif peut passer tous les tests d'un dépôt et rester néanmoins erroné d'une façon qui corromprait discrètement un résultat de recherche — c'est exactement cet écart que ce benchmark est construit pour mettre au jour.
Ce qui est mesuré, et pourquoi c'est un axe différent
Les logiciels qui calculent des grandeurs physiques, transforment des systèmes de coordonnées ou analysent des formats de fichiers propres à un domaine ont des modes de défaillance que les logiciels génériques n'ont pas : une conversion d'unité discrètement perdue, un ordre d'axes inversé, une tolérance numérique assouplie au point de ne plus rien signifier. Une suite de tests écrite avant que ces contraintes n'aient été rendues explicites ne détecte pas nécessairement un changement qui les viole. D'où l'intérêt de traiter « est-ce que ça passe l'intégration continue » et « est-ce que ça préserve le contrat scientifique » comme deux questions distinctes, toutes deux dignes d'être mesurées. Cette approche mérite d'être prise au sérieux pour elle-même, quels que soient les taux de réussite constatés, puisqu'elle vise un mode de défaillance qu'une simple métrique de passage de tests ne peut structurellement pas voir.
Échelle et construction
Le benchmark comprend 119 tâches publiées, tirées de 98 dépôts GitHub répartis sur 20 domaines scientifiques. Parmi elles, 96 sont sous licences non restrictives et constituent l'ensemble d'évaluation par défaut, tandis que 23 tâches supplémentaires sous licences de la famille GPL/LGPL/AGPL ne sont disponibles que par choix explicite. C'est une décision délibérée et divulguée, destinée à garder l'ensemble par défaut juridiquement simple plutôt qu'à inclure silencieusement du code sous copyleft dans une exécution de benchmark par défaut. Un sous-ensemble distinct de 91 tâches est marqué pour une « ablation de connaissance scientifique » — testant ce qui arrive à la performance des agents quand un contexte scientifique spécifique au domaine est délibérément fourni ou retenu —, mais le dépôt du projet n'en détaille pas le protocole exact.
Chaque tâche est ancrée à un commit de référence fixe et est livrée sous forme de deux images Docker distinctes : une image d'environnement portant le code source de référence, les fixtures et les dépendances contre lesquels l'agent travaille, et une image de vérification qui applique le correctif candidat de l'agent à une reconstruction propre de cette référence et exécute contre lui des tests retenus. L'évaluation passe par un outil appelé Pier, avec des empreintes d'image figées et des configurations d'exécution enregistrées pour la reproductibilité. Cette séparation en deux images compte méthodologiquement : l'agent n'a jamais d'accès direct à l'environnement de vérification pendant son travail, ce qui ferme la voie la plus facile par laquelle un harnais pourrait sinon tricher avec une suite de tests fixe qu'il peut voir.
Le seul chiffre disponible, et ce qui n'a pas pu être confirmé
Le résultat phare rapporté pour ce benchmark : la meilleure configuration trouvée jusqu'ici, Claude Code exécutant Opus 5 à effort de raisonnement maximal, obtient un score inférieur à 50 % de pass@1. Il vaut la peine d'être précis sur les limites de cette affirmation : ce chiffre sous les 50 % repose sur une corroboration secondaire plutôt que sur une lecture directe du classement. Un classement complet couvrant d'autres agents et modèles (Codex, mini-swe-agent, et d'autres modèles de pointe explicitement pris en charge par l'outillage du projet) n'a pas pu être vérifié : il n'est donc pas rapporté ici plutôt que deviné.
Une autre petite incohérence mérite d'être signalée — le genre de détail que cette couverture vérifie systématiquement sur chaque benchmark auto-publié. Le README de premier niveau du projet indique une répartition par défaut/restreint de 96/23, tandis qu'un autre fichier de documentation du même dépôt l'indique à 97/22. Les deux chiffres ne se réconcilient avec aucun total de référence annoncé — exactement le genre d'écart de précision facile à laisser passer pour un lecteur et facile à corriger pour un projet.
Pas encore relu par les pairs
C'est un préprint arXiv, soumis ce mois-ci — une distinction importante pour un article qui fait des affirmations méthodologiques sur la façon dont les logiciels scientifiques devraient être évalués. Le statut de préprint ne rend pas la conception du benchmark ou le résultat rapporté erronés, mais cela signifie que la construction des tâches, la méthodologie de vérification des invariants et le taux de réussite phare n'ont pas encore traversé une relecture par les pairs indépendante — une étape qui mérite d'être attendue avant de traiter tout cela comme une mesure établie plutôt que proposée.
À surveiller
- La relecture par les pairs. Un benchmark dont toute la prémisse est la précision sur la justesse scientifique devrait être tenu à cette même précision — la relecture par les pairs en est le mécanisme.
- Un classement complet devenant lisible de façon indépendante. Le graphique de comparaison par modèle est publié sous forme d'image ; un tableau de classement en texte rendrait des résultats comme celui-ci vérifiables de façon indépendante.
- D'autres laboratoires publieront-ils des scores sur ce benchmark ? Un unique chiffre auto-rapporté de « meilleure configuration » est un point de départ, pas un classement — des exécutions tierces contre les mêmes références fixes et les mêmes images de vérification sont ce qui rendrait cela comparable au reste de la famille SWE-bench.