Zero-shot, one-shot, few-shot: scegliere il numero di esempi

Gli esempi sono uno dei modi più forti per guidare un LLM. Ma ogni esempio costa token, può introdurre bias e può insegnare al modello dettagli sbagliati. La domanda non è “metto esempi o no?”, ma “quale rischio voglio ridurre con gli esempi?”.

Perché questa lezione conta

Molti prompt tecnici falliscono non perché mancano istruzioni, ma perché il formato atteso è implicito. Un esempio può chiarire tono, struttura, casi limite e livello di dettaglio meglio di un paragrafo di spiegazione. Allo stesso tempo, esempi inutili appesantiscono il prompt e possono portare il modello a copiare pattern non desiderati.

Zero-shot

Zero-shot significa chiedere il task senza esempi. Funziona quando:

• il task è comune;
• il formato è semplice;
• i criteri sono chiari;
• il costo deve restare basso;
• gli errori sono facili da intercettare.

Esempio:

Riassumi questo bug report in tre campi: sintomo, ambiente, passi di riproduzione.

Qui un esempio potrebbe non servire: il formato è semplice e il modello conosce bene il concetto di bug report.

One-shot

One-shot aggiunge un esempio. È utile quando vuoi mostrare il livello esatto di dettaglio o evitare un fraintendimento frequente.

Esempio:

Classifica il seguente finding di code review.

Esempio:
Input: "La funzione accetta HTML utente e lo inserisce con innerHTML"
Output:
{
  "categoria": "security",
  "severita": "blocking",
  "motivo": "possibile XSS su input non fidato"
}

Ora classifica:
Input: "{{finding}}"

L’esempio non spiega solo il formato: mostra anche la soglia di severità.

Few-shot

Few-shot usa più esempi. Serve quando il task ha varietà reale:

• classi simili da distinguere;
• edge case;
• stile editoriale preciso;
• output strutturato;
• dati ambigui;
• esempi negativi.

Il few-shot migliore non contiene tre esempi quasi identici. Contiene casi rappresentativi e difficili.

Come scegliere gli esempi

Usa questa griglia:

Domanda	Se sì
Il formato viene spesso sbagliato?	aggiungi un esempio di formato
Ci sono classi ambigue?	aggiungi esempi contrastivi
Ci sono casi limite?	includine almeno uno
Il task è semplice e frequente?	resta zero-shot
Il costo è critico?	limita esempi o sposta esempi in template riusabile

Anti-pattern

Esempio troppo perfetto:

Input: bottone rosso
Output: errore UI

Non aiuta se nel mondo reale gli input sono lunghi, incompleti o contraddittori.

Esempio utile:

Input: "Da mobile il bottone salva sparisce dopo aver aperto la tastiera. Succede solo su Safari iOS."
Output:
{
  "categoria": "frontend-ui",
  "severita": "high",
  "dati_mancanti": ["versione iOS", "viewport", "passi esatti"],
  "prima_verifica": "riprodurre con DevTools o device reale"
}

Laboratorio guidato

Costruisci tre versioni dello stesso prompt:

1. zero-shot;
2. one-shot;
3. few-shot con almeno un caso limite.

Task consigliato: estrazione strutturata da issue, classificazione di finding, sintesi di bug report, generazione di messaggi di commit.

Confronta:

• rispetto del formato;
• costo in token;
• gestione casi ambigui;
• quantità di correzioni manuali;
• stabilità su input diversi.

Output atteso

Una regola operativa per decidere quando passare da zero-shot a few-shot.

Esempio:

Uso zero-shot per task semplici e formato naturale.
Uso one-shot quando devo mostrare soglia o stile.
Uso few-shot quando devo coprire ambiguità, casi limite o schema rigido.

Checklist di verifica

• so spiegare perché ho aggiunto ogni esempio;
• gli esempi coprono casi diversi, non ripetizioni;
• ho almeno un esempio limite o negativo quando serve;
• il costo degli esempi è giustificato dal miglioramento;
• il prompt funziona anche su input non identici agli esempi.

Collegamenti

• Modulo: Tecniche di prompting — lezione 11 del corso.
• Lezione precedente: Formato e verifiche: come parlare al modello dell’output.
• Prossima lezione: Chain-of-thought e ragionamento esplicito.