5 Livelli di Maturità di MLOps

5 levels of MLOps maturity.

Introduzione

Creare un’infrastruttura solida per i sistemi di ML è importante. Deve garantire che lo sviluppo e il deployment delle applicazioni di ML siano organizzati e affidabili. Ma ecco la cosa — le esigenze di infrastruttura di ogni azienda sono diverse. Dipende da quanti modelli di ML hanno, da quanto velocemente devono essere deployati o da quanti richieste devono gestire.

Ad esempio, se un’azienda ha solo un modello in produzione, il processo di deployment può essere gestito manualmente. Dall’altro lato dello spettro, aziende come Netflix o Uber, con centinaia di modelli in produzione, hanno bisogno di un’infrastruttura altamente specializzata per sostenerli.

Ora potresti chiederti una domanda: dove si colloca la tua azienda in quel range?

I livelli di maturità di MLOps condivisi da Google e Microsoft sono qui per aiutare. Descrivono l’avanzamento e la sofisticazione dell’infrastruttura di ML basata sulle migliori pratiche del settore.

• Il tuo Plugin ChatGPT del Consiglio sull’IA Ottieni Consulenza Esperta
• Promemoria per i personaggi dei cartoni animati durante il viaggio.
• Vai avanti, colleziona più giochi Xbox Game Pass arriva su GeForce NOW.

Questo post del blog mira a sintetizzare e prendere il meglio da entrambi i framework. Innanzitutto, analizzeremo i cinque livelli di maturità e mostreremo la progressione dai processi manuali alle infrastrutture avanzate automatizzate. Poi, nell’ultima sezione, sosterremo che alcuni dei punti presentati da Microsoft e Google non dovrebbero essere seguiti ciecamente, ma piuttosto essere adattati alle tue esigenze. Ciò dovrebbe aiutarti a essere più consapevole nel processo di capire dove ti trovi con la tua infrastruttura e trovare eventuali aree di miglioramento potenziali.

Ok, immergiamoci!

Cos’è MLOps?

MLOps è un insieme di pratiche per stabilire un processo standardizzato e ripetibile per la gestione dell’intero ciclo di vita di ML, partendo dalla preparazione dei dati, dalla formazione del modello, dal deployment e dal monitoraggio. Prende in prestito dalle pratiche di DevOps ampiamente adottate nell’ingegneria del software, che sono focalizzate nel dare ai team un approccio rapido e continuamente iterativo allo shipping delle applicazioni software.

Tuttavia, gli strumenti di DevOps non sono sufficienti per il mondo del ML e differiscono in diversi modi:

• MLOps richiede un team multidisciplinare con un set di competenze diverse. Questo team include ingegneri dei dati responsabili della raccolta e dello storage dei dati, scienziati dei dati che sviluppano i modelli, ingegneri di machine learning (MLE) per deployare i modelli e ingegneri del software che li integrano con il prodotto.
• La scienza dei dati è per sua natura sperimentale, permettendo un miglioramento continuo esplorando diversi modelli, analisi dei dati, tecniche di formazione e configurazioni degli iperparametri. L’infrastruttura che supporta MLOps dovrebbe includere il tracciamento e la valutazione di approcci di successo e di insuccesso.
• Anche se il modello è in esecuzione in produzione, può ancora fallire a causa di cambiamenti nei dati in ingresso. Questo è chiamato fallimento silenzioso del modello, causato da drift dei dati e dei concetti. Pertanto, l’infrastruttura di ML richiede un sistema di monitoraggio per controllare costantemente le prestazioni del modello e i dati per evitare questo problema.

Ora esploriamo i vari livelli di maturità delle infrastrutture MLOps.

Livello 1 — Manuale

A questo livello, l’elaborazione dei dati, la sperimentazione e i processi di deployment del modello sono interamente manuali. Microsoft si riferisce a questo livello come ‘Nessun MLOps’, poiché il ciclo di vita di ML è difficile da ripetere e automatizzare.

L’intero flusso di lavoro si basa pesantemente su scienziati dei dati esperti, con un certo supporto da un ingegnere dei dati per preparare i dati e un ingegnere del software per integrare il modello con il prodotto/processi aziendali se necessario.

