Statistica e machine learning: perché ML senza statistica produce overclaim

Nel 2001 uno statistico di Berkeley scrive che il 98% della sua disciplina sta lavorando nel modo sbagliato. Aveva inventato le random forest, e stava descrivendo, senza ancora chiamarlo così, il machine learning. Questo capitolo chiude la Parte V mostrando che il ML non ha sostituito la statistica: ne è una delle due metà, e l’altra metà è ciò che impedisce ai suoi numeri di mentire.

Perché questo capitolo

I quattordici capitoli precedenti hanno costruito, pezzo per pezzo, una macchina per ragionare sotto incertezza: popolazione e campione, stimatore e parametro, intervalli di confidenza, test di ipotesi, massima verosimiglianza, bootstrap, calibrazione. Ogni capitolo ha anticipato che quegli strumenti servono per leggere i numeri di un sistema AI.

Questo capitolo riscuote la promessa: prende tutta la Parte V e la punta esplicitamente contro il machine learning. Dove i capitoli precedenti dicevano “questo strumento serve anche per l’AI”, questo dice perché, e cosa va storto quando l’AI lo ignora.

La tesi è secca, e il titolo la dichiara: il machine learning senza statistica produce overclaim. Non errori di calcolo — le librerie calcolano bene — ma errori di interpretazione, e sempre nella stessa direzione. Si presenta uno score come un fatto invece che come una stima. Si dichiara un modello “migliore” di un altro perché ha mezzo punto in più, ignorando che mezzo punto è dentro il rumore. Si pubblica il vincitore di un leaderboard senza chiedersi quanti modelli sono stati provati per trovarlo. Ogni volta, l’errore gonfia la fiducia: l’overclaim è la modalità di fallimento di default di un ML che ha dimenticato la statistica.

Conviene fissare cosa intende, qui, “overclaim”. Non è la frode di chi inventa numeri: è l’errore in buona fede di chi tratta un numero stimato come un numero certo. Lo stesso identico score — diciamo 88% — può essere riportato in modo onesto (“88%, intervallo [85%, 91%], su 500 esempi della distribuzione X”) o in modo che invita all’overclaim (“il modello è accurato all’88%”).

La seconda formulazione non mente: dice meno del vero, e omettendo l’incertezza induce chi legge a fidarsi più di quanto i dati giustifichino. L’overclaim è quasi sempre una colpa di omissione, e proprio per questo è insidioso — non c’è un’affermazione falsa da contestare, c’è un margine che non è stato scritto.

C’è anche una ragione concettuale, più profonda di una checklist di buone pratiche. Esiste un mito diffuso secondo cui il machine learning avrebbe superato la statistica, l’avrebbe resa una disciplina del passato, buona per gli A/B test ma irrilevante per le reti neurali. Il mito è falso, e capire perché è falso cambia il modo in cui si legge ogni numero prodotto da un modello.

Il machine learning non è il successore della statistica. È una delle sue due culture, cresciuta enormemente quando dati e potenza di calcolo l’hanno resa praticabile. L’altra cultura — quella dell’inferenza, dell’incertezza quantificata, dell’onestà sui numeri — non è stata superata. È diventata più necessaria, perché i numeri in gioco contano di più.

C’è una ragione anche per la posizione di questo capitolo: chiude la Parte V. Tutti i capitoli precedenti hanno costruito uno strumento e mostrato un suo uso su un sistema AI; questo capitolo li raccoglie e dichiara la tesi che li teneva insieme fin dall’inizio. Per chi ha letto la Parte in ordine, è il momento in cui i quattordici pezzi diventano una cosa sola. Per chi atterra qui da una ricerca, è una mappa: ogni sezione rimanda al capitolo dove lo strumento è costruito per davvero.

Un’ultima nota su cosa questo capitolo non è. Non è un capitolo di machine learning: non costruisce modelli, non spiega come si addestra una rete o come funziona una random forest. Quei capitoli stanno altrove nella wiki. Questo è un capitolo sul rapporto tra due discipline, e il suo scopo è darti una lente — la lente statistica — da tenere puntata su ogni sistema ML che incontrerai dopo. La lente non costruisce niente; serve a guardare bene. E guardare bene, in un campo dove i numeri si moltiplicano e contano sempre di più, è esattamente ciò che separa una valutazione onesta da un overclaim.

Questo capitolo è un capitolo-ponte e una sintesi. Non introduce uno strumento nuovo: collega gli strumenti già costruiti. Per ogni concetto della Parte V dirà due cose. Primo: il ML quel concetto lo eredita, spesso come equivalenza formale esatta, non come somiglianza vaga. Secondo: quel concetto resta lo strumento per fare le pulci ai modelli moderni — per dire quando uno score è reale e quando è rumore vestito da risultato.

Contesto

Il documento di nascita di questa frattura ha una data e un autore. Nel 2001, sulla rivista Statistical Science (vol. 16, n. 3), lo statistico Leo Breiman (1928-2005, professore a Berkeley, inventore degli alberi CART e delle random forest, e per anni consulente fuori dall’accademia) pubblica un articolo intitolato Statistical Modeling: The Two Cultures. È un articolo insolito: non dimostra un teorema, fa una diagnosi. E la diagnosi è che la statistica accademica sta lavorando, in larghissima maggioranza, nel modo sbagliato per i problemi che contano.

Breiman descrive due culture nell’uso dei modelli statistici. La prima, che chiama data modeling culture, assume che i dati siano generati da un modello stocastico dato: una regressione lineare con rumore gaussiano, un modello logistico, una specifica distribuzione di probabilità. Il lavoro consiste nello stimare i parametri di quel modello e poi interpretarli — il coefficiente vuol dire qualcosa, racconta come una variabile influenza un’altra. La validazione passa per i test sulla bontà del fit e l’analisi dei residui. Breiman stima che il 98% degli statistici accademici lavori così.

La seconda cultura, la algorithmic modeling culture, tratta il meccanismo che genera i dati come ignoto e, soprattutto, come irrilevante. Non si assume nessuna distribuzione. Si costruisce un algoritmo — una random forest, una rete neurale, una support vector machine, un boosting — come una scatola nera che mappa input a output, e lo si giudica con un solo criterio: l’accuratezza predittiva su dati che non ha mai visto, misurata su un test set o per cross-validation. Breiman stima questa cultura al 2% degli statistici. Ma è, parola per parola, la descrizione di ciò che pochi anni dopo il mondo avrebbe chiamato machine learning.

Conviene fermarsi un momento sul peso di chi parla. Breiman non era un esterno che criticava la statistica da fuori: era un suo membro di primo piano, e aveva fatto il percorso al contrario rispetto a molti — tredici anni come consulente fuori dall’accademia prima di tornare a Berkeley. Aveva visto, sul campo, problemi reali che i modelli statistici classici non risolvevano bene, e aveva costruito strumenti algoritmici per affrontarli. Quando scrive che il 98% della sua disciplina lavora nel modo sbagliato per i problemi che contano, non lo dice per provocazione: lo dice come diagnosi di chi ha lavorato su entrambi i lati. È questo che rende il paper difficile da liquidare.

L’argomento di Breiman è che l’impegno quasi esclusivo verso il data modeling ha prodotto teoria irrilevante e ha tenuto gli statistici lontani dai problemi interessanti. Tre accuse concrete. La prima: il modello stocastico assunto può semplicemente essere quello sbagliato, e i test di bontà del fit sono troppo deboli per accorgersene.

La seconda — Breiman la chiama the multiplicity of good models, la molteplicità dei buoni modelli — è che molti modelli diversi fittano ugualmente bene gli stessi dati, e ciascuno racconta una storia causale diversa: se ti affidi all’interpretazione dei parametri, stai scegliendo una storia tra molte senza un buon motivo. La terza: la fede nell’interpretabilità costa accuratezza, perché vincola a modelli semplici quando un black box predirebbe meglio.

Un punto va fissato subito, perché tutto il capitolo ci poggia sopra. Breiman non dice che il data modeling è sbagliato. Dice che è una scelta, non un default obbligatorio, e che le due culture risolvono problemi diversi: una vuole capire, l’altra vuole prevedere.

Nove anni dopo, sempre su Statistical Science (2010), la statistica Galit Shmueli formalizza la stessa frattura nell’articolo To Explain or to Predict?, distinguendo la modellazione esplicativa dalla modellazione predittiva e dimostrando un punto controintuitivo: un modello con alto potere esplicativo non è automaticamente un buon predittore, e viceversa. Spiegare e prevedere sono obiettivi diversi, e ottimizzare per l’uno non regala l’altro.

