Creare un flusso di lavoro MLOps end-to-end per l’ispezione visiva della qualità sul bordo – Parte 1

Creare un flusso di lavoro completo MLOps per l'ispezione visiva della qualità sul bordo - Parte 1

Una distribuzione di successo di un modello di machine learning (ML) in un ambiente di produzione si basa fortemente su un flusso di lavoro di ML end-to-end. Sebbene lo sviluppo di un tale flusso di lavoro possa essere impegnativo, diventa ancora più complesso quando si tratta di un caso d’uso di ML distribuito (edge ML). Il machine learning al limite (edge) è un concetto che porta la capacità di eseguire modelli di ML localmente su dispositivi edge. Per distribuire, monitorare e mantenere questi modelli sul limite, è necessario un robusto flusso di lavoro di MLOps. Un flusso di lavoro di MLOps consente di automatizzare l’intero ciclo di vita di ML, dall’etichettatura dei dati all’allenamento e alla distribuzione del modello.

L’implementazione di un flusso di lavoro di MLOps al limite introduce complessità aggiuntive che rendono i processi di automazione, integrazione e manutenzione più sfidanti a causa dell’aumento dei costi operativi coinvolti. Tuttavia, l’utilizzo di servizi appositamente progettati come Amazon SageMaker e AWS IoT Greengrass ti consente di ridurre significativamente questo sforzo. In questa serie, ti guideremo nel processo di architettura e costruzione di un flusso di lavoro di MLOps end-to-end integrato per un caso d’uso di visione artificiale al limite utilizzando SageMaker, AWS IoT Greengrass e l’AWS Cloud Development Kit (AWS CDK).

Questo post si concentra sulla progettazione dell’architettura complessiva del flusso di lavoro di MLOps; la Parte 2 e la Parte 3 di questa serie sono incentrate sull’implementazione dei singoli componenti. Abbiamo fornito un’implementazione di esempio nel repository GitHub di accompagnamento per permetterti di provarlo. Se stai iniziando con MLOps al limite su AWS, consulta MLOps al limite con Amazon SageMaker Edge Manager e AWS IoT Greengrass per una panoramica e architettura di riferimento.

Caso d’uso: Ispezione della qualità dei tag in metallo

Come ingegnere di ML, è importante capire il caso di business su cui si sta lavorando. Quindi, prima di entrare nell’architettura del flusso di lavoro di MLOps, guardiamo al caso d’uso di esempio di questo post. Immagina una linea di produzione di un produttore che incide tag in metallo per creare etichette per bagagli personalizzate. Il processo di controllo di qualità è costoso perché i tag in metallo grezzo devono essere ispezionati manualmente per difetti come graffi. Per rendere questo processo più efficiente, utilizziamo il ML per rilevare i tag difettosi in anticipo nel processo. Questo aiuta a evitare costosi difetti in fasi successive del processo di produzione. Il modello dovrebbe identificare possibili difetti come graffi in quasi tempo reale e marcarli. Negli ambienti di produzione, spesso si deve affrontare la mancanza di connettività o la banda limitata e un aumento della latenza. Pertanto, vogliamo implementare una soluzione di ML sul limite per l’ispezione visiva della qualità che può eseguire l’elaborazione localmente in fabbrica e ridurre i requisiti in termini di connettività. Per mantenere l’esempio semplice, addestriamo un modello che identifica i graffi rilevati con bounding box. L’immagine seguente è un esempio di un tag dal nostro insieme di dati con tre graffi marcati.

• Microsoft si impegna al massimo con l’IA attraverso Copilot nell’ultima aggiornamento di Windows
• Tom Hanks avverte i fan dei Deepfake generati dall’IA
• LangChain 101 Parte 2c. Affinare LLMs con PEFT, LORA e RL

Definizione dell’architettura del flusso di lavoro

Ora abbiamo acquisito chiarezza sul nostro caso d’uso e sul problema ML specifico che vogliamo affrontare, che riguarda la rilevazione degli oggetti sul limite. Ora è il momento di stilare un’architettura per il nostro flusso di lavoro di MLOps. In questa fase, non stiamo ancora guardando tecnologie o servizi specifici, ma piuttosto i componenti di alto livello del nostro flusso di lavoro. Per poter riprogettare rapidamente e distribuire, dobbiamo automatizzare l’intero processo end-to-end: dall’etichettatura dei dati, all’addestramento, all’inferenza. Tuttavia, ci sono alcune sfide che rendono particolarmente difficile configurare un flusso di lavoro per un caso sul limite:

