Valutare un prompt: dataset minimo e metriche

Un prompt non è “buono” perché una volta ha prodotto una risposta convincente. È buono quando, su un insieme di casi rappresentativi, produce risultati abbastanza corretti, nel formato richiesto, con costi e latenza accettabili.

Per uno sviluppatore questa è la svolta: smetti di giudicare il prompt come una frase e inizi a trattarlo come una parte del sistema. Se cambia il modello, se cambia il contesto, se aggiungi un vincolo, devi poter capire se hai migliorato davvero o se hai solo ottenuto un output più gradevole.

Perché questa lezione conta

La valutazione è ciò che separa il prompting artigianale dal prompting ingegnerizzato. Senza evaluation ogni modifica è un atto di fiducia: cambi una frase, provi due esempi, ti sembra meglio, vai avanti. Funziona finché il prompt è personale. Non funziona quando il prompt serve un team, un prodotto, un flusso ricorrente o un’automazione.

La buona notizia è che non serve partire da una piattaforma complessa. Per molti task basta un dataset minimo di 20-50 casi, una griglia di metriche e una procedura ripetibile. L’obiettivo non è ottenere una verità assoluta, ma avere un confronto stabile tra versioni.

Obiettivo operativo

Alla fine della lezione devi saper costruire un evaluation set minimo per un prompt tecnico, scegliere metriche sensate e leggere i risultati senza farti ingannare da output isolati. Devi anche saper decidere quando una valutazione manuale è sufficiente e quando serve automatizzare.

Dataset minimo

Un dataset di valutazione è una raccolta di input realistici su cui testare il prompt. Non deve contenere solo casi facili: deve contenere la distribuzione reale del lavoro.

Per un prompt di code review, ad esempio, il dataset può contenere:

1. diff con bug evidente;
2. diff corretto ma stilisticamente discutibile;
3. diff con problema di sicurezza;
4. diff con falso positivo probabile;
5. diff grande ma a basso rischio;
6. diff piccolo ma critico;
7. diff con contesto insufficiente;
8. diff che non deve produrre commenti.

La regola pratica è semplice: includi casi normali, casi limite e casi in cui il modello tende a sbagliare. Se nel dataset ci sono solo esempi puliti, misurerai la capacità del modello di comportarsi bene quando tutto è facile.

Etichette e aspettative

Ogni caso deve avere un’aspettativa. Non sempre serve una risposta perfetta già scritta. A volte basta una griglia:

id: review-014
input: diff del componente checkout
atteso:
  - deve segnalare il rischio di doppio submit
  - non deve chiedere un refactor completo
  - severita massima: P1
  - formato: lista di findings con file e linea

Questa struttura evita il problema classico: leggere l’output dopo il fatto e decidere se ti piace. L’aspettativa va scritta prima, altrimenti la valutazione diventa negoziabile.

Metriche utili

Le metriche dipendono dal task. Per i prompt da sviluppatore, di solito bastano queste:

Accuratezza funzionale. L’output risolve il problema richiesto? Nel caso di estrazione dati, i campi sono corretti? Nel caso di debug, la causa proposta è coerente con i sintomi?

Format compliance. L’output rispetta lo schema? Se chiedi JSON valido, non basta che il contenuto sia buono: deve essere parsabile.

Copertura dei casi critici. Il prompt riconosce i casi ad alto rischio? Una media alta non basta se fallisce proprio sui casi che costano di più.

Tasso di falsi positivi. Nei prompt di review o sicurezza, un modello troppo aggressivo consuma tempo del team. Misurare solo i bug trovati spinge verso output rumorosi.

Latenza e costo. Una versione leggermente migliore ma tre volte più cara potrebbe non essere una versione migliore nel prodotto reale.

Stabilità. Se esegui lo stesso caso più volte, l’output rimane nella stessa classe di qualità o oscilla troppo?

Giudice umano e LLM-as-judge

Il giudice umano è più affidabile quando il dominio richiede responsabilità, conoscenza della codebase o decisioni di prodotto. È lento, ma vede sfumature che una metrica automatica non coglie.

Un LLM-as-judge è utile quando devi fare triage, confrontare molte varianti o misurare aspetti relativamente chiari come aderenza al formato, presenza di elementi obbligatori, completezza rispetto a una rubrica. Non va trattato come arbitro assoluto: va calibrato con alcuni esempi già valutati da persone.

Una scelta pragmatica:

1. prime 20 valutazioni fatte da umano;
2. costruzione di una rubrica;
3. judge automatico sulla rubrica;
4. controllo umano periodico sui casi controversi.

Laboratorio guidato

Scegli un prompt che usi davvero: code review, generazione test, riassunto ticket, estrazione requisiti, spiegazione errore. Costruisci un file eval-cases.md o eval-cases.jsonl con almeno 15 casi.

Per ogni caso inserisci:

1. identificativo stabile;
2. input o riferimento al file di input;
3. aspettativa prima dell’esecuzione;
4. metriche da osservare;
5. spazio per note e risultato.

Esegui il prompt attuale su tutti i casi, poi modifica una sola leva: contesto, formato, vincoli o esempi. Riesegui e confronta. Se cambi più cose insieme, non saprai quale modifica ha prodotto l’effetto.

Output atteso

Alla fine devi avere una procedura di evaluation minima, composta da:

1. dataset di casi rappresentativi;
2. rubrica di valutazione;
3. tabella risultati per versione del prompt;
4. nota decisionale: mantenere, scartare o iterare.

Questo artefatto deve vivere nel repo o in uno spazio versionato. Se resta in una chat, non è un processo: è memoria personale.

Errori comuni

Usare solo esempi favorevoli. Un prompt validato su casi facili fallisce appena entra in produzione.

Cambiare prompt e modello insieme. Se migliori o peggiori, non sai perché.

Misurare solo la media. Un prompt con media alta ma fallimento sui casi critici può essere inaccettabile.

Confondere stile e qualità. Un output più ordinato non è necessariamente più corretto.

Checklist di verifica

• ho almeno 15 casi realistici, non inventati solo per la lezione;
• ogni caso ha aspettative scritte prima dell’esecuzione;
• ho almeno una metrica di qualità e una metrica operativa;
• posso confrontare due versioni del prompt senza cambiare metodo;
• so dire quale regressione bloccherebbe il rilascio.

Collegamenti

• Modulo: Affidabilità: valutazione, sicurezza, costi — questa lezione è la numero 26 del corso.
• È il prerequisito pratico per le regressioni di prompt della lezione successiva.