Perché i benchmark AI ignorano il 90% del lavoro reale

Un mio amico gestisce le operazioni in un'azienda di logistica di medie dimensioni, e la scorsa primavera il suo team ha passato tre settimane a valutare se un LLM potesse prendere in carico il loro flusso di gestione delle eccezioni, cioè il lavoro poco appariscente di riconciliare fatture che non corrispondono agli ordini d'acquisto tra tre sistemi che si detestano a vicenda. La presentazione del fornitore era piena di numeri impressionanti: MMLU, GSM8K, HumanEval e una manciata di benchmark agentici. Il modello ha superato ogni test preconfezionato che gli hanno sottoposto. Poi l'hanno messo di fronte a una settimana reale di eccezioni e lui ha abbinato con sicurezza una fattura da 14.000 dollari all'ordine d'acquisto sbagliato, perché un fornitore aveva abbreviato il proprio nome in modo diverso. Nessuna classifica misura una cosa del genere.

Quel divario ora è misurabile. Una recente mappatura dei benchmark pubblici di AI rispetto alla tassonomia O*NET del Dipartimento del Lavoro statunitense, cioè tutte le 923 professioni e le 18.797 attività che compongono il lavoro americano, ha rilevato che il 90% delle ore lavorative negli Stati Uniti è dedicato ad attività con poca o nessuna copertura da parte dei benchmark. Solo 208 delle 923 professioni hanno almeno un'attività supportata da cinque o più prompt di benchmark. Sei delle 22 famiglie professionali non ne hanno affatto. La conclusione scomoda non è che l'AI sia debole. È che i nostri strumenti per misurare le capacità dell'AI sono puntati quasi interamente sulla parte sbagliata dell'economia.

Cosa Coprono Davvero i Benchmark dell'AI

La metodologia dietro questa mappatura merita attenzione, perché è più rigorosa di quanto lasci intendere il titolo. I ricercatori hanno preso 29 benchmark agentici di alta qualità e non saturi, cioè test in cui i modelli devono svolgere un lavoro vero e non limitarsi a rispondere a domande, e hanno usato un giudice LLM (validato rispetto a esperti umani) per etichettare ogni prompt con le attività O*NET che esercita. Un'attività conta come "coperta" se almeno cinque prompt vi corrispondono. Combinando questo dato con le stime del tempo di lavoro assorbito da ciascuna attività, si ottiene un quadro a livello di economia intera di ciò che la nostra suite di valutazione riesce a vedere.

Ciò che riesce a vedere è stretto e alto, non ampio. Ingegneria del software e analisi finanziaria sono saturate di benchmark. La guida di camion, la gestione di impianti a gas, la ristorazione e gran parte del lavoro quotidiano in sanità sono praticamente invisibili. E lo squilibrio non riguarda solo quali attività siano tecnicamente automatizzabili. Le attività etichettate come "esposte all'AI" hanno circa sei volte più probabilità di essere sottoposte a benchmark rispetto a quelle non esposte, il che ha senso, ma anche controllando per questo, le attività delle professioni con grandi masse salariali complessive sono significativamente sovrarappresentate. Le attività degli avvocati sono coperte in modo fitto. Segretari legali e cancellieri di tribunale, che affrontano un'esposizione all'AI simile, quasi non compaiono.

Rileggi questo passaggio: stiamo testando l'AI sulla versione prestigiosa di un mestiere, ignorando la versione che la maggior parte delle persone effettivamente svolge. La lunga coda del lavoro intellettuale a reddito medio, cioè i coordinatori, gli impiegati, gli specialisti e i pianificatori le cui ore sommate costituiscono una quota enorme dell'economia, ha quasi nessuna infrastruttura di misurazione. Quando qualcuno afferma che l'AI può svolgere una certa percentuale del "lavoro intellettuale", chiedi quale lavoro intellettuale, misurato come e rispetto a quale elenco di attività. La risposta onesta è di solito: una fetta sottile e non rappresentativa, misurata con test pensati per gli articoli di ricerca.

