Colmare il divario tra sviluppo e produzione di Machine Learning

Nel campo dell’Intelligenza Artificiale, il Machine Learning è emerso come una forza trasformativa, che consente alle aziende di sbloccare la potenza dei dati e prendere decisioni informate. Tuttavia, colmare il divario tra lo sviluppo di modelli di ML e la loro implementazione in ambienti di produzione può rappresentare una sfida da affrontare con attenzione. 

In questa intervista con Alessandro Conflitti (Head of Data Science di Radicalbit, una consociata di Bitrock), esploriamo il mondo dell’MLOps, approfondendone il significato, le sfide e le strategie per un’implementazione di successo. 

Tuffiamoci subito nella prima domanda.

Che cos’è l’MLOps e perché è importante?

MLOps è l’acronimo di “Machine Learning Operations“. Descrive un insieme di pratiche che vanno dall’immissine dei dati, allo sviluppo di un modello di machine learning (modello ML), alla sua distribuzione in produzione e al suo monitoraggio continuo. 

In effetti, lo sviluppo di un buon modello di Machine Learning è solo il primo passo di una soluzione di IA. Immaginate, ad esempio, di avere un modello estremamente valido ma di ricevere migliaia di richieste di inferenza (input che il modello deve prevedere) al secondo: se la vostra infrastruttura sottostante non è molto scalabile, il vostro modello si romperà immediatamente, o comunque sarà troppo lento per le vostre esigenze.

Oppure, immaginate che il vostro modello richieda infrastrutture molto potenti e costose, ad esempio diverse GPU di alto livello: senza un’analisi attenta e una buona strategia potreste finire per perdere denaro con il vostro modello, perché i costi infrastrutturali sono superiori al vostro rendimento.

È qui che entra in gioco MLOps, che integra organicamente un modello di ML in un ambiente aziendale.

Un altro esempio: molto spesso i dati grezzi devono essere pre-elaborati prima di essere inviati al modello e allo stesso modo l’output di un modello di ML deve essere post-elaborato prima di essere utilizzato. In questo caso, è possibile creare una pipeline di dati MLOps che si occupi di tutte queste trasformazioni.

Un’ultima osservazione: un tema molto caldo oggi è il monitoraggio dei modelli. I modelli di ML devono essere mantenuti in ogni momento, poiché si degradano nel tempo, ad esempio a causa della deriva (che si verifica quando i dati di addestramento non sono più rappresentativi dei dati inviati per l’inferenza). È quindi fondamentale disporre di un buon sistema di monitoraggio che analizzi l’integrità dei dati (cioè che i dati inviati come input al modello non siano corrotti) e le prestazioni del modello (cioè che le previsioni del modello non si degradino e siano ancora affidabili).

Quali possono essere i diversi componenti di una soluzione MLOps?

Una soluzione MLOps può includere diversi componenti a seconda delle esigenze e dei requisiti specifici del progetto. Una configurazione comune può includere, nell’ordine:

• Data Engineer: Come primo passo, è necessario raccogliere, preparare e archiviare i dati; questo include attività come l’ingestione, la pulizia dei dati e una prima analisi esplorativa dei dati.
• Sviluppo del modello: È il momento in cui si costruisce e si addestra il modello di ML. Comprende attività come l’ingegnerizzazione delle caratteristiche, la codifica, la scelta delle metriche giuste, la selezione dell’architettura del modello, l’addestramento del modello e la regolazione degli iperparametri.
• Tracciamento degli esperimenti: Fare esperimenti può essere considerata una sottofase dello sviluppo del modello, ma mi piace evidenziarlo separatamente perché gli esperimenti possono essere utilizzati per modificare il modello in futuro o se si devono realizzare progetti simili.. In particolare, si tiene traccia del comportamento dei diversi modelli (ad esempio, Lasso vs. Ridge regression, o XGBoost vs. CatBoost), ma anche delle configurazioni degli iperparametri, degli artefatti del modello e di altri risultati.
• Distribuzione del modello: in questa fase si mette in produzione il modello di ML, cioè lo si rende disponibile per gli utenti che possono inviare input al modello e ottenere previsioni. L’aspetto di questa fase può variare molto, da qualcosa di semplice come una Flask o una FastAPI a soluzioni molto più complicate.
• Gestione dell’infrastruttura: con un modello distribuito è necessario gestire l’infrastruttura associata, occupandosi della scalabilità, sia verticale che orizzontale, ossia assicurandosi che il modello possa gestire senza problemi volumi di dati elevati e ad alta velocità. Una soluzione molto diffusa, ma non certo l’unica, è l’utilizzo di Kubernetes.
• Monitoraggio del modello: Una volta che tutti i passaggi precedenti sono andati a buon fine, è necessario monitorare che il modello di ML funzioni come previsto: ciò significa da un lato registrare tutti gli errori, dall’altro verificare le sue prestazioni e rilevare le derive.

