SWE-bench : Les modèles de langage peuvent-ils résoudre des problèmes GitHub réels ?

L'article CodeAct a présenté des arguments convaincants en faveur de Python comme format d'action approprié pour les agents LLM. Mais choisir le bon format d'action n'est que la moitié du problème — il faut aussi démontrer que les agents peuvent gérer la complexité des tâches réelles, et pas seulement des benchmarks triés sur le volet. SWE-bench (arXiv:2310.06770), publié par Carlos Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press et Karthik Narasimhan de Princeton et présenté à l'ICLR 2024, est l'article qui a forcé le domaine à confronter directement cet écart.

L'article

"SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" construit un benchmark de 2 294 instances de tâches tirées de pull requests fusionnées réelles sur 12 dépôts Python populaires — astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy et xarray. Chaque instance présente au modèle un instantané de la base de code et une description de ticket GitHub ; le modèle doit produire un correctif (patch) qui fait passer un ensemble désigné de tests échouant précédemment, sans casser les tests existants. Le benchmark a été construit en explorant environ 90 000 PR, en filtrant celles qui résolvaient à la fois un ticket lié et ajoutaient de nouveaux tests, puis en vérifiant les transitions succès/échec basées sur l'exécution. Cette construction disciplinée évite le problème typique des benchmarks aux vérités de terrain ambiguës ou facilement manipulables.

Idées clés

• Claude 2, le modèle le plus performant lors de la publication, ne résout que 1,96 % des problèmes en utilisant la recherche clairsemée BM25 — le cadre de déploiement réaliste où le modèle doit trouver les fichiers pertinents par lui-même.
• Avec la recherche par oracle — où l'on fournit au modèle exactement les fichiers dont il a besoin — Claude 2 monte à 4,80 %, confirmant que le goulot d'étranglement est en partie la recherche, mais principalement l'édition : même avec un contexte parfait, les taux de réussite restent inférieurs à 5 %.
• GPT-4 résout 0,00 % des problèmes avec la recherche BM25 (évalué sur un sous-ensemble de 25 % pour des raisons de budget) et 1,74 % avec l'oracle. La chute entre l'oracle et BM25 pour Claude 2 est sévère ; pour GPT-4, elle est totale.
• Les correctifs générés sont systématiquement trop courts : les correctifs réussis de Claude 2 font en moyenne 19,6 lignes, contre 74,5 lignes pour les correctifs humains de référence. Les modèles trouvent des solutions locales simples ; les humains écrivent des solutions complètes multi-fichiers.
• Un contexte plus large nuit activement. Le BM25 à 50 000 jetons récupère plus de fichiers de l'oracle qu'à 13 000 jetons, pourtant les taux de résolution diminuent souvent. L'effet « perdu au milieu » (lost in the middle) — les modèles ignorant des preuves pertinentes enfouies dans de longs contextes — est un mode d'échec réel et documenté ici.
• SWE-Llama 13b, affiné sur des contextes récupérés par oracle, atteint 4,00 % avec l'oracle mais seulement 0,70 % avec BM25. L'entraînement sur un contexte parfait crée des agents fragiles qui s'effondrent lorsque la recherche est réaliste.

Ce qui tient la route — et ce qui ne la tient pas

La construction du benchmark est rigoureuse. L'évaluation basée sur l'exécution — les tests sont réellement lancés et réussissent ou échouent — est la bonne vérité de terrain pour les tâches d'édition de code. C'est objectif, automatisable et difficile à manipuler. La décision d'exiger des transitions d'échec à succès (et pas seulement l'application réussie du correctif) est particulièrement importante : elle empêche les correctifs trivialement corrects comme les opérations nulles ou les suppressions.

Les résultats ont remarquablement bien résisté au temps. SWE-bench a été publié en octobre 2023 et est rapidement devenu l'évaluation de facto pour les agents de codage. La base initiale de 1,96 % est véritablement informative, pas choisie arbitrairement. SWE-agent, publié en 2024 par un groupe lié, a fait bouger les lignes à 12,47 % en repensant l'interface agent-ordinateur — une amélioration de 6x qui confirme elle-même tout ce que la base initiale laissait de côté.

Deux points que l'article ne gère pas bien : Premièrement, le benchmark est exclusivement en Python. C'est une nécessité pratique, mais cela crée un risque réel de sur-apprentissage (overfitting) aux conventions Python. Deuxièmement, l'article ne propose que des bases de génération augmentée par recherche (RAG) et renvoie explicitement aux travaux futurs pour les approches basées sur les agents. Ce report était approprié en 2023, mais signifie que l'article lui-même ne fournit aucun signal sur les architectures d'agents qui aident.

Le réglage « oracle » est également une limite supérieure plus faible qu'il n'y paraît. Fournir le contexte parfait du fichier ne résout pas la localisation du code à l'intérieur de ces fichiers, et cela n'aide pas au raisonnement multi-fichiers sur les interactions entre les modules. Claude 2 à 4,8 % avec l'oracle signifie que même avec les bons fichiers en contexte, le modèle échoue 95 % du temps. Le problème n'est pas prioritairement la recherche.

Pourquoi cela compte pour l'IA financière

Beancount est un projet Python hébergé sur GitHub. Un agent d'écriture (write-back) pour Beancount est, par essence, un agent qui doit réussir des tâches de type SWE-bench : à partir d'un fichier de grand livre et d'une instruction (« ajouter cette transaction », « corriger cet écart de solde »), produire une édition qui passe le bean-check sans casser les assertions existantes.

L'échec de la recherche est directement analogue au problème de localisation dans le grand livre. Lorsqu'un utilisateur dit « corriger la surestimation des fournitures de bureau au T3 », l'agent doit d'abord trouver les écritures pertinentes dans un fichier qui peut contenir des milliers de lignes — la même tâche de localisation de fichier où le BM25 échoue pour 40 à 50 % des instances de SWE-bench. La dégradation « perdu au milieu » s'applique également aux longs fichiers .beancount, où les écritures plus anciennes sont tout aussi susceptibles d'être ignorées.

L'asymétrie de la longueur des correctifs est un avertissement pratique. Les modèles appliquent des correctifs trop étroits. En comptabilité, cela se traduit par la correction d'une écriture tout en oubliant la contre-écriture, ou par la mise à jour de la ligne de dépense tout en laissant le solde courant périmé. Un agent Beancount de production a besoin d'une couche de validation — bean-check, assertions de solde ou une passe de rapprochement explicite — qui force l'agent à voir la conséquence complète de son édition, et pas seulement sa plausibilité locale.

L'écart oracle/BM25 rappelle également que la qualité de la recherche n'est pas séparable de la qualité de l'agent. Un agent qui ne peut pas identifier de manière fiable quels comptes ou fichiers sont pertinents pour la question d'un utilisateur échouera à l'étape de navigation dans le grand livre avant même de tenter une édition.

Lectures suggérées

• SWE-agent (arXiv:2405.15793, NeurIPS 2024) — le suivi direct ; passe de 1,96 % à 12,47 % en repensant l'interface agent-ordinateur. Les principes de conception pour la navigation dans les fichiers et la recherche de code sont directement applicables à l'outillage des agents Beancount.
• Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — dépouille la complexité de l'agent et montre qu'un simple pipeline localisation + réparation sans infrastructure complexe peut être compétitif ; un contrepoint utile aux approches lourdes en interface.
• MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — s'attaque de front au problème du contexte long avec une gestion de la mémoire par paliers ; directement pertinent pour les agents qui doivent raisonner sur des grands livres Beancount s'étendant sur plusieurs années.