SWE-bench: Dokážu jazykové modely riešiť skutočné problémy na GitHub-e?

Článok CodeAct presvedčivo argumentoval v prospech Pythonu ako správneho formátu akcií pre agentov LLM. Ale výber správneho formátu akcií je len polovica problému — musíte tiež dokázať, že agenti zvládnu zložitosť úloh z reálneho sveta, nielen vybrané benchmarky. SWE-bench (arXiv:2310.06770), publikovaný autormi Carlos Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press a Karthik Narasimhan z Princetonu a prezentovaný na ICLR 2024, je článok, ktorý prinútil toto odvetvie priamo čeliť tejto medzere.

O článku

"SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" buduje benchmark z 2 294 inštancií úloh vybraných zo skutočných zlúčených pull requestov v 12 populárnych repozitároch Pythonu — astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy a xarray. Každá inštancia predkladá modelu snímku kódovej bázy a popis problému na GitHub-e; model musí vytvoriť patch, vďaka ktorému prejde určená sada predtým neúspešných testov bez toho, aby sa porušili existujúce testy. Benchmark bol vytvorený vyťažením približne 90 000 PR, filtrovaním tých, ktoré vyriešili prepojený problém a zároveň pridali nové testy, a následným overením prechodov úspešnosti/neúspešnosti na základe spustenia. Táto disciplinovaná konštrukcia sa vyhýba typickému problému benchmarkov s nejednoznačnou alebo ľahko manipulovateľnou pravdou (ground truth).

Kľúčové myšlienky

• Claude 2, najvýkonnejší model v čase publikácie, vyriešil iba 1,96 % problémov pomocou riedkeho vyhľadávania BM25 — čo je realistické nastavenie nasadenia, kde si model musí relevantné súbory nájsť sám.
• Pri vyhľadávaní typu „oracle“ — kedy model dostane presne tie súbory, ktoré potrebuje — sa Claude 2 zlepšil na 4,80 %, čo potvrdzuje, že úzkym hrdlom je čiastočne vyhľadávanie, ale hlavne editovanie: aj s dokonalým kontextom zostáva miera úspešnosti pod 5 %.
• GPT-4 vyriešil 0,00 % problémov s vyhľadávaním BM25 (vyhodnotené na 25 % podmnožine z rozpočtových dôvodov) a 1,74 % s oracle. Pokles z oracle na BM25 je pri Claude 2 drastický; pri GPT-4 je totálny.
• Generované patche sú systematicky príliš krátke: úspešné patche Claude 2 majú v priemere 19,6 riadkov, v porovnaní so 74,5 riadkami pri zlatých ľudských patchoch. Modely nachádzajú jednoduché lokálne opravy; ľudia píšu komplexné riešenia naprieč viacerými súbormi.
• Viac kontextu aktívne škodí. BM25 pri 50 tisícoch tokenov vyhľadá viac oracle súborov ako pri 13 tisícoch, napriek tomu miera vyriešenia často klesá. Efekt „stratený v strede“ (lost in the middle) — modely ignorujúce relevantné dôkazy pochované v dlhých kontextoch — je tu reálnym a zdokumentovaným spôsobom zlyhania.
• SWE-Llama 13b, jemne doladená na kontextoch získaných cez oracle, dosahuje 4,00 % s oracle, ale iba 0,70 % s BM25. Trénovanie na dokonalom kontexte vytvára krehkých agentov, ktorí zlyhávajú pri realistickom vyhľadávaní.

Čo obstojí — a čo nie

Konštrukcia benchmarku je prísna. Evaluácia založená na spustení — testy sa skutočne spustia a buď prejdú, alebo nie — je správnou pravdou pre úlohy editovania kódu. Je objektívna, automatizovateľná a ťažko sa manipuluje. Rozhodnutie vyžadovať prechody z neúspechu na úspech (nielen úspešnú aplikáciu patchu) je obzvlášť dôležité: zabraňuje triviálne správnym patchom, ako sú prázdne operácie alebo mazanie.

