Punteggi dei benchmark IA: quando i numeri misurano altro

Ogni giorno aziende e sviluppatori leggono i punteggi dei benchmark per scegliere quali modelli di intelligenza artificiale adottare. Quattro ricerche pubblicate su arXiv a ottobre 2026 raccontano un problema concreto. Quei numeri spesso misurano altro rispetto a ciò che conta davvero. Esempi vanno dal rischio fisico di un robot urbano alla sicurezza di un assistente domestico.

Quando i modelli più grandi misurano altro ma non decidono meglio

Un sistema agentico per l’automazione domestica open source fa chiamate molto diverse a un modello linguistico. Interpreta l’intenzione dell’utente, classifica azioni e collega le parole ai dispositivi reali. Pianifica inoltre pipeline multi-agente e scrive il codice che le esegue. In pratica, però, un unico modello, scelto per il compito più difficile, serve tutti i punti di chiamata. Una ricerca ha valutato 9 modelli sulle cinque funzioni del sistema. Secondo arxiv.org, la gamma andava dai piccoli open source da 0,8 miliardi di parametri fino a un modello ospitato di frontiera. I test usavano installazioni reali di Home Assistant con 280 casi di test.

Il risultato ribalta l’intuizione comune: la capacità non si ordina allo stesso modo in ogni compito. Secondo arxiv.org, un modello da 4 miliardi di parametri risulta peggiore del suo fratello da 2 miliardi nell’azione ancorata ai dispositivi. Il miglior modello locale è statisticamente indistinguibile dai modelli ospitati in quattro compiti su cinque: solo la scrittura di codice li separa davvero.

Instradare ogni compito al miglior modello locale raggiunge il 91,8% di accuratezza contro il 95,4%, senza costi aggiuntivi per chiamata.

C’è anche un problema di sicurezza che l’accuratezza aggregata nasconde. Un modello piccolo esegue comandi su dispositivi non posseduti dal sito nell’87,2% dei casi, mentre un altro si rifiuta di fare qualsiasi cosa. Nella prova dal vivo, ospitare solo le due funzioni generative ottiene lo stesso punteggio di 39 casi riusciti su 43. Questa configurazione spende però solo il 28% del budget. È una lezione per chi teme che i modelli piccoli non bastino mai.

I giudici del benchmark sbagliano pure loro

La fiducia nei punteggi vacilla anche a monte. Le verifiche basate sull’esecuzione decidono se un agente ha completato un compito. Sono state messe alla prova con test di mutazione su due piattaforme diffuse. In AppWorld, duplicando una scrittura non ripetibile si crea un record in più a parità di ogni campo verificato. Il verificatore accetta questo sotterfugio in 6 combinazioni su 15 esaminate. Il controllo dichiara successo anche quando l’effetto è sbagliato.

In WorkArena, i ricercatori hanno riesaminato 23 candidati che avevano superato il controllo. Una lettura indipendente conferma valori persistenti non corretti in 21 casi, e due stringhe richieste erano semplicemente alias di valori predefiniti. I controlli, però, non sono ciechi ovunque: su una griglia di scambi di intenti restituiscono zero successi su 2.689 esecuzioni fuori diagonale. Il quadro è quindi sbilanciato, non rotto: i falsi positivi esistono, ma sono costruiti in modo specifico. Per un’azienda che valuta fornitori in base a questi punteggi, il dato conta: un caso su 23 può essere un successo di carta.

Anche i test di memoria portano con sé errori nascosti

Il terzo filone guarda a un benchmark di memoria per agenti, MemoryAgentBench, e alla sua sezione sulla risoluzione dei conflitti tra informazioni. I ricercatori hanno eseguito la regola del benchmark stesso, la dichiarazione più recente su un fatto vince, come risolutore senza alcun apprendimento. La regola risponde correttamente all’80,25% delle domande secondo la metrica ufficiale: un banale criterio di recency batte sistemi sofisticati.

Il resto del punteggio nasconde una scorta di domande irraggiungibili. Su 67 casi, la risposta corretta dichiarata dal benchmark contraddice la regola stessa. Un esempio celebre richiede “Grosseto” come capitale dell’India. New Delhi è in realtà la risposta corretta. Un terzo delle domande multi-passaggio a scala grande è irraggiungibile in linea di principio. Due modelli a lungo contesto e una re-implementazione fedele dell’agente di riferimento ottengono rispettivamente 84,7%, 82,6% e 41,6% sui casi risolvibili. Ma crollano tra il 6% e l’11,9% sui 67 irraggiungibili. Confrontare modelli su un aggregato che mescola errori veri e domande impossibili, in altre parole, produce classifiche fuorvianti.

Quando la fisica non aspetta che il modello ragioni

Il quarto lavoro sposta il discorso dal digitale al mondo fisico. Nel contesto dell’intelligenza artificiale applicata a robot e veicoli, un’azione sicura al momento dell’osservazione può diventare pericolosa prima dell’esecuzione. I pedoni si muovono e le auto si avvicinano. Il benchmark RT-Safe simula un ambiente urbano con attori mobili, pericoli ambientali e regole stradali, lasciando che il mondo evolva mentre il modello ragiona.

I risultati sono impietosi. Su otto modelli visione-linguaggio, gli agenti completano i compiti con alti punteggi. Quasi nessuno li completa però senza incidenti: solo lo 0,7% degli episodi nel caso più difficile. Il confronto tra valutazioni statica e in tempo reale è il dato più sorprendente. Il completamento dei compiti passa dal 91,3% al 94,1%. Le collisioni aumentano però di 12,3 volte. Chi legge solo il tasso di successo vede un’IA eccellente; chi guarda la strada vede macchine che investono. Il segnale positivo è che l’addestramento con apprendimento per rinforzo su questo benchmark riduce sensibilmente le collisioni mantenendo buoni compiti completati.

Che cosa cambia da qui

Le quattro ricerche convergono su un punto che riguarda chiunque debba scegliere, acquistare o regolamentare sistemi di IA: l’aggregato nasconde, il dettaglio rivela. Un punteggio medio non distingue tra codice e semplice interpretazione di intenti. Non distingue nemmeno tra successo reale e verificatore ingannato, né tra questione impossibile e fallimento del modello. Ignora infine la differenza tra azione sicura e incidente evitato per caso. Per sindacati, HR e responsabili IT che devono valutare l’impatto di questi sistemi sul lavoro, la domanda giusta non è più “quanto scala?”. Ma “misurato come, e su quali casi?”. Rimane aperto il nodo più scomodo: chi produce i benchmark è spesso chi vende i modelli. Le correzioni alle verifiche arrivano solo quando qualcuno indaga. I test di mutazione lo mostrano chiaramente. Finché la verifica resterà interna, il numero sul tabellone continuerà a raccontare una storia più tranquilla della realtà.

Fonti:

• Not Every Call Needs a Frontier Model: Per-Call-Site Evaluation of… | arxiv.org
• Finding Blind Spots in AppWorld and WorkArena Task Verifiers | arxiv.org
• Bookkeeping, Composition, or Unreachable Gold? Reading… | arxiv.org
• RT-Safe: Benchmarking Agent Safety in Real-Time Embodied Environment | arxiv.org