Hai costruito un agente che risponde alle domande dei clienti, e adesso devi decidere: è pronto per entrare in produzione o conviene lavorarci ancora? La prima reazione è cercare un benchmark, un numero che ti dica quanto è bravo. Il problema è che i benchmark pubblici misurano cose generiche su dataset che non somigliano ai tuoi utenti, e tu ti ritrovi con un punteggio alto e un agente che sbaglia esattamente dove ti serve che non sbagli.

Questa lezione parte da un’idea semplice: valutare un agente non è misurare quanto è bravo in astratto, ma capire se fa il lavoro che gli hai affidato. E questo lo scopri mettendolo alla prova su casi reali, non su test che qualcun altro ha scritto per qualcun altro.

L’idea: il banco di prova batte il benchmark

Un benchmark generico è come testare un’auto da città sui circuiti di Formula 1: ti dice qualcosa sulla velocità massima, poco su come si comporta in salita con due bambini dietro. I benchmark pubblici misurano capacità ampie su domande di cultura generale, ragionamento matematico, comprensione del linguaggio. Sono utili per confrontare modelli diversi prima di sceglierne uno, ma non ti dicono se il tuo agente risponde bene alle domande che i tuoi clienti fanno davvero.

Il banco di prova è l’opposto: un insieme piccolo di casi presi dal tuo lavoro vero, con l’esito che ti aspetti per ciascuno. Non serve un dataset enorme. Dieci casi scelti bene ti dicono più di mille domande casuali, perché quei dieci li hai visti fallire o andare storti nella vita reale. Quando il tuo agente li passa tutti, sai che è pronto. Quando ne sbaglia uno, sai esattamente cosa correggere.

In pratica: costruire il banco di prova

Immagina di aver costruito un agente che risponde alle richieste di assistenza tecnica. Prima di metterlo in mano agli utenti, prendi dieci richieste vere che hai già risolto tu o un collega. Scegli casi che coprono situazioni diverse: una domanda facile, una domanda ambigua dove serve chiedere chiarimenti, una richiesta che esce dal perimetro del supporto, una lamentela mascherata da domanda, una richiesta urgente.

Per ciascuna, scrivi l’esito che ti aspetti. Non la risposta esatta parola per parola, ma il comportamento giusto: «Risponde con la procedura corretta e il link alla documentazione», «Chiede quale versione del prodotto sta usando prima di rispondere», «Spiega che quel servizio non è coperto dal supporto e passa il contatto al commerciale». Questo è il tuo banco di prova.

Ora fai passare il tuo agente su quei dieci casi. Uno per uno, confronti l’esito vero con quello atteso. Dove sbaglia, segni il tipo di errore: ha dato una risposta secca dove serviva una domanda di chiarimento, ha inventato una funzione che non esiste, ha rimbalzato una richiesta che poteva risolvere. Questi errori ti dicono cosa correggere nelle istruzioni o negli strumenti che hai dato all’agente.

Cosa misurare davvero

La tentazione è contare le risposte corrette e fare una percentuale. Il problema è che non tutte le risposte pesano uguale. Un agente che passa nove casi facili e fallisce su quello dove il cliente è arrabbiato non è pronto, anche se la percentuale dice 90%. La valutazione vera guarda tre cose:

Sicurezza. L’agente evita gli errori che fanno danni? Inventare una procedura inesistente, promettere qualcosa che il prodotto non fa, dare un numero di telefono sbagliato: sono errori che non puoi permetterti. Se il banco di prova ne cattura anche uno solo, l’agente va rivisto.

Utilità. Quando l’agente risponde bene, il risultato è davvero spendibile o va comunque riscritto? Una risposta corretta ma fredda, o troppo lunga, o scritta in un tono che non è il tuo, tecnicamente passa il test ma nella pratica ti fa perdere tempo. Il banco di prova ti costringe a decidere cosa significa “risposta utile” per il tuo caso, e a scriverlo nero su bianco.

Copertura. I casi che hai scelto rappresentano davvero la varietà delle situazioni che incontrerai? Se il tuo agente passa tutti i test ma poi fallisce sul primo caso un po’ diverso, il banco di prova era troppo stretto. Questo si scopre solo mettendolo alla prova sul campo, ma puoi partire da casi veri e variegati che hai già visto.

