On the Role of Fault Localization Context for LLM-Based Program Repair

1. Il Problema

L'Automated Program Repair (APR) basato su Large Language Models (LLM) ha fatto passi da gigante, ma la sua efficacia dipende criticamente da come il modello identifica le posizioni del codice da riparare (Fault Localization - FL).
Esiste un'ipotesi non verificata nella comunità: più contesto di localizzazione si fornisce all'LLM, migliore sarà la riparazione. Tuttavia, non è chiaro:

• Quanto contesto sia realmente necessario.
• Se espandere il contesto oltre la posizione esatta del bug (a livello di file, elemento o riga) sia benefico o dannoso.
• Come questo contesto debba essere recuperato (euristiche strutturali vs. recupero semantico basato su LLM).

Molti sistemi APR attuali adottano strategie di localizzazione fisse senza analizzare sistematicamente l'interazione tra diverse granularità (file, funzioni/classi, righe) e come l'espansione del contesto influisca sul successo della riparazione.

2. Metodologia

Gli autori hanno condotto uno studio empirico su larga scala per isolare l'impatto del contesto di localizzazione.

• Dataset: 500 istanze reali del benchmark SWE-bench Verified (repository Python come Django, Matplotlib, Scikit-learn).
• Modello: Utilizzo di GPT-5-mini per la generazione delle patch.
• Design Sperimentale: Uno studio fattoriale che varia tre dimensioni ortogonali del contesto:
  1. Livello File: Nessuno, File "buggy" (ground-truth), File rilevanti basati su regole (importi/che importano), File rilevanti recuperati da LLM.
  2. Livello Elemento (Funzioni/Classi): Nessuno, Elementi "buggy", Elementi basati su Call Graph, Elementi recuperati da LLM.
  3. Livello Riga: Nessuna, Righe "buggy", Finestra di contesto (±10 righe), Code slicing statico, Righe recuperate da LLM.
• Configurazioni: Sono state testate 61 configurazioni diverse (combinazioni delle tre dimensioni).
• Assunzione Chiave: Per isolare l'effetto del contesto dall'errore di localizzazione, lo studio assume una localizzazione perfetta (Ground Truth) per estrarre i file, gli elementi e le righe "buggy". Questo permette di valutare se l'aggiunta di contesto extra aiuta o danneggia il modello quando le posizioni esatte sono già note.
• Metrica: Tasso di risoluzione (percentuale di istanze in cui la patch generata passa tutti i test).

3. Contributi Chiave e Risultati Principali

Lo studio ha prodotto risultati che sfidano l'assunzione comune che "più contesto sia sempre meglio".

A. Il Livello File è Dominante

• Impatto: Introdurre il contesto a livello di file offre il miglioramento più significativo rispetto alla baseline senza file (miglioramento di 15-17 volte, dal 3.6% al ~60%).
• Espansione: Espandere il contesto oltre i soli file "buggy" migliora ulteriormente le prestazioni.
• Recupero: Il recupero basato su LLM supera significativamente le euristiche basate su regole (es. importi). Le configurazioni con file recuperati da LLM risolvono più istanze e lo fanno con meno file e meno token rispetto ai metodi basati su regole, rendendoli più efficienti in termini di costi.

B. Il Livello Elemento ha Benefici Condizionati

• Aggiungere informazioni sugli elementi (funzioni/classi) aiuta, ma il beneficio dipende fortemente dalla qualità del contesto a livello file.
• Il recupero semantico basato su LLM per gli elementi supera l'approccio strutturale basato su Call Graph.
• L'espansione oltre gli elementi "buggy" offre guadagni limitati e variabili; il miglior risultato si ottiene combinando un contesto semantico ampio a livello di elemento con una localizzazione precisa a livello di riga.

C. Il Livello Riga è Critico (Spesso Dannoso)

• Risultato Sorprendente: Espandere il contesto a livello di riga (aggiungendo finestre di contesto o slicing) spesso degrada le prestazioni.
• Le configurazioni con solo le righe "buggy" (o senza specifiche righe) spesso performano meglio di quelle con finestre di contesto o slicing statico.
• Motivo: A livello di riga, il compito dell'LLM passa dalla "comprensione" (dove serve contesto ampio) alla "modifica precisa". Aggiungere righe circostanti introduce rumore (codice irrilevante, gestione errori, logging) che diluisce il segnale del bug.
• L'unica eccezione è il recupero di righe basato su LLM, che performa meglio delle euristiche strutturali, ma comunque non supera sistematicamente l'uso preciso delle sole righe "buggy".

D. La Strategia Ottimale: Ibridazione

La configurazione migliore in assoluto (63.4% di risoluzione) combina:

1. Contesto ampio e semantico a livello di File (recuperato da LLM).
2. Contesto semantico a livello di Elemento (recuperato da LLM).
3. Localizzazione precisa e minima a livello di Riga (solo le righe "buggy" ground-truth).

Questo dimostra che la qualità del contesto supera la quantità: serve un'ampia comprensione semantica ad alto livello, ma una localizzazione chirurgica a basso livello.

4. Analisi Qualitativa

L'analisi dei casi di successo e fallimento ha rivelato pattern specifici:

• Contesto Eccessivo (Fallimento): Quando il contesto è troppo ampio, l'LLM tende a generalizzare eccessivamente, modificando file non correlati o proponendo rifattorizzazioni architetturali non necessarie invece di fix localizzati.
• Interferenza Irrilevante: Codice semanticamente correlato ma non causale può distorcere il ragionamento del modello (es. far pensare a un problema di tipo invece che a un errore di logica).
• Dipendenze Transversali (Successo): Per bug complessi che coinvolgono più moduli, un contesto file/elemento espanso è essenziale per comprendere le dipendenze incrociate.

5. Significato e Implicazioni Pratiche

Questo lavoro fornisce linee guida concrete per la progettazione di sistemi APR basati su LLM:

1. Priorità al Livello File: Investire risorse nella localizzazione accurata dei file è il fattore più critico. Usare il recupero basato su LLM è superiore ed economico rispetto alle euristiche strutturali.
2. Minimizzare il Contesto a Livello Riga: Evitare di espandere il contesto con finestre fisse o slicing statico. Se le righe esatte sono note, usarle; se non lo sono, è spesso meglio non fornire contesto a livello di riga piuttosto che fornire contesto rumoroso.
3. Strategie Adattive o Ensemble: Poiché nessun singolo contesto funziona per tutti i bug, i futuri sistemi APR dovrebbero adottare strategie adattive che variano la granularità del contesto in base alla complessità del bug (es. contesto ampio per bug cross-modulo, contesto ristretto per bug isolati).
4. Ridefinizione della Localizzazione: La localizzazione non deve essere vista solo come "trovare la riga sbagliata", ma come un processo gerarchico che bilancia la comprensione semantica (file/elementi) con la precisione chirurgica (righe).

In sintesi, il paper dimostra che l'espansione uniforme del contesto non migliora le prestazioni. L'approccio vincente è una combinazione complementare: comprensione semantica ampia ai livelli superiori e localizzazione precisa e minimale al livello inferiore.