Questo documento illustra le tecniche di implementazione e automatizzazione dell'integrazione continua (CI), della distribuzione continua (CD) e per l'addestramento (CT) per i sistemi di machine learning (ML).
Data science e ML stanno diventando funzionalità fondamentali per risolvere complessi problemi reali, trasformare i settori e fornire valore a tutti domini. Attualmente, gli ingredienti per applicare un ML efficaci sono disponibili di:
- 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, la comprensione del linguaggio naturale e i sistemi di AI per suggerimenti).
Pertanto, molte aziende stanno investendo nei propri team di data science e nel machine learning per sviluppare modelli predittivi in grado di fornire valore aziendale per i loro utenti.
Questo documento è rivolto ai data scientist e agli ML engineer che vogliono applicare DevOps principi per i sistemi ML (MLOps). MLOps è una cultura di ingegneria ML pratica che mira a unificare lo sviluppo dei sistemi di ML (Dev) e i sistemi di ML operativa (Ops). Mettere in pratica le MLOps significa sostenere l'automazione e il monitoraggio di tutte le fasi della creazione di sistemi ML, inclusa l'integrazione, per i test, il rilascio, il deployment e la gestione dell'infrastruttura.
I data scientist possono implementare e addestrare un modello ML modello con prestazioni predittive su un set di dati di holdout offline, dati pertinenti e i dati di addestramento per il loro caso d'uso. La vera sfida, però, non è creare una di ML, la sfida è creare un sistema ML integrato e a utilizzarla continuamente in produzione. Con la lunga storia dell'ML di produzione di Google, abbiamo imparato che possono esistere molte insidie operative sistemi basati su ML in produzione. Alcune di queste insidie sono riassunte in Machine Learning: la carta di credito ad alto interesse che rappresenta un debito tecnico.
Come mostrato nel seguente diagramma, solo una piccola parte del modello ML reale è composto dal codice ML. Gli elementi circostanti richiesti sono vasti e complesso.
Figura 1. Elementi per i sistemi ML. Adattato da Debito tecnico nascosto nei sistemi di machine learning.
In questo diagramma, il resto il sistema è composto da configurazione, automazione, raccolta dati, verifica, 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 DevOps principi per i sistemi ML (MLOps). Questo documento tratta i concetti da considerare quando impostazione creare un ambiente MLOps per le tue pratiche di data science, come CI, CD e CT nell'ML.
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 l'abbreviazione dei cicli di sviluppo, aumentando la velocità di deployment e le release affidabili. Per raggiungere questi , introdurre due concetti nello sviluppo del sistema software:
Un sistema di ML è un sistema software, quindi si applicano pratiche simili per garantire di poter creare e gestire in modo affidabile sistemi di 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 dati scienziati o ricercatori di ML, che si concentrano sull'analisi esplorativa dei dati, sviluppo e sperimentazione. Questi membri potrebbero non avere esperienza tecnici del software in grado di creare servizi di produzione.
Sviluppo: il ML è di natura sperimentale. Dovresti provare diverse funzionalità, algoritmi, tecniche di modellazione e configurazioni dei parametri per trovare riesce a risolvere il problema il più rapidamente possibile. La sfida è monitorare che cosa ha funzionato ciò che non è stato registrato e mantenendo la riproducibilità massimizzando al contempo il codice riutilizzabili.
Test: il test di un sistema ML è più impegnativo rispetto a test di altri i sistemi software per le attività. Oltre ai tipici test delle unità e di integrazione, richiedono la convalida dei dati, la valutazione addestrata della qualità del modello e la convalida del modello.
Deployment: nei sistemi ML, il deployment non è semplice quanto addestrato offline come servizio di previsione. I sistemi di ML possono richiedere eseguire il deployment di una pipeline in più fasi per riaddestrare ed eseguire automaticamente il deployment model. Questa pipeline aumenta la complessità e richiede l'automazione dei passaggi che vengono eseguite manualmente prima del deployment da parte dei data scientist per addestrare convalidare nuovi modelli.
Produzione: i modelli di ML possono avere prestazioni ridotte, non solo a causa a una programmazione non ottimale, ma anche a causa della costante evoluzione dei profili di dati. Nel In altre parole, i modelli possono peggiorare in più modi rispetto a quelli convenzionali sistemi software ed è necessario considerare questo peggioramento. Pertanto, è necessario monitorare le statistiche riepilogative dei dati e monitorare delle prestazioni del modello, in modo da inviare notifiche o eseguire il rollback deviare dalle tue aspettative.
Il ML e altri sistemi software sono simili integrazione continua tra controllo del codice sorgente, test delle unità, test di integrazione la distribuzione continua del modulo software o del pacchetto. Tuttavia, nell'ML, esistono alcune differenze degne di nota:
- 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 (una pipeline di addestramento ML) che deve eseguire automaticamente il deployment di un'altra (servizio di previsione del modello).
- CT è una nuova proprietà, unica dei sistemi ML, che si occupa il riaddestramento e la pubblicazione automatici dei modelli.
La seguente sezione illustra i passaggi tipici dell'addestramento e della valutazione un modello ML da usare come servizio di previsione.
Passaggi di data science per l'ML
In qualsiasi progetto ML, dopo aver definito il caso d'uso aziendale e stabilito criteri di successo, il processo di invio di un modello ML in produzione implica i seguenti passaggi. Puoi completare questi passaggi manualmente o anche solo da una pipeline automatica.
- Estrazione dati: devi selezionare integrare i dati pertinenti provenienti da varie origini dati per l'attività ML.
- Analisi dei dati: esegui
analisi esplorativa dei dati
(EDA) per comprendere i dati disponibili per la creazione del modello ML. Questo
porta a quanto segue:
- Comprendere lo schema dei dati e le caratteristiche previste del modello.
- Identificazione della preparazione dei dati e del 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 li suddividi in set di addestramento, convalida e test. Applichi anche trasformazioni dei dati e feature engineering al modello che risolve l'attività target. La di questo passaggio sono le suddivisioni di dati nel formato preparato.
- Addestramento del modello: il data scientist implementa con i dati preparati per addestrare vari modelli di ML. Inoltre, sottoponi gli algoritmi implementati all'ottimizzazione degli iperparametri per il modello ML con le migliori prestazioni. L'output di questo passaggio è un modello addestrato.
- Valutazione del modello: il modello viene valutato sulla base di set di test di holdout per valutare la qualità del modello. L'output di questo passaggio è un insieme metriche per valutare la qualità del modello.
- Convalida del modello: è confermato che il modello è adeguato per il deployment, che le sue prestazioni predittive siano migliori di quelle una certa base di riferimento.
- Pubblicazione del modello: viene eseguito il deployment del modello convalidato in una
dell'ambiente di destinazione
per fornire 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: il rendimento predittivo del modello è monitorati per richiamare potenzialmente una nuova iterazione nel processo ML.
Il livello di automazione di questi passaggi definisce la maturità del processo ML, che riflette la velocità di addestramento dei nuovi modelli sulla base di nuovi dati o addestramento nuovi modelli considerati implementazioni. Le seguenti sezioni descrivono tre livelli di MLOps, a partire da partendo dal livello più comune, ovvero l'assenza di automazione, fino all'automazione di entrambe pipeline ML e CI/CD.
MLOps livello 0: processo manuale
Molti team dispongono di data scientist e ricercatori di ML che possono creare modelli all'avanguardia, ma il loro processo per la creazione e il deployment sono completamente manuali. 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
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, tra cui analisi dei dati, preparazione dei dati, modelli addestramento e convalida. Richiede l'esecuzione manuale di ogni passaggio e la transizione manuale da un passaggio all'altro. Questo processo è in genere guidato da codice sperimentale scritto ed eseguito nei blocchi note in base ai dati gli scienziati in modo interattivo, fino a produrre un modello attuabile.
Disconnessione tra ML e operazioni: il processo separa i dati gli scienziati che creano il modello e gli ingegneri che lo utilizzano come di previsione. I data scientist consegnano un modello addestrato come l'artefatto al team di progettazione per eseguire il deployment dell'API dell'infrastruttura. Questo passaggio può includere l'inserimento del modello addestrato in posizione di archiviazione, archiviando l'oggetto di modello in un repository di codice in un registro dei modelli. Gli ingegneri che eseguono il deployment del modello per rendere le funzionalità richieste disponibili in produzione per una bassa latenza pubblicazione, il che può portare disallineamento addestramento/distribuzione.
Iterazioni di release non frequenti: il processo presuppone che i tuoi dati scientifico gestisce alcuni modelli che non cambiano di frequente, cambiare l'implementazione del modello o riaddestrarlo con nuove e i dati di Google Cloud. 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 ignorato. Di solito, il test del codice fa parte dei blocchi note o dell'esecuzione dello script. I copioni e i blocchi note che implementano i passaggi dell'esperimento sono 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, non viene preso in considerazione.
Il deployment si riferisce al servizio di previsione: il processo è preoccupato solo con il deployment del modello addestrato come servizio di previsione (ad esempio, un microservizio con un'API REST) anziché eseguire il deployment dell'intero sistema ML.
Mancanza di un monitoraggio attivo del rendimento: il processo non monitorare o registrare le previsioni e le azioni del modello, necessarie in ordine 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 delle API, test e deployment, tra cui sicurezza, regressione, carico e canary test. Inoltre, il deployment in produzione di una nuova versione di un modello ML di solito viene sottoposto a test A/B o a esperimenti online prima che il modello promosso per gestire tutto il traffico delle richieste di previsione.
Sfide
Il livello MLOps 0 è comune in molte aziende che stanno iniziando ad applicare il ML alle nei loro casi d'uso. Questo processo manuale guidato da data scientist potrebbe essere sufficiente quando i modelli vengono modificati o addestrati raramente. In pratica, i modelli spesso si rompono quando di cui viene eseguito il deployment nel mondo reale. I modelli non si adattano ai cambiamenti le dinamiche dell'ambiente o le modifiche ai dati che descrivono i completamente gestito di Google Cloud. Per ulteriori informazioni, vedi Perché i modelli di machine learning si arrestano in modo anomalo e bruciano in produzione.
Per affrontare queste sfide e mantenere l'accuratezza del modello in produzione, devi effettuare le seguenti operazioni:
Monitora attivamente la qualità del modello in produzione: il monitoraggio ti consente un peggioramento delle prestazioni e l'inattività del modello. Funge da segnale a una nuova iterazione della sperimentazione e al riaddestramento (manuale) del modello nuovi dati.
Riaddestrare di frequente i modelli di produzione: per intercettare l'evoluzione e pattern emergenti, devi riaddestrare il modello con le e i dati di Google Cloud. Ad esempio, se la tua app consiglia prodotti di moda utilizzando il machine learning, i consigli dovrebbero adattarsi agli ultimi prodotti e tendenze.
Prova continuamente nuove implementazioni per produrre il modello: Per sfruttare le ultime idee e i progressi tecnologici, devi provare le nuove implementazioni, come il feature engineering, l'architettura dei modelli e regolare gli iperparametri. Ad esempio, se usi la visione artificiale per il rilevamento facciale, le sequenze del volto sono risolte, ma nuove tecniche migliori possono migliorare la precisione di un 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 e configurare un sistema CI/CD testare, creare e distribuire rapidamente nuove implementazioni della pipeline ML. Questi verranno 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 automatizzare la pipeline ML; Ciò consente di ottenere la distribuzione continua di previsione. automatizzare il processo di utilizzo di nuovi dati per riaddestrare i modelli in produzione, devi introdurre i dati automatizzati e i passaggi di convalida del modello alla pipeline, nonché ai trigger della pipeline e alla 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 di MLOps livello 1, come mostrato nella Figura 3:
Esperimento rapido: i passaggi dell'esperimento ML sono orchestrate. La transizione tra i passaggi è automatizzata, il che porta rapida iterazione degli esperimenti e una migliore prontezza a spostare l'intero pipeline in produzione.
CT del modello in produzione: il modello viene addestrato automaticamente in produzione utilizzando dati aggiornati basati sulle live dei trigger della pipeline, di cui parleremo nella prossima sezione.
Simmetria sperimentale-operativa: implementazione della pipeline utilizzata nell'ambiente di sviluppo o di esperimento viene utilizzata di preproduzione e produzione, che è un aspetto chiave MLOps per l'unificazione di DevOps.
Codice modularizzato per componenti e pipeline: per costruire l'ML pipeline, i componenti devono essere riutilizzabili, componibili e condivisibile tra le pipeline di ML. Pertanto, sebbene il codice EDA possa continuare nei blocchi note, il codice sorgente dei componenti deve essere modularizzato. Nel 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 tra sviluppo e ambienti di produzione.
- Isola ogni componente della pipeline. I componenti possono avere la propria versione dell'ambiente di runtime e avere linguaggi e librerie.
Distribuzione continua di modelli: una pipeline ML in produzione in modo continuo fornisce servizi di previsione ai nuovi modelli addestrati sulla base di nuovi dati. La passaggio di deployment del modello, che serve il modello addestrato e convalidato come di previsione online per le previsioni online.
Deployment della pipeline: nel livello 0, esegui il deployment di una un modello di machine learning come servizio di previsione in produzione. Per il livello 1, esegui il deployment dell'intera pipeline di addestramento, che viene eseguita automaticamente e in modo ricorrente il modello addestrato come servizio di previsione.
Componenti aggiuntivi
Questa sezione illustra i componenti da aggiungere all'architettura per abilitare l'addestramento continuo del ML.
Convalida dei dati e dei modelli
Quando esegui il deployment della tua pipeline ML in produzione, uno o più trigger discusso nel Trigger della pipeline ML esegue automaticamente la pipeline. La pipeline si aspetta nuovi dati in tempo reale per produrre una nuova versione del modello che viene addestrata sui nuovi dati (come mostrato Figura 3). Pertanto, i passaggi di convalida automatica dei dati e di convalida del modello nella pipeline di produzione per garantire che: comportamento:
Convalida dei dati: questo passaggio è obbligatorio prima dell'addestramento del modello decidere se riaddestrare il modello o interrompere l'esecuzione una pipeline o un blocco note personalizzato. Questa decisione viene presa automaticamente se: identificati dalla pipeline.
- Disallineamenti dello schema dei dati: questi disallineamenti sono considerati anomalie nel i dati di input, il che significa che i passaggi della pipeline downstream, tra cui l'elaborazione dei dati e l'addestramento dei modelli, riceve dati non è conforme allo schema previsto. In questo caso, devi interrompere della pipeline per consentire al team di data science di analizzare. La team potrebbe rilasciare una correzione o un aggiornamento della pipeline per modifiche allo schema. I disallineamenti dello schema includono la ricezione inaspettata non ricevono tutte le funzionalità previste o non ricevono con valori inaspettati.
- Disallineamento dei valori dei dati: questi disallineamenti sono cambiamenti significativi nella proprietà statistiche dei dati, il che significa che i modelli di dati cambiare e devi attivare un riaddestramento del modello per acquisire queste modifiche.
Convalida del modello: questo passaggio si verifica dopo che hai addestrato correttamente il modello in base ai nuovi dati. Devi valutare e convalidare il modello prima che passa alla fase di produzione. Questo passaggio di convalida del modello offline è costituito da: per eseguire le operazioni indicate di seguito.
- Produrre i valori delle metriche di valutazione utilizzando il modello addestrato su una set di dati di test per valutare la qualità predittiva del modello.
- Confrontare i valori delle metriche di valutazione prodotti dai cluster modello attuale, ad esempio modello di produzione, base di riferimento o altri modelli di requisiti aziendali. L'utente deve assicurarsi che il nuovo produce prestazioni migliori rispetto al modello attuale e la promozione in produzione.
- Assicurarsi che le prestazioni del modello siano coerenti diversi segmenti di dati. Ad esempio, il cliente appena addestrato il tasso di abbandono può produrre una migliore accuratezza predittiva complessiva rispetto al modello precedente, ma i valori di accuratezza per cliente regione potrebbe avere una grande varianza.
- Assicurati di testare il modello per il deployment, inclusi la compatibilità e la coerenza dell'infrastruttura con il servizio di previsione API.
Oltre alla convalida del modello offline, è stato eseguito il deployment viene sottoposto a convalida del modello online, in un deployment canary o in un test A/B. prima di pubblicare 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 standardizzare la definizione, l'archiviazione e l'accesso alle caratteristiche per l'addestramento e in fase di pubblicazione. Un Feature Store deve fornire un'API sia per i batch a velocità effettiva elevata e gestione in tempo reale a bassa latenza per i valori delle caratteristiche e per il supporto sia per l'addestramento che per la gestione dei carichi di lavoro.
Il Feature Store aiuta i data scientist a:
- Scopri e riutilizza gli insiemi di caratteristiche disponibili per le relative entità di ricreare le stesse immagini o crearne di simili.
- Evita di avere caratteristiche simili con definizioni diverse mantenendo caratteristiche e i relativi metadati.
- Pubblica valori di caratteristiche aggiornati dal Feature Store.
Evita il disallineamento addestramento/distribuzione utilizzando il Feature Store come dati per la sperimentazione, l'addestramento continuo e la pubblicazione online. Questo fa in modo che le caratteristiche usate per l'addestramento siano le stesse utilizzata durante la pubblicazione:
- Per la sperimentazione, i data scientist possono ottenere un'estrazione offline dal Feature Store per eseguire i loro esperimenti.
- Per l'addestramento continuo, la pipeline di addestramento ML automatizzata Recupera un batch di valori di caratteristiche aggiornati del set di dati utilizzate per l'attività di addestramento.
- Per la previsione online, il servizio di previsione può recuperare in un batch i valori delle caratteristiche relativi dell'inserzionista, come le caratteristiche demografiche dei clienti, le caratteristiche dei prodotti funzionalità di aggregazione delle sessioni correnti.
Gestione dei metadati
Le informazioni su ciascuna esecuzione della pipeline di ML vengono registrate per aiutare con derivazione, riproducibilità e confronti di dati e artefatti. Inoltre, è utile ed eseguire il debug di errori e anomalie. Ogni volta che esegui la pipeline, l'archivio di metadati 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 necessario per il completamento della pipeline per ognuno dei passaggi.
- L'esecutore della pipeline.
- Gli argomenti dei parametri passati alla pipeline.
- I puntatori agli artefatti prodotti da ogni passaggio della pipeline, come posizione dei dati preparati, anomalie di convalida, statistiche calcolate, ed estratto il vocabolario dalle caratteristiche categoriche. Monitoraggio di questi Gli output intermedi consentono di riprendere la pipeline dalla versione più recente se la pipeline si è arrestata a causa di un passaggio non riuscito, senza dover esegui nuovamente i passaggi già completati.
- Un puntatore al modello addestrato precedente se devi eseguire il rollback a un 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 per sia il set di addestramento che quello di test. Queste metriche ti consentono di confrontare le prestazioni di un modello appena addestrato alle prestazioni registrate 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 a seconda del caso d'uso:
- On demand: esecuzione manuale ad hoc della pipeline.
- In base a una pianificazione: i nuovi dati etichettati sono sistematicamente disponibili per l'ML ogni giorno, settimana o mese. La frequenza di riaddestramento dipende dalla frequenza di modifica dei pattern di dati e da quanto costa per riaddestrare i modelli.
- In base alla disponibilità di nuovi dati di addestramento: i nuovi dati non lo sono disponibile in modo sistematico per il sistema di ML, ma su ad hoc quando vengono raccolti nuovi dati e resi disponibili nell'origine o Microsoft SQL Server.
- Al peggioramento delle prestazioni del modello: il modello viene riaddestrato se sono presenti un peggioramento notevole delle prestazioni.
- Sui cambiamenti significativi nelle distribuzioni dei dati (deviazione concettuale). È difficile valutare le prestazioni complete del modello online, ma noterà cambiamenti significativi nelle distribuzioni dei dati delle caratteristiche che utilizzate per eseguire la previsione. Queste modifiche suggeriscono che il tuo modello è diventato inattivo, perciò è necessario riaddestrarlo con dati aggiornati.
Sfide
Supponendo che il deployment di nuove implementazioni della pipeline non venga eseguito di frequente e gestisci solo poche pipeline, di solito testerai manualmente una pipeline e i suoi componenti. Inoltre, esegui il deployment manuale della nuova pipeline implementazioni. Invierai anche il codice sorgente testato per la pipeline a al team IT di implementare nell'ambiente di destinazione. Questa configurazione è adatta quando il deployment di nuovi modelli basati su nuovi dati, piuttosto che 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, devi una configurazione CI/CD per automatizzare la creazione, il test e il deployment di pipeline ML.
MLOps livello 2: automazione delle pipeline CI/CD
Per un aggiornamento rapido e affidabile delle pipeline in produzione, è necessario un solido sistema CI/CD automatizzato. Questo sistema CI/CD automatizzato consente ai tuoi dati gli scienziati esplorano rapidamente nuove idee sul feature engineering, architettura e iperparametri. Possono mettere in pratica queste idee e creare, testare ed eseguire automaticamente il deployment dei nuovi componenti della pipeline nella destinazione completamente gestito di Google Cloud.
Il seguente diagramma mostra l'implementazione della pipeline ML utilizzando CI/CD, che ha le caratteristiche della configurazione automatizzata delle pipeline di ML più di 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 ML algoritmi e nuovi modelli in cui vengono orchestrati i passaggi dell'esperimento. L'output di questa fase è il codice sorgente dei passaggi della pipeline ML che vengono quindi inviate a un repository di codice sorgente.
Integrazione continua della pipeline: crei codice sorgente ed esegui varie 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 da CI la fase successiva all'ambiente di destinazione. L'output di questa fase è un deployment pipeline con la nuova implementazione del modello.
Trigger automatico: la pipeline viene eseguita automaticamente in produzione in base a una programmazione o in risposta a un trigger. L'output di questa fase è un modello addestrato di cui viene eseguito il push al modello registro di sistema.
Distribuzione continua del modello: fornisci il modello addestrato come previsione per le previsioni. L'output di questa fase è un modello di cui è stato eseguito il deployment di previsione.
Monitoraggio: raccogli le statistiche sulle prestazioni del modello in base ai dati in tempo reale e i dati di Google Cloud. L'output di questa fase è un trigger per eseguire la pipeline o eseguire un nuovo ciclo dell'esperimento.
La fase dell'analisi dei dati è ancora un processo manuale per i data scientist prima la pipeline avvia una nuova iterazione dell'esperimento. Anche il passaggio di analisi del modello processo manuale.
Integrazione continua
In questa configurazione, la pipeline e i suoi componenti vengono creati, testati e pacchettizzati quando viene eseguito il commit o il push di un nuovo codice 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. Per Ad esempio, esiste una funzione che accetta una colonna di dati categorici e codifichi la funzione come una tantum funzionalità.
Testando la convergenza dell'addestramento del modello, ovvero la perdita si riduce per iterazioni overfitting alcuni record di esempio).
Test che l'addestramento del modello non produce NaN valori dovuti alla divisione per zero o alla manipolazione di valori piccoli o grandi.
Testando che ogni componente della pipeline produca i risultati previsti artefatti.
Test dell'integrazione tra i componenti della pipeline.
Distribuzione continua
A questo livello, il sistema fornisce continuamente nuove implementazioni della pipeline all'ambiente di destinazione che a sua volta fornisce servizi di previsione del addestrato al modello. Per la distribuzione continua rapida e affidabile di pipeline è necessario considerare quanto segue:
Verifica della compatibilità del modello con il target della tua infrastruttura prima di eseguire il deployment del modello. Ad esempio, devi avere e verificare che i pacchetti richiesti dal modello siano installati di gestione dell'ambiente di gestione e che le richieste di memoria, computing e acceleratore a disposizione.
Per testare il servizio di previsione, chiama l'API del servizio con il input, assicurandosi di ottenere la risposta prevista. Questo test di solito acquisisce i problemi che potrebbero verificarsi quando aggiorni la versione del modello e si aspetta un input diverso.
Testare le prestazioni del servizio di previsione, che prevede il test di carico per acquisire metriche come query al secondo (QPS) e la latenza del modello.
Convalida dei dati per il riaddestramento o la previsione batch.
Verificare che i modelli soddisfino i target di rendimento predittivi prima che viene eseguito il deployment.
il deployment automatico in un ambiente di test, ad esempio un deployment 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 i revisori approvano le modifiche.
Deployment manuale in un ambiente di produzione dopo diversi tentativi della pipeline nell'ambiente di pre-produzione.
Per riassumere, implementare il ML in un ambiente di produzione non significa solo il deployment del modello come API per la previsione. Piuttosto, significa eseguire il deployment pipeline in grado di automatizzare il riaddestramento e il deployment di nuovi modelli. Impostazione un sistema CI/CD consente di testare ed eseguire automaticamente il deployment di nuove pipeline implementazioni. Questo sistema ti consente di affrontare rapidi cambiamenti nei dati e in un ambiente di business. Non è necessario spostare immediatamente tutti i processi da un livello all'altro. Puoi implementare gradualmente queste pratiche per migliorare l'automazione dello sviluppo e della produzione del tuo sistema ML.
Passaggi successivi
- Scopri di più su Architettura per MLOps con TensorFlow Extended, Vertex AI Pipelines e Cloud Build.
- Scopri di più sulla Guida alle operazioni di machine learning (MLOps) per professionisti.
- Scopri di più su Impostazione di una pipeline CI/CD per il flusso di lavoro di elaborazione dati.
- Guarda il Best practice MLOps su Google Cloud (Cloud Next '19) su YouTube.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.