Il 70% delle volte funziona. Il 30% delle volte produce spazzatura. Se ti sei chiesto come migliorare i prompt AI che usi ogni giorno, questa proporzione ti suona familiare. È il problema fondamentale di chiunque lavori con ChatGPT, Claude o qualsiasi altro modello linguistico: i prompt non sono deterministici. Lo stesso input può dare un risultato eccellente o un risultato inutilizzabile, e non hai modo di saperlo in anticipo.
Ma c’è un approccio che cambia le regole del gioco. Si chiama eval - abbreviazione di evaluation - ed è lo stesso metodo che i laboratori AI usano per misurare e migliorare i propri modelli. Combinato con il pattern Auto Research di Karpathy, permette di far auto-ottimizzare i prompt in autonomia fino a raggiungere percentuali di affidabilità che manualmente non raggiungeresti mai.
Da 32 su 40 a 39 su 40. In poche iterazioni automatiche. Senza toccare nulla.
Perché i prompt AI danno risultati diversi ogni volta
Ogni output di un modello linguistico è una distribuzione probabilistica. Non è un programma che restituisce sempre lo stesso risultato - è più simile a un collega molto bravo che però ogni tanto ha una giornata storta.
Il problema non è scrivere il prompt perfetto. Il prompt perfetto non esiste, perché la variabilità è intrinseca al funzionamento dei LLM. Quello che puoi fare è misurare quanto spesso il prompt produce un output accettabile e poi migliorare quella percentuale sistematicamente.
È la differenza tra sperare che funzioni e sapere con che frequenza funziona. Ed è esattamente quello che fanno le eval.
Come testare la qualità dei prompt: le eval
Una eval è un test standardizzato per i tuoi prompt. Funziona come una verifica scolastica: definisci i criteri, esegui il prompt più volte, e valuti ogni output contro quei criteri.
La regola d’oro è: domande binarie. Sì o no. Passa o non passa. Niente scale da 1 a 7, niente “quanto ti sembra buono”. Perché?
Perché ogni livello di soggettività che aggiungi si moltiplica per ogni punto di valutazione. Immagina un cono: parte stretto dall’input, ma più variabilità introduci nella valutazione, più i risultati si disperdono. Con domande binarie il cono resta stretto. Con scale soggettive, diventa ingestibile.
Eval binaria vs scala soggettiva
Binaria (consigliata)
- ✓ “Il testo è leggibile?” → Sì/No
- ✓ “Rispetta la palette colori?” → Sì/No
- ✓ “Il layout è lineare?” → Sì/No
- ✓ “Assenza di numeri ordinali?” → Sì/No
Risultato: 3/4 → 75%
Scala (da evitare)
- ✗ “Quanto è leggibile?” → 1-7
- ✗ “Quanto rispetta la palette?” → 1-7
- ✗ “Quanto è lineare?” → 1-7
- ✗ “Quanto è pulito?” → 1-7
Risultato: 19/28 → ???
Le eval binarie producono punteggi stabili e confrontabili. Le scale soggettive amplificano la variabilità del modello valutatore.
Prompt engineering avanzato: da 32/40 a 39/40
Prendiamo un caso reale. Una skill di Claude Code che genera diagrammi in stile whiteboard: rettangoli arrotondati, colori pastello, frecce sottili, etichette pulite. Il tipo di grafica che usi nelle presentazioni o nei documenti tecnici.
Il problema: il 30% delle volte il diagramma usciva con testo illeggibile, colori neon, layout caotico o numeri ordinali non richiesti.
La eval suite era composta da 4 criteri binari:
- Leggibilità - tutto il testo nel diagramma è leggibile e grammaticalmente corretto?
- Palette - usa colori pastello e morbidi, niente neon o rossi accesi?
- Linearità - il flusso va da sinistra a destra o dall’alto in basso?
- Pulizia - assenza di numeri, ordinali e numerazione non richiesta?
Il setup: genera 10 diagrammi per ciclo, valuta ognuno contro i 4 criteri (punteggio massimo: 40), modifica il prompt, ripeti ogni 2 minuti.
Primo ciclo: 32/40. Già buono, ma con margine. Dopo pochi cicli automatici: 39/40. Il 97,5% di affidabilità. Il tutto senza intervento umano, con un costo totale di circa 10 dollari.
Il dettaglio più interessante non è il punteggio finale - è il log delle modifiche. L’agente ha documentato ogni cambiamento al prompt e il suo impatto sul punteggio. Quel log è un asset: puoi passarlo a modelli futuri più potenti che riprenderanno l’ottimizzazione da dove è stata lasciata.
Come ottimizzare i prompt in automatico con Claude Code
Il setup è più semplice di quanto sembri. Tre ingredienti:
I tre ingredienti
Il prompt da ottimizzare
Il tuo file .md con le istruzioni della skill. È il “codice sorgente” che l’agente modificherà ad ogni iterazione.
La eval suite
3-6 criteri binari (sì/no) che definiscono cosa significa “output buono”. Moltiplicati per N esecuzioni = il tuo punteggio oggettivo.
Il loop automatico
Un agente orchestratore che esegue la skill N volte, calcola il punteggio eval, modifica il prompt e ripete. Ogni 2-5 minuti.
La stessa architettura di Auto Research di Karpathy, applicata ai prompt invece che ai modelli ML.
Il passaggio chiave è pensare al prompt come al train.py nel repo di Karpathy, e alla eval suite come alla validation loss. L’agente orchestratore - il tuo program.md - riceve le istruzioni: “esegui la skill 10 volte, valuta contro questi criteri, modifica il prompt per migliorare il punteggio, ripeti”.
Puoi applicarlo a qualsiasi skill: generazione di presentazioni, scrittura di email, analisi di documenti, creazione di report. Se riesci a definire cosa significa “buono” con domande sì/no, puoi automatizzare il miglioramento.
È il passaggio che separa chi usa l’intelligenza artificiale in modo artigianale da chi la usa in modo ingegneristico. E per le aziende che vogliono fare questo salto, la formazione aziendale sull’AI parte esattamente da qui: come passare dal prompt engineering intuitivo a un approccio misurabile e ripetibile.
Errori comuni nel prompt engineering e come evitarli
Due errori che vediamo spesso quando le aziende iniziano a costruire pipeline AI automatizzate.
Criteri troppo rigidi - “massimo 47 parole”, “nessun uso della lettera Q”, “esattamente 3 paragrafi”. Il modello ottimizzerà per il vincolo, non per la qualità. È come uno studente che impara a superare il test senza capire la materia: tecnicamente passa, ma l’output è inutile. Tieni i criteri legati alla qualità percepita, non a regole arbitrarie.
Troppe eval contemporaneamente - se dai al modello 20 criteri, troverà il modo di soddisfarli tutti formalmente producendo output che “passa il test” ma non è realmente buono. 3-6 criteri ben scelti funzionano meglio di 20 criteri dettagliati. La parsimonia è tua amica.
C’è anche una riflessione più ampia. Le eval misurano ciò che sai definire, non ciò che conta davvero. Un diagramma può essere leggibile, lineare, con colori pastello e senza numeri - e comunque non comunicare il concetto giusto. La qualità semantica è la più difficile da catturare in domande binarie. Per ora, le eval funzionano bene sugli aspetti formali. Per la sostanza, serve ancora un occhio umano.
Forse non per sempre. Ma per ora sì. E chi lavora con l’AI ogni giorno sa che riconoscere questo limite è più utile che ignorarlo.