Self-critique, self-consistency, rephrase

Un modello può produrre una risposta e poi valutarla con criteri espliciti. Questa tecnica non sostituisce review umana, test o validazione, ma aiuta a intercettare problemi prima che arrivino al diff o alla produzione.

Perché questa lezione conta

La prima risposta di un LLM è spesso plausibile, non necessariamente robusta. Chiedere una seconda fase di critica può far emergere assunzioni, casi limite, incoerenze e violazioni del formato.

Il punto è non chiedere “controlla se è giusto” in modo vago. Devi fornire una rubrica di critica.

Self-critique

Self-critique significa far rivedere al modello il proprio output.

Prompt debole:

Controlla la tua risposta.

Prompt operativo:

Rivedi la soluzione appena proposta usando questi criteri:
1. correttezza del comportamento;
2. casi limite non coperti;
3. sicurezza su input non fidato;
4. rispetto del formato richiesto;
5. modifiche fuori scope.

Restituisci solo problemi che cambierebbero la soluzione.

La rubrica impedisce al modello di fare una critica cosmetica.

Self-consistency

Self-consistency consiste nel generare più risposte indipendenti e confrontarle. È utile quando il task ha una risposta corretta ma il percorso può variare: diagnosi, classificazioni ambigue, calcoli, decisioni con indizi incompleti.

Esempio:

Genera tre ipotesi indipendenti sul bug.
Poi confrontale e scegli quella più coerente con i log.
Non sommare ipotesi: se mancano dati, dichiaralo.

Attenzione: tre risposte simili non garantiscono verità. Possono condividere la stessa assunzione sbagliata. Serve comunque verifica esterna.

Rephrase

Rephrase significa chiedere al modello di riformulare la richiesta prima di rispondere. È utile quando il task è ambiguo.

Prima di rispondere, riformula il task in massimo 5 righe.
Elenca le assunzioni che stai facendo.
Se ci sono ambiguità bloccanti, fermati e chiedi chiarimento.

Questa tecnica espone fraintendimenti prima che diventino codice.

Quando usare queste tecniche

Tecnica	Quando usarla	Rischio
Self-critique	output complesso da rivedere	critica superficiale se mancano criteri
Self-consistency	diagnosi o classificazione ambigua	accordo apparente su assunzione sbagliata
Rephrase	task lungo o ambiguo	rallenta task semplici

Laboratorio guidato

Scegli un task di code review o debug. Esegui:

1. prompt normale;
2. prompt con fase di rephrase;
3. prompt con generazione + self-critique;
4. prompt con due alternative e confronto.

Valuta:

• quali errori vengono intercettati;
• quanta verbosità viene aggiunta;
• quali problemi restano invisibili;
• quali criteri di critica funzionano meglio.

Output atteso

Una procedura a due o tre passi per task ad alta criticità.

Esempio:

Fase 1: riformula task e assunzioni.
Fase 2: produci soluzione.
Fase 3: critica con rubrica: correttezza, sicurezza, casi limite, formato.
Fase 4: applica solo correzioni motivate.

Checklist di verifica

• la critica usa criteri espliciti;
• la fase di revisione può cambiare davvero la soluzione;
• non uso self-critique per evitare test o review;
• so quando fermarmi per non entrare in loop;
• salvo la procedura per task rischiosi ricorrenti.

Errori comuni

Chiedere una critica senza rubrica. Il modello tenderà a confermare o a fare osservazioni generiche.

Accettare la maggioranza come verità. Self-consistency aumenta confidenza, non garantisce correttezza.

Iterare all’infinito. Dopo due o tre passaggi, serve verifica esterna.

Collegamenti

• Modulo: Tecniche di prompting — lezione 13 del corso.
• Lezione precedente: Chain-of-thought e ragionamento esplicito.
• Prossima lezione: Decomposizione: catene di prompt e prompt chaining.