Costruisci un flusso di lavoro MLOps end-to-end per l’ispezione visiva della qualità al limite – Parte 3

Costruisci un flusso di lavoro MLOps end-to-end per l'ispezione visiva di qualità ottimale - Parte 3

Questo è il terzo capitolo della nostra serie in cui progettiamo ed implementiamo una pipeline MLOps per l’ispezione visiva della qualità sul campo. In questo articolo, ci concentriamo su come automatizzare la parte di deploy sul campo della pipeline MLOps end-to-end. Ti mostriamo come utilizzare AWS IoT Greengrass per gestire l’inferenza del modello sul campo e come automatizzare il processo utilizzando AWS Step Functions e altri servizi AWS.

Panoramica della soluzione

Nel Parte 1 di questa serie, abbiamo delineato un’architettura per la nostra pipeline MLOps end-to-end che automatizza l’intero processo di machine learning (ML), dall’etichettatura dei dati all’addestramento e al deploy del modello sul campo. Nel Parte 2, abbiamo mostrato come automatizzare l’etichettatura e l’addestramento dei modelli nella pipeline.

Il caso d’uso di esempio utilizzato per questa serie è una soluzione di ispezione visiva della qualità che può rilevare difetti su targhette metalliche, che puoi implementare come parte di un processo di produzione. Il diagramma seguente mostra l’architettura ad alto livello della pipeline MLOps che abbiamo definito all’inizio di questa serie. Se non l’hai ancora letto, ti consigliamo di dare un’occhiata alla Parte 1.

• Perfezionamento rapido ed economico LLaMA 2 con AWS Trainium
• Migliora la qualità delle previsioni nei modelli di classificazione personalizzati con Amazon Comprehend
• Elaborazione intelligente dei documenti con i servizi di intelligenza artificiale AWS e Amazon Bedrock

Automazione del deploy sul campo di un modello ML

Dopo che un modello di ML è stato addestrato e valutato, deve essere deployato in un sistema di produzione per generare valore commerciale tramite la previsione dei dati in ingresso. Questo processo può diventare rapidamente complesso in un ambiente sul campo in cui i modelli devono essere deployati ed eseguiti su dispositivi che spesso si trovano lontani dall’ambiente cloud in cui i modelli sono stati addestrati. Ecco alcune delle sfide uniche del machine learning sul campo:

• I modelli di ML spesso devono essere ottimizzati a causa delle limitazioni di risorse sui dispositivi sul campo
• I dispositivi sul campo non possono essere ridistribuiti o sostituiti come un server nel cloud, quindi è necessario un processo robusto di deploy del modello e gestione dei dispositivi
• La comunicazione tra i dispositivi e il cloud deve essere efficiente e sicura perché spesso attraversa reti a bassa larghezza di banda non attendibili

Vediamo come possiamo affrontare queste sfide con i servizi AWS in aggiunta all’esportazione del modello nel formato ONNX, che ci consente ad esempio di applicare ottimizzazioni come la quantizzazione per ridurre la dimensione del modello per dispositivi con vincoli. ONNX fornisce inoltre runtime ottimizzati per le piattaforme hardware sul campo più comuni.

Scomponendo il processo di deploy sul campo, sono necessari due componenti:

• Un meccanismo di deploy per la consegna del modello, che include il modello stesso e una logica di business per gestire ed interagire con il modello
• Un motore di flusso di lavoro che possa orchestrare l’intero processo per renderlo robusto e ripetibile

In questo esempio, utilizziamo diversi servizi AWS per costruire il nostro meccanismo di deploy sul campo automatizzato, che integra tutte le componenti necessarie che abbiamo discusso.

Innanzitutto, simuliamo un dispositivo sul campo. Per rendere più semplice per te seguire l’intero flusso di lavoro, utilizziamo un’istanza di Amazon Elastic Compute Cloud (Amazon EC2) per simulare un dispositivo sul campo installando il software AWS IoT Greengrass Core. Puoi anche utilizzare le istanze EC2 per convalidare le diverse componenti in un processo di QA prima del deploy su un dispositivo di produzione sul campo effettivo. AWS IoT Greengrass è un framework di runtime edge open-source per l’Internet of Things (IoT) e un servizio cloud che ti aiuta a creare, deployare e gestire il software sui dispositivi edge. AWS IoT Greengrass riduce lo sforzo necessario per creare, deployare e gestire il software sui dispositivi edge in modo sicuro e scalabile. Dopo aver installato il software AWS IoT Greengrass Core sul tuo dispositivo, puoi aggiungere o rimuovere funzionalità e componenti e gestire le applicazioni dei tuoi dispositivi IoT utilizzando AWS IoT Greengrass. Offre molte componenti integrate per semplificarti la vita, come le componenti StreamManager e MQTT broker, che puoi utilizzare per comunicare in modo sicuro con il cloud, supportando la crittografia end-to-end. Puoi utilizzare queste funzionalità per caricare i risultati dell’inferenza e le immagini in modo efficiente.