La conseguenza per la mappa di questa wiki è netta. Il machine learning non è un campo che si è staccato dalla statistica come un ramo. È una delle due culture già interne alla statistica — quella algoritmica — che è esplosa quando due ingredienti, prima mancanti, sono arrivati: dataset enormi e potenza di calcolo a basso costo. Questa è una filiazione documentata: c’è un paper che la afferma, scritto da un insider che aveva un piede in entrambe le culture.

Il momento di Breiman non arriva dal nulla. La cultura algoritmica esisteva da decenni: il perceptron — il primo modello di neurone artificiale addestrabile — proposto dallo psicologo statunitense Frank Rosenblatt nel 1958 è un suo antenato, e gli alberi di decisione e le reti neurali si studiavano da tempo. Quello che mancava era la legittimazione. Per la statistica accademica del Novecento un modello senza assunzioni distribuzionali esplicite, giudicato solo sull’accuratezza predittiva, era poco più di un trucco ingegneristico, non scienza.

Il paper di Breiman è il momento in cui un membro autorevole dell’establishment statistico — uno che aveva inventato strumenti che il manuale insegnava — dice in pubblico che il trucco ingegneristico era diventato il modo migliore di affrontare un’ampia classe di problemi reali. Negli stessi anni l’industria stava per dargli ragione su scala: la disponibilità di dati dal web e di GPU economiche avrebbe reso, nel decennio successivo, la cultura algoritmica non più una minoranza ma il mainstream dell’AI applicata.

Il dibattito che Breiman apre nel 2001 non si è mai chiuso del tutto — la statistica accademica e la comunità ML restano in parte due mondi con conferenze, riviste e gerghi distinti — ma la sua diagnosi si è rivelata profetica.

C’è una ragione per cui questa frattura, vecchia di vent’anni, conta più oggi che nel 2001. Allora i modelli algoritmici erano random forest e SVM, addestrati da specialisti che conoscevano entrambe le culture. Oggi un sistema ML è spesso un LLM dietro una chiamata API, usato da sviluppatori che non hanno mai studiato statistica, e i suoi numeri — score di benchmark, tassi di successo, metriche di valutazione — circolano in blog, thread, slide e decisioni di prodotto. La cultura algoritmica ha vinto sul piano dell’adozione, ma la sua vittoria ha portato in primo piano una popolazione di utenti che ha ereditato gli strumenti predittivi senza ereditare la disciplina dell’incertezza che dovrebbe accompagnarli. È esattamente il vuoto in cui l’overclaim prospera, ed è il vuoto che questo capitolo, e tutta la Parte V, cercano di colmare.

Nel grafo di questa wiki, il capitolo siede in fondo alla Parte V e ne è il punto di raccolta: tira le fila dei quattordici capitoli precedenti — da statistica-intro a calibrazione-statistica — e poggia su bias-varianza della Parte IV per il trade-off che il double descent rivede. Guarda avanti verso la Parte XVIII, dove i metodi della cultura algoritmica vengono costruiti uno per uno, e verso la Parte XLIV sulla valutazione, dove benchmark e leaderboard sono l’oggetto centrale. Non è un capitolo da leggere per primo: è un capitolo da leggere quando i quattordici strumenti della Parte sono già in mano, per vedere come si montano in una sola macchina.

L’intuizione

Primo angolo: due mestieri con lo stesso attrezzo

Immagina due persone che usano lo stesso attrezzo — un campione di dati — per due mestieri diversi.

La prima è un epidemiologo che vuole sapere se e quanto il fumo causa una certa malattia. Raccoglie dati, costruisce un modello, e la cosa che gli interessa è un numero dentro il modello: il coefficiente del fumo. Quel numero deve voler dire qualcosa, deve essere interpretabile, e attorno a quel numero gli serve un intervallo di confidenza, perché la sua conclusione — “il fumo aumenta il rischio di tanto” — è un’affermazione sul mondo che deve reggere alla domanda “quanto sei sicuro?”. A questo epidemiologo non interessa predire la malattia del prossimo paziente. Gli interessa capire un meccanismo. È la cultura del data modeling.

La seconda persona è un ingegnere che costruisce un filtro antispam. Non gliene importa niente di perché una mail è spam. Gli importa solo che il filtro, sulle mail di domani — mail che oggi non esistono ancora — sbagli il meno possibile. Userà il modello più accurato disponibile, anche se è una scatola nera di cui nessuno sa leggere i parametri. Lo giudicherà su una sola cosa: l’errore su mail mai viste. È la cultura algoritmica, è il machine learning.

Stesso attrezzo, il campione. Due mestieri. L’epidemiologo non può permettersi una scatola nera, perché la scatola nera non gli dice quanto il fumo conta. L’ingegnere non può permettersi di rinunciare all’accuratezza in cambio di un coefficiente leggibile, perché il coefficiente leggibile non ferma lo spam. Non è che uno dei due ha ragione: risolvono problemi diversi.

E quando senti dire “il ML ha superato la statistica”, quello che è successo davvero è che il mestiere dell’ingegnere è diventato economicamente enorme — perché i dati e il calcolo sono diventati abbondanti — mentre il mestiere dell’epidemiologo è rimasto della stessa dimensione di sempre. Una cultura è cresciuta. L’altra non è morta: è solo rimasta dov’era, e serve ancora esattamente per quello che ha sempre fatto.

C’è un dettaglio di questa metafora che vale la pena tenere, perché è il cuore della tesi del capitolo. Anche l’ingegnere — quello che non vuole capire, vuole solo prevedere — ha bisogno della statistica. Non per interpretare un coefficiente, ma per rispondere a una domanda diversa: “il mio filtro sbaglia davvero meno, o ho solo avuto fortuna sul campione di mail con cui l’ho misurato?”. Quella domanda è inferenza pura. L’ingegnere può ignorare l’interpretabilità, ma non può ignorare l’incertezza della sua stima di errore senza scivolare nell’overclaim. È il punto in cui le due culture, per quanto distinte negli obiettivi, restano legate: nessuna delle due può fare a meno della logica dell’incertezza.

Secondo angolo: lo stesso calcolo sotto due nomi

C’è un secondo modo di vedere il legame, più tecnico e più stretto. In molti casi il ML e la statistica non somigliano: fanno letteralmente lo stesso calcolo, chiamandolo in due modi.

Prendi la cross-entropy loss, la funzione che ogni classificatore — dalla regressione logistica alla rete profonda — minimizza durante il training. Nel capitolo maximum-likelihood hai visto la massima verosimiglianza: scegli i parametri che rendono i dati osservati i più probabili possibile. Ebbene: minimizzare la cross-entropy è, riga per riga, massimizzare la log-verosimiglianza. Non è un’analogia, è la stessa formula con il segno cambiato. Quando un ingegnere ML scrive loss = cross_entropy(...) e quando uno statistico scrive “stimo i parametri per massima verosimiglianza”, stanno scrivendo la stessa cosa.

Lo stesso vale per la regressione: minimizzare l’errore quadratico medio è massima verosimiglianza sotto l’assunzione di rumore gaussiano (capitolo regressione-statistica). E vale per la regolarizzazione: il weight decay, la penalità L2 che ogni rete neurale usa per non fittare il rumore, è una stima MAP con un prior gaussiano sui pesi (capitolo map-bayesiano). La L1 è lo stesso con un prior di Laplace.

L’intuizione da portare via è questa: sotto il vocabolario del deep learning — loss, training, regolarizzazione, fit — c’è, in molti punti centrali, la statistica inferenziale del Novecento, intatta. Non sotto forma di somiglianza didattica, ma sotto forma di identità matematica. Il ML non ha sostituito quelle formule. Le ha rinominate e le esegue su scala più grande.

Questo ha una conseguenza pratica che vale più di una curiosità terminologica. Se la cross-entropy è la verosimiglianza, allora tutto ciò che la statistica sa sulla massima verosimiglianza — quando è uno stimatore buono, quando è distorto, come si comporta su pochi dati, quando va regolarizzata — si applica al training di una rete. Conoscere la statistica dietro il nome non è erudizione: è ciò che permette di prevedere quando un metodo di training si comporterà male, invece di scoprirlo dopo. Chi vede solo “una loss da minimizzare” ha meno strumenti di chi riconosce, sotto, uno stimatore con un secolo di teoria alle spalle.

Terzo angolo: ogni numero è una scommessa sul non visto

