💻 computer science

When Prompt Under-Specification Improves Code Correctness: An Exploratory Study of Prompt Wording and Structure Effects on LLM-Based Code Generation

Questo studio esplorativo rivela che, sebbene la sottodeterminazione del prompt degradi tipicamente la generazione di codice su benchmark strutturalmente minimi, può sorprendentemente migliorare la correttezza su compiti più ricchi come LiveCodeBench, interrompendo indizi fuorvianti, dimostrando così che la robustezza del prompt dipende fortemente dalla struttura del compito piuttosto che essere una proprietà fissa del modello.

Autori originali: Amal AKLI, Mike PAPADAKIS, Maxime CORDY, Yves Le TRAON

Pubblicato 2026-04-28

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Amal AKLI, Mike PAPADAKIS, Maxime CORDY, Yves Le TRAON

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di assumere un assistente brillante ma leggermente letterale per scrivere un programma informatico per te. Gli fornisci un insieme di istruzioni (un "prompt"). Per molto tempo, gli esperti hanno creduto che più le tue istruzioni fossero precise, dettagliate e rigorose, tanto meglio l'assistente avrebbe lavorato. Se lasciavi fuori un dettaglio, l'assistente si confondeva e falliva.

Questo articolo sfida quella vecchia convinzione. I ricercatori hanno scoperto che, a volte, dare al tuo assistente meno dettagli lo aiuta effettivamente a scrivere codice migliore.

Ecco come l'hanno scoperto, spiegato attraverso semplici analogie:

1. I Due Tipi di "Esami"

I ricercatori hanno testato questa idea su due diversi tipi di "esami" (benchmark) per i modelli di intelligenza artificiale:

L'Esame "Flashcard" (HumanEval): Questi sono come brevi flashcard di una sola frase. Le istruzioni sono molto concise, senza contesto aggiuntivo. È come chiedere: "Scrivi una funzione per ordinare questa lista".
L'Esame "Libro di Testo" (LiveCodeBench): Questi sono come capitoli completi di un libro di testo. Includono una lunga storia, un elenco di regole, esempi di input e output e vincoli specifici. È come dire: "Ecco una storia sull'ordinamento di una lista di nomi. Ecco le regole: i nomi non possono superare le 10 lettere, ed ecco un esempio di come appare l'input...".

2. L'Esperimento: "Rompere" le Istruzioni

I ricercatori hanno preso queste istruzioni e le hanno intenzionalmente "mutate" in tre modi per vedere cosa sarebbe successo:

Vaghezza (LV): Hanno sostituito parole specifiche con termini vaghi (ad esempio, cambiando "ordina" con "disponi").
Sottospecificazione (US): Hanno rimosso una regola o un vincolo specifico (ad esempio, eliminando una regola sulla grandezza dei numeri).
Formattazione Disordinata (SF): Hanno aggiunto errori di battitura o modificato gli spaziature.

3. I Risultati Sorprendenti

I risultati sono stati molto diversi a seconda di quale "esame" l'IA ha sostenuto:

Sull'Esame "Flashcard": Quando i ricercatori hanno rimosso dettagli o reso le parole vaghe, le prestazioni dell'IA sono crollate. Proprio come uno studente che va in panico quando un insegnante rimuove un indizio da un breve quiz, l'IA si è confusa e ha scritto codice rotto.
Sull'Esame "Libro di Testo": Quando hanno fatto la stessa cosa, le prestazioni dell'IA sono rimaste invariate o, sorprendentemente, migliorate.

L'Illusione del "Net Zero":
Inizialmente, i ricercatori pensavano che l'IA sull'esame "Libro di Testo" non si curasse semplicemente dei cambiamenti. Ma osservando più da vicino, hanno trovato una lotta di trazione.

Alcuni cambiamenti hanno fatto fallire l'IA (degrado).
Ma quasi lo stesso numero di cambiamenti ha fatto sì che l'IA riuscisse dove in precedenza aveva fallito (miglioramento).
Queste due forze si sono annullate a vicenda, facendo sembrare che non fosse successo nulla.

4. Perché "Meno" a volte Significa "Più"?

L'articolo ha trovato una ragione affascinante per cui rimuovere una regola a volte risolve il codice. Si tratta di cattive abitudini e "indizi".

Immagina che l'IA sia come uno studente che ha memorizzato le risposte da un libro di testo specifico.

La Trappola: A volte, una parola specifica o un numero specifico nel prompt agisce come un "grilletto". Ricorda all'IA una soluzione memorizzata che sembra giusta ma è in realtà sbagliata per questo problema specifico.
- Esempio dall'articolo: Un problema menzionava "Valuta". Questa parola ha innescato nell'IA il pensiero sui tassi di cambio finanziari, portandola a utilizzare un algoritmo di pensiero inverso.
La Soluzione: Quando i ricercatori hanno rimosso la parola "Valuta" e l'hanno sostituita con una parola vaga come "Risorsa", l'IA ha smesso di attivare la sua "memoria finanziaria". Invece, è stata costretta a pensare effettivamente alla struttura del problema da zero. Questo ha portato a una soluzione corretta.

