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. Ce cadrage mérite d'être pris au sérieux pour lui-même, indépendamment de où se situent les taux de réussite précis, puisqu'il 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 — une décision délibérée et divulguée pour garder l'ensemble par défaut juridiquement simple plutôt que d'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, bien que le propre dépôt du projet ne détaille pas le protocole exact dans les pages accessibles ici.
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 — l'accès réseau de cet environnement bloque les récupérations directes vers arxiv.org, la page du jeu de données sur Hugging Face, et le propre site de classement du projet (swescience.github.io), où se trouve le vrai graphique de comparaison par modèle. Le chiffre sous les 50 % pour la configuration en tête est le seul chiffre pour lequel ce billet a pu obtenir une corroboration indépendante, via une recherche plutôt qu'une lecture directe de la source ; 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é et n'est pas rapporté ici plutôt que d'être deviné.
Un autre point qui mérite d'être signalé précisément parce que c'est le genre de petite incohérence 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. Aucun des deux chiffres n'a pu être réconcilié avec un total de référence dans ce qui est accessible ici — à noter comme 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 se trouve derrière une page que cet environnement ne peut pas récupérer directement ; un tableau de classement en texte, plutôt qu'une image, rendrait des résultats comme celui-ci vérifiables de façon indépendante sans dépendre de résumés de moteurs de recherche.
- Si d'autres laboratoires rapportent 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.
Références : arXiv — SWE-bench Science: Can Coding Agents Resolve Engineering Tasks in Science? (2608.19799) · GitHub — OpenMOSS/SWE-bench-Science · Classement — swescience.github.io · couverture liée : Prime Agent dépasse la ligne humaine de 0,1 point · Frontier Arcade : tendances et prédictions