✔️✔️ Doppie Spunte Blu Cap. 11 · Prompt engineering decente

Puntata 118

Puntata 118 — Iterare il prompt

Livello: ✔️✔️ Doppie Spunte Blu · Capitolo 11 · Prompt engineering decente

Il primo prompt è una bozza. Il vero prompt nasce dall’osservazione: che ha sbagliato? perché? cosa correggere? Cinque iterazioni e un prompt mediocre diventa un prompt-modello.

un loop circolare a 4 stazioni: ✍️ scrivi prompt → 🤖 osserva output → 🔍 trova lo scarto → ✏️ correggi prompt. Al centro, un cronometro che diventa più piccolo a ogni giro

Il prompt come codice

Pensa al prompt come a una funzione: input (l’istruzione e i dati) → output (la risposta). Come ogni funzione:

  1. La prima versione raramente funziona perfettamente.
  2. La debuggi guardando l’output e capendo cosa è andato male.
  3. La rifinisci, e itera.

Questo è prompt engineering iterativo. È meno glamour del “trovare il prompt magico”, ma è il modo in cui i prompt seri vengono costruiti in azienda.

Il loop a 4 stazioni

1. ✍️ Scrivi

Prima versione, applicando le 6 leggi (puntata 111). Non perfetta, ma ragionata.

2. 🤖 Esegui

Lanci il prompt su uno o più input di test.

3. 🔍 Osserva

Cosa è uscito? Confrontalo con quello che volevi. Trova lo scarto specifico:

  • Manca un dato?
  • C’è del rumore (frasi inutili)?
  • Il formato è sbagliato?
  • Il tono non è giusto?
  • Il modello ha allucinato qualcosa?
  • È troppo lungo / troppo corto?

4. ✏️ Correggi

Tocca solo le parti del prompt che corrispondono allo scarto. Non riscrivere tutto: pinpoint l’aggiunta che risolverà quel problema specifico.

Torna a 2. Ripeti.

Le 5 categorie di scarto e i loro fix

Scarto 1 — “Allucina informazioni”

Diagnosi: il modello inventa dati che non ha.

Fix:

  • Aggiungi “se non sai, scrivi ‘NON HO QUESTA INFORMAZIONE’”.
  • Aggiungi “non inventare nomi, citazioni, date” (puntata 116).
  • Considera RAG (puntata 238).

Scarto 2 — “Output troppo generico”

Diagnosi: risposta vaga, “su entrambi i lati”, senza prospettiva.

Fix:

  • Aggiungi role specifico (puntata 112).
  • Aggiungi few-shot con esempi concreti (puntata 113).
  • Aggiungi “prendi una posizione netta su X”.

Scarto 3 — “Formato sbagliato”

Diagnosi: testo libero quando volevi JSON; tabella senza separatori; lunghezza fuori target.

Fix:

  • Specifica formato preciso (puntata 115).
  • Per JSON, usa structured outputs / schema.
  • Per lunghezza, aggiungi vincolo numerico + post-processing.

Scarto 4 — “Tono non adatto”

Diagnosi: troppo formale/informale, troppo “promo”, troppo lungo.

Fix:

  • Vincoli negativi (puntata 116).
  • Esempi di tono nel prompt.
  • Specifica audience: “per programmatori junior, italiano colloquiale”.

Scarto 5 — “Logica sbagliata”

Diagnosi: l’output è ben formattato ma il ragionamento è errato.

Fix:

  • Aggiungi CoT (puntata 114).
  • Switcha a modello reasoning (puntata 128).
  • Aggiungi step di self-verification.

Esempio reale di iterazione

Task: estrarre dati di vendita da una mail commerciale.

Iterazione 1

Estrai i dati di vendita da questa email.

Output: paragrafo discorsivo, niente struttura. Inutilizzabile da codice.

Iterazione 2

Estrai i dati di vendita da questa email in JSON con campi:
prodotto, quantità, prezzo_unitario, totale.

Output: JSON, ma a volte con commenti prima, virgolette miste, formato date inconsistente.

Iterazione 3

Estrai i dati di vendita da questa email in JSON.

Schema obbligatorio:
{
  "prodotto": string,
  "quantità": int,
  "prezzo_unitario": float (euro),
  "totale": float (euro),
  "data_consegna": string in formato YYYY-MM-DD
}

Vincoli:
- Output ESCLUSIVAMENTE JSON, niente prima/dopo.
- Se un campo non è presente nel testo, valore null.
- Niente commenti dentro il JSON.

Output: JSON valido al 90%, formato date corretto. Quasi pronto per produzione.

Iterazione 4

[…stesso prompt iterazione 3…]

Few-shot:

Email: "Confermo l'ordine di 50 scatole di carta A4 a 2.40€ cad.
Consegna 12 giugno."
JSON: {"prodotto": "carta A4", "quantità": 50, "prezzo_unitario": 2.40,
"totale": 120.00, "data_consegna": "2026-06-12"}

