Il divario capacità-affidabilità
- Perché 'ha funzionato nella mia demo' non è prova che funzionerà in produzione
- Capacità vs. affidabilità — sono proprietà diverse, e la maggior parte delle guide le confonde
- Come la varianza trasformi silenziosamente un task al 95% in un prodotto rotto
- Un ciclo di valutazione golden-set in quattro passi che puoi iniziare oggi con un foglio di calcolo
- Perché le eval sono il vero fossato — non i prompt
Ecco uno schema che scotta quasi tutti quelli che portano l'IA a utenti reali per la prima volta:
Il modello fa la cosa perfettamente nel tuo test. Fallisce in produzione. Sei confuso, perché l'hai visto funzionare.
Ciò in cui sei incappato è il divario capacità-affidabilità.
Capacità significa che il modello può svolgere un compito — produce un output corretto almeno una volta, in certe condizioni.
Affidabilità significa che il modello svolge il compito correttamente in modo coerente — su input variati, su esecuzioni ripetute, con leggere variazioni di formulazione o contesto.
Le demo dimostrano la capacità. La produzione richiede l'affidabilità. Sono proprietà diverse, e la maggior parte delle guide le confonde.
Perché le demo mentono
Quando testi un prompt, di solito:
- Lo esegui su input che hai progettato tu stesso
- Lo esegui una manciata di volte
- Scegli l'output che sembra buono
- Ritocchi il prompt finché non sembra a posto
Questo processo ottimizza per la capacità. Il prompt ora funziona sui tuoi esempi. Hai visto un output corretto. Lo rilasci.
Il problema è che gli input degli utenti in produzione non sono i tuoi esempi. Sono più disordinati, più variati, formulati in modi che non avevi previsto. Il modello non è mai stato testato su di essi. Non hai idea di come si comporti.
Un singolo output buono non è una stima delle prestazioni. È un aneddoto.
La varianza è la variabile nascosta
Gli LLM sono stocastici. Esegui lo stesso prompt due volte e spesso ottieni output diversi. Questa varianza è normale e di solito va bene. Ma significa che la domanda rilevante non è "ha funzionato?" — è "in quale frazione dei casi funziona?"
Un task in cui il modello riesce nel 95% dei casi sembra ottimo in una demo e si rompe più o meno su un utente ogni venti. Un task in cui riesce nel 60% dei casi sembra a posto quando sei tu a eseguirlo. Sono situazioni molto diverse, e non puoi distinguerle senza misurare.
Lo spettro capacità-affidabilità in pratica
| Dimensione | Capace ma inaffidabile | Affidabile |
|---|---|---|
| Input testati | Esempi progettati dall'autore | Input diversi, di utenti reali |
| Dimensione del campione | Poche esecuzioni | Esecuzioni ripetute su molti esempi |
| Visibilità delle modalità di fallimento | I fallimenti sono rari nei test, comuni in produzione | I fallimenti sono misurati e compresi |
| Come scopri che si è rotto | Reclami degli utenti | La tua suite di eval |
| Come lo migliori | Prompt a tentoni | Traccia il tasso di successo, debugga i fallimenti in modo sistematico |
| Fiducia nel deploy | A pelle | Basata sull'evidenza |
Le eval sono il vero fossato
Prompt migliori possono aumentare la capacità. Solo le eval possono dirti se hai aumentato l'affidabilità.
Una eval è un test strutturato: un insieme di input, output attesi o criteri di valutazione, e un modo per misurare il tasso di successo. Esegui il modello sugli input, valuti gli output, ottieni un numero. Poi cambi qualcosa — il prompt, il modello, la temperatura — ed esegui di nuovo. Ora hai un segnale.
Non è affascinante. È la parte del lavoro sui prodotti IA che la maggior parte dei tutorial salta a piè pari. Ma è l'unico modo di rispondere alla domanda che conta davvero quando si rilascia: "Quanto spesso funziona su input che non ho visto?"
Un modo semplice per iniziare
Non servono infrastrutture per cominciare. Ecco un ciclo di eval minimo:
- Raccogli 20-50 input reali o realistici. Per ciascuno, scrivi che aspetto ha un output corretto (o i criteri per giudicarlo). Questi sono i tuoi esempi golden. Preferisci input di utenti reali a quelli che hai inventato — stai cercando la distribuzione contro cui non hai testato.
- Esegui il tuo prompt su ciascun esempio più volte (3-5 è un minimo ragionevole). La varianza tra le esecuzioni ti parla della stabilità del prompt; la varianza tra gli esempi ti parla della copertura. Entrambe contano.
- Per ogni coppia (input, esecuzione), registra passato o fallito. Calcola il tasso complessivo. Questo singolo numero è l'inizio del tuo quadro di affidabilità — tutto il resto è rumore finché non lo hai.
- Ogni volta che cambi il prompt, il modello o la temperatura, riesegui la eval. Se il tasso di successo cala, hai rotto qualcosa. Se sale, hai fatto un miglioramento reale — al contrario di una modifica che sembrava migliore sul singolo esempio che hai guardato a occhio.
Tutto qui. Un foglio di calcolo va bene. La disciplina conta più della tecnologia.
Perché è un problema di ingegneria, non di prompting
L'istinto quando un modello fallisce è riscrivere il prompt. A volte è giusto. Ma spesso è un modo di ottimizzare per il caso di fallimento che hai visto, al costo di regredire su casi che non hai controllato.
L'ingegneria dell'affidabilità per l'IA assomiglia a questo:
- Definire cosa significa "corretto" prima di eseguire qualsiasi cosa
- Misurare rispetto a una distribuzione rappresentativa di input
- Tracciare i cambiamenti nel tempo con una metodologia coerente
- Distinguere "questo modello non sa fare questo task" da "questo task è sotto-specificato"
Il prompt engineering è uno strumento dentro quel processo. Non ne è un sostituto.
L'inquadramento onesto
La maggior parte delle capacità dell'IA sono reali. I modelli sanno davvero fare cose notevoli. Il divario capacità-affidabilità non è un argomento per dire che le capacità sono finte — è un argomento per dire che sapere che esistono non basta.
Se hai bisogno che un task funzioni nel 95% dei casi, ti serve evidenza che funzioni nel 95% dei casi. Quell'evidenza viene da test strutturati, non dalla fiducia nella demo.
Gli ingegneri che costruiscono prodotti IA duraturi non sono necessariamente quelli che scrivono i prompt migliori. Sono quelli che sanno cosa significa "funzionare" prima di rilasciare, e che hanno una misura che dice loro se è vero.
Verifica
0/3- Capacità è 'può farlo?' Affidabilità è 'quanto spesso lo fa?' — le demo dimostrano la prima, la produzione richiede la seconda.
- Un singolo output buono è un aneddoto, non una stima delle prestazioni. L'evidenza reale richiede input variati eseguiti più volte.
- La varianza è la variabile nascosta: il 95% di successo sembra ottimo in una demo e si rompe su un utente ogni venti.
- Inizia con un golden set di 20-50 input reali, esegui ciascuno N volte, traccia il tasso di successo e riesegui a ogni modifica.
- Prompt migliori aumentano la capacità. Solo le eval aumentano (e provano) l'affidabilità — le eval sono il vero fossato.
Correlati
- La tua prima chiamata API
- Basi del prompting
- L'emivita della freschezza
- Quando gli agenti gestiscono un'attività — il divario reso concreto: due esperimenti reali in cui a modelli di frontiera è stato dato un budget vivo.
- Agenti sotto pressione da KPI — un benchmark che mostra come lo stesso divario si trasformi in violazioni di vincoli quando un KPI entra nel prompt.
- Il collo di bottiglia della verifica — la versione su scala industriale del divario: quando l'IA sa scrivere codice più velocemente di quanto i team riescano a fidarsene.