C’è un terzo modo di guardare il legame, ed è il più utile per capire da dove nasce l’overclaim. Ogni numero che esce da un sistema di machine learning è, senza eccezioni, una scommessa su dati che non sono stati osservati.

Quando un eval restituisce “91.3% di accuratezza”, quel numero non descrive il modello. Descrive il comportamento del modello su quei 500 o 5000 esempi del test set, che sono un campione. Il numero che davvero interessa — l’accuratezza sulla popolazione di tutti gli input possibili — non è osservabile, e il 91.3% ne è una stima. Cambia il test set, cambia il numero, anche se il modello è identico.

Lo sviluppatore che viene dalla programmazione deterministica ha qui un istinto che lo tradisce: una funzione che restituisce un valore restituisce quel valore, sempre. Uno score di un modello non è un valore restituito: è una stima con un’incertezza attaccata, e se l’incertezza non viene dichiarata non sparisce — resta nascosta, e diventa la materia prima dell’overclaim.

Questo cambia il modo di leggere ogni report. Davanti a “il modello ha il 91.3% di accuratezza” la domanda giusta non è “è un buon numero?” ma “quanto è solida questa scommessa?”. E la solidità si misura: dipende da quanto è grande il campione su cui il numero è stato calcolato e da quanto quel campione somiglia ai dati che il modello incontrerà davvero. Un numero senza queste due informazioni accanto non è un risultato, è una scommessa di cui non è stata dichiarata la posta.

Questo angolo unifica i due precedenti. La cultura del data modeling e quella algoritmica scommettono entrambe sul non visto: l’epidemiologo scommette che il coefficiente stimato sul suo campione valga sulla popolazione, l’ingegnere scommette che l’errore misurato sul test set valga sulle mail di domani. La differenza è solo cosa scommettono. Ma la struttura della scommessa — una parte osservata, un tutto da indovinare, un’incertezza da quantificare — è la stessa.

Ed è la statistica, non il machine learning, la disciplina che ha passato un secolo a rendere matematizzabile quella scommessa. Un sistema ML che riporta i suoi numeri senza incertezza non ha eliminato la scommessa: ha solo smesso di dichiararla.

La meccanica

Resa precisa, la relazione si articola in tre movimenti: cosa il ML eredita, cosa il ML cambia, e come la statistica resta la lente per leggere i modelli moderni.

Cosa il ML eredita dalla statistica

Questa è la mappa dei collegamenti con i capitoli precedenti della Parte V. Per ciascuno, dichiaro la classe del legame — e la dichiarazione non è una formalità: la regola editoriale di questa wiki chiede di distinguere quando due cose somigliano (analogia), quando una discende dall’altra (filiazione), e quando sono la stessa cosa sotto nomi diversi (equivalenza). Nella relazione tra ML e statistica compaiono tutte e tre, e confonderle è un errore frequente. Buona parte dei legami che seguono sono equivalenze — il caso più forte, che va argomentato e non solo asserito — e qualcuno è eredità di vocabolario. Quasi nessuno è semplice analogia: il legame tra le due discipline è più stretto di una somiglianza didattica.

Popolazione e campione (capitolo statistica-intro). Il training set di un modello è un campione. La “popolazione” è la distribuzione da cui i dati sono stati estratti — tutte le mail possibili, tutte le immagini possibili, tutto il testo possibile. L’affermazione “il modello generalizza” è esattamente l’affermazione “la stima fatta sul campione vale sulla popolazione”. Classe: equivalenza. Il train/test split non somiglia al campionamento, è campionamento.

Stima (capitolo stima-puntiale). I pesi di un modello sono parametri stimati da un campione. “Addestrare un modello” è “calcolare uno stimatore”. Le proprietà che hai studiato — bias e varianza dello stimatore, consistenza — si applicano ai pesi con lo stesso significato tecnico. Classe: equivalenza.

Massima verosimiglianza (capitolo maximum-likelihood). La cross-entropy loss è la log-verosimiglianza negativa; l’MSE è MLE sotto rumore gaussiano. Classe: equivalenza formale, dimostrabile. Vedi anche entropia e cross-entropy nella Parte IV.

MAP e regolarizzazione (capitolo map-bayesiano). La penalità L2 è una stima MAP con prior gaussiano. Classe: equivalenza formale.

Regressione (capitolo regressione-statistica). La regressione lineare e quella logistica vivono su entrambi i lati della frattura: sono modelli statistici classici e i mattoni elementari delle reti. Un singolo neurone con attivazione sigmoide, addestrato con cross-entropy, è una regressione logistica. La regressione è il punto fisico in cui le due culture si toccano.

Bias-varianza (capitolo bias-varianza, Parte IV). Il trade-off classico: modelli troppo semplici hanno bias alto e fanno underfitting; modelli troppo complessi hanno varianza alta e fanno overfitting; l’errore di test, al crescere della complessità, segue una curva a U. Il ML eredita questo vocabolario per intero. Classe: eredità di vocabolario — e tra poco vedremo che il ML moderno lo complica.

Intervalli di confidenza e incertezza (capitoli intervalli-confidenza, legge dei grandi numeri e CLT, bootstrap). Uno score su un benchmark è una proporzione campionaria. Come ogni proporzione, ha uno standard error, e quel numero ha una formula:

$\text{SE} = \sqrt{\frac{p\,(1-p)}{n}}$

In parole povere, questo dice che l’incertezza su uno score dipende da due cose: quanto vale lo score stesso ( $p$ , la frazione di risposte corrette) e quanto è grande il test set ( $n$ , il numero di esempi). Più esempi, meno incertezza, e l’incertezza scende come la radice di $n$ : per dimezzarla servono quattro volte più esempi. Questa formula è il teorema del limite centrale applicato a una proporzione. Quando non esiste una formula chiusa, il bootstrap fornisce le error bar simulando.

Distribuzioni (capitolo distribuzioni-comuni). Ogni risposta giusta-o-sbagliata di un modello è una prova di Bernoulli; la somma di molte prove tende alla normale via CLT. La base probabilistica del ML è la stessa della statistica.

Conviene fissare le equivalenze formali in una tabella, perché sono il punto in cui “eredità” smette di essere una parola vaga e diventa identità dimostrabile. A sinistra il nome che usa il deep learning, a destra il nome che usa la statistica, e la relazione non è somiglianza ma uguaglianza del calcolo sottostante.

Nel vocabolario del ML	Nel vocabolario della statistica
training set	campione estratto dalla popolazione
addestrare un modello	calcolare uno stimatore
pesi del modello	parametri stimati
cross-entropy loss minimizzata	log-verosimiglianza negativa (MLE)
MSE loss minimizzata	MLE sotto rumore gaussiano
weight decay / penalità L2	stima MAP con prior gaussiano
penalità L1	stima MAP con prior di Laplace
score su un test set	stima di una proporzione, con standard error
k-fold cross-validation	stima empirica della distribuzione campionaria dell’errore

Le righe della tabella non sono mnemoniche da imparare: sono affermazioni di classe “equivalenza”, ognuna dimostrabile con un passaggio algebrico. Quando un capitolo della Parte XVIII spiegherà la cross-entropy come “la loss standard per la classificazione”, starà descrivendo, sotto un altro nome, la massima verosimiglianza del capitolo maximum-likelihood.

Cosa il ML cambia rispetto alla statistica classica

L’eredità è massiccia, ma il ML non è statistica classica travestita. La tabella delle equivalenze fotografa ciò che resta identico; ma se tutto fosse identico, “machine learning” sarebbe solo un sinonimo di “statistica” e non sarebbe nato un campo distinto. La differenza esiste, ed è reale. Quattro spostamenti sono i più importanti.

Primo: la predizione fuori-campione prima dell’interpretabilità. La statistica classica giudica un modello anche su quanto i suoi parametri sono leggibili. Il ML, nella cultura algoritmica, accetta una scatola nera opaca se predice meglio. Nessuno legge i pesi di una random forest o di una rete profonda. Si giudica solo l’errore di test. È lo spostamento di Breiman, e ha un costo: si guadagna accuratezza, si perde la capacità di dire perché.

Secondo: dataset enormi e modelli sovra-parametrizzati. La statistica del Novecento nasce in regime di dati scarsi. William Sealy Gosset, il chimico della Guinness che firmava “Student”, studiava campioni piccoli perché in birreria non si fanno migliaia di prove; Ronald Fisher lavorava con manciate di appezzamenti agricoli. In quel regime il numero di parametri $p$ era molto minore del numero di osservazioni $n$ . Il ML moderno lavora nel regime opposto: una rete può avere $p$ molto maggiore di $n$ — miliardi di parametri su milioni di esempi. In questo regime alcuni teoremi asintotici classici perdono la loro presa pratica.

