Few-shot, esempi negativi e controesempi

Un esempio vale dieci spiegazioni. Quando descrivi a parole “voglio uno stile pulito”, il modello indovina cosa intendi. Quando mostri due esempi prima e due esempi dopo, il modello vede esattamente cosa cercare. Few-shot prompting è la tecnica più sottovalutata: economica, efficace, applicabile ovunque.

Perché questa lezione conta

I modelli moderni sono pattern matcher addestrati su enormi quantità di testo. Quando dai pattern espliciti nell’input, il modello li replica meglio di qualunque istruzione testuale. Few-shot non sostituisce il prompt strutturato: lo completa nei punti dove “stile”, “tono”, “convenzioni” sono difficili da scrivere a parole.

Obiettivo operativo

Alla fine devi saper:

1. distinguere esempio positivo, esempio negativo, controesempio;
2. costruire un prompt few-shot per stile/format/tono;
3. capire quando aggiungere esempi e quando non serve.

Nucleo della lezione

1. Tre tipi di esempio

Positivo (few-shot classico): “ecco come voglio che siano”. Mostri 2-4 esempi del risultato target. Il modello inferisce pattern e replica.

Caso d’uso: stile commit message, tono microcopy, formato JSON, struttura di componenti, naming convention.

Negativo: “ecco come NON voglio”. Mostri esempi da evitare e spieghi perché.

Caso d’uso: errori ricorrenti del modello, anti-pattern del progetto, scelte già scartate.

Controesempio (edge case): “ecco un caso difficile gestito correttamente”. Mostri input atipico + output atteso. Il modello impara a non solo replicare il pattern ma a estenderlo a casi non ovvi.

Caso d’uso: gestione errori, input vuoti, valori limite, comportamenti non standard.

I tre si combinano. Un prompt forte ha 2-3 positivi + 1 negativo + 1 controesempio.

2. Quando few-shot è efficace

Casi dove vale la pena:

• Stile soggettivo: tono microcopy, scrittura commit, formato comment di codice. Difficile da definire a parole.
• Convenzioni specifiche del progetto: naming, struttura componenti, architettura. Il modello non le conosce per default.
• Output ripetitivo: stessa struttura ripetuta per molti elementi. Esempio + “fai lo stesso per X, Y, Z”.
• Gestione casi limite: edge case che il modello tende a saltare. Mostrare input limite + output atteso.

Casi dove non aiuta:

• Logica complessa: few-shot non sostituisce ragionamento. Per task con dipendenze logiche, serve descrizione + piano, non esempi.
• Domini non visti: se il modello non ha visto esempi simili nel training, few-shot di 2 elementi non basta.
• Esempi contraddittori: due esempi positivi che mostrano pattern diversi confondono.

3. Costruire un prompt few-shot

Schema:

Task: [descrizione]

Esempi:

ESEMPIO 1
Input: ...
Output: ...

ESEMPIO 2
Input: ...
Output: ...

CONTROESEMPIO (caso difficile)
Input: ...
Output: ...

DA EVITARE
Output sbagliato: ...
Motivo: ...

Ora il tuo turno:
Input: [input reale]
Output:

Quattro esempi totali. Più di 5-6 spesso peggiora: il modello si fissa su dettagli irrilevanti o l’output diventa troppo lungo.

Esempio guidato: microcopy di errore

Immagina di voler generare messaggi di errore per una form. Prompt vago:

Scrivi messaggi di errore chiari e professionali.

Risultato probabile: frasi generiche come “Si è verificato un errore” o “Input non valido”. Non sono abbastanza utili. Con few-shot, invece, mostri lo stile.

Voglio messaggi brevi, specifici, non colpevolizzanti.

ESEMPIO POSITIVO 1
Campo: email vuota
Messaggio: Inserisci un indirizzo email.
Motivo: dice cosa manca, senza tono burocratico.

ESEMPIO POSITIVO 2
Campo: password troppo corta
Messaggio: Usa almeno 8 caratteri.
Motivo: indica la correzione concreta.

CONTROESEMPIO
Campo: nome con solo spazi
Messaggio: Inserisci un nome leggibile.
Motivo: non dice "campo invalido", spiega il problema reale.

DA EVITARE
Messaggio: Errore: valore non conforme.
Motivo: freddo, generico, non aiuta l'utente.

Ora scrivi messaggi per:
- telefono non valido
- data nel passato
- file troppo grande

Output migliore:

• “Inserisci un numero con prefisso.”
• “Scegli una data futura.”
• “Carica un file sotto i 5 MB.”

Il few-shot funziona perché rende visibile il criterio: breve, azionabile, umano. Non stai chiedendo al modello di essere “professionale”; gli stai mostrando cosa significa nel tuo progetto.

Procedura pratica

Per task con stile/format soggettivo:

1. Scrivi 2 esempi target a mano. 30 minuti, una volta. Salvali.
2. Scrivi 1 esempio “errore tipico” del modello con motivo dell’errore.
3. Scrivi 1 controesempio (caso limite gestito bene).
4. Inserisci nel prompt prima della richiesta vera.
5. Riusa: gli esempi sono asset, non monouso.