In un ambiente di produzione, avresti tipicamente una telecamera industriale che fornisce immagini per le quali il modello ML dovrebbe produrre previsioni. Per la nostra configurazione, simuliamo questo input di immagine caricando un set predefinito di immagini in una specifica directory sul dispositivo edge. Quindi utilizziamo queste immagini come input di inferenza per il modello.

Abbiamo suddiviso l’intero processo di distribuzione e inferenza in tre passaggi consecutivi per distribuire un modello ML allenato nel cloud in un ambiente edge e utilizzarlo per le previsioni:

1. Preparazione – Confezionare il modello allenato per la distribuzione edge.
2. Distribuzione – Trasferimento dei componenti del modello e dell’inferenza dal cloud al dispositivo edge.
3. Inferenza – Caricare il modello ed eseguire il codice di inferenza per le previsioni sull’immagine.

Il diagramma di architettura seguente mostra i dettagli di questo processo a tre fasi e come l’abbiamo implementato con i servizi AWS.

Nelle sezioni seguenti, discutiamo i dettagli di ogni passaggio e mostriamo come incorporare questo processo in un flusso di lavoro di orchestrazione e CI/CD automatizzato e ripetibile sia per i modelli ML che per il codice di inferenza corrispondente.

Preparazione

I dispositivi edge spesso hanno risorse di calcolo e memoria limitate rispetto a un ambiente cloud in cui potenti CPU e GPU possono eseguire facilmente i modelli ML. Diverse tecniche di ottimizzazione del modello consentono di personalizzare un modello per una piattaforma software o hardware specifica per aumentare la velocità di previsione senza perdere precisione.

In questo esempio, abbiamo esportato il modello allenato nel flusso di lavoro di addestramento nel formato ONNX per la portabilità, possibili ottimizzazioni e tempi di esecuzione edge ottimizzati, e abbiamo registrato il modello all’interno del Registro dei modelli Amazon SageMaker. In questo passaggio, creiamo un nuovo componente di modello Greengrass che includa l’ultimo modello registrato per la distribuzione successiva.

Distribuzione

Un meccanismo di distribuzione sicuro e affidabile è fondamentale quando si distribuisce un modello dal cloud a un dispositivo edge. Poiché AWS IoT Greengrass incorpora già un sistema di distribuzione edge robusto e sicuro, lo utilizziamo per i nostri scopi di distribuzione. Prima di esaminare nel dettaglio il nostro processo di distribuzione, facciamo un breve riepilogo di come funzionano le distribuzioni di AWS IoT Greengrass. Al cuore del sistema di distribuzione di AWS IoT Greengrass ci sono i componenti, che definiscono i moduli software distribuiti su un dispositivo edge che esegue AWS IoT Greengrass Core. Questi possono essere componenti privati che si creano o componenti pubblici forniti sia da AWS che dalla più ampia comunità Greengrass. Diversi componenti possono essere raggruppati insieme come parte di una distribuzione. Una configurazione di distribuzione definisce i componenti inclusi in una distribuzione e i dispositivi di destinazione della distribuzione. Può essere definita in un file di configurazione di distribuzione (JSON) o tramite la console AWS IoT Greengrass durante la creazione di una nuova distribuzione.

Creamo i seguenti due componenti Greengrass, che poi vengono distribuiti al dispositivo edge tramite il processo di distribuzione:

• Modello confezionato (componente privato) – Questo componente contiene il modello ML addestrato nel formato ONNX.
• Codice di inferenza (componente privato) – Oltre al modello ML stesso, è necessario implementare una logica dell’applicazione per gestire compiti come la preparazione dei dati, la comunicazione con il modello per l’inferenza e l’elaborazione dei risultati dell’inferenza. Nel nostro esempio, abbiamo sviluppato un componente privato basato su Python per gestire i seguenti compiti:
  • Installare i componenti di runtime richiesti, come il pacchetto Python Ultralytics YOLOv8.
  • Invece di acquisire immagini da uno streaming live di una telecamera, simuliamo caricando immagini preparate da una directory specifica e preparando i dati dell’immagine secondo i requisiti di input del modello.
  • Eseguire chiamate di inferenza sul modello caricato con i dati dell’immagine preparati.
  • Controllare le previsioni e caricare i risultati dell’inferenza nel cloud.