In altre parole, i dettagli aggiuntivi nel prompt a volte hanno accidentalmente dato all'IA un "indizio" che l'ha portata sulla strada sbagliata. Rimuovere quell'indizio ha costretto l'IA a svolgere il lavoro correttamente.

5. La Conclusione Principale

L'articolo conclude che la robustezza non dipende dalle dimensioni dell'IA (che sia un modello piccolo o gigante); si tratta di come sono costruite le istruzioni.

Se dai all'IA un prompt breve e di una sola frase, è molto fragile. Se sbagli la formulazione, fallisce.
Se dai all'IA un prompt ricco e multilivello (con esempi, vincoli e formati), è molto più robusto. Ha "segnali di backup" su cui fare affidamento se una parte dell'istruzione è confusa.
Crucialmente: A volte, essere troppo specifici è una trappola. Parole o numeri specifici possono accidentalmente "preparare" l'IA a usare una scorciatoia memorizzata ma errata. Rimuovere quegli indizi specifici può a volte costringere l'IA a risolvere correttamente il problema.

In breve: Non dare per scontato che un prompt perfetto e dettagliato sia sempre il migliore. A volte, un prompt leggermente più vago costringe l'IA a pensare da sola, evitando le trappole delle sue stesse abitudini memorizzate.

1. Enunciato del Problema

Sebbene i Modelli Linguistici di Grandi Dimensioni (LLM) siano sempre più utilizzati per la generazione di codice, la correttezza del loro output è altamente sensibile alla formulazione del prompt. Ricerche precedenti hanno stabilito che la sotto-specificazione (requisiti mancanti o indeboliti) e le piccole perturbazioni del prompt degradano generalmente le prestazioni. Tuttavia, questi risultati sono derivati in larga misura da benchmark a specifica minima (ad esempio, HumanEval, MBPP) che presentano descrizioni brevi con una singola docstring e una ridondanza strutturale limitata.

Gli autori ipotizzano che tali benchmark esagerino la fragilità degli LLM. In scenari reali, i compiti includono spesso specifiche ricche e multilivello (descrizioni, vincoli, formati di I/O, esempi). Il documento indaga se gli effetti negativi della sotto-specificazione persistano in ambienti strutturalmente ricchi e se, controintuitivamente, la rimozione di elementi specifici del prompt possa effettivamente migliorare la correttezza del codice interrompendo gli indizi di recupero fuorvianti.

2. Metodologia

Benchmark

Lo studio confronta due benchmark con proprietà strutturali distinte:

HumanEval (HE): 164 problemi Python semplici con docstring brevi. Manca di vincoli separati, I/O strutturato o esempi. Rappresenta la "specificazione minima".
LiveCodeBench (LCB): 1.055 problemi di programmazione competitiva (LeetCode, Codeforces, AtCoder) con descrizioni in prosa completa, vincoli espliciti, molteplici coppie di esempi di I/O e specifiche di formato. Rappresenta la "specificazione ricca".

Modelli

Lo studio valuta 10 LLM in tre categorie:

Open-Source Piccoli (6–7B): CodeLlama-7B, DeepSeek-Coder-6.7B, Qwen2.5-Coder-7B.
Open-Source Grandi (15–34B): StarCoder2-15B, Codestral-22B, CodeLlama-34B, DeepSeek-Coder-33B, Qwen2.5-Coder-32B.
Proprietari/Ragionamento: GPT-5-mini, Claude Sonnet 4.

Mutazioni del Prompt

Gli autori hanno generato sistematicamente 3.651 prompt mutati utilizzando tre tipi di trasformazione:

Vaghezza Lessicale (LV): Sostituzione di termini/identificatori precisi con sinonimi più ampi (es. "sort" $\to$ "arrange", delimiter $\to$ filler).
Sotto-specificazione (US): Rimozione di un singolo vincolo esplicito (es. limiti di valore, regole di ordinamento, descrizioni di casi limite) mantenendo il prompt grammaticalmente valido.
Sintassi e Formattazione (SF): Introduzione di rumore a livello superficiale (errori di battitura, errori di indentazione, problemi di delimitatori) senza alterare la semantica.

Metriche di Valutazione

Pass@1: La metrica principale per la correttezza.
Analisi delle Transizioni: Tracciamento delle transizioni Pass $\to$ Fail (degradazione) e Fail $\to$ Pass (miglioramento) per distinguere tra degradazione uniforme e forze opposte.
Analisi dell'Attenzione: Esame dei pattern di attenzione del modello per comprendere quali regioni del prompt guidano le decisioni.
Analisi delle Cause Radice: Ispezione manuale dei casi in cui le mutazioni hanno migliorato la correttezza per identificare i meccanismi linguistici.

3. Contributi e Risultati Chiave

Risultato 1: La Robustezza è Strutturale, non Architettonica

