MLOps: pipeline di distribuzione continua e automazione nel machine learning

Last reviewed 2024-08-28 UTC

Questo documento illustra le tecniche per l'implementazione e l'automazione dell'integrazione continua (CI), della distribuzione continua (CD) e dell'addestramento continuo (CT) per i sistemi di machine learning (ML). Questo documento si applica principalmente ai sistemi di AI predittiva.

La data science e il machine learning stanno diventando funzionalità fondamentali per risolvere problemi complessi del mondo reale, trasformare i settori e fornire valore in tutti i domini. Al momento, hai a disposizione gli ingredienti per applicare un ML efficace:

  • Set di dati di grandi dimensioni
  • Risorse di computing on demand economiche
  • Acceleratori specializzati per il ML su varie piattaforme cloud
  • Rapidi progressi in diversi campi di ricerca del ML (come visione artificiale, comprensione del linguaggio naturale, AI generativa e sistemi di Recommendations AI).

Pertanto, molte aziende stanno investendo nei propri team di data science e nelle funzionalità di ML per sviluppare modelli predittivi in grado di offrire valore aziendale ai propri utenti.

Questo documento è rivolto a data scientist e ML engineer che vogliono applicare i principi DevOps ai sistemi ML (MLOps). MLOps è una cultura e una pratica di ML engineering che mira a unificare lo sviluppo (Dev) e il funzionamento (Ops) dei sistemi ML. Mettere in pratica le MLOps significa promuovere l'automazione e il monitoraggio di ogni fase della creazione di un sistema ML, tra cui integrazione, test, rilascio, deployment e gestione dell'infrastruttura.

I data scientist possono implementare e addestrare un modello ML con prestazioni predittive su un set di dati di holdout offline, dati i dati di addestramento pertinenti per il loro caso d'uso. Tuttavia, la vera sfida non è creare un modello ML, ma creare un sistema ML integrato e gestirlo continuamente in produzione. Grazie alla lunga storia dei servizi di ML di produzione di Google, abbiamo imparato che possono esserci molte insidie nella gestione dei sistemi basati su ML in produzione. Alcune di queste insidie sono riassunte in Machine Learning: The High Interest Credit Card of Technical Debt.

Come mostrato nel diagramma seguente, solo una piccola parte di un sistema di ML reale è composta dal codice ML. Gli elementi circostanti richiesti sono vasti e complessi.

I sistemi ML non sono solo codice ML.

Figura 1. Elementi per i sistemi ML. Adattato da Hidden Technical Debt in Machine Learning Systems.

Il diagramma precedente mostra i seguenti componenti del sistema:

  • Configurazione
  • Automazione
  • Raccolta dei dati
  • Verifica dei dati
  • Test e debug
  • Gestione delle risorse
  • Analisi dei modelli
  • Gestione dei processi e dei metadati
  • Infrastruttura di distribuzione
  • Monitoraggio

Per sviluppare e gestire sistemi complessi come questi, puoi applicare i principi DevOps ai sistemi ML (MLOps). Questo documento illustra i concetti da considerare quando configuri un ambiente MLOps per le tue pratiche di data science, come CI, CD e CT nel ML.

Vengono discussi i seguenti argomenti:

  • DevOps e MLOps
  • Passaggi per lo sviluppo di modelli ML
  • Livelli di maturità di MLOps
  • MLOps per l'AI generativa

DevOps e MLOps

DevOps è una pratica molto diffusa nello sviluppo e nella gestione di sistemi software su larga scala. Questa pratica offre vantaggi come l'abbreviazione dei cicli di sviluppo, l'aumento della velocità di deployment e release affidabili. Per ottenere questi vantaggi, devi introdurre due concetti nello sviluppo del sistema software:

Un sistema ML è un sistema software, quindi si applicano pratiche simili per garantire che tu possa creare e gestire in modo affidabile i sistemi ML su larga scala.

