SWE-bench (benchmark) (IT)

From Systems analysis Wiki
Jump to navigation Jump to search

SWE-bench — è un benchmark su larga scala (insieme di attività di test) per la valutazione delle capacità dei grandi modelli linguistici (LLM) nel campo dello sviluppo software automatizzato e del debugging[1]. È stato sviluppato da un gruppo di ricercatori dell'Università di Princeton e di altre organizzazioni ed è stato presentato alla conferenza ICLR 2024[2]. SWE-bench si distingue dai benchmark di codice tradizionali per l'utilizzo di attività reali tratte dalla pratica dello sviluppo: il set di test comprende 2294 attività, basate su issue chiuse e relative correzioni (pull request) provenienti da 12 popolari repository Python open source su GitHub[1][3]. Ogni attività contiene la descrizione di un problema (issue) e fornisce al modello l'accesso al codice sorgente del progetto corrispondente; l'obiettivo del modello è generare modifiche minime alla codebase (patch) che risolvano il problema indicato[1][3].

Metodologia e caratteristiche della valutazione

SWE-bench simula il reale processo di sviluppo del software. Per ogni attività, al modello viene presentato il testo dell'issue originale su GitHub (descrizione del problema) e uno snapshot del codice del repository nella versione precedente alla correzione[4]. Il modello (o un agente basato sul modello) è tenuto ad analizzare il codice sorgente, comprendere la natura dell'errore o della modifica richiesta e apportare le correzioni ai file di codice pertinenti, risolvendo il problema[4][5]. La validazione della soluzione è automatizzata: a ogni attività sono associati test unitari reali provenienti dalla pull request che ha chiuso quel problema. Tra questi vi sono sia test «fail-to-pass» (che non vengono superati sul codice originale, ma devono essere superati dopo l'applicazione della correzione corretta) sia test di regressione (pass-to-pass, che vengono superati inizialmente e devono continuare a essere superati dopo le modifiche)[3]. La patch proposta dal modello viene applicata al codice, dopodiché vengono eseguiti i test corrispondenti: se tutti i test fail-to-pass iniziano a essere superati e i test pass-to-pass non vengono compromessi, l'attività è considerata risolta correttamente[3]. Questo approccio alla valutazione consente di verificare non solo la capacità del modello di generare codice sintatticamente corretto, ma anche la sua abilità di risolvere effettivamente il compito assegnato senza compromettere le funzionalità esistenti. Allo stesso tempo, il modello deve operare con un contesto ampio (un intero repository di codice), comprendere le relazioni tra i componenti e coordinare le modifiche in più file contemporaneamente[1] — tutto ciò è significativamente più complesso dei tipici compiti di scrittura di una funzione a partire da una descrizione.

Nelle valutazioni SWE-bench di solito non partecipano semplicemente gli LLM, ma sistemi agentici che avvolgono il modello con strumenti ausiliari (ad esempio, per la navigazione tra file, l'esecuzione di codice, l'uso del debugger, ecc.)[4][6]. Tale sistema imita il reale ciclo di sviluppo: il modello può esaminare i file in sequenza, eseguire test o script e migliorare progressivamente la soluzione finché non raggiunge un risultato positivo[4]. È significativo che l'efficacia nella risoluzione delle attività SWE-bench dipenda in larga misura dalla qualità di questo «scaffolding» (infrastruttura dell'agente): gli stessi modelli di base possono mostrare risultati diversi a seconda di come viene organizzata l'interazione con il repository e gli strumenti[4][7]. Pertanto, SWE-bench funge da misura delle capacità dell'insieme composto dal modello e dalla sua strategia di risoluzione delle attività, avvicinando la valutazione alle reali condizioni operative di un developer AI autonomo[4][7].

Varianti del set di attività

