Esce un modello nuovo, guida la tabella, e in poche ore qualcuno nella tua impresa inoltra il grafico con un «dovremmo passare a questo». La tabella è bella, le barre sono più lunghe del mese scorso, e la conclusione pare ovvia: chi punteggia più alto è il migliore, quindi è quello da usare. Un ragionamento pulito, rapido, e quasi sempre sbagliato.
La tesi in una frase: i benchmark degli LLM per l'impresa non predicono il tuo risultato. Il numero uno della classifica vince un esame standardizzato —domande da quiz, problemi di codice giocattolo, indovinelli di logica— che non somiglia per niente al tuo lavoro vero. Chi rende nel TUO caso lo decidono i tuoi dati, il tuo compito concreto e il tuo contesto, e questi tre fattori non appaiono in nessuna tabella pubblica. Scegliere un modello dalla classifica è partire dal posto sbagliato, come scegliere uno strumento prima di sapere cosa automatizzerai.
Perché i benchmark degli LLM per l'impresa non predicono il tuo risultato
Un benchmark è un esame: un insieme fisso di domande con risposte note, uguale per tutti i modelli, che produce un numero comparabile. Va benissimo per ciò che è —confrontare i modelli tra loro su una prova comune— ed è inutile per ciò che la gente crede: dire quale funzionerà nella tua impresa. Perché la tua impresa non chiede al modello di risolvere indovinelli di matematica da olimpiade; gli chiede di leggere le tue mail, capire il tuo gergo, classificare i tuoi documenti e non inventarsi dati del tuo catalogo. Niente di tutto ciò è nell'esame.
C'è un problema ancora più scomodo: l'esame trapela. Quando un benchmark è famoso, le sue domande finiscono, in un modo o nell'altro, nei dati con cui si addestrano i modelli successivi. Risultato: punteggiare alto in una prova nota misura, in parte, quanto il modello ha visto di quella prova —non quanto ragiona su qualcosa che non ha mai visto, che è esattamente ciò che gli chiederai tu—. La tabella premia chi ha studiato l'esame a memoria. Il tuo lavoro è l'esame che nessun modello ha visto.
Il benchmark misura un esame; la tua impresa è un'altra cosa
Pensa alla differenza tra un candidato con il massimo dei voti a un test standardizzato e quello che fa davvero bene il tuo lavoro. Non sono sempre la stessa persona, per la stessa ragione: il test misura una capacità generale e senza contesto, il lavoro vero misura l'incastro con un problema concreto. Un modello può essere brillante a ragionare in astratto e mediocre a riassumere i verbali delle tue riunioni perché non conosce le tue sigle, il tuo tono né cosa conta per te. Un altro, più modesto in tabella, può inchiodare il tuo compito perché combacia meglio con la forma dei tuoi dati.
Questo si collega a un errore d'ordine che affonda progetti interi, raccontato bene nella guida su perché falliscono i progetti di automazione con l'IA: si sceglie la tecnologia prima di capire il problema. Partire da «qual è il modello migliore?» è la versione raffinata dello stesso errore. La domanda utile non è quale vince la tabella, è quale risolve il tuo compito con i tuoi dati —e quella risposta non è pubblicata da nessuna parte, va tirata fuori.
Cosa predice il tuo risultato: i tuoi dati, il tuo compito, il tuo contesto
Se la classifica non comanda, chi comanda? Tre cose, e nessuna sta in una barra colorata:
- I tuoi dati. Il modello lavorerà sulla TUA informazione —il tuo catalogo, le tue mail, i tuoi documenti, il tuo gergo interno—, non sul corpus pulito dell'esame. Un modello che brilla su testo da manuale può inciampare sui tuoi PDF mal scansionati e sulle tue tabelle strane. La qualità e la forma dei tuoi dati predicono il risultato più di qualsiasi classifica. Per questo il primo lavoro non è scegliere un modello, è guardare i dati.
- Il tuo compito concreto. «Scrivere bene» non è un compito; classificare ticket, estrarre campi da una fattura o redigere col tuo tono, sì. I modelli non rendono uguale su tutti: uno vince a classificare, un altro a riassumere, un altro a ragionare per passi. Quello che vince il tuo compito non è quello che vince la media dell'esame; è quello che vince QUELLA colonna, che la tabella aggregata nasconde.
- Il tuo contesto. Costo per uso, latenza accettabile, se il dato può uscire dal tuo perimetro o no, se devi autoospitarlo, quali integrazioni hai. Un modello un filo peggiore ma che gira dentro il tuo cloud e rispetta il tuo GDPR può essere la scelta giusta rispetto al numero uno che non puoi usare. Il contesto non è un dettaglio: spesso è ciò che decide.
L'unico benchmark che conta è quello che lanci tu
La conclusione pratica non è «ignora i modelli», è «monta il tuo esame». Prendi il tuo compito reale, prepari un insieme di casi tuoi —con le risposte che consideri corrette— e ci fai passare i due o tre modelli candidati. In un pomeriggio hai ciò che nessuna classifica ti dà: quale rende sul TUO lavoro, coi TUOI dati, a un costo che puoi pagare. Questo è un eval, ed è la differenza tra scegliere con criterio e scegliere per la barra più lunga del grafico di questa settimana.
E quell'eval non è un lusso da laboratorio: è la stessa disciplina di decidere bene quali processi automatizzare con l'IA —prima il compito, poi il «con cosa»—. Ha inoltre un vantaggio che la classifica non avrà mai: è stabile. La tabella cambia ogni mese e ti spinge a rincorrere il modello di moda; il tuo eval sul tuo compito resta valido quando esce il prossimo numero uno, perché misura l'unica cosa che non cambia: il tuo problema.
Allora, a cosa servono i benchmark?
Non a niente. Servono per ciò che sono: un filtro grezzo e una mappa del terreno. Ti dicono quali modelli sono nella conversazione, scartano quelli chiaramente indietro e ti danno un'intuizione di dove sia la frontiera. Come primo vaglio —«questi cinque valgono un'occhiata»— sono utili. L'errore non è leggere la tabella; è trattarla come la risposta finale invece del punto di partenza. La classifica ti dice chi invitare alla prova; il tuo eval decide chi assumi.
C'è una ragione di fondo per cui ce lo dimentichiamo: scegliere il modello top sembra progresso, è gratis e non richiede lavoro; montare il tuo eval è noioso e ti obbliga a guardare i tuoi stessi dati. Ma è lo stesso autoinganno che racconta il post su perché l'adozione, non il modello, decide il ROI dell'IA: la parte che decide il risultato è sempre quella che non sta nel keynote. Il modello è l'ultima decisione, non la prima, e di certo non quella che si prende fissando una tabella.