Un modello che funziona sul dataset di test e un modello che funziona in esercizio sono due oggetti diversi, e la differenza non è l’accuratezza. L’errore di classificazione misurato su un insieme di validazione descrive come si comporta il modello su dati raccolti nel passato; il sistema in produzione riceve dati di adesso, prodotti da un processo che cambia mentre il modello resta fermo. Tutto quello che separa i due regimi — serializzazione, latenza di scoring, monitoraggio, riaddestramento, tracciabilità delle decisioni — è lavoro di ingegneria e di processo che non compare su nessuna curva ROC.

Contesto

Negli ultimi anni costruire un modello è diventato alla portata di tutti. scikit-learn, descritto da Pedregosa et al. nel lavoro uscito su JMLR, mette gli stimatori supervisionati e non supervisionati dietro un’unica interfaccia fit/predict, sopra NumPy e SciPy, con licenza BSD. Apache Mahout porta clustering, classificazione e filtraggio collaborativo su Hadoop, in batch MapReduce. Vowpal Wabbit, nato a Yahoo! Research, addestra modelli lineari online su flussi che non stanno in memoria. La barriera all’addestramento si è abbassata; quella all’esercizio no.

Molte organizzazioni hanno oggi un modello addestrato — dentro una sessione R, uno script Python, un job Mahout — e nessun percorso definito per portarlo nel sistema che prende le decisioni. Il modello vive nel notebook di chi l’ha scritto. Il problema non è ricostruirlo una seconda volta: è farne un componente di cui qualcuno risponde.

Dal notebook al servizio

Il primo ostacolo è banale e costoso: il modello va serializzato e ricaricato altrove. In Python di solito si usa pickle, che salva lo stato dell’oggetto stimatore. Funziona finché le versioni di scikit-learn, NumPy e dell’interprete in produzione coincidono con quelle di addestramento; un pickle prodotto con una versione e deserializzato con un’altra si può rompere in silenzio, restituendo un oggetto che predice senza sollevare errori. La versione delle librerie diventa così parte della definizione del modello, non un dettaglio d’ambiente.

L’alternativa indipendente dal linguaggio esiste da tempo: PMML (Predictive Model Markup Language), lo standard XML del Data Mining Group, alla versione 4.0 dal 2009. Un albero di decisione o un modello di regressione esportato in PMML si può caricare in un motore di scoring scritto in un linguaggio diverso da quello dell’addestramento. PMML copre una parte dei modelli più comuni, non tutti, e la fedeltà dell’export dipende dall’implementazione; resta comunque l’unico modo per disaccoppiare il formato del modello dal runtime di chi l’ha addestrato.

Il secondo ostacolo è la differenza tra scoring batch e scoring online. Un modello che ricalcola le raccomandazioni una volta al giorno su Hadoop è un job che legge un input e scrive un output: lo schedula cron, lo si tratta come qualsiasi pipeline ETL. Un modello che deve rispondere dentro una richiesta HTTP è un servizio con un budget di latenza, che carica i parametri in memoria all’avvio e li tiene caldi. Sono due architetture diverse, e la scelta condiziona il formato di serializzazione, il dimensionamento e il monitoraggio.

I dati cambiano, il modello no

Un classificatore addestrato è una funzione fissa. La distribuzione dei dati su cui lavora non lo è. Il fenomeno ha un nome consolidato — concept drift — e una letteratura altrettanto: Widmer e Kubat lo descrivono già nel 1996, Tsymbal ne fa una rassegna nel 2004. La relazione statistica tra le variabili in ingresso e l’esito da prevedere si sposta nel tempo, per ragioni esterne al modello: stagionalità, il cambio di una sorgente dati a monte, il comportamento di chi genera i dati che si modifica, perfino il fatto che il modello agisca e alteri il processo che osserva.

L’accuratezza misurata in validazione non dice nulla su quando tutto questo succederà. Dice solo come si comportava il modello sui dati del passato. In produzione un modello può degradare lentamente per settimane senza che si sollevi nessun errore: continua a restituire una classe, una probabilità, un punteggio, e quei valori sono semplicemente sempre più sbagliati. Il guasto silenzioso è il modo tipico in cui un modello in esercizio smette di funzionare.

Ne discende una conseguenza operativa precisa: un modello in produzione va monitorato sulla qualità delle predizioni, non solo sulla disponibilità del servizio. Controllare che l’endpoint risponda con un 200 sotto i 50 ms non dice nulla sulla correttezza di quello che risponde. Servono metriche sulla distribuzione degli input — il confronto tra la distribuzione di addestramento e quella corrente — e, dove l’esito reale si conosce a posteriori, una misura continua dell’errore sul campo. Quest’ultima spesso arriva tardi: in un modello di churn l’etichetta vera si sa settimane dopo la predizione, e fino ad allora si lavora solo su segnali indiretti.

Implicazioni di governance

Quando un modello prende o suggerisce decisioni che riguardano le persone — un punteggio di rischio, una priorità, una classificazione — la domanda non è più solo se sia accurato, ma chi risponde di una decisione sbagliata e con quali dati il modello era stato addestrato. Questo richiede tracciabilità: per ogni versione del modello in esercizio, sapere su quale dataset l’hanno addestrata, con quali parametri, chi l’ha fatto e da quando è attiva. È versionamento applicato a un artefatto che non è codice e non è dato, ma dipende da entrambi.

La riproducibilità è il prerequisito tecnico di questa tracciabilità. Un modello è riproducibile se, dato lo stesso dataset, lo stesso codice e gli stessi parametri — incluso il seme dei generatori pseudo-casuali — produce gli stessi pesi. Senza fissare il seme, due addestramenti sullo stesso input danno modelli diversi, e diventa impossibile dire se una differenza di comportamento in produzione venga da un cambiamento dei dati o dal caso. Fissare i semi e annotare le versioni delle librerie è il minimo perché un modello sia un oggetto che si possa interrogare a posteriori.

Limiti

Niente di tutto questo dipende dall’algoritmo. Un albero di decisione e una macchina a vettori di supporto hanno lo stesso problema di serializzazione, la stessa deriva, lo stesso bisogno di monitoraggio. L’apprendimento incrementale — i modelli online di Vowpal Wabbit, per dirne uno — abbassa il costo del riaddestramento perché aggiorna i pesi a ogni esempio, ma non elimina il bisogno di misurare se l’aggiornamento va nella direzione giusta: un modello online insegue il rumore con la stessa facilità con cui insegue un segnale.

E resta il limite della retroazione lenta. Quando l’esito vero di una predizione si conosce solo a distanza di tempo, qualunque schema di monitoraggio che parta dall’errore reale è strutturalmente in ritardo rispetto al degrado. Si possono usare segnali indiretti — la deriva della distribuzione degli input — ma sono un’approssimazione, e un modello può degradare anche a input stabili se cambia ciò che lega input ed esito. Su questo la letteratura sul concept drift è chiara da oltre un decennio: il problema è noto, le soluzioni complete no.

Su come questi vincoli si traducono nel passaggio dei modelli dalla sperimentazione all’esercizio si veda l’insight di noze sul tema: https://www.noze.it/insights/machine-learning-produzione/.

Immagine di copertina: Diagramma di overfitting: due gruppi di punti colorati separati da una linea molto frastagliata che li divide alla perfezione,… — diagramma di Chabacano, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:Overfitting.svg