Questo documento illustra le tecniche per implementare e automatizzare l'integrazione continua (CI), la distribuzione continua (CD) e l'addestramento continuo (CT) per i sistemi di machine learning (ML).
Le data science e il machine learning stanno diventando funzionalità essenziali per risolvere problemi complessi e reali, trasformare i settori e fornire valore in tutti i domini. Al momento, hai a disposizione gli elementi per applicare un ML efficace:
- Set di dati di grandi dimensioni
- Risorse di calcolo on demand economiche
- Acceleratori specializzati per il machine learning su varie piattaforme cloud
- Rapidi progressi in diversi campi di ricerca ML (come visione artificiale, comprensione del linguaggio naturale e sistemi di AI per i suggerimenti).
Pertanto, molte aziende stanno investendo nei propri team di data science e nelle capacità di ML per sviluppare modelli predittivi in grado di fornire valore aziendale agli 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 ingegneria del ML che mira a unificare lo sviluppo di sistemi ML (Dev) e le operazioni di sistema di ML (Ops). Mettere in pratica le MLOps significa sostenere l'automazione e il monitoraggio in tutte le fasi della creazione di sistemi 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 di addestramento pertinenti per il proprio caso d'uso. La vera sfida, però, non è creare un modello ML, ma creare un sistema ML integrato e gestirlo in modo continuativo in produzione. Grazie alla lunga storia dei servizi ML di produzione di Google, abbiamo imparato che possono esserci molte insidie nell'utilizzo in produzione di sistemi basati su ML. Alcune di queste insidie sono riassunte in Machine Learning: la carta di credito ad alto interesse del debito tecnico.
Come mostrato nel seguente diagramma, solo una piccola parte di un sistema ML reale è composta dal codice ML. Gli elementi circostanti richiesti sono estesi e complessi.
Figura 1. Elementi per i sistemi ML. Adattato da Debito tecnico nascosto nei sistemi di machine learning.
In questo diagramma, il resto del sistema è composto da configurazione, automazione, raccolta dei dati, verifica dei dati, test e debug, gestione delle risorse, analisi del modello, gestione di processi e metadati, infrastruttura di gestione e 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 durante la configurazione di un ambiente MLOps per le pratiche di data science, come CI, CD e CT nel machine learning.
Vengono trattati i seguenti argomenti:
- DevOps e MLOps
- Passaggi per lo sviluppo dei modelli ML
- Livelli di maturità MLOps
DevOps e MLOps
DevOps è una pratica diffusa nello sviluppo e nella gestione di sistemi software su larga scala. Questa pratica offre vantaggi quali abbreviazione dei cicli di sviluppo, maggiore velocità di deployment e release affidabili. Per ottenere questi vantaggi, introduci due concetti nello sviluppo di sistemi software:
Un sistema ML è un sistema software, quindi si applicano pratiche simili per garantire di poter creare e gestire in modo affidabile sistemi ML su larga scala.
Tuttavia, i sistemi di ML differiscono da altri sistemi software per i seguenti aspetti:
Competenze del team: in un progetto ML, di solito il team include data scientist o ricercatori ML che si occupano di analisi esplorativa dei dati, sviluppo di modelli e sperimentazione. Questi membri potrebbero non essere ingegneri di software esperti in grado di creare servizi di produzione.
Sviluppo: il ML è di natura sperimentale. Ti consigliamo di provare diverse funzionalità, algoritmi, tecniche di modellazione e configurazioni di parametri per trovare ciò che funziona meglio per risolvere il problema il più rapidamente possibile. La sfida è tenere traccia di ciò che ha funzionato e di ciò che non ha funzionato e di mantenere la riproducibilità massimizzando al contempo la riusabilità del codice.
Test: il test di un sistema di ML è più impegnativo del test di altri sistemi software. Oltre ai test tipici delle unità e di integrazione, devi eseguire la convalida dei dati, la valutazione della qualità del modello addestrato e la convalida del modello.
Deployment: nei sistemi ML, il deployment non è semplice quanto eseguire il deployment di un modello ML addestrato offline come un servizio di previsione. I sistemi di ML possono richiedere il deployment di una pipeline in più fasi per riaddestrare e implementare automaticamente il modello. Questa pipeline aumenta complessità e richiede l'automazione dei passaggi che vengono eseguiti manualmente prima del deployment da parte dei data scientist per addestrare e convalidare nuovi modelli.
Produzione: i modelli di ML possono avere prestazioni ridotte non solo a causa di una programmazione non ottimale, ma anche a causa della costante evoluzione dei profili di dati. In altre parole, i modelli possono peggiorare in più modi rispetto ai sistemi software convenzionali ed è necessario considerare questo peggioramento. Pertanto, devi tenere traccia delle statistiche di riepilogo dei dati e monitorare le prestazioni online del modello per inviare notifiche o eseguire il rollback quando i valori si discostano dalle aspettative.
Il machine learning e altri sistemi software sono simili per quanto riguarda l'integrazione continua del controllo del codice sorgente, il test delle unità, il test di integrazione e la distribuzione continua del modulo software o del pacchetto. Tuttavia, nel ML esistono alcune differenze notevoli:
- CI non si limita più a testare e convalidare codice e componenti, ma anche testare e convalidare dati, schemi di dati e modelli.
- 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).
- CT è una nuova proprietà, unica dei sistemi ML, che si occupa di riaddestrare e pubblicare automaticamente i modelli.
La seguente sezione 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 l'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. Possono essere completate manualmente o tramite una pipeline automatica.
- Estrazione dati: selezioni e integri i dati pertinenti da varie origini dati per l'attività ML.
- Analisi dei dati: esegui un'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 dei dati e le caratteristiche previste dal modello.
- identificando la preparazione dei dati e il feature engineering necessari per il modello.
- Preparazione dei dati: i dati vengono preparati per l'attività ML. Questa preparazione prevede la pulizia dei dati, che prevede la suddivisione in set di addestramento, convalida e test. 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.
- 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 le prestazioni migliori. L'output di questo passaggio è un modello addestrato.
- Valutazione del modello: il modello viene valutato sulla base di un set di test di holdout per valutarne la qualità. L'output di questo passaggio è un insieme di metriche per valutare la qualità del modello.
- Convalida del modello: è stato confermato che il modello è adeguato per il deployment e che le sue prestazioni predittive sono migliori di una determinata base di riferimento.
- Pubblicazione del modello: viene eseguito il deployment del modello convalidato
in un ambiente di destinazione per fornire le previsioni. Questo deployment può essere uno dei seguenti:
- Microservizi con un'API REST per gestire le previsioni online.
- Un modello incorporato in un dispositivo perimetrale o mobile.
- Parte di un sistema di previsione batch.
- Monitoraggio del modello: le prestazioni predittive del modello vengono monitorate per richiamare una nuova iterazione nel processo ML.
Il livello di automazione di questi passaggi definisce la maturità del processo di ML, che riflette la velocità di addestramento di nuovi modelli con nuovi dati o di addestramento di nuovi modelli con nuove implementazioni. Le seguenti sezioni descrivono tre livelli di MLOps, a partire dal più comune, che non prevede automazione, fino all'automazione delle pipeline ML e CI/CD.
MLOps livello 0: processo manuale
Molti team dispongono di data scientist e ricercatori ML in grado di creare modelli all'avanguardia, ma il loro processo per la creazione e il deployment di modelli 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.
Figura 2. Passaggi di ML manuali per pubblicare il modello come servizio di previsione.
Caratteristiche
L'elenco seguente evidenzia le caratteristiche del processo MLOps di livello 0, come mostrato nella Figura 2:
Processo manuale, interattivo e basato su script: ogni passaggio è manuale e include analisi dei dati, preparazione dei dati, addestramento del modello e convalida. Richiede l'esecuzione manuale di ogni passaggio e la transizione manuale da un passaggio all'altro. Questo processo è in genere guidato da un codice sperimentale scritto ed eseguito nei blocchi note da data scientist in modo interattivo, fino a quando non viene generato un modello attuabile.
Disconnessione tra ML e operazioni: il processo separa i data scientist che creano il modello e gli ingegneri che lo utilizzano come servizio di previsione. I data scientist consegnano come artefatto un modello addestrato al team di tecnici, che lo distribuirà sull'infrastruttura API. Questo trasferimento può includere il posizionamento del modello addestrato in una posizione di archiviazione, il controllo dell'oggetto del modello in un repository di codice o il caricamento in un registro dei modelli. Quindi, gli ingegneri che eseguono il deployment del modello devono rendere disponibili in produzione le caratteristiche richieste per la pubblicazione a bassa latenza, il che può portare a un disallineamento addestramento/distribuzione.
Iterazioni di rilascio poco frequenti: il processo presuppone che il team di data science gestisca alcuni modelli che non cambiano di frequente, ad esempio cambiando l'implementazione del modello o riaddestrando il modello con nuovi dati. Il deployment di una nuova versione del modello viene eseguito solo un paio di volte all'anno.
Nessuna CI: poiché si presume che vengano apportate poche modifiche di implementazione, CI viene ignorata. In genere, il test del codice fa parte dei blocchi note o dell'esecuzione dello script. Gli script e i blocchi note che implementano i passaggi dell'esperimento sono controllati dall'origine e producono artefatti come modelli addestrati, metriche di valutazione e visualizzazioni.
Nessuna distribuzione continua: poiché non vengono eseguiti di frequente deployment delle versioni del modello, CD non viene presa 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 o registra le previsioni e le azioni del modello, necessarie per rilevare un peggioramento delle prestazioni del modello e altre deviazioni comportamentali del modello.
Il team di tecnici potrebbe avere una propria configurazione complessa per la configurazione, il test e il deployment delle API, inclusi test di sicurezza, regressione, carico e test 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 gestisca tutto il traffico delle richieste di previsione.
Sfide
Il livello MLOps 0 è comune in molte aziende che stanno iniziando ad applicare il ML ai propri casi d'uso. Questo processo manuale basato sui data scientist può essere sufficiente quando i modelli vengono modificati o addestrati raramente. In pratica, i modelli spesso si rompono quando vengono implementati nel mondo reale. I modelli non si adattano alle variazioni delle dinamiche dell'ambiente o alle modifiche dei dati che descrivono l'ambiente. Per ulteriori informazioni, consulta Why Machine Learning Models Crash and Burn in Production.
Per affrontare queste sfide e mantenere l'accuratezza del modello in produzione, devi fare quanto segue:
Monitora attivamente la qualità del modello in produzione: il monitoraggio consente di rilevare un peggioramento delle prestazioni e l'inattività del modello. Agisce da spunto per una nuova iterazione di sperimentazione e riaddestramento (manuale) del modello con nuovi dati.
Riaddestrare frequentemente 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 il machine learning, i suoi consigli dovrebbero adattarsi alle ultime tendenze e agli ultimi prodotti.
Sperimenta continuamente nuove implementazioni per produrre il modello: per sfruttare le idee più recenti e i progressi tecnologici, devi sperimentare nuove implementazioni come il feature engineering, l'architettura del modello e gli iperparametri. Ad esempio, se utilizzi la visione artificiale per il rilevamento dei volti, le sequenze del volto vengono risolte, ma nuove tecniche migliori possono migliorare la precisione del rilevamento.
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 CT e configurare un sistema CI/CD per testare, creare ed eseguire rapidamente il deployment di nuove implementazioni della pipeline ML. Queste funzionalità saranno discusse più in dettaglio nelle sezioni successive.
MLOps livello 1: automazione delle pipeline ML
L'obiettivo del livello 1 è eseguire l'addestramento continuo del modello mediante l'automazione della pipeline ML, in modo da 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 i dati automatizzati e i passaggi di convalida dei modelli, nonché i trigger della pipeline e la gestione dei metadati.
La figura seguente è una rappresentazione schematica di una pipeline ML automatizzata per CT.
Figura 3. Automazione delle pipeline ML per CT.
Caratteristiche
L'elenco seguente evidenzia le caratteristiche della configurazione del livello 1 di MLOps, come mostrato nella Figura 3:
Esperimento rapido: le fasi dell'esperimento ML sono orchestrate. La transizione tra le fasi è automatizzata, il che porta a un'iterazione rapida degli esperimenti e a una migliore preparazione per portare l'intera pipeline in produzione.
CT del modello in produzione: il modello viene addestrato automaticamente in produzione utilizzando dati aggiornati in base agli attivatori della pipeline in tempo reale, descritti nella sezione successiva.
Simmetria sperimentale-operativa: l'implementazione della pipeline utilizzata nell'ambiente di sviluppo o esperimento viene utilizzata nell'ambiente di preproduzione e 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, anche se il codice EDA può ancora essere inserito nei blocchi note, il codice sorgente dei componenti deve essere modularizzato. Inoltre, i componenti idealmente dovrebbero essere containerizzati per fare quanto segue:
- Disaccoppia l'ambiente di esecuzione dal runtime del codice personalizzato.
- Rendi il codice riproducibile in ambienti di sviluppo e 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 di modelli: una pipeline ML in produzione fornisce servizi di previsione a nuovi modelli addestrati su nuovi dati. Il passaggio di deployment del modello, che utilizza il modello addestrato e convalidato come servizio di previsione per le previsioni online, è automatizzato.
Deployment della pipeline: nel livello 0, esegui il deployment in produzione di un modello addestrato come servizio di previsione. Per il livello 1, esegui il deployment di un'intera pipeline di addestramento, che viene eseguita automaticamente e periodicamente per fornire il modello addestrato come servizio di previsione.
Componenti aggiuntivi
Questa sezione illustra i componenti da aggiungere all'architettura per consentire l'addestramento continuo del machine learning.
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 si aspetta che nuovi dati in tempo reale producano una nuova versione del modello che venga addestrata sui nuovi dati (come mostrato nella Figura 3). Pertanto, nella pipeline di produzione sono richieste fasi automatizzate di convalida dei dati e convalida del modello per garantire il seguente comportamento previsto:
Convalida dei dati: questo passaggio è obbligatorio 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 identifica i seguenti elementi.
- Disallineamento dello schema dei dati: questi disallineamenti sono considerati anomalie nei dati di input, il che significa che i passaggi della pipeline downstream, tra cui l'elaborazione dei dati e l'addestramento dei modelli, ricevono dati non conformi allo schema previsto. In questo caso, devi arrestare la pipeline in modo che il team di data science possa analizzare. Il team potrebbe rilasciare una correzione o un aggiornamento della pipeline per gestire queste modifiche allo schema. I disallineamenti dello schema includono la ricezione di caratteristiche impreviste, la non ricezione di tutte le caratteristiche previste o la ricezione di caratteristiche con valori imprevisti.
- Disallineamento dei valori dei dati: questi disallineamenti sono cambiamenti significativi nelle proprietà statistiche dei dati, il che significa che i pattern di dati stanno cambiando e che è necessario attivare un riaddestramento del modello per acquisire queste modifiche.
Convalida del modello: questo passaggio si verifica dopo che hai addestrato correttamente il modello con i nuovi dati. Devi valutare e convalidare il modello prima che venga promosso in produzione. Questo passaggio di convalida del modello offline è costituito dai seguenti passaggi.
- Produzione dei 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, modello di produzione, modello di base o altri modelli di requisiti aziendali. Prima di promuoverlo in produzione, assicurati che il nuovo modello produca prestazioni migliori rispetto al modello attuale.
- Assicurarsi che le prestazioni del modello siano coerenti su vari segmenti di dati. Ad esempio, il modello di abbandono dei clienti appena addestrato potrebbe produrre un'accuratezza predittiva migliore complessiva rispetto al modello precedente, ma i valori di accuratezza per regione del cliente potrebbero avere una grande variazione.
- Assicurati di testare il modello per il deployment, includendo la compatibilità dell'infrastruttura e la coerenza con l'API del servizio di previsione.
Oltre alla convalida del modello offline, un modello appena distribuito viene sottoposto a convalida del modello online, in un deployment canary o in una configurazione di test A/B, prima di fornire la previsione per il traffico online.
Archivio di caratteristiche
Un componente aggiuntivo facoltativo per l'automazione della pipeline ML di livello 1 è un feature store. Un archivio di caratteristiche è un repository centralizzato in cui standardzzi la definizione, l'archiviazione e l'accesso delle caratteristiche per l'addestramento e la pubblicazione. Un archivio di caratteristiche deve fornire un'API sia per la distribuzione in batch ad alta velocità effettiva che per la gestione in tempo reale a bassa latenza per i valori delle caratteristiche, nonché per supportare i carichi di lavoro di addestramento e gestione.
Il Feature Store aiuta i data scientist a:
- Rileva e riutilizza i set di caratteristiche disponibili per le rispettive entità, anziché ricreare gli stessi set o crearne di simili.
- Evita di avere caratteristiche simili con definizioni diverse mantenendo le caratteristiche e i relativi metadati.
- Pubblica valori di caratteristiche aggiornati dal Feature Store.
Evita il disallineamento addestramento/distribuzione utilizzando il Feature Store come origine dati per la sperimentazione, l'addestramento continuo e la distribuzione online. Questo approccio fa in modo che le caratteristiche utilizzate per l'addestramento siano le stesse usate durante la distribuzione:
- Per la sperimentazione, i data scientist possono ottenere un'estrazione offline dal Feature Store.
- Per l'addestramento continuo, la pipeline di addestramento ML automatizzata può recuperare un batch di 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 un batch i valori delle caratteristiche relative all'entità richiesta, come le caratteristiche demografiche dei clienti, le caratteristiche del prodotto e le caratteristiche di aggregazione delle sessioni correnti.
Gestione dei metadati
Le informazioni su ciascuna esecuzione della pipeline ML vengono registrate per facilitare la derivazione, la riproducibilità e i confronti di dati e artefatti. Aiuta anche a eseguire il debug di errori e anomalie. Ogni volta che esegui la pipeline, l'archivio di metadati ML registra i seguenti metadati:
- Le versioni della pipeline e dei componenti che sono state eseguite.
- La data di inizio e di fine, l'ora e il tempo impiegato dalla pipeline per completare ciascun passaggio.
- L'esecutore della pipeline.
- Gli argomenti dei parametri passati alla pipeline.
- I puntatori agli artefatti prodotti da ogni passaggio della pipeline, ad esempio 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 consente di riprendere la pipeline dal passaggio più recente se la pipeline si è arrestata 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 la fase di convalida del modello.
- Le metriche di valutazione del modello prodotte durante la fase di valutazione del modello sia per il set di addestramento che per quello di test. Queste metriche consentono di confrontare le prestazioni di un modello appena addestrato con le prestazioni 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 di modifica dei pattern di dati e da quanto è costoso riaddestrare i 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 nuovi dati vengono raccolti e resi disponibili nei database di origine.
- Al peggioramento delle prestazioni del modello: il modello viene riaddestrato quando si verifica un peggioramento notevole delle prestazioni.
- Su cambiamenti significativi nelle distribuzioni dei dati (deviazione concettuale). È difficile valutare le prestazioni complete del modello online, ma si notano cambiamenti significativi nelle distribuzioni dei dati delle caratteristiche utilizzate per eseguire la previsione. Queste modifiche suggeriscono che il modello non è più aggiornato e che è necessario riaddestrarlo con dati aggiornati.
Sfide
Supponendo che il deployment di nuove implementazioni della pipeline non venga eseguito di frequente e che tu gestisca solo poche pipeline, di solito testerai manualmente la pipeline e i relativi componenti. Inoltre, esegui il deployment manuale delle nuove implementazioni della pipeline. Invierai anche il codice sorgente testato per la pipeline al team IT, che ne eseguirà 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 per il machine learning ed eseguire rapidamente il deployment di nuove implementazioni dei componenti ML. Se gestisci molte pipeline ML in produzione, ti serve una configurazione CI/CD per automatizzare la creazione, il test e il deployment delle pipeline ML.
MLOps livello 2: automazione delle pipeline CI/CD
Per un aggiornamento rapido e affidabile delle pipeline in produzione, è necessario un sistema CI/CD automatizzato e solido. Questo sistema CI/CD automatizzato consente ai data scientist di esplorare rapidamente nuove idee sul feature engineering, sull'architettura dei modelli e sugli 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 e le routine CI/CD automatizzate.
Figura 4. CI/CD e pipeline ML automatizzata.
Questa configurazione delle MLOps include i seguenti componenti:
- Controllo del codice sorgente
- Servizi di test e creazione
- Servizi di deployment
- Registro dei modelli
- Archivio di caratteristiche
- Archivio di metadati ML
- Agente di orchestrazione pipeline ML
Caratteristiche
Il seguente diagramma mostra le fasi della pipeline di automazione CI/CD ML:
Figura 5. Fasi della pipeline ML automatizzata CI/CD.
La pipeline prevede le seguenti fasi:
Sviluppo e sperimentazione: provi iterativamente nuovi algoritmi ML e nuovi modelli di modellazione in cui vengono orchestrati i passaggi dell'esperimento. L'output di questa fase è il codice sorgente dei passaggi della pipeline ML che vengono quindi inviati a un repository di codice sorgente.
Integrazione continua della pipeline: tu crei il codice sorgente ed esegui vari test. Gli output di questa fase sono i componenti della pipeline (pacchetti, eseguibili e artefatti) di cui eseguire il deployment in una fase successiva.
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 del modello.
Trigger automatico: 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 di cui viene eseguito il push nel registro del modello.
Distribuzione continua del modello: fornisci il modello addestrato come servizio di previsione per le previsioni. L'output di questa fase è un servizio di previsione del modello di cui è stato eseguito il deployment.
Monitoraggio: raccogli le statistiche sulle prestazioni del modello in base ai dati in tempo reale. L'output di questa fase è un trigger per eseguire la pipeline o un nuovo ciclo dell'esperimento.
La fase di analisi dei dati è ancora un processo manuale per i data scientist prima che la pipeline inizi 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 di nuovo codice o ne viene eseguito il push nel repository di codice sorgente. Oltre a creare pacchetti, immagini container ed eseguibili, il processo CI può includere i seguenti test:
Test dell'unità della logica del feature engineering.
Test dell'unità dei diversi metodi implementati nel tuo modello. Ad esempio, se hai una funzione che accetta una colonna di dati categorici, codifichi la funzione come caratteristica one-hot.
Testare la convergenza dell'addestramento del modello (ovvero, la perdita del modello dipende da iterazioni e supera alcuni record di esempio).
Testa che l'addestramento del modello non produce valori NaN a causa della divisione per zero o della manipolazione di valori piccoli o grandi.
Testando ogni componente della pipeline produrre gli artefatti previsti.
Test dell'integrazione tra i componenti della pipeline.
Distribuzione continua
A questo livello, il sistema fornisce continuamente nuove implementazioni della pipeline nell'ambiente di destinazione, che a sua volta fornisce servizi di previsione del modello appena addestrato. Per una distribuzione continua e rapida affidabile di pipeline e modelli, considera quanto segue:
Verifica la compatibilità del modello con l'infrastruttura di destinazione prima di eseguirne il deployment. Ad esempio, devi verificare che i pacchetti richiesti dal modello siano installati nell'ambiente di pubblicazione e che siano disponibili le risorse richieste di memoria, calcolo e acceleratore.
Testa il servizio di previsione chiamando l'API del servizio con gli input previsti e assicurandoti di ottenere la risposta prevista. Questo test di solito acquisisce i problemi che potrebbero verificarsi quando aggiorni la versione del modello e prevede un input diverso.
Testare le prestazioni del servizio di previsione, che prevede la verifica di carico del servizio per acquisire metriche come le query al secondo (QPS) e la latenza del modello.
Convalida dei dati per il riaddestramento o la previsione batch.
È necessario verificare che i modelli soddisfino i target di rendimento predittivi prima del deployment.
Deployment automatico in un ambiente di test, ad esempio un deployment che viene attivato eseguendo il push del codice al ramo di sviluppo.
Deployment semi-automatico in un ambiente di pre-produzione, ad esempio un deployment che viene attivato unendo il codice al ramo principale dopo l'approvazione delle modifiche da parte dei revisori.
Il deployment manuale in un ambiente di produzione dopo diverse esecuzioni riuscite della pipeline nell'ambiente di pre-produzione.
Per riassumere, implementare il machine learning in un ambiente di produzione non significa solo eseguire il deployment del modello come API per la previsione. Vuol dire il deployment di una pipeline ML in grado di automatizzare il riaddestramento e il deployment di nuovi modelli. La configurazione di un sistema CI/CD ti consente di testare ed eseguire automaticamente il deployment di nuove implementazioni di pipeline. Questo sistema ti consente di affrontare cambiamenti rapidi nei dati e nell'ambiente aziendale. Non devi spostare immediatamente tutti i processi da un livello all'altro. Puoi implementare queste pratiche in modo graduale per migliorare l'automazione dello sviluppo e della produzione di sistemi ML.
Passaggi successivi
- Scopri di più sull'architettura per MLOps con TensorFlow Extended, Vertex AI Pipelines e Cloud Build.
- Scopri di più sulla guida pratica del machine learning alle operazioni di machine learning (MLOps).
- Scopri di più sulla configurazione di una pipeline CI/CD per il flusso di lavoro di elaborazione dati.
- Guarda le best practice MLOps su Google Cloud (Cloud Next '19) su YouTube.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.