Gli autori di SWE-bench e la comunità hanno successivamente presentato diversi set derivati per diversi scopi di valutazione:

  • SWE-bench Lite — versione semplificata del benchmark, che include ~300 attività[8], selezionate in modo da ridurre la complessità e i costi computazionali del testing dei modelli. Questo sottoinsieme è stato creato per esperimenti rapidi con i modelli ed esclude le validazioni più laboriose, mantenendo al contempo la rappresentatività dei problemi principali[7]. In sostanza, Lite contiene attività di correzione di bug più semplici e brevi, e i risultati dei modelli su Lite sono in genere più alti che sul set completo, grazie all'esclusione dei casi più complessi[7].
  • SWE-bench Verified — sottoinsieme filtrato tramite verifica manuale, presentato nell'agosto 2024 in collaborazione con OpenAI[7]. I ricercatori hanno coinvolto 93 sviluppatori professionisti per analizzare ogni attività del benchmark originale ed escludere i casi in cui la descrizione originale del problema è troppo vaga o il comportamento richiesto dai test non emerge chiaramente dalle condizioni dell'attività[7]. Sono state inoltre rimosse le attività che in pratica non è possibile risolvere a causa di problemi ambientali o test non corretti[7]. Il risultato è un set di 500 attività, garantite risolvibili e correttamente formulate[7]. SWE-bench Verified mira a fornire una valutazione più affidabile delle capacità dei modelli, eliminando i casi in cui anche una soluzione corretta viene rifiutata a causa dell'inadeguatezza dei test o dell'enunciato[7]. Questo set ha sostituito i campioni di test originali di SWE-bench (completo e Lite) come principale riferimento per il confronto tra modelli[7]. Inoltre, insieme a Verified sono state pubblicate le valutazioni di difficoltà delle attività (ad esempio, sono state identificate attività «facili», risolvibili in <15 minuti da un essere umano, e attività «difficili», che richiedono >1 ora)[7], ed è stato rilasciato un nuovo framework strumentale basato su Docker per un'esecuzione dei test più stabile e riproducibile[7].
  • SWE-bench Multimodal — estensione del benchmark, presentata nel gennaio 2025, che include attività in cui la descrizione del problema contiene non solo testo, ma anche elementi visivi (ad esempio, immagini dell'interfaccia, screenshot di errori, ecc.)[8]. Questo set (517 attività[8]) verifica la capacità di modelli e agenti di comprendere e utilizzare informazioni visive nella risoluzione di attività di programmazione. La valutazione sul set multimodale è organizzata in modo analogo, ma richiede dal modello capacità multimodali (ad esempio, il riconoscimento del testo nelle immagini). La parte di test di SWE-bench Multimodal è mantenuta chiusa (nascosta) per prevenire l'adattamento delle soluzioni alle risposte note; gli sviluppatori possono inviare soluzioni a una leaderboard remota per valutare i propri modelli su queste attività[2].

Oltre a queste principali variazioni, attorno a SWE-bench si è formata un'ecosistema di strumenti: SWE-agent — un «agente» software open source che dimostra risultati all'avanguardia nelle attività del benchmark[2]; SWE-smith — un framework per l'addestramento di modelli developer personalizzati; SWE-REX — uno strumento per l'estrazione e l'elaborazione avanzata di informazioni dai repository, ecc. Questi progetti mirano a semplificare la riproducibilità dei risultati e a promuovere la ricerca nel campo dei sistemi di programmazione autonomi.

Risultati e progressi dei modelli

Alla sua prima apparizione, SWE-bench ha evidenziato un divario significativo tra gli LLM moderni e le competenze di programmatori esperti. Gli autori riportavano che persino i modelli più potenti dell'inizio del 2023 riuscivano a risolvere solo pochi punti percentuali delle attività: ad esempio, il modello Claude 2 di Anthropic risolveva con successo meno del 2% delle attività del set completo[1]. Il modello appositamente addestrato dagli autori del benchmark (basato su LLaMA, denominato SWE-Llama) e i modelli proprietari come GPT-4 riuscivano a risolvere principalmente solo gli errori più semplici[1]. Questi bassi valori iniziali hanno sottolineato la complessità di SWE-bench e hanno stimolato lo sviluppo di nuovi approcci.

Nel corso del 2024, con l'apparizione di modelli più avanzati e schemi agentici, i risultati sono migliorati significativamente. I ricercatori di Princeton hanno presentato il sistema SWE-agent, che combina GPT-4 con ricerca nel codice, pianificazione e altri strumenti; ha raggiunto circa il 12,5% di attività risolte sul set completo, stabilendo un nuovo riferimento per i modelli accademici[5]. A metà del 2024, nella leaderboard ufficiale di SWE-bench, le migliori soluzioni (incluse quelle proprietarie) avevano raggiunto circa il 20% di soluzioni riuscite sul benchmark completo e fino al 43% sul set semplificato Lite[7]. Tale crescita è legata al miglioramento dei modelli (ad esempio, l'arrivo di GPT-4, Claude 2 e 3) e in particolare allo sviluppo dello «scaffolding» — strategie esterne che consentono al modello di suddividere efficacemente il compito in passi, leggere la documentazione, avviare sessioni di debug, ecc.[7].