La Saturazione dei Benchmark È un Errore di Progettazione della Valutazione

Ho passato anni a costruire pipeline di valutazione, e la lezione più dura è questa: un benchmark è un modello del mondo, e la maggior parte dei benchmark è un pessimo modello. Comprimono un compito umano confuso, contestuale e multi-step in un prompt pulito con una risposta verificabile, perché è ciò che costa poco correggere. Poi la legge di Goodhart fa il resto. Nel momento in cui un benchmark diventa il bersaglio dello sviluppo dei modelli, smette di misurare la capacità che doveva rappresentare. I dati di addestramento assorbono la distribuzione del test, i team ottimizzano sulla classifica e i punteggi salgono mentre le prestazioni nel mondo reale restano ferme o peggiorano.

La saturazione è il sintomo visibile. Quando ogni modello di frontiera ottiene più del 90% in un test, il test ha smesso di discriminare, ma il problema più profondo è che reagiamo costruendo un altro benchmark dello stesso stile, che copre gli stessi tipi di attività, perché sono quelle che sappiamo valutare automaticamente. Le domande a risposta multipla generano domande a risposta multipla più difficili. Le sfide di programmazione generano sfide di programmazione più difficili. Nel frattempo nessuno costruisce il benchmark per "notare che la clausola di indennizzo di questo contratto contraddice in silenzio il term sheet di marzo", perché valutarlo richiede un avvocato, tempo e giudizi che resistono all'automazione.

Per questo non condivido l'idea che la saturazione dei benchmark significhi che l'AI ha "risolto" un dominio. La saturazione significa che lo strumento è al massimo, punto. Un termometro che si blocca a 40°C non dimostra che la stanza sia a 40 gradi; dimostra che serve un termometro diverso. Se stai valutando modelli per la produzione, e soprattutto se stai costruendo sistemi decisionali basati su LLM dove gli errori hanno costi reali, i distacchi in classifica sui benchmark saturi dovrebbero pesare quasi zero nella tua decisione.

Sappiamo con precisione quanto siano bravi i modelli nel lavoro che abbiamo deciso di misurare. Non sappiamo quasi nulla dell'altro novanta per cento.

L'Effetto Lampione nella Valutazione dell'AI

C'è una vecchia barzelletta su un ubriaco che cerca le chiavi sotto un lampione, non perché le abbia perse lì, ma perché lì c'è luce. La costruzione dei benchmark segue la stessa logica, e i dati confermano che non è casuale. Lo studio di mappatura ha rilevato che l'importanza di un'attività all'interno di una professione predice la copertura: le attività O*NET ritenute più importanti per la propria professione hanno da sei a dieci volte più probabilità di essere sottoposte a benchmark rispetto alle meno importanti. A prima vista sembra una priorità sensata. In pratica significa che misuriamo le attività vetrina e saltiamo il tessuto connettivo.

Ogni lavoro è per lo più tessuto connettivo. L'attività di un ingegnere del software coperta da benchmark è "implementa una funzione che superi questi test". La sua giornata reale comprende leggere la migrazione a metà di un collega, capire quale stakeholder possiede davvero una decisione e accorgersi che il ticket descrive il problema sbagliato. Ho già scritto di come gli strumenti di coding agentici riescano o falliscano proprio su questo: il ciclo, il contesto e i confini dei permessi contano più della qualità grezza della generazione. Niente di tutto questo compare in un punteggio in stile HumanEval.

C'è anche un problema di definizione sottile nei numeri di copertura. "Coperto" significa che cinque o più prompt corrispondono a un'attività, non che cinque prompt catturino l'attività. Tredici prompt sul consigliare i genitori riguardo ai problemi educativi dei figli non rappresentano ciò che un assistente sociale fa davvero tra un caseload, un'aula di tribunale e una visita a casa di una famiglia. Se applicassimo la definizione di "coperto bene" di un profano, la quota misurata dell'economia non sarebbe il 10%. Sarebbe zero. Il lampione non è solo stretto; la luce che proietta è debole.