Vale la pena rendere concreto perché il regime $p > n$ è così estraneo alla statistica classica. Il manuale insegna che un modello con più parametri che osservazioni è sotto-determinato: ci sono infinite combinazioni di parametri che fittano i dati alla perfezione, e nessuna ragione, dai soli dati, per preferirne una. Nel data modeling questo è una condanna: un modello sotto-determinato è inutilizzabile, perché i suoi coefficienti — la cosa che interessa — non sono identificati. La statistica classica reagisce con una regola di igiene: tieni $p$ ben sotto $n$ , conta i gradi di libertà, non chiedere ai dati più di quanto possano dire.

Il ML moderno viola questa regola di proposito, e funziona lo stesso. Una rete con miliardi di parametri addestrata su un milione di esempi è massicciamente sotto-determinata: la statistica classica predirebbe overfitting catastrofico. Invece generalizza.

La spiegazione, ancora oggi solo parzialmente compresa, è che il processo di addestramento — la discesa del gradiente, vedi discesa del gradiente nella Parte IV — non sceglie una soluzione qualsiasi tra le infinite che fittano i dati. Ne sceglie una con proprietà particolari (informalmente, la “più semplice” o “più liscia” tra quelle disponibili), e quella tende a generalizzare.

Questa preferenza implicita ha un nome, implicit regularization, e il punto da portare via è che nel regime $p > n$ la capacità di generalizzare non viene più dal contare i gradi di libertà — la ricetta classica — ma da come l’ottimizzatore si muove nel paesaggio dei parametri. È un terreno dove la teoria classica dà risposte sbagliate, e il double descent è il sintomo più visibile di questo scarto.

Terzo, e più sorprendente: il double descent. Ne parliamo nella sezione dedicata, perché è il punto in cui il ML moderno non solo eredita ma contraddice un pezzo del manuale classico.

Quarto: cross-validation al posto dei test analitici. La statistica classica, povera di dati, sviluppa formule analitiche per stimare l’errore: standard error in forma chiusa, criteri come AIC e BIC che penalizzano la complessità con un termine calcolato. Il ML, ricco di dati, può permettersi di stimare l’errore di generalizzazione empiricamente: tiene da parte una porzione di dati come validation o test set, oppure fa $k$ -fold cross-validation — divide i dati in $k$ blocchi, addestra su $k-1$ e misura sul blocco escluso, ruotando.

È lo stesso spirito del bootstrap: simulare invece di derivare. Quando i dati abbondano, contare batte calcolare. Vale la pena vedere perché questo spostamento è più di una comodità. Una formula analitica per lo standard error vale solo sotto le assunzioni con cui è stata derivata — una certa distribuzione del rumore, l’indipendenza delle osservazioni, una forma del modello. Se l’assunzione è sbagliata, la formula dà un numero preciso e falso. La stima empirica — cross-validation, bootstrap — non assume la distribuzione: la legge dai dati. È più robusta proprio perché chiede di meno. Il prezzo è il costo di calcolo: dove la formula dà la risposta in un’operazione, la simulazione richiede di riaddestrare o ricampionare centinaia di volte. Nel regime di dati e compute abbondanti del ML moderno, quel prezzo si paga volentieri.

Il double descent: dove il manuale classico si incrina

Per decenni il trade-off bias-varianza è stato insegnato come una legge: la curva dell’errore di test, al crescere della complessità del modello, ha la forma di una U, e il punto giusto è il fondo della U. Spingere oltre significa overfitting, errore che risale.

I modelli moderni non si comportano così, e per anni questo è stato un imbarazzo tacito: le reti profonde hanno spesso più parametri dei dati, dovrebbero overfittare in modo catastrofico, e invece generalizzano bene. Nel 2019 due paper mettono il fenomeno a fuoco. Mikhail Belkin, Daniel Hsu, Siyuan Ma e Soumik Mandal, in Reconciling modern machine-learning practice and the classical bias-variance trade-off (PNAS, vol. 116 n. 32, 2019), e Preetum Nakkiran e colleghi di OpenAI e Harvard in Deep Double Descent: Where Bigger Models and More Data Hurt (arXiv 1912.02292, 2019).

Il fenomeno è questo. Al crescere della capacità del modello, l’errore di test segue prima la classica U: scende, tocca un minimo, risale. Risalendo, raggiunge un picco netto in un punto preciso — la soglia di interpolazione, il punto in cui il modello ha esattamente abbastanza parametri da fittare perfettamente il training set, errore di training a zero. E poi, oltre quel picco, l’errore di test ridiscende. Modelli ancora più grandi generalizzano meglio, a volte meglio del minimo della U classica. La curva ha due discese: di qui il nome, double descent.

Belkin e colleghi mostrano che il fenomeno è ubiquo: random forest, reti neurali, boosting, su dati immagine e testo. Nakkiran e colleghi lo estendono in tre direzioni. Il double descent compare al variare del numero di parametri (lo chiamano model-wise), ma anche al variare del numero di epoche di training (epoch-wise: lo stesso modello, addestrato più a lungo, può prima peggiorare e poi migliorare), e — il punto più controintuitivo — al variare della dimensione del dataset (sample-wise), per cui in una zona specifica più dati peggiorano il test error. Nakkiran propone come metro unificante l’effective model complexity, una nozione di complessità che assorbe tutti e tre i casi.

Va dichiarata con precisione la classe di questa affermazione, perché è facile esagerarla. Il double descent non dimostra che il trade-off bias-varianza è “falso” o “sbagliato”. Il trade-off resta una descrizione corretta nel suo regime — sotto la soglia di interpolazione, quando $p < n$ .

Quello che il double descent mostra è che il trade-off era un caso particolare, valido in un regime, scambiato per legge universale. La classe corretta dell’affermazione è precisazione di scope, non confutazione. È la stessa relazione che la meccanica relativistica ha con quella newtoniana: non smentita, ma circoscritta.

C’è una lezione metodologica più larga, e riguarda proprio il rapporto tra le due culture. Il trade-off bias-varianza era una previsione teorica, derivata da assunzioni; il double descent è un’osservazione empirica, emersa quando si è guardato un regime che la teoria non aveva esplorato. È un caso da manuale di come la cultura algoritmica corregge quella del data modeling: non con un teorema migliore, ma misurando dove la teoria classica non era mai stata messa alla prova. La statistica non perde da questo scambio — guadagna un fenomeno nuovo da spiegare, e infatti la ricerca statistica sul perché il double descent emerge è oggi attiva. Le due culture si correggono a vicenda; non si sostituiscono.

La statistica come lente diagnostica sui modelli moderni

Il ML cambia le priorità, ma non può abolire la statistica. Anzi: più i modelli diventano grandi e opachi, più la statistica torna utile in un ruolo preciso — non come strumento per costruire il modello, ma come lente per leggerne onestamente i numeri. Quattro usi diagnostici, ciascuno ancorato a un capitolo della Parte V.

Calibrazione. Un modello che dichiara confidenza 0.9 è calibrato se, su tutte le volte che dice 0.9, ha ragione il 90% delle volte (capitolo calibrazione-statistica). È un controllo a posteriori, fatto contando. Il risultato controintuitivo del capitolo sulla calibrazione: le reti profonde moderne, e gli LLM dopo l’allineamento, sono spesso peggio calibrate dei modelli piccoli e meno accurati che hanno sostituito. Accuratezza alta e onestà probabilistica non vanno insieme da sole. Senza un’analisi di calibrazione, “il modello è sicuro al 90%” è una frase priva di contenuto verificabile.

Significatività delle differenze tra modelli. Il modello A segna 92.1% su un benchmark, B segna 91.4%. A è migliore? È esattamente la domanda del capitolo test-ipotesi. Ogni score è una proporzione campionaria; la differenza ha un suo standard error; e una differenza dentro un paio di standard error è compatibile con due modelli di pari capacità. Senza questo calcolo, ogni classifica di modelli ordina anche il rumore.

Multiple testing sui leaderboard. Il capitolo multiple-testing insegna che, fatti abbastanza test, qualcuno risulta significativo per puro caso. Un leaderboard con centinaia di modelli è un esperimento a centinaia di confronti; il modello in cima è spesso il più fortunato sul rumore di quel particolare test set, non il migliore. È la winner’s curse: la performance reale del vincitore è quasi sempre più bassa dello score che gli ha fatto vincere. Le correzioni nate per la genomica — Bonferroni, false discovery rate — si applicano concettualmente identiche.