Se vuoi approfondire il codice di inferenza che abbiamo creato, fai riferimento al repository GitHub.

Inferenza

Il processo di inferenza del modello sul dispositivo edge avvia automaticamente dopo il completamento della distribuzione dei componenti sopra menzionati. Il componente di inferenza personalizzato esegue periodicamente il modello di machine learning con immagini da una directory locale. Il risultato di inferenza per immagine restituito dal modello è un tensore con i seguenti contenuti:

• Punteggi di confidenza – Quanto sicuro è il modello riguardo alle rilevazioni
• Coordinate oggetto – Le coordinate dell’oggetto scratch (x, y, larghezza, altezza) rilevato dal modello nell’immagine

Nel nostro caso, il componente di inferenza si occupa di inviare i risultati di inferenza a un particolare argomento MQTT su AWS IoT dove possono essere letti per ulteriori elaborazioni. Questi messaggi possono essere visualizzati tramite il client di test MQTT sulla console di AWS IoT per il debug. In un ambiente di produzione, è possibile decidere di notificare automaticamente un altro sistema che si occupa di rimuovere i tag metallici difettosi dalla linea di produzione.

Orchestrazione

Come visto nelle sezioni precedenti, sono necessari diversi passaggi per preparare e distribuire un modello di machine learning, il codice di inferenza corrispondente e l’ambiente di esecuzione o agente richiesto su un dispositivo edge. Step Functions è un servizio completamente gestito che consente di orchestrare questi passaggi dedicati e progettare il flusso di lavoro sotto forma di una macchina a stati. La natura serverless di questo servizio e le capacità native di Step Functions come le integrazioni API dei servizi AWS consentono di configurare rapidamente questo flusso di lavoro. Le capacità incorporate come i ripetuti tentativi o la registrazione sono punti importanti per creare orchestratori robusti. Per ulteriori dettagli sulla definizione della macchina a stati stessa, fare riferimento al repository GitHub o controllare il grafico della macchina a stati sulla console di Step Functions dopo aver distribuito questo esempio nel proprio account.

Distribuzione dell’infrastruttura e integrazione in CI/CD

Il flusso di lavoro CI/CD per integrare e creare tutti i componenti infrastrutturali richiesti segue lo stesso modello illustrato in Parte 1 di questa serie. Utilizziamo il AWS Cloud Development Kit (AWS CDK) per distribuire le pipeline richieste da AWS CodePipeline.

Lezioni apprese

Ci sono molti modi per costruire un’architettura per un sistema di distribuzione di modelli di machine learning automatizzato, robusto e sicuro sul bordo, che spesso dipendono molto dal caso d’uso e dai requisiti. Tuttavia, ecco alcune lezioni che vorremmo condividere con voi:

• Valuta in anticipo se i requisiti aggiuntivi di risorse di calcolo di AWS IoT Greengrass si adattano al tuo caso, specialmente con dispositivi edge limitati.
• Stabilisci un meccanismo di distribuzione che integri una fase di verifica degli artefatti distribuiti prima dell’esecuzione sul dispositivo edge per garantire che non vi siano state manipolazioni durante la trasmissione.
• È buona pratica mantenere i componenti di distribuzione su AWS IoT Greengrass modulari e autosufficienti per poterli distribuire indipendentemente. Ad esempio, se si dispone di un modulo di codice di inferenza relativamente piccolo ma un modello di machine learning molto grande in termini di dimensioni, non sempre si desidera distribuirli entrambi se è cambiato solo il codice di inferenza. Questo è particolarmente importante quando si dispone di una larghezza di banda limitata o di una connettività costosa del dispositivo edge.

Conclusioni

Questo conclude la nostra serie di tre parti sulla costruzione di una pipeline MLOps end-to-end per l’ispezione visiva di qualità sul bordo. Abbiamo esaminato le sfide aggiuntive che derivano dalla distribuzione di un modello di machine learning sul bordo come il packaging del modello o la complessa orchestrazione della distribuzione. Abbiamo implementato la pipeline in modo completamente automatizzato in modo da poter mettere i nostri modelli in produzione in modo robusto, sicuro, ripetibile e tracciabile. Sentitevi liberi di utilizzare l’architettura e l’implementazione sviluppate in questa serie come punto di partenza per il vostro prossimo progetto abilitato da ML. Se avete domande su come progettare e costruire un sistema simile per il vostro ambiente, per favore contattateci. Per altri argomenti e casi d’uso, fare riferimento ai nostri blog su Machine Learning e IoT.