• Costruire diverse parti di questo processo richiede competenze diverse. Ad esempio, l’etichettatura dei dati e la formazione richiedono una forte focalizzazione sulla scienza dei dati, la distribuzione sul bordo richiede uno specialista dell’Internet of Things (IoT) e l’automazione dell’intero processo viene solitamente eseguita da qualcuno con competenze in DevOps.
• A seconda della tua organizzazione, l’intero processo potrebbe essere implementato anche da più team. Nel nostro caso d’uso, lavoriamo nell’ipotesi che squadre separate siano responsabili dell’etichettatura, della formazione e della distribuzione.
• La presenza di più ruoli e competenze significa requisiti diversi in termini di strumenti e processi. Ad esempio, gli scienziati dei dati potrebbero voler monitorare e lavorare con il loro ambiente di lavoro familiare. Gli ingegneri MLOps desiderano lavorare utilizzando strumenti di infrastructure as code (IaC) e potrebbero essere più familiari con la Console di gestione AWS.

Cosa significa tutto questo per l’architettura del nostro flusso di lavoro?

Innanzitutto, è cruciale definire chiaramente i componenti principali del sistema end-to-end che permette ai diversi team di lavorare in modo indipendente. In secondo luogo, devono essere definite interfacce ben definite tra i team per migliorare l’efficienza della collaborazione. Queste interfacce aiutano a ridurre le interruzioni tra i team, consentendo loro di modificare i loro processi interni come richiesto purché rispettino le interfacce definite. Il diagramma seguente illustra come potrebbe apparire tutto ciò per il nostro flusso di lavoro nella visione artificiale.

Esaminiamo ora l’architettura complessiva del flusso di lavoro MLOps nel dettaglio:

1. Il processo inizia con una raccolta di immagini grezze di etichette metalliche, che vengono acquisite utilizzando un dispositivo fotocamera sul bordo nell’ambiente di produzione per formare un dataset di formazione iniziale.
2. Il passo successivo prevede l’etichettatura di queste immagini e l’individuazione dei difetti utilizzando bounding box. È essenziale versionare il dataset etichettato, garantendo la tracciabilità e la responsabilità dei dati di formazione utilizzati.
3. Dopo aver ottenuto un dataset etichettato, possiamo procedere con la formazione, il raffinamento, la valutazione e la versioning del nostro modello.
4. Quando siamo soddisfatti delle prestazioni del nostro modello, possiamo distribuire il modello su un dispositivo sul bordo ed eseguire inferenze in tempo reale sul bordo.
5. Mentre il modello opera in produzione, il dispositivo fotocamera sul bordo genera dati di immagine preziosi contenenti difetti e casi limite precedentemente non osservati. Possiamo utilizzare questi dati per migliorare ulteriormente le prestazioni del nostro modello. Per fare ciò, salviamo le immagini per le quali il modello predice con bassa confidenza o fa previsioni errate. Queste immagini vengono quindi aggiunte nuovamente al nostro dataset grezzo, avviando nuovamente l’intero processo.

È importante notare che i dati di immagine grezzi, il dataset etichettato e il modello addestrato fungono da interfacce ben definite tra i diversi flussi di lavoro. Gli ingegneri MLOps e gli scienziati dei dati hanno la flessibilità di scegliere le tecnologie all’interno dei loro flussi di lavoro purché producano in modo coerente questi artefatti. In modo significativo, abbiamo stabilito un ciclo di feedback chiuso. Previsioni errate o a bassa confidenza fatte in produzione possono essere utilizzate per migliorare regolarmente il nostro dataset e per ritrained automaticamente e potenziare il modello.

Architettura obiettivo

