Nel machine learning di produzione, l'obiettivo non è creare un singolo modello ed eseguirne il deployment. L'obiettivo è creare pipeline automatizzate per lo sviluppo, il test e il deployment di modelli nel tempo. Perché? Con l'evolversi del mondo, le tendenze dei dati si evolvono, causando l'inattività dei modelli in produzione. In genere i modelli necessitano di un riaddestramento con dati aggiornati per continuare a fornire previsioni di alta qualità sul lungo periodo. In altre parole, dovresti trovare un modo per sostituire i modelli obsoleti con altri nuovi.
Senza pipeline, la sostituzione di un modello inattivo è un processo soggetto a errori. Ad esempio, una volta che un modello inizia a fornire previsioni errate, qualcuno dovrà raccogliere ed elaborare manualmente nuovi dati, addestrare un nuovo modello, convalidarne la qualità e infine eseguirne il deployment. Le pipeline ML automatizzano molti di questi processi ripetitivi, rendendo la gestione e la manutenzione dei modelli più efficienti e affidabili.
Creazione di pipeline
Le pipeline ML organizzano i passaggi per la creazione e il deployment dei modelli in attività ben definite. Le pipeline hanno una di due funzioni: fornire previsioni o aggiornare il modello.
Fornisce previsioni
La pipeline di gestione fornisce previsioni. Il modello viene esposto al mondo reale, rendendolo accessibile agli utenti. Ad esempio, quando un utente vuole una previsione (come sarà il tempo di domani, quanti minuti ci vorrà per andare in aeroporto oppure un elenco di video consigliati), la pipeline di pubblicazione riceve ed elabora i dati dell'utente, fa una previsione e poi li invia all'utente.
Aggiornamento del modello
I modelli tendono a diventare inattivi quasi immediatamente dopo essere entrati in produzione. In pratica, fanno previsioni utilizzando informazioni obsolete. I loro set di dati di addestramento hanno catturato lo stato del mondo un giorno fa o, in alcuni casi, un'ora fa. Inevitabilmente il mondo è cambiato: un utente ha guardato più video e ha bisogno di un nuovo elenco di consigli; la pioggia ha causato un rallentamento del traffico e gli utenti hanno bisogno di stime aggiornate per i loro orari di arrivo; una tendenza diffusa spinge i rivenditori a richiedere previsioni aggiornate dell'inventario per determinati articoli.
In genere, i team addestrano i nuovi modelli molto prima che il modello di produzione diventi inattivo. In alcuni casi, i team addestrano ed eseguono il deployment di nuovi modelli ogni giorno, nell'ambito di un ciclo continuo di addestramento e deployment. Idealmente, l'addestramento di un nuovo modello dovrebbe avvenire molto prima che il modello di produzione diventi inattivo.
Le seguenti pipeline collaborano per addestrare un nuovo modello:
- pipeline di dati. La pipeline elabora i dati utente per creare set di dati di addestramento e test.
- pipeline di addestramento. La pipeline di addestramento addestra i modelli utilizzando i nuovi set di dati della pipeline.
- pipeline di convalida. La pipeline di convalida convalida il modello addestrato confrontandolo con il modello di produzione utilizzando i set di dati di test generati dalla pipeline di dati.
La Figura 4 illustra gli input e gli output di ogni pipeline ML.
Pipeline ML
Figura 4. Le pipeline ML automatizzano molti processi per lo sviluppo e la manutenzione dei modelli. Ogni pipeline mostra i suoi input e gli output.
A livello generale, ecco come le pipeline mantengono un modello aggiornato in produzione:
In primo luogo, un modello va in produzione e la pipeline di pubblicazione inizia a fornire previsioni.
La pipeline inizia immediatamente a raccogliere dati per generare nuovi set di dati di addestramento e test.
In base a una pianificazione o a un trigger, le pipeline di addestramento e convalida addestrano e convalidano un nuovo modello utilizzando i set di dati generati dalla pipeline di dati.
Quando la pipeline di convalida conferma che il nuovo modello non è inferiore a quello di produzione, viene eseguito il deployment del nuovo modello.
Questo processo si ripete in continuazione.
Inattività del modello e frequenza di addestramento
Quasi tutti i modelli diventano inattivi. Alcuni modelli diventano inattivi più velocemente di altri. Ad esempio, i modelli che consigliano i vestiti di solito diventano obsoleti rapidamente perché le preferenze dei consumatori sono note per essere cambiate di frequente. D'altra parte, i modelli che identificano i fiori potrebbero non diventare mai vecchi. Le caratteristiche identificative di un fiore rimangono stabili.
La maggior parte dei modelli inizia a diventare inattivo subito dopo la messa in produzione. Dovrai stabilire una frequenza di addestramento che rifletta la natura dei tuoi dati. Se i dati sono dinamici, esegui spesso l'addestramento. Se è meno dinamico, potrebbe non essere necessario addestrarlo spesso.
Addestra i modelli prima che diventino inattivi. L'addestramento anticipato fornisce un buffer per risolvere potenziali problemi, ad esempio in caso di errore della pipeline di dati o di addestramento o in caso di scarsa qualità del modello.
Una best practice consigliata consiste nell'addestrare ed eseguire il deployment di nuovi modelli su base giornaliera. Proprio come i normali progetti software con un processo di creazione e rilascio giornaliero, le pipeline ML per l'addestramento e la convalida spesso sono più efficaci se vengono eseguite ogni giorno.
Pipeline di pubblicazione
La pipeline di pubblicazione genera e fornisce previsioni in due modi: online o offline.
Previsioni online. Le previsioni online vengono eseguite in tempo reale, in genere inviando una richiesta a un server online e restituendo una previsione. Ad esempio, quando un utente vuole una previsione, i suoi dati vengono inviati al modello e il modello restituisce la previsione. Ad esempio, Gmail classifica i messaggi in arrivo in tempo reale utilizzando le previsioni online.
Previsioni offline. Le previsioni offline sono precalcolate e memorizzate nella cache. Per fornire una previsione, l'app trova la previsione memorizzata nella cache nel database e la restituisce. Ad esempio, un servizio basato su abbonamento potrebbe prevedere il tasso di abbandono per gli abbonati. Il modello prevede la probabilità di abbandono per ogni sottoscrittore e la memorizza nella cache. Quando l'app ha bisogno della previsione, ad esempio per incentivare gli utenti che potrebbero abbandonare l'app, si limita a cercare la previsione precalcolata.
La figura 5 mostra come vengono generate e recapitate le previsioni online e offline.
Previsioni online e offline
Figura 5. Le previsioni online forniscono previsioni in tempo reale. Le previsioni offline vengono memorizzate nella cache e controllate al momento della pubblicazione.
Post-elaborazione della previsione
In genere, le previsioni vengono post-elaborate prima di essere inviate. Ad esempio, le previsioni potrebbero essere post-elaborate per rimuovere contenuti tossici o di parte. I risultati della classificazione potrebbero utilizzare variazioni per riordinare i risultati invece di mostrare l'output non elaborato del modello, ad esempio per promuovere contenuti più autorevoli, presentare una varietà di risultati, retrocedere risultati specifici (come clickbait) o rimuovere risultati per motivi legali.
La Figura 6 mostra una pipeline di gestione e le attività tipiche coinvolte nella fornitura delle previsioni.
Previsioni post-elaborazione
Figura 6. Pipeline di pubblicazione che illustra le attività tipiche per fornire previsioni.
Tieni presente che il passaggio di feature engineering in genere si crea all'interno del modello e non in un processo autonomo separato. Il codice di elaborazione dei dati nella pipeline di gestione è spesso quasi identico al codice di elaborazione dei dati utilizzato dalla pipeline di dati per creare set di dati di addestramento e test.
Archiviazione di asset e metadati
La pipeline di gestione deve incorporare un repository per registrare le previsioni del modello e, se possibile, i dati empirici reali.
Le previsioni del modello di logging ti consentono di monitorare la qualità del modello. Aggregando le previsioni, puoi monitorare la qualità generale del tuo modello e determinare se sta iniziando a perdere qualità. In genere, le previsioni del modello di produzione dovrebbero avere la stessa media delle etichette del set di dati di addestramento. Per ulteriori informazioni, consulta la sezione Bias di previsione.
Acquisizione di dati empirici reali
In alcuni casi, i dati empirici reali diventano disponibili solo molto tempo dopo. Ad esempio, se un'app meteo prevede il meteo nelle prossime sei settimane nel futuro, i dati empirici reali (il tempo reale) non saranno disponibili per sei settimane.
Ove possibile, incoraggia gli utenti a segnalare dati empirici reali aggiungendo nell'app meccanismi di feedback. Gmail acquisisce implicitamente il feedback degli utenti quando spostano la posta dalla Posta in arrivo alla cartella Spam. Tuttavia, funziona solo se l'utente ha classificato la posta in modo corretto. Quando gli utenti lasciano spam nella posta in arrivo (perché sanno che si tratta di spam e non lo aprono mai), i dati di addestramento diventano imprecisi. I messaggi verranno contrassegnati come "non spam" quando dovrebbero essere "spam". In altre parole, cerca sempre di trovare modi per acquisire e registrare dati empirici reali, ma presta attenzione alle eventuali lacune che potrebbero esistere nei meccanismi di feedback.
La Figura 7 mostra le previsioni fornite a un utente e registrate in un repository.
Previsioni di Logging
Figura 7. Registra le previsioni per monitorare la qualità del modello.
Pipeline di dati
Le pipeline di dati generano set di dati di addestramento e test dai dati dell'applicazione. Le pipeline di addestramento e convalida utilizzano quindi i set di dati per addestrare e convalidare nuovi modelli.
La pipeline di dati crea set di dati di addestramento e test con le stesse caratteristiche e la stessa etichetta originariamente utilizzata per addestrare il modello, ma con informazioni più recenti. Ad esempio, un'app per le mappe genera set di dati di addestramento e test relativi ai tempi di percorrenza recenti tra i punti per milioni di utenti, insieme ad altri dati pertinenti come il meteo.
Un'app per suggerimenti video genera set di dati di addestramento e test che includevano i video su cui un utente faceva clic dall'elenco consigliato (oltre a quelli su cui non è stato fatto clic), oltre ad altri dati pertinenti come la cronologia delle visualizzazioni.
La Figura 8 illustra la pipeline di dati utilizzando i dati dell'applicazione per generare set di dati di addestramento e test.
pipeline di dati
Figura 8. La pipeline elabora i dati delle applicazioni per creare set di dati per le pipeline di addestramento e convalida.
Raccolta ed trattamento dei dati
Le attività di raccolta ed elaborazione dei dati nelle pipeline di dati saranno probabilmente diverse dalla fase di sperimentazione (in cui hai stabilito che la tua soluzione era fattibile):
Raccolta dati. Durante la sperimentazione, la raccolta dei dati in genere richiede l'accesso ai dati salvati. Per le pipeline di dati, la raccolta dei dati potrebbe richiedere il rilevamento e l'approvazione per accedere ai dati dei log in modalità flusso.
Se hai bisogno di dati etichettati da esseri umani (come immagini mediche), avrai bisogno anche di un processo per la raccolta e l'aggiornamento. Se hai bisogno di dati etichettati da persone fisiche, consulta la pagina CrowdCompute.
Trattamento dati. Durante la sperimentazione, le funzionalità giuste sono venute dall'estrazione, dall'unione e dal campionamento dei set di dati. Per le pipeline di dati, la generazione delle stesse caratteristiche potrebbe richiedere processi completamente diversi. Tuttavia, assicurati di duplicare le trasformazioni dei dati della fase di sperimentazione applicando le stesse operazioni matematiche alle caratteristiche e alle etichette.
Archiviazione di asset e metadati
Sarà necessario un processo per l'archiviazione, il controllo delle versioni e la gestione dei set di dati di addestramento e test. I repository con controllo della versione offrono i seguenti vantaggi:
Riproducibilità. Ricrea e standardizza gli ambienti di addestramento e confronta la qualità delle previsioni tra i vari modelli.
Conformità. Rispettare i requisiti di conformità normativa per la verificabilità e la trasparenza.
Conservazione dei dati. Imposta i valori di conservazione dei dati per la durata dell'archiviazione dei dati.
Gestione degli accessi. Gestisci chi può accedere ai tuoi dati tramite autorizzazioni granulari.
Integrità dei dati. Monitora e comprendi le modifiche apportate ai set di dati nel tempo, semplificando la diagnosi dei problemi relativi ai dati o al modello.
Rilevabilità. Consenti ad altre persone di trovare facilmente i set di dati e le funzionalità. Altri team possono quindi determinare se sarebbero utili per i loro scopi.
Documentare i dati
Una buona documentazione aiuta gli altri a comprendere informazioni chiave sui tuoi dati, come tipo, fonte, dimensioni e altri metadati essenziali. Nella maggior parte dei casi, è sufficiente documentare i dati in un documento di progettazione o in g3doc. Se prevedi di condividere o pubblicare i dati, utilizza le schede di dati per strutturare le informazioni. Le schede dati semplificano la scoperta e la comprensione dei tuoi set di dati.
Pipeline di addestramento e convalida
Le pipeline di addestramento e convalida producono nuovi modelli per sostituire quelli di produzione prima che diventino inattivi. L'addestramento e la convalida di nuovi modelli assicurano che il modello migliore sia sempre in produzione.
La pipeline di addestramento genera un nuovo modello dai set di dati di addestramento e la pipeline di convalida confronta la qualità del nuovo modello con quella in produzione utilizzando i set di dati di test.
La Figura 9 illustra la pipeline di addestramento utilizzando un set di dati di addestramento per addestrare un nuovo modello.
pipeline di addestramento
Figura 9. La pipeline di addestramento addestra nuovi modelli usando il set di dati di addestramento più recente.
Dopo l'addestramento del modello, la pipeline di convalida utilizza set di dati di test per confrontare la qualità del modello di produzione con il modello addestrato.
In generale, se il modello addestrato non è significativamente peggiore del modello di produzione, il modello addestrato va in produzione. Se il modello addestrato è peggiore, l'infrastruttura di monitoraggio dovrebbe creare un avviso. I modelli addestrati con una qualità di previsione peggiore potrebbero indicare potenziali problemi con i dati o le pipeline di convalida. Questo approccio garantisce che il modello migliore, addestrato con i dati più recenti, sia sempre in produzione.
Archiviazione di asset e metadati
I modelli e i relativi metadati devono essere archiviati in repository con controllo delle versioni per organizzare e monitorare i deployment dei modelli. I repository di modelli offrono i seguenti vantaggi:
Monitoraggio e valutazione. Monitora i modelli in produzione e comprendi le metriche sulla qualità di valutazione e previsione.
Processo di rilascio del modello. Semplifica la revisione, l'approvazione, il rilascio o il rollback dei modelli.
Riproducibilità e debug. Riproduci i risultati del modello ed esegui il debug dei problemi in modo più efficace tracciando i set di dati e le dipendenze di un modello nei deployment.
Rilevabilità. Fai in modo che le altre persone trovino facilmente il tuo modello. Altri team possono quindi determinare se il tuo modello (o parti di esso) può essere utilizzato per i loro scopi.
La Figura 10 illustra un modello convalidato archiviato in un repository di modelli.
Archiviazione dei modelli
Figura 10. I modelli convalidati vengono archiviati in un repository di modelli per garantirne il monitoraggio e la rilevabilità.
Utilizza le schede dei modelli per documentare e condividere le informazioni chiave sul modello, come scopo, architettura, requisiti hardware, metriche di valutazione e così via.
Sfide nella creazione di pipeline
Quando crei le pipeline, potresti riscontrare i seguenti problemi:
Accedere ai dati necessari. Per accedere ai dati potrebbe essere necessario giustificare il motivo per cui ne hai bisogno. Ad esempio, potresti dover spiegare come verranno utilizzati i dati e chiarire come verranno risolti i problemi relativi alle PII. Preparati a mostrare una proof of concept che dimostri come il modello effettui previsioni migliori con l'accesso a determinati tipi di dati.
Ottenere le funzionalità giuste. In alcuni casi, le funzionalità utilizzate nella fase di sperimentazione non saranno disponibili dai dati in tempo reale. Pertanto, durante la sperimentazione, cerca di verificare che potrai ottenere le stesse funzionalità in produzione.
Comprendere come vengono raccolti e rappresentati i dati. Scoprire come sono stati raccolti i dati, chi li ha raccolti e come (insieme ad altri problemi) può richiedere tempo e impegno. È importante comprendere i dati in modo approfondito. Non utilizzare dati non attendibili per addestrare un modello che potrebbe andare in produzione.
Comprendere i compromessi tra impegno, costi e qualità del modello. Incorporare una nuova funzionalità in una pipeline di dati può richiedere molto impegno. Tuttavia, la caratteristica aggiuntiva potrebbe migliorare solo leggermente la qualità del modello. In altri casi, aggiungere una nuova funzionalità potrebbe essere semplice. Tuttavia, le risorse per recuperare e archiviare la funzionalità potrebbero essere costose in modo proibitivo.
Calcolo. Se hai bisogno di TPU per il riaddestramento, potrebbe essere difficile ottenere la quota richiesta. Inoltre, la gestione delle TPU è complicata. Ad esempio, alcune parti del modello o dei dati potrebbero dover essere progettate specificamente per le TPU, suddividendole in più chip TPU.
Individuazione del set di dati aureo corretto. Se i dati cambiano di frequente, ottenere set di dati d'oro con etichette coerenti e accurate può essere difficile.
Rilevare questi tipi di problemi durante la sperimentazione consente di risparmiare tempo. Ad esempio, non vuoi sviluppare le funzionalità e i modelli migliori per sapere che non sono utilizzabili in produzione. Pertanto, prova a confermare il prima possibile che la tua soluzione funzionerà entro i vincoli di un ambiente di produzione. È preferibile dedicare del tempo a verificare il funzionamento di una soluzione piuttosto che dover tornare alla fase di sperimentazione, perché la fase della pipeline ha messo in luce problemi insormontabili.