Quali sono le sfide più comuni nell’implementazione di MLOps?

Poiché l’MLOps è un’impresa complessa, si presenta con molte sfide potenziali, ma in questa sede vorrei concentrarmi sugli aspetti legati ai dati. Dopo tutto è una delle cose più importanti; come direbbe Sherlock Holmes: “Dati! Dati! Dati! (…) Non posso fare mattoni senza argilla”.

Per diversi motivi, non è banale avere un set di dati sufficientemente buono per sviluppare, addestrare e testare un modello di ML. Potrebbe non essere abbastanza grande, potrebbe non avere una varietà sufficiente (ad esempio, si pensi a un problema di classificazione con classi molto sbilanciate e sottorappresentate), o potrebbe non avere una qualità sufficiente (dati molto sporchi, provenienti da fonti diverse, con formato e tipo di dati diversi, molti valori mancanti o incoerenti, ad esempio {“genere”: “maschio”, “incinta”: Vero}).

Un altro problema dei dati è il diritto di accedervi. Per motivi di riservatezza o legali (ad es. GDPR), potrebbe non essere possibile spostare i dati da un server aziendale o da un Paese specifico (ad es. informazioni finanziarie che non possono essere esportate) e questo limita i tipi di tecnologia o di infrastrutture che possono essere utilizzate, e la distribuzione su cloud può essere ostacolata (o del tutto vietata). In altri casi, solo un piccolo sottoinsieme di dati curati è accessibile all’uomo e tutti gli altri dati sono leggibili solo a macchina.

Qual è uno strumento o una tecnologia che ritieni molto interessante per gli MLOps ma che potrebbe non essere ancora completamente diffuso?

Forse è il Data Scientist che è in me a parlare, ma direi un Feature Store. Sicuramente conoscete il Feature Engineering, che è il processo di estrazione di nuove caratteristiche o informazioni dai dati grezzi: ad esempio, se avete una data, ad esempio il 5 maggio 1821, calcolate e aggiungete il giorno della settimana corrispondente, il sabato. Questo potrebbe essere utile se si sta cercando di prevedere il consumo di elettricità di una fabbrica, dato che spesso sono chiuse di domenica e nei giorni festivi. Pertanto, quando si lavora su un modello di Machine Learning, si prendono i dati grezzi e li si trasforma in dati curati, con nuove informazioni/caratteristiche e organizzati nel modo giusto. Un archivio di caratteristiche è uno strumento che consente di salvare e memorizzare tutte queste informazioni.

In questo modo, quando si vogliono sviluppare nuove versioni del modello di ML, o un modello di ML diverso utilizzando le stesse fonti di dati, o quando team diversi lavorano su progetti diversi con le stesse fonti di dati, è possibile garantire la coerenza dei dati. 

Inoltre, la pre-elaborazione dei dati grezzi è automatizzata e riproducibile: ad esempio, chiunque lavori al progetto può recuperare i dati curati (output dell’ingegneria delle caratteristiche) calcolati in una data specifica (ad esempio, la media degli ultimi 30 giorni relativi alla data di calcolo) ed essere sicuro che il risultato sia coerente.

Prima di concludere, hai qualche consiglio o trucco del mestiere da condividere?

Vorrei citare tre cose che ho trovato utili nella mia esperienza. 

Il primo suggerimento è quello di utilizzare una struttura standardizzata per tutti i progetti di Data Science. Questo facilita la collaborazione quando più persone lavorano allo stesso progetto e anche quando nuove persone si aggiungono a un progetto esistente. Inoltre, aiuta a garantire coerenza, chiarezza e riproducibilità. Da questo punto di vista mi piace utilizzare Cookiecutter Data Science.

Un altro suggerimento è quello di utilizzare MLflow (o uno strumento simile) per confezionare il modello di ML. In questo modo il modello è facilmente disponibile tramite API e facile da condividere. Infine, vi raccomando di avere un solido sistema CI/CD (Continuous Integration and Continuous Delivery). In questo modo, una volta che gli artefatti del modello vengono messi in produzione, il modello è immediatamente attivo e disponibile. Potrete vedere il vostro modello funzionare senza problemi ed essere felici di un lavoro ben fatto.

---

Autore: Dr. Alessandro Conflitti, PhD in Matematica presso l’Università di Roma Tor Vergata & Head of Data Science @Radicalbit (sister company di Bitrock).

Intervistato da Luigi Cerrato, Senior Software Engineer @ Bitrock