SWE-QA: Can Language Models Answer Repository-level Code Questions?

1. Enunciato del Problema

I moderni Modelli Linguistici di Grandi Dimensioni (LLM) hanno dimostrato potenziale nella comprensione del codice, ma i benchmark esistenti (ad esempio CoSQA, CodeQA) si concentrano prevalentemente su frammenti di codice isolati, funzioni o API. Queste impostazioni non riescono a catturare la complessità dell'ingegneria del software reale, dove gli sviluppatori devono:

• Navigare in grandi codebase interconnessi che si estendono su più file.
• Comprendere l'architettura software e le ragioni alla base delle scelte progettuali.
• Tracciare dipendenze a lungo raggio ed eseguire ragionamenti multi-hop.
• Sintetizzare conoscenze architetturali per rispondere a complesse domande "Perché" e "Come".

Manca un benchmark di alta qualità, verificato da umani, che valuti gli LLM sulla risposta a domande (QA) a livello di repository, richiedendo un contesto profondo multi-file e una comprensione strutturale.

2. Metodologia: Costruzione del Benchmark SWE-QA

Gli autori propongono SWE-QA, un benchmark di QA per codice a livello di repository costruito attraverso una pipeline a quattro fasi (Figura 2) che coinvolge 15 repository Python diversificati (12 da SWE-Bench, 3 da SWE-Bench-Live).

A. Raccolta dei Semi e Costruzione della Tassonomia

• Fonte Dati: Sono stati estratti 77.100 issue da GitHub provenienti da 12 repository popolari.
• Filtraggio: Sono stati selezionati 41.955 issue con contenuto sostanziale (>1.000 caratteri) e utilizzato un LLM per estrarre 127.415 domande esplicite relative al codice.
• Tassonomia: Due esperti umani con oltre 3 anni di esperienza hanno analizzato manualmente 1.000 domande campionate per creare una tassonomia a due livelli:
  • Livello 1 (Interrogativo): Cosa, Perché, Dove, Come.
  • Livello 2 (Intento): 12 categorie granulari (ad esempio, Tracciamento delle Dipendenze, Rationale Progettuale, Localizzazione delle Funzionalità, Implementazione dell'Algoritmo).
• Distribuzione: Le domande "Come" (35,2%) e "Dove" (28,4%) sono le più frequenti, riflettendo la necessità di conoscenze procedurali e di localizzazione.

B. Istantizzazione delle Domande

• Estrazione del Contesto: È stato utilizzato tree-sitter per analizzare la struttura dei repository in grafi tipizzati (nodi: classi, metodi, file; archi: chiamate, importazioni).
• Generazione: Sono stati selezionati elementi focali (ad esempio, una classe specifica) e combinati con il loro contesto strutturale utilizzando template di partenza derivati dalla tassonomia.
• Processo: Un LLM ha generato domande candidate adattate a repository specifici, assicurando che richiedessero ragionamenti multi-hop e non potessero essere risposte tramite semplice recupero.

C. Raccolta e Validazione delle Risposte

• Pipeline RAG: Le risposte sono state generate utilizzando un approccio di Generazione Aumentata dal Recupero (RAG), recuperando frammenti di codice rilevanti, documentazione e metadati.
• Uomo nel Loop:
  • Revisione Esperta: Due sviluppatori senior hanno revisionato ogni risposta per accuratezza fattuale, completezza e chiarezza utilizzando strumenti come Cursor. I disaccordi sono stati risolti da un terzo esperto.
  • Filtraggio della Qualità: Le coppie sono state scartate se ambigue, fattualmente errate o prive di un fondamento sufficiente nel codice.
• Dataset Finale: 720 coppie QA di alta qualità (48 per repository), che coprono 13.300 file e oltre 3,4 milioni di righe di codice.

3. Contributi Chiave

1. Benchmark SWE-QA: Un benchmark di QA a livello di repository con 720 coppie QA verificate da umani che coprono 15 repository Python. Combina in modo unico ragionamento multi-hop, dipendenze tra file e comprensione architetturale.
2. Pipeline di Generazione Flessibile: Un framework modulare che consente la creazione semi-automatica di dataset QA per qualsiasi nuovo repository open-source utilizzando template di partenza e analisi statica del codice.
3. Valutazione Completa: Una valutazione rigorosa degli LLM sotto diverse strategie di aumento del contesto (Prompting Diretto, RAG, Framework di Agenti).

4. Risultati Sperimentali

Gli autori hanno valutato sei LLM avanzati (inclusi GPT-5.1, Gemini 2.5 Pro, GLM-4.6 e Qwen3-Coder) utilizzando diverse strategie:

• Impatto dell'Aumento del Contesto:
  • Prompting Diretto: Ha performato male (ad esempio, Kimi K2 ha ottenuto circa 51/100), evidenziando la necessità del contesto del repository.
  • RAG (Finestra Scorrevole/Chunking delle Funzioni): Ha migliorato significativamente le prestazioni (ad esempio, +10–14 punti).
  • Framework di Agenti (OpenHands, SWE-agent): Hanno ottenuto i migliori risultati abilitando ragionamento iterativo e uso di strumenti. OpenHands con GPT-5.1 ha ottenuto il punteggio più alto di 70,79/100.
• Prestazioni del Modello:
  • GPT-5.1 e GLM-4.6 (con OpenHands) hanno guidato la classifica.
  • Modelli più piccoli (ad esempio Qwen3-30B) hanno faticato con i framework di agenti, performando in modo simile o peggiore rispetto al RAG, suggerendo limitazioni nella memoria a lungo termine e nella pianificazione degli strumenti.
  • Gli strumenti commerciali (Cursor, Tongyi Lingma) hanno performato in modo competitivo (69–70), validando soluzioni integrate con strumenti end-to-end.
• Analisi della Tassonomia:
  • I modelli hanno eccellito nelle domande "Perché" (Rationale Progettuale) e "Come" riguardanti il supporto API, dove le informazioni sono spesso esplicite nelle docstring.
  • I modelli hanno faticato con le domande "Cosa" (Esplorazione dell'architettura) e "Dove" (Localizzazione delle funzionalità), che richiedono di ricostruire logica dispersa tra più file.
• Generalizzazione Cross-Repository:
  • Le prestazioni sono variate in base alla complessità del repository. "Flask" è stato il più semplice (75,42), mentre "Pylint" (62,01) e "Conan" (64,51) sono stati i più impegnativi.
  • I repository provenienti da SWE-Bench-Live (minore perdita di dati) sono stati più difficili di quelli provenienti da SWE-Bench.

5. Significato e Direzioni Future

• Valutazione Realistica: SWE-QA supera i test a livello di frammento per valutare la comprensione dell'"intero repository" richiesta per compiti di ingegneria del software reali.
• Framework di Agenti: I risultati suggeriscono che, sebbene il RAG aiuti, i framework basati su agenti sono attualmente l'approccio più efficace per navigare in codebase complessi e multi-file, nonostante i costi di token più elevati.
• Limitazioni: Il benchmark è attualmente limitato al solo Python e basato su snapshot statici. Il lavoro futuro mira ad estendersi ad altri linguaggi e a repository dinamici ed evolutivi.
• Sfide Aperte: Il documento evidenzia che gli LLM faticano ancora nel tracciamento profondo delle dipendenze e nel ragionamento di localizzazione preciso, indicando la necessità di una migliore integrazione dei grafi di codice e di capacità di ragionamento.

Il documento conclude che, sebbene gli LLM mostrino potenziale nella QA a livello di repository, specialmente se potenziati da agenti, rimangono sfide significative nella gestione di dipendenze complesse multi-hop e nel ragionamento architetturale.