Miglioramento della stabilità e della flessibilità delle pipeline ML presso Amazon Packaging Innovation con Amazon SageMaker Pipelines

Per soddisfare i clienti e ridurre al minimo gli sprechi di imballaggio, Amazon deve selezionare il tipo di imballaggio ottimale per miliardi di pacchi spediti ogni anno. Se viene utilizzata una protezione insufficiente per un articolo fragile come una tazza da caffè, l'articolo arriverà danneggiato e Amazon rischia la fiducia del cliente. L'uso di troppa protezione comporterà un aumento dei costi e un eccessivo riempimento dei contenitori per il riciclaggio. Con centinaia di milioni di prodotti disponibili, è necessario un meccanismo decisionale scalabile per imparare continuamente dai test dei prodotti e dal feedback dei clienti.

Per risolvere questi problemi, il team di Amazon Packaging Innovation ha sviluppato modelli di machine learning (ML) che classificano se i prodotti sono adatti per i tipi di imballaggio Amazon come buste, buste o scatole o se possono anche essere spediti senza imballaggio aggiuntivo. In precedenza, il team ha sviluppato una pipeline personalizzata basata su Funzioni AWS Step per eseguire corsi di formazione settimanali e lavori di inferenza giornalieri o mensili. Tuttavia, nel tempo la pipeline non ha fornito una flessibilità sufficiente per lanciare modelli con nuove architetture. Lo sviluppo delle nuove pipeline ha presentato un sovraccarico e un coordinamento richiesto tra data scientist e sviluppatori. Per superare queste difficoltà e migliorare la velocità di implementazione di nuovi modelli e architetture, il team ha scelto di orchestrare l'addestramento e l'inferenza del modello con Pipeline di Amazon SageMaker.

In questo post, discutiamo della precedente architettura di orchestrazione basata su Step Functions, descriviamo le architetture di formazione e di inferenza utilizzando le pipeline ed evidenzieremo la flessibilità raggiunta dal team di Amazon Packaging Innovation.

Sfide dell'ex pipeline ML presso Amazon Packaging Innovation

Per incorporare un feedback continuo sulle prestazioni dei pacchetti, ogni settimana viene addestrato un nuovo modello utilizzando un numero crescente di etichette. L'inferenza per l'intero inventario dei prodotti viene eseguita mensilmente e viene eseguita un'inferenza giornaliera per fornire previsioni just-in-time per l'inventario appena aggiunto.

Per automatizzare il processo di addestramento di più modelli e fornire previsioni, il team ha sviluppato una pipeline personalizzata basata su Step Functions per orchestrare i seguenti passaggi:

• Preparazione dei dati per lavori di addestramento e inferenza e caricamento delle previsioni nel database (Amazon RedShift) Con Colla AWS.
• Formazione del modello e inferenza con Amazon Sage Maker.
• Calcolo delle metriche di performance del modello sul set di validazione con Batch AWS.
• utilizzando Amazon DynamoDB per archiviare le configurazioni del modello (come il rapporto di divisione dei dati per l'addestramento e la convalida, la posizione dell'artefatto del modello, il tipo di modello e il numero di istanze per l'addestramento e l'inferenza), le metriche delle prestazioni del modello e l'ultima versione del modello addestrata con successo.
• Calcolo delle differenze nei punteggi delle prestazioni del modello, modifiche nella distribuzione delle etichette di formazione e confronto della dimensione dei dati di input tra le versioni precedenti e nuove del modello con AWS Lambda funzioni.
• Dato l'elevato numero di passaggi, il gasdotto richiedeva anche un sistema di allarme affidabile in ogni passaggio per avvisare le parti interessate di eventuali problemi. Ciò è stato ottenuto tramite una combinazione di Servizio Amazon Simple Queue (Amazon SQS) e Servizio di notifica semplice Amazon (Amazon SNS). Gli allarmi sono stati creati per notificare agli stakeholder aziendali, ai data scientist e agli sviluppatori eventuali passaggi non riusciti e grandi deviazioni nel modello e nelle metriche dei dati.

