Beyond Code Snippets: Benchmarking LLMs on Repository-Level Question Answering

1. Il Problema

La comprensione del software è una delle attività più dispendiose in termini di tempo per gli sviluppatori (circa il 58% del tempo). Sebbene i Modelli Linguistici su Grande Scala (LLM) abbiano mostrato capacità promettenti nel rispondere a domande su frammenti di codice isolati (snippet), la maggior parte degli studi e dei benchmark attuali si concentra su funzioni singole o file isolati.

Questo approccio trascura le sfide della comprensione del programma a livello di repository, dove le domande reali degli sviluppatori spesso richiedono di tracciare dipendenze tra più file, comprendere gerarchie di classi e analizzare relazioni strutturali complesse. Inoltre, le soluzioni basate su RAG (Retrieval-Augmented Generation) che si affidano esclusivamente alla similarità testuale piatta sono insufficienti per il codice, poiché non catturano le relazioni semantiche e strutturali intrinseche (es. chiamate di funzioni, dipendenze di dati). Infine, esiste il rischio che i modelli ottengano buoni risultati non grazie al ragionamento, ma alla memorizzazione di domande e risposte già presenti nei dati di addestramento (es. Stack Overflow).

2. Metodologia

Gli autori hanno sviluppato un approccio sistematico basato su un nuovo dataset e una valutazione multi-agente.

A. Dataset: StackRepoQA

• Costruzione: È stato creato il primo dataset pubblico multi-progetto per domande e risposte a livello di repository.
• Fonti: 1.318 domande reali con risposte accettate da Stack Overflow, mappate su 134 progetti Java open-source attivi su GitHub.
• Filtraggio: I repository sono stati selezionati in base a criteri rigorosi (almeno 20 contributori, 10 stelle, 1.000 commit, licenza permissiva, ecc.). Le domande sono state filtrate per garantire la pertinenza con il repository mappato.
• Caratteristica Unica: Il dataset include un'analisi temporale basata sulle date di taglio (cutoff) dell'addestramento dei modelli, permettendo di distinguere tra domande "viste" (pre-cutoff) e "non viste" (post-cutoff).

B. Sperimentazione e Architettura

• Modelli Valutati: Claude 3.5 Sonnet e GPT-4o.
• Configurazioni di Valutazione:
  1. Baseline (Direct Prompting): Il modello risponde senza strumenti esterni.
  2. Agentic RAG: Un sistema multi-agente dove un "Supervisor" coordina agenti specializzati:
     • File-RAG Agent: Recupera frammenti di codice rilevanti tramite similarità vettoriale (ChromaDB).
     • Graph-RAG Agent: Interroga un database Neo4j contenente la struttura del codice (AST, dipendenze statiche, relazioni CALLS/CONTAINS) per recuperare sottografi rilevanti.
     • Summarization Agent: Sintetizza le informazioni recuperate in una risposta coerente.
• Valutazione: Utilizzo di "LLM-as-a-judge" per valutare la correttezza, completezza e fedeltà delle risposte su una scala 1-10, con validazione incrociata da parte di ingegneri software umani.

3. Contributi Chiave

1. StackRepoQA: Il primo dataset pubblico multi-progetto per QA a livello di repository, derivato da domande reali di sviluppatori, che permette di testare la capacità di ragionamento su contesti ampi.
2. Valutazione Sistematica: Un framework di valutazione che confronta modelli LLM diretti con configurazioni agentiche che integrano recupero file e recupero basato su grafi.
3. Studio di Ablazione: Dimostrazione empirica che il recupero basato su grafi (Graph RAG) offre guadagni di performance superiori rispetto al solo recupero file-level.
4. Analisi Memorizzazione vs. Ragionamento: La prima evidenza empirica che mostra come i punteggi elevati su benchmark di QA a livello di repository siano spesso dovuti alla memorizzazione di contenuti di Stack Overflow piuttosto che al ragionamento sul codice sorgente.

4. Risultati Principali

Accuratezza e Memorizzazione (RQ1)

• Senza augmentation, i modelli raggiungono un'accuratezza moderata (circa 6.7-6.9 su 10).
• Effetto Cutoff: C'è un calo significativo delle prestazioni per le domande poste dopo la data di taglio dell'addestramento (es. da 6.59 a 5.44 per Claude). Questo conferma che gran parte del successo sui dati precedenti deriva dalla memorizzazione.
• Riproduzione Verbatim: L'analisi ha rivelato che molte risposte sono riproduzioni quasi letterali delle risposte accettate su Stack Overflow, indicando contaminazione dei dati di addestramento.

Impatto dell'Augmentation (RQ2)

• Miglioramento Strutturale: L'uso del RAG migliora le prestazioni, ma la strategia di recupero è cruciale.
  • File-RAG: Fornisce benefici limitati (punteggio medio ~5.66).
  • Graph-RAG: Offre i guadagni più consistenti (punteggio medio ~6.12), dimostrando che le relazioni strutturali sono essenziali per la comprensione del repository.
• Distracting Effect: L'aggiunta di contesto irrilevante (domande non correlate al progetto) degrada le prestazioni, confermando la vulnerabilità degli LLM al "rumore" contestuale.
• Confronto Modelli: Claude 3.5 ha mostrato prestazioni superiori nel generare query Cypher per il database grafico rispetto a GPT-4o.

5. Significato e Implicazioni

• Limiti Attuali: I modelli LLM attuali non sono ancora pronti per essere utilizzati come soluzioni autonome per la comprensione di repository complessi, specialmente per progetti privati o in rapida evoluzione dove non esiste memorizzazione pregressa.
• Necessità di Strutture: Il semplice recupero testuale non è sufficiente. È fondamentale integrare rappresentazioni strutturate (grafi di dipendenze, AST) per guidare il ragionamento del modello.
• Nuovi Standard di Benchmark: Lo studio invita la comunità a sviluppare benchmark che disgiungano esplicitamente la memorizzazione dal ragionamento (es. utilizzando dataset post-cutoff o repository non visti) e a evitare la sovrastima delle capacità degli LLM basata su dati contaminati.
• Implicazioni Pratiche: Gli sviluppatori dovrebbero adottare sistemi ibridi che combinino LLM con meccanismi di recupero strutturato e verifiche rigorose, piuttosto che affidarsi ciecamente alla conoscenza interna del modello.

In sintesi, il paper stabilisce che mentre gli LLM hanno potenziale, la loro applicazione alla comprensione del software su larga scala richiede un cambio di paradigma: dal recupero testuale al recupero strutturale e da una valutazione basata sulla conoscenza statica a una basata sul ragionamento dinamico su dati non visti.