Code Roulette: How Prompt Variability Affects LLM Code Generation

Il paper propone una pipeline di valutazione agnostica per misurare la sensibilità dei modelli linguistici di grandi dimensioni alle variazioni dei prompt nella generazione di codice, fornendo evidenze sperimentali e strumenti open source per la comunità.

L'essenziale

🎰 La Roulette del Codice: Quando un piccolo errore cambia tutto

Immagina di avere un cuoco robot super intelligente (una Intelligenza Artificiale) che sa cucinare qualsiasi piatto, dal semplice caffè a un banchetto di gala. Il problema è che questo robot non legge i tuoi pensieri, ma solo quello che scrivi su un foglio di carta (il "prompt").

Se scrivi "Fammi un caffè", il robot potrebbe farti un espresso perfetto. Ma se per sbaglio scrivi "Fammi un cffé" (con un errore di battitura) o usi parole diverse come "Preparami una tazza di caffè nero", il robot potrebbe:

1. Farti un caffè perfetto comunque.
2. Farti un tè.
3. Farti un caffè con la sabbia.
4. Non capire nulla e dirti che non sa cucinare.

Gli autori di questo studio (dall'Università di Cambridge) si sono chiesti: quanto è fragile questo cuoco robot? Se cambiamo leggermente le parole, la ricetta che ci dà cambia drasticamente o rimane la stessa?

Hanno chiamato il loro esperimento "Code Roulette" (Roulette del Codice), perché inserire un prompt è come girare la ruota: non sai mai esattamente quale versione del codice uscirà fuori.

🧪 Cosa hanno fatto? (Il Laboratorio di Cucina)

Per testare la stabilità di questi robot, hanno creato un esperimento in tre fasi, usando quattro modelli di intelligenza artificiale famosi (come GPT-4, Claude, Gemini e Llama).

Hanno preso delle richieste di codice (es. "Scrivi un programma che calcola le tasse") e le hanno modificate in tre modi diversi, come se stessero "rovinando" leggermente la ricetta:

1. Errori di Battitura (Typos): Come se qualcuno avesse le dita lunghe e premesse il tasto sbagliato sulla tastiera (es. scrivere "q" invece di "w").
   • Risultato: Disastro. Anche un piccolo errore ha fatto cambiare completamente il codice prodotto. È come se il robot pensasse: "Ah, hai scritto 'caffè' invece di 'caffè', quindi ti faccio un tè verde!".
2. Sinonimi: Sostituire le parole con altre che significano la stessa cosa (es. "Crea" invece di "Fai").
   • Risultato: Meno male. I robot sono stati più bravi a capire che il significato era lo stesso, anche se le parole cambiavano.
3. Riformulazione (Paraphrasing): Riscrivere l'intera frase in modo diverso ma con lo stesso senso (es. "Ho bisogno di un programma per le tasse" invece di "Calcola le tasse").
   • Risultato: Buono. I robot hanno mantenuto il codice abbastanza stabile, anche se non perfetto.

📉 I Risultati Sorprendenti

Ecco cosa hanno scoperto, usando delle metafore:

• La fragilità degli errori: Se sbagli anche solo una lettera (un "typos"), il codice prodotto diventa quasi irriconoscibile rispetto all'originale. È come se un piccolo graffio sulla ricetta facesse bruciare tutto il piatto.
• Il problema dei "Piatto Fatti" (Data Contamination): Hanno notato che se chiedevano al robot di fare un esercizio di programmazione molto famoso e vecchio (tipo quelli che si trovano su siti di allenamento per programmatori), il robot era super stabile. Non importava quanto cambiavi il prompt, lui produceva sempre lo stesso codice.
  • Perché? Perché il robot ha "imparato a memoria" quella ricetta durante i suoi studi! È come se chiedessi a un cuoco di fare la pizza Margherita: anche se chiedi "pizza con pomodoro e mozzarella" o "pizza rossa e bianca", lui sa già esattamente cosa fare perché l'ha fatta mille volte.
  • Il rischio: Se usiamo solo esercizi vecchi per testare l'IA, pensiamo che sia bravissima e sicura. Ma se le chiediamo qualcosa di nuovo (un esercizio che non ha mai visto), diventa molto più nervosa e cambia il codice per ogni piccola variazione.
• Non tutti i robot sono uguali: Alcuni modelli (come Gemini) erano più "testardi" e mantenevano il codice simile anche quando cambiavi le parole. Altri (come Llama) erano più "capricciosi" e cambiavano tutto anche per piccole modifiche.

🤔 Perché dovremmo preoccuparci?

Immagina di essere un architetto che usa questo robot per disegnare case.

• Se scrivi "Fai una casa con 3 stanze" e il robot disegna una villa.
• Se scrivi "Costruisci un'abitazione con tre locali" (stesso significato!) e il robot disegna un capannone industriale.

Questo è un problema enorme per la fiducia. Se il codice cambia solo perché hai usato parole diverse, come puoi fidarti di affidare a un'IA la creazione di software importanti? Potresti avere bug nascosti o codice difficile da mantenere solo perché hai scritto la richiesta in modo leggermente diverso.

💡 La Conclusione in Pillole

1. Le IA sono sensibili: Cambiare anche una sola lettera o una parola nel prompt può cambiare drasticamente il codice che producono.
2. Attenzione ai test vecchi: Se testiamo le IA con esercizi che hanno già visto, sembrano geni. Se usiamo esercizi nuovi e originali, vediamo che sono molto più fragili di quanto pensiamo.
3. Serve più cautela: Non possiamo trattare queste IA come se fossero umani infallibili. Dobbiamo capire che sono sensibili alle sfumature del linguaggio.

In sintesi, gli autori ci dicono: "Non date per scontato che l'IA capisca tutto. Se cambiate le parole, cambiate anche il risultato. Usate la testa e controllate sempre il lavoro!"

Sommario tecnico

Titolo

Code Roulette: Come la Variabilità dei Prompt Influenza la Generazione di Codice da parte dei LLM

1. Il Problema

La generazione di codice tramite Modelli Linguistici su Larga Scala (LLM) è diventata un'applicazione diffusa, capace di abbattere le barriere all'ingresso nello sviluppo software. Tuttavia, la qualità e la funzionalità del codice generato dipendono criticamente dalla qualità del prompt fornito dall'utente.
Il problema centrale affrontato dagli autori è la sensibilità dei LLM alle variazioni nel prompt. Gli utenti, a seconda del loro background, esperienza e modelli mentali, formulano richieste per lo stesso compito in modi diversi (sinonimi, parafrasi, errori di battitura). Se un LLM produce codice drasticamente diverso (o errato) a fronte di piccole variazioni semantiche o sintattiche nel prompt, ciò mina la fiducia nel processo, complica la manutenzione e rende difficile standardizzare l'output. Attualmente, mancano pipeline di valutazione robuste e indipendenti dal task specifico per quantificare questa sensibilità.

2. Metodologia

Gli autori propongono una pipeline di valutazione agnostica rispetto al modello e al task specifico, progettata per misurare sistematicamente la sensibilità del codice generato rispetto alle perturbazioni del prompt.

• Definizione del Processo:

  • Si definisce una funzione di augmentazione $F$ che modifica un prompt $p$ con un tasso di perturbazione $r \in [0, 1]$.
  • Si definisce una funzione di distanza $D$ che quantifica la dissimilarità tra due snippet di codice.
  • Il processo genera un set di riferimento di codice (dal prompt originale) e set di codice perturbato (a vari livelli di $r$), calcolando poi la distanza media tra le uscite.

• Metodi di Augmentazione del Prompt:
  Sono stati utilizzati tre metodi per simulare variazioni realistiche:

  1. Errori di battitura (Keyboard Typos): Sostituzione casuale di caratteri con tasti adiacenti sulla tastiera QWERTY.
  2. Sinonimi: Sostituzione casuale di parole con i loro sinonimi (basati su WordNet).
  3. Parafrasi: Riscrittura del prompt utilizzando le capacità di traduzione/parafrasi di un LLM (Gemini) per mantenere il significato semantico ma variare il lessico.

• Metriche di Valutazione:

  • TSED (Tree Similarity of Edit Distance): La metrica principale scelta per misurare la distanza tra i frammenti di codice. TSED opera sull'albero sintattico (AST) e misura le differenze strutturali, non la correttezza funzionale o la similarità semantica del testo. Gli autori scelgono TSED perché metriche testuali generiche come BLEU o BERT Score mostrano un "effetto soffitto" (valori troppo alti, scarsa discriminazione) e costi computazionali elevati quando applicati al codice.
  • Dataset: Sono stati utilizzati tre dataset:
    1. LeetCode (Old): 20 task classici (probabilmente presenti nei dati di addestramento, soggetti a "contaminazione").
    2. LeetCode (New): 20 task pubblicati nel marzo 2025 (non presenti nei dati di addestramento).
    3. Our Dataset: 22 task originali creati dagli autori, aperti e non strutturati come esercizi di programmazione competitivi standard.

• Modelli Testati: GPT-4o mini, Claude 3 Haiku, Gemini 2.0 Flash, Llama 3.3 70B. Tutti con temperatura impostata a 0 per ridurre la stocasticità intrinseca.

3. Contributi Chiave

1. Procedura di Valutazione: Introduzione di un framework sistematico per misurare la sensibilità dei LLM alla variabilità dei prompt, indipendente dal task specifico.
2. Analisi Comparativa: Una valutazione estesa della sensibilità su quattro modelli LLM popolari e tre dataset distinti.
3. Risorsa Open Source: Pubblicazione del codice e del dataset di task originali per permettere alla comunità di replicare e estendere il lavoro.
4. Identificazione della Contaminazione: Dimostrazione empirica di come la contaminazione dei dati di addestramento influenzi la robustezza dei modelli.

4. Risultati Sperimentali

• Impatto dei Tipi di Perturbazione:
  • Errori di battitura (Typos): Hanno l'effetto più devastante. La similarità del codice crolla rapidamente (fino a un TSED di ~0.3) già con un tasso di perturbazione basso (0.0 - 0.6). Questo indica che i modelli sono molto fragili a errori sintattici minori.
  • Sinonimi e Parafrasi: I modelli mostrano una robustezza significativamente maggiore. La similarità del codice diminuisce gradualmente e rimane più alta rispetto ai casi di errori di battitura. Gemini 2.0 Flash si è dimostrato il più resiliente alle variazioni di sinonimi.
• Influenza del Dataset (Contaminazione dei Dati):
  • LeetCode (Old): I modelli mostrano la minima sensibilità (alta stabilità) su questo dataset, confermando che i task sono probabilmente memorizzati nei dati di addestramento.
  • LeetCode (New): La sensibilità aumenta, ma i modelli mantengono una certa stabilità finché non viene alterato oltre il 50% del prompt.
  • Our Dataset (Task Originali): Qui si osserva la massima instabilità. Anche per prompt non alterati, la similarità tra le uscite è bassa (0.7). Inoltre, la similarità del codice scende sotto 0.5 dopo solo il 10% di modifica del prompt, suggerendo che i modelli sono estremamente sensibili quando non riconoscono il pattern del task.
• Stabilità Intrinseca: GPT-4o mini e Gemini 2.0 Flash mostrano una stabilità eccezionale (similitudine 0.9) su prompt non alterati, mentre Llama 3.3 e Claude 3 Haiku mostrano una maggiore variabilità anche a temperatura 0.

5. Significato e Implicazioni

Il paper sottolinea che la variabilità del prompt non è un dettaglio minore, ma un fattore critico per l'affidabilità degli LLM nella generazione di codice.

• Fiducia e Sicurezza: La sensibilità alle piccole variazioni (come errori di battitura) suggerisce che gli utenti potrebbero ottenere implementazioni radicalmente diverse per la stessa richiesta, complicando il debugging e la manutenzione.
• Progettazione di Pipeline: Gli sviluppatori di strumenti basati su LLM dovrebbero considerare tecniche di regolarizzazione (es. generazione multipla e media) o interazioni guidate (domande di follow-up) per mitigare questa sensibilità.
• Valutazione Futura: È fondamentale utilizzare dataset freschi e non contaminati per valutare le capacità reali dei modelli, poiché i benchmark tradizionali (come LeetCode classico) potrebbero sovrastimare la robustezza.
• Direzioni Future: Gli autori suggeriscono di estendere questo lavoro a dialoghi multi-turno, test funzionali (per distinguere diversità benigna da instabilità problematica) e studi con utenti reali di diversi livelli di esperienza.

In sintesi, "Code Roulette" evidenzia che la generazione di codice con LLM è intrinsecamente instabile rispetto alle variazioni del prompt, specialmente in scenari realistici e non contaminati, e propone strumenti per misurare e comprendere questa fragilità.