LLM benchmark: quali punteggi contano per il tuo lavoro

I risultati di un LLM benchmark dovrebbero aiutare a scegliere cosa testare. SWE-bench Verified misura le prestazioni su 500 problemi software selezionati; un punteggio elevato non dice se un agente sappia rispettare le regole sui rimborsi della tua azienda. Prima di guardare il numero che vince, leggi il compito, la configurazione del test e il criterio di valutazione.

Verificato sulle pagine degli autori dei benchmark e sulla scheda del modello di Google il 15 ottobre 2026. Le descrizioni che seguono spiegano i test; i punteggi dell'esempio sono quelli pubblicati da Google. L'interpretazione e la checklist di valutazione sono nostre.

Per un assistente di programmazione, parti dai compiti su repository o terminale. Per un agente di assistenza clienti, dall'uso degli strumenti durante la conversazione e dal rispetto delle procedure. Per un assistente documentale, dal ragionamento su contesti lunghi. Un punteggio sulle conoscenze generali può contribuire alla scelta, ma non basta a determinarla.

Che cosa misura un LLM benchmark?

Un benchmark misura le prestazioni su un insieme preciso di compiti, secondo regole precise. Assomiglia più a una gara sportiva che a un certificato di intelligenza: il tempo in una gara di velocità dà un'informazione utile, ma non stabilisce chi debba guidare un soccorso in montagna.

Il dataset contiene le domande o i compiti. Il protocollo di valutazione definisce cosa riceve il modello, quali aiuti può usare e come viene giudicato il risultato. L'harness, chiamato anche scaffold, è il software che circonda il modello: prompt, strumenti e ciclo di esecuzione.

La distinzione conta quando un annuncio sostiene che un modello sa programmare. Scrivere una funzione a partire da un breve prompt è un lavoro diverso da quello di un agente che esplora un repository, modifica file, esegue test e recupera dopo un errore. In quest'ultimo caso, il punteggio appartiene al sistema nel suo insieme, harness incluso.

La classifica di SWE-bench rende evidente questa differenza separando le configurazioni di valutazione, tra cui un ambiente condiviso mini-SWE-agent. Il prodotto che usi per programmare può offrire strumenti, istruzioni o limiti diversi. Prima di applicare quel punteggio al tuo flusso di lavoro, identifica il software che affiancava il modello durante il test.

I nomi dei benchmark AI negli annunci dei modelli

Prima di confrontare i punteggi, abbina il benchmark al lavoro da svolgere. Queste sono le famiglie da riconoscere negli annunci del 2026 dedicati ai modelli generalisti, alla programmazione e alla voce, insieme ai test sul contesto che aiutano a interpretarli. Ogni nome rimanda alla pagina o al repository dei suoi autori.

Accompagna sempre il nome con la versione. HLE-Diamond contiene 1,000 domande perfezionate, mentre la versione definitiva di HLE originale ne contiene 2,500. Terminal-Bench 4.0 ha modificato risorse e compiti. Il repository attuale di tau documenta sia nuove modalità sia correzioni dei criteri di valutazione. Due numeri pubblicati in momenti diversi potrebbero riferirsi a esami diversi, senza dimostrare un miglioramento del modello.

Quali punteggi contano per il tuo lavoro?

Scegli la famiglia che assomiglia al tipo di errore da prevenire. Chi fonda un'azienda e sceglie una funzione AI, un CTO che approva un agente e chi gestisce i ticket di assistenza non dovrebbero attribuire lo stesso peso a ogni riga di una tabella di lancio.

Benchmark per agenti di programmazione

Chi sviluppa e mantiene un prodotto esistente dovrebbe partire dalla risoluzione di problemi nei repository e dal lavoro da terminale. SWE-bench offre indicazioni utili sulla risoluzione delle issue; Terminal-Bench sull'esecuzione di attività in una shell. LiveCodeBench e HumanEval aiutano a rispondere a domande più circoscritte sulla programmazione. Nessuno di questi test, da solo, misura la manutenibilità di una patch nella tua base di codice.