Ora che l’architettura di alto livello è stabilita, è il momento di andare un livello più in profondità e vedere come potremmo costruire tutto questo con i servizi AWS. Si noti che l’architettura mostrata in questo articolo assume che si desideri avere il pieno controllo dell’intero processo di scienza dei dati. Tuttavia, se si sta iniziando con l’ispezione della qualità sul bordo, si consiglia di utilizzare Amazon Lookout for Vision. Fornisce un modo per addestrare il proprio modello di ispezione della qualità senza dover costruire, mantenere o comprendere il codice di ML. Per ulteriori informazioni, consultare Amazon Lookout for Vision now supports visual inspection of product defects at the edge.

Tuttavia, se si desidera avere il pieno controllo, il diagramma seguente mostra come potrebbe apparire un’architettura.

Simile a prima, procediamo passo passo attraverso il flusso di lavoro e identifichiamo quali servizi AWS soddisfano le nostre esigenze:

1. Amazon Simple Storage Service (Amazon S3) viene utilizzato per archiviare i dati delle immagini grezze perché ci fornisce una soluzione di archiviazione a basso costo.
2. Il flusso di lavoro di etichettatura viene orchestrato utilizzando AWS Step Functions, un motore di flusso di lavoro senza server che semplifica l’orchestrazione dei passaggi del flusso di lavoro di etichettatura. Come parte di questo flusso di lavoro, utilizziamo Amazon SageMaker Ground Truth per automatizzare completamente l’etichettatura utilizzando lavori di etichettatura e forze lavoro umane gestite. AWS Lambda viene utilizzato per preparare i dati, avviare i lavori di etichettatura e archiviare le etichette in Amazon SageMaker Feature Store.
3. SageMaker Feature Store archivia le etichette. Ci consente di gestire e condividere centralmente le nostre funzionalità e ci fornisce funzionalità di versioning dei dati integrate, che rendono il nostro flusso di lavoro più robusto.
4. Orchestriamo la costruzione del modello e il flusso di lavoro di addestramento utilizzando Amazon SageMaker Pipelines. Si integra con le altre funzionalità di SageMaker richieste tramite passaggi integrati. Vengono utilizzati lavori di addestramento di SageMaker per automatizzare l’addestramento del modello e lavori di elaborazione di SageMaker per preparare i dati e valutare le prestazioni del modello. In questo esempio, stiamo utilizzando il pacchetto e l’architettura del modello Ultralytics YOLOv8 di Python per addestrare ed esportare un modello di rilevazione oggetti nel formato modello ML ONNX per la portabilità.
5. Se le prestazioni sono accettabili, il modello addestrato viene registrato in Amazon SageMaker Model Registry con un numero di versione incrementale allegato. Funge da interfaccia tra l’addestramento del modello e i passaggi di distribuzione edge. Gestiamo anche lo stato di approvazione dei modelli qui. Simile agli altri servizi utilizzati, è completamente gestito, quindi non dobbiamo occuparci di gestire la nostra infrastruttura.
6. Il flusso di lavoro di distribuzione edge viene automatizzato utilizzando Step Functions, simile al flusso di lavoro di etichettatura. Possiamo utilizzare le integrazioni API di Step Functions per chiamare facilmente le varie API di servizio AWS richieste come AWS IoT Greengrass per creare nuovi componenti di modello e successivamente distribuire i componenti al dispositivo edge.
7. AWS IoT Greengrass viene utilizzato come ambiente di runtime del dispositivo edge. Gestisce il ciclo di vita della distribuzione per il nostro modello e i componenti di inferenza al limite. Ci consente di distribuire facilmente nuove versioni del nostro modello e dei componenti di inferenza utilizzando semplici chiamate API. Inoltre, i modelli ML al limite di solito non vengono eseguiti in isolamento; possiamo utilizzare i vari componenti forniti da AWS e community di AWS IoT Greengrass per connettersi ad altri servizi.

L’architettura delineata assomiglia alla nostra architettura ad alto livello mostrata in precedenza. Amazon S3, SageMaker Feature Store e SageMaker Model Registry fungono da interfacce tra i diversi flussi di lavoro. Per ridurre al minimo lo sforzo per eseguire e gestire la soluzione, utilizziamo servizi gestiti e senza server ogni volta che è possibile.

Integrazione in un robusto sistema CI/CD

