Overfitting: come riconoscerlo ed evitarlo (esempio numerico)

C’è un momento preciso in cui un progetto di machine learning inizia ad andare male, ed è quasi sempre lo stesso: il modello raggiunge un’accuratezza altissima sui dati con cui è stato addestrato, il team esulta, e poi in produzione i numeri crollano. Quel momento ha un nome tecnico, overfitting, e una traduzione italiana che si usa poco ma è più chiara dell’originale: sovradattamento. Il modello non ha imparato la regola, ha imparato i suoi appunti.

Questo articolo non si ferma alla definizione. La parte centrale è un esempio numerico svolto: lo stesso identico dataset, tre modelli di complessità diversa, e i valori di errore che dicono esattamente dove sta il punto in cui l’apprendimento si trasforma in memorizzazione. Sono numeri riproducibili, non illustrativi. Da lì si capisce perché le contromisure funzionano, e perché una sola metrica non basta mai a dirti se un modello è buono.

In questo articolo scoprirai:

• Che cos’è l’overfitting e perché non te ne accorgi guardando l’accuratezza
• L’esempio numerico: un dataset, tre modelli, i numeri che divergono
• Overfitting e underfitting: la differenza, e perché sono lo stesso problema visto da due lati
• Come riconoscere l’overfitting: leggere le curve di apprendimento
• Cosa causa davvero l’overfitting
• Le contromisure che funzionano: regolarizzazione, dropout, early stopping
• Più dati e validazione onesta: quanto contano davvero, e come si suddividono i dati
• L’overfitting negli LLM: la contaminazione dei benchmark e perché i punteggi pubblici ingannano

Che cos’è l’overfitting e perché non te ne accorgi guardando l’accuratezza

Il problema dell’overfitting nel machine learning è che si presenta travestito da successo. Un modello sovradattato ha, per definizione, prestazioni eccellenti sui dati di addestramento: è lì che ha memorizzato tutto. La documentazione di Google per il Machine Learning Crash Course lo descrive come un modello che «memorizza il training set così strettamente da non riuscire a fare previsioni corrette su dati nuovi», e usa un’analogia efficace: un’invenzione che funziona in laboratorio ma è inutile nel mondo reale.

La definizione formale è più severa e più utile. Goodfellow, Bengio e Courville, nel Deep Learning Book, impostano la questione sul rapporto tra capacità del modello e generalizzazione: quando la capacità eccede quella richiesta dal fenomeno e dalla quantità di dati disponibili, il modello si adatta a proprietà del training set che non si ripeteranno, e il divario tra errore di addestramento ed errore su dati nuovi si allarga. La voce di Wikipedia dedicata all’overfitting lo riassume nella stessa direzione: un modello sovradattato «contiene più parametri di quanti i dati possano giustificare», ed estrae «la variazione residua, il rumore, come se fosse struttura del fenomeno». È questa la distinzione che conta: ogni dataset reale contiene due cose sovrapposte, un segnale sistematico che si ripeterà anche domani e delle fluttuazioni casuali che non si ripeteranno mai. Un modello troppo flessibile non ha modo di distinguerle, e le impara entrambe con lo stesso zelo.

Overfitting: quando i parametri superano le osservazioni

Il caso limite è illuminante: quando il numero di parametri eguaglia o supera il numero di osservazioni, un modello può prevedere perfettamente i dati di addestramento semplicemente memorizzandoli per intero, salvo poi fallire clamorosamente su qualsiasi previsione. Accuratezza del 100% sul training set, quindi, non è un risultato: è un sintomo. Ed è il motivo per cui nessuna valutazione seria si fa sui dati con cui si è addestrato, un errore metodologico che sta a monte di parecchi progetti AI che falliscono prima di arrivare in produzione.

L’esempio numerico: un dataset, tre modelli, i numeri che divergono

Qui sta il cuore dell’articolo. L’esempio è quello canonico della documentazione scikit-learn su underfitting e overfitting, e ha il pregio di essere interamente riproducibile in venti righe di codice.

Il setup: una funzione vera nota, cos(1,5 · π · x), da cui si estraggono 30 campioni nell’intervallo da 0 a 1, ai quali si aggiunge rumore gaussiano di ampiezza 0,1. Su questi trenta punti si addestrano tre regressioni polinomiali di grado 1, 4 e 15. La valutazione non si fa sugli stessi punti: si usa una cross-validation a 10 fold, cioè si addestra dieci volte tenendo ogni volta una fetta diversa fuori dall’addestramento e misurando l’errore quadratico medio su quella fetta mai vista.