Immagina uno sviluppatore indipendente che chiede a un agente di modificare la cancellazione degli account. Produrre una funzione di supporto corretta è solo una parte del lavoro. L'agente deve individuare tutti i punti di chiamata interessati, preservare i permessi, aggiornare i test ed evitare incoerenze nei dati dei clienti. La valutazione dovrebbe includere l'intera modifica, con lo stesso accesso al repository e gli stessi strumenti che intendi mettere a disposizione.

Criterio di scelta: se il lavoro coinvolge più file e passaggi di esecuzione, richiedi risultati su compiti svolti da agenti prima di selezionare i candidati. Usa i punteggi sulle singole funzioni come informazioni di supporto. Mantieni la revisione del codice tra i criteri di accettazione finché i tuoi casi non giustificano una riduzione dei controlli.

Benchmark di ragionamento degli LLM

GPQA, HLE, MMLU-Pro, AIME e ARC-AGI esplorano forme diverse di ragionamento. Indicano capacità da approfondire, soprattutto quando un compito richiede di risolvere problemi scientifici o matematici difficili. Sostituiscono male, però, una verifica diretta del rispetto delle tue regole operative.

Le 198 domande di GPQA Diamond costituiscono un insieme scientifico selezionato appositamente. Un CTO che valuta un assistente interno per la ricerca può usare quel risultato per restringere la scelta, poi mettere alla prova l'assistente con domande le cui risposte dipendono dai materiali dell'azienda. Chi dirige l'assistenza dovrebbe concentrarsi di più sull'uso degli strumenti nel rispetto delle procedure e sul passaggio dei casi a un operatore.

Per Humanity's Last Exam, separa l'ambizione del nome da ciò che viene misurato. Gli autori distinguono esplicitamente le prestazioni su quesiti accademici a risposta determinata dalla ricerca autonoma. Rispondere a una domanda difficile con soluzione nota non dimostra che un sistema sappia scegliere un problema che vale la pena affrontare, raccogliere prove affidabili e riconoscere i propri errori.

Contesto lungo e voce richiedono verifiche specifiche

La finestra di contesto è una capacità: indica quanto input un sistema può accettare. La valutazione sui contesti lunghi verifica cosa sa farne. I test di recupero individuano informazioni; quelli di ragionamento richiedono di collegarle. Gli autori di RULER mostrano perché trovare un dato nascosto non dovrebbe essere considerato una misura generale delle prestazioni sui contesti lunghi.

Per chi esamina contratti, il test utile verifica se l'assistente collega un'eccezione in appendice a una clausola dell'accordo principale e le cita entrambe correttamente. Includi documenti in cui la risposta manca, è stata superata o viene contraddetta. Un sistema che combina con sicurezza versioni incompatibili ha fallito, anche se ha recuperato ogni passaggio.

Per la voce, separa ascolto, ragionamento, produzione del parlato e gestione della conversazione. FLEURS può contribuire alla valutazione della trascrizione; Big Bench Audio riguarda il ragionamento su domande pronunciate a voce; VoiceBench comprende compiti basati su istruzioni vocali. Anche l'attuale famiglia tau valuta le interazioni vocali. Sono misurazioni distinte.

Un progetto pilota per l'assistenza telefonica dovrebbe includere rumore di fondo, nomi, interruzioni, correzioni e passaggi a un operatore. Ascolta l'interazione e verifica l'azione finale. La trascrizione può sembrare corretta mentre lo scambio vocale è frustrante o viene aggiornato l'account sbagliato.

Benchmark delle prestazioni degli LLM

Per decidere se adottare un sistema, considera le prestazioni come lavoro che soddisfa i criteri di accettazione entro i limiti del tuo flusso operativo. Qualità della risposta, affidabilità nel completamento e tempi di risposta sono requisiti separati. Un benchmark eseguito con un ampio budget di ragionamento può essere pertinente per un'indagine notturna e poco adatto a un'interazione di assistenza in tempo reale.

Chi acquista dovrebbe chiedere risultati sulle categorie di compiti necessarie e sulla configurazione effettiva del prodotto. Chi lo gestisce dovrebbe esaminare gli errori e i tentativi di recupero. Chi lo sviluppa dovrebbe poter riprodurre le impostazioni. Se il fornitore non sa identificare la configurazione valutata, il punteggio non basta a giustificare una scelta per la produzione.