Tuttavia, i sistemi di ML differiscono dagli altri sistemi software nei seguenti modi:

  • Competenze del team: in un progetto ML, il team di solito include data scientist o ricercatori ML, che si concentrano sull'analisi esplorativa dei dati, sullo sviluppo di modelli e sulla sperimentazione. Questi membri potrebbero non essere ingegneri del software esperti in grado di creare servizi di livello di produzione.

  • Sviluppo: il ML è di natura sperimentale. Dovresti provare diverse caratteristiche, algoritmi, tecniche di modellazione e configurazioni dei parametri per trovare ciò che funziona meglio per il problema il più rapidamente possibile. La sfida consiste nel monitorare ciò che ha funzionato e ciò che non ha funzionato e nel mantenere la riproducibilità, massimizzando al contempo la riusabilità del codice.

  • Test: il test di un sistema di ML è più complesso di quello di altri sistemi software. Oltre ai tipici test di unità e di integrazione, sono necessari la convalida dei dati, la valutazione della qualità del modello addestrato e la convalida del modello.

  • Deployment: nei sistemi ML, il deployment non è semplice come il deployment di un modello ML addestrato offline come servizio di previsione. I sistemi ML possono richiedere il deployment di una pipeline in più passaggi per addestrare e implementare automaticamente i modelli. Questa pipeline aggiunge complessità e richiede l'automazione dei passaggi eseguiti manualmente prima del deployment dai data scientist per addestrare e convalidare i nuovi modelli.

  • Produzione: i modelli ML possono avere un rendimento ridotto non solo a causa di una programmazione non ottimale, ma anche a causa di profili di dati in continua evoluzione. In altre parole, i modelli possono deteriorarsi in più modi rispetto ai sistemi software convenzionali e devi tenere conto di questo degrado. Pertanto, devi monitorare le statistiche di riepilogo dei dati e le prestazioni online del modello per inviare notifiche o eseguire il rollback quando i valori si discostano dalle tue aspettative.

I sistemi ML e altri sistemi software sono simili per quanto riguarda l'integrazione continua del controllo del codice sorgente, i test delle unità, i test di integrazione e la distribuzione continua del modulo o del pacchetto software. Tuttavia, nel ML, ci sono alcune differenze notevoli:

  • La CI non riguarda più solo il test e la convalida di codice e componenti, ma anche il test e la convalida di dati, schemi di dati e modelli.
  • La CD non riguarda più un singolo pacchetto software o un servizio, ma un sistema (una pipeline di addestramento ML) che deve eseguire automaticamente il deployment di un altro servizio (servizio di previsione del modello).
  • Il CT è una nuova proprietà, esclusiva dei sistemi di ML, che riguarda l'addestramento e la pubblicazione automatici dei modelli.

La sezione seguente illustra i passaggi tipici per l'addestramento e la valutazione di un modello ML da utilizzare come servizio di previsione.

Passaggi di data science per il ML

In qualsiasi progetto di ML, dopo aver definito il caso d'uso aziendale e stabilito i criteri di successo, il processo di invio di un modello di ML in produzione prevede le seguenti fasi. Queste fasi possono essere completate manualmente o mediante una pipeline automatizzata.

  1. Estrazione dati: selezioni e integri i dati pertinenti da varie origini dati per l'attività di ML.
  2. Analisi dei dati: esegui l'analisi esplorativa dei dati (EDA) per comprendere i dati disponibili per la creazione del modello ML. Questo processo porta a quanto segue:
    • Comprendere lo schema e le caratteristiche dei dati previsti dal modello.
    • Identificare la preparazione dei dati e il feature engineering necessari per il modello.
  3. Preparazione dei dati: i dati vengono preparati per l'attività di ML. Questa preparazione prevede la pulizia dei dati, in cui i dati vengono suddivisi in set di addestramento, convalida e test. Inoltre, applichi trasformazioni dei dati e feature engineering al modello che risolve l'attività target. L'output di questo passaggio sono le suddivisioni dei dati nel formato preparato.
  4. Addestramento del modello: il data scientist implementa diversi algoritmi con i dati preparati per addestrare vari modelli ML. Inoltre, sottoponi gli algoritmi implementati all'ottimizzazione degli iperparametri per ottenere il modello ML con il rendimento migliore. L'output di questo passaggio è un modello addestrato.
  5. Valutazione del modello: il modello viene valutato su un set di test di holdout per valutare la qualità del modello. L'output di questo passaggio è un insieme di metriche per valutare la qualità del modello.
  6. Convalida del modello: viene confermata l'idoneità del modello per il deployment, ovvero che le sue prestazioni predittive siano migliori di una determinata base di riferimento.
  7. Erogazione del modello: il deployment del modello convalidato viene eseguito in un ambiente di destinazione per generare previsioni. Questo deployment può essere uno dei seguenti:
    • Microservizi con un'API REST per fornire previsioni online.
    • Un modello incorporato in un dispositivo edge o mobile.
    • Parte di un sistema di previsione in batch.
  8. Monitoraggio del modello: le prestazioni predittive del modello vengono monitorate per richiamare potenzialmente una nuova iterazione nel processo di elaborazione ML.

