Il consiglio standard per la qualità dei prompt è "metti su gli eval". Per la maggior parte dei solo dev e dei piccoli team è prematuro, e salta proprio il controllo che intercetta più errori con meno sforzo. La qualità di un prompt ha tre livelli, e quasi sicuramente ti serve che funzioni il più economico prima di costruire quelli costosi. Ecco come si confrontano i tre, un test in tre domande per capire quale livello ti serve davvero adesso, e perché diamo un punteggio a ogni prompt prima di costruire un solo eval.
Tre livelli di QA del prompt
Non sono in competizione: intercettano errori diversi a costi diversi, e si impilano.
Livello 1, il punteggio strutturale. Prima di eseguire il prompt, in pochi secondi, valuti la sua struttura: il task è chiaro, c'è il contesto, il formato di output è specificato, usa un ruolo dove il compito lo richiede. Intercetta gli errori che vivono nel testo stesso del prompt, e non richiede né dati né esecuzione. È la rubrica a 6 criteri e il modello Prompt Score che la regge. In pratica è il livello che ti impedisce di mandare "riassumi questo" senza lunghezza, pubblico o formato, il tipo di prompt che nessun eval dovrebbe mai vedere.
Livello 2, i set di eval. Metti insieme un dataset di input rappresentativi con output corretti noti, scegli una metrica ed esegui il prompt su tutti. Intercetta le regressioni di comportamento: limare le parole per sistemare un caso limite ne ha rotti altri tre? Costa ore per costruire il dataset e, più difficile, una metrica che correli davvero con quello che ti interessa. In pratica è ciò che ti dice che una riformulazione del system prompt ha fatto regredire in silenzio casi che a occhio non avresti mai ricontrollato su tutto un dataset. È il livello per cui sono nati strumenti come Promptfoo, Braintrust, Langfuse e LangSmith.
Livello 3, l'A/B in produzione. Metti due versioni del prompt sul traffico reale e misuri l'esito vero: tasso di risoluzione, conversione, pollice in su. Intercetta ciò che gli eval offline non possono, perché gli utenti veri non somigliano al tuo set di test. In pratica è l'unico livello che coglie un prompt che fa un buon punteggio e passa ogni caso offline, eppure rende poco sul campo, perché il tuo set di test era più pulito della realtà. Costa volume di traffico reale e la pazienza di arrivare a un segnale leggibile.
I tre livelli di QA del prompt: punteggio strutturale, set di eval, A/B in produzione, ordinati per costo e per cosa intercettano
I tuoi prompt possono migliorare. Promptimizer li riscrive e li testa automaticamente.
I tre livelli si impilano dal più economico al più costoso. Il punteggio strutturale gira prima dell'esecuzione e non richiede nulla; i set di eval richiedono un dataset etichettato; l'A/B richiede volume dal vivo. Ognuno coglie errori che gli altri si perdono.
Perché "basta mettere su gli eval" è prematuro per la maggior parte
Gli eval sono lo strumento giusto quando stai mettendo in produzione una funzione LLM su larga scala. Richiedono tre cose che un piccolo team spesso non ha ancora: un dataset etichettato che rappresenti gli input reali, una metrica che correli con l'esito che vuoi davvero, e abbastanza iterazioni perché la messa a punto ripaghi.
Le piattaforme di eval sono davvero valide, e sono pensate per team che fanno girare funzioni LLM in produzione con il volume che le giustifica. Per una libreria di qualche decina di prompt che ritocchi a mano, il costo di setup schiaccia il ritorno. Passi una giornata a cablare un'infrastruttura e a etichettare casi per cogliere regressioni in prompt che non sono ancora abbastanza stabili da regredire. Agli eval ci arriviamo quando un prompt se li è guadagnati, non come prima mossa di default.
La parte più difficile di un eval non è il dataset, è la metrica. "Il modello ha prodotto un buon output" non è qualcosa che uno script può verificare, quindi lo riduci a qualcosa che può, e una metrica scelta male ti dà una dashboard verde mentre sotto la qualità scivola. L'exact-match punisce una risposta corretta perché formulata in modo diverso; un LLM-as-judge aggiunge un secondo prompt che può sbagliare a modo suo. Far sì che la metrica insegua quello che ti interessa davvero richiede iterazioni che la maggior parte dei piccoli team non ha ancora fatto. È un'altra ragione per cui il livello strutturale si guadagna il primo posto: lì il "buono" è già definito dalla rubrica, quindi non c'è nessuna metrica da sbagliare.
Il test in tre domande
Tre domande, in ordine. Fermati al primo "no".
1. Questo prompt girerà riusato, non sorvegliato o nelle mani di altri? Se è una cosa usa e getta che esegui e leggi tu, l'eval sei tu: un punteggio strutturale basta, perché cogli le risposte scadenti man mano che arrivano. Se girerà senza che tu lo guardi, vai avanti.
2. Puoi ottenere a basso costo una ventina di casi rappresentativi con una risposta corretta nota? Se non riesci a definire com'è fatto il "corretto" su input reali, non puoi ancora costruire un eval sensato: dai un punteggio al prompt e aggiungi controlli manuali a campione. Se puoi, vai avanti.
Le tecniche che stai leggendo funzionano. Testa subito i tuoi prompt con Prompt Score e vedi il punteggio in tempo reale.
3. Hai abbastanza volume dal vivo per leggere un segnale A/B? Se due versioni impiegherebbero mesi a separarsi dal rumore, un test A/B è teatro: costruisci invece il set di eval offline. Se il volume ce l'hai, fai girare set di eval e A/B insieme.
Un albero decisionale a tre domande che instrada verso punteggio strutturale, punteggio più controlli a campione, set di eval, o eval più A/B
Il test ti instrada al livello più leggero che davvero ti serve. La maggior parte dei prompt da solo dev si ferma alla prima domanda. Gli eval si guadagnano il posto solo oltre la seconda.
Dove vince il punteggio
Il punteggio strutturale è il filtro pre-esecuzione, e la maggior parte dei prompt che falliscono, falliscono per struttura. Sono vaghi, manca il contesto, non hanno mai specificato un formato. Il punteggio li coglie prima che tu spenda un token, figurarsi costruire un dataset. Un set di eval conferma il comportamento sui casi che hai pensato di definire; un punteggio strutturale ti dice che il prompt era sottospecificato in partenza, che è un problema diverso e più a monte.
Immagina il caso tipico: un prompt restituisce output incoerente, così corri a un eval per misurare l'incoerenza. Dagli prima un punteggio e la diagnosi è di solito immediata: non è mai stato specificato un formato, quindi il modello improvvisa una forma diversa a ogni giro. È una correzione di una riga che la rubrica fa emergere in pochi secondi, non un dataset che dovevi costruire. Lavorare quella correzione criterio per criterio è un ciclo a sé, quello che porta un prompt da 2 a 4. Il punteggio riporta un problema di misura a un problema di scrittura, e un problema di scrittura è molto più economico da risolvere.
È per questo che il punteggio viene prima anche quando alla fine ti serviranno gli eval. È abbastanza economico da girare su ogni prompt, a ogni salvataggio, e toglie di mezzo l'intera classe di errori che nessun eval dovrebbe dover cogliere. Quando un prompt arriva al tuo set di eval, dovrebbe già fare un buon punteggio strutturale, altrimenti l'eval sta misurando la cosa sbagliata.
Un confronto tra punteggio strutturale e set di eval su costo, quando gira, cosa intercetta e cosa si perde
Il punteggio strutturale e i set di eval rispondono a domande diverse. Uno chiede se il prompt è costruito bene; l'altro chiede se si comporta bene sui tuoi casi. Vuoi prima quello economico, e quello costoso solo quando si guadagna il posto.
Quando passare agli eval
Ci sono segnali onesti. Costruisci il set di eval quando stai mettendo il prompt nelle mani degli utenti, quando lo stesso prompt gira migliaia di volte al giorno, o quando la correttezza è misurabile e il costo di sbagliare è reale: estrazione, classificazione, instradamento, tutto ciò dove una risposta sbagliata si propaga in silenzio. A quel punto il dataset etichettato si ripaga, e le piattaforme di eval nel confronto tra strumenti di gestione prompt valgono il setup.
Prendi un prompt di estrazione che tira campi da fatture in JSON. Gira non sorvegliato, migliaia di volte, e un campo sbagliato finisce in un database che nessuno sta guardando. Quel prompt si è chiaramente guadagnato un set di eval: fatture rappresentative, JSON corretto noto, una metrica sui campi esatti. Ma dovrebbe comunque passare prima un pulito punteggio strutturale, perché un prompt di estrazione che non ha mai specificato il formato di output fallirà l'eval per un motivo che la rubrica avrebbe colto gratis.
Anche allora, il punteggio resta il primo cancello. Un prompt che fa un buon punteggio strutturale e passa il suo set di eval è in buona forma. Un prompt che fallisce il set di eval ma fa anche un brutto punteggio strutturale non aveva bisogno dell'eval per dirti che era rotto.
Prima il punteggio
L'ordine è tutto il punto. Prima il punteggio, perché è gratis e coglie gli errori più comuni prima dell'esecuzione. Costruisci gli eval quando un prompt se li è guadagnati con riuso, correttezza misurabile e volume. Fai A/B solo quando il traffico dal vivo riesce davvero a distinguere due versioni. Saltare dritti agli eval sembra rigoroso, ma è un modo costoso per scoprire che un prompt era semplicemente vago, e vago è esattamente ciò che il punteggio coglie per niente.
Se vuoi il livello economico attivo già oggi, Keep My Prompts dà un punteggio a ogni prompt che salvi sui sei criteri, così gli errori strutturali vengono colti prima che ci debba pensare uno dei livelli costosi. Parti da lì, e aggiungi gli eval il giorno in cui un prompt te lo impone.
