Il benchmark non è il tuo lavoro

Gianluca Garofalo

I benchmark raccontano quanto è forte un modello AI in una serie di test, ma non quanto sarà efficace nel lavoro reale. Vorrei partire dal caso Gemini 4 Argon per mostrare perché le aziende dovrebbero costruire una propria suite di valutazione, basata su casi reali, errori, costi e conseguenze.

Lo stesso modello, due storie

Il 30 settembre Google ha presentato Gemini 4 Argon, il suo nuovo modello di punta. Il comunicato è quello di un vincitore: fino a un milione di token generati in una sola risposta, contro i 64.000 della versione precedente, e risultati da primato su lavoro d'ufficio, diritto, finanza e sicurezza informatica. Secondo VentureBeat, su 18 benchmark dichiarati Argon è primo in 12 e pari in uno.

Lo stesso giorno è uscita un'altra storia. Bloomberg, ripreso da Implicator e Byteiota, ha raccolto i dubbi di alcuni dipendenti Google che hanno usato il modello: nell'uso pratico, per esempio su certi compiti di programmazione, renderebbe meno di quanto dicono i test. Secondo il resoconto di Implicator, due persone a conoscenza del modello, rimaste anonime, hanno parlato di segnali di "benchmaxxing": un modello ottimizzato per fare bella figura nei test più che per lavorare bene. Google contesta questa lettura.

Il giorno dopo è arrivata la valutazione indipendente di Artificial Analysis, riportata da The Decoder e Trending Topics. Nel suo indice generale Argon ottiene 53 punti, alla pari con GPT-6 Astra di OpenAI e dietro Claude Opus 5.5 di Anthropic (58). Anche i numeri di Google mostrano luci e ombre: secondo The New Stack, Argon guida su DeepSWE ma resta indietro, fino a 10,5 punti, su altri due test di programmazione.

Non so quale delle due storie sia più vicina alla verità, e per ora non lo sa nessuno: il modello è disponibile solo a un gruppo ristretto di specialisti di sicurezza informatica, e Google non ha indicato una data per l'apertura agli sviluppatori e agli abbonati. Ma la domanda giusta è un'altra. Chi deve scegliere un modello per la propria azienda non ha bisogno di sapere chi è primo in classifica. Ha bisogno di sapere quale modello fa meglio il suo lavoro. E nessuna classifica pubblica può dirglielo.

Perché le classifiche si consumano

In economia la chiamano legge di Goodhart, nella formulazione resa celebre dall'antropologa Marilyn Strathern: quando una misura diventa un obiettivo, smette di essere una buona misura. Chi ha lavorato in un'azienda con indicatori di performance la conosce bene. Se premi il numero di ticket chiusi, i ticket si chiudono, non necessariamente i problemi.

Con i modelli di AI succede lo stesso, per tre ragioni.

Il test diventa il bersaglio. Un benchmark pubblico è un insieme fisso di domande. Quando la classifica decide la reputazione di un laboratorio e il prezzo delle sue azioni, l'addestramento finisce per inseguire proprio quei compiti. Non serve malafede: basta che migliorare su quel test sia la cosa più visibile da fare.
Il test finisce nei dati. I modelli si addestrano su enormi quantità di testo raccolto dal web, dove spesso circolano anche le domande dei benchmark e le loro soluzioni. A quel punto il modello può aver visto le risposte, e il punteggio misura in parte la memoria, non il ragionamento.
Il test misura un compito, non un lavoro. Ogni benchmark sceglie un tipo di compito: problemi chiusi, con una risposta verificabile, in un ambiente controllato. Il lavoro reale è fatto di richieste ambigue, documenti incompleti, eccezioni e conseguenze. Il caso Argon lo mostra bene: lo stesso modello va molto bene sui compiti lunghi e strutturati che Google ha messo in evidenza, e meno bene su quelli interattivi che misurano altri.

Questo non significa che i benchmark siano inutili. Servono a capire in che fascia sta un modello e a scartare quelli chiaramente inadeguati. Ma tra due modelli vicini in classifica, la classifica non decide. E lo scarto tra i punteggi dichiarati dai produttori e quelli misurati da valutatori indipendenti, visibile anche questa settimana, è un buon motivo per non prendere i primi come una prova.

Il lavoro vero non sta in classifica

