L'articolo su CodeAct ha argomentato in modo convincente a favore di Python come formato di azione appropriato per gli agenti LLM. Ma scegliere il giusto formato di azione è solo metà del problema — devi anche dimostrare che gli agenti possono gestire la complessità di compiti reali, non solo benchmark curati. SWE-bench (arXiv:2310.06770), pubblicato da Carlos Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press e Karthik Narasimhan di Princeton e presentato a ICLR 2024, è l'articolo che ha costretto il settore ad affrontare direttamente questo divario.
L'articolo
"SWE-bench: I modelli linguistici possono risolvere problemi reali di GitHub?" costruisce un benchmark di 2.294 istanze di compiti tratte da richieste pull effettivamente unite in 12 popolari repository Python — astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy e xarray. Ogni istanza presenta al modello un'istantanea del codice e una descrizione del problema di GitHub; il modello deve produrre una patch che faccia superare un insieme designato di test precedentemente falliti senza rompere i test esistenti. Il benchmark è stato costruito estraendo ~90.000 PR, filtrando quelle che sia risolvevano un problema collegato sia aggiungevano nuovi test, e poi verificando le transizioni di passaggio/fallimento basate sull'esecuzione. Questa costruzione disciplinata evita il tipico problema dei benchmark di una verità di base ambigua o facilmente aggirabile.
Idee chiave
- Claude 2, il modello con le migliori prestazioni al momento della pubblicazione, risolve solo l'1,96% dei problemi utilizzando il recupero sparso BM25 — l'impostazione di distribuzione realistica in cui il modello deve trovare i file rilevanti da solo.
- Con il recupero oracle — dove al modello vengono forniti esattamente i file di cui ha bisogno — Claude 2 migliora al 4,80%, confermando che il collo di bottiglia è in parte il recupero ma principalmente la modifica: anche con un contesto perfetto, i tassi di successo rimangono sotto il 5%.
- GPT-4 risolve lo 0,00% dei problemi con il recupero BM25 (valutato su un sottoinsieme del 25% per motivi di budget) e l'1,74% con oracle. Il calo da oracle a BM25 per Claude 2 è grave; per GPT-4 è totale.
- Le patch generate sono sistematicamente troppo corte: le patch riuscite di Claude 2 misurano in media 19,6 righe, contro le 74,5 righe delle patch umane gold. I modelli trovano soluzioni locali semplici; gli umani scrivono soluzioni complete su più file.
- Più contesto danneggia attivamente. BM25 a 50k token recupera più file oracle rispetto a 13k token, eppure i tassi di risoluzione spesso diminuiscono. L'effetto "perso nel mezzo" — i modelli che ignorano prove rilevanti nascoste in contesti lunghi — è una modalità di fallimento reale e documentata qui.
- SWE-Llama 13b, perfezionato su contesti recuperati con oracle, raggiunge il 4,00% con oracle ma solo lo 0,70% con BM25. L'addestramento su un contesto perfetto crea agenti fragili che collassano quando il recupero è realistico.
Cosa regge — e cosa no
La costruzione del benchmark è rigorosa. La valutazione basata sull'esecuzione — i test vengono effettivamente eseguiti, superati o falliti — è la verità di base corretta per i compiti di modifica del codice. È oggettiva, automatizzabile e difficile da aggirare. La decisione di richiedere transizioni fallimento-a-successo (non solo l'applicazione riuscita della patch) è particolarmente importante: previene patch banalmente corrette come no-op o cancellazioni.
I risultati hanno retto in modo notevole. SWE-bench è stato pubblicato nell'ottobre 2023 ed è rapidamente diventato la valutazione de facto per gli agenti di codifica. La baseline iniziale dell'1,96% è genuinamente informativa, non scelta ad arte. SWE-agent, pubblicato nel 2024 da un gruppo correlato, ha spostato l'asticella al 12,47% riprogettando l'interfaccia agente-computer — un miglioramento di 6 volte che di per sé conferma quanto la baseline originale abbia lasciato in sospeso.
Due cose che l'articolo non gestisce bene: Primo, il benchmark è solo Python. Questa è una necessità pratica, ma crea un rischio reale di eccessivo adattamento alle convenzioni di Python. Secondo, l'articolo propone solo baseline di generazione aumentata dal recupero e rinvia esplicitamente a lavori futuri per approcci basati su agenti. Quel rinvio era appropriato nel 2023, ma significa che l'articolo stesso non fornisce alcun segnale su quali architetture di agenti siano utili.
Anche l'impostazione "oracle" è un limite superiore più debole di quanto sembri. Fornire un contesto di file perfetto non risolve la localizzazione del codice all'interno di quei file, e non aiuta con il ragionamento su più file sulle interazioni tra moduli. Il 4,8% di Claude 2 con oracle significa che anche con i file giusti nel contesto, il modello fallisce il 95% delle volte. Il problema non è principalmente il recupero.
Perché questo è importante per l'IA finanziaria
Beancount è un progetto Python ospitato su GitHub. Un agente di scrittura per Beancount è, in sostanza, un agente che deve superare compiti in stile SWE-bench: dato un file di registro e un'istruzione ("aggiungi questa transazione", "correggi questa discrepanza di saldo"), produrre una modifica che superi bean-check senza rompere le asserzioni esistenti.
Il fallimento del recupero è direttamente analogo al problema di localizzazione del registro. Quando un utente dice "correggi la sopravvalutazione nelle forniture per ufficio del terzo trimestre", l'agente deve prima trovare le voci rilevanti in un file che potrebbe contenere migliaia di righe — lo stesso compito di localizzazione dei file in cui BM25 fallisce per il 40-50% delle istanze di SWE-bench. Il degrado "perso nel mezzo" si applica ugualmente a file .beancount lunghi, dove le voci datate precedenti hanno la stessa probabilità di essere ignorate.
L'asimmetria della lunghezza della patch è un avvertimento pratico. I modelli patchano in modo troppo ristretto. In contabilità, ciò si traduce nella correzione di una voce mentre si perde la voce di compensazione, o nell'aggiornamento della riga di spesa lasciando stantio il saldo corrente. Un agente Beancount in produzione ha bisogno di un livello di validazione — bean-check, asserzioni di saldo o un passaggio di riconciliazione esplicito — che costringa l'agente a vedere l'intera conseguenza della sua modifica, non solo la sua plausibilità locale.
Il divario oracle/BM25 è anche un promemoria del fatto che la qualità del recupero non è separabile dalla qualità dell'agente. Un agente che non riesce a identificare in modo affidabile quali conti o file sono rilevanti per la domanda di un utente fallirà al passaggio di navigazione del registro prima ancora di tentare una modifica.
Cosa leggere dopo
- SWE-agent (arXiv:2405.15793, NeurIPS 2024) — il seguito diretto; passa dall'1,96% al 12,47% riprogettando l'interfaccia agente-computer. I principi di progettazione per la navigazione dei file e la ricerca del codice sono direttamente applicabili agli strumenti dell'agente Beancount.
- Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — spoglia la complessità degli agenti e mostra che un semplice pipeline di localizzazione + riparazione senza impalcatura può essere competitivo; un utile contrappunto agli approcci incentrati sull'interfaccia.
- MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — affronta il problema del contesto lungo a testa alta con una gestione della memoria a livelli; direttamente rilevante per agenti che devono ragionare su registri Beancount pluriennali.