METR Time Horizon e benchmark maxing: come leggere i grafici di progresso degli LLM senza farsi ingannare

Il 28 febbraio 2026, una settimana dopo che METR aveva aggiunto Claude Opus 4.6 alla pagina Task-Completion Time Horizons, il grafico è circolato su LinkedIn italiano con caption "AGI in 18 mesi". Sul mio Hetzner CCX33 (8 vCPU AMD EPYC 9454P, 32 GB RAM DDR5) sono andato a leggere la pagina sorgente sul sito METR, e quello che il grafico mostrava era effettivamente notevole: il 50%-time horizon di Opus 4.6 era stimato a 718 minuti, circa 12 ore di lavoro umano esperto, partendo da Claude 3.7 Sonnet che a febbraio 2025 stava intorno ai 60 minuti. Una crescita di 12x in dodici mesi. Quello che il grafico non mostrava, e che il caption LinkedIn ometteva accuratamente, era il confidence interval: 319-3949 minuti, ovvero da 5 ore a 65 ore. Un order of magnitude di incertezza su un singolo punto. METR stessa, nelle note metodologiche, scrive che il task suite non ha abbastanza task lunghi per stimare un upper bound credibile sopra le 8 ore di lavoro umano, e che si "sorprenderebbero" se Opus avesse davvero un 50%-horizon di 20+ ore.

C'è un nome tecnico per il pattern in cui un modello cresce esponenzialmente sui benchmark misurabili mentre l'utilità aziendale reale resta piatta: si chiama benchmark maxing. È il fenomeno strutturale che spiega perché ogni rilascio di un nuovo modello frontier porta nuovi record sui leaderboard pubblici e simultaneamente delude le aspettative dei progetti aziendali che ne vengono giustificati. METR, RLVR e l'imminente AA Omniscience sono tre lenti diverse sullo stesso elefante, e capirle è prerequisito per non costruire una pipeline AI sopra una curva esponenziale che misura una cosa diversa da quello che ti serve.

Cosa misura davvero METR Time Horizon?

METR (Model Evaluation & Threat Research, organizzazione no-profit di Berkeley/Stanford) costruisce dal 2024 una metrica chiamata Time Horizon che vuole rispondere a una domanda sintetica: "Quanto è lungo il task umano che un AI agent può completare con riliability X%?". La logica è elegante: prendi un set di task, ognuno con tempo medio richiesto da un esperto umano per completarlo, fai eseguire il task all'AI agent, e calcoli a che durata di task umano corrisponde il punto in cui l'agent fallisce nel 50% dei casi (50%-horizon) o nell'80% (80%-horizon). Il numero che esce è interpretabile come "questo modello sostituisce un esperto umano per task lunghi fino a N minuti, oltre crolla".

Il dettaglio fondamentale è la composizione del task suite. METR pesca da tre fonti: RE-Bench (research engineering benchmark), HCAST (Human-Calibrated Autonomy Software Tasks) e un set di task software brevi novel. Su metr.org/time-horizons la pagina dichiara esplicitamente: "These primarily consist of software engineering, machine learning, and cybersecurity tasks. They are designed to be self-contained and well-specified, with clear success criteria that can be automatically evaluated". Tre vincoli espliciti: dominio software/ML/cybersec, task ben specificati, criterio di successo automaticamente valutabile. Ognuno di questi è una scelta metodologica che limita radicalmente cosa il numero che esce può davvero dirti.

Per essere concreti: una negoziazione commerciale di tre ore con un cliente difficile, una valutazione clinica complessa di un paziente con sintomi multipli, la stesura di una memoria difensiva per un contenzioso, l'analisi di un piano industriale di una PMI manifatturiera. Tutti task umani che durano da minuti a giorni, ma nessuno di questi è "self-contained con criterio di successo automaticamente valutabile". Tutti questi sono fuori dal dominio METR per costruzione. Il claim "Opus 4.6 fa 12 ore di lavoro umano" è vero solo se quel "lavoro umano" è codifica, debugging, ML pipeline, exploit di sicurezza valutati come pass/fail dalla logica.

Se progetti AI sapendo cosa stai misurando

Nel mio hub dedicato all'AI per aziende raccolgo articoli su come distinguo le metriche di benchmark dal valore reale in produzione. Se stai per firmare un contratto giustificato da una crescita di benchmark, leggi prima la nota su come leggere un paper AI con occhio critico, che è il prerequisito per non comprare hype.

Opus 4.6 risolve davvero task da 12 ore? Leggi il confidence interval