Leggiamoli. Il polinomio di grado 1 è una retta: non ha la flessibilità per seguire una cosinusoide, sbaglia sui dati di addestramento e sbaglia su quelli nuovi allo stesso modo. Il grado 4 aderisce alla forma vera e commette un errore di validazione quasi dieci volte inferiore. Il grado 15 peggiora: 0,220 contro 0,043, cioè un errore cinque volte più alto di quello del grado 4, il migliore dei tre, pur essendo, sulla carta, il modello più potente.

Overfitting in tabella: dove training e validazione divergono

Il punto decisivo è cosa succede intanto sul training set. Il polinomio di grado 15 ha abbastanza gradi di libertà da passare vicinissimo a ciascuno dei trenta punti, rumore incluso: il suo errore di addestramento è per costruzione il più basso dei tre, anche se l’esempio riporta solo l’errore in validazione. È esattamente la divergenza che definisce l’overfitting, errore di addestramento che continua a scendere mentre l’errore di validazione risale. Se avessimo guardato solo la prima delle due curve, avremmo scelto il modello peggiore convinti di scegliere il migliore.

La varianza del modello sovradattato

Un dettaglio spesso ignorato: guardate la deviazione standard. Il grado 4 ha 0,071, il grado 15 ha 0,420. Il modello sovradattato non è solo più impreciso, è instabile: cambia risposta a seconda di quale fetta di dati gli capita. Alta varianza, in gergo. Ed è il ponte verso la sezione successiva.

Overfitting e underfitting: la differenza, e perché sono lo stesso problema visto da due lati

Underfitting e overfitting sembrano due difetti opposti, e in un certo senso lo sono: il primo è un modello troppo semplice per il fenomeno, il secondo un modello troppo flessibile per la quantità di dati disponibili. L’underfitting, si legge sempre nella definizione formale, è caratterizzato da alto bias e bassa varianza, l’esatto inverso del sovradattamento.

Bias e varianza: le due facce dell’overfitting

Ma è più utile vederli come i due estremi di un’unica manopola. Il capitolo di riferimento su metodi predittivi del NCBI Bookshelf scompone l’errore di previsione in tre pezzi: una varianza irriducibile (il rumore intrinseco, che nessun modello eliminerà mai), il bias (quanto la previsione media si discosta sistematicamente dal vero) e la varianza della stima (quanto le previsioni ballano se cambi il campione di addestramento). La modellazione predittiva, scrivono, «cerca di minimizzare la combinazione di bias e varianza», accettando talvolta di sacrificare accuratezza teorica in cambio di precisione empirica.

È il bias-variance tradeoff, e nell’esempio numerico lo abbiamo appena letto in tabella. Il grado 1 è tutto bias: sbaglia sempre nello stesso modo, ma sbaglia poco diversamente da un campione all’altro (0,425 di deviazione standard su un errore medio di 0,408, cioè un errore già alto di per sé). Il grado 15 è tutta varianza: potrebbe in linea di principio approssimare la funzione vera, ma il suo comportamento dipende dal rumore che gli è capitato. Il grado 4 sta nel punto in cui la somma dei due è minima.

Complessità del modello e dati disponibili

La conseguenza pratica è che non esiste un modello «più potente» in assoluto: esiste un modello adeguato alla quantità e alla qualità dei dati che hai. Aumentare la complessità senza aumentare i dati non compra prestazioni, compra varianza. È un principio che vale identico quando si sceglie fra architetture diverse, come nel confronto tra RAG e fine-tuning per casi d’uso enterprise: la domanda giusta non è quale tecnica sia superiore, ma quale regga con i dati che hai davvero.

Come riconoscere l’overfitting: leggere le curve di apprendimento

La diagnosi non si fa a occhio sul risultato finale, si fa guardando due curve nel tempo: l’errore sul training set e l’errore sul validation set, epoca dopo epoca. Google chiama il grafico generalization curve e ne dà il criterio più conciso che esista: c’è overfitting quando la perdita sul training set continua a scendere o resta stabile mentre quella sul validation set sale.

La lettura completa delle learning curve come strumento diagnostico distingue tre forme riconoscibili a colpo d’occhio. Nell’underfitting la curva di training è piatta su valori di errore alti, oppure sta ancora scendendo quando l’addestramento finisce: il modello non ha capacità sufficiente, o non ha finito di imparare. Nell’overfitting la curva di validazione ha la forma a U, scende, tocca un minimo, poi risale, mentre quella di training prosegue imperterrita verso il basso. Nel caso sano entrambe scendono e si stabilizzano, con un gap di generalizzazione piccolo e costante fra le due.

Il gap fra training e validation: quando preoccuparsi

