Il punteggio che vi hanno mostrato misura il modello. Voi comprate un sistema

Model evaluation e system evaluation misurano cose diverse, e il mercato le usa come se fossero la stessa. TTFT, inter-token latency, throughput e SLO dichiarati: come si costruisce una valutazione che vale per la vostra azienda.

BlueSky Agent AI · 2026-09-03

Quando un fornitore di AI porta in riunione una classifica di benchmark, quella classifica risponde a una domanda che non è la vostra. Misura quanto è capace un modello su compiti generici e dataset noti. Non dice come si comporterà l'applicazione che state comprando, sui vostri documenti, con i vostri tempi di risposta.

La distinzione ha un nome tecnico e IBM l'ha messa per iscritto in un intervento di fine agosto 2026: da una parte la model evaluation, dall'altra la system evaluation. Sono due misure diverse e nel mercato vengono usate come se fossero la stessa.

Le due valutazioni, con i termini giusti

La model evaluation stabilisce quanto è "intelligente" un modello. Gli strumenti sono i benchmark pubblici tipo MMLU, e il risultato è un numero confrontabile fra modelli. Serve a chi sviluppa modelli. A chi compra un prodotto dice poco, perché il prodotto è fatto anche di prompt, strumenti, memoria, controlli e infrastruttura.

La system evaluation misura il prodotto in esercizio. Le grandezze sono altre:

• Time to First Token (TTFT), cioè quanto passa dalla richiesta alla prima parola della risposta. È quello che l'utente percepisce come lentezza.
• Inter-Token Latency (ITL), la velocità con cui la risposta si completa una volta partita.
• Throughput, quante richieste il sistema regge in parallelo prima di degradare.
• Service Level Objective dichiarati. L'esempio portato da IBM è il 99% delle richieste sotto i 300 millisecondi: un impegno verificabile, non un aggettivo.

Sopra a tutto sta il triangolo fra accuratezza, prestazioni e costo. I vertici si muovono insieme e nessun sistema li massimizza contemporaneamente. Ma chi vi dice il contrario di solito sta guardando un vertice solo.

Per gli agenti non basta guardare il risultato

Un agente non produce una risposta. Produce una catena: riceve un input, decide, chiama uno strumento, riceve un esito, decide di nuovo, produce un output.

La valutazione di un agente è quindi gerarchica. Ogni passo della catena va verificato su sicurezza e formato, e poi sull'accuratezza di quello che ha prodotto. Guardare solo l'esito finale nasconde il caso peggiore, che è l'agente che arriva alla risposta giusta passando da una chiamata sbagliata. Funziona finché non funziona più, e quando smette nessuno sa da dove ricominciare a guardare.

Un esempio dal lavoro quotidiano: un agente che prepara un'offerta può produrre un documento corretto avendo letto il listino sbagliato, perché il totale coincideva per caso. Sul risultato finale il test passa. Sul singolo passo, no.

Quello che è successo a un modello, tre settimane fa

Il 14 agosto 2026, su OpenRouter, è comparso un modello senza nome, con un milione di token di contesto e gratuito per un periodo promozionale. I primi benchmark pubblici lo davano intorno all'80% su DeepSWE, sopra diversi modelli di punta. Tre giorni dopo, rimisurato su benchmark privati, era al 63%. Nel frattempo non aveva ricevuto aggiornamenti. Era cambiato chi misurava e con quali dati.

Quella storia era la prova. Questa è la spiegazione: i benchmark pubblici usano dataset noti agli sviluppatori dei modelli, e misurano una capacità generica. Un benchmark privato costruito su casi che il modello non ha mai visto misura qualcos'altro, e i due numeri non sono paragonabili anche quando hanno lo stesso nome.

Per un'azienda che deve decidere, la conseguenza operativa è che nessuna delle due classifiche è la sua. La sua misura si costruisce sul suo compito.

Come si costruisce una valutazione che vale per voi

Serve meno tempo di quanto si pensi. Ecco cosa mettere insieme.

Un campione di casi reali presi dai vostri archivi. Fra i trenta e i cinquanta bastano per la maggior parte dei processi documentali. Vanno scelti includendo i casi storti, non solo quelli puliti, perché è lì che i sistemi si differenziano.

Un criterio di successo scritto prima di iniziare. "Estrae correttamente data, importo e controparte da un contratto" è un criterio. "Funziona bene" non lo è, e ha il difetto di adattarsi al risultato che si ottiene.

Gli SLO che vi servono davvero. Un agente che risponde in due secondi va benissimo per un'elaborazione notturna e non va bene in un centralino. Dichiararlo prima evita di comprare velocità che non usate o di scoprire dopo che ve ne serviva.

Il costo per unità di lavoro completata. Non per token e nemmeno per postazione. Per pratica evasa, per ticket chiuso, per offerta preparata. È l'unico numero che il controllo di gestione può confrontare con quello che spendete oggi.

Cosa fa ModelMatch con questi quattro pezzi

ModelMatch è il motore di routing che sceglie quale modello usare per ciascuna fase di un processo agentico. La parte interessante rispetto a questo articolo è come arriva a quella scelta: eseguendo esattamente il tipo di valutazione descritto sopra, sul compito del cliente, con i suoi documenti e i suoi obiettivi di servizio.

Sui progetti in cui è attivo la riduzione media dei costi è del 42% a qualità invariata. Il dato va letto per quello che è: una media su progetti di natura diversa, dove il guadagno arriva soprattutto dalle fasi in cui un modello grande stava facendo un lavoro che un modello piccolo fa uguale. Su un processo composto da un solo passo difficile il margine è molto più stretto, e in qualche caso è nullo.

La frase che ci interessa poter dire in una riunione non è "il nostro modello è migliore". È "abbiamo valutato il sistema sul vostro compito, con i vostri SLO, e questi sono i numeri".

Cosa portarsi via

• La model evaluation misura il modello con benchmark pubblici. La system evaluation misura il prodotto in produzione con TTFT, inter-token latency, throughput e SLO dichiarati. Un fornitore che vi porta solo la prima vi sta mostrando la metà che non comprate.
• Gli agenti si valutano passo per passo, sul singolo input, sulla chiamata allo strumento e sull'output, verificando sicurezza, formato e accuratezza. Un risultato finale corretto può nascondere una catena rotta.
• Il caso del 14 agosto (80% al primo test, 63% al ricontrollo tre giorni dopo, modello invariato) mostra quanto pesa il metodo di misura rispetto al modello misurato.
• Una valutazione utile in azienda si costruisce con 30-50 casi reali, un criterio di successo scritto prima, gli SLO che servono davvero e il costo per unità di lavoro completata.

Se avete una decisione su un fornitore AI in corso, chiedete di vedere la valutazione fatta sui vostri dati. Se la risposta è una classifica pubblica, la decisione non è ancora pronta.