Overfitting al test set. Un test set riusato mille volte smette di essere fuori-campione. Ogni decisione presa guardando il test set — scelta dell’architettura, degli iperparametri, di quale modello pubblicare — lo contamina un po’. Il leakage del benchmark è la versione ML del p-hacking: non un imbroglio deliberato, ma l’effetto cumulato di troppe occhiate allo stesso campione.

Questi quattro usi diagnostici hanno una cosa in comune, e vale la pena nominarla. Nessuno di essi serve a costruire un modello migliore: servono tutti a giudicare onestamente un modello già costruito. È la divisione del lavoro tra le due culture vista da vicino. La cultura algoritmica costruisce; la cultura inferenziale verifica. Un team che ha solo la prima produce modelli e numeri; un team che ha entrambe produce modelli e numeri di cui sa dichiarare l’affidabilità. La differenza, di nuovo, è tutta tra fare un sistema e sapere quanto fidarsene.

Statistica e LLM: valutazione, incertezza, allucinazioni

Gli LLM alzano la posta, ma i concetti restano quelli della Parte V. Tre punti, perché qui l’overclaim è più costoso e più diffuso.

Valutare un LLM è inferenza statistica. Lo score su un benchmark come MMLU (Massive Multitask Language Understanding, un test a scelta multipla su decine di materie) o GSM8K (un insieme di problemi di matematica da scuola elementare) è una proporzione su un campione di domande, con la sua incertezza. È il contenuto di Adding Error Bars to Evals di Evan Miller (arXiv 2411.00640, 2024): le differenze di pochi punti tra modelli sui leaderboard sono spesso dentro il rumore campionario, e vanno riportate con intervallo di confidenza.

La contaminazione del benchmark è leakage di campione. Un benchmark pubblico, dopo qualche anno, finisce — domande e risposte — dentro i dati di pretraining del modello successivo. Quando questo accade, il test set non è più un campione di dati mai visti: è in parte materiale di training. Lo score gonfia, e gonfia in modo che nessuna error bar cattura, perché l’errore non è varianza campionaria ma una violazione dell’assunzione stessa di “fuori-campione”. È la versione su scala del data leakage che la statistica conosce da sempre: misurare su dati che il modello, in un modo o nell’altro, ha già visto.

Incertezza aleatoria contro incertezza epistemica. Un LLM produce, a ogni passo, una distribuzione di probabilità sul prossimo token. Quella distribuzione esprime un’incertezza, ma di un tipo solo: incertezza aleatoria — quale token verrà campionato. Non esprime incertezza epistemica — se la risposta è vera. Un’entropia bassa sui logit significa che il modello è deciso, non che sa. Confondere le due è un errore statistico che si propaga in ogni sistema che legge la confidenza di un LLM come garanzia di verità.

Le allucinazioni come fenomeno statistico. Questo è il punto in cui la statistica dà la lettura più profonda della modalità di fallimento più discussa degli LLM. Lo svolge per esteso la sezione “Dove si rompe”.

Il filo che lega questi tre punti è uno solo. Un LLM è, dal punto di vista statistico, un oggetto enorme e opaco, ma i numeri che produce — e i numeri che lo descrivono — restano stime su campioni, distribuzioni di probabilità, proporzioni con un’incertezza. La taglia del modello non cambia la natura di quei numeri. Cambia solo quanto costa sbagliare a leggerli, perché un LLM mal valutato non resta in un report: entra in un prodotto, in una decisione, in un’interfaccia usata da milioni di persone. È per questo che la statistica, lungi dall’essere resa obsoleta dagli LLM, torna utile esattamente dove serve di più.

Il prezzo dello spostamento: l’interpretabilità che si perde

Resta un conto da fare esplicitamente, perché la sintesi non sia un’apologia. Quando la cultura algoritmica vince sul terreno dell’accuratezza, qualcosa si perde, e quel qualcosa è proprio ciò che alla cultura del data modeling stava più a cuore: la capacità di leggere il modello.

Nel data modeling il parametro stimato è il risultato. Il coefficiente del fumo in un modello epidemiologico non è un dettaglio interno: è la conclusione, ed è interpretabile — dice di quanto cambia il rischio. In una rete profonda i parametri sono miliardi di numeri senza significato individuale; nessuno li legge, e non c’è “il coefficiente di” qualcosa. Il modello predice bene e tace sul perché.

Questa non è una mancanza temporanea che la ricerca colmerà a breve. È strutturale alla scelta di Breiman: la cultura algoritmica compra accuratezza con la moneta dell’interpretabilità. Per molti problemi il cambio conviene — a un filtro antispam non serve spiegarsi. Per altri no: una decisione medica, una concessione di credito, una sentenza assistita da un modello richiedono di poter dire perché, e lì un black box accurato non basta.

È nata un’intera disciplina per recuperare a posteriori un po’ di quella leggibilità — l’interpretabilità del machine learning, con strumenti che cercano di spiegare le predizioni di un modello opaco senza riaddestrarlo. Ma vale la pena tenere chiara la classe dell’affermazione: quegli strumenti producono spiegazioni approssimate di un modello che resta intrinsecamente non interpretabile. Non riportano la cultura algoritmica dentro quella del data modeling. Costruiscono un ponte sopra la frattura, non la chiudono.

Esempi

Esempio numerico: due modelli su un benchmark

Un leaderboard mette in cima il modello A con 88.0% e sotto il modello B con 85.6%, su un benchmark di 500 esempi. Il modello A è “lo stato dell’arte”, in grassetto.

Calcoliamo. Lo standard error dello score di A è $\sqrt{0.88 \cdot 0.12 / 500} \approx 0.0145$ , cioè circa 1.5 punti percentuali. Quello di B è simile. Lo standard error della differenza tra i due score è circa $\sqrt{0.0145^2 + 0.0153^2} \approx 0.021$ , poco più di 2 punti.

La differenza osservata è 2.4 punti: appena 1.1 standard error. Nel linguaggio del capitolo test-ipotesi, una differenza di poco più di un standard error non è statisticamente significativa: è perfettamente compatibile con due modelli di pari capacità misurati su un campione rumoroso. Il leaderboard la riporta come un risultato. È, con buona probabilità, rumore in grassetto.

C’è un secondo strato, più sottile, e tocca la winner’s curse del capitolo multiple-testing. Se quel leaderboard non confronta due modelli ma cinquanta, e si guarda solo chi è in cima, la situazione peggiora. Con cinquanta modelli di capacità simile, qualcuno finirà in cima per fortuna campionaria, e il suo score osservato sarà sistematicamente più alto del suo score vero — perché è stato selezionato proprio per essere il massimo. Lo score del vincitore è uno stimatore distorto verso l’alto della sua capacità reale. È il motivo per cui un modello che debutta primo su un benchmark spesso “regredisce” quando viene rimisurato: non è peggiorato, era stato sovrastimato dal fatto stesso di aver vinto.

Esempio in codice: cross_val_score è una distribuzione campionaria

from sklearn.model_selection import cross_val_score

scores = cross_val_score(model, X, y, cv=10)
print(scores.mean(), scores.std())

Cosa restituisce davvero questo frammento. cross_val_score con cv=10 addestra il modello dieci volte, ogni volta su nove decimi dei dati, e lo valuta sul decimo escluso. Il risultato è un vettore di dieci score. Quel vettore non è un dettaglio tecnico: è una stima empirica della distribuzione campionaria dell’errore — esattamente l’oggetto che il capitolo legge dei grandi numeri e CLT chiama distribuzione di una statistica, e che il capitolo bootstrap costruisce per ricampionamento.

La .mean() è la stima puntuale; la .std() è una stima dello standard error. Riportare solo la media, senza la deviazione standard, significa buttare via metà del risultato — la metà che dice quanto fidarsi dell’altra.

Esempio scenario reale: la grid search che trova oro e perde tutto

Un team fa una grid search su 200 combinazioni di iperparametri. Una di esse spunta un +1.5% di accuratezza di validation rispetto alla configurazione di partenza. Il team la adotta, la mette in produzione. In produzione il guadagno svanisce: lo score torna quello di prima.

