MLOps: Machine Learning Operations

L'applicazione dei principi DevOps nei sistemi ML consente di realizzare e gestire soluzioni su larga scala in modo affidabile ed efficiente

Contesto

Nonostante la forte diffusione negli ultimi anni di modelli basati su algoritmi di Machine Learning, solo in parte le aziende sono state in grado di portare in produzione soluzioni basate su questo tipo di tecnologia ottenendo un buon ritorno sull'investimento.

Machine Learning Operations (MLOps) nasce con l'obiettivo di colmare le carenze legate all'integrazione e al mantenimento di questi sistemi all'interno delle architetture software aziendali, basandosi sui principi DevOps per facilitare il processo di sviluppo, gestione e mantenimento di questi strumenti.

MLOps vs DevOps

DevOps è una metodologia di sviluppo del software basata sui principi di Continuous Integration e Continuous Delivery. La sua finalità è di rendere più efficiente e veloce lo sviluppo effettuando cicli frequenti di testing, integrazione e rilascio.
Queste pratiche risultano necessarie ma non sufficienti per lo sviluppo di un software basato su algoritmi di Machine Learning, per i seguenti motivi:

  • Continuous Integration non riguarda solamente i componenti software, ma anche i dati e il modello;

  • Continuous Delivery non riguarda più un solo pacchetto software o servizio, ma anche l’intera pipeline di addestramento del modello;

  • un modello necessita di essere riaddestrato nel tempo.

E’ necessario, quindi, introdurre la nozione di Continuous Training, il cui significato è di automatizzare il riaddestramento del modello e la distribuzione del nuovo servizio di predizione.

Il nostro approccio MLOps

Sulla base delle esperienze progettuali maturate negli ultimi anni e della letteratura scientifica, abbiamo affinato il nostro approccio MLOps, riassunto nei seguenti punti chiave.

Ogni fase dello sviluppo e industrializzazione di un modello deve essere riproducibile. In fase di sviluppo vengono effettuati diversi esperimenti, che possono variare tra loro sia per l’architettura del modello utilizzata che per la sorgente dati ed il suo processamento. Per riprodurre i risultati ottenuti durante questo processo iterativo, tracciare la configurazione del modello non è sufficiente. Occorre predisporre anche il versionamento dei dati.

Applicazione in un caso reale
Nell'ambito di una serie di attività volte a ridurre il tasso di churn dei servizi offerti da un nostro cliente, abbiamo realizzato un modello in grado di predirre coloro che avrebbero disdetto il loro contratto a distanza di un mese. Dopo aver effettuato un riaddestramento del modello, avevamo notato un forte calo nelle performance. Per capire l’origine del problema, abbiamo deciso di confrontare le versioni dei set di dati utilizzate per addestrare le ultime due versioni del modello. Durante l’analisi abbiamo scoperto che alcune feature numeriche contenevano dei valori di testo, e che il problema era sorto a valle di una modifica apportata alla fase di preparazione del dato.

A valle dell’industrializzazione, sia per dei conflitti nati durante il rilascio di un componente che per motivi di performance, può sorgere l’esigenza di ridistribuire una versione precedente del modello. Per farlo, è importante avere a disposizione anche le informazioni riguardanti le versioni dei componenti della pipeline utilizzate con la versione precedente del modello, e le metriche utilizzate per valutarne le performance. Per assicurare la mantenibilità e resilienza del software, è necessario quindi predisporre un versionamento sia dell’immagine del modello, che dei suoi metadati.

Applicazione in un caso reale
Nel corso di una delle nostre progettualità abbiamo distribuito in produzione una nuova versione di un modello in grado di classificare i clienti di un sito web in base ai loro comportamenti sul sito. Un giorno questo nuovo modello ha iniziato a classificare tutti i clienti come “principianti”, ovvero clienti con una bassa dimestichezza nello svolgere le proprie attività sul sito web. Durante una fase di analisi abbiamo deciso di ridistribuire in produzione la versione precedente del modello poichè restituiva dati meno anomali della nuova versione. Dopo averne analizzato i risultati, abbiamo notato che anche le performance della versione precedente risultavano anomale. Confrontare le due versioni del modello ha reso possibile identificare che l’origine del problema risiedeva in una sorgente dati malfunzionante. La sorgente conteneva il comportamento dell’utente durante l’utilizzo di una feature avanzata del sito. Poichè questa feature avanzata risultava non utilizzata da tutti i clienti, il modello falliva nel classificare i clienti in maniera appropriata.