Il punto stimato 718 minuti di Opus 4.6 è uscito a febbraio 2026. Ma il confidence interval del 95% va da 319 a 3949 minuti. Il rapporto upper-bound/punto-stimato è 5,5x. È un'incertezza che, in qualsiasi altra disciplina scientifica, farebbe rifiutare il numero come non informativo. METR sa benissimo perché succede: il task suite ha solo 31 task con stima umana di 8+ ore (su 228 totali nella versione TH1.1 di gennaio 2026), e di questi 31 solo 5 hanno human baseline misurato direttamente, gli altri 26 sono stime. Il modello di regressione logistica con cui si stima il 50%-horizon viene forzato a estrapolare oltre i task realmente calibrati nel dataset. Quando un modello psicometrico estrapola fuori distribuzione, gli intervalli di confidenza esplodono.

C'è anche un effetto correlato di saturation: RE-Bench, una delle fonti del task suite, ha tasks che toppano intorno a 480 minuti (8 ore). Se il modello stima 718 minuti come 50%-horizon, la stima sta letteralmente predicendo capacità su task più difficili di qualunque task realmente presente nel dataset. È come se misurassi l'altezza media degli italiani avendo nel campione solo persone alte tra 1,50 e 1,80, e poi stimassi quanti uomini sono alti 2,10. Il numero è statisticamente computabile, ma non è una misura empirica.

A favore di METR va detto che il team è esplicitamente onesto su questo limite. La nota TH1.1 del 29 gennaio 2026 sulla pagina ufficiale METR dice: "These confidence intervals are still very wide, and METR is actively working on adding more long tasks to help get tighter estimates and avoid saturation as model capabilities continue to advance". Il problema non è METR, è chi cita METR senza riportare l'incertezza. Il post LinkedIn italiano "AGI in 18 mesi" prendeva il 718 minuti, lo etichettava "12 ore", e ometteva il fatto che il modello potrebbe stare a 5 ore o a 65 ore con la stessa probabilità statistica.

Il dato robusto, quello che METR riporta con confidence interval ragionevole, è il 80%-horizon. È rimasto sostanzialmente piatto a 27-32 minuti dal rilascio di GPT-5.1-Codex-Max in poi. Tradotto: dove l'agent deve avere alta affidabilità (cosa che vorresti in produzione), il limite resta sull'ordine della mezz'ora di lavoro umano esperto. Il salto dei 12x sui 50%-horizon è guidato in larga parte dalla capacità del modello di completare task molto lunghi con bassa affidabilità, non dalla capacità di produrre lavoro robusto sostenibile.

Time Horizon 1.1 e il soffitto della misurazione

Il 29 gennaio 2026 METR ha rilasciato la versione TH1.1 della metodologia con tre cambiamenti operativi. Primo, il task suite è cresciuto da 170 a 228 task, con i task lunghi (8+ ore) raddoppiati da 14 a 31. Secondo, l'infrastruttura di valutazione si è spostata da Vivaria (in-house METR del 2023) a Inspect, framework open-source ampiamente adottato e mantenuto da UK AI Security Institute. Terzo, i confidence interval sono effettivamente più stretti rispetto a TH1: l'upper bound su Opus 4.5 era 4,4x il punto stimato in TH1, è ora 2,3x in TH1.1.

Il dato qualitativo importante è la doubling time. Su tutto il periodo 2019-2025 il time horizon raddoppiava ogni 7 mesi circa. Limitando il fit ai dati post-2023, il doubling time scende a ~4 mesi (CI 105-157 giorni). È un'accelerazione apparente impressionante che alimenta narrazione AGI-imminente. Ma il dato fa parte dello stesso pattern di benchmark maxing: la curva di progressi è ripida specifically sulla metrica che stiamo misurando, mentre lo spazio di task non misurabili (gli 80%-horizon, i task non software, i task aziendali olistici) progredisce molto più lentamente o resta piatto.

Benchmark maxing: il pattern strutturale

Il termine benchmark maxing è l'osservazione operativa che le architetture AI moderne sono ottimizzate selettivamente sui benchmark che hanno funzioni di reward computabili. RLVR (Reinforcement Learning from Verifiable Rewards), il paradigma di training dominante per i reasoning model 2025-2026, richiede per costruzione che l'output sia automaticamente verificabile: codice che passa o fallisce un test, dimostrazione matematica formale, soluzione a un puzzle con criterio binario. Su questi domini i modelli imparano a comportarsi sempre meglio, e i benchmark che misurano questi domini mostrano curve esponenziali. Su domini dove la "correttezza" non è automaticamente verificabile (giudizio legale, scelta strategica, diagnosi clinica differenziale, valutazione estetica) RLVR non può fare leva e la performance resta piatta. Il futuro AA Omniscience benchmark di Artificial Analysis (rilascio annunciato per Q2 2026) è uno dei tentativi di misurare il pavimento di affidabilità su task verificabili ma con un focus su quale modello sa dire "non lo so", invece di allucinare.