I Modelli Generano, ma Nessuno Testa il Giudizio

Ecco l'asimmetria che trovo più impietosa. Quasi ogni benchmark esistente testa la produzione: scrivi il codice, redigi il memo, risolvi il problema. Ma la metà economicamente critica della maggior parte dei compiti reali è il rilevamento: individuare l'errore, segnalare l'incoerenza, capire quando la risposta sicura è sbagliata. Il valore di un contabile junior non sta nel produrre una riconciliazione; sta nel notare che un numero puzza. I benchmark quasi mai lo testano, perché costruire un compito valutabile di rilevamento degli errori è molto più difficile che costruire un compito di generazione. Servono artefatti difettosi realistici, errori plausibili ma sottili e un accordo tra esseri umani su cosa conti come individuato.

Questa è la fallacia del portiere applicata al design della valutazione. Sostituisci un portiere con una porta automatica e scopri, troppo tardi, che il portiere salutava anche gli inquilini, accettava i pacchi e controllava la strada. Automatizza la parte testata di un lavoro e scopri che le parti non testate reggevano il peso. Il modello del mio amico della logistica poteva redigere ottime note di riconciliazione, cioè il compito visibile, mentre rovinava in silenzio l'abbinamento, cioè il giudizio che rendeva le note degne di essere scritte. La suite di valutazione ha valutato la guarnizione e ignorato la portata principale.

Finché il rilevamento degli errori non riceverà un trattamento di prima classe nei benchmark, aspettati un divario persistente tra prestazioni in demo e prestazioni in produzione. È lo stesso divario che esiste tra ciò che dice una specifica e ciò che fa l'implementazione, e proprio come nel software, è lì che nascono i fallimenti. Un modello che genera al 90° percentile e verifica al 30° è, in produzione, un dipendente al 30° percentile con una velocità di battitura superiore.

Ponderare le Valutazioni in Base alla Distribuzione Reale dei Compiti

L'idea più pratica emersa dal lavoro di mappatura dei benchmark è anche la più semplice: se i benchmark sovrarappresentano alcuni compiti, smetti di fare la media sui prompt e inizia a farla sui compiti, pesati in base al tempo di lavoro effettivamente assorbito da ciascuno. Una media semplice di tutti i prompt etichettati "analista finanziario" è dominata dal compito che ha più prompt di benchmark, di solito quello più facile da trasformare in dataset. Una media ponderata con O*NET dà a ogni compito reale lo stesso peso. La differenza può essere drastica.

import pandas as pd
# The tasks an occupation actually performs, with time shares
# (from O*NET, your own ticket logs, or time-tracking data)
tasks = pd.DataFrame({
"task": ["draft contract", "advise client", "review filing", "coordinate closing"],
"time_share": [0.30, 0.25, 0.35, 0.10],
})
# Model results: one row per eval prompt, mapped to the task it exercises
results = pd.DataFrame({
"prompt_id": ["p1", "p2", "p3", "p4", "p5"],
"task": ["draft contract", "draft contract", "draft contract",
"review filing", "coordinate closing"],
"score": [0.92, 0.88, 0.95, 0.61, 0.40],
})
# Naive: flat average over prompts. Drafting has 3 of 5 prompts,
# so the score is dominated by the model's best task.
naive = results["score"].mean()  # 0.752
# Task-weighted: average within each task first, then weight by
# the share of working hours that task consumes.
per_task = results.groupby("task")["score"].mean()
weights = tasks.set_index("task")["time_share"]
weighted = (per_task * weights).sum() / weights[per_task.index].sum()
# 0.30*0.917 + 0.35*0.61 + 0.10*0.40, over covered time (0.75) = 0.705
# vs naive 0.752 — and 'advise client' (25% of the job) has no data at all