Questo approccio funziona molto bene in casi come:

• Start-up in fase iniziale e progetti di proof of concept — dove l’attenzione è sulla sperimentazione e le risorse sono limitate. Lo sviluppo e il deployment dei modelli di ML sono la principale preoccupazione prima di scalare le operazioni.
• Applicazioni di ML a piccola scala — l’approccio manuale può essere sufficiente per le applicazioni di ML con un ambito limitato o una piccola base di utenti, come un piccolo negozio di moda online. Con poche dipendenze dai dati e requisiti in tempo reale, gli scienziati dei dati possono gestire manualmente i processi di elaborazione dei dati, sperimentazione e deployment.
• Attività di ML ad hoc — In scenari specifici come le campagne di marketing, le attività o le analisi ML una tantum potrebbero non richiedere una piena implementazione di MLOps.

Secondo sia Google che Microsoft, questo approccio affronta anche diverse limitazioni, tra cui:

• Mancanza di un sistema di monitoraggio – non c’è visibilità sulle prestazioni del modello. Se si degrada, avrà un impatto negativo sul business. Inoltre, c’è una scienza dei dati post-deployment per capire il comportamento del modello in produzione.
• Nessun ritraining frequente dei modelli di produzione – nessuna adattamento del modello alle ultime tendenze o pattern.
• Le release sono dolorose e poco frequenti – poiché viene fatto manualmente, le release dei modelli avvengono solo un paio di volte all’anno.
• Nessun tracciamento centralizzato delle prestazioni del modello rende difficile confrontare le prestazioni di modelli diversi, ripetere i risultati o aggiornarlo.
• Documentazione limitata e nessuna versioning – pongono poche sfide in termini di rischio di introdurre modifiche non intenzionali al codice, rollback limitato alla versione funzionante e mancanza di ripetibilità.

Livello 2 – Ripetibile

Successivamente, introduciamo l’aspetto DevOps all’infrastruttura convertendo gli esperimenti in codice sorgente e memorizzandoli nel repository di origine utilizzando un sistema di controllo delle versioni come Git.

Microsoft suggerisce modifiche al processo di raccolta dei dati aggiungendo quanto segue:

• Pipeline dei dati – consente di estrarre i dati da diverse fonti e combinarli insieme. Quindi, i dati vengono trasformati utilizzando operazioni di pulizia, aggregazione o filtraggio. Rende l’infrastruttura più scalabile, efficiente e precisa rispetto a quella manuale.
• Catalogo dei dati – un repository centralizzato che include informazioni come la fonte dei dati, il tipo di dati, il formato dei dati, il proprietario, l’uso e la lineage. Aiuta ad organizzare, gestire e mantenere grandi volumi di dati in modo scalabile ed efficiente.

Per migliorare l’infrastruttura, dobbiamo introdurre alcuni test automatizzati insieme al controllo delle versioni. Ciò significa utilizzare pratiche come test unitari, test di integrazione o test di regressione. Questi ci aiuteranno a distribuire più velocemente e rendere le cose più affidabili garantendo che le nostre modifiche al codice non causino errori o bug.

Con tutti questi cambiamenti in atto, possiamo ripetere il processo di raccolta e distribuzione dei dati. Tuttavia, abbiamo ancora bisogno di un sistema di monitoraggio adeguato. Microsoft lo menziona brevemente dicendo che c’è “un feedback limitato su quanto bene un modello funziona in produzione”, ma non entra nei dettagli a riguardo.

Livello 3 – Riproducibile

Ci sono due motivi chiave per cui la riproducibilità è cruciale: risoluzione dei problemi e collaborazione. Immagina uno scenario in cui le prestazioni del tuo modello appena distribuito stanno deteriorando, con conseguenti previsioni inaccurate. In quel caso, è necessario conservare un registro delle versioni precedenti dei dati e del modello per tornare alla versione precedente del modello finché non si trova la causa radice del problema sottostante.

Inoltre, la riproducibilità rende più facile per i diversi membri del team capire cosa stanno facendo gli altri e costruire sul lavoro degli altri. Questo approccio collaborativo e condivisione delle conoscenze può portare a una maggiore innovazione e a modelli migliori.