L’etichettatura dei dati, l’addestramento del modello e i passaggi di distribuzione edge sono fondamentali per la nostra soluzione. Pertanto, qualsiasi modifica relativa al codice sottostante o ai dati in una di quelle parti dovrebbe innescare una nuova esecuzione dell’intero processo di orchestrazione. Per raggiungere questo obiettivo, è necessario integrare questo flusso di lavoro in un sistema CI/CD che ci consenta di distribuire automaticamente le modifiche del codice e dell’infrastruttura da un repository di codice versionato in produzione. Simile all’architettura precedente, l’autonomia del team è un aspetto importante qui. Il diagramma seguente mostra come potrebbe apparire utilizzando i servizi AWS.

Esaminiamo l’architettura CI/CD:

1. AWS CodeCommit funge da nostro repository Git. Per semplicità, nel nostro esempio fornito, abbiamo separato le diverse parti (etichettatura, addestramento del modello, distribuzione edge) tramite sottocartelle in un singolo repository Git. In uno scenario del mondo reale, ogni team potrebbe utilizzare repository diversi per ogni parte.
2. La distribuzione dell’infrastruttura è automatizzata utilizzando AWS CDK e ogni parte (etichettatura, addestramento e edge) ha la propria applicazione AWS CDK per consentire distribuzioni indipendenti.
3. La funzionalità del pipeline AWS CDK utilizza AWS CodePipeline per automatizzare la distribuzione dell’infrastruttura e del codice.
4. Il AWS CDK distribuisce due pipeline di codice per ogni passaggio: una pipeline di asset e una pipeline di flusso di lavoro. Abbiamo separato il flusso di lavoro dal rilascio degli asset per consentire l’avvio separato dei flussi di lavoro in caso di assenza di modifiche agli asset (ad esempio, quando sono disponibili nuove immagini per l’addestramento).
   • La pipeline di codice di asset distribuisce tutta l’infrastruttura necessaria per l’esecuzione corretta del flusso di lavoro, come i ruoli di AWS Identity and Access Management (IAM), le funzioni Lambda e le immagini dei contenitori utilizzate durante l’addestramento.
   • La pipeline di codice del flusso di lavoro esegue effettivamente il flusso di lavoro di etichettatura, addestramento o distribuzione edge.
5. Le pipeline degli asset vengono attivate automaticamente alla commit e quando una pipeline di flusso di lavoro precedente è completa.
6. Il processo completo viene avviato secondo un programma utilizzando una regola di Amazon EventBridge per i riaddestramenti regolari.

Con l’integrazione CI/CD, l’intera catena end-to-end è ora completamente automatizzata. Il pipeline viene attivato ogni volta che vengono apportate modifiche al codice nel nostro repository Git e secondo un programma per adattarsi alle modifiche dei dati.

Pensare in avanti

L’architettura della soluzione descritta rappresenta i componenti di base per costruire un flusso di lavoro MLOps end-to-end sul campo. Tuttavia, a seconda delle vostre esigenze, potreste pensare di aggiungere funzionalità aggiuntive. Ecco alcuni esempi:

• Introdurre una configurazione multi-account per migliorare la postura di sicurezza. Per ulteriori dettagli, consultare MLOps sul campo con Amazon SageMaker Edge Manager e AWS IoT Greengrass.
• Mettere l’architettura in un layout in modo che possa essere riutilizzata da altri team, ad esempio utilizzando SageMaker Projects. Per ulteriori informazioni, consultare Build Custom SageMaker Project Templates – Best Practices.

Conclusione

In questo post, abbiamo delineato la nostra architettura per la costruzione di un flusso di lavoro MLOps end-to-end per l’ispezione visiva della qualità sul campo utilizzando i servizi AWS. Questa architettura semplifica l’intero processo, comprensivo dell’etichettatura dei dati, dello sviluppo del modello e della distribuzione sul campo, consentendoci di addestrare e implementare nuove versioni del modello rapidamente e in modo affidabile. Con i servizi serverless e gestiti, possiamo concentrarci sulla consegna del valore aziendale anziché sulla gestione dell’infrastruttura.

In Parte 2 di questa serie, approfondiremo ancora di più e analizzeremo l’implementazione di questa architettura con maggior dettaglio, in particolare l’etichettatura e la costruzione del modello. Se volete passare direttamente al codice, potete consultare il nostro repo GitHub associato.