Benchmark · agentic
Multi-SWE-bench
Multi-SWE-bench mesure si un agent de codage IA peut résoudre de vrais tickets (issues) GitHub sur de nombreux dépôts et langages de programmation, et pas seulement Python. La métrique principale est le taux de résolution (resolution rate) : le pourcentage d'instances dont le correctif fait passer la suite de tests cachée.
En savoir plus
- Exemple
- Une tâche représentative : à partir d'un vrai rapport de bug ou d'une demande de fonctionnalité issus d'un projet open source écrit dans un langage tel que Java, Go, Rust, TypeScript, JavaScript, C ou C++, ainsi que du dépôt extrait au commit précédant le correctif, l'agent doit produire un patch de code qui résout le problème décrit.
- Notation
- Chaque instance est notée réussite/échec par exécution. Le patch de l'agent est appliqué au dépôt et les tests du projet sont exécutés ; l'instance compte comme résolue uniquement si les tests désignés FAIL_TO_PASS passent désormais et si tous les tests PASS_TO_PASS passent toujours. Le score rapporté est le taux de résolution (instances résolues ÷ total), généralement en pass@1, et peut être ventilé par langage et par difficulté annotée par des experts (easy/medium/hard).
- Vérification
- L'acceptation repose entièrement sur l'exécution au sein d'une image Docker propre à chaque instance qui reproduit exactement la chaîne d'outils du langage et les dépendances. Le patch généré doit s'appliquer proprement, puis les tests fail-to-pass et pass-to-pass sont exécutés ; il n'y a ni évaluation par LLM ni comparaison textuelle avec le patch de référence du développeur.
- Pourquoi c'est important
- SWE-bench a été influent mais ne couvre que Python, alors que le génie logiciel réel s'étend à de nombreux langages. Multi-SWE-bench teste si les agents de codage généralisent d'un langage à l'autre sur des issues authentiques, avec des étiquettes de difficulté d'experts, offrant un signal plus difficile, plus réaliste et moins saturé de la capacité pratique en génie logiciel.
Exemple résolu
Tâche
Instance illustrative au format Multi-SWE-bench — langage : Go, une petite bibliothèque de collections génériques. problem_statement : « Stack.Pop() sur une pile vide renvoie la valeur zéro avec une erreur nil, masquant silencieusement des bugs chez l'appelant ; il devrait plutôt renvoyer la sentinelle ErrEmpty. » On vous fournit le dépôt au commit de base bogué et le test qui échoue. FAIL_TO_PASS : TestPopEmptyReturnsError. PASS_TO_PASS : TestPushThenPop, TestLen. Soumettez un patch qui fait passer le test en échec sans casser les tests qui passent.
Solution
--- a/stack.go
+++ b/stack.go
@@ func (s *Stack[T]) Pop() (T, error) {
+ if len(s.items) == 0 {
+ var zero T
+ return zero, ErrEmpty
+ }
n := len(s.items)
v := s.items[n-1]
s.items = s.items[:n-1]
return v, nil
}Explication
Le correctif ajoute à Pop une vérification de vacuité qui renvoie la sentinelle ErrEmpty (avec la valeur zéro du type) exactement comme l'attend TestPopEmptyReturnsError, tout en laissant inchangé le chemin normal de dépilage afin que TestPushThenPop et TestLen continuent de passer. La notation est purement par exécution : le harnais applique le patch dans l'image Docker de l'instance et ne la marque comme résolue que si le test FAIL_TO_PASS passe à la réussite et qu'aucun test PASS_TO_PASS ne régresse.
Aucun score vérifié pour ce benchmark à ce jour.