Il tuo eval per agent è obsoleto — EVA-Bench 2.0 fissa un nuovo standard

ServiceNow AI ha appena pubblicato EVA-Bench 2.0, un dataset pubblico per la valutazione di agent che copre 121 tool, 3 domini e 213 scenari. Per i CTO che hanno approvato un pilot con agent quest'anno, la cosa è rilevante: il benchmark che il tuo team probabilmente sta usando — un mix di demo interne e sensazioni a pelle — ha finalmente un nome, e quel nome è "non abbastanza". La nostra lettura: EVA-Bench 2.0 è il primo artefatto esterno abbastanza concreto da ancorare una conversazione seria sulla production readiness. Se non hai ancora definito la tua superficie di eval, qualcun altro l'ha appena definita al posto tuo.

Cosa è cambiato nel benchmarking degli agent questa settimana

EVA-Bench 2.0, pubblicato da ServiceNow AI su Hugging Face, espande il benchmark originale con un dataset strutturato pensato per testare gli agent su workflow realistici multi-tool. Il benchmark è organizzato in 3 domini distinti — ognuno rappresenta una classe di workload enterprise — e copre 121 tool con 213 scenari costruiti per far emergere i failure mode che gli eval su singolo tool mancano sistematicamente.

La filosofia di design è deliberata. Invece di verificare se un modello riesce a chiamare una sola API correttamente in isolamento, EVA-Bench 2.0 concatena l'uso dei tool su sequenze realistiche — ed è esattamente lì che gli agent in produzione falliscono. Uno scenario può richiedere all'agent di interrogare una knowledge base, incrociare i dati con un sistema di ticketing e produrre un output strutturato — in sequenza, con lo stato mantenuto tra uno step e l'altro. È un test sostanzialmente diverso da "il modello ha scelto il nome della funzione giusto."

Il dataset è pubblico, strutturato per la riproducibilità e con licenza MIT. Significa che il tuo team di engineering può scaricarlo oggi, far girare i propri modelli e ottenere numeri almeno comparabili con quelli che riportano gli altri. Già questo lo mette davanti alla maggior parte degli eval rig interni che vediamo nelle aziende che mandano in produzione il loro primo agent.

Perché il tuo processo di eval attuale probabilmente non regge a questo confronto

La maggior parte dei pilot con agent che analizziamo nel 2026 ha la stessa architettura di valutazione: un set di demo happy-path costruite a mano, qualche edge case che qualcuno ha tirato fuori in un thread Slack, e un bar implicito che si chiama "il PM ha dato l'ok dopo la review di giovedì." Quel processo trova i bug che il tuo team già conosceva. Non trova i failure mode che emergono quando un agent incontra combinazioni di tool che non ha mai visto, o quando una chiamata API al quarto step restituisce uno schema che il tuo prompt non ha mai anticipato.

La superficie da 121 tool di EVA-Bench 2.0 è significativa perché forza una domanda che la maggior parte dei team non si è mai posta formalmente: quanti tool tocca davvero il tuo agent in produzione, e hai valutato il comportamento su ogni combinazione rilevante? Per un agent di customer support che tocca un CRM, una knowledge base, un sistema di ticketing e un'API email, la superficie combinatoria è grande — e il rischio di regressione ogni volta che aggiorni il modello sottostante è reale. Senza un eval strutturato, non saprai che è avvenuta una regressione finché non te lo dice un cliente.

C'è anche un angolo di vendor selection. Se stai valutando framework agent di terze parti o foundation model per la prossima build, EVA-Bench 2.0 ti dà un vocabolario condiviso per chiedere numeri comparabili ai vendor. "Come performa il tuo modello su EVA-Bench 2.0 dominio 2" è una domanda di procurement più difendibile di "puoi mostrarci una demo che assomigli al nostro use case."

Prenota un architecture audit con Domani AI →

La mossa del lunedì mattina dipende da dove si trova il tuo agent nel suo ciclo di vita

La risposta giusta a EVA-Bench 2.0 non è "eseguire l'intero benchmark su tutto." È diagnostica. Inizia rispondendo a 5 domande sul tuo agent attuale:

• Quanti tool distinti chiama in produzione? Se la risposta è più di 5, quasi certamente hai failure mode non coperti nelle sequenze multi-step.
• Hai una suite di eval scritta, separata dagli script di demo? Se la demo e l'eval sono lo stesso artefatto, non hai un eval.
• Hai testato il comportamento dopo l'ultimo aggiornamento di versione del modello? La maggior parte dei team non ha eseguito una regressione strutturata dall'inizio del progetto.
• Qual è la tua tassonomia degli errori? Riesci a categorizzare i failure per tipo — selezione del tool sbagliata, estrazione dei parametri errata, output allucinato — o sai solo che qualcosa è andato storto?
• Hai un domain mapping? La struttura a 3 domini di EVA-Bench è una forcing function utile: riesci a mappare il workload del tuo agent su un dominio coerente, o si estende su contesti per cui non è mai stato progettato?

Se hai risposto "no" o "non sono sicuro" a 3 o più di queste domande, la mossa del lunedì è pianificare uno sprint di eval strutturato prima del prossimo push in produzione. Scarica il dataset EVA-Bench 2.0 da Hugging Face, identifica quale dei 3 domini mappa meglio la superficie di tool del tuo agent ed esegui il tuo modello attuale sul sottoinsieme di scenari rilevanti. Non coprirai tutto, ma avrai una baseline documentata — che è già più di quello che possono dire la maggior parte dei team che oggi mandano agent in produzione.

Se sei in una fase precedente del ciclo — stai valutando se costruire o comprare una capacità agent — usa EVA-Bench 2.0 come scaffold per il tuo vendor RFP. Chiedi a qualsiasi provider di modelli o framework di mostrarti i punteggi specifici per dominio. Se non riescono, è un segnale che vale la pena pesare.

Quanto costa farlo, e quanto costa di più non farlo

Eseguire un sottoinsieme di EVA-Bench 2.0 non è gratuito. Uno sprint di eval strutturato — definire gli scenari rilevanti, strumentare l'agent per produrre output registrabili e analizzare effettivamente i failure mode — richiede da 2 a 4 settimane di tempo di engineering, a seconda del tuo setup di osservabilità attuale. Se oggi non hai infrastruttura di eval, aspettati di passare la prima settimana a costruire il harness prima di generare un solo numero utile.

Il costo alternativo è più difficile da quantificare, ma più facile da riconoscere a posteriori: un aggiornamento del modello che fa regredire silenziosamente un workflow critico, un incidente in produzione che si riconduce a un failure di tool-chaining che la tua demo non ha mai toccato, o una decisione di procurement che sembrava difendibile finché i numeri di un vendor si sono rivelati cherry-picked su un benchmark che non corrisponde al tuo stack. EVA-Bench 2.0 non elimina questi rischi — nessun benchmark lo fa — ma ti dà uno standard esterno condiviso su cui fare pressure-test, che è una categoria di difesa diversa da "ha funzionato quando l'abbiamo mostrato al board."