Come valutare gli agenti AI: dalle chiamate agli strumenti al completamento dei task

In Breve

Perché la correttezza di una singola chiamata non è sufficiente?

Perché un agente può selezionare lo strumento giusto e compilare correttamente gli argomenti senza completare l’operazione o aggiornare lo stato dell’ambiente.

Quali sono i due livelli principali di valutazione?

Lo scoring a livello di step analizza la validità e l’utilità di ogni azione; quello end-to-end verifica se lo stato finale corrisponde all’obiettivo.

Quali metriche dovrebbero essere riportate?

NVIDIA indica tasso di successo e consistenza, precisione delle chiamate e degli argomenti, step per task completato e costo per successo.

Valutare un agente AI sulla correttezza di una singola chiamata a uno strumento non basta a stabilire se sia in grado di completare un’attività reale. Secondo NVIDIA, i benchmark per sistemi agentici devono seguire l’intera catena di esecuzione: scelta dello strumento, compilazione degli argomenti, gestione degli errori e verifica dello stato finale dell’ambiente.

Il tema è affrontato in un’analisi pubblicata il 21 settembre 2026 sul blog tecnico di NVIDIA e firmata da Sophia Abbassi, Chris Alexiuk, Davide Onofrio e Gomathy Venkata Krishnan.

Dalla correttezza delle chiamate al risultato finale

I primi framework di valutazione dei modelli linguistici erano pensati per attività statiche, nelle quali la qualità della risposta poteva essere misurata attraverso il testo prodotto. Gli agenti, osserva NVIDIA, operano invece su task multi-step: chiamano strumenti, ricevono risultati, aggiornano il contesto e devono reagire agli errori.

Il Berkeley Function-Calling Leaderboard, citato nell’articolo, valuta la selezione delle funzioni e la correttezza degli argomenti in scenari single-turn e multi-turn. Una chiamata formalmente corretta, però, non garantisce che l’operazione sia stata portata a termine: un’azione come issue_refund può fallire se i controlli o gli aggiornamenti sottostanti non vengono eseguiti.

Per questo NVIDIA propone di eseguire ogni chiamata in un ambiente capace di mantenere lo stato tra i passaggi e di verificare il risultato ottenuto.

Due livelli di scoring

La valutazione si basa su due livelli applicati alla stessa traccia di esecuzione, cioè al registro ordinato del messaggio dell’utente, delle azioni dell’agente e dello stato dell’ambiente:

• Scoring a livello di step: verifica se ogni chiamata è valida, pertinente e utile rispetto allo stato corrente. Serve soprattutto per individuare il punto in cui la catena si interrompe e orientare il debugging.
• Scoring end-to-end: ignora il percorso seguito e controlla se lo stato finale corrisponde all’obiettivo, per esempio se un rimborso è stato registrato o se un ticket è stato instradato correttamente.

Secondo NVIDIA, il risultato end-to-end è quello più vicino all’esperienza dell’utente e dovrebbe avere un ruolo centrale nelle decisioni di rilascio. Le metriche a livello di step restano necessarie per capire l’origine di un fallimento.

La gerarchia delle metriche

Il modello di valutazione descritto nel post organizza i dati secondo una gerarchia fissa: benchmark, trial, task, turn e step. Un trial è un passaggio indipendente sull’intero insieme di task con una configurazione invariata; un task è una singola istanza valutabile; un turn delimita uno scambio tra messaggio in ingresso e risposta dell’agente; uno step è un’azione atomica, come una chiamata a uno strumento, un comando, un piano o il messaggio finale.

Le metriche principali sono distribuite su tre assi:

• Accuratezza: tasso di successo del task, consistenza tra più trial, precisione delle chiamate agli strumenti e correttezza degli argomenti.
• Verbosity: numero di step per task completato, utile per misurare quanto è lunga la traiettoria necessaria a raggiungere il risultato.
• Costo: spesa per task completato, che può includere token e secondi di calcolo su GPU.

NVIDIA sottolinea che il tasso di successo dovrebbe essere accompagnato dall’intervallo osservato su tre-cinque trial. Un sistema che raggiunge il 90% in una prova e il 74% in un’altra non è equivalente a uno stabile all’84%. Allo stesso modo, la precisione delle chiamate non dovrebbe essere separata dalla correttezza degli argomenti.

Le chiamate parallele possono ridurre il numero di step e la latenza, ma non il numero complessivo di chiamate emesse: un singolo turn che attiva quattro strumenti rappresenta comunque quattro chiamate.