Il livello di automazione di questi passaggi definisce la maturità del processo di elaborazione ML, che riflette la velocità di addestramento di nuovi modelli in base a nuovi dati o di addestramento di nuovi modelli in base a nuove implementazioni. Le sezioni seguenti descrivono tre livelli di MLOps, a partire dal livello più comune, che non prevede l'automazione, fino all'automazione delle pipeline ML e CI/CD.

Livello MLOps 0: processo manuale

Molti team hanno data scientist e ricercatori di ML che possono creare modelli allo stato dell'arte, ma il loro processo di creazione e deployment dei modelli di ML è completamente manuale. Questo è considerato il livello di maturità di base o livello 0. Il seguente diagramma mostra il flusso di lavoro di questo processo.

Flusso di lavoro dei passaggi ML manuali per MLOps di livello 0.

Figura 2. Passaggi di ML manuale per pubblicare il modello come servizio di previsione.

Caratteristiche

Il seguente elenco evidenzia le caratteristiche del processo MLOps di livello 0, come mostrato nella Figura 2:

  • Processo manuale, basato su script e interattivo: ogni passaggio è manuale, inclusi l'analisi dei dati, la preparazione dei dati, l'addestramento del modello e la convalida. Richiede l'esecuzione manuale di ogni passaggio e la transizione manuale da un passaggio all'altro. Questo processo è solitamente guidato da codice sperimentale scritto ed eseguito in modo interattivo nei notebook dai data scientist, fino alla produzione di un modello utilizzabile.

  • Scollegamento tra ML e operazioni: il processo separa i data scientist che creano il modello dagli ingegneri che lo pubblicano come servizio di previsione. I data scientist consegnano un modello addestrato come artefatto al team di ingegneri per il deployment sulla loro infrastruttura API. Questo passaggio può includere l'inserimento del modello addestrato in una posizione di archiviazione, l'archiviazione dell'oggetto del modello in un repository di codice o il caricamento in un registro dei modelli. In seguito, gli ingegneri che eseguono il deployment del modello devono rendere disponibili in produzione le caratteristiche richieste per la gestione a bassa latenza, il che può portare a un disallineamento addestramento/erogazione.

  • Iterazioni di rilascio non frequenti: il processo presuppone che il tuo team di data science gestisca alcuni modelli che non cambiano di frequente, modificando l'implementazione del modello o riaddestrandolo con nuovi dati. Il deployment di una nuova versione del modello viene eseguito solo un paio di volte all'anno.

  • Nessuna CI: poiché si presuppone che le modifiche all'implementazione siano minime, la CI viene ignorata. In genere, il test del codice fa parte dell'esecuzione dei notebook o degli script. Gli script e i notebook che implementano i passaggi dell'esperimento sono controllati dal codice sorgente e producono artefatti come modelli addestrati, metriche di valutazione e visualizzazioni.

  • Nessun CD: poiché non vengono eseguite frequenti implementazioni di versioni del modello, il CD non viene preso in considerazione.

  • Il deployment si riferisce al servizio di previsione: il processo riguarda solo il deployment del modello addestrato come servizio di previsione (ad esempio, un microservizio con un'API REST), anziché il deployment dell'intero sistema ML.

  • Mancanza di monitoraggio attivo delle prestazioni: il processo non monitora né registra le previsioni e le azioni del modello, necessarie per rilevare il degrado delle prestazioni del modello e altre deviazioni comportamentali del modello.

Il team di ingegneria potrebbe avere una propria configurazione complessa per la configurazione, il test e il deployment delle API, tra cui test di sicurezza, regressione, carico e canary. Inoltre, il deployment in produzione di una nuova versione di un modello ML di solito passa attraverso test A/B o esperimenti online prima che il modello venga promosso per gestire tutto il traffico delle richieste di previsione.

Sfide

Il livello 0 di MLOps è comune in molte aziende che iniziano ad applicare il ML ai propri casi d'uso. Questo processo manuale, guidato dai data scientist, potrebbe essere sufficiente quando i modelli vengono modificati o addestrati raramente. In pratica, i modelli spesso non funzionano quando vengono implementati nel mondo reale. I modelli non riescono ad adattarsi ai cambiamenti nelle dinamiche dell'ambiente o ai cambiamenti nei dati che descrivono l'ambiente. Per saperne di più, consulta Why Machine Learning Models Crash and Burn in Production.

Per affrontare queste sfide e mantenere l'accuratezza del modello in produzione, devi:

  • Monitora attivamente la qualità del modello in produzione: il monitoraggio ti consente di rilevare il peggioramento delle prestazioni e l'obsolescenza del modello. Funge da indicatore per una nuova iterazione di sperimentazione e un nuovo addestramento (manuale) del modello su nuovi dati.

  • Riaddestra di frequente i modelli di produzione: per acquisire i pattern in evoluzione ed emergenti, devi riaddestrare il modello con i dati più recenti. Ad esempio, se la tua app consiglia prodotti di moda utilizzando l'ML, i suoi suggerimenti dovrebbero adattarsi alle ultime tendenze e ai prodotti più recenti.

  • Sperimenta continuamente nuove implementazioni per produrre il modello: per sfruttare le idee e i progressi tecnologici più recenti, devi provare nuove implementazioni come feature engineering, architettura del modello e iperparametri. Ad esempio, se utilizzi la visione artificiale nel riconoscimento facciale, i pattern dei volti sono fissi, ma nuove tecniche migliori possono migliorare l'accuratezza del riconoscimento.

Per affrontare le sfide di questo processo manuale, sono utili le pratiche MLOps per CI/CD e CT. Eseguendo il deployment di una pipeline di addestramento ML, puoi abilitare il CT e configurare un sistema CI/CD per testare, creare ed eseguire rapidamente il deployment di nuove implementazioni della pipeline ML. Queste funzionalità sono descritte in maggiore dettaglio nelle sezioni successive.

MLOps livello 1: automazione della pipeline ML

L'obiettivo del livello 1 è eseguire l'addestramento continuo del modello automatizzando la pipeline ML. In questo modo, puoi ottenere la distribuzione continua del servizio di previsione del modello. Per automatizzare il processo di utilizzo di nuovi dati per riaddestrare i modelli in produzione, devi introdurre nella pipeline passaggi di convalida automatica dei dati e dei modelli, nonché trigger della pipeline e gestione dei metadati.

La figura seguente è una rappresentazione schematica di una pipeline ML automatizzata per l'addestramento continuo.

Flusso di lavoro della pipeline ML per l'addestramento continuo.

Figura 3. Automazione della pipeline ML per l'addestramento continuo.

Caratteristiche

Il seguente elenco evidenzia le caratteristiche della configurazione MLOps di livello 1, come mostrato nella Figura 3:

  • Sperimentazione rapida: i passaggi dell'esperimento ML sono orchestrati. La transizione tra i passaggi è automatizzata, il che porta a una rapida iterazione degli esperimenti e a una migliore idoneità a spostare l'intera pipeline in produzione.

  • CT del modello in produzione: il modello viene addestrato automaticamente in produzione utilizzando dati aggiornati in base ai trigger della pipeline in tempo reale, che vengono discussi nella sezione successiva.

  • Simmetria sperimentale-operativa: l'implementazione della pipeline utilizzata nell'ambiente di sviluppo o di esperimento viene utilizzata nell'ambiente di pre-produzione e di produzione, che è un aspetto chiave della pratica MLOps per l'unificazione di DevOps.

  • Codice modularizzato per componenti e pipeline: per creare pipeline ML, i componenti devono essere riutilizzabili, componibili e potenzialmente condivisibili tra le pipeline ML. Pertanto, mentre il codice EDA può ancora risiedere nei notebook, il codice sorgente dei componenti deve essere modularizzato. Inoltre, idealmente i componenti dovrebbero essere containerizzati per:

    • Disaccoppia l'ambiente di esecuzione dal runtime del codice personalizzato.
    • Rendi il codice riproducibile tra gli ambienti di sviluppo e di produzione.
    • Isola ogni componente della pipeline. I componenti possono avere la propria versione dell'ambiente di runtime e avere linguaggi e librerie diversi.

  • Distribuzione continua dei modelli: una pipeline ML in produzione distribuisce continuamente servizi di previsione ai nuovi modelli addestrati su nuovi dati. Il passaggio di deployment del modello, che fornisce il modello addestrato e convalidato come servizio di previsione per le previsioni online, è automatizzato.

  • Deployment della pipeline: nel livello 0, esegui il deployment di un modello addestrato come servizio di previsione in produzione. Per il livello 1, esegui il deployment di un'intera pipeline di addestramento, che viene eseguita automaticamente e in modo ricorrente per fornire il modello addestrato come servizio di previsione.

Componenti aggiuntivi

Questa sezione illustra i componenti che devi aggiungere all'architettura per abilitare l'addestramento continuo del ML.

Convalida dei dati e dei modelli

Quando esegui il deployment della pipeline ML in produzione, uno o più trigger discussi nella sezione Trigger della pipeline ML eseguono automaticamente la pipeline. La pipeline prevede nuovi dati in tempo reale per produrre una nuova versione del modello addestrata sui nuovi dati (come mostrato nella Figura 3). Pertanto, nella pipeline di produzione sono necessari passaggi automatizzati di convalida dei dati e convalida del modello per garantire il seguente comportamento previsto:

  • Convalida dei dati: questo passaggio è necessario prima dell'addestramento del modello per decidere se riaddestrare il modello o interrompere l'esecuzione della pipeline. Questa decisione viene presa automaticamente se la pipeline ha identificato quanto segue.

    • Disallineamenti dello schema dei dati: questi disallineamenti sono considerati anomalie nei dati di input. Pertanto, i dati di input che non sono conformi allo schema previsto vengono ricevuti dai passaggi della pipeline downstream, inclusi i passaggi di trattamento dati e addestramento del modello. In questo caso, devi interrompere la pipeline in modo che il team di data science possa indagare. Il team potrebbe rilasciare una correzione o un aggiornamento alla pipeline per gestire queste modifiche nello schema. Le asimmetrie dello schema includono la ricezione di caratteristiche impreviste, la mancata ricezione di tutte le caratteristiche previste o la ricezione di caratteristiche con valori imprevisti.
    • Disallineamenti dei valori dei dati: questi disallineamenti sono variazioni significative delle proprietà statistiche dei dati, il che significa che i pattern dei dati stanno cambiando e devi attivare un nuovo addestramento del modello per acquisire queste modifiche.

  • Convalida del modello: questo passaggio avviene dopo aver addestrato correttamente il modello con i nuovi dati. Valuti e convalidi il modello prima che venga promosso in produzione. Questo passaggio di convalida del modello offline prevede quanto segue.

    • Generazione di valori delle metriche di valutazione utilizzando il modello addestrato su un set di dati di test per valutare la qualità predittiva del modello.
    • Confrontare i valori delle metriche di valutazione prodotti dal modello appena addestrato con il modello attuale, ad esempio il modello di produzione, il modello di riferimento o altri modelli di requisiti aziendali. Assicurati che il nuovo modello produca prestazioni migliori rispetto al modello attuale prima di promuoverlo in produzione.
    • Assicurarsi che le prestazioni del modello siano coerenti in vari segmenti dei dati. Ad esempio, il modello di abbandono dei clienti appena addestrato potrebbe produrre un'accuratezza predittiva complessiva migliore rispetto al modello precedente, ma i valori di accuratezza per regione del cliente potrebbero presentare una varianza elevata.
    • Assicurarti di testare il modello per il deployment, inclusa la compatibilità dell'infrastruttura e la coerenza con l'API del servizio di previsione.

Oltre alla convalida del modello offline, un modello di cui è stato appena eseguito il deployment viene sottoposto alla convalida del modello online, in un deployment canary o in una configurazione di test A/B, prima di fornire previsioni per il traffico online.

Feature Store

Un componente aggiuntivo facoltativo per l'automazione della pipeline ML di livello 1 è un Feature Store. Un Feature Store è un repository centralizzato in cui standardizzi la definizione, l'archiviazione e l'accesso alle caratteristiche per l'addestramento e l'erogazione. Un Feature Store deve fornire un'API sia per l'erogazione batch ad alto throughput sia per l'erogazione in tempo reale a bassa latenza per i valori delle caratteristiche, nonché supportare i workload di addestramento e di erogazione.

Il Feature Store aiuta i data scientist a:

  • Scoprire e riutilizzare i set di caratteristiche disponibili per le loro entità, anziché ricreare caratteristiche uguali o simili.
  • Evita di avere caratteristiche simili con definizioni diverse gestendo le caratteristiche e i relativi metadati.
  • Pubblica i valori delle caratteristiche aggiornati da Feature Store.

  • Evita il disallineamento addestramento/erogazione utilizzando Feature Store come origine dati per la sperimentazione, l'addestramento continuo e l'erogazione online. Questo approccio garantisce che le caratteristiche utilizzate per l'addestramento siano le stesse utilizzate durante la distribuzione:

    • Per la sperimentazione, i data scientist possono ottenere un estratto offline dal Feature Store per eseguire i loro esperimenti.
    • Per l'addestramento continuo, la pipeline di addestramento ML automatizzata può recuperare un batch dei valori delle caratteristiche aggiornati del set di dati utilizzati per l'attività di addestramento.
    • Per la previsione online, il servizio di previsione può recuperare in batch i valori delle caratteristiche relativi all'entità richiesta, ad esempio le caratteristiche demografiche dei clienti, le caratteristiche dei prodotti e le caratteristiche di aggregazione della sessione corrente.
    • Per la previsione online e il recupero delle caratteristiche, il servizio di previsione identifica le caratteristiche pertinenti per un'entità. Ad esempio, se l'entità è un cliente, le caratteristiche pertinenti potrebbero includere età, cronologia acquisti e comportamento di navigazione. Il servizio raggruppa questi valori delle caratteristiche e recupera tutte le caratteristiche necessarie per l'entità contemporaneamente, anziché singolarmente. Questo metodo di recupero contribuisce all'efficienza, soprattutto quando devi gestire più entità.

Gestione dei metadati

Le informazioni su ogni esecuzione della pipeline ML vengono registrate per facilitare la derivazione, la riproducibilità e i confronti di dati e artefatti. Inoltre, ti aiuta a eseguire il debug di errori e anomalie. Ogni volta che esegui la pipeline, l'archivio dei metadati ML registra i seguenti metadati:

  • Le versioni della pipeline e dei componenti che sono state eseguite.
  • La data e l'ora di inizio e di fine, nonché il tempo impiegato dalla pipeline per completare ciascuno dei passaggi.
  • L'esecutore della pipeline.
  • Gli argomenti dei parametri passati alla pipeline.
  • I puntatori agli artefatti prodotti da ogni passaggio della pipeline, come la posizione dei dati preparati, le anomalie di convalida, le statistiche calcolate e il vocabolario estratto dalle caratteristiche categoriche. Il monitoraggio di questi output intermedi ti aiuta a riprendere la pipeline dal passaggio più recente se la pipeline si è interrotta a causa di un passaggio non riuscito, senza dover eseguire nuovamente i passaggi già completati.
  • Un puntatore al modello addestrato precedente se devi eseguire il rollback a una versione precedente del modello o se devi produrre metriche di valutazione per una versione precedente del modello quando alla pipeline vengono forniti nuovi dati di test durante il passaggio di convalida del modello.
  • Le metriche di valutazione del modello generate durante la fase di valutazione del modello per i set di addestramento e di test. Queste metriche ti aiutano a confrontare le prestazioni di un modello appena addestrato con quelle registrate del modello precedente durante la fase di convalida del modello.

Trigger delle pipeline ML

Puoi automatizzare le pipeline di produzione ML per riaddestrare i modelli con nuovi dati, a seconda del tuo caso d'uso:

  • On demand: esecuzione manuale ad hoc della pipeline.
  • In base a una pianificazione: i nuovi dati etichettati sono sistematicamente disponibili per il sistema di ML su base giornaliera, settimanale o mensile. La frequenza di riaddestramento dipende anche dalla frequenza con cui cambiano i pattern dei dati e dal costo del riaddestramento dei modelli.
  • In base alla disponibilità di nuovi dati di addestramento: i nuovi dati non sono sistematicamente disponibili per il sistema ML, ma sono disponibili su base ad hoc quando vengono raccolti e resi disponibili nei database di origine.
  • In caso di degrado delle prestazioni del modello: il modello viene riaddestrato quando si verifica un degrado evidente delle prestazioni.
  • In caso di variazioni significative nelle distribuzioni dei dati (concept drift). È difficile valutare il rendimento completo del modello online, ma noti cambiamenti significativi nelle distribuzioni dei dati delle caratteristiche utilizzate per eseguire la previsione. Queste modifiche suggeriscono che il modello è diventato obsoleto e che deve essere riaddestrato con dati aggiornati.

Sfide

Supponendo che le nuove implementazioni della pipeline non vengano distribuite di frequente e che tu gestisca solo poche pipeline, di solito testi manualmente la pipeline e i suoi componenti. Inoltre, esegui manualmente il deployment delle nuove implementazioni della pipeline. Inoltre, invii il codice sorgente testato per la pipeline al team IT per il deployment nell'ambiente di destinazione. Questa configurazione è adatta quando esegui il deployment di nuovi modelli basati su nuovi dati, anziché su nuove idee di ML.

Tuttavia, devi provare nuove idee di ML ed eseguire rapidamente il deployment di nuove implementazioni dei componenti ML. Se gestisci molte pipeline ML in produzione, hai bisogno di una configurazione CI/CD per automatizzare la creazione, il test e il deployment delle pipeline ML.

MLOps livello 2: automazione della pipeline CI/CD

Per un aggiornamento rapido e affidabile delle pipeline in produzione, hai bisogno di un sistema CI/CD automatizzato e solido. Questo sistema CI/CD automatizzato consente ai tuoi data scientist di esplorare rapidamente nuove idee relative a feature engineering, architettura dei modelli e iperparametri. Possono implementare queste idee e creare, testare ed eseguire automaticamente il deployment dei nuovi componenti della pipeline nell'ambiente di destinazione.

Il seguente diagramma mostra l'implementazione della pipeline ML utilizzando CI/CD, che ha le caratteristiche della configurazione delle pipeline ML automatizzate, oltre alle routine CI/CD automatizzate.

Flusso di lavoro della pipeline ML con integrazione CI/CD.

Figura 4. Pipeline CI/CD e ML automatizzata.

Questa configurazione MLOps include i seguenti componenti:

  • Controllo del codice sorgente
  • Servizi di test e build
  • Servizi di deployment
  • Model Registry
  • Feature Store
  • Archivio dei metadati ML
  • Orchestratore di pipeline ML

Caratteristiche

Il seguente diagramma mostra le fasi della pipeline di automazione CI/CD ML:

Caratteristiche della pipeline ML automatizzata CI/CD.

Figura 5. Fasi della pipeline ML automatizzata CI/CD.

La pipeline è costituita dalle seguenti fasi:

  1. Sviluppo e sperimentazione: provi in modo iterativo nuovi algoritmi di ML e una nuova modellazione in cui vengono orchestrati i passaggi dell'esperimento. L'output di questa fase è il codice sorgente dei passaggi della pipeline ML, che viene poi inviato a un repository di origine.

  2. Integrazione continua della pipeline: crei il codice sorgente ed esegui vari test. Gli output di questa fase sono i componenti della pipeline (pacchetti, eseguibili e artefatti) di cui verrà eseguito il deployment in una fase successiva.

  3. Distribuzione continua della pipeline: esegui il deployment degli artefatti prodotti dalla fase di CI nell'ambiente di destinazione. L'output di questa fase è una pipeline di cui è stato eseguito il deployment con la nuova implementazione del modello.

  4. Attivazione automatica: la pipeline viene eseguita automaticamente in produzione in base a una pianificazione o in risposta a un trigger. L'output di questa fase è un modello addestrato che viene inviato al registro dei modelli.

  5. Distribuzione continua del modello: il modello addestrato viene utilizzato come servizio di previsione per le previsioni. L'output di questa fase è un servizio di previsione del modello di cui è stato eseguito il deployment.

  6. Monitoraggio: raccogli statistiche sulle prestazioni del modello in base ai dati in tempo reale. L'output di questa fase è un trigger per eseguire la pipeline o per eseguire un nuovo ciclo di esperimenti.

La fase di analisi dei dati è ancora un processo manuale per i data scientist prima che la pipeline avvii una nuova iterazione dell'esperimento. Anche la fase di analisi del modello è un processo manuale.

Integrazione continua

In questa configurazione, la pipeline e i suoi componenti vengono creati, testati e pacchettizzati quando viene eseguito il commit o il push del nuovo codice nel repository di codice sorgente. Oltre alla creazione di pacchetti, immagini container ed eseguibili, il processo CI può includere i seguenti test:

  • Test delle unità della logica di feature engineering.

  • Test delle unità dei diversi metodi implementati nel modello. Ad esempio, hai una funzione che accetta una colonna di dati categorici e la codifichi come caratteristica one-hot.

  • Verifica che l'addestramento del modello converga (ovvero che la perdita del modello diminuisca con le iterazioni e che si verifichi l'overfitting di alcuni record di esempio).

  • Verificare che l'addestramento del modello non produca valori NaN a causa della divisione per zero o della manipolazione di valori piccoli o grandi.

  • Verifica che ogni componente della pipeline produca gli artefatti previsti.

  • Test dell'integrazione tra i componenti della pipeline.