Per ottenere la riproducibilità, dovremmo migliorare l’architettura in quattro modi:

• Pipeline di training automatizzata – gestisce il processo end-to-end di formazione dei modelli, dalla preparazione dei dati alla valutazione del modello.
• Metadata store – un database è un modo per tracciare e gestire i metadati, inclusi le fonti dei dati, le configurazioni del modello, gli iperparametri, le esecuzioni di formazione, le metriche di valutazione e tutti i dati degli esperimenti.
• Registro del modello – è un repository per memorizzare i modelli di ML, le loro versioni e gli artefatti necessari per la distribuzione, che aiuta a recuperare l’esatta versione se necessario.
• Feature store – che serve a aiutare i data scientist e gli ingegneri di machine learning a sviluppare, testare e distribuire modelli di machine learning in modo più efficiente fornendo un punto centralizzato per memorizzare, gestire e servire le caratteristiche. Può anche essere utilizzato per tracciare l’evoluzione delle caratteristiche nel tempo e pre-elaborare e trasformare le caratteristiche secondo necessità.

In questa fase è disponibile un servizio di monitoraggio che offre un feedback in tempo reale sulle prestazioni del modello. Tuttavia, Microsoft e Google non forniscono alcuna informazione aggiuntiva oltre a confermare che è presente.

Livello 4 — Automatizzato

Questo livello di automazione aiuta i data scientist a esplorare efficientemente nuove idee in ambito di ingegneria delle features, architettura del modello e iperparametri, automatizzando l’intera pipeline di apprendimento automatico, inclusa la creazione, il testing e il rilascio. Per raggiungere questo obiettivo, Microsoft suggerisce di incorporare due componenti aggiuntivi:

• CI/CD — dove l’Integrazione Continua (CI) garantisce l’integrazione delle modifiche al codice da parte di diversi membri del team in un repository condiviso, mentre il Deployment Continuo (CD) automatizza il rilascio del codice convalidato negli ambienti di produzione. Ciò consente un rapido rilascio di aggiornamenti del modello, miglioramenti e correzioni di bug.
• Test A/B dei modelli — questo metodo di convalida del modello consiste nel confrontare le previsioni e il feedback degli utenti tra un modello esistente e un modello candidato per determinare il migliore.

Livello 5 — Continuamente migliorato

In questa fase, il modello viene riallenato automaticamente in base al trigger del sistema di monitoraggio. Questo processo di riallenamento è anche noto come apprendimento continuo. Gli obiettivi dell’apprendimento continuo sono:

• Combattere improvvisi scostamenti dei dati che possono verificarsi, garantendo che il modello rimanga efficace anche di fronte a cambiamenti inattesi dei dati.
• Adattarsi a eventi rari come il Black Friday, dove i modelli e le tendenze dei dati possono deviare significativamente dalla norma.
• Superare il problema della partenza a freddo, che si verifica quando il modello deve fare previsioni per nuovi utenti privi di dati storici.

Impulso per l’automazione

Microsoft e Google sono importanti player nel mercato del cloud computing, con Azure che detiene una quota di mercato del 22% e Google del 10%. Offrono una vasta gamma di servizi, tra cui elaborazione, archiviazione e strumenti di sviluppo, che sono componenti essenziali per la costruzione di infrastrutture di apprendimento automatico avanzate.

Come qualsiasi attività commerciale, il loro obiettivo principale è generare ricavi vendendo questi servizi. Questo è parzialmente il motivo per cui i loro blog enfatizzano l’avanzamento e l’automazione. Tuttavia, un livello di maturità più elevato non garantisce risultati migliori per la tua attività. La soluzione ottimale è quella che si allinea alle specifiche esigenze della tua azienda e alla giusta tecnologia.

