Un benchmark è un insieme di scenari di valutazione riprodotti automaticamente su una pipeline. È lo strumento per misurare oggettivamente la qualità di un agent e rilevare le regressioni prima che arrivino in produzione.
Perché
Un agent che "sembrava funzionare" può regredire silenziosamente dopo:
- una modifica della missione;
- un cambio di modello LLM;
- l'aggiunta di un nuovo tool.
Senza benchmark, lo scopri in produzione. Con un benchmark, lo vedi all'esecuzione successiva — prima dei tuoi utenti.
Anatomia di uno scenario
Uno scenario contiene:
- Uno stimolo — l'input che la pipeline riceve (messaggio o sequenza di turni, fixture di dati).
- Dei controlli — asserzioni esplicite valutate su ogni turno: l'output prodotto, la forma della risposta, la catena di chiamate ai tool, il costo delle azioni.
Catalogo dei controlli
| Controllo | Verifica |
|---|---|
pipeline_output_match | Una chiave del flusso di uscita corrisponde al valore atteso (percorso + asserzione) |
response_shape | La forma della risposta dell'agent (lunghezza, struttura), misurata senza giudice |
llm_rubric | Il contenuto della risposta, valutato da un giudice LLM su una rubrica di criteri verificabili |
tool_chain_analysis | La sequenza di chiamate ai tool segue la strategia attesa |
tool_cost | Il budget di azioni: ogni chiamata ha un costo, raggiungere l'obiettivo dà un bonus |
static / tests / diff_quality | Controlli orientati a file e codice (output di una pipeline di sviluppo) |
Il catalogo è estensibile lato piattaforma: ogni controllo è un plugin registrato lato server.
Creare un benchmark
- Applicazioni → Évaluation → Scénarios.
- Crea gli scenari (stimolo, controlli, fixture di dati); ogni scenario è dedicato a un modello (la pipeline di destinazione). Le fixture si gestiscono nella scheda Fixtures.
Uno scenario può anche essere creato o modificato tramite proposta dal server MCP (benchmark_create / benchmark_update), che resta in attesa fino alla sua accettazione.
Un buon benchmark include un mix: caso nominale, casi limite, casi avversariali (tentativi di manipolazione, ambiguità, dati mancanti).
Eseguire un benchmark
Dal pannello di amministrazione, avvia una esecuzione: viene messa in una coda durevole e poi eseguita da un worker dedicato, al di fuori del server web. Se questo worker si arresta nel mezzo di un'esecuzione, l'esecuzione viene contrassegnata come fallita al riavvio (non viene ripresa automaticamente): rilanciala. Un drawer fornisce il dettaglio per scenario.
Il report mostra:
- Tasso di successo per controllo
- Evoluzione dei punteggi tra le esecuzioni (schede Historique ed Évolution)
- Elenco degli scenari falliti, con il dettaglio di ogni controllo
Buone pratiche
- Inizia in piccolo — 5 scenari ben mirati valgono più di 50 approssimativi.
- Esegui il benchmark prima di ogni pubblicazione, e confronta con l'esecuzione precedente prima di rilasciare.
- Versiona le tue missioni. Non solo le pipeline: anche le missioni evolvono.
- Mantieni i controlli leggibili. Un controllo che richiede 20 righe di spiegazione per essere compreso è un controllo che va scomposto.