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).
La data science e il machine learning stanno diventando funzionalità fondamentali per risolvere problemi del mondo reale complessi, trasformare settori e fornire valore in tutti i domini. Attualmente, hai a disposizione gli ingredienti 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 suggerimenti).
Pertanto, molte aziende stanno investendo nei propri team di data science e nelle loro capacità di ML per sviluppare modelli predittivi in grado di fornire valore aziendale ai loro utenti.
Questo documento è rivolto a data scientist e ML engineer che vogliono applicare i principi delle DevOps ai sistemi ML (MLOps). MLOps è una cultura e una pratica di ingegneria ML che mira a unificare lo sviluppo di sistemi ML (Dev) e le operazioni su sistemi ML (Ops). Praticare MLOps significa promuovere l'automazione e il monitoraggio in tutte le fasi della creazione di un sistema ML, tra cui l'integrazione, i test, il rilascio, il deployment e la gestione dell'infrastruttura.
I data scientist possono implementare e addestrare un modello ML con prestazioni predittive su un set di dati di holdout offline, sulla base dei dati di addestramento pertinenti per il loro caso d'uso. Tuttavia, la vera sfida non è la creazione di un modello ML, ma la creazione di un sistema ML integrato e il suo funzionamento continuo in produzione. Con la lunga storia di servizi ML di produzione di Google, abbiamo imparato che possono verificarsi molte insidie nell'utilizzo di sistemi basati su ML in produzione. 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 immensi e complessi.
Figura 1. Elementi per i sistemi ML. Adattamento di 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 dei modelli, gestione di processi e metadati, infrastruttura di pubblicazione 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 quando configuri un ambiente MLOps per le tue pratiche di data science, come CI, CD e CT nel ML.
Vengono trattati i seguenti argomenti:
- DevOps e MLOps
- Passaggi per lo sviluppo di 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 come l'accorciamento dei cicli di sviluppo, l'aumento della velocità di deployment e l'affidabilità delle release. 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 la creazione e la gestione affidabili di sistemi ML su larga scala.
Tuttavia, i sistemi di ML differiscono da altri sistemi software per i seguenti aspetti:
Competenze in 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 produzione.
Sviluppo: il machine learning è di natura sperimentale. Prova diverse funzionalità, algoritmi, tecniche di modellazione e configurazioni di parametri per trovare quello che funziona meglio per il problema il prima possibile. La sfida consiste nel monitorare cosa ha funzionato e cosa no e mantenere la riproducibilità massimizzando al contempo la riusabilità del codice.
Test: eseguire test su un sistema di machine learning è più impegnativo che testarne altri sistemi software. Oltre ai tipici test di unità e integrazione, sono necessari la convalida dei dati, la valutazione della qualità del modello addestrato e la convalida del modello.
Distribuzione: nei sistemi ML, il deployment non è semplice quanto il deployment di un modello ML addestrato offline quanto un servizio di previsione. I sistemi di ML possono richiedere il deployment di una pipeline in più passaggi per riaddestrare ed eseguire automaticamente il deployment del modello. Questa pipeline aumenta la complessità e richiede l'automazione dei passaggi eseguiti manualmente prima del deployment da parte dei data scientist per addestrare e convalidare nuovi modelli.
Produzione: i modelli ML possono avere prestazioni ridotte 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 decadere in più modi rispetto ai sistemi software convenzionali e devi tenere conto di questo peggioramento. Devi quindi tenere traccia delle statistiche riepilogative dei dati e monitorare le prestazioni online del modello per inviare notifiche o eseguire il rollback quando i valori differiscono dalle tue aspettative.
Il machine learning e altri sistemi software sono simili per quanto riguarda l'integrazione continua di controllo del codice sorgente, test delle unità, test di integrazione e distribuzione continua del modulo software o del pacchetto. Tuttavia, nel ML ci sono alcune importanti differenze:
- La CI non si limita più a testare e convalidare codice e componenti, ma anche a testare e convalidare 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 dovrebbe eseguire automaticamente il deployment di un altro servizio (servizio di previsione del modello).
- CT è una nuova proprietà, unica per i 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 usare come servizio di previsione.
Passaggi di data science per il ML
In qualsiasi progetto ML, dopo aver definito il caso d'uso aziendale e stabilito i criteri di successo, il processo di distribuzione di un modello ML in produzione prevede i seguenti passaggi. Questi passaggi possono essere completati manualmente o da una pipeline automatica.
- Estrazione dei dati: si selezionano e si integrano i dati rilevanti da varie origini dati per l'attività ML.
- Analisi dei dati: esegui l'analisi esplorativa dei dati (EDA) per comprendere i dati disponibili per la creazione del modello ML. Questa procedura comporta quanto segue:
- Comprendere lo schema di dati e le caratteristiche previste dal modello.
- identificazione della preparazione dei dati e del feature engineering necessarie al modello.
- Preparazione dei dati: i dati sono preparati per l'attività di ML. Questa preparazione prevede la pulizia dei dati, che li suddividono in set di addestramento, convalida e test. Applicherai inoltre 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 di modelli: i data scientist implementano 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 su 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 previsioni. Questo deployment può essere uno dei seguenti:
- Microservizi con un'API REST per fornire previsioni online.
- Un modello incorporato in un perimetro o in un dispositivo mobile.
- Parte di un sistema di previsione batch.
- Monitoraggio del modello: le prestazioni predittive del modello vengono monitorate per richiamare potenzialmente 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 in base alle nuove implementazioni. Le seguenti sezioni descrivono tre livelli di MLOps, a partire dal livello più comune, che non prevede alcuna automazione, fino all'automazione delle pipeline ML e CI/CD.
MLOps livello 0: processo manuale
Molti team hanno data scientist e ricercatori ML che possono creare modelli all'avanguardia, ma il loro processo per la creazione e il deployment di modelli ML è interamente manuale. Questo è considerato il livello di maturità di base o 0. Il seguente diagramma mostra il flusso di lavoro di questa procedura.
Figura 2. Passaggi ML manuali per gestire 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, incluse analisi dei dati, preparazione dei dati, addestramento dei modelli e convalida. Richiede l'esecuzione manuale di ogni passaggio e la transizione manuale da un passaggio all'altro. Questo processo di solito è basato su codice sperimentale che viene scritto ed eseguito nei blocchi note da data scientist in modo interattivo, fino a quando non viene prodotto un modello utilizzabile.
Disconnessione tra ML e operazioni: il processo separa i data scientist che creano il modello e gli ingegneri che gestiscono il modello come servizio di previsione. I data scientist consegnano un modello addestrato come artefatto al team di tecnici per il deployment della loro 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. Poi, gli ingegneri che eseguono il deployment del modello devono rendere disponibili in produzione le funzionalità necessarie per la gestione a bassa latenza, il che può portare a un disallineamento addestramento/produzione.
Iterazioni di release non frequenti: il processo presuppone che il team di data science gestisca alcuni modelli che non cambiano spesso, 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.
Nessun CI: poiché vengono presupposte poche modifiche di implementazione, la 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 dal codice sorgente e producono artefatti come modelli addestrati, metriche di valutazione e visualizzazioni.
Nessun CD: poiché non esistono frequenti deployment delle versioni dei modelli, la CD non viene considerata.
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), piuttosto che il deployment dell'intero sistema di ML.
Mancanza di monitoraggio attivo delle prestazioni: il processo non tiene traccia né registra le previsioni e le azioni del modello, necessarie per rilevare il deterioramento delle prestazioni del modello e altre deviazioni di comportamento del modello.
Il team di tecnici potrebbe avere una propria configurazione complessa per la configurazione, i test e il deployment delle API, inclusi sicurezza, regressione e test di carico e canary. Inoltre, il deployment in produzione di una nuova versione di un modello ML solitamente passa attraverso test A/B o esperimenti online prima che il modello venga promosso per gestire tutto il traffico delle richieste di previsione.
sfide
MLOps livello 0 è comune in molte aziende che stanno iniziando ad applicare il ML ai propri casi d'uso. Questo processo manuale basato su data scientist potrebbe essere sufficiente quando i modelli vengono addestrati raramente o vengono addestrati. In pratica, i modelli spesso non funzionano quando ne viene eseguito il deployment nel mondo reale. I modelli non riescono ad adattarsi ai cambiamenti nelle dinamiche dell'ambiente o ai cambiamenti dei dati che descrivono l'ambiente. Per scoprire di più, consulta la pagina Perché i modelli di machine learning si arrestano in modo anomalo e si bruciano in produzione.
Per affrontare queste sfide e mantenere la precisione del modello in produzione, devi fare quanto segue:
Monitora attivamente la qualità del tuo modello in produzione: il monitoraggio consente di rilevare il peggioramento delle prestazioni e il mancato aggiornamento del modello. Funge da segnale di una nuova iterazione di sperimentazione e di un riaddestramento (manuale) del modello sulla base di nuovi dati.
Riaddestra spesso i tuoi 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 ai prodotti più recenti.
Sperimenta continuamente nuove implementazioni per produrre il modello: per sfruttare le ultime idee e i progressi tecnologici, devi provare nuove implementazioni come feature engineering, architettura dei modelli e iperparametri. Ad esempio, se utilizzi la visione artificiale per il rilevamento dei volti, le sequenze dei volti vengono corrette, ma nuove tecniche migliori possono migliorare l'accuratezza del rilevamento.
Per affrontare le sfide di questo processo manuale, le pratiche MLOps per CI/CD e CT sono utili. Eseguendo il deployment di una pipeline di addestramento ML, puoi abilitare CT e configurare un sistema CI/CD per testare, creare ed eseguire il deployment di nuove implementazioni della pipeline ML in modo rapido. Queste funzionalità sono trattate in modo più dettagliato nelle sezioni successive.
MLOps livello 1: automazione delle 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 dei modelli. Per automatizzare il processo di utilizzo di nuovi dati per riaddestrare i modelli in produzione, devi introdurre dati automatizzati e passaggi di convalida dei modelli nella pipeline, nonché trigger della pipeline e gestione dei metadati.
La figura seguente è una rappresentazione schematica di una pipeline ML automatizzata per CT.
Figura 3. Automazione della pipeline ML per il CT.
Caratteristiche
Il seguente elenco evidenzia le caratteristiche della configurazione di MLOps livello 1, come mostrato nella Figura 3:
Esperimento rapido: i passaggi dell'esperimento ML sono orchestrati. La transizione tra i passaggi è automatizzata, il che porta a un'iterazione rapida degli esperimenti e a una migliore preparazione per spostare l'intera pipeline in produzione.
CT del modello in produzione: il modello viene addestrato automaticamente in produzione utilizzando dati aggiornati basati su trigger di pipeline in tempo reale, descritti nella sezione successiva.
Simmetria sperimentale-operativa: l'implementazione della pipeline utilizzata nell'ambiente di sviluppo o di esperimento viene utilizzata nell'ambiente di preproduzione e produzione, che è un aspetto chiave della pratica MLOps per unificare le DevOps.
Codice modulare per componenti e pipeline: per creare pipeline ML, i componenti devono essere riutilizzabili, componibili e potenzialmente condivisibili nelle pipeline ML. Pertanto, anche se il codice EDA può ancora essere presente nei blocchi note, il codice sorgente dei componenti deve essere modularizzato. Inoltre, i componenti dovrebbero essere idealmente containerizzati per eseguire le seguenti operazioni:
- Disaccoppia l'ambiente di esecuzione dal runtime del codice personalizzato.
- Rendere il codice riproducibile tra ambienti di sviluppo e produzione.
- Isolare ogni componente della pipeline. I componenti possono avere la propria versione dell'ambiente di runtime, linguaggi e librerie diversi.
Distribuzione continua di modelli: una pipeline ML in produzione fornisce continuamente servizi di previsione a nuovi modelli addestrati su nuovi dati. La fase di deployment del modello, che fornisce il modello addestrato e convalidato come servizio di previsione per le previsioni online, è automatizzato.
Deployment della pipeline: al 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 periodicamente per fornire il modello addestrato come servizio di previsione.
Componenti aggiuntivi
Questa sezione illustra i componenti da aggiungere all'architettura per abilitare l'addestramento continuo ML.
Convalida di dati e modelli
Quando esegui il deployment della tua pipeline ML in produzione, uno o più trigger discussi nella sezione Trigger della pipeline ML eseguono automaticamente la pipeline. La pipeline prevede che i nuovi dati in tempo reale producano una nuova versione del modello che viene addestrata sui nuovi dati (come mostrato nella Figura 3). Pertanto, nella pipeline di produzione, sono necessari passaggi automatizzati per la convalida dei dati e la 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.
- Disallineamento dello schema dei dati: queste disallineamenti sono considerate 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 effettuare accertamenti. Il team potrebbe rilasciare una correzione o un aggiornamento alla pipeline per gestire queste modifiche allo schema. Le disallineamenti dello schema includono la ricezione di funzionalità impreviste, la mancata ricezione di tutte le funzionalità previste o la ricezione di funzionalità con valori imprevisti.
- Disallineamento dei valori dei dati: queste disallineamenti sono cambiamenti significativi nelle proprietà statistiche dei dati, il che significa che i pattern dei dati stanno cambiando ed è necessario attivare un riaddestramento del modello per acquisire queste modifiche.
Convalida del modello: questo passaggio si verifica dopo aver completato l'addestramento del modello in base ai nuovi dati. Devi valutare e convalidare il modello prima che venga promosso in produzione. Questo passaggio di convalida del modello offline è costituito da quanto segue.
- Produrre 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 passare alla produzione, ti assicuri che il nuovo modello produca prestazioni migliori rispetto al modello attuale.
- Assicurarsi che le prestazioni del modello siano coerenti su vari segmenti dei dati. Ad esempio, il modello di abbandono dei clienti appena addestrato potrebbe produrre una precisione predittiva complessiva migliore rispetto al modello precedente, ma i valori di accuratezza per area geografica del cliente potrebbero variare notevolmente.
- Assicurati 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 un test A/B) prima di fornire previsioni 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 standardizza la definizione, l'archiviazione e l'accesso delle caratteristiche per l'addestramento e la pubblicazione. Un archivio di caratteristiche deve fornire un'API per la pubblicazione in batch ad alta velocità effettiva e per la gestione in tempo reale a bassa latenza dei valori delle caratteristiche, oltre a supportare i carichi di lavoro di addestramento e gestione.
Il Feature Store aiuta i data scientist a:
- Scoprire e riutilizzare i set di caratteristiche disponibili per le loro entità, invece di ricreare, uguali o simili.
- Evita di avere funzionalità simili con definizioni diverse mantenendo le caratteristiche e i relativi metadati.
- Pubblica valori aggiornati delle caratteristiche dal Feature Store.
Evita il disallineamento addestramento/produzione utilizzando il Feature Store come origine dati per la sperimentazione, l'addestramento continuo e la pubblicazione online. Questo approccio garantisce che le funzionalità utilizzate per l'addestramento siano le stesse utilizzate durante la pubblicazione:
- Per la sperimentazione, i data scientist possono recuperare un'estrazione offline dal Feature Store ed eseguire gli esperimenti.
- Per l'addestramento continuo, la pipeline di addestramento ML automatizzato può recuperare un batch dei valori aggiornati delle funzionalità del set di dati utilizzati per l'attività di addestramento.
- Per la previsione online, il servizio di previsione può recuperare un batch dei valori delle funzionalità relativi all'entità richiesta, ad esempio funzionalità demografiche dei clienti, funzionalità di prodotto e funzionalità di aggregazione della sessione corrente.
Gestione dei metadati
Le informazioni su ogni esecuzione della pipeline ML vengono registrate per agevolare 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 dei metadati ML registra i seguenti metadati:
- Le versioni della pipeline e dei componenti eseguite.
- La data di inizio e di fine, l'ora e il tempo impiegato dalla pipeline per completare ogni passaggio.
- 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 funzionalità categoriche. Il monitoraggio di questi output intermedi ti aiuta a riprendere la pipeline dal passaggio più recente se 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 generare 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 i set di addestramento che per quelli di test. Queste metriche ti consentono di confrontare le prestazioni di un modello appena addestrato con quelle registrate del modello precedente durante la fase di convalida del modello.
Trigger della 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 disponibili sistematicamente per il sistema di ML su base giornaliera, settimanale o mensile. La frequenza di riaddestramento dipende anche dalla frequenza con cui i pattern dei dati cambiano e da quanto costa riaddestrare i modelli.
- Al momento della disponibilità di nuovi dati di addestramento: i nuovi dati non sono sistematicamente disponibili per il sistema di ML, ma sono invece disponibili su base ad hoc quando i nuovi dati vengono raccolti e resi disponibili nei database di origine.
- Al degrado delle prestazioni del modello: il modello viene riaddestrato quando si verifica un peggioramento delle prestazioni evidente.
- In caso di cambiamenti significativi nelle distribuzioni dei dati (deviazione del concetto). È difficile valutare le prestazioni complete del modello online, ma noti cambiamenti significativi nelle distribuzioni dei dati delle caratteristiche utilizzate per eseguire la previsione. Queste modifiche suggeriscono che il modello non è più aggiornato e che deve essere riaddestrato con dati aggiornati.
sfide
Supponendo che il deployment di nuove implementazioni della pipeline non venga eseguito di frequente e che tu stia gestendo solo poche pipeline, in genere verifichi manualmente la pipeline e i relativi componenti. Inoltre, esegui manualmente il deployment di nuove implementazioni delle pipeline. Devi inoltre inviare al team IT il codice sorgente testato per la pipeline in modo che venga implementato nell'ambiente di destinazione. Questa configurazione è adatta al deployment di nuovi modelli basati su nuovi dati piuttosto che su nuove idee ML.
Tuttavia, devi provare nuove idee ML ed eseguire rapidamente il deployment di nuove implementazioni dei componenti ML. Se gestisci molte pipeline ML in produzione, devi eseguire 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, hai bisogno di un solido sistema CI/CD automatizzato. Questo sistema CI/CD automatizzato consente ai tuoi data scientist di esplorare rapidamente nuove idee su feature engineering, architettura dei modelli e iperparametri. Possono implementare queste idee e creare, testare ed eseguire il deployment dei nuovi componenti della pipeline nell'ambiente di destinazione.
Il seguente diagramma mostra l'implementazione della pipeline ML utilizzando CI/CD, che presenta le caratteristiche della configurazione delle pipeline ML automatizzate oltre alle routine CI/CD automatizzate.
Figura 4. Pipeline CI/CD e ML automatizzata.
Questa configurazione 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
- Orchestratore di pipeline ML
Caratteristiche
Il seguente diagramma mostra le fasi della pipeline di automazione ML CI/CD:
Figura 5. Fasi della pipeline ML automatizzata CI/CD.
La pipeline è costituita dalle seguenti fasi:
Sviluppo e sperimentazione: proverai iterativamente nuovi algoritmi ML e una nuova definizione del modello in cui i passaggi dell'esperimento vengono orchestrati. 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: crei il codice sorgente ed esegui vari test. Gli output di questa fase sono 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 con la nuova implementazione 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 che viene inviato al registro dei modelli.
Distribuzione continua del modello: fornisci il modello addestrato come servizio di previsione per le previsioni. L'output di questa fase è un servizio di previsione dei modelli di cui è stato eseguito il deployment.
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 eseguire un nuovo ciclo di esperimento.
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 il passaggio di analisi del modello è un processo manuale.
Integrazione continua
In questa configurazione, la pipeline e i relativi componenti vengono creati, testati e pacchettizzati quando viene eseguito il commit del nuovo codice o il push del nuovo codice nel repository del codice sorgente. Oltre a creare pacchetti, immagini container ed eseguibili, il processo di CI può includere i seguenti test:
Testare la logica di feature engineering.
Test delle unità dei diversi metodi implementati nel tuo modello. Ad esempio, hai una funzione che accetta una colonna di dati categorici e codifichi la funzione come funzionalità one-hot.
Testare che l'addestramento del modello converge (ovvero, la perdita del modello si riduce per iterazioni e si adatta ad alcuni record di esempio).
Se verifichi che l'addestramento del modello non produce valori NaN, a causa della divisione per zero o della manipolazione di valori piccoli o grandi.
Il test che ogni componente della pipeline produce gli artefatti previsti.
Test dell'integrazione tra i componenti della pipeline.
Distribuzione continua
In questo livello, il sistema fornisce continuamente nuove implementazioni della pipeline nell'ambiente di destinazione, che a sua volta fornisce servizi di previsione per il modello appena addestrato. Per una distribuzione continua rapida e affidabile di pipeline e modelli, dovresti considerare quanto segue:
Verificare 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 di memoria, calcolo e acceleratore necessarie.
Testare il servizio di previsione chiamando l'API del servizio con gli input previsti e assicurarsi 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 il test di carico del servizio per acquisire metriche come query al secondo (QPS) e latenza del modello.
Convalida dei dati per il riaddestramento o la previsione batch.
Verificare che i modelli soddisfino i target di rendimento predittivi prima di eseguirne il 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 dall'unione del codice nel ramo 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.
Riassumendo, implementare ML in un ambiente di produzione non significa solo eseguire il deployment del modello come API per la previsione. ma 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 delle pipeline. Questo sistema consente di far fronte ai rapidi cambiamenti dei dati e dell'ambiente aziendale. Non devi spostare immediatamente tutti i processi da un livello all'altro. Puoi implementare gradualmente queste pratiche per migliorare l'automazione dello sviluppo e della produzione di sistemi ML.
Passaggi successivi
- Scopri di più su Architecture for MLOps using TensorFlow Extended, Vertex AI Pipelines e Cloud Build.
- Scopri di più sulla Guida alle operazioni di machine learning (MLOps) per professionisti.
- 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 ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.