Il Divario tra Capacità e Affidabilità
Ecco un pattern che scotta quasi tutti coloro che mandano per la prima volta l'AI a utenti reali:
Il modello fa la cosa alla perfezione nel tuo test. Fallisce in produzione. Sei confuso, perché l'hai visto funzionare.
Quello in cui ti sei imbattuto è il divario tra capacità e 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 variabili, su esecuzioni ripetute, su lievi cambiamenti 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, tipicamente:
- Lo esegui su input che hai progettato tu stesso
- Lo esegui una manciata di volte
- Selezioni a tuo piacimento l'output che sembra buono
- Modifichi il prompt finché non sembra giusto
Questo processo ottimizza per la capacità. Il prompt ora funziona sui tuoi esempi. Hai visto un output corretto. Lo metti in produzione.
Il problema è che gli input degli utenti in produzione non sono i tuoi esempi. Sono più disordinati, più variabili, formulati in modi che non hai anticipato. Il modello non è mai stato testato su di essi. Non hai idea di come si comporti su di essi.
Un singolo buon output 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 delle volte funziona?"
Un compito in cui il modello riesce il 95% delle volte sembra fantastico in una demo e si rompe su circa un utente su venti. Un compito in cui riesce il 60% delle volte sembra a posto quando sei tu a eseguirlo. Sono situazioni molto diverse, e non puoi distinguerle senza misurare.
Lo spettro capacità-affidabilità nella 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à della modalità di errore | I fallimenti sono rari nei test, comuni in produzione | I fallimenti sono misurati e compresi |
| Come scopri che si è rotto | Lamentele degli utenti | La tua suite di eval |
| Come lo migliori | Indovina e prova i prompt | Traccia il tasso di successo, debugga i fallimenti in modo sistematico |
| Fiducia nel deployment | Basata sulle vibrazioni | Basata sulle prove |
Le eval sono il vero fossato difensivo
Prompt migliori possono alzare la capacità. Solo le eval possono dirti se hai alzato 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, assegni un punteggio agli output e ottieni un numero. Poi cambi qualcosa — il prompt, il modello, la temperatura — e lo riesegui. Ora hai un segnale.
Non è glamour. È la parte del lavoro sui prodotti AI che la maggior parte dei tutorial salta del tutto. Ma è l'unico modo per rispondere alla domanda che conta davvero quando vai in produzione: "Quanto spesso funziona su input che non ho visto?"
Un modo semplice per iniziare
Non hai bisogno di infrastruttura per cominciare. Ecco un ciclo di eval minimo funzionante:
-
Costruisci un golden set. 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.
-
Eseguilo N volte. Esegui il tuo prompt su ciascun esempio più volte. La varianza tra le esecuzioni ti dice qualcosa sulla stabilità del prompt; la varianza tra gli esempi ti dice qualcosa sulla copertura.
-
Traccia il tasso di successo. Per ogni coppia (input, esecuzione), registra successo o fallimento. Calcola il tasso complessivo. Questo numero è l'inizio del tuo quadro di affidabilità.
-
Rendilo un test di regressione. Ogni volta che cambi il prompt, riesegui la eval. Se il tasso di successo cala, hai rotto qualcosa. Se sale, hai fatto un miglioramento reale.
Tutto qui. Un foglio di calcolo va bene. La disciplina conta più degli strumenti.
Perché questo è un problema di ingegneria, non di prompting
L'istinto, quando un modello fallisce, è riscrivere il prompt. A volte è giusto. Ma spesso è un modo per 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'AI assomiglia a questo:
- Definire cosa significa "corretto" prima di eseguire qualsiasi cosa
- Misurare rispetto a una distribuzione di input rappresentativa
- Tracciare i cambiamenti nel tempo con una metodologia coerente
- Distinguere "questo modello non può fare questo compito" da "questo compito è sottospecificato"
Il prompt engineering è uno strumento all'interno di quel processo. Non è un suo sostituto.
L'inquadratura onesta
La maggior parte delle capacità dell'AI è reale. I modelli possono genuinamente fare cose notevoli. Il divario tra capacità e 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 compito funzioni il 95% delle volte, hai bisogno di prove che funzioni il 95% delle volte. Quelle prove vengono dall'eseguire test strutturati, non dalla fiducia nella demo.
Gli ingegneri che costruiscono prodotti AI durevoli non sono necessariamente quelli che scrivono i migliori prompt. Sono quelli che sanno cosa significa "funzionare" prima di andare in produzione, e che hanno una misurazione che dice loro se è vero.