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 complessi del mondo reale, trasformare i settori e offrire 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 capacità di ML per sviluppare modelli predittivi in grado di fornire 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 pratica e una cultura di ingegneria del machine learning che mira a unificare lo sviluppo di sistemi ML (Dev) e la gestione dei sistemi ML (Ops). Praticare MLOps significa sostenere l'automazione e il monitoraggio in tutte le fasi di 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, con 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 utilizzarlo continuamente in produzione. Con la lunga storia di servizi ML di produzione di Google, abbiamo imparato che possono verificarsi molte insidie nel funzionamento dei sistemi basati su ML in produzione. Alcune di queste insidie sono riassunte nel Machine Learning: la carta di credito ad alto interesse del debito tecnico.
Come mostrato nel diagramma seguente, solo una piccola parte di un sistema ML reale è composta dal codice ML. Gli elementi circostanti richiesti sono grandi e complessi.
Figura 1. Elementi per i sistemi ML. Adattamento 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 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 tratta i concetti da considerare quando configuri un ambiente MLOps per le tue pratiche di data science, come CI, CD e CT in 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 popolare 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 assicurarti di poter creare e gestire in modo affidabile sistemi ML su larga scala.
Tuttavia, i sistemi di ML si differenziano dagli altri sistemi software per i seguenti aspetti:
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 produzione.
Sviluppo: il machine learning è di natura sperimentale. Prova diversi algoritmi, funzionalità, tecniche di modellazione e configurazioni di parametri per trovare ciò che funziona meglio per il problema il più rapidamente possibile. La sfida è tracciare ciò che ha funzionato e cosa no e mantenere la riproducibilità massimizzando al contempo la riusabilità del codice.
Test: eseguire test su un sistema ML è più impegnativo rispetto ai test di altri sistemi software. Oltre ai test tipici 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 come un servizio di previsione. I sistemi ML possono richiedere il deployment di una pipeline in più passaggi per il riaddestramento e il deployment del modello. Questa pipeline aggiunge complessità e richiede di automatizzare i passaggi 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 di profili di dati in costante evoluzione. In altre parole, i modelli possono deteriorarsi in più modi rispetto ai sistemi software convenzionali e devi tenere in considerazione questo peggioramento. Devi quindi monitorare 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.
I sistemi ML 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 ci sono alcune differenze degne di nota:
- La CI non riguarda più solo il test e la convalida di codice e componenti, ma anche di test e convalida di dati, schemi di dati e modelli.
- La tecnologia 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 del riaddestramento e della pubblicazione automatici dei 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 il ML
In qualsiasi progetto ML, dopo aver definito il caso d'uso aziendale e aver 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 dati: selezioni e integri i dati pertinenti da varie origini dati per l'attività ML.
- Analisi dei dati: esegui
l'analisi esplorativa dei dati
(EDA) per comprendere i dati disponibili per creare il modello ML. Questa procedura porta a quanto segue:
- Comprendere lo schema di dati e le caratteristiche che si prevede dal modello.
- identificazione della preparazione dei dati e del feature engineering necessari per il modello.
- Preparazione dei dati: i dati sono preparati per l'attività ML. Questa preparazione prevede la pulizia dei dati, in cui i dati vengono suddivisi in set di addestramento, convalida e test. Inoltre, puoi applicare le trasformazioni dei dati e il feature engineering al modello che risolve l'attività di destinazione. L'output di questo passaggio corrisponde alle suddivisioni dei dati nel formato preparato.
- Addestramento del modello: il data scientist implementa diversi algoritmi con i dati preparati per addestrare Inoltre, sottoponi gli algoritmi implementati all'ottimizzazione degli iperparametri per ottenere il modello ML con le migliori prestazioni. L'output di questo passaggio è un modello addestrato.
- Valutazione del modello: il modello viene valutato su un set di test di isolamento 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 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 di ML.
Il livello di automazione di questi passaggi definisce la maturità del processo di ML, che riflette la velocità di addestramento di nuovi modelli in base a nuovi dati o di addestramento di nuovi modelli con nuove implementazioni. Le seguenti sezioni 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.
MLOps livello 0: processo manuale
Molti team dispongono di data scientist e ricercatori ML che possono creare modelli all'avanguardia, ma il processo di creazione e 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 manuali di ML 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, inclusi 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 di solito si basa su un codice sperimentale scritto ed eseguito su blocchi note da data scientist in modo interattivo, fino a quando non viene prodotto un modello attuabile.
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 del modello in un registro dei modelli. Quindi gli ingegneri che eseguono il deployment del modello devono rendere disponibili in produzione le funzionalità richieste per la pubblicazione 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 di frequente, 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 un numero ridotto di modifiche all'implementazione, l'integrazione continua 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 ci sono deployment frequenti delle versioni del modello, 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), invece che il deployment dell'intero sistema ML.
Mancanza di un monitoraggio attivo delle prestazioni: il processo non tiene traccia e non registra le previsioni e le azioni del modello, necessarie per rilevare il peggioramento delle prestazioni del modello e altre deviazioni comportamentali del modello.
Il team di tecnici potrebbe disporre di una 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 di solito viene sottoposto a test A/B o esperimenti online prima che il modello venga promosso per gestire tutto il traffico delle richieste di previsione.
Sfide
MLOps di livello 0 è comune in molte aziende che iniziano ad applicare il ML ai propri casi d'uso. Questo processo manuale basato su data scientist potrebbe essere sufficiente quando i modelli vengono modificati o addestrati raramente. In pratica, i modelli spesso non funzionano quando ne viene eseguito il deployment nel mondo reale. I modelli non si adattano ai cambiamenti delle dinamiche dell'ambiente o alle modifiche dei dati che descrivono l'ambiente. Per maggiori informazioni, consulta Perché i modelli di machine learning si arrestano in modo anomalo e si arrestano in produzione.
Per affrontare queste sfide e mantenere l'accuratezza del modello in produzione, devi fare quanto segue:
Monitora attivamente la qualità del tuo modello in produzione: il monitoraggio consente di rilevare un peggioramento delle prestazioni e il mancato aggiornamento del modello. Funge da spunto per una nuova iterazione di sperimentazione e 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 ML, i consigli devono 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 nel rilevamento dei volti, le sequenze dei volti vengono corrette, ma nuove tecniche migliori possono migliorare la precisione 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 rapidamente il deployment di nuove implementazioni della pipeline ML. Queste funzionalità saranno illustrate più dettagliatamente nelle prossime sezioni.
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 i dati automatizzati e i passaggi di convalida dei modelli nella pipeline, 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
Il seguente elenco evidenzia le caratteristiche della configurazione di livello 1 di MLOps, come mostrato nella Figura 3:
Esperimento rapido: i passaggi dell'esperimento ML vengono 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 prossima sezione.
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 l'unificazione di DevOps.
Codice modularizzato 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:
- 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 e avere 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 serve il modello addestrato e convalidato come servizio di previsione per le previsioni online, è automatizzata.
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 pipeline ML in produzione, uno o più trigger discussi nella sezione Trigger della pipeline ML esegue 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). Di conseguenza, nella pipeline di produzione sono richiesti passaggi automatici 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.
- Disallineamento dello schema dei dati: queste disallineamento 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 del modello, ricevono dati non conformi allo schema previsto. In questo caso, devi arrestare la pipeline in modo che il team di data scientist possa analizzare. Il team potrebbe rilasciare una correzione o un aggiornamento alla pipeline per gestire queste modifiche allo schema. I 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 disallineamento rappresentano cambiamenti significativi nelle proprietà statistiche dei dati, il che significa che i pattern di dati stanno cambiando e che devi attivare un riaddestramento del modello per acquisire queste modifiche.
Convalida del modello: questo passaggio si verifica dopo aver addestrato correttamente il modello in base ai nuovi dati. Devi valutare e convalidare il modello prima che venga trasmesso in produzione. Questo passaggio di convalida del modello offline è costituito da quanto segue.
- Produrre i 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. Prima di promuoverlo in 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 di dati. Ad esempio, il modello di abbandono dei clienti appena addestrato potrebbe produrre una precisione predittiva generale migliore rispetto al modello precedente, ma i valori di accuratezza per regione del cliente potrebbero avere una grande varianza.
- Assicurati di testare il modello per il deployment, comprese la compatibilità e la coerenza dell'infrastruttura 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 la previsione per il traffico online.
Archivio di caratteristiche
Un componente aggiuntivo facoltativo per l'automazione delle pipeline ML di livello 1 è un Feature Store. Un Feature Store è un repository centralizzato in cui standardizza la definizione, l'archiviazione e l'accesso delle funzionalità per l'addestramento e la pubblicazione. Un archivio di caratteristiche deve fornire un'API per la pubblicazione in batch ad alta velocità effettiva e la gestione in tempo reale a bassa latenza per i valori delle caratteristiche e per supportare sia l'addestramento che la gestione dei carichi di lavoro.
Il Feature Store consente ai data scientist di:
- Scoprire e riutilizzare i set di caratteristiche disponibili per le rispettive entità, anziché crearne di uguali o simili.
- Evita di avere funzionalità simili con definizioni diverse mantenendo le funzionalità e i relativi metadati.
- Pubblica valori aggiornati delle caratteristiche dal Feature Store.
Per evitare il disallineamento addestramento/produzione, utilizza il Feature Store come origine dati per la sperimentazione, l'addestramento continuo e la pubblicazione online. Questo approccio assicura che le funzionalità utilizzate per l'addestramento siano le stesse utilizzate durante la pubblicazione:
- Per fare esperimenti, i data scientist possono ottenere un'estrazione offline dal Feature Store,
- Per l'addestramento continuo, la pipeline di addestramento ML automatizzato può recuperare un batch di valori aggiornati delle caratteristiche del set di dati utilizzati per l'attività di addestramento.
- Per la previsione online, il servizio di previsione può recuperare un batch di valori delle funzionalità relativi all'entità richiesta, ad esempio funzionalità relative ai dati demografici dei clienti, funzionalità di prodotto e funzionalità di aggregazione delle sessioni correnti.
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, è utile per eseguire il debug di errori e anomalie. Ogni volta che esegui la pipeline, i metadati ML archiviano i seguenti metadati:
- Le versioni della pipeline e dei componenti eseguite.
- Le date 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, 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 consente di 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 hai bisogno di 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 i set 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 di dati cambiano e da quanto costa riaddestrare i modelli.
- Sulla 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 degrado delle prestazioni del modello: il modello viene riaddestrato quando si nota un peggioramento delle prestazioni.
- 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 delle nuove implementazioni della pipeline non venga eseguito di frequente e che tu stia gestendo solo poche pipeline, di solito testerai manualmente la pipeline e i relativi componenti. Inoltre, esegui manualmente il deployment delle nuove implementazioni delle pipeline. Dovrai 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 di 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, hai bisogno di 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 sistema CI/CD automatizzato e solido. 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 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 presenta le caratteristiche della configurazione delle pipeline ML automatizzate e le routine CI/CD automatizzate.
Figura 4. pipeline CI/CD e ML automatizzata.
Questa configurazione di 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: provi in modo iterativo nuovi algoritmi ML e nuovi modelli di modellazione in cui vengono orchestrate le fasi dell'esperimento. L'output di questa fase è il codice sorgente dei passaggi della pipeline ML, di cui viene eseguito il push a un repository di codice sorgente.
Integrazione continua della pipeline: crea 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.
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.
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 statistiche sulle prestazioni del modello in base ai dati in tempo reale. L'output di questa fase è un trigger per l'esecuzione della pipeline o di 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. La fase di analisi del modello è anche un processo manuale.
Integrazione continua
In questa configurazione, la pipeline e i suoi componenti vengono creati, testati e messi in pacchetti quando viene eseguito il commit del 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 delle unità della logica del 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 la codifichi come funzionalità one-hot.
Testare la convergenza dell'addestramento del modello (ovvero, la perdita del modello diminuisce per iterazioni e sovradimensiona alcuni record di esempio).
Testando l'addestramento del modello non vengono generati valori NaN a causa della divisione per zero o della manipolazione di valori piccoli o grandi.
Testare che ogni componente della pipeline produce 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 i servizi di previsione per il modello appena addestrato. Per una distribuzione continua rapida e affidabile di pipeline e modelli, considera quanto segue:
Verificare la compatibilità del modello con l'infrastruttura target prima di eseguire il deployment del modello. 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 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 acquisisce i problemi che potrebbero verificarsi quando aggiorni la versione del modello e prevede un input diverso.
Test delle prestazioni del servizio di previsione, che comporta 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 gli obiettivi di rendimento predittivo prima del deployment.
Deployment automatico in un ambiente di test, ad esempio un deployment che viene attivato eseguendo il push del codice nel 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 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, l'implementazione del machine learning 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 il deployment di nuove implementazioni delle pipeline in modo automatico. 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 di sviluppo e 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 alle operazioni di machine learning (MLOps) per i 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 altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.