Come leggere una tabella di lancio in cinque minuti

Usa questa lettura in cinque minuti per decidere se un lancio merita una valutazione più approfondita. È un metodo per leggere i risultati: non basta a stabilire se un modello sia sicuro o utile nella tua applicazione.

1. 1

   Minuto 1: definisci il tuo compito

   Scrivi il risultato che ti serve: risolvere problemi nel repository, gestire richieste di assistenza, rispondere usando documenti o gestire chiamate vocali. Segna le righe che gli assomigliano. Escludi dalla decisione di adozione i successi che non sono pertinenti.

2. 2

   Minuto 2: identifica il test esatto

   Annota edizione del benchmark, sottoinsieme, lingua e periodo dei compiti. Cerca qualifiche come Diamond, Verified, offline, solo testo o con strumenti. Quando l'etichetta è incompleta, consulta la pagina del benchmark.

3. 3

   Minuto 3: esamina la configurazione

   Individua harness, strumenti, impostazione del ragionamento, tempo concesso e regole sui tentativi. Verifica se il tuo prodotto userà quelle condizioni. Accesso alla ricerca, esecuzione del codice o più tentativi disponibili possono cambiare il significato di un punteggio.

4. 4

   Minuto 4: interpreta la metrica

   L'accuratezza è la quota di risposte giudicate corrette. F1 bilancia quanti degli elementi restituiti sono corretti e quanti degli elementi richiesti sono stati trovati. Un punteggio parziale può premiare i progressi anche senza il completamento. Per un tasso di errore, un valore più basso è migliore. Leggi la definizione prima di interpretare una percentuale come quota di lavori completati.

5. 5

   Minuto 5: risali a chi ha eseguito il test

   Identifica chi ha condotto il test: il produttore, l'organizzatore del benchmark o un altro valutatore. Leggi la nota della singola riga, senza presumere che l'intera tabella segua un'unica procedura. Salva fonte e impostazioni, poi scegli un candidato per i tuoi test.

Il risultato dovrebbe essere una breve nota decisionale: «Famiglia di compiti pertinente, versione attuale, configurazione compresa, vale la pena provarlo sui nostri casi». Se non riesci a completarla, annota l'informazione mancante prima di modificare un sistema che funziona.

Un esempio concreto: la tabella di Gemini 4 Argon di Google

Gemini 4 Argon, il modello AI generalista di Google, è un esempio utile perché la sua tabella combina famiglie di compiti e criteri di valutazione diversi. Le righe seguenti riproducono i risultati della scheda del modello di ottobre pubblicata da Google, verificati il 15 ottobre 2026. Sono risultati attribuiti alla fonte, non misurazioni effettuate per questo articolo.

Leggi l'etichetta della riga e le note accanto a ogni valore. Queste percentuali non condividono né il denominatore né il significato.

BFS significa breadth-first search, ricerca in ampiezza: si seguono i collegamenti del grafo per livelli di profondità. I token sono le unità usate per misurare il contesto del modello; non coincidono con le parole.

Prima delle conclusioni, leggi le note

La metodologia di valutazione di Google indica che Argon usa in genere l'impostazione di ragionamento più alta e pass@1, con alcune eccezioni. Il risultato DeepSWE usa un harness mini-swe. Quello di Terminal-Bench è calcolato da Google, mentre i risultati di confronto provengono dalla classifica ufficiale. Anche i risultati di GraphWalks sono calcolati da Google per tutti i modelli. OSWorld usa il massimo di tre esecuzioni e riporta un punteggio parziale offline.

Si tratta di una combinazione di modalità di valutazione, non della prova che ogni cella provenga da un unico esperimento controllato. Chi sviluppa deve chiedersi se l'harness di programmazione assomigli all'agente previsto. Chi acquista, se la configurazione proposta per l'applicazione corrisponda a quella documentata. Chi gestisce il sistema, se la metrica premi il completamento del risultato.

Il nostro calcolo: 99.7 meno 84.2 dà una differenza di 15.5 punti percentuali tra i risultati F1 pubblicati per GraphWalks. Le righe usano sottoinsiemi di lunghezza diversa, quindi la sottrazione non isola l'effetto causale della lunghezza su domande identiche. Mostra però perché citare solo la riga con il contesto più breve ometterebbe informazioni rilevanti per un flusso di lavoro su documenti lunghi.

