Addestrare un modello di machine learning significa mostrargli molti esempi già etichettati affinché “impari” la relazione fra i dati in ingresso (le feature) e il risultato atteso (l’etichetta, o label). Ma addestrare non basta: bisogna anche capire quanto bene il modello generalizza su dati mai visti prima. Training e valutazione sono quindi due facce dello stesso processo iterativo.

Il ciclo di training e validation

Il flusso tipico parte dividendo i dati disponibili in insiemi separati:

  • Training set: gli esempi con cui il modello impara, aggiustando i propri parametri interni per ridurre progressivamente l’errore.
  • Validation set: dati tenuti da parte, usati durante lo sviluppo per misurare le prestazioni e regolare le scelte del modello.
  • Test set: un insieme finale, toccato una sola volta, per stimare le prestazioni reali “sul campo”.

L’idea chiave è che il modello non deve mai essere valutato sugli stessi dati usati per addestrarlo. Se così fosse, avremmo solo la prova che ha memorizzato gli esempi, non che ha imparato a generalizzare. Il validation set fornisce un giudizio onesto e indipendente, permettendo di confrontare versioni diverse del modello e scegliere la migliore.

In Azure Machine Learning questo ciclo è automatizzato: funzionalità come l’automated machine learning (AutoML) provano molte configurazioni, le valutano su dati di validazione e propongono il modello con il punteggio migliore.

Le metriche di valutazione

La metrica giusta dipende dal tipo di problema.

Classification

Quando il modello prevede una categoria (es. “spam / non spam”, “gatto / cane”), la metrica più intuitiva è l’accuracy: la percentuale di previsioni corrette sul totale.

Attenzione però: con classi sbilanciate l’accuracy può ingannare. Se il 99% delle email non è spam, un modello che dice sempre “non spam” ha il 99% di accuracy ma è inutile. Per questo si usano anche:

  • Precision: fra i casi previsti come positivi, quanti lo erano davvero.
  • Recall: fra i casi realmente positivi, quanti ne ha individuati il modello.

Regression

Quando il modello prevede un valore numerico continuo (es. il prezzo di una casa, la temperatura di domani), non ha senso parlare di “giusto o sbagliato”: interessa quanto ci si avvicina. Si misura quindi un errore medio fra valore previsto e valore reale, ad esempio il Mean Absolute Error (MAE) o il Root Mean Squared Error (RMSE). Più l’errore è basso, migliore è il modello.

Overfitting e underfitting

Due problemi opposti minacciano la capacità di generalizzare.

  • Overfitting (sovradattamento): il modello impara “troppo bene” il training set, memorizzando anche il rumore e i dettagli irrilevanti. Risultato: ottimo sul training, scarso sui dati nuovi. È come uno studente che impara le risposte a memoria ma va in crisi con domande riformulate.
  • Underfitting (sottoadattamento): il modello è troppo semplice per cogliere gli schemi presenti nei dati. Risultato: prestazioni deboli ovunque, sia in training sia in validation.

Il segnale rivelatore dell’overfitting è proprio il divario fra la performance sul training (molto alta) e quella sul validation (molto più bassa). Ecco perché un validation set separato è indispensabile: senza di esso l’overfitting resterebbe invisibile. L’obiettivo è il giusto equilibrio, con buone prestazioni su entrambi gli insiemi.

Trappole tipiche d’esame

  • Scenario: valuti un modello che riconosce numeri di carte fraudolente (“frode / non frode”) e vuoi sapere quante previsioni sono corrette → risposta giusta: usi una metrica di classification come l’accuracy (con classi sbilanciate, guarda anche precision e recall), non un errore medio.
  • Scenario: prevedi il prezzo futuro di un immobile, un valore continuo → risposta giusta: è un problema di regression, valutato con un errore medio (MAE/RMSE), non con l’accuracy.
  • Scenario: il modello raggiunge il 99% sul training ma solo il 60% sui dati nuovi → risposta giusta: è overfitting; serve un validation set separato per rilevarlo e correggerlo.
  • Scenario: il modello ha prestazioni scarse sia in training sia in validation → risposta giusta: è underfitting, il modello è troppo semplice per i dati.
  • Scenario: devi confrontare più modelli e scegliere il migliore senza “barare” → risposta giusta: valuti su dati non usati per il training (validation/test set), mai sugli stessi dati di addestramento.