Questo documento illustra le tecniche per l'implementazione e l'automazione dell'integrazione continua (CI), della distribuzione continua (CD) e dell'addestramento continuo (CT) per i sistemi di machine learning (ML). Questo documento si applica principalmente ai sistemi di IA predittiva.
La scienza dei dati e l'ML stanno diventando funzionalità di base per risolvere problemi complessi del mondo reale, trasformare i settori e creare valore in tutti i domini. Al momento, hai a disposizione gli ingredienti per applicare un ML efficace:
- Set di dati di grandi dimensioni
- Risorse di calcolo on demand a basso costo
- Acceleratori specializzati per il machine learning su varie piattaforme cloud
- Rapidi progressi in diversi campi di ricerca del ML (come visione artificiale, comprensione del linguaggio naturale, AI generativa e sistemi di AI per i consigli).
Di conseguenza, molte aziende stanno investendo nei team di data science e nelle proprie competenze di ML per sviluppare modelli predittivi in grado di offrire valore commerciale ai propri utenti.
Questo documento è rivolto a data scientist e ML engineer che vogliono applicare i principi di DevOps ai sistemi di ML (MLOps). MLOps è una cultura e una pratica di ingegneria ML che mira a unificare lo sviluppo (Dev) e il funzionamento (Ops) dei sistemi ML. Praticare MLOps significa promuovere l'automazione e il monitoraggio di tutte le fasi di creazione di un sistema ML, tra cui integrazione, test, rilascio, deployment e gestione dell'infrastruttura.
I data scientist possono implementare e addestrare un modello di ML con prestazioni predittive su un set di dati di controllo offline, in base ai dati di addestramento pertinenti per il loro caso d'uso. Tuttavia, la vera sfida non è creare un modello ML, ma creare un sistema ML integrato e gestirlo continuamente in produzione. Grazie alla lunga esperienza di Google nell'offerta di servizi di ML per la produzione, abbiamo imparato che possono esserci molti problemi nell'utilizzo di sistemi basati sul machine learning in produzione. Alcuni di questi problemi sono descritti in Machine Learning: The High Interest Credit Card of Technical Debt.
Come mostrato nel seguente diagramma, solo una piccola parte di un sistema di ML reale è composta dal codice di ML. Gli elementi circostanti obbligatori sono numerosi e complessi.
Figura 1. Elementi per i sistemi di ML. Adattato da Debito tecnico nascosto nei sistemi di machine learning.
Il diagramma precedente mostra i seguenti componenti di sistema:
- Configurazione
- Automazione
- Raccolta dei dati
- Verifica dei dati
- Test e debug
- Gestione delle risorse
- Analisi dei modelli
- Gestione dei processi e dei metadati
- Infrastruttura di pubblicazione
- Monitoraggio
Per sviluppare e gestire sistemi complessi come questi, puoi applicare i principi di DevOps ai sistemi ML (MLOps). Questo documento illustra i concetti da prendere in considerazione quando si configura un ambiente MLOps per le 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 di ML
- Livelli di maturità di MLOps
- MLOps per l'AI generativa
DevOps e MLOps
DevOps è una pratica molto utilizzata per lo sviluppo e l'utilizzo di sistemi software su larga scala. Questa pratica offre vantaggi come l'accorciamento dei cicli di sviluppo, l'aumento della velocità di deployment e release affidabili. Per ottenere questi vantaggi, devi introdurre due concetti nello sviluppo del sistema software:
Un sistema ML è un sistema software, quindi vengono applicate pratiche simili per garantire che sia possibile creare e gestire in modo affidabile sistemi ML su larga scala.
Tuttavia, i sistemi di ML differiscono dagli altri sistemi software nei seguenti modi:
Competenze del team: in un progetto di ML, il team di solito include data scientist o ricercatori di ML, che si concentrano sull'analisi esplorativa dei dati, sullo sviluppo del modello e sulla sperimentazione. Questi membri potrebbero non essere sviluppatori software esperti in grado di creare servizi di livello di produzione.
Sviluppo: il machine learning è di natura sperimentale. Dovresti provare funzionalità, algoritmi, tecniche di modellazione e configurazioni di parametri diversi per trovare il metodo migliore per il problema il più rapidamente possibile. La sfida è monitorare cosa ha funzionato e cosa no, nonché mantenere la riproducibilità massimizzando al contempo la riutilizzabilità del codice.
Test: i test di un sistema di ML sono più complessi rispetto a quelli di altri sistemi software. Oltre ai tipici test di unità e integrazione, è necessaria la convalida dei dati, la valutazione della qualità del modello addestrato e la convalida del modello.
Deployment: nei sistemi ML, il deployment non è semplice come eseguire il deployment di un modello ML addestrato offline come servizio di previsione. I sistemi di ML possono richiedere di eseguire il deployment di una pipeline in più passaggi per addestrare e implementare automaticamente i modelli. Questa pipeline aggiunge complessità e richiede di automatizzare i passaggi svolti manualmente prima del deployment dai data scientist per addestrare e convalidare i nuovi modelli.
Produzione: i modelli di ML possono avere un rendimento ridotto non solo a causa di un codice non ottimale, ma anche a causa di profili di dati in continua evoluzione. In altre parole, i modelli possono peggiorare in più modi rispetto ai sistemi software convenzionali e devi prendere in considerazione questo degrado. Pertanto, devi monitorare le statistiche di riepilogo dei dati e il rendimento online del modello per inviare notifiche o eseguire il rollback quando i valori deviano dalle tue aspettative.
L'ML e altri sistemi software sono simili per quanto riguarda l'integrazione continua del controllo del codice sorgente, i test di unità, i test di integrazione e il deployment continuo del modulo o del pacchetto software. Tuttavia, nell'ML esistono alcune differenze sostanziali:
- La CI non riguarda più solo il test e la convalida di codice e componenti, ma anche di dati, schemi di dati e modelli.
- Il CD non riguarda più un singolo pacchetto software o un servizio, ma un sistema (una pipeline di addestramento ML) che deve eseguire automaticamente il deployment di un altro servizio (servizio di previsione del modello).
- CT è una nuova proprietà, unica per i sistemi di ML, che si occupa del riaddestramento e della pubblicazione automatica dei modelli.
La sezione seguente illustra i passaggi tipici per addestrare e valutare un modello di ML da utilizzare come servizio di previsione.
Passaggi di data science per l'ML
In qualsiasi progetto di ML, dopo aver definito il caso d'uso aziendale e stabilito i criteri di successo, il processo di invio di un modello di ML in produzione prevede le seguenti fasi. Queste fasi possono essere completate manualmente o mediante una pipeline automatica.
- Estrazione dati: selezioni e integri i dati pertinenti da varie origini dati per l'attività di ML.
- Analisi dei dati: esegui
analisi esplorative dei dati (EDA)
per comprendere i dati disponibili per la creazione del modello ML. Questa procedura porta a quanto segue:
- Comprendere lo schema e le caratteristiche dei dati previsti dal modello.
- Identificazione della preparazione dei dati e del feature engineering necessari per il modello.
- Preparazione dei dati: i dati vengono preparati per l'attività di ML. Questa preparazione prevede la pulizia dei dati, in cui li suddividi in set di addestramento, convalida e test. Applicano anche le trasformazioni dei dati e il feature engineering al modello che risolve l'attività target. Il risultato di questo passaggio sono le suddivisioni dei dati nel formato preparato.
- Addestramento del modello: il data scientist implementa diversi algoritmi con i dati preparati per addestrare vari modelli di ML. Inoltre, sometido 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 holdout per valutare la qualità del modello. L'output di questo passaggio è un insieme di metriche per valutare la qualità del modello.
- Convalida del modello: il modello è stato confermato come adeguato per il deployment, ovvero il suo rendimento predittivo è migliore rispetto a un determinato valore di riferimento.
- Pubblicazione del modello: il modello convalidato viene distribuito in un ambiente di destinazione per fornire le previsioni. Questo deployment può essere uno dei seguenti:
- Microservizi con un'API REST per fornire previsioni online.
- Un modello incorporato in un dispositivo edge o mobile.
- Componente di un sistema di previsione batch.
- Monitoraggio del modello: le prestazioni predittive del modello vengono monitorate per poter potenzialmente richiamare 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 in base a nuove implementazioni. Le sezioni seguenti descrivono tre livelli di MLOps, dal livello più comune, che non prevede alcuna automazione, fino all'automazione sia delle pipeline di ML sia di CI/CD.
Livello 0 di MLOps: procedura manuale
Molti team dispongono di data scientist e ricercatori di ML che possono creare modelli all'avanguardia, ma la loro procedura per creare e implementare i modelli di ML è interamente manuale. Questo è considerato il livello di maturità di base o livello 0. Il seguente diagramma mostra il flusso di lavoro di questa procedura.
Figura 2. Passaggi manuali di ML per pubblicare il modello come servizio di previsione.
Caratteristiche
L'elenco seguente mette in evidenza le caratteristiche del processo MLOps di livello 0, come mostrato nella Figura 2:
Procedura manuale, basata su script e interattiva: ogni passaggio è manuale, incluso l'analisi dei dati, la preparazione dei dati, l'addestramento e la convalida del modello. 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 in modo interattivo nei notebook dai data scientist, fino a quando non viene prodotto un modello utilizzabile.
Disconnessione tra ML e operazioni: il processo separa i data scientist che creano il modello dagli ingegneri che lo pubblicano come servizio di previsione. I data scientist consegnano un modello addestrato come elemento al team di ingegneria per il deployment nell'infrastruttura dell'API. Questo trasferimento può includere l'inserimento del modello addestrato in una posizione di archiviazione, il controllo dell'oggetto modello in un repository di codice o il caricamento in un registry dei modelli. Gli ingegneri che eseguono il deployment del modello devono quindi rendere disponibili le funzionalità richieste in produzione per il servizio a bassa latenza, il che può portare a un spostamento dell'addestramento rispetto al servizio.
Iterazioni di rilascio non frequenti: il processo presuppone che il tuo team di data science gestisca alcuni modelli che non cambiano spesso, modificando l'implementazione del modello o addestrando nuovamente il modello con nuovi dati. Viene eseguita il deployment di una nuova versione del modello solo un paio di volte all'anno.
Nessun CI: poiché si presumeno poche modifiche di implementazione, la CI viene ignorata. In genere, la verifica del codice fa parte dell'esecuzione dei notebook o degli script. Gli script e i notebook che implementano i passaggi dell'esperimento sono sottoposti a controllo della versione e producono artefatti come modelli addestrati, metriche di valutazione e visualizzazioni.
Nessun CD: poiché non vengono eseguiti implementazioni frequenti delle versioni del modello, il CD non viene preso in considerazione.
Il deployment si riferisce al servizio di previsione: il processo riguarda solo il deployment del modello addestrato come servizio di previsione (ad esempio un microservizio con un'API REST), anziché il deployment dell'intero sistema di ML.
Mancanza di monitoraggio attivo delle prestazioni: il processo non monitora né registra le previsioni e le azioni del modello, che sono necessarie per rilevare il degrado delle prestazioni del modello e altri scostamenti comportamentali del modello.
Il team di ingegneria potrebbe avere una propria configurazione complessa per la configurazione, il test e il deployment delle API, inclusi i test di sicurezza, di regressione, di carico e canary. Inoltre, il deployment in produzione di una nuova versione di un modello di 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
Il livello 0 di MLOps è comune in molte aziende che stanno iniziando ad applicare l'ML ai propri casi d'uso. Questa procedura manuale guidata da data scientist potrebbe essere sufficiente quando i modelli vengono modificati o addestrati raramente. In pratica, i modelli spesso si guastano quando vengono implementati nel mondo reale. I modelli non riescono ad adattarsi alle modifiche delle dinamiche dell'ambiente o dei dati che lo descrivono. Per saperne di più, consulta Perché i modelli di machine learning si arrestano in modo anomalo e non funzionano in produzione.
Per affrontare queste sfide e mantenere l'accuratezza del modello in produzione, devi procedere nel seguente modo:
Monitora attivamente la qualità del modello in produzione: il monitoraggio consente di rilevare il degrado delle prestazioni e l'obsolescenza del modello. Agisce da prompt per una nuova evoluzione della sperimentazione e per l'addestramento (manuale) del modello su nuovi dati.
Riaddestra spesso i modelli di produzione: per acquisire i pattern in evoluzione e emergenti, devi riaddestrare il modello con i dati più recenti. Ad esempio, se la tua app consiglia prodotti di moda utilizzando l'IA, i suoi consigli devono adattarsi alle ultime tendenze e ai prodotti più recenti.
Sperimenta continuamente nuove implementazioni per produrre il modello: per sfruttare le idee e i progressi tecnologici più recenti, devi provare nuove implementazioni come feature engineering, l'architettura del modello e gli iperparametri. Ad esempio, se utilizzi la visione artificiale per il rilevamento dei volti, gli schemi dei volti sono fissi, ma nuove tecniche migliori possono migliorare la precisióne del rilevamento.
Per affrontare le sfide di questa procedura manuale, sono utili le pratiche MLOps per CI/CD e CT. Se esegui il deployment di una pipeline di addestramento ML, puoi attivare la CT e configurare un sistema CI/CD per testare, creare ed eseguire rapidamente il deployment di nuove implementazioni della pipeline ML. Queste funzionalità vengono descritte in maggiore dettaglio nelle sezioni successive.
MLOps livello 1: automazione della pipeline ML
L'obiettivo del livello 1 è eseguire l'addestramento continuo del modello automatizzando la pipeline di ML, in modo da ottenere la distribuzione continua del servizio di previsione del modello. Per automatizzare il processo di utilizzo di nuovi dati per addestrare nuovamente 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 di ML automatizzata per la TC.
Figura 3. Automazione della pipeline di ML per l'addestramento continuo.
Caratteristiche
L'elenco seguente mette in evidenza le caratteristiche della configurazione di MLOps di livello 1, come mostrato nella Figura 3:
Esperimento rapido: i passaggi dell'esperimento di ML sono orchestrati. La transizione tra i passaggi è automatizzata, il che consente di eseguire rapidamente l'iterazione degli esperimenti e di essere più pronti a spostare l'intera pipeline in produzione.
CT del modello in produzione: il modello viene addestrato automaticamente in produzione utilizzando dati aggiornati in base agli trigger della pipeline in tempo reale, descritti nella sezione successiva.
Simmetria sperimentale-operativa: l'implementazione della pipeline utilizzata nell'ambiente di sviluppo o dell'esperimento viene utilizzata nell'ambiente preproduzione e di produzione, che è un aspetto chiave della pratica MLOps per unificare DevOps.
Codice modulare per componenti e pipeline: per costruire le pipeline ML, i componenti devono essere riutilizzabili, componibili e potenzialmente condivisibili tra le pipeline ML. Pertanto, anche se il codice EDA può essere ancora visualizzato nei notebook, il codice sorgente dei componenti deve essere modularizzato. Inoltre, i componenti dovrebbero essere idealmente in container per:
- Scollega l'ambiente di esecuzione dal runtime del codice personalizzato.
- Rendi il codice riproducibile tra gli ambienti di sviluppo e di produzione.
- Isola ogni componente della pipeline. I componenti possono avere la propria versione dell'ambiente di runtime e avere linguaggi e librerie diversi.
Distribuzione continua dei modelli: una pipeline ML in produzione fornisce continuamente servizi di previsione a nuovi modelli addestrati su nuovi dati. Il passaggio di deployment del modello, che pubblica il modello addestrato e convalidato come servizio di previsione per le previsioni online, è automatizzato.
Deployment della pipeline: nel livello 0, esegui il deployment di un modello addestrato come servizio di previsione in produzione. Per il livello 1, viene eseguita una 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 dell'IA.
Convalida dei dati e dei modelli
Quando esegui il deployment della pipeline ML in produzione, uno o più degli attivatori discussi nella sezione Attivatori della pipeline ML eseguono automaticamente la pipeline. La pipeline si aspetta nuovi dati in tempo reale per produrre una nuova versione del modello addestrata sui nuovi dati (come mostrato nella Figura 3). Pertanto, nella pipeline di produzione sono necessari passaggi di convalida dei dati e di convalida del modello automatici per garantire il seguente comportamento previsto:
Convalida dei dati: questo passaggio è necessario prima dell'addestramento del modello per decidere se addestrare nuovamente il modello o interrompere l'esecuzione della pipeline. Questa decisione viene presa automaticamente se la pipeline ha identificato quanto segue.
- Spostamenti nello schema dei dati: questi scostamenti sono considerati anomalie nei dati di input. Pertanto, i dati di input non conformi allo schema previsto vengono ricevuti dai passaggi della pipeline a valle, inclusi i passaggi di elaborazione dei dati e di addestramento del modello. In questo caso, devi interrompere la pipeline in modo che il team di data science possa effettuare accertamenti. Il team potrebbe rilasciare una correzione o un aggiornamento della pipeline per gestire queste modifiche nello schema. I disallineamenti dello schema includono la ricezione di funzionalità inaspettate, la mancata ricezione di tutte le funzionalità previste o la ricezione di funzionalità con valori inaspettati.
- Spostamenti dei valori dei dati: si tratta di variazioni significative nelle proprietà statistiche dei dati, il che significa che i pattern dei dati stanno cambiando e devi attivare una nuova addestramento del modello per rilevare queste variazioni.
Convalida del modello: questo passaggio viene eseguito dopo aver addestrato correttamente il modello in base ai nuovi dati. Valuta e convalida il modello prima di promuoverlo in produzione. Questo passaggio di convalida del modello offline consiste in quanto segue.
- Generazione di valori delle metriche di valutazione utilizzando il modello addestrato su un set di dati di test per valutare la qualità predittiva del modello.
- Confrontare i valori delle metriche di valutazione prodotti dal nuovo modello addestrato con il modello attuale, ad esempio il modello di produzione, il modello di riferimento o altri modelli dei requisiti aziendali. Assicurati che il nuovo modello generi un rendimento migliore rispetto al modello attuale prima di promuoverelo in produzione.
- Assicurati che le prestazioni del modello siano coerenti su vari segmenti di dati. Ad esempio, il nuovo modello di abbandono dei clienti addestrato potrebbe produrre un'accuratezza predittiva complessiva migliore rispetto al modello precedente, ma i valori di accuratezza per regione del cliente potrebbero presentare una varianza elevata.
- Assicurati di testare il modello per il deployment, inclusa la compatibilità e la coerenza dell'infrastruttura con l'API del servizio di previsione.
Oltre alla convalida offline, un modello appena implementato viene sottoposto a convalida online, in un deployment canary o in una configurazione di test A/B, prima di fornire la previsione per il traffico online.
Archivio di caratteristiche
Un componente aggiuntivo facoltativo per l'automazione della pipeline ML di livello 1 è un feature store. Un Feature Store è un repository centralizzato in cui standardizzare la definizione, lo stoccaggio e l'accesso alle funzionalità per l'addestramento e la distribuzione. Un Feature Store deve fornire un'API sia per la pubblicazione batch ad alta velocità effettiva sia per la pubblicazione in tempo reale a bassa latenza per i valori delle funzionalità, nonché per supportare i carichi di lavoro di addestramento e pubblicazione.
L'archivio di funzionalità aiuta i data scientist a:
- Scopri e riutilizza gli insiemi di funzionalità disponibili per le relative entità, anziché ricrearne di uguali o simili.
- Evita di avere funzionalità simili con definizioni diverse mantenendo le funzionalità e i relativi metadati.
- Pubblica i valori delle caratteristiche aggiornati dall'archivio di caratteristiche.
Evita il disallineamento addestramento/distribuzione utilizzando il feature store come fonte di dati per la sperimentazione, l'addestramento continuo e la distribuzione 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 ottenere un'estrazione offline dal feature store per eseguire i propri esperimenti.
- Per l'addestramento continuo, la pipeline di addestramento ML automatizzata può recuperare un batch di valori delle funzionalità aggiornati 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 caratteristiche demografiche dei clienti, funzionalità dei prodotti e funzionalità di aggregazione delle sessioni correnti.
- Per la previsione online e il recupero delle funzionalità, il servizio di previsione identifica le funzionalità pertinenti per un'entità. Ad esempio, se l'entità è un cliente, le funzionalità pertinenti potrebbero includere età, cronologia acquisti e comportamento di navigazione. Il servizio raggruppa questi valori insieme e recupera tutte le funzionalità necessarie per l'entità contemporaneamente, anziché singolarmente. Questo metodo di recupero contribuisce all'efficienza, soprattutto quando devi gestire più entità.
Gestione dei metadati
Le informazioni su ogni esecuzione della pipeline ML vengono registrate per contribuire a migliorare la derivazione, la riproducibilità e i confronti dei dati e degli artefatti. Inoltre, ti aiuta a eseguire il debug di errori e anomalie. Ogni volta che esegui la pipeline, il datastore dei metadati ML registra i seguenti metadati:
- Le versioni della pipeline e dei componenti che sono state eseguite.
- La data e l'ora di inizio e di fine e il tempo impiegato dalla pipeline per completare ciascuno dei passaggi.
- L'esecutore della pipeline.
- Gli argomenti del parametro passati alla pipeline.
- I puntatori agli elementi artefatti prodotti da ogni passaggio della pipeline, ad esempio la posizione dei dati preparati, le anomalie di convalida, le statistiche calcolate e il vocabolario estratto dalle funzionalità categoriche. Il monitoraggio di questi output intermedi ti consente di riprendere la pipeline dal passaggio più recente se si è interrotta a causa di un passaggio non riuscito, senza dover eseguire nuovamente i passaggi già completati.
- Un puntatore al modello addestrato precedente se devi eseguire il rollback a una versione precedente del modello o se devi produrre metriche di valutazione per una versione precedente del modello quando alla pipeline vengono forniti nuovi dati di test durante il passaggio di convalida del modello.
- Le metriche di valutazione del modello prodotte durante il passaggio di valutazione del modello sia per i set di addestramento sia per i set di test. Queste metriche ti aiutano a confrontare le prestazioni di un modello appena addestrato con quelle registrate del modello precedente durante il passaggio di convalida del modello.
Trigger delle pipeline ML
Puoi automatizzare le pipeline di produzione ML per addestrare nuovamente i modelli con nuovi dati, 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 il sistema di ML su base giornaliera, settimanale o mensile. La frequenza di addestramento dipende anche dalla frequenza con cui cambiano i pattern dei dati e dal costo dell'addestramento dei modelli.
- Sulla disponibilità di nuovi dati di addestramento: i nuovi dati non sono disponibili in modo sistematico per il sistema di ML, ma sono disponibili su base ad hoc quando vengono raccolti e resi disponibili nei database di origine.
- Sul degrado delle prestazioni del modello: il modello viene riaddestrato quando si verifica un degrado delle prestazioni.
- In caso di variazioni significative nelle distribuzioni dei dati (deviazione del concetto). È difficile valutare il rendimento completo del modello online, ma noti cambiamenti significativi nelle distribuzioni dei dati delle funzionalità utilizzate per eseguire la previsione. Queste modifiche suggeriscono che il modello è diventato obsoleto e deve essere addestrato nuovamente con dati aggiornati.
Sfide
Supponendo che le nuove implementazioni della pipeline non vengano implementate di frequente e che tu stia gestendo solo alcune pipeline, in genere testi manualmente la pipeline e i relativi componenti. Inoltre, esegui manualmente il deployment di nuove implementazioni delle pipeline. Inoltre, invii il codice sorgente testato della pipeline al team IT per il deployment nell'ambiente di destinazione. Questa configurazione è adatta quando si eseguono il deployment di nuovi modelli in base a nuovi dati anziché a nuove idee di ML.
Tuttavia, devi provare nuove idee di ML ed eseguire rapidamente il deployment di nuove implementazioni dei componenti di ML. Se gestisci molte pipeline di ML in produzione, hai bisogno di una configurazione CI/CD per automatizzare la compilazione, il test e il deployment delle pipeline di ML.
MLOps di livello 2: automazione di 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 data scientist di esplorare rapidamente nuove idee riguardanti il processo di feature engineering, l'architettura dei modelli e gli iperparametri. Possono implementare queste idee e automaticamente creare, testare ed eseguire il deployment dei componenti della nuova 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 più le routine CI/CD automatizzate.
Figura 4. Pipeline di machine learning CI/CD automatizzata.
Questa configurazione MLOps include i seguenti componenti:
- Controllo del codice sorgente
- Testare e creare servizi
- Servizi di deployment
- Registro dei modelli
- Archivio di caratteristiche
- Archivio dei metadati ML
- Orchestratore di pipeline ML
Caratteristiche
Il seguente diagramma mostra le fasi della pipeline di automazione CI/CD per il machine learning:
Figura 5. Fasi della pipeline di ML automatizzata CI/CD.
La pipeline è costituita dalle seguenti fasi:
Sviluppo e sperimentazione: provi in modo iterativo nuovi algoritmi di ML e nuove modalità di definizione del modello in cui vengono orchestrati i passaggi dell'esperimento. L'output di questa fase è il codice sorgente dei passaggi della pipeline ML che vengono poi inviati a un repository di origine.
Integrazione continua della pipeline: crei il codice sorgente ed esegui vari test. Gli output di questa fase sono i componenti della pipeline (pacchetti, executable e artefatti) da eseguire in una fase successiva.
Distribuzione continua della pipeline: esegui il deployment degli elementi 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 attivatore. L'output di questa fase è un modello addestrato che viene inviato al registro dei modelli.
Distribuzione continua del modello: il modello addestrato viene pubblicato 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 sul rendimento del modello in base ai dati in tempo reale. L'output di questa fase è un attivatore per eseguire la pipeline o un nuovo ciclo di esperimenti.
Il passaggio di analisi dei dati è ancora una procedura manuale per i data scientist prima che la pipeline avvii una nuova iterazione dell'esperimento. Anche il passaggio di analisi del modello è un procedura manuale.
Integrazione continua
In questa configurazione, la pipeline e i relativi componenti vengono costruiti, testati e impacchettati quando viene eseguito il commit o il push del nuovo codice nel repository del codice sorgente. Oltre a creare pacchetti, immagini container ed eseguibili, la procedura CI può includere i seguenti test:
Test delle unità della logica di feature engineering.
Test di unità dei diversi metodi implementati nel modello. Ad esempio, hai una funzione che accetta una colonna di dati categorici e la codifichi come caratteristica one-hot.
Verificare che l'addestramento del modello converga (ovvero che la perdita del modello diminuisca con le iterazioni e che il modello sovrapparti alcuni record di esempio).
Verificare che l'addestramento del modello non produca valori NaN a causa della divisione per zero o della manipolazione di valori piccoli o grandi.
Verificare che ogni componente della pipeline produca gli elementi previsti.
Testare l'integrazione tra i componenti della pipeline.
Distribuzione continua
In questo livello, il sistema rilascia continuamente nuove implementazioni della pipeline nell'ambiente di destinazione, che a sua volta fornisce i servizi di previsione del nuovo modello addestrato. Per una distribuzione continua rapida e affidabile di pipeline e modelli, devi considerare quanto segue:
Verificare la compatibilità del modello con l'infrastruttura di destinazione prima di eseguire il deployment del modello. Ad esempio, devi verificare che i pacchetti richiesti dal modello siano installati nell'ambiente di servizio e che le risorse di memoria, calcolo e acceleratore richieste siano disponibili.
Testa il servizio di previsione chiamando l'API del servizio con gli input previsti e assicurati di ricevere la risposta che ti aspetti. Questo test solitamente rileva 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 la latenza del modello.
Convalida dei dati per il ricoinvolgimento o la previsione batch.
Verificare che i modelli soddisfino gli obiettivi di rendimento predittivi prima di essere impiegati.
Deployment automatico in un ambiente di test, ad esempio un deployment attivato inviando il codice al ramo di sviluppo.
Deployment semiautomatico in un ambiente di preproduzione, ad esempio un deployment attivato dall'unione del codice al ramo principale dopo l'approvazione delle modifiche da parte dei revisori.
Deployment manuale in un ambiente di produzione dopo diverse esecuzioni riuscite della pipeline nell'ambiente di pre-produzione.
In sintesi, l'implementazione dell'IA in un ambiente di produzione non significa solo eseguire il deployment del modello come API per la previsione. ma di implementare una pipeline ML in grado di automatizzare il ricoinvolgimento e il deployment di nuovi modelli. La configurazione di un sistema CI/CD ti consente di testare e implementare automaticamente nuove implementazioni della pipeline. Questo sistema ti consente di gestire i rapidi cambiamenti dei dati e dell'ambiente aziendale. Non è necessario spostare immediatamente tutte le tue procedure da un livello all'altro. Puoi implementare gradualmente queste pratiche per contribuire a migliorare l'automazione dello sviluppo e della produzione del tuo sistema di ML.
Passaggi successivi
- Scopri di più sull'architettura per MLOps che utilizza TensorFlow Extended, Vertex AI Pipelines e Cloud Build.
- Consulta la Guida alle operazioni di machine learning (MLOps) per i professionisti.
- Scopri di più su come configurare una pipeline CI/CD per il flusso di lavoro di elaborazione dei dati.
- Guarda le Best practice di MLOps su Google Cloud (Cloud Next '19) su YouTube.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.
Collaboratori
Autori:
- Jarek Kazmierczak | Solutions Architect
- Khalid Salama | Staff Software Engineer, Machine Learning
- Valentin Huerta | Tecnico IA
Altro collaboratore: Sunil Kumar Jang Bahadur | Customer Engineer