Výsledky obstáli pozoruhodne dobre. SWE-bench bol publikovaný v októbri 2023 a rýchlo sa stal de facto štandardom pre hodnotenie kódovacích agentov. Počiatočná základná línia 1,96 % je skutočne informatívna, nie účelovo vybratá. SWE-agent, publikovaný v roku 2024 súvisiacou skupinou, posunul hranicu na 12,47 % prepracovaním rozhrania medzi agentom a počítačom — čo je 6-násobné zlepšenie, ktoré samo o sebe potvrdzuje, koľko toho pôvodná základná línia ponechala nevyužitého.

Dve veci, ktoré článok nerieši dobre: Po prvé, benchmark je určený len pre Python. Je to praktická nevyhnutnosť, ale vytvára to reálne riziko pretrénovania na konvencie Pythonu. Po druhé, článok navrhuje iba základné línie založené na generovaní rozšírenom o vyhľadávanie (RAG) a explicitne odkladá prístupy založené na agentoch na budúcu prácu. Toto odloženie bolo v roku 2023 primerané, ale znamená to, že samotný článok neposkytuje žiadny signál o tom, ktoré architektúry agentov pomáhajú.

Nastavenie „oracle“ je tiež slabším horným limitom, než sa zdá. Poskytnutie dokonalého kontextu súborov nerieši lokalizáciu kódu v rámci týchto súborov a nepomáha s uvažovaním o interakciách medzi modulmi vo viacerých súboroch. Výsledok Claude 2 na úrovni 4,8 % pri oracle znamená, že aj so správnymi súbormi v kontexte model zlyhá v 95 % prípadov. Problém nie je primárne vo vyhľadávaní.

Prečo je to dôležité pre finančnú AI

Beancount je projekt v Pythone hostovaný na GitHub-e. Agent pre spätný zápis pre Beancount je v podstate agent, ktorý musí riešiť úlohy v štýle SWE-bench: na základe súboru účtovnej knihy a inštrukcie („pridaj túto transakciu“, „oprav túto nezrovnalosť v zostatku“) vytvoriť úpravu, ktorá prejde kontrolou bean-check bez porušenia existujúcich asercií.

Zlyhanie vyhľadávania je priamo analogické k problému lokalizácie v účtovnej knihe. Keď používateľ povie „oprav nadhodnotenie v kancelárskych potrebách za 3. štvrťrok“, agent musí najprv nájsť relevantné záznamy v súbore, ktorý môže obsahovať tisíce riadkov — čo je rovnaká úloha lokalizácie súborov, kde BM25 zlyháva v 40 – 50 % inštancií SWE-bench. Degradácia „stratený v strede“ sa rovnako vzťahuje na dlhé súbory .beancount, kde je rovnako pravdepodobné, že staršie datované záznamy budú ignorované.

Asymetria dĺžky patchov je praktickým varovaním. Modely opravujú príliš úzko. V účtovníctve sa to prejavuje opravou jedného zápisu, pričom sa vynechá protizápis, alebo aktualizáciou nákladového riadku, pričom priebežný zostatok zostane neaktuálny. Produkčný agent pre Beancount potrebuje validačnú vrstvu — bean-check, asercie zostatku alebo explicitný odsúhlasovací proces — ktorý prinúti agenta vidieť úplný dôsledok jeho úpravy, nielen jej lokálnu uveriteľnosť.

Priepasť medzi oracle a BM25 je tiež pripomenutím, že kvalita vyhľadávania nie je oddeliteľná od kvality agenta. Agent, ktorý nedokáže spoľahlivo identifikovať, ktoré účty alebo súbory sú relevantné pre otázku používateľa, zlyhá už pri kroku navigácie v účtovnej knihe, skôr než sa vôbec pokúsi o úpravu.

Čo si prečítať ďalej

• SWE-agent (arXiv:2405.15793, NeurIPS 2024) — priame pokračovanie; posúva sa z 1,96 % na 12,47 % prepracovaním rozhrania medzi agentom a počítačom. Princípy návrhu pre navigáciu v súboroch a vyhľadávanie kódu sú priamo použiteľné pre nástroje agentov Beancount.
• Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — odstraňuje zložitosť agentov a ukazuje, že jednoduchá pipeline pre lokalizáciu a opravu bez zložitej infraštruktúry môže byť konkurencieschopná; užitočný protipól k prístupom náročným na rozhranie.
• MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — rieši problém dlhého kontextu priamo pomocou vrstvenej správy pamäte; priamo relevantné pre agentov, ktorí musia uvažovať nad viacročnými účtovnými knihami Beancount.