Dopo l'introduzione del set Verified alla fine del 2024 (ripulito dalle attività non corrette), le prestazioni misurabili sono aumentate ancora di più. Il modello GPT-4 (variante GPT-4o) ha subito mostrato circa il 33% di soluzioni riuscite su Verified rispetto al ~16% precedente sul set originale[7]. I migliori framework-agente open source (ad esempio, Agentless) hanno raddoppiato il loro risultato dal ~16% al 32% su Verified[7]. Ciò ha confermato l'ipotesi che il benchmark originale sottostimasse leggermente le prestazioni a causa della presenza di casi irrisolvibili[7]. Allo stesso tempo, il miglioramento dei risultati su Verified rispetto a Lite non è così drammatico (i modelli migliori avevano già raggiunto ~43% su Lite), il che è logico: Lite selezionava inizialmente esempi più semplici, mentre Verified ha rimosso quelli non eseguibili, ma ha mantenuto le attività difficili[7]. È importante notare che la crescita dei valori nel passaggio a Verified è avvenuta in tutte le categorie di difficoltà delle attività, non solo grazie all'eliminazione delle più difficili — ossia il filtraggio ha liberato il set anche da casi silenziosamente irrisolvibili tra le attività relativamente semplici[7].

All'inizio del 2025, i sistemi AI leader dimostrano già un'efficacia vicina a quella umana sul set verificato di attività, sebbene il tetto del 100% sia ancora lontano. Nel gennaio 2025, Anthropic ha annunciato che il suo nuovo modello Claude 3.5 Sonnet, in combinazione con un agente migliorato, ha risolto il 49% delle attività SWE-bench Verified[4], raggiungendo temporaneamente il primo posto. Le grandi aziende tecnologiche e i team indipendenti partecipano attivamente anche a competizioni non ufficiali su questo benchmark. Ad esempio, il team CodeStory ha sviluppato un approccio multi-modello con ricerca di varianti («Midwit Agent»), che ha raggiunto un record del 62,2% di attività risolte su Verified (dati all'inizio del 2025)[5][9]. È stato osservato che per ottenere questo risultato è stato necessario aumentare significativamente le spese di risorse computazionali nella fase di inferenza del modello (il cosiddetto inference time scaling), eseguendo numerosi tentativi di soluzione e selezionando il risultato migliore[5]. A sua volta, nei materiali di OpenAI veniva menzionato un sistema sperimentale GPT-03, che con una sufficiente scalabilità computazionale avrebbe presumibilmente superato la soglia del 70% su Verified (dati non ufficiali)[5]. Tuttavia, la verifica indipendente di questi risultati è assente, e un valore così elevato rimane più un obiettivo per ricerche future che un traguardo raggiunto.

Secondo una ricerca di Microsoft Research (2025), persino i modelli più recenti, dotati di strumenti di debug, non superano ancora la soglia del 50% di correzioni di bug riuscite da SWE-bench Lite[6]. In questo test, il migliore è risultato Claude 3.7 Sonnet con ~48,4% di attività risolte, mentre il sistema basato su GPT-4 (OpenAI o1) ha risolto circa il 30%, e il modello più leggero o3-mini solo il 22%[6]. Questi risultati sottolineano che, nonostante il rapido progresso, i sistemi AI moderni sono ancora inferiori ai programmatori esperti: per un essere umano la risoluzione di tali attività (con la comprensione del codice) non presenta difficoltà, mentre il modello spesso non è in grado di applicare efficacemente gli strumenti di debug o soffre della mancanza di dati di addestramento che riflettano il processo multi-step di correzione degli errori[6].

Limitazioni e prospettive

SWE-bench è diventata una piattaforma standardizzata per la valutazione di agenti di codice intelligenti, tuttavia le ricerche ne hanno evidenziato anche alcune limitazioni. Il problema principale è la copertura incompleta dei test: il set di test di verifica per ogni attività è tratto da una specifica pull request e di solito include solo i test unitari che sono stati modificati nella correzione del bug[3]. Come ha dimostrato l'analisi di un gruppo di ricercatori dell'Università di Zhejiang e dell'Università di Stoccarda (Wang et al. 2025), ignorare gli altri test del progetto può nascondere la scorrettezza di alcune soluzioni[3]. La verifica delle soluzioni sull'intero set di test del repository ha rivelato che in media il 7,8% delle patch contrassegnate come riuscite in SWE-bench in realtà non superano altri test nel progetto[3]. Ciò porta a una sovrastima della metrica «attività risolte» di circa 4-6 punti percentuali[3]. Un caso ancora più sottile si verifica quando la patch generata supera tutti i test originali, ma è non equivalente alla soluzione dello sviluppatore e modifica il comportamento del programma in modo diverso da quanto atteso. Mediante la generazione di test case aggiuntivi (metodologia PatchDiff), i ricercatori hanno rilevato che quasi il 30% delle correzioni proposte dall'AI si comporta diversamente rispetto alle patch di riferimento, e circa l'11% è inequivocabilmente errato, pur non essendo rilevato dai test esistenti[3]. Pertanto, le reali capacità dei modelli potrebbero essere sopravvalutate se ci si affida esclusivamente al superamento di un set limitato di test. I creatori di SWE-bench riconoscono questa vulnerabilità e sottolineano che il benchmark deve evolversi nel tempo: migliorare la copertura dei test, aggiungere verifiche sull'assenza di effetti collaterali indesiderati, ampliare il set di tipi di attività[7]. Lo sviluppo di tali strumenti di valutazione è una parte importante della preparazione all'avvento di developer AI sempre più autonomi e potenti, e l'esperienza con SWE-bench dimostra la necessità di prestare grande attenzione alla qualità dei benchmark[7].

SWE-bench, pur essendo solo un set statico di attività, non copre assolutamente tutti gli aspetti della programmazione, ma è già diventato uno standard de facto per l'analisi comparativa dei modelli di codice[3]. Viene utilizzato in lavori scientifici per dimostrare nuovi metodi e algoritmi, nonché da gruppi di ricerca industriale per valutare il potenziale di sistemi destinati ad automatizzare la programmazione[3]. La costante crescita dei risultati su SWE-bench nel periodo 2023-2025 dimostra chiaramente il rapido miglioramento delle capacità degli LLM nella risoluzione di attività pratiche di sviluppo. Allo stesso tempo, funge da barometro della complessità: anche avvicinandosi al 50-60% di attività risolte, i modelli sono ancora lontani da una piena sostituzione dell'essere umano, specialmente in condizioni di informazioni limitate e di necessità di una comprensione fine dei requisiti[4][7]. Tuttavia, il progresso non si ferma — grazie a iniziative come SWE-bench, la comunità vede chiaramente i propri obiettivi e limiti, e continua a muoversi verso la creazione di un vero developer AI, capace di comprendere e correggere autonomamente il codice sorgente al livello di un esperto umano[4][7].

Riferimenti

  • SWE-bench su GitHub
  • Leaderboard ufficiale SWE-bench

Bibliografia

  • Liang, P. et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110.
  • Chang, Y. et al. (2023). A Survey on Evaluation of Large Language Models. arXiv:2307.03109.
  • Ni, S. et al. (2025). A Survey on Large Language Model Benchmarks. arXiv:2508.15361.
  • Biderman, S. et al. (2024). The Language Model Evaluation Harness (lm-eval): Guidance and Lessons Learned. arXiv:2405.14782.
  • Kiela, D. et al. (2021). Dynabench: Rethinking Benchmarking in NLP. arXiv:2104.14337.
  • Ma, Z. et al. (2021). Dynaboard: An Evaluation‑As‑A‑Service Platform for Holistic Next‑Generation Benchmarking. arXiv:2106.06052.
  • Goel, K. et al. (2021). Robustness Gym: Unifying the NLP Evaluation Landscape. arXiv:2101.04840.
  • Xu, C. et al. (2024). Benchmark Data Contamination of Large Language Models: A Survey. arXiv:2406.04244.
  • Liu, S. et al. (2025). A Comprehensive Survey on Safety Evaluation of LLMs. arXiv:2506.11094.
  • Chiang, W.-L. et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. arXiv:2403.04132.
  • Boubdir, M. et al. (2023). Elo Uncovered: Robustness and Best Practices in Language Model Evaluation. arXiv:2311.17295.
  • Huang, L. et al. (2023). A Survey on Hallucination in Large Language Models. arXiv:2311.05232.

Note

  1. 1.0 1.1 1.2 1.3 1.4 1.5 Jimenez, Carlos E. et al. «SWE-bench: Can Language Models Resolve Real-World GitHub Issues?». arXiv. [1]
  2. 2.0 2.1 2.2 «SWE-bench/SWE-bench». GitHub. [2]
  3. 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 Wang, Shuyang et al. «Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study». arXiv. [3]
  4. 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 «Claude SWE-Bench Performance». Anthropic. [4]
  5. 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. «SWE Benchmark: LLM evaluation in Software Engineering Setting». Medium. [5]
  6. 6.0 6.1 6.2 6.3 Hatmaker, Taylor. «AI models still struggle to debug software, Microsoft study shows». TechCrunch. [6]
  7. 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 «Introducing SWE-bench Verified». OpenAI. [7]
  8. 8.0 8.1 8.2 «SWE-bench Leaderboard». [8]
  9. «SOTA on swebench-verified: relearning the bitter lesson». Hacker News (Y Combinator). [9]