Per l'uso del computer, l'interpretazione è altrettanto concreta: non trasformare il punteggio parziale in «l'agente completa questa quota dei nostri lavori al desktop». I progressi parziali possono essere utili per un assistente che restituisce il lavoro a una persona. Un processo senza supervisione richiede prove di risultati completi e corretti.

Per approfondire l'adozione di questo modello, leggi la guida a Gemini 4 Argon e il confronto dedicato tra Gemini 4 Argon e Opus 5.5.

Perché un punteggio alto può ingannare

Un punteggio elevato può essere valido e rispondere comunque alla domanda aziendale sbagliata. La reazione utile è identificare il limite, poi stabilire quali prove servano per superarlo.

Contaminazione e ottimizzazione mirata al test

La contaminazione si verifica quando domande o risposte della valutazione finiscono nei dati di addestramento. Il modello può così beneficiare dell'esposizione precedente, invece di risolvere un problema mai visto. Anche i test pubblici possono diventare obiettivi di ottimizzazione: adattare ripetutamente prompt o scaffold agli stessi compiti ne riduce il valore come verifica su casi nuovi.

LiveCodeBench usa problemi con data di pubblicazione nota, così chi valuta può scegliere compiti usciti dopo la data limite dell'addestramento. È una caratteristica progettuale utile, non un motivo per presumere che qualsiasi risultato con «Live» nel nome sia privo di contaminazione. Controlla il periodo effettivo dei problemi. Un salto insolitamente ampio è un motivo per esaminare il protocollo, non una prova di scorrettezza.

Per le tue valutazioni, conserva un insieme di test separato, che non usi per mettere a punto i prompt. Quando un errore diventa un esempio di sviluppo, aggiungi nuovi casi a questo insieme riservato. Altrimenti il sistema può diventare eccellente sugli esempi familiari e restare fragile negli altri casi.

Lo scaffold può cambiare il sistema che stai confrontando

L'ambiente di esecuzione conta. Un modello con ricerca, strumenti per i file, tentativi ripetuti e istruzioni curate è un sistema diverso dallo stesso modello che risponde a un singolo prompt. Migliorare lo scaffold può essere un progresso ingegneristico prezioso; l'errore è attribuire tutto il risultato al modello sottostante.

Usa un harness comune quando vuoi isolare l'effetto del cambio di modello. Valuta il prodotto completo quando devi scegliere tra prodotti completi. Sono domande diverse e possono legittimamente portare a conclusioni diverse.

Un test del produttore è utile, ma non equivale a una replica indipendente

Un risultato del produttore è utile quando il metodo è chiaro; quello dell'organizzatore di un benchmark è utile quando la configurazione è adatta al confronto. Nessuna delle due etichette sostituisce la lettura del protocollo. Distingui un risultato inviato a una classifica da uno rieseguito in modo indipendente in condizioni comuni.

Cerca prompt, identificativo del modello, harness, metodo di valutazione, esclusioni e incertezza. Una piccola differenza, senza informazioni sufficienti sulla variabilità, non dovrebbe determinare una migrazione. Un risultato omesso è un dato mancante: non equivale automaticamente a zero.

Esamina anche l'aggregazione. Una media complessiva incorpora le scelte di chi valuta su compiti e pesi. La tua coda di assistenza può contenere molti casi eccezionali che incidono appena su quella media. Non fare la media di percentuali di benchmark non correlati per costruirti un punteggio di intelligenza.

Anche un buon valutatore può misurare il risultato sbagliato

Test unitari, risposte di riferimento, modelli usati come giudici e preferenze umane premiano aspetti diversi. La copertura dei test può non rilevare un difetto; una risposta di riferimento può contenere un errore; un modello giudice può preferire una spiegazione ben formulata a un'azione corretta. Una vittoria nelle preferenze misura ciò che i partecipanti hanno preferito secondo quella procedura.

L'attuale repository di tau documenta correzioni ai compiti e ai criteri di valutazione. Questi interventi migliorano la valutazione e rendono essenziale tenere traccia delle versioni. Un test è un sistema di misurazione che richiede manutenzione, non una fonte di verità indiscutibile.