Dopo aver utilizzato questa soluzione per quasi 2 anni, il team si è reso conto che questa implementazione funzionava bene solo per un tipico flusso di lavoro ML in cui un singolo modello veniva addestrato e valutato su un set di dati di convalida. Tuttavia, la soluzione non era sufficientemente flessibile per modelli complessi e non era resistente ai guasti. Ad esempio, l'architettura non si adattava facilmente all'addestramento sequenziale del modello. È stato difficile aggiungere o rimuovere un passaggio senza duplicare l'intera pipeline e modificare l'infrastruttura. Anche semplici modifiche alle fasi di elaborazione dei dati, come la regolazione del rapporto di suddivisione dei dati o la selezione di un diverso insieme di funzionalità, richiedevano il coordinamento sia di un data scientist che di uno sviluppatore. Quando il gasdotto si guastava in qualsiasi fase, doveva essere riavviato dall'inizio, il che si traduceva in ripetute corse e aumento dei costi. Per evitare esecuzioni ripetute e dover ricominciare dal passaggio non riuscito, il team creerebbe una nuova copia di una macchina a stati ridotta. Questa risoluzione dei problemi ha portato a una proliferazione delle macchine a stati, ciascuna a partire dai passaggi comunemente falliti. Infine, se un lavoro di formazione ha riscontrato una deviazione nella distribuzione delle etichette, nel punteggio del modello o nel numero di etichette, un data scientist doveva rivedere manualmente il modello e le relative metriche. Quindi uno scienziato dei dati accederà a una tabella DynamoDB con le versioni del modello e aggiornerà la tabella per assicurarsi che sia stato utilizzato il modello corretto per il successivo processo di inferenza.

Il mantenimento di questa architettura richiedeva almeno una risorsa dedicata e una risorsa aggiuntiva a tempo pieno per lo sviluppo. Date le difficoltà di espandere la pipeline per accogliere nuovi casi d'uso, i data scientist avevano iniziato a sviluppare i propri flussi di lavoro, che a loro volta avevano portato a una base di codice in crescita, più tabelle di dati con schemi di dati simili e monitoraggio decentralizzato del modello. L'accumulo di questi problemi aveva comportato una minore produttività del team e un aumento delle spese generali.

Per affrontare queste sfide, il team di Amazon Packaging Innovation ha valutato altre soluzioni esistenti per MLOps, tra cui SageMaker Pipelines (Annuncio di rilascio di dicembre 2020). Pipelines è una funzionalità di SageMaker per la creazione, la gestione, l'automazione e il ridimensionamento dei flussi di lavoro ML end-to-end. Pipelines consente di ridurre il numero di passaggi nell'intero flusso di lavoro di ML ed è sufficientemente flessibile da consentire ai data scientist di definire un flusso di lavoro di ML personalizzato. Si occupa di monitorare e registrare i passaggi. Inoltre viene fornito con un registro dei modelli che esegue automaticamente le versioni dei nuovi modelli. Il registro dei modelli dispone di flussi di lavoro di approvazione integrati per selezionare i modelli per l'inferenza in produzione. Pipelines consente anche di memorizzare nella cache i passaggi chiamati con gli stessi argomenti. Se viene trovata un'esecuzione precedente, viene creata una cache, che consente un facile riavvio invece di ricalcolare i passaggi completati con successo.

Nel processo di valutazione, Pipelines si è distinto dalle altre soluzioni per la sua flessibilità e disponibilità di funzionalità per supportare ed espandere i flussi di lavoro attuali e futuri. Il passaggio a Pipelines ha liberato il tempo degli sviluppatori dalla manutenzione della piattaforma e dalla risoluzione dei problemi e ha reindirizzato l'attenzione verso l'aggiunta delle nuove funzionalità. In questo post, presentiamo la progettazione per i flussi di lavoro di formazione e di inferenza al team di Amazon Packaging Innovation utilizzando Pipelines. Discutiamo anche dei vantaggi e della riduzione dei costi che il team ha realizzato passando a Pipelines.

Condotto di formazione

Il team di Amazon Packaging Innovation addestra i modelli per ogni tipo di pacco utilizzando un numero crescente di etichette. Il diagramma seguente illustra l'intero processo.

Il flusso di lavoro inizia estraendo etichette e funzionalità da un database Amazon Redshift e scaricando i dati su Servizio di archiviazione semplice Amazon (Amazon S3) tramite un processo pianificato di estrazione, trasformazione e caricamento (ETL). Insieme ai dati di input, nel bucket S3 viene inserito un oggetto file con il tipo di modello e i parametri. Questo file funge da trigger della pipeline tramite una funzione Lambda.

I passaggi successivi sono completamente personalizzabili e definiti interamente da un data scientist che utilizza SageMaker Python SDK for Pipelines. Nello scenario che presentiamo in questo post, i dati di input vengono suddivisi in set di addestramento e convalida e salvati in un bucket S3 avviando un processo di elaborazione SageMaker.