Perché i benchmark non sono sempre comparabili

Due benchmark che dichiarano di misurare il tool calling possono produrre risultati difficili da confrontare. NVIDIA individua tre fattori principali:

• Complessità del task: un’operazione single-turn con un solo strumento non misura la capacità di pianificare, recuperare da un errore o gestire una sequenza lunga.
• Stato dell’ambiente: i benchmark stateful aggiornano il mondo a ogni azione e possono far emergere perdita di contesto, deriva o corruzione dello stato.
• Metodo di verifica: i controlli eseguibili, come l’aggiornamento di un database o il superamento dei test, sono indicati come il riferimento preferibile. Le valutazioni basate su risposte annotate richiedono invece il mantenimento di set di riferimento, mentre il giudizio di un altro modello dovrebbe essere validato rispetto a valutazioni umane.

Il post osserva inoltre che il rischio di contaminazione non riguarda soltanto i dati di addestramento. Gli agenti con accesso al web possono recuperare soluzioni durante la valutazione, mentre i dataset pubblici possono essere riutilizzati nei corpus di pretraining. Le valutazioni private costruite su dati di dominio riducono questo rischio.

Un esempio su SWE-bench Verified

NVIDIA riporta una traccia pubblica relativa a SWE-bench Verified, una suite basata su issue reali di GitHub e sulla verifica eseguibile tramite test. Nel caso descritto, l’agente OpenHands ha lavorato su un problema di pytest relativo a _pytest.capture.EncodedFile: l’oggetto riportava la modalità binaria del buffer sottostante, ma il metodo write() accettava solo stringhe.

La traccia comprendeva strumenti per il terminale, la modifica dei file, il monitoraggio del task e la chiusura dell’attività. Lo stato del repository persisteva tra i turn e le chiamate parallele erano disattivate. Una delle quattro azioni è stata giudicata ridondante perché l’agente ha visualizzato un file di oltre 400 righe prima di restringere la ricerca alla classe interessata.

Il controllo end-to-end e i test hanno avuto esito positivo. La traccia ha ottenuto un punteggio di 1 sul risultato finale, 3/4 a livello di step, 3/4 nella precisione delle chiamate e 4/4 nella correttezza degli argomenti. L’esempio mostra, secondo NVIDIA, come un task possa essere completato anche quando il percorso contiene un passaggio non necessario.

Il caso Nemotron 3.5 Lightning

NVIDIA presenta Nemotron 3.5 Lightning attraverso metriche di completamento dei task e tempo necessario per portarli a termine, invece di limitarsi alla correttezza delle singole chiamate. Nel materiale citato, il modello raggiunge l’86% di accuratezza su PinchBench e completa 10.000 task fino al 30% più velocemente di Qwen3.6 35B a un livello di accuratezza comparabile.

Il post cita anche Banking, che misura il completamento di conversazioni bancarie multi-turn, e GDPval-AA v2, che valuta lavori agentici reali attraverso confronti a coppie esaminati da giudici basati su modelli linguistici. Per quest’ultimo benchmark, NVIDIA riferisce che il punteggio Elo è ancorato a una baseline di 1.000 esperti umani.

Questi dati sono risultati pubblicati da NVIDIA e non costituiscono, da soli, una verifica indipendente delle prestazioni. La stessa azienda precisa che i punteggi pubblici dovrebbero rappresentare un riferimento iniziale, non il solo criterio per autorizzare il rilascio di un agente.

Come costruire una valutazione per l’impresa

Per adattare il processo al proprio contesto, NVIDIA suggerisce di partire da una suite pubblica e di fissare un livello minimo, registrando il tasso di successo e la sua variabilità su più trial. Il passaggio successivo consiste nel creare una valutazione di dominio basata su ticket, tracce e API reali.

• Verificare lo stato dell’ambiente, come una riga di database modificata, una pull request integrata o un ticket chiuso.
• Adattare modello e harness alla distribuzione di task effettivamente osservata.
• Misurare nuovamente successo, consistenza, step per successo e costo per successo.
• Conservare le tracce a livello di step per le attività di debugging.
• Usare i giudizi linguistici per valutare il testo e le metriche di precisione degli strumenti per individuare i punti di rottura della catena.

La conclusione dell’analisi è che il tool calling è ormai parte integrante della valutazione degli agenti. Per sistemi destinati a operare in ambienti reali, il parametro decisivo non è soltanto la capacità di produrre una risposta corretta, ma la possibilità di raggiungere in modo ripetibile lo stato desiderato.