Quando servono valutazioni proprie?

Esegui valutazioni interne quando la decisione dipende da dati, regole, strumenti, utenti o tolleranza agli errori specifici della tua organizzazione. I punteggi pubblici bastano a identificare candidati plausibili. Non bastano ad approvare un agente che modifica i dati dei clienti o risponde usando documenti privati.

Agisci subito se un miglioramento in un benchmark pertinente affronta un errore noto del sistema attuale: esegui un confronto controllato su quella categoria di errori. Rimanda la migrazione se il miglioramento riguarda compiti estranei al tuo lavoro o se la configurazione pubblicata non è disponibile nel tuo prodotto. Mantieni il sistema attuale se soddisfa già i criteri di accettazione e il nuovo candidato non ha dimostrato miglioramenti pertinenti.

Per il team di assistenza di un'azienda di medie dimensioni, un progetto pilota iniziale potrebbe comprendere 50 casi: 20 richieste ordinarie, 10 eccezioni alle regole, 10 input mancanti o contraddittori e 10 casi relativi a permessi o passaggi a un operatore. Sono quantità suggerite per progettare il test, non una dichiarazione che questo campione sia statisticamente sufficiente per la messa in produzione. Scegli la dimensione finale in base ai tassi di errore e alle differenze che devi rilevare.

Definisci il risultato prima di eseguire i candidati. Un caso di rimborso potrebbe richiedere una corretta verifica dell'idoneità, account e importo giusti, nessuna azione non autorizzata e una spiegazione chiara. Un caso di escalation dovrebbe superare il test quando l'agente lo passa correttamente a un operatore, anche se non risolve direttamente la richiesta.

Esegui ogni candidato con i prompt, il recupero delle informazioni, gli strumenti e i permessi previsti. Esamina il record finale e la traccia delle azioni, oltre al messaggio conclusivo. Ripeti i casi instabili, misura la latenza separatamente ed esamina i giudizi discordanti prima di dichiarare un miglioramento. Conserva un insieme di test riservato per la decisione finale.

Promptfoo è uno strumento di valutazione per confrontare prompt, modelli e applicazioni con casi di test e asserzioni. La sua documentazione descrive il modello di esecuzione; la nostra recensione di Promptfoo spiega dove si inserisce e quali responsabilità restano a tuo carico.

Usa controlli deterministici per i fatti verificabili direttamente, come l'account selezionato o un'azione vietata. Per gli aspetti che richiedono un giudizio, come la completezza e il fondamento di una spiegazione, usa una griglia di valutazione e calibrala sui giudizi umani. La guida a LLM-as-a-judge tratta questo livello di valutazione e i modi in cui può fallire.

Da fare lunedì: scegli un flusso di lavoro, scrivi i criteri di accettazione, raccogli casi recenti e confronta il sistema attuale con un candidato nelle stesse condizioni. Decidi la messa in produzione in base ai risultati e agli errori che contano per i tuoi utenti.

Domande frequenti sulle tabelle dei benchmark

Quali sono i benchmark LLM più comuni?

Impara prima a riconoscere le famiglie: SWE-bench e Terminal-Bench per gli agenti di programmazione, GPQA e Humanity's Last Exam per i quesiti accademici, la famiglia tau per l'uso degli strumenti durante le conversazioni e test separati per contesti lunghi e voce. Associa sempre edizione e impostazioni a ogni punteggio.

Qual è il miglior benchmark LLM per la programmazione?

Usa il benchmark più vicino al compito. SWE-bench riguarda la risoluzione di problemi nei repository; Terminal-Bench il lavoro da terminale; HumanEval la generazione di funzioni; LiveCodeBench include problemi di competizione con data nota. Sono le modifiche al tuo repository a stabilire se quei risultati si applicano al tuo caso.

Che cos'è il dataset di un benchmark LLM?

Un dataset fornisce le domande o i compiti. Per confrontare i risultati di un benchmark serve anche il protocollo: prompt, strumenti, limiti, tentativi e criteri di valutazione. Il solo nome del dataset non dimostra che due risultati siano confrontabili.

Per indicazioni pratiche su come valutare e adottare l'AI, iscriviti alla newsletter.