Quando i dati sono pronti in Amazon S3, inizia un processo di formazione SageMaker. Dopo che il modello è stato addestrato e creato con successo, la fase di valutazione del modello viene eseguita sui dati di convalida tramite un processo di trasformazione batch di SageMaker. Le metriche del modello vengono quindi confrontate con le metriche del modello della settimana precedente utilizzando un processo di elaborazione SageMaker. Il team ha definito più criteri personalizzati per valutare le deviazioni nelle prestazioni del modello. Il modello viene rifiutato o approvato sulla base di questi criteri. Se il modello viene rifiutato, il precedente modello approvato viene utilizzato per i successivi lavori di inferenza. Se il modello viene approvato, la sua versione viene registrata e quel modello viene utilizzato per lavori di inferenza. Le parti interessate ricevono una notifica sull'esito tramite Amazon Cloud Watch allarmi.

Il seguente screenshot di Amazon Sage Maker Studio mostra le fasi della pipeline di formazione.

Pipelines tiene traccia di ogni esecuzione della pipeline, che puoi monitorare in Studio. In alternativa, puoi interrogare lo stato di avanzamento della corsa utilizzando Boto3 oppure Interfaccia della riga di comando di AWS (AWS CLI). Puoi visualizzare le metriche del modello in Studio e confrontare diverse versioni del modello.

Conduttura di inferenza

Il team di Amazon Packaging Innovation aggiorna mensilmente le previsioni per l'intero inventario dei prodotti. Le previsioni giornaliere vengono generate per fornire consigli sull'imballaggio just-in-time per l'inventario appena aggiunto utilizzando l'ultimo modello addestrato. Ciò richiede che la pipeline di inferenza venga eseguita quotidianamente con diversi volumi di dati. Il diagramma seguente illustra questo flusso di lavoro.

Simile alla pipeline di addestramento, l'inferenza inizia con lo scarico dei dati da Amazon Redshift a un bucket S3. Un oggetto file inserito in Amazon S3 attiva la funzione Lambda che avvia la pipeline di inferenza. Le funzioni vengono preparate per l'inferenza ei dati vengono suddivisi in file di dimensioni adeguate utilizzando un processo di elaborazione SageMaker. Successivamente, la pipeline identifica l'ultimo modello approvato per eseguire le previsioni e caricarle in un bucket S3. Infine, le previsioni vengono ricaricate su Amazon Redshift utilizzando l'API boto3-data all'interno del processo di elaborazione SageMaker.

Lo screenshot seguente di Studio mostra i dettagli della pipeline di inferenza.

Vantaggi della scelta di progettare flussi di lavoro ML con SageMaker Pipelines

In questa sezione, discutiamo dei vantaggi ottenuti dal team di Amazon Packaging Innovation passando a Pipelines per l'addestramento e l'inferenza del modello.

Funzionalità MLOps a livello di produzione pronte all'uso

Confrontando diverse soluzioni interne ed esterne per la prossima soluzione di pipeline ML, un singolo data scientist è stato in grado di prototipare e sviluppare una versione completa di un flusso di lavoro ML con Pipelines in un ambiente Studio Jupyter in meno di 3 settimane. Già nella fase di prototipazione, è diventato chiaro che Pipelines forniva tutti i componenti dell'infrastruttura necessari per un flusso di lavoro a livello di produzione: controllo delle versioni del modello, memorizzazione nella cache e allarmi. L'immediata disponibilità di queste funzionalità significava che non sarebbe stato speso tempo aggiuntivo per svilupparle e personalizzarle. Questa è stata una chiara dimostrazione di valore, che ha convinto il team di Amazon Packaging Innovation che Pipelines era la soluzione giusta.

Flessibilità nello sviluppo di modelli ML

Il più grande vantaggio per i data scientist del team è stata la capacità di sperimentare facilmente e di scorrere diversi modelli. Indipendentemente dal framework che preferivano per il loro lavoro di ML e dal numero di passaggi e funzionalità coinvolti, Pipelines ha soddisfatto le loro esigenze. I data scientist sono stati autorizzati a sperimentare senza dover aspettare per iniziare lo sprint di sviluppo del software per aggiungere una funzionalità o un passaggio aggiuntivo.

Costi ridotti