Cosa è successo. Provare 200 configurazioni e tenere la migliore sullo score di validation è, senza che nessuno lo abbia chiamato così, un esperimento a 200 test. È il problema del capitolo multiple-testing: se cerchi abbastanza, qualcosa risulta positivo per puro caso. La configurazione “vincente” era quella più fortunata sul rumore di quel particolare validation set, non quella davvero migliore. Il +1.5% era rumore selezionato, e la produzione — un campione nuovo — non aveva motivo di confermarlo.

Il rimedio non è smettere di fare grid search: la ricerca di iperparametri è necessaria. Il rimedio è separare la fase di ricerca dalla fase di stima. Si usa il validation set per scegliere la configurazione, poi si misura la configurazione scelta — una sola volta — su un terzo insieme di dati, mai toccato durante la ricerca. Quello score, e non il +1.5% di validation, è la stima onesta. È la stessa disciplina che il capitolo multiple-testing chiede per ogni esperimento a molti confronti: chi cerca tanto deve validare il vincitore altrove.

Esempio concettuale: il neurone che è una regressione logistica

Prendi il modello statistico più classico del manuale, la regressione logistica: una combinazione lineare degli input passata attraverso una funzione sigmoide per produrre una probabilità, con i parametri stimati per massima verosimiglianza. Ora prendi il componente più elementare di una rete neurale: un neurone con attivazione sigmoide, addestrato con cross-entropy loss. Sono lo stesso oggetto. Non somigliano: coincidono.

La cultura del data modeling e quella algoritmica, qui, condividono fisicamente il mattone. La rete profonda è quel mattone ripetuto e impilato a milioni — ma il mattone viene dal manuale di statistica. La differenza tra le due culture non è nei mattoni: è in cosa ci si costruisce e con quale criterio lo si giudica. La regressione logistica usata da sola, con pochi predittori scelti a mano e i coefficienti letti uno per uno, è data modeling. La stessa regressione logistica impilata a milioni di copie, addestrata su dati grezzi e giudicata solo sull’errore di test, è la cultura algoritmica. Identico l’attrezzo, opposto il mestiere — esattamente il primo angolo di intuizione, ora visto al livello del singolo neurone.

Esempio del fenomeno: il modello più grande che, contro il manuale, vince

Un team addestra una famiglia di reti per classificare immagini, facendo crescere la dimensione del modello: 10 mila parametri, 100 mila, un milione, dieci milioni. Misura l’errore di test a ogni taglia e lo mette in grafico. Sulle prime taglie vede esattamente la U del manuale: l’errore scende, tocca un minimo intorno a un certo numero di parametri, poi risale. Un istruttore di statistica classica si fermerebbe al minimo della U e direbbe “ecco la taglia giusta, oltre è overfitting”.

Il team invece continua. La rete da un milione di parametri ha errore di test peggiore di quella ottimale — sta nella zona di risalita. Ma la rete da dieci milioni, quella che supera la soglia di interpolazione e fitta perfettamente ogni esempio di training, ha errore di test di nuovo basso, e quella ancora più grande lo abbassa ulteriormente. È il double descent osservato in laboratorio: il modello che il manuale classico avrebbe scartato come “troppo grande, overfitterà” è quello che generalizza meglio.

La lezione non è “il manuale mente”: è che il manuale descriveva la prima metà del grafico, e nessuno aveva guardato abbastanza a destra. Per chi costruisce sistemi AI oggi questo ha un risvolto operativo concreto: la vecchia regola “se peggiora sul test, riduci la capacità del modello” non è più universalmente valida. A volte la mossa giusta, davanti a un modello che overfitta, è ingrandirlo ancora — spingerlo oltre la soglia di interpolazione invece di tirarlo indietro. È una mossa che la sola intuizione classica del bias-varianza non suggerirebbe mai, e che solo conoscere il double descent rende pensabile.

Esempio in codice: error bar su una metrica senza formula chiusa

Lo score di accuratezza ha una formula per lo standard error. Una metrica aggregata come l’F1 — la media armonica di precision e recall — non ce l’ha in forma comoda. Il bootstrap risolve, ed è poche righe.

import numpy as np
from sklearn.metrics import f1_score

def bootstrap_f1(y_true, y_pred, n_boot=2000):
    n = len(y_true)
    scores = []
    for _ in range(n_boot):
        idx = np.random.randint(0, n, size=n)   # ricampiona con reinserimento
        scores.append(f1_score(y_true[idx], y_pred[idx]))
    lo, hi = np.percentile(scores, [2.5, 97.5])
    return np.mean(scores), (lo, hi)

Cosa fa, riga per riga. np.random.randint pesca $n$ indici a caso con reinserimento: ogni “campione bootstrap” è un test set finto, costruito ripescando dal test set vero. Per ognuno si ricalcola l’F1. Dopo 2000 ripetizioni si ha una distribuzione di 2000 valori di F1 — la distribuzione campionaria stimata empiricamente, esattamente come nel capitolo bootstrap. I percentili 2.5 e 97.5 sono gli estremi di un intervallo di confidenza al 95%.

Il valore di questo frammento non è il codice in sé: è che trasforma “F1 = 0.83” in “F1 = 0.83, intervallo [0.79, 0.86]”. Il primo è un numero che invita all’overclaim; il secondo dichiara quanto fidarsi. La differenza tra i due è tutta la tesi del capitolo, in una riga di output.

Vale la pena notare che questo bootstrap non assume nulla sulla distribuzione dell’F1 — non c’è una formula, non c’è una gaussiana invocata. Costruisce l’incertezza pescando dal campione che si ha. È la cultura algoritmica applicata alla statistica stessa: invece di derivare un risultato da assunzioni, lo si simula dai dati. Lo strumento è di pochi anni dopo Breiman, ma incarna alla perfezione lo spirito che lui descriveva — e mostra che le due culture non si combattono solo, a volte si prestano i metodi a vicenda.

Esempio statistico classico: l’A/B test che è inferenza pura

Vale la pena un esempio che non è deep learning, per ricordare che l’altra cultura non è scomparsa. Un team cambia il prompt di sistema di un assistente e vuole sapere se gli utenti sono più soddisfatti. Mostra il vecchio prompt a metà degli utenti e il nuovo all’altra metà, e misura il tasso di pollice-su.

Variante A: 1200 valutazioni, 61% di pollice-su. Variante B: 1200 valutazioni, 64%. La differenza è 3 punti. È reale? Lo standard error di ciascun tasso è circa $\sqrt{0.62 \cdot 0.38 / 1200} \approx 0.014$ ; quello della differenza è circa $0.020$ . La differenza osservata, 3 punti, è circa 1.5 standard error: nella zona grigia, suggestiva ma non conclusiva. La conclusione onesta non è “B vince”, è “B promette, raccogliere più dati prima di decidere”.

Questo è inferenza statistica classica, identica nella struttura a quella che Fisher faceva sui campi agricoli un secolo fa, e identica nella struttura al confronto tra due modelli su un benchmark. È la prova che la cultura del data modeling non è un reperto: chiunque costruisca sistemi AI la usa ogni volta che decide se un cambiamento ha funzionato. Il machine learning è cresciuto accanto a lei, non al suo posto.

Vale la pena notare quanto questo esempio sia eterogeneo rispetto ai precedenti, eppure quanto la logica resti la stessa. Il primo esempio confrontava due modelli su un benchmark; questo confronta due prompt su utenti reali. Nell’uno il campione è fatto di domande, nell’altro di persone. In nessuno dei due il modello viene addestrato. Ma la domanda — “questa differenza osservata è segnale o rumore?” — e lo strumento per rispondere — lo standard error della differenza, la soglia dei due standard error — sono identici. È la dimostrazione operativa della tesi: la statistica della Parte V non è una teoria che vale solo per le reti neurali o solo per gli A/B test. È la grammatica comune di ogni affermazione quantitativa su un sistema AI, qualunque sia la sua forma.

Applicazioni pratiche

Leggere un leaderboard. La prima domanda davanti a una classifica di modelli non è “chi è in cima” ma “quanti esempi ha il test set”. Con $n$ e lo score si calcola lo standard error in dieci secondi. Differenze inferiori a circa due standard error vanno trattate come pareggi. Un leaderboard senza error bar ordina anche il rumore, e chi lo legge senza farsi questa domanda sta facendo overclaim per conto di altri.

Disegnare un’eval interna. Lo standard è cambiato: Evan Miller, in Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations (arXiv 2411.00640, 2024), argomenta che ogni score di valutazione di un modello va riportato con il suo intervallo di confidenza, non come numero secco con la mentalità “il più alto vince”. Concretamente: non riusare lo stesso test set per scegliere e per misurare; tenere un golden set intoccato, valutato una volta sola alla fine.

