Helping LLMs Improve Code Generation Using Feedback from Testing and Static Analysis

Questo studio presenta un framework che utilizza test e analisi statica per valutare e guidare l'auto-miglioramento di modelli linguistici open-source nella generazione di codice C, dimostrando che, sebbene tali modelli producano spesso codice insicuro e abbiano difficoltà a rilevare errori, riescono a correggere efficacemente il codice quando forniti di feedback specifici.

L'essenziale

Immagina di assumere un giovane apprendista programmatore molto intelligente, che ha letto milioni di libri e sa parlare fluentemente, ma che non ha mai messo davvero mano a un computer per costruire qualcosa di solido. Questo è ciò che sono i LLM (i grandi modelli linguistici come Llama o Gemma) quando proviamo a farli scrivere codice.

La ricerca di Greta Dolcetti e colleghi si chiede: "Quanto è affidabile questo apprendista? Se sbaglia, sa accorgersene da solo? E se gli diciamo dove ha sbagliato, riesce a sistemare il lavoro?"

Ecco la spiegazione della loro ricerca, divisa in tre atti, con qualche metafora per chiarire i concetti.

1. L'Apprendista al Lavoro (Generazione del Codice)

I ricercatori hanno dato all'apprendista (il modello AI) 100 piccoli compiti, tipo "scrivi una funzione che ordina una lista di numeri", ma in un linguaggio difficile come il C (che è come costruire una casa con i mattoni: se sbagli un mattone, tutto crolla).

• Il Risultato: L'apprendista è stato veloce, ma spesso disastroso.
  • Circa la metà dei suoi lavori non funzionava affatto (come se avesse scritto una ricetta per una torta ma dimenticato le uova).
  • Peggio ancora, molti lavori sembravano belli, ma avevano buchi nella sicurezza (come una porta di casa lasciata aperta o un cavo elettrico scoperto).
  • La sorpresa: Anche se il codice sembrava funzionare, spesso conteneva errori invisibili che solo un ispettore esperto avrebbe notato.

2. L'Ispettore e il Controllore (Auto-valutazione)

Qui arriva il punto cruciale. Hanno chiesto all'apprendista: "Guarda il tuo lavoro. Secondo te, è corretto? Ci sono pericoli?"

• Il Risultato: L'apprendista era molto sicuro di sé, ma molto sbagliato.
  • Quando il lavoro era pieno di buchi, lui diceva: "Tutto perfetto!".
  • Quando il lavoro era corretto, a volte diceva: "C'è un errore!".
  • La metafora: È come se un pittore che ha dipinto un quadro storto guardasse il suo lavoro e dicesse: "È un capolavoro", mentre un altro pittore guardasse un capolavoro e dicesse: "È storto".
  • Conclusione: L'AI non ha ancora una vera "coscienza" dei propri errori. Non sa distinguere il bene dal male quando guarda il proprio lavoro.

3. Il Riparatore con la Guida (Correzione)

Poi, i ricercatori hanno fatto un esperimento diverso. Non hanno chiesto all'apprendista di indovinare l'errore. Gli hanno detto: "Ehi, guarda qui: il static analyzer (un ispettore robotico chiamato Infer) ti ha detto che c'è un errore di memoria qui, e il test ha fallito lì. Riprova a sistemarlo."