Tempo iniziale: alto. Tempo per richieste successive: zero (basta riusare). ROI dopo 5 richieste è già netto.

Laboratorio guidato

Caso reale: vuoi commit message in stile Conventional Commits con tono italiano e descrizione del “perché”, non del “cosa”.

Senza few-shot: prompt “scrivi commit message per [diff]”. Output probabile: generico inglese, descrive il cosa.

Con few-shot:

Stile commit message per questo progetto: Conventional Commits, italiano, descrive il PERCHÉ.

ESEMPIO 1
Diff: aggiunta validazione email lato server
Commit: feat(auth): valida email server-side per ridurre rischio bypass client

ESEMPIO 2
Diff: rimossa libreria moment.js, sostituita con date-fns
Commit: refactor(deps): sostituisci moment con date-fns per ridurre bundle 20kb

CONTROESEMPIO (cambio piccolo, tono comunque sostanziale)
Diff: rinominata variabile `data` in `userInput` in form contatto
Commit: refactor(form): rinomina `data` in `userInput` per chiarezza in code review

DA EVITARE
Commit: "Update form" — generico, in inglese, dice il cosa non il perché.

Ora scrivi commit message per questo diff:
[diff reale]

Esegui i due round. Confronta. Output con few-shot dovrebbe rispettare convenzioni precisamente.

Output atteso

Una libreria personale di “few-shot prompts” per task ricorrenti: commit message, microcopy, refactor, gestione errori, naming. File con coppie input-output da copiare nel prompt.

Controllo qualità degli esempi

Prima di salvare un prompt few-shot, controlla che gli esempi non insegnino accidentalmente il comportamento sbagliato. Ogni esempio deve avere stesso formato, stesso livello di dettaglio e stessa intenzione. Se un esempio positivo è lungo e uno è telegrafico, il modello non capisce quale ritmo seguire. Se un controesempio è troppo simile agli esempi positivi, non separa davvero il caso limite.

Buona regola: per ogni esempio scrivi una riga “perché è buono”. Se non sai motivarlo, non è un asset didattico, è solo testo in più. Gli esempi migliori sono piccoli, ripetibili e legati a errori che hai davvero visto nel progetto.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: usare esempi concreti per orientare stile, struttura e qualità dell’output, includendo anche ciò che va evitato. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Few-shot come dimostrazione di formato, tono, architettura o livello di dettaglio.
• Esempi negativi: mostrare codice o risposte da non imitare e spiegare il motivo.
• Controesempi per coprire casi limite, errori comuni e comportamenti indesiderati.

3. Applicazione: svolgi il laboratorio: preparare un prompt con un esempio buono, uno cattivo e un caso limite per la stessa funzionalità. L’output da ottenere è: una richiesta che usa esempi per ottenere output più coerenti, confrontabile con una versione senza esempi.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• so distinguere esempio positivo, negativo, controesempio;
• ho almeno 3 prompt few-shot salvati e riusabili;
• so quando few-shot è efficace e quando non aiuta;
• aggiungo controesempi per gestione edge case che il modello tende a saltare.

Errori comuni

Esempi vaghi. “Esempio: qualcosa di simile a Stripe”. Inutile. Esempio = input + output concreti.

Troppi esempi. 10 few-shot diluiscono l’attenzione. 3-4 mirati funzionano meglio.

Esempi contraddittori. Due “esempi target” con pattern diversi. Il modello sceglie uno o mescola. Verifica coerenza.

Niente controesempio. Il modello replica pattern del caso normale e fallisce su edge case. Un controesempio salva.

Few-shot dove serve ragionamento. Task con logica complessa non si risolve con esempi. Serve piano + spiegazione.

Esempi che diventano stale. Convenzioni del progetto cambiano, esempi no. Aggiornali periodicamente.

Prompt di lavoro

Task: [descrizione]

Stile/convenzione attesa (esempi):

ESEMPIO 1
Input: [input concreto]
Output: [output concreto]

ESEMPIO 2
Input: [input concreto]
Output: [output concreto]

CONTROESEMPIO (caso limite gestito bene)
Input: [input atipico]
Output: [output corretto]
Motivo: [perché questo è gestito così]

DA EVITARE
Output sbagliato: [output che il modello tipicamente produce]
Motivo: [cosa c'è di sbagliato]

Adesso applica lo stesso stile a:
Input: [input vero]
Output:

Esercizio finale

Per ogni tipo di task ricorrente che fai con AI (commit, microcopy, refactor di una funzione, naming di componenti, ecc), costruisci un prompt few-shot e salvalo. Misura su 5 esecuzioni con vs senza esempi: tempo di iterazione, qualità dell’output al primo tentativo, numero di correzioni richieste. Il delta è il valore di tenere una libreria few-shot. Probabilmente è 30-50% di tempo risparmiato sui task ripetitivi.