Due cose da notare in quello snippet. Primo, il punteggio ponderato scende perché i compiti più deboli del modello erano sottorappresentati nel pool di prompt, esattamente la distorsione che una media piatta nasconde. Secondo, e più importante: "consigliare il cliente" scompare del tutto dal calcolo perché nessun prompt vi corrisponde. Qualsiasi schema di ponderazione elimina in silenzio i compiti senza copertura, e l'assenza di copertura è la norma per gran parte dell'economia. La ponderazione risolve il problema della ponderazione. Non può risolvere il problema dei dati mancanti. Quello richiede di costruire nuove valutazioni, non di rifare la media di quelle vecchie.

Come Valutare l'AI sul Lavoro che Fai Davvero

Se stai scegliendo o mettendo in produzione dei modelli, il divario di copertura a livello di economia ha una conseguenza concreta: i benchmark pubblici sono un prior debole per il tuo caso d'uso, a meno che tu non ti trovi nell'angolo piccolo e luminoso che misurano. Quindi costruisci il tuo angolo. È meno eroico di quanto sembri, e batte di gran lunga la fiducia nella presentazione di un fornitore.

• Campiona i compiti dai log, non dall'immaginazione. Estrai una settimana di ticket, email o eccezioni reali e campiona in base alla frequenza. Il tuo set di valutazione dovrebbe rispecchiare l'istogramma del tuo carico di lavoro, coda noiosa compresa: la coda noiosa è la maggior parte del lavoro.
• Pondera per tempo o costo, poi riporta entrambi i numeri. Una media piatta e una media ponderata delimitano la verità. Se un modello vince sulla media piatta ma perde su quella ponderata, è bravo nei compiti facili da testare, che è esattamente la modalità di fallimento che stai cercando di intercettare.
• Includi compiti di verifica. Prendi output reali, compresi quelli noti come errati, e valuta il modello in base alla capacità di individuare errori inseriti e naturali. Nella mia esperienza, la capacità di rilevamento e quella di generazione sono quasi non correlate, e il rilevamento è ciò che stai effettivamente acquistando.
• Tieni un set privato e rinnovalo. Qualsiasi valutazione riutilizzata per mesi diventa un obiettivo di addestramento, anche senza volerlo, nel momento in cui qualcuno inizia a ottimizzare i prompt su di essa. Ruota i casi ogni trimestre.
• Valuta gli esiti end-to-end quando possibile. Se il compito è "riconcilia questa fattura", valuta la riconciliazione, non la prosa intermedia. Le metriche intermedie lusingano i modelli come gli unit test lusingano il codice privo di copertura di integrazione.

C'è un effetto finale più silenzioso che vale la pena nominare, quello che chiunque usi quotidianamente strumenti di coding con l'AI riconoscerà: la malattia dei costi di Baumol su micro-scala. Quando la generazione diventa venti volte più veloce, non passi la giornata a generare. La passi sulle parti che non si sono accelerate: revisione, coordinamento, verifica, decisioni. Il residuo non testato non si riduce man mano che l'AI migliora; cresce per riempire il tempo liberato, e diventa una quota sempre maggiore di ciò che determina se valesse la pena dispiegare l'AI. Misurare la fetta automatizzabile con precisione sempre maggiore ignorando il residuo non è solo incompleto. Capovolge ciò che conta.

Nulla di tutto questo è un argomento contro il progresso dell'AI: i guadagni di capacità sono reali, e ci ho puntato dei progetti. È un argomento sul fatto che la nostra cultura della misurazione è puntata sulla distribuzione sbagliata. I benchmark sono nati dove i prompt erano economici da scrivere e valutare: codice, matematica, conoscenze in stile esame. L'economia non è in gran parte così. Finché la valutazione non si metterà al passo, tratta ogni affermazione clamorosa sulle capacità come una dichiarazione sul decimo luminoso della mappa, e costruisci le valutazioni che coprono i tuoi novanta per cento oscuri. Le organizzazioni che faranno questo lavoro di misurazione noioso e poco appariscente prenderanno decisioni di deployment migliori di tutti quelli che ricaricano le classifiche, e non sarà nemmeno in discussione.