• Il Risultato: Qui l'apprendista è diventato un genio!
  • Quando gli hanno dato una mappa precisa degli errori (i report dell'ispettore), l'AI è riuscita a riparare la maggior parte dei problemi.
  • Ha corretto circa il 60-90% dei difetti, a seconda del modello.
  • La metafora: È come se avessimo detto al meccanico: "Non devi indovinare dove si è rotta l'auto. Ti ho già detto che la ruota posteriore sinistra è sgonfia e il motore fa un rumore strano. Ora ripara." In questo caso, il meccanico lavora benissimo.

Le Scoperte Chiave (in parole povere)

1. L'AI scrive codice, ma spesso è "spazzatura" o pericolosa: Non possiamo fidarci ciecamente che il codice generato sia sicuro.
2. L'AI non si critica bene: Chiedere all'AI di controllare se stessa è inutile; è troppo sicura di sé e non vede i propri errori.
3. L'AI impara se le spieghi l'errore: Se usiamo strumenti automatici (come gli ispettori di sicurezza) per trovare gli errori e poi li mostriamo all'AI, lei riesce a correggerli molto bene.

La Soluzione Proposta: Il "Ciclo di Feedback"

I ricercatori propongono un metodo per rendere l'AI più sicura, che chiamiamo "Il Circolo Virtuoso":

1. L'AI scrive il codice.
2. Un ispettore automatico (Infer) e dei test controllano il codice e trovano gli errori.
3. L'AI riceve il rapporto dell'ispettore (non deve indovinare, deve solo leggere il rapporto).
4. L'AI ripara il codice basandosi su quel rapporto.
5. Si ripete finché il codice non è pulito.

Perché è importante?

Oggi molti programmatori usano l'AI per scrivere codice velocemente. Questo studio ci dice che non dobbiamo fidarci ciecamente. Dobbiamo usare l'AI come un "primo abbozzo", ma poi dobbiamo farla passare attraverso un "controllo qualità automatico" e darle le istruzioni precise per correggere gli errori.

Se facciamo così, possiamo trasformare un apprendista disattento in un maestro artigiano capace di produrre software sicuro e affidabile. È come avere un assistente che non sa ancora fare da solo, ma che, se gli dai gli strumenti giusti, diventa incredibilmente bravo a sistemare i guai.

Sommario tecnico

1. Problema e Contesto

L'adozione di Large Language Models (LLM) per la generazione di codice sta crescendo rapidamente, con previsioni che indicano che entro il 2027 il 50% degli ingegneri software farà affidamento su tali strumenti. Tuttavia, i modelli commerciali e open-source attuali presentano limiti significativi:

• Correttezza: Il codice generato spesso non soddisfa le specifiche o fallisce i test.
• Sicurezza: Il codice contiene vulnerabilità (es. gestione della memoria, buffer overflow) e "code smells".
• Auto-valutazione: Gli LLM mostrano una scarsa capacità di identificare i propri errori o le vulnerabilità nel codice che hanno generato.
• Riparazione: La capacità di correggere il codice in modo autonomo (senza feedback esterno) è limitata.

L'obiettivo del paper è valutare empiricamente la correttezza e la sicurezza del codice generato da LLM open-source e investigare se un ciclo di feedback basato su test e analisi statica possa migliorare la qualità del codice attraverso un processo di auto-riparazione iterativo.

2. Metodologia

Gli autori hanno proposto un framework automatizzato composto da tre fasi principali, applicato a quattro modelli LLM open-source di diverse dimensioni e architetture: Llama 3 (8B e 70B), Gemma 7B e Mixtral 8x7B.

A. Setup Sperimentale

• Dataset: Sono stati selezionati 100 task dal dataset MBPP (Mostly Basic Python Problems), riscritti manualmente in C per adattarli alla sintassi e alle strutture dati del linguaggio (es. sostituzione di array literals e operatori di confronto). Questo approccio mira a minimizzare il rischio di "memorizzazione" (memorization) dei task di addestramento originali.
• Fase 1: Generazione del Codice: Gli LLM generano codice C per risolvere i task. Il codice viene poi "pulito" automaticamente (rimozione di testo esplicativo, aggiunta di librerie mancanti, correzione di formattazione).
• Fase 2: Valutazione e Auto-Valutazione:
  • Correttezza: Il codice compilabile viene eseguito contro unit test di ground-truth.
  • Sicurezza: Viene utilizzata l'analisi statica Infer (di Meta) per rilevare vulnerabilità (es. dereferenziamento di puntatori nulli, memory leak, buffer overflow).
  • Auto-Valutazione: Gli LLM vengono interrogati per valutare la correttezza e la sicurezza del codice generato (sia dal proprio modello che dagli altri), senza sapere chi lo ha generato.
• Fase 3: Riparazione (Repair): Gli LLM ricevono il codice difettoso insieme ai report di errore (fallimento dei test o segnalazioni di Infer) e vengono invitati a correggerlo. Questo processo è iterativo (fino a 6 iterazioni) per ogni errore rilevato.

B. Strumenti e Prompt Engineering

• Compilatore: Clang 15.0.0.
• Analizzatore Statico: Infer (con checkers specifici come bufferoverrun, linters, pulse).
• Prompt Engineering: Sono state testate diverse configurazioni di prompt (Vanilla, Esempi/Controesempi, Chain-of-Thought, Istruzioni specifiche). La configurazione migliore è stata selezionata per ogni fase.

3. Risultati Chiave

Generazione del Codice

• Compilazione: Dopo la pulizia, oltre il 93% del codice generato compila correttamente.
• Correttezza: Solo il 46% - 65% del codice generato supera tutti i test unitari. Il modello Llama 3 70B ottiene i migliori risultati (65%), mentre Gemma 7B il peggior (46%).
• Sicurezza: Secondo Infer, l'87% - 96% del codice non contiene vulnerabilità rilevate. Tuttavia, il modello Mixtral 8x7B genera un numero significativamente maggiore di file insicuri rispetto agli altri.
• Conclusione: Il codice generato è più propenso a essere funzionalmente errato che insicuro.

Auto-Valutazione (Self-Evaluation)

• Correttezza: Gli LLM hanno prestazioni molto scarse nell'identificare se il codice è corretto o meno (F1-score < 80%). Non emerge un fenomeno di "self-preference" (non preferiscono il proprio codice), ma mostrano tendenze distorte (es. Gemma risponde quasi sempre "Sì", Llama 8B quasi sempre "No").
• Sicurezza: La rilevazione delle vulnerabilità è estremamente bassa (F1-score < 0.3). I modelli falliscono nel riconoscere le vulnerabilità anche quando sono presenti nel codice da loro stesso generato.

Capacità di Riparazione

• Correttezza: Quando forniti con feedback sui test falliti, i modelli migliorano significativamente. Llama 3 70B riesce a riparare completamente il 62% dei file errati (96 su 155).
• Sicurezza: La riparazione delle vulnerabilità è molto efficace. I modelli migliori (Llama 3 70B e Mixtral 8x7B) riparano l'89% delle vulnerabilità (39 su 44).
• Auto-Preferenza nella Riparazione: Non c'è evidenza che un modello ripari meglio il proprio codice rispetto a quello degli altri; anzi, spesso riparano meglio il codice generato da modelli diversi (es. Llama 70B ripara meglio il codice di Gemma).

4. Contributi Principali

1. Framework di Valutazione Integrato: Un pipeline automatizzata che combina generazione, test dinamici, analisi statica (Infer) e riparazione iterativa guidata dal feedback.
2. Valutazione Empirica su LLM Open-Source: Analisi dettagliata di modelli recenti (Llama 3, Gemma, Mixtral) su task C, evidenziando che, sebbene generino codice compilabile, la correttezza funzionale rimane un collo di bottiglia.
3. Dimostrazione dell'Inefficacia dell'Auto-Valutazione: Prove concrete che gli LLM attuali non possiedono una "consapevolezza" affidabile della correttezza o sicurezza del proprio codice.
4. Efficacia del Feedback Esterno: Dimostrazione che l'approccio iterativo con feedback da test e analisi statica permette di riparare la maggior parte degli errori e delle vulnerabilità, superando i limiti della generazione zero-shot.
5. Dataset e Codice Aperti: Pubblicazione del benchmark adattato in C, degli script di valutazione e dei dati grezzi per la comunità di ricerca.

5. Significato e Implicazioni

Il lavoro sottolinea che, sebbene gli LLM siano potenti strumenti di produttività, non possono essere considerati autonomi per la generazione di codice sicuro e corretto in contesti critici.

• Necessità di Verifica: L'integrazione di strumenti di verifica formale e test automatizzati è obbligatoria nel ciclo di sviluppo assistito da AI.
• Potenziale del Feedback Loop: Il metodo proposto (generazione -> analisi -> feedback -> riparazione) rappresenta una via promettente per creare strumenti di sviluppo più sicuri, trasformando l'LLM da generatore statico a sistema iterativo di miglioramento.
• Futuri Sviluppi: Gli autori suggeriscono di estendere il framework ad altri linguaggi (es. Rust per la sicurezza della memoria, Python per la tipizzazione dinamica) e di integrare analisi ibride (statiche e dinamiche) per ridurre i falsi positivi/negativi.

In sintesi, il paper conclude che l'automazione completa della generazione di codice sicuro non è ancora matura, ma l'uso di pipeline di feedback guidate da strumenti di analisi tradizionali può colmare significativamente il divario di qualità.