Un divario esiste sempre e non è patologico di per sé. Diventa un segnale quando cresce nel tempo invece di stabilizzarsi, e quando la curva di validazione inverte la direzione. Il minimo di quella curva a U, non l’ultima epoca, è il punto in cui il modello andava fermato, ed è precisamente l’osservazione su cui si fonda l’early stopping.

C’è un presupposto che rende valida tutta questa lettura, e che Google elenca esplicitamente: gli esempi devono essere indipendenti e identicamente distribuiti, il fenomeno stazionario, e le partizioni di training, validation e test devono provenire dalla stessa distribuzione. Se il validation set è più facile del training set, o se le due partizioni sono state costruite con criteri diversi, le curve raccontano una favola.

Cosa causa davvero l’overfitting

Le cause si riducono a un rapporto sbilanciato tra quanto il modello può memorizzare e quanto i dati hanno da dire. La documentazione AWS sull’overfitting ne elenca quattro ricorrenti: un training set troppo piccolo, dati rumorosi, un modello che memorizza anziché estrarre pattern, ed eccessiva complessità del modello. Sono in realtà quattro facce dello stesso squilibrio.

Overfitting e dati di training: la quantità non è tutto

Pochi dati sono la causa più comune e la più fraintesa. Con trenta punti, come nell’esempio, un polinomio di grado 15 ha praticamente abbastanza libertà da inseguirli uno per uno. Ma il problema non è solo il numero: è la copertura. Diecimila esempi tutti simili tra loro informano il modello meno di mille esempi che coprono la varietà reale dei casi. Quando le rappresentazioni numeriche dei dati sono ad alta dimensionalità, è il caso degli embeddings, il meccanismo su cui poggiano i sistemi RAG, la questione della copertura diventa dominante, perché lo spazio da riempire cresce esponenzialmente con le dimensioni.

Overfitting nelle reti neurali: capacità e rumore

Le reti profonde sono il caso estremo perché hanno una capacità enorme e nessun freno intrinseco. Con milioni di parametri e un dataset finito, la strada di minor resistenza per ridurre la loss è memorizzare. Il fatto che le operazioni sottostanti siano moltiplicazioni di matrici, la sostanza dell’algebra lineare applicata a machine learning e deep learning, rende la cosa più concreta: aggiungere strati significa aggiungere gradi di libertà, e ogni grado di libertà non vincolato è spazio in cui il rumore può insediarsi.

Va aggiunta una causa che nessuna lista canonica menziona abbastanza: il data leakage. Se un’informazione che in produzione non sarà disponibile filtra nelle feature di addestramento, un identificativo correlato all’esito, una normalizzazione calcolata su tutto il dataset prima dello split, il modello impara una scorciatoia che sparirà. Le metriche saranno ottime e completamente false, e a differenza dell’overfitting classico questo non si vede nelle curve.

Come evitare l’overfitting: regolarizzazione, dropout, early stopping

La definizione più pulita di regolarizzazione la danno Goodfellow, Bengio e Courville nel capitolo dedicato del Deep Learning Book: «qualsiasi modifica a un algoritmo di apprendimento intesa a ridurre l’errore di generalizzazione ma non quello di addestramento». La formulazione dice tutto: una tecnica di regolarizzazione, se funziona, peggiora deliberatamente le prestazioni sul training set. Chi si lamenta perché «da quando ho aggiunto la regolarizzazione l’accuratezza in training è scesa» ha ottenuto esattamente ciò che ha chiesto.

Regolarizzazione L2 e weight decay

La L2 aggiunge alla funzione obiettivo una penalità proporzionale al quadrato dei pesi, spingendoli verso lo zero a ogni passo di addestramento. L’effetto matematico, spiegano gli autori, è che i pesi vengono preservati lungo le direzioni in cui i dati portano informazione forte e ridimensionati lungo quelle in cui l’informazione è debole. In pratica: il modello mantiene la flessibilità dove serve e la perde dove serviva solo a inseguire il rumore.

Dropout: i numeri dell’esperimento originale

Il dropout spegne casualmente una frazione di neuroni a ogni passo di addestramento, impedendo che si specializzino in coppia su artefatti del training set. Il paper originale di Srivastava e colleghi (JMLR, 2014) raccomanda di mantenere attivo il 50% delle unità nascoste e l’80% degli input, e riporta il risultato che ha reso la tecnica standard: su MNIST l’errore di test scende da circa 1,6% a circa 0,94%, quasi dimezzato senza toccare l’architettura né aggiungere un solo esempio.

Early stopping