La relazione tra le varie entità e fenomeni presenti in natura è in continuo cambiamento. Le proprietà dei dati utilizzati dal modello industrializzato cambia nel tempo, degradandone le performance. Infatti è importante ricordare che un modello garantisce le performance ottenute in fase di sviluppo solamente se i dati a sua disposizione appartengono alla stessa distribuzione di dati osservata durante il suo addestramento. Monitorando il modello diventa possibile osservare un cambiamento nelle performance e, se necessario, innescare un nuovo ciclo di addestramento. Questo è fondamentale per garantire l’affidabilità dei risultati nel tempo.

Applicazione in un caso reale
Uno dei nostri clienti aveva sviluppato un algoritmo in grado di predirre gli acquisti dei propri clienti in base al loro comportamento sulla loro piattaforma e-commerce. Al momento del passaggio in produzione del modello avevano osservato delle performance basse e non riuscivano a comprenderne il motivo. Analizzando le performance in base all’ora del giorno, abbiamo notato che il modello aveva una elevata accuratezza solamente in un determinato arco della giornata. Dopo aver analizzato il set di dati utilizzato per l’addestramento, abbiamo scoperto che il modello era stato addestrato utilizzando dati che rappresentavano il comportamento dell’utente solamente in quel periodo in cui il modello restituiva risultati soddisfacenti. Effettuando un riaddestramento con un set di dati rappresentativo del comportamento dell’utente lungo l’arco dell’intera giornata è stato possibile aumentare le performance del modello considerevolmente. Questo esempio mostra l’importanza di predisporre un monitoraggio approfondito delle performance del modello.

MLOps con Google Cloud


Google Cloud offre una gamma di servizi in grado di soddisfare le varie esigenze che possono presentarsi durante il ciclo di sviluppo e distribuzione di un prodotto in Cloud. Come Google Cloud Partner certificato, il nostro team consiglia i seguenti servizi per l’implementazione dei principi chiave sopra menzionati.

BigQuery per il versionamento dei dati. BigQuery è un data warehouse ottimizzato per l’archiviazione ed analisi (tramite linguaggio SQL) di set di dati di grandi dimensioni. Le tabelle al suo interno possono essere partizionate in base alla data di inserimento nel database. Le partizioni vengono memorizzate e trattate come singole tabelle, ottimizzando il costo e la velocità di esecuzione delle query eseguite sulle singole partizioni. Questo servizio si posiziona come strumento ideale per il versionamento dei dati utilizzati per l’addestramento del modello, composti da una grossa quantità di dati su cui è necessario poter eseguire delle analisi all’occorrenza.

  • Cloud Storage come registro delle versioni del modello. Il servizio offre un sistema di archiviazione di oggetti con diverse possibilità di personalizzazione. In particolare, è possibile selezionare tra diverse classi di archiviazione in base alla frequenza di accesso desiderata, ed ottimizzare i costi di gestione.

  • Cloud SQL come registro dei metadati del modello. Cloud SQL è un servizio completamente gestito per database relazionali che garantisce scalabilità e disponibilità elevata. Inoltre si integra bene con altri servizi quali Google Kubernetes Engine, Compute Engine ed App Engine. Rappresenta un ottimo backend ad alte prestazioni per contenere i metadati del modello quali metriche utilizzate per valutarne le performance e le versioni dei componenti utilizzate in produzione.

  • TensorFlow Model Analysis per monitorare le performance del modello. TFMA è uno dei componenti di TensorFlow Extended, la piattaforma Google indicata per l’impiego di modelli di machine learning su scala di produzione. In particolare, TFMA consente di calcolare e visualizzare le metriche di valutazione per i propri modelli. Questo aiuta a valutare le prestazioni del modello per garantire che soddisfi determinate soglie di qualità e si comporti come previsto per i dati rilevanti.

  • Kubeflow Pipelines come orchestratore della catena di sviluppo e distribuzione del modello. Kubeflow Pipelines è un componente di Kubeflow, il progetto open source di Google volto a semplificare l’impacchettamento e il riutilizzo delle pipeline ML. Consente di gestire i componenti sviluppati con le librerie di TensorFlow Extended. In aggiunta, fornisce una interfaccia utente utile per tenere traccia sia degli esperimenti in fase di sviluppo che delle varie esecuzioni del servizio di predizione in produzione.