HumanEval: Tutti i tipi di mutazione hanno causato cali significativi delle prestazioni (es. le mutazioni US hanno causato un calo medio del -11,8%).
LiveCodeBench: Le stesse mutazioni hanno avuto un impatto netto quasi nullo (es. le mutazioni US hanno causato un calo solo del -0,9%).
Conclusione: La robustezza non è una proprietà intrinseca della dimensione o dell'architettura del modello. È governata dalla struttura del prompt. Le specifiche ricche forniscono ridondanza (vincoli, esempi, I/O) che agiscono come segnali di riserva quando parti del prompt sono degradate. Le mappe di attenzione confermano che i modelli su LCB fanno affidamento pesantemente su questi componenti ausiliari, mentre i modelli su HE fanno affidamento quasi esclusivamente sulla descrizione.

Risultato 2: La Sotto-specificazione può Migliorare la Correttezza

Contrariamente all'assunto che "più specificazione sia sempre meglio", lo studio ha rilevato che la sotto-specificazione spesso migliora la correttezza del codice su LCB.

Su LCB, il rapporto tra transizioni Fail $\to$ Pass e Pass $\to$ Fail è stato quasi 1:1 (0,99) per le mutazioni LV, il che significa che i miglioramenti hanno compensato le degradazioni.
Su HumanEval, le degradazioni hanno dominato pesantemente (Rapporto 0,40).
Miglioramenti Costanti: Lo studio ha identificato 47 specifici task LCB in cui la rimozione di vincoli o vaghezze ha costantemente migliorato i tassi di successo su più modelli.

Risultato 3: Meccanismi di Miglioramento (Interruzione degli Indizi di Recupero)

L'analisi manuale ha rivelato che i prompt originali contengono spesso "indizi di recupero" che ancorano i modelli a soluzioni memorizzate ma errate. La sotto-specificazione interrompe questi indizi, costringendo il modello a ragionare sulla struttura del problema.

Vaghezza Lessicale (LV):
- Ridenominazione delle Variabili: Rottura delle associazioni sovraindossate (es. rinominare s in seq previene il recupero di un algoritmo sbagliato specifico).
- Generalizzazione della Terminologia: Sostituzione di sostantivi specifici del dominio (es. "valuta") con termini generici (es. "risorsa") previene l'applicazione da parte del modello di euristiche specifiche del dominio (come scansioni finanziarie all'indietro) e incoraggia un ragionamento algoritmico generale (come la programmazione dinamica in avanti).
Sotto-specificazione (US):
- Rimozione dei Vincoli: Vincoli specifici (es. $C_i \le 10^9$ ) spesso predispongono i modelli a utilizzare scorciatoie ottimizzate (es. formule per il diametro di grafi a stella) che falliscono su casi generali. Rimuovere il vincolo costringe il modello a utilizzare un algoritmo generale e corretto (es. due-BFS).
- Priming I/O: I vincoli a volte innescano pattern di parsing degli input errati (es. input().split() stile LeetCode vs formati stdin della programmazione competitiva). Rimuoverli forza un parsing corretto.

4. Significato e Implicazioni

Rivalutazione dei Benchmark: I benchmark minimi come HumanEval potrebbero sovrastimare la fragilità degli LLM perché mancano della ridondanza presente nei compiti reali. Non riescono a catturare l'"effetto di cancellazione" in cui la ricchezza strutturale mitiga gli errori del prompt.
Ingegneria del Prompt: Lo studio sfida il dogma secondo cui i prompt devono essere massimamente precisi. In alcuni casi, la sovraspecificazione (inclusione specifica di vincoli fuorvianti o identificatori specifici del dominio) inganna silenziosamente i modelli. I praticanti dovrebbero essere consapevoli che la rimozione di certi indizi può talvolta produrre risultati migliori.
Sviluppo dei Modelli: La sensibilità agli indizi di recupero indica un divario di generalizzazione che la sola scala del modello non risolve. Anche i modelli di ragionamento all'avanguardia (GPT-5, Claude) cadono preda di questi indizi, suggerendo la necessità di strategie di addestramento che diano priorità al ragionamento strutturale rispetto alla corrispondenza di pattern.
Ricerca Futura: Il documento invita a creare benchmark che riflettano la ricchezza strutturale dello sviluppo reale e incoraggia l'indagine sui trigger linguistici specifici che causano fallimenti basati sul recupero.

Riepilogo

Questo studio esplorativo dimostra che l'impatto della sotto-specificazione del prompt non è uniforme. Sebbene degradi le prestazioni su benchmark minimi, le specifiche ricche nei compiti reali forniscono ridondanza che neutralizza questi effetti. Sorprendentemente, la sotto-specificazione può migliorare la correttezza del codice interrompendo gli indizi di recupero fuorvianti che causano ai modelli di affidarsi a pattern memorizzati e errati. Gli autori concludono che la robustezza è una funzione della struttura del prompt e che "meno è più" in contesti specifici in cui la precisione innesca l'overfitting.