Proviamo a elencare cosa chiede davvero all'AI un'azienda italiana di medie dimensioni. Leggere contratti con clienti e fornitori scritti in un italiano giuridico che cambia da accordo ad accordo e da revisione a revisione. Capire da un'email di un cliente, spesso scritta di fretta e con allegati fotografati, qual è il problema e chi deve occuparsene. Classificare un reclamo e preparare una risposta che rispetti i tempi e il tono richiesti. Spiegare a un collega cosa fa un programma scritto trent'anni fa da qualcuno che non c'è più. Riassumere una circolare o un regolamento senza perdere l'eccezione che conta.

Nessuno di questi compiti compare nei benchmark con cui i laboratori si sfidano. Alcuni ci assomigliano: esistono test sul diritto, sulla finanza, sul codice. Ma un test sul diritto americano non dice nulla su come il modello legge una clausola di recesso in un contratto italiano. E un test su repository moderni dice poco su un gestionale stratificato in decenni di manutenzione.

C'è poi una differenza che le classifiche non vedono: il peso degli errori. In un benchmark ogni risposta sbagliata vale un punto in meno. In azienda un riassunto impreciso di una nota interna è un fastidio; una penale contrattuale ignorata o una scadenza sbagliata comunicata a un cliente sono un costo, un reclamo, a volte un contenzioso. Un modello che sbaglia meno spesso ma sbaglia in modo grave può essere peggiore di uno che sbaglia più spesso su cose irrilevanti. La media non lo mostra.

Per alcuni usi, inoltre, misurare non è solo prudenza. L'AI Act classifica ad alto rischio, tra gli altri, i sistemi usati per selezionare il personale e valutare i candidati, e quelli che valutano i risultati di apprendimento degli studenti. Per questi sistemi chiede di testare le prestazioni rispetto a metriche definite in anticipo e di dichiarare i livelli di accuratezza. Con il Digital Omnibus (regolamento UE 2026/1744, in vigore dal 27 luglio 2026) questi obblighi si applicano dal 2 dicembre 2027, non più dall'agosto 2026. C'è più tempo, ma il principio non cambia: chi mette l'AI in questi processi dovrà poter misurare e documentare come funziona nel proprio contesto, non limitarsi ai numeri di una classifica.

Dalla classifica alla suite di valutazione

Chi ha lavorato nel collaudo del software riconosce subito la soluzione, perché è la stessa di sempre: una suite di test scritta sul proprio dominio, eseguita ogni volta che qualcosa cambia. Con i modelli di AI cambia la natura delle risposte, che non sono mai identiche due volte, ma non cambia il principio. Ecco come la costruirei.

Partire dai casi reali. Da 50 a 100 casi per ogni processo, presi dal lavoro vero e anonimizzati: le richieste dei clienti più difficili, i reclami ambigui, i contratti che hanno generato contestazioni. I casi facili servono poco: il modello li risolve tutti.
Scrivere la risposta attesa prima di provare il modello. La scrive un esperto del processo, non chi sceglie il fornitore. Per i compiti aperti non serve una risposta identica: servono criteri espliciti, per esempio "cita la clausola giusta", "non inventa importi", "segnala quando manca un documento".
Pesare gli errori per gravità. Un errore di forma, un'omissione, un'informazione inventata, una decisione sbagliata non valgono lo stesso. La suite deve dire non solo quante volte il modello sbaglia, ma come.
Ripetere le prove. Lo stesso caso va eseguito più volte: se il modello risponde bene due volte su tre, quel caso non è superato. In produzione conta la stabilità, non il risultato migliore.
Misurare anche costo e tempo. Token consumati, tempo di risposta, tempo che un umano impiega a verificare l'output. Ci torno nella prossima sezione.
Eseguire la suite a ogni cambiamento. Nuovo modello, nuova versione dello stesso modello, nuove istruzioni, nuovi documenti di riferimento: ogni cambiamento è un rilascio, e ogni rilascio passa dalla regressione.

Ecco come possono apparire alcuni casi di una suite per il servizio clienti e l'ufficio contratti. I casi sono inventati a scopo illustrativo.

Email di un cliente con foto allegate e descrizione confusa. Il modello deve individuare il problema, l'ufficio competente e le informazioni mancanti. Errore grave: assegna la pratica all'ufficio sbagliato o inventa un dato che non c'è.
Reclamo per una consegna in ritardo. Il modello deve classificare il reclamo e proporre una risposta nei termini. Errore grave: promette un rimborso o una data che non risultano dagli atti.
Clausola contrattuale con doppia negazione. Il modello deve spiegare in italiano semplice cosa è escluso. Errore grave: inverte il significato della clausola.
Vecchio programma che calcola sconti e listini. Il modello deve descrivere la logica e le eccezioni. Errore grave: omette un caso particolare presente nel codice.