Tuning di iperparametri. Trattare ogni grid search come ciò che è — multiple testing — e validare la configurazione vincente su un fold mai toccato durante la ricerca. Il vincitore va sempre sospettato della winner’s curse: la sua performance reale è quasi sempre più bassa dello score che gli ha fatto vincere la ricerca.

Interpretare la confidenza di un modello. Prima di usare un numero di confidenza in una decisione — una soglia oltre cui l’agente agisce da solo, un costo atteso da minimizzare — verificare che il modello sia calibrato (capitolo calibrazione-statistica). Un numero di confidenza non calibrato è un numero vuoto, e costruirci sopra una decisione propaga l’errore in silenzio.

Confrontare un modello prima e dopo un cambiamento. Quando si modifica un prompt, si aggiorna un modello o si cambia un iperparametro, la domanda “è migliorato?” è un test di ipotesi, non un confronto di due numeri. Lo schema corretto: fissare in anticipo quanti esempi servono per rilevare una differenza che conti davvero (è un calcolo di potenza, capitolo test-ipotesi); valutare su un campione di quella dimensione; riportare la differenza con il suo intervallo di confidenza. Se il guadagno osservato è dentro l’incertezza, la conclusione onesta è “non distinguibile da nessun cambiamento”, non “leggero miglioramento”. Saltare questo passo è il modo più comune in cui un team si convince di star migliorando mentre sta solo inseguendo il rumore.

Stimare l’incertezza quando manca la formula. Per metriche complesse — non una semplice accuratezza ma un punteggio aggregato, una metrica di ranking, uno score calcolato da un giudice automatico — non esiste una formula chiusa per lo standard error. Qui si usa il bootstrap (capitolo bootstrap): si ricampiona il test set con reinserimento centinaia di volte, si ricalcola la metrica ogni volta, e la dispersione di quei valori è la stima dell’incertezza. È poche righe di codice, e trasforma un numero secco in un numero con error bar.

Sospettare la distanza tra test set e produzione. Prima di promettere che un modello “ha il 91% di accuratezza”, chiedersi se la popolazione su cui girerà in produzione è la stessa da cui è stato estratto il test set. Se gli utenti reali, la lingua, il dominio o il periodo differiscono, lo score di test è valido sulla popolazione di test ma non è una previsione affidabile per la produzione. Il rimedio pratico non è statistico in senso stretto: è monitorare le metriche in produzione su dati freschi, trattando lo score di test come punto di partenza da verificare, non come garanzia.

Riportare i numeri con l’incertezza, sempre. La regola che riassume tutte le precedenti: nessun numero che descrive un sistema AI va comunicato da solo. Accuratezza, F1, tasso di conversione, score di benchmark — ognuno è una stima, e ogni stima ha un intervallo. Un report che scrive “91.3%” senza margine non ha sbagliato un calcolo: ha omesso metà del risultato. Comunicare “91.3%, intervallo [89.8%, 92.6%]” costa una riga e disinnesca alla radice la classe di overclaim più comune.

Dove si rompe

La relazione fra statistica e ML è solida, ma proprio per questo è facile tirarla troppo, in una direzione o nell’altra. Questa sezione raccoglie i modi tipici in cui il ragionamento si rompe.

“Il ML ha superato la statistica.” È il mito da cui è partito il capitolo. Il ML non ha superato niente: è la cultura algoritmica che Breiman descriveva già nel 2001 come una delle due metà della statistica. È cresciuta enormemente perché dati e calcolo sono diventati abbondanti. L’altra metà — l’inferenza, l’incertezza quantificata — non è stata superata. È diventata più necessaria, perché regola i numeri che il ML produce, e quei numeri ora muovono prodotti e decisioni.

“Double descent dimostra che bias-varianza è falso.” No. Il trade-off bias-varianza resta una descrizione corretta nel regime classico, sotto la soglia di interpolazione. Il double descent mostra che quel regime era un caso particolare, non una legge universale. Confondere “circoscritto a un regime” con “falso” è un errore di classe di affermazione: la classe giusta è precisazione di scope.

“Score più alto, modello migliore.” Vero solo se la differenza tra gli score supera il rumore campionario. Senza intervalli di confidenza non si può dire se un modello è migliore o solo più fortunato su quel test set. La maggior parte delle classifiche di modelli viene letta ignorando questo, ed è la fonte più comune di overclaim quotidiano.

“L’incertezza dei logit è la confidenza del modello.” Un LLM produce, a ogni passo, una distribuzione di probabilità sul prossimo token (i logit normalizzati dalla softmax, vedi softmax e sigmoid nella Parte IV). Quella distribuzione esprime un’incertezza, ma è incertezza aleatoria — quale token verrà campionato — non incertezza epistemica — se la risposta è vera. Un’entropia bassa sui logit significa solo che il modello è deciso, non che sa. Scambiare le due incertezze è un errore statistico ricorrente nei sistemi LLM: la decisione del modello viene letta come verità del modello.

“Le allucinazioni sono un bug da patchare.” Qui la statistica dà una risposta dura. Adam Tauman Kalai e Santosh Vempala, in Calibrated Language Models Must Hallucinate (arXiv 2311.14648, presentato a STOC 2024), dimostrano un risultato sorprendente: esiste un lower bound statistico sul tasso di allucinazione. Per i fatti “arbitrari” la cui veridicità non è deducibile dai dati di training, un modello calibrato deve allucinare a un tasso vicino alla frazione di fatti che compaiono esattamente una volta nel training — una stima nota come stima di Good-Turing.

In parole povere: calibrazione e assenza totale di allucinazioni sono in tensione matematica. Non per un difetto del transformer, ma per la struttura statistica del problema. L’allucinazione non si patcha via del tutto; si gestisce, sapendo che un pavimento minimo esiste.

C’è un seguito, e sposta il problema su un terreno familiare a questa Parte. Kalai, Ofir Nachum, Vempala ed Edwin Zhang, in Why Language Models Hallucinate (arXiv 2509.04664, 2025), sostengono che gli LLM allucinano in parte perché il training e soprattutto la valutazione premiano il tirare a indovinare invece di ammettere l’incertezza. Un benchmark che assegna 0 punti a “non lo so” e 1 punto a una risposta corretta incentiva il modello a sparare sempre una risposta — è la logica dello studente che a un test a crocette tira a indovinare invece di lasciare in bianco, perché lasciare in bianco è garanzia di zero.

La proposta degli autori non è architetturale: è cambiare lo scoring dei benchmark dominanti, penalizzando gli errori sicuri più dell’incertezza e dando credito parziale all’astensione. È un problema di disegno della valutazione, cioè di statistica applicata. La modalità di fallimento più visibile degli LLM, vista da vicino, è un problema di come misuriamo — e misurare bene è il mestiere della Parte V.

“La cross-validation è un trucco da ML, non vera statistica.” La cross-validation è stima empirica dell’errore di generalizzazione: lo stesso spirito del bootstrap, simulare invece di derivare. Non è meno rigorosa delle formule analitiche; è la versione che si può permettere chi ha dati in abbondanza. Liquidarla come trucco è non aver visto che è inferenza a tutti gli effetti.

“Un modello accurato è un modello affidabile.” Accuratezza e calibrazione sono due assi distinti, e il capitolo calibrazione-statistica mostra che possono divergere: un modello molto accurato può essere sistematicamente overconfident, dichiarare 0.95 quando ha ragione l’80% delle volte. Per chi usa la confidenza del modello in una decisione — una soglia, un costo atteso, un triage — l’accuratezza media non basta: serve sapere se i numeri di confidenza sono onesti. Dedurre l’affidabilità dall’accuratezza è uno scivolamento che la statistica della calibrazione smonta con un conteggio.

“Statistica e ML sono la stessa cosa, allora basta saperne una.” È l’errore opposto a “il ML ha superato la statistica”, e questo capitolo rischia di indurlo proprio insistendo sulle equivalenze. Non è così. Le equivalenze formali — cross-entropy uguale verosimiglianza, L2 uguale MAP — sono reali ma locali: riguardano specifici punti di contatto, non l’intero territorio. Il ML ha problemi suoi (ottimizzazione su miliardi di parametri, architetture, regimi sovra-parametrizzati) che la statistica classica non tratta; la statistica ha un secolo di teoria dell’inferenza che il ML usa ma non riscrive. Saperne una sola lascia un buco: chi conosce solo il ML non sa leggere l’incertezza dei propri numeri, chi conosce solo la statistica classica non sa perché un modello sovra-parametrizzato generalizza. La posizione corretta non è “sono la stessa cosa” né “sono campi separati”, ma “sono due culture che si sovrappongono in modo sostanziale e vanno conosciute entrambe”.