Il punto operativo per chi progetta sistemi aziendali è che la classe di task che la tua PMI vuole automatizzare con AI raramente cade nel dominio benchmark-maxabile. Un sistema di gestione delle ticket per customer support deve giudicare urgenza e ownership, criteri non automaticamente verificabili. Un assistente per la stesura di contratti deve valutare se una clausola tutela il cliente in un caso edge, criterio non automaticamente verificabile. Un copilot per analisti finanziari deve tradurre un piano industriale in valutazione di rischio, criterio non automaticamente verificabile. Per tutti questi task, la curva METR non ti dice nulla. Ti illude di sapere dove va il progresso, ma sta misurando una direzione diversa.

I dati dell'Osservatorio Politecnico Milano 2026 raccontano una conseguenza concreta: il mercato italiano AI vale 1,8 miliardi di euro con +50% YoY 2025, l'84% delle grandi aziende italiane ha acquistato licenze GenAI, ma solo il 9% ha governance strutturata e il 41% dei lavoratori dichiara di svolgere "attività che altrimenti non sarebbero in grado di fare". Quel 41% è in larga parte sui domini benchmark-maxabili (writing assist, codice, traduzioni, analisi su dati strutturati). Il gap di governance del 91% nasce in parte dal disallineamento tra le aspettative create dai grafici esponenziali sui benchmark e la realtà dei task aziendali non verificabili che restano fuori dalla curva.

Un esempio concreto dal mio orchestrator interno. A inizio marzo 2026 ho provato a sostituire il classifier che marca i ticket di customer support nella mia pipeline con un agente Opus 4.7 a few-shot, motivato dal nuovo time horizon. Sui 200 ticket di test il classifier raggiungeva 94% di accuracy (criterio binario verificabile, dominio benchmark-maxabile), ma il subsystem successivo, dove l'agente doveva scrivere la bozza di risposta tecnica al cliente, scendeva a 71% di "bozza accettabile senza riscrittura sostanziale" valutato da me a campione. I due numeri non sono confrontabili e non avrebbe senso aspettarsi che fossero lo stesso: il primo task è verificabile, il secondo è soft. Ma se l'orchestrator fosse stato in produzione con un cliente, il 71% si sarebbe presentato come incident operativi nel terzo mese, non come metrica nel primo. La curva METR mi dice che il modello è migliorato sul classifier; non mi dice nulla sulla bozza, dove i casi limite (cliente arrabbiato, contestazione di fatturazione, escalation legale) sono fuori distribuzione anche per l'attualOpus.

Lo stesso tipo di disallineamento metodologico è quello che ho descritto nell'articolo sulle cinque famiglie di compiti che non vanno date a un LLM diretto: conta i caratteri di una stringa è verificabile, scrivere una bozza commerciale che chiuda un deal non lo è, e i benchmark non distinguono i due casi.

L'errore che vedo ripetersi nei progetti che falliscono è la scelta di architettura basata sulle aspettative del benchmark, non sulle caratteristiche del task aziendale specifico. Un cliente ti chiede "automatizzare la classificazione delle email del customer service": è un task ben definito con criterio quasi-automatico, sta dentro la curva benchmark, va bene un'integrazione API diretta. Un cliente ti chiede "scrivere bozze di risposta a reclami complessi": è un task con criteri di qualità soft, fuori dalla curva benchmark, serve human-in-the-loop e validation pipeline. Confondere i due significa promettere il primo livello di affidabilità sul secondo tipo di task, e ritrovarti con un cliente arrabbiato dopo sei mesi.

La griglia che applico nella pipeline personale è semplice: prima di scegliere il modello e l'architettura, separo i task del cliente in tre categorie. Verificabili (criterio binario o oggettivo): METR predice bene, scegli il modello con il più alto 80%-horizon, non con il più alto 50%-horizon. Misurabili ma soft (richiede review umana per accettazione): METR ti dice solo che il modello "ci prova", devi misurare con metriche di qualità tue sul tuo dominio. Non verificabili (giudizio strategico, contenzioso, decisione clinica): METR è irrelevant, qui non parliamo di automazione ma di copilot che amplifica un esperto umano. La differenza la fa raccontare al cliente onestamente quale dei tre tipi di task ha proposto, e disegnare la pipeline che corrisponde, non quella che vorrebbe credere giustificata dal grafico esponenziale. Se questa è la conversazione che ti manca prima del prossimo investimento AI, il modulo di preventivo gratuito è il punto da cui inquadrare la richiesta in due minuti, sette domande.