Email: "Ti mando 200 pezzi del codice X44. Prezzo da definire."
JSON: {"prodotto": "X44", "quantità": 200, "prezzo_unitario": null,
"totale": null, "data_consegna": null}

Ora estrai da:
Email: "..."

Output: 99% accurato, formato stabile, gestisce edge case (campo null).

Iterazione 5 (produzione)

Aggiungi:

  • Validazione con Pydantic dopo il parsing (puntata 115).
  • Fallback se il JSON è invalido (retry con prompt rinforzato).
  • Monitoring che logga gli output sospetti per review umana.

Dal “prompt che funziona a demo” al “componente di sistema”.

Quanti giri servono

Empiricamente:

  • Task semplici (riformulare, tradurre): 1-2 iterazioni.
  • Task medi (classificazione, estrazione strutturata): 3-5.
  • Task complessi (multi-step, dominio specifico, vincoli stretti): 5-15.

Dopo 15-20 iterazioni senza convergenza: probabilmente serve un approccio diverso (RAG, fine-tuning, decomposizione del task).

L’eval-driven prompt engineering

In produzione, non iterare a caso. Costruisci una eval suite:

  1. Raccogli 10-50 input rappresentativi del problema reale.
  2. Per ognuno, definisci l’output corretto (manualmente, da esperti).
  3. Per ogni iterazione del prompt, lancia su tutti gli input e calcola la accuracy.
  4. Tieni traccia delle modifiche e dei risultati in un file.

Esempio struttura:

v1.0: prompt base                           accuracy: 62%
v1.1: + vincoli negativi                    accuracy: 71%
v1.2: + 3 esempi few-shot                   accuracy: 88%
v1.3: + JSON schema strict                  accuracy: 92%
v1.4: + edge case nei few-shot              accuracy: 96%
v2.0: refactor + role più specifico         accuracy: 95% ⚠️ regression
v2.1: rollback + raffinamento esempi        accuracy: 97% ✓

Standard professionale: trattare i prompt come codice versionato con test.

Vedi anche puntate 221 (benchmark/eval) e 297 (LLMOps).

Iterare con il modello

Trucco potente: chiedi all’AI stessa di migliorare il tuo prompt.

“Questo è il mio prompt: [PROMPT]. Questo è l’output che ha generato: [OUTPUT]. Questo è l’output che volevo: [TARGET].

Trova le 3 modifiche al prompt che ridurrebbero lo scarto. Riformula il prompt completo. Spiegami brevemente cosa hai cambiato e perché.”

Il modello fa “prompt engineering su sé stesso”. Spesso funziona meglio di quanto pensiamo. È la base di tecniche come APE (Automatic Prompt Engineering, 2022) e DSPy (Stanford, 2023).

Iterazione “umile” — leggi gli output sbagliati

Trappola classica: guardi solo gli output “buoni” e ti convinci che il prompt funziona. Guarda gli output rotti — è lì che sta l’informazione.

Pratica utile: tieni un file failure-mode.md dove annoti:

  • Esempio di input
  • Output sbagliato
  • Output corretto atteso
  • Ipotesi sul perché ha sbagliato

Dopo 20-30 voci, emergono pattern. Quei pattern sono il prossimo set di vincoli da aggiungere al prompt.

Quando smettere di iterare

Tre segnali:

  1. Rendimenti decrescenti: l’ultimo cambiamento ha migliorato di <1%.
  2. Accuracy target raggiunta sull’eval suite (es. 95%).
  3. Costo del prompt (in token) è cresciuto troppo per giustificare i miglioramenti.

A quel punto: deploy + monitoring + revisione periodica (mensile, trimestrale).

TEST pratico (15 minuti)

Prendi un task ricorrente che vuoi affidare all’AI. Costruisci una mini-eval:

  1. Raccogli 5 input reali.
  2. Definisci per ognuno l’output ideale (scritto a mano).
  3. Lancia un prompt iniziale, segna accuratezza percepita (0-100 per ogni input).
  4. Itera: aggiungi un solo cambiamento alla volta, rilancia, ri-misura.
  5. Tieni traccia in una mini-tabella delle versioni.

Dopo 3-4 iterazioni, vedrai chiaramente:

  • Quali aggiunte hanno portato accuracy.
  • Quali sono state inutili (le togli).
  • Dove il modello fatica strutturalmente (= cambiare modello o approccio).

In 15 minuti, hai un prompt-modello che vale settimane di tentativi caotici.

Take-away in una riga

Il prompt magico non esiste. Il prompt bravo nasce dall’osservazione iterativa: scarto specifico, fix specifico, ripeti finché converge.

➡️ Prossima puntata: Variabili e template riusabili — costruire una libreria personale.