“Più dati sono sempre meglio.” È un’assunzione così radicata da sembrare ovvia, e il double descent mostra che ha eccezioni. Nakkiran e colleghi documentano il sample-wise double descent: esiste una zona, vicino alla soglia di interpolazione, in cui aggiungere esempi al training set fa peggiorare l’errore di test. Il motivo intuitivo: aggiungere dati sposta la soglia di interpolazione, e per un modello di taglia fissa quello spostamento può portarlo dalla zona buona alla zona del picco.

Non è un argomento contro il raccogliere dati — su scala, più dati restano un bene — ma è la prova che “più dati, meno errore” non è una legge monotòna, è una tendenza con una buca dentro. Trattarla come legge è un altro modo di fare overclaim.

“Un test t risolve la domanda ‘A è meglio di B’.” Applicare un test statistico è necessario, ma non basta se le condizioni del test sono violate. Sui benchmark un caso ricorrente: gli esempi non sono indipendenti — domande dello stesso argomento, varianti dello stesso problema, item generati dallo stesso template — e quasi tutti i test classici assumono indipendenza.

Esempi correlati gonfiano la dimensione effettiva del campione: si crede di avere 1000 prove indipendenti quando se ne hanno, in pratica, molte meno, e lo standard error reale è più grande di quello calcolato. Il rimedio non è abbandonare i test, è usare lo schema di campionamento corretto (capitolo campionamento) e, quando la struttura è complessa, ricampionare a blocchi con il bootstrap invece di fidarsi della formula chiusa.

“Il test set garantisce che il modello generalizzerà.” Tutta l’inferenza dal campione alla popolazione poggia su un’assunzione che il capitolo campionamento rende esplicita: il campione e la popolazione sono la stessa distribuzione. Un test set garantisce qualcosa solo sulla popolazione da cui è estratto. Se in produzione gli input arrivano da una distribuzione diversa — utenti diversi, lingua diversa, periodo diverso, dati più recenti del training — lo score di test smette di essere una previsione valida.

È il problema del distribution shift, e nessuna formula statistica lo cura: la statistica quantifica l’incertezza dentro una distribuzione, non protegge dal fatto che la distribuzione cambi. Un modello con uno score di test impeccabile può fallire in produzione semplicemente perché il mondo, nel frattempo, si è mosso. Riportare lo score di test come garanzia di comportamento futuro, senza menzionare questa assunzione, è una forma di overclaim particolarmente insidiosa, perché il numero è statisticamente corretto — è l’estrapolazione a essere ingiustificata.

Il limite della sintesi stessa. Un capitolo-ponte rischia un overclaim suo proprio: presentare statistica e ML come perfettamente sovrapponibili. Non lo sono. Il ML ha sviluppato strumenti che la statistica classica non aveva — l’ottimizzazione per discesa del gradiente su milioni di parametri, le architetture profonde, il transfer learning — e affronta regimi (sovra-parametrizzazione, dati non i.i.d., distribuzioni che cambiano nel tempo) dove la teoria classica è ancora incompleta.

La tesi del capitolo non è “ML uguale statistica”. È più precisa: il ML eredita dalla statistica gli strumenti per stimare e per quantificare l’incertezza, e quando li dimentica produce overclaim. La statistica non è tutto il ML. È la parte del ML che gli impedisce di mentire sui propri numeri.

Cosa chiude, di questa Parte

Questo è l’ultimo capitolo della Parte V, e vale la pena guardare indietro a cosa la Parte ha costruito. Ogni capitolo ha preso uno strumento — un modo di estrarre un campione, una distribuzione, un teorema di convergenza, un intervallo, un test, una loss, un metodo di stima dell’incertezza — e ha mostrato, accanto alla teoria, un uso su un sistema AI. Letti di fila, quei quattordici capitoli non sono una collezione di tecniche: sono una sola disciplina vista da quattordici angoli.

La disciplina è la logica dell’inferenza: come fare affermazioni giustificate su un tutto che non si osserva, partendo da una parte che si osserva. Questo capitolo ha mostrato che il machine learning, anche nella sua forma più moderna e sovra-parametrizzata, vive interamente dentro quella logica. Un modello è uno stimatore; uno score è una stima; un benchmark è un campione; una differenza tra modelli è un’ipotesi da testare; una confidenza è una probabilità da calibrare. Cambiare i nomi non cambia la sostanza.

Resta una sola frase da portare via, ed è la tesi del titolo, ora pienamente argomentata. Il machine learning senza statistica non è un machine learning più semplice: è un machine learning che ha smesso di sapere quanto fidarsi dei propri numeri. E un sistema che non sa quanto fidarsi dei propri numeri li riporterà tutti come se fossero certi. È questa, ridotta all’osso, la radice dell’overclaim.

Collegamenti

statistica-intro — la distinzione popolazione/campione su cui poggia ogni claim di generalizzazione: il training set è un campione.
distribuzioni-comuni — Bernoulli e normale sono le distribuzioni sotto ogni score di benchmark e ogni error bar.
campionamento — un test set non rappresentativo produce uno score distorto che nessun calcolo a valle corregge.
legge dei grandi numeri e CLT — perché gli score convergono al valore vero e che forma ha l’errore mentre convergono.
stima-puntiale — i pesi di un modello sono stimatori; bias e varianza si applicano ai pesi con lo stesso significato.
intervalli-confidenza — lo strumento per attaccare un margine di incertezza a uno score, invece di riportarlo come numero secco.
test-ipotesi — la macchina per decidere se la differenza tra due modelli è reale o rumore campionario.
multiple-testing — perché ogni grid search e ogni leaderboard è un esperimento a molti test, e il vincitore soffre la winner’s curse.
correlazione-causalità — il ML predittivo vive interamente sul lato dell’associazione: prevede senza spiegare il meccanismo.
regressione-statistica — il punto fisico in cui le due culture si toccano: un neurone è una regressione logistica.
maximum-likelihood — la cross-entropy loss è la log-verosimiglianza negativa: addestrare è fare MLE.
map-bayesiano — la regolarizzazione L2 è una stima MAP con prior gaussiano: stesso calcolo, due nomi.
bootstrap — il parente empirico della cross-validation: stimare l’incertezza simulando invece di derivare.
calibrazione-statistica — la lente che verifica se le probabilità prodotte da un modello meritano di essere usate come probabilità.
bias-varianza — il trade-off classico che il double descent circoscrive a un regime invece di confutare.
Parte XVIII Machine Learning (in preparazione) — dove i metodi della cultura algoritmica di Breiman sono trattati uno per uno.
Parte XLIV Valutazione (in preparazione) — benchmark, eval e leaderboard in dettaglio, con il problema dello scoring delle allucinazioni.

Per andare oltre

Leo Breiman, Statistical Modeling: The Two Cultures, Statistical Science vol. 16 n. 3, 2001. Il manifesto delle due culture. Breve, polemico, ancora attualissimo: si legge in un’ora e cambia il modo di guardare ogni modello.
Galit Shmueli, To Explain or to Predict?, Statistical Science vol. 25 n. 3, 2010. La formalizzazione della frattura tra modellazione esplicativa e predittiva, con la dimostrazione che alto potere esplicativo non implica alto potere predittivo.
Mikhail Belkin, Daniel Hsu, Siyuan Ma, Soumik Mandal, Reconciling modern machine-learning practice and the classical bias-variance trade-off, PNAS 116(32), 2019. Il paper che mette a fuoco il double descent e ne mostra l’ubiquità.
Preetum Nakkiran et al., Deep Double Descent: Where Bigger Models and More Data Hurt, arXiv 1912.02292, 2019. Estende il fenomeno a parametri, epoche e dimensione del dataset; il blog di OpenAI ne dà una versione divulgativa.
Adam Tauman Kalai, Santosh Vempala, Calibrated Language Models Must Hallucinate, arXiv 2311.14648, STOC 2024; e il seguito Why Language Models Hallucinate (Kalai, Nachum, Vempala, Zhang, arXiv 2509.04664, 2025). Le allucinazioni degli LLM lette come fenomeno statistico, con un lower bound e una proposta sullo scoring dei benchmark.
Evan Miller, Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations, arXiv 2411.00640, 2024. La guida pratica per riportare gli score di valutazione con il loro intervallo di confidenza.