La suite non è un progetto una tantum. È un patrimonio che cresce: ogni errore trovato in produzione diventa un nuovo caso di prova. Dopo un anno, quell'insieme di casi racconta il vostro lavoro meglio di qualsiasi documento.

Il prezzo di listino non è il costo

Il caso Argon offre anche una lezione di contabilità. Google lo propone a un prezzo introduttivo di 2 dollari per milione di token in ingresso e 10 in uscita, destinato a raddoppiare a 4 e 20 dopo il periodo promozionale, di cui non è indicata la fine. Sembra un prezzo aggressivo. Ma i token non sono il lavoro: sono la materia prima. Conta quanti ne servono per finire un compito.

Artificial Analysis lo ha misurato sul proprio insieme di prove, secondo quanto riportano The Decoder e Trending Topics:

Gemini 4 Argon, a prezzo introduttivo: 53 punti nell'indice, circa 62.000 token in uscita per compito, 1,99 dollari per compito.
GPT-6 Astra: 53 punti, circa 27.000 token per compito, 3,26 dollari per compito.
Claude Opus 5.5: 58 punti, 5,98 dollari per compito.

Argon è il più economico per compito, ma usa più del doppio dei token di GPT-6 Astra per arrivare allo stesso punteggio. Il vantaggio viene dal prezzo unitario basso, non dall'efficienza. Artificial Analysis ha fatto anche il conto a prezzo pieno: con le tariffe standard di 4 e 20 dollari, il costo per compito di Argon sale a 3,98 dollari, e il vantaggio sui 3,26 di GPT-6 Astra scompare (dato riportato da OfficeChai).

E c'è un costo che nessuna tabella dei fornitori include: il tempo della persona che controlla l'output. Qui il dato più interessante su Argon non è il prezzo. Nel test AA-Omniscience di Artificial Analysis, Argon ha un tasso di allucinazione del 15%, contro il 51% di GPT-6 Astra: il più basso tra i modelli sopra i 45 punti dell'indice. Va letto bene. Non significa che Argon sbagli il 15% delle risposte: AA-Omniscience conta, tra le domande a cui il modello non risponde correttamente, quante volte dà una risposta sbagliata invece di astenersi. Il 15% descrive quindi un modello prudente, che quando non sa preferisce dirlo. In produzione, sapere quando non rispondere può valere quanto sapere rispondere. Riguarda 6.000 domande di conoscenza su 42 materie, non i vostri processi. Se lo stesso comportamento si conferma sui vostri casi, un modello che si astiene invece di inventare può costare di più in token e meno in verifiche.

La formula da usare è semplice: costo per compito svolto correttamente, cioè costo dei token, più tempo di verifica umana, più costo atteso degli errori sfuggiti, diviso il numero di compiti superati. Si calcola solo con una suite come quella descritta sopra. Senza, si confrontano listini.

Il vero vantaggio è saper misurare

Google non ha ancora detto quando Argon sarà disponibile a sviluppatori e abbonati. Quando succederà, sapremo se avevano ragione i comunicati o i dipendenti scettici. Probabilmente un po' entrambi. Poi uscirà un altro modello, con un'altra classifica e un altro titolo sul "nuovo leader". Il ciclo si ripete ormai ogni poche settimane.

Un'azienda che sceglie inseguendo le classifiche resta in balia di quel ciclo: cambia fornitore quando cambia il titolo, e scopre in produzione se ha fatto bene. Un'azienda che ha una propria suite di valutazione fa un'altra cosa: prova il nuovo modello sui propri casi, in un pomeriggio, e decide con numeri suoi. A volte la risposta sarà cambiare. Più spesso sarà restare dove si è.

I modelli si comprano, e tra un anno saranno diversi. I casi di prova, le risposte attese, i criteri per pesare gli errori no: nascono dall'esperienza di chi fa il lavoro, e nessun fornitore può venderli. Per un'azienda è l'unico pezzo dell'AI che possiede davvero. Conviene cominciare a costruirlo prima del prossimo comunicato.

Fonti

Pubblicato il 02 ottobre 2026

Gianluca Garofalo / AI Responsabile & Governance | Automazione Strategica | Associate Manager @Accenture | Comitato Tecnico Scientifico @ENIA

https://ggarofalo-dev.github.io/