SWE-bench: Poden els models de llenguatge resoldre problemes reals de GitHub?

L'article CodeAct va argumentar de manera convincent que Python és el format d'acció adequat per als agents LLM. Però triar el format d'acció correcte és només la meitat del problema: també cal demostrar que els agents poden gestionar la complexitat de les tasques del món real, no només referents (benchmarks) seleccionats. SWE-bench (arXiv:2310.06770), publicat per Carlos Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press i Karthik Narasimhan de Princeton i presentat a l'ICLR 2024, és l'article que va obligar el camp a enfrontar-se directament a aquesta bretxa.

L'article

"SWE-bench: Poden els models de llenguatge resoldre problemes reals de GitHub?" construeix un referent de 2.294 instàncies de tasques extretes de pull requests reals fusionades en 12 repositoris populars de Python: astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy i xarray. Cada instància presenta al model una instantània de la base de codi i una descripció d'un problema de GitHub; el model ha de produir un pegat (patch) que faci que un conjunt designat de proves que anteriorment fallaven passin sense trencar les proves existents. El referent es va construir mitjançant la mineria d'unes 90.000 PR, filtrant aquelles que resolien un problema vinculat i afegien noves proves, i després verificant les transicions d'èxit/fallada basades en l'execució. Aquesta construcció disciplinada evita el problema típic dels referents de veritats fonamentals ambigües o fàcilment manipulables.

Idees clau

• Claude 2, el model amb millor rendiment en el moment de la publicació, resol només l'1,96% dels problemes utilitzant la recuperació dispersa BM25, l'entorn de desplegament realista on el model ha de trobar fitxers rellevants per si mateix.
• Amb la recuperació d'oracle —on el model rep exactament els fitxers que necessita— Claude 2 millora fins al 4,80%, confirmant que el coll d'ampolla és en part la recuperació però principalment l'edició: fins i tot amb un context perfecte, les taxes d'èxit es mantenen per sota del 5%.
• GPT-4 resol el 0,00% dels problemes amb la recuperació BM25 (avaluat en un subconjunt del 25% per raons de pressupost) i l'1,74% amb oracle. La caiguda d'oracle a BM25 per a Claude 2 és severa; per a GPT-4 és total.
• Els pegats generats són sistemàticament massa curts: els pegats reeixits de Claude 2 tenen una mitjana de 19,6 línies, en comparació amb les 74,5 línies dels pegats humans de referència. Els models troben correccions locals senzilles; els humans escriuen solucions completes que abasten diversos fitxers.
• Més context perjudica activament. BM25 amb 50.000 tokens recupera més fitxers de l'oracle que amb 13.000 tokens, però les taxes de resolució sovint disminueixen. L'efecte "perdut al mig" (lost in the middle) —els models que ignoren l'evidència rellevant enterrada en contextos llargs— és un mode de fallada real i documentat aquí.
• SWE-Llama 13b, ajustat amb contextos recuperats per oracle, aconsegueix un 4,00% amb oracle però només un 0,70% amb BM25. Entrenar en un context perfecte crea agents fràgils que col·lapsen quan la recuperació és realista.

Què es manté i què no

La construcció del referent és rigorosa. L'avaluació basada en l'execució —proves que s'executen realment, superades o fallides— és la veritat fonamental adequada per a les tasques d'edició de codi. És objectiva, automatitzable i difícil de manipular. La decisió de requerir transicions de fallada a èxit (no només l'aplicació reeixida del pegat) és especialment important: evita pegats trivialment correctes com operacions nul·les o eliminacions.

Els resultats s'han mantingut sorprenentment bé. SWE-bench es va publicar l'octubre de 2023 i ràpidament es va convertir en l'avaluació de facto per als agents de codificació. La línia de base inicial de l'1,96% és genuïnament informativa, no seleccionada a conveniència. SWE-agent, publicat el 2024 per un grup relacionat, va moure l'agulla al 12,47% redissenyant la interfície agent-ordinador, una millora de 6 vegades que confirma per si mateixa quant va deixar sobre la taula la línia de base original.

Dues coses que l'article no gestiona bé: En primer lloc, el referent és només per a Python. Això és una necessitat pràctica, però crea un risc real de sobreajustament a les convencions de Python. En segon lloc, l'article proposa només línies de base de generació augmentada per recuperació i remet explícitament a treballs futurs per als enfocaments basats en agents. Aquesta demora era adequada el 2023, però significa que l'article en si no proporciona cap senyal sobre quines arquitectures d'agents ajuden.

L'entorn "oracle" també és un límit superior més feble del que sembla. Proporcionar un context de fitxer perfecte no resol la localització del codi dins d'aquests fitxers, i no ajuda amb el raonament multifitxer sobre les interaccions entre mòduls. Claude 2 amb un 4,8% en oracle significa que, fins i tot amb els fitxers correctes en context, el model falla el 95% de les vegades. El problema no és principalment la recuperació.

Per què això és important per a la IA financera

Beancount és un projecte de Python allotjat a GitHub. Un agent d'escriptura per a Beancount és, en essència, un agent que necessita superar tasques de l'estil de SWE-bench: donat un fitxer de llibre major i una instrucció ("afegeix aquesta transacció", "corregeix aquesta discrepància de saldo"), produir una edició que passi el bean-check sense trencar les assercions existents.

El fracàs de la recuperació és directament anàleg al problema de la localització del llibre major. Quan un usuari diu "corregeix la sobreestimació en el material d'oficina del tercer trimestre", l'agent primer ha de trobar les entrades rellevants en un fitxer que podria contenir milers de línies, la mateixa tasca de localització de fitxers on BM25 falla en el 40-50% de les instàncies de SWE-bench. La degradació "perdut al mig" s'aplica igualment als fitxers .beancount llargs, on les entrades amb dates anteriors tenen les mateixes probabilitats de ser ignorades.

L'asimetria de la longitud del pegat és un advertiment pràctic. Els models posen pegats de manera massa estreta. En comptabilitat, això es tradueix a corregir una entrada mentre es perd l'entrada de compensació, o a actualitzar la línia de despesa mentre es deixa el saldo corrent desactualitzat. Un agent de Beancount de producció necessita una capa de validació —bean-check, assercions de saldo o un pas de conciliació explit— que obligui l'agent a veure la conseqüència total de la seva edició, no només la seva plausibilitat local.

La bretxa entre oracle i BM25 també és un recordatori que la qualitat de la recuperació no es pot separar de la qualitat de l'agent. Un agent que no pot identificar de manera fiable quins comptes o fitxers són rellevants per a la pregunta d'un usuari fallarà en el pas de navegació pel llibre major abans fins i tot d'intentar una edició.

Què llegir a continuació

• SWE-agent (arXiv:2405.15793, NeurIPS 2024) — el seguiment directe; passa de l'1,96% al 12,47% redissenyant la interfície agent-ordinador. Els principis de disseny per a la navegació de fitxers i la cerca de codi són directament aplicables a les eines d'agents de Beancount.
• Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — elimina la complexitat dels agents i mostra que una canonada senzilla de localització + reparació sense bastides pot ser competitiva; un contrapunt útil als enfocaments amb interfícies pesades.
• MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — aborda el problema del context llarg directament amb una gestió de memòria per nivells; directament rellevant per als agents que han de raonar sobre llibres majors de Beancount de diversos anys.