Quando un agente è pronto

Non esiste una soglia universale. Un agente è pronto quando tu saresti tranquillo a lasciarlo lavorare da solo sul tipo di compiti per cui l’hai costruito, sapendo che controllerai comunque il risultato prima che esca. Se il banco di prova ti mostra che l’agente sbaglia in modi che ti accorgeresti subito a controllare, è pronto per una prova sul campo. Se gli errori sono sottili o pericolosi, conviene lavorarci ancora.

La regola pratica è questa: fallo girare su dieci casi nuovi, veri, che non erano nel banco di prova. Se ti trovi a correggere più della metà delle risposte, torna indietro e rivedi le istruzioni o gli strumenti. Se ne correggi due su dieci e le correzioni sono piccole, l’agente è pronto. Il banco di prova ti ha dato un’idea realistica di quello che succederà sul campo.

Una cosa da fare

Prendi un agente che hai già costruito o che stai costruendo. Raccogli cinque casi reali che quell’agente dovrebbe saper gestire. Possono venire da email, ticket, conversazioni vere, appunti di riunioni. Per ciascun caso, scrivi in una riga l’esito che ti aspetti. Non serve un formato complicato: un foglio con due colonne, «input» e «esito atteso», basta.

Fai passare l’agente su quei cinque casi e segna cosa va e cosa no. Ti prenderà meno di un quarto d’ora, e quando hai finito avrai un’idea molto più chiara di quanto sia pronto il tuo agente rispetto a qualsiasi numero di benchmark.

Prompt pronti

Per costruire il banco di prova con l’aiuto di un assistente:

Devo costruire un banco di prova per un agente che [descrizione breve del compito].
Ho questi casi reali che dovrebbe saper gestire:
[incolla 3-5 casi presi dal tuo lavoro]

Per ciascun caso, aiutami a scrivere l'esito che mi aspetto, in termini di comportamento (cosa deve fare l'agente) e non di risposta esatta parola per parola.

Per valutare i risultati dell’agente:

Ho fatto girare il mio agente su [numero] casi del banco di prova.
Casi passati: [descrivi brevemente]
Casi falliti: [descrivi l'input, l'esito atteso, l'esito vero]

Aiutami a classificare i tipi di errore e a decidere se l'agente è pronto per una prova sul campo o conviene lavorarci ancora.

Fallo davvero

Il foglio a due colonne della “una cosa da fare” ha una versione eseguibile, e il corso te la dà già funzionante: il banco di prova automatico, due file, lo script e i casi (casi.json). Il primo giro si fa senza chiave e senza costi:

node esegui.mjs --prova

L’output è la valutazione di cinque casi di smistamento email, con un fallimento lasciato dentro apposta per farti vedere come si presenta: quali parole mancavano nella risposta, quali non dovevano esserci. Le verifiche sono volutamente elementari, presenza e assenza di parole chiave, ed è una scelta: un controllo grezzo che lanci dopo ogni modifica batte una valutazione raffinata che rimandi sempre.

Poi rendilo tuo. Apri casi.json, sostituisci le istruzioni con quelle del tuo agente e i cinque casi con i tuoi, prendendoli dal foglio a due colonne che hai già compilato. Da quel momento ogni modifica alle istruzioni ha un prezzo di verifica di un comando: lo script esce con un errore se anche un solo caso fallisce, quindi puoi metterlo in un flusso automatico che si rifiuta di andare avanti quando qualcosa si è rotto. Il degrado silenzioso visto nel percorso pro diventa rumoroso, che è l’unica cosa che gli impedisce di costarti caro.

Dove andare adesso

Se vuoi approfondire il ragionamento dietro questa lezione e vedere altri esempi di banco di prova costruiti su casi reali, leggi il paper «Valutare un agente senza benchmark». Nel prossimo capitolo, Costi, latenza, sicurezza: reggere fuori dalla demo, vediamo come portare un agente da pronto a robusto, affrontando quello che il banco di prova da solo non cattura.