Distribuzione continua

A questo livello, il sistema distribuisce continuamente nuove implementazioni della pipeline all'ambiente di destinazione che, a sua volta, fornisce servizi di previsione del modello appena addestrato. Per una distribuzione continua rapida e affidabile di pipeline e modelli, devi considerare quanto segue:

  • Verifica della compatibilità del modello con l'infrastruttura di destinazione prima di eseguire il deployment del modello. Ad esempio, devi verificare che i pacchetti richiesti dal modello siano installati nell'ambiente di gestione e che siano disponibili le risorse di memoria, calcolo e acceleratore richieste.

  • Test del servizio di previsione chiamando l'API del servizio con gli input previsti e assicurandoti di ottenere la risposta prevista. Questo test di solito rileva i problemi che potrebbero verificarsi quando aggiorni la versione del modello e questo si aspetta un input diverso.

  • Test delle prestazioni del servizio di previsione, che prevede il test di carico del servizio per acquisire metriche come query al secondo (QPS) e latenza del modello.

  • Convalida dei dati per l'addestramento o la previsione in batch.

  • Verifica che i modelli soddisfino i target di rendimento predittivo prima del deployment.

  • Deployment automatico in un ambiente di test, ad esempio un deployment attivato dal push del codice nel branch di sviluppo.

  • Deployment semiautomatico in un ambiente di pre-produzione, ad esempio un deployment attivato dall'unione del codice al branch principale dopo che i revisori hanno approvato le modifiche.

  • Deployment manuale in un ambiente di produzione dopo diverse esecuzioni riuscite della pipeline nell'ambiente di pre-produzione.

In sintesi, l'implementazione del ML in un ambiente di produzione non significa solo eseguire il deployment del modello come API per la previsione. Significa invece eseguire il deployment di una pipeline ML in grado di automatizzare l'addestramento e il deployment di nuovi modelli. La configurazione di un sistema CI/CD consente di testare ed eseguire automaticamente il deployment di nuove implementazioni della pipeline. Questo sistema ti consente di far fronte ai rapidi cambiamenti dei dati e dell'ambiente aziendale. Non è necessario spostare immediatamente tutti i processi da un livello all'altro. Puoi implementare gradualmente queste pratiche per migliorare l'automazione dello sviluppo e della produzione del tuo sistema ML.

Passaggi successivi

Collaboratori

Autori:

Altro collaboratore: Sunil Kumar Jang Bahadur | Customer Engineer