La funzionalità Pipelines di SageMaker è "gratis": paghi solo per le risorse di calcolo e l'archiviazione associate all'addestramento e all'inferenza. Tuttavia, quando si pensa al costo, è necessario tenere conto non solo del costo dei servizi utilizzati, ma anche delle ore di sviluppo necessarie per mantenere il flusso di lavoro, eseguire il debug e correggerlo. L'orchestrazione con Pipelines è più semplice perché consiste in un minor numero di pezzi e un'infrastruttura familiare. In precedenza, l'aggiunta di una nuova funzionalità richiedeva almeno due persone (data scientist e software engineer) nel team di Amazon Packaging Innovation per implementarla. Con la pipeline riprogettata, gli sforzi di progettazione sono ora diretti verso un'infrastruttura personalizzata aggiuntiva attorno alla pipeline, come la creazione di un unico repository per il tracciamento del codice di machine learning, la semplificazione della distribuzione del modello tra gli account AWS, lo sviluppo di lavori ETL integrati e funzioni riutilizzabili.

Anche la possibilità di memorizzare nella cache i passaggi con un input simile ha contribuito alla riduzione dei costi, poiché era meno probabile che i team eseguissero nuovamente l'intera pipeline. Invece, potrebbero facilmente avviarlo dal punto di errore.

Conclusione

Il team di Amazon Packaging Innovation addestra i modelli ML su base mensile e aggiorna regolarmente le previsioni per i tipi di imballaggio dei prodotti consigliati. Questi consigli li hanno aiutati a raggiungere molteplici obiettivi a livello di team e aziendali, riducendo gli sprechi e soddisfacendo i clienti con ogni ordine. Le pipeline di formazione e di inferenza devono funzionare in modo affidabile su base regolare, pur consentendo un miglioramento costante dei modelli.

Il passaggio a Pipelines ha consentito al team di implementare quattro nuove architetture di modelli multimodali in produzione in meno di 2 mesi. La distribuzione di un nuovo modello utilizzando l'architettura precedente avrebbe richiesto da 5 giorni (con la stessa architettura del modello) a 1 mese (con una nuova architettura del modello). La distribuzione dello stesso modello utilizzando Pipelines ha consentito al team di ridurre il tempo di sviluppo a 4 ore con la stessa architettura del modello ea 5 giorni con una nuova architettura del modello. Ciò equivale a un risparmio di quasi l'80% dell'orario di lavoro.

Risorse addizionali

Per ulteriori informazioni, vedere le seguenti risorse:

---

Informazioni sugli autori

Ankur Shukla è Principal Data Scientist presso AWS-ProServe con sede a Palo Alto. Ankur ha più di 15 anni di esperienza nella consulenza, lavorando direttamente con il cliente e aiutandolo a risolvere i problemi aziendali con la tecnologia. Dirige numerose iniziative globali di scienza applicata e ML-Ops all'interno di AWS. Nel tempo libero ama leggere e passare il tempo con la famiglia.

Akash Singla è un Sr. System Dev Engineer con il team Amazon Packaging Innovation. Ha più di 17 anni di esperienza nella risoluzione di problemi aziendali critici attraverso la tecnologia per diversi verticali aziendali. Attualmente si concentra sull'aggiornamento dell'infrastruttura NAWS per una varietà di applicazioni incentrate sul packaging per ridimensionarle meglio.

Vitalina Komaško è un Data Scientist con AWS Professional Services. Ha conseguito un dottorato di ricerca in Farmacologia e Tossicologia ma è passata alla scienza dei dati dal lavoro sperimentale perché voleva "possedere la generazione dei dati e l'interpretazione dei risultati". All'inizio della sua carriera ha lavorato con aziende biotecnologiche e farmaceutiche. In AWS le piace risolvere i problemi per i clienti di diversi settori e conoscere le loro sfide uniche.

Prasanth Meiyappan è Sr. Applied Scientist con Amazon Packaging Innovation da oltre 4 anni. Ha oltre 6 anni di esperienza nel settore dell'apprendimento automatico e ha spedito prodotti per migliorare l'esperienza del cliente di ricerca e migliorare l'esperienza di confezionamento del cliente. Prasanth è appassionato di sostenibilità e ha un dottorato di ricerca in modellistica statistica dei cambiamenti climatici.

Matteo Bale è una ricercatrice senior che lavora per ottimizzare la selezione del tipo di pacchetto utilizzando il feedback dei clienti e l'apprendimento automatico. Prima di Amazon, Matt ha lavorato come post-doc eseguendo simulazioni di fisica delle particelle in Germania e in una vita precedente, come responsabile della produzione di dispositivi di impianto medico radioattivi in ​​una startup. Ha conseguito un dottorato di ricerca in Fisica presso l'Università del Michigan.