Anche se i livelli di maturità possono aiutare a determinare il tuo livello di avanzamento attuale, non dovrebbero essere seguiti ciecamente poiché gli incentivi principali di Microsoft e Google sono la vendita dei loro servizi. L’esempio è specificamente il loro impulso per il riallenamento automatico. Questo processo richiede molta elaborazione, ma spesso è superfluo o dannoso. Il riallenamento dovrebbe essere fatto solo quando necessario. Ciò che è più importante per la tua infrastruttura è avere un sistema di monitoraggio affidabile e un processo di analisi della causa radice efficace.

Il monitoraggio dovrebbe iniziare dal livello manuale

Un sistema di monitoraggio limitato appare al livello 2 dei livelli di maturità descritti. In realtà, dovresti monitorare il tuo modello non appena si prendono decisioni commerciali basate sulle sue uscite, indipendentemente dal livello di maturità. Ciò consente di ridurre il rischio di fallimento e vedere come il modello si comporta rispetto ai tuoi obiettivi commerciali.

Il primo passo nel monitoraggio può essere semplice come confrontare le previsioni del modello con i valori effettivi. Questo confronto di base è una valutazione di base delle prestazioni del modello e un buon punto di partenza per ulteriori analisi quando il modello non funziona. Inoltre, è importante considerare la valutazione degli sforzi di scienza dei dati, che include la misurazione del rendimento dell’investimento (ROI). Ciò significa valutare il valore che le tecniche e gli algoritmi di scienza dei dati apportano. È fondamentale capire quanto efficaci sono questi sforzi nel generare valore commerciale.

La valutazione del ROI fornisce informazioni utili che possono aiutarti a prendere decisioni migliori riguardo all’allocazione di risorse e alla pianificazione di investimenti futuri. Con l’evoluzione dell’infrastruttura, il sistema di monitoraggio può diventare più complesso con funzionalità e capacità aggiuntive. Tuttavia, è comunque importante prestare attenzione all’importanza di applicare una configurazione di monitoraggio di base all’infrastruttura al primo livello di maturità.

Rischi della riqualificazione

Nella descrizione del livello 5, abbiamo elencato i vantaggi della riqualificazione automatica in produzione. Tuttavia, prima di aggiungerla alla tua infrastruttura, dovresti considerare i rischi ad essa correlati:

1. Riqualificazione su dati ritardati

In alcuni scenari del mondo reale, come la previsione del default dei prestiti, le etichette possono essere ritardate per mesi o addirittura anni. La verità di base sta ancora arrivando, ma stai riqualificando il tuo modello utilizzando vecchi dati, che potrebbero non rappresentare bene la realtà attuale.

2. Incapacità di determinare la causa radice del problema

Se le prestazioni del modello diminuiscono, non significa sempre che abbia bisogno di più dati. Potrebbero esserci vari motivi per il fallimento del modello, come i cambiamenti nei processi aziendali downstream, lo scostamento tra addestramento e servizio o la fuga di dati. Dovresti prima indagare per trovare il problema sottostante e quindi riqualificare il modello se necessario.

3. Maggiore rischio di fallimento

La riqualificazione amplifica il rischio di fallimento del modello. Oltre al fatto che aggiunge complessità all’infrastruttura, più frequentemente si aggiorna, più opportunità il modello ha di fallire. Qualsiasi problema non rilevato che appare nella raccolta o nella pre-elaborazione dei dati verrà propagato al modello, risultando in un modello riqualificato su dati difettosi.

4. Costi più elevati

La riqualificazione non è un processo gratuito. Comporta spese relative a:

• Archiviazione e convalida dei dati di riqualificazione
• Risorse di calcolo per riqualificare il modello
• Test di un nuovo modello per determinare se funziona meglio di quello attuale

Sommario

I sistemi di ML sono complessi. Costruire e distribuire modelli in modo ripetibile e sostenibile è difficile. In questo post del blog, abbiamo esplorato cinque livelli di maturità MLOps basati sulle migliori pratiche di Google e Microsoft nell’industria. Abbiamo discusso dell’evoluzione dalla distribuzione manuale alle infrastrutture automatizzate, evidenziando i vantaggi che ogni livello porta. Tuttavia, è fondamentale capire che queste pratiche non dovrebbero essere seguite ciecamente. Invece, la loro adattabilità dovrebbe essere basata sulle esigenze e i requisiti specifici della tua azienda.