È la contromisura più economica e la più diretta conseguenza della curva a U: si monitora l’errore di validazione e si interrompe l’addestramento al suo minimo, prima che risalga. AWS la descrive come «mettere in pausa l’addestramento prima che il modello impari il rumore». Non costa un parametro in più, non richiede dati aggiuntivi, e va usata praticamente sempre, a patto di conservare i pesi del punto di minimo, non quelli dell’ultima epoca.

Più dati e validazione onesta: cosa fare quando la regolarizzazione non basta

Più dati aiutano, ma non sono un rimedio universale e non sono sempre disponibili. La data augmentation è il compromesso: si espande artificialmente il training set con trasformazioni che non cambiano l’etichetta. Funziona benissimo sulle immagini, traslazioni, rotazioni, cambi di scala, con un’avvertenza che il Deep Learning Book sottolinea e che è facile violare: mai applicare trasformazioni che cambiano la classe, come ribaltare orizzontalmente un carattere in un compito di riconoscimento testuale, dove una “b” diventa una “d”.

La leva più sottovalutata, però, non è avere più dati: è valutare in modo onesto quelli che si hanno. Il riferimento NCBI raccomanda una k-fold cross-validation con 5 o 10 fold come pratica standard, preferita al leave-one-out perché più stabile, e suggerisce di ripeterla su partizioni diverse. Per dataset ampi, oltre le 50.000 osservazioni, indica suddivisioni tipiche del 50% training / 25% validation / 25% test, oppure 70/15/15.

La regola implicita in tutte queste cifre è una sola: il test set si tocca una volta sola, alla fine. Se lo si guarda ripetutamente per scegliere iperparametri, smette di essere un test set e diventa un secondo validation set, e l’overfitting si sposta silenziosamente lì, un livello più su. È il motivo per cui esistono tre partizioni e non due, ed è la differenza tra un modello che regge e uno che va rimesso in discussione appena arriva in produzione, dove ottimizzare l’inferenza presuppone che il modello sia già affidabile.

L’overfitting nell’era degli LLM: la contaminazione dei benchmark

Chi lavora con i modelli linguistici tende a considerare l’overfitting un problema del machine learning classico, superato dalla scala. È vero il contrario: cambia forma e diventa più difficile da vedere. La versione moderna si chiama data contamination, e la survey del 2025 sui benchmark LLM sotto contaminazione la definisce come la sovrapposizione impropria tra dati di addestramento e dati di valutazione, nella forma esatta, quando lo stesso esempio compare in entrambi, o sintattica, quando ricompare dopo normalizzazioni della punteggiatura, modifiche di spaziatura o sostituzioni di sinonimi.

Contaminazione dei benchmark: i numeri dell’inflazione

È overfitting nella sostanza: il modello risponde bene perché ha già visto la risposta, non perché sappia generalizzare. E l’entità dell’inflazione è misurabile. L’esperimento riportato nella survey mostra che su HumanEval, un benchmark statico, l’accuratezza di Llama-3.2-3B passa da 0,28 a 0,87 in presenza di contaminazione totale; con un benchmark generato dinamicamente lo stesso modello resta invece nell’intorno del suo valore reale. Un salto di prestazioni che non corrisponde a nessun aumento di capacità.

Valutare un modello sull’overfitting: il test sui propri dati

Le implicazioni pratiche sono due. La prima: i punteggi di benchmark pubblici non sono una garanzia di prestazioni sui vostri dati, e vanno letti come indizio, non come misura, vale per le classifiche dei modelli generalisti come per quelli ottenuti per distillazione da modelli più grandi. La seconda, più operativa: se state valutando quale modello adottare, l’unico test che conta è quello costruito sui vostri casi reali, con esempi che nessun modello può aver visto durante l’addestramento. Un set di cinquanta casi presi dal vostro dominio, valutati a mano, dice più di qualunque leaderboard, e vale per la scelta di un large language model come per qualsiasi altro componente.

È lo stesso principio dell’esempio numerico da cui siamo partiti, applicato tre ordini di grandezza più su: l’unico dato che ti dice come andrà domani è quello che il modello non ha mai visto.

Imparare troppo bene i casi visti è un incidente che riguarda l’addestramento, che è a sua volta un pezzo di una storia più grande: come funziona davvero un modello di AI, dall’ingresso del testo alla risposta.

Fonti:

• Google per il Machine Learning Crash Course
• scikit-learn su underfitting e overfitting
• metodi predittivi del NCBI Bookshelf
• learning curve come strumento diagnostico
• AWS sull’overfitting
• capitolo dedicato del Deep Learning Book
• paper originale di Srivastava e colleghi (JMLR, 2014)
• survey del 2025 sui benchmark LLM sotto contaminazione