Costruisci una pipeline MLOps end-to-end per l'ispezione della qualità visiva sull'edge – Parte 1

Ripubblicato da Platone

Seguaci: 0

Una distribuzione di successo di un modello di machine learning (ML) in un ambiente di produzione dipende in larga misura da una pipeline ML end-to-end. Sebbene lo sviluppo di una pipeline di questo tipo possa essere impegnativo, diventa ancora più complesso quando si ha a che fare con un file caso d'uso di Edge ML. L'apprendimento automatico all'edge è un concetto che porta la capacità di eseguire modelli ML localmente sui dispositivi edge. Per distribuire, monitorare e mantenere questi modelli all'edge, è necessaria una solida pipeline MLOps. Una pipeline MLOps consente di automatizzare l'intero ciclo di vita del machine learning, dall'etichettatura dei dati all'addestramento e alla distribuzione del modello.

L'implementazione di una pipeline MLOps all'edge introduce ulteriori complessità che rendono i processi di automazione, integrazione e manutenzione più impegnativi a causa del maggiore sovraccarico operativo coinvolto. Tuttavia, utilizzando servizi appositamente creati come Amazon Sage Maker ed AWS IoT Greengrass consente di ridurre notevolmente questo sforzo. In questa serie ti guideremo attraverso il processo di progettazione e creazione di una pipeline MLOps end-to-end integrata per un caso d'uso di visione artificiale all'edge utilizzando SageMaker, AWS IoT Greengrass e il Kit di sviluppo cloud AWS (AWSCDK).

Questo post si concentra sulla progettazione dell'architettura complessiva della pipeline MLOps; Parte 2 ed Parte 3 di questa serie si concentrano sull'implementazione dei singoli componenti. Abbiamo fornito un esempio di implementazione nella documentazione allegata Repository GitHub per farti provare tu stesso. Se hai appena iniziato con MLOps all'edge su AWS, fai riferimento a MLOp all'edge con Amazon SageMaker Edge Manager e AWS IoT Greengrass per una panoramica e un'architettura di riferimento.

Caso d'uso: ispezione della qualità delle etichette metalliche

In qualità di ingegnere ML, è importante comprendere il business case su cui stai lavorando. Quindi, prima di approfondire l'architettura della pipeline MLOps, diamo un'occhiata al caso d'uso di esempio per questo post. Immagina la linea di produzione di un produttore che incide etichette metalliche per creare etichette per bagagli personalizzate. Il processo di garanzia della qualità è costoso perché le etichette in metallo grezzo devono essere ispezionate manualmente per individuare difetti come graffi. Per rendere questo processo più efficiente, utilizziamo il machine learning per rilevare i tag difettosi nelle prime fasi del processo. Ciò aiuta a evitare costosi difetti nelle fasi successive del processo di produzione. Il modello dovrebbe identificare possibili difetti come graffi in tempo quasi reale e contrassegnarli. Negli ambienti di produzione, spesso è necessario fare i conti con la mancanza di connettività, con una larghezza di banda limitata e con una maggiore latenza. Pertanto, desideriamo implementare una soluzione ML on-edge per l'ispezione visiva della qualità in grado di eseguire inferenze localmente in officina e ridurre i requisiti in termini di connettività. Per mantenere il nostro esempio semplice, addestriamo un modello che contrassegna i graffi rilevati con riquadri di delimitazione. L'immagine seguente è un esempio di un tag del nostro set di dati con tre graffi contrassegnati.

Definizione dell'architettura della pipeline

Ora abbiamo acquisito chiarezza sul nostro caso d'uso e sullo specifico problema ML che intendiamo affrontare, che ruota attorno al rilevamento di oggetti sul perimetro. Ora è il momento di abbozzare un'architettura per la nostra pipeline MLOps. In questa fase non stiamo ancora guardando a tecnologie o servizi specifici, ma piuttosto ai componenti di alto livello della nostra pipeline. Per riqualificare e implementare rapidamente, dobbiamo automatizzare l'intero processo end-to-end: dall'etichettatura dei dati, alla formazione, all'inferenza. Tuttavia, ci sono alcune sfide che rendono particolarmente difficile la creazione di una pipeline per un caso limite:

Costruire parti diverse di questo processo richiede competenze diverse. Ad esempio, l'etichettatura e la formazione dei dati hanno un forte focus sulla scienza dei dati, l'implementazione edge richiede uno specialista di Internet of Things (IoT) e l'automazione dell'intero processo viene solitamente eseguita da qualcuno con competenze DevOps.
A seconda della tua organizzazione, l'intero processo potrebbe anche essere implementato da più team. Per il nostro caso d'uso, stiamo lavorando presupponendo che team separati siano responsabili dell'etichettatura, della formazione e della distribuzione.
Più ruoli e competenze implicano requisiti diversi in termini di strumenti e processi. Ad esempio, i data scientist potrebbero voler monitorare e lavorare con il loro ambiente notebook familiare. Gli ingegneri di MLOps desiderano lavorare utilizzando gli strumenti Infrastructure as Code (IaC) e potrebbero avere più familiarità con Console di gestione AWS.

Cosa significa questo per la nostra architettura di pipeline?

In primo luogo, è fondamentale definire chiaramente i componenti principali del sistema end-to-end che consente ai diversi team di lavorare in modo indipendente. In secondo luogo, è necessario definire interfacce ben definite tra i team per migliorare l’efficienza della collaborazione. Queste interfacce aiutano a ridurre al minimo le interruzioni tra i team, consentendo loro di modificare i propri processi interni secondo necessità purché aderiscano alle interfacce definite. Il diagramma seguente illustra come potrebbe apparire per la nostra pipeline di visione artificiale.

Esaminiamo nel dettaglio l'architettura complessiva della pipeline MLOps:

Il processo inizia con una raccolta di immagini grezze di etichette metalliche, che vengono catturate utilizzando un dispositivo edge camera nell'ambiente di produzione per formare un set di dati di addestramento iniziale.
Il passaggio successivo prevede l'etichettatura di queste immagini e la marcatura dei difetti utilizzando i riquadri di delimitazione. È essenziale creare versioni del set di dati etichettato, garantendo tracciabilità e responsabilità per i dati di addestramento utilizzati.
Dopo aver ottenuto un set di dati etichettato, possiamo procedere con l'addestramento, il perfezionamento, la valutazione e il controllo delle versioni del nostro modello.
Quando siamo soddisfatti delle prestazioni del nostro modello, possiamo distribuire il modello su un dispositivo edge ed eseguire inferenze in tempo reale sull'edge.
Mentre il modello è in produzione, il dispositivo edge camera genera preziosi dati immagine contenenti difetti e casi limite mai visti prima. Possiamo utilizzare questi dati per migliorare ulteriormente le prestazioni del nostro modello. A tale scopo, salviamo le immagini per le quali il modello prevede con scarsa confidenza o fa previsioni errate. Queste immagini vengono quindi aggiunte nuovamente al nostro set di dati grezzi, avviando nuovamente l'intero processo.

È importante notare che i dati dell'immagine grezza, il set di dati etichettati e il modello addestrato fungono da interfacce ben definite tra le pipeline distinte. Gli ingegneri e i data scientist di MLOps hanno la flessibilità di scegliere le tecnologie all'interno delle loro pipeline purché producano costantemente questi artefatti. La cosa più significativa è che abbiamo stabilito un ciclo di feedback chiuso. Le previsioni errate o poco attendibili effettuate in produzione possono essere utilizzate per aumentare regolarmente il nostro set di dati e riqualificare e migliorare automaticamente il modello.

Architettura di destinazione

Ora che l'architettura di alto livello è stata stabilita, è tempo di andare a un livello più profondo e vedere come potremmo realizzarla con i servizi AWS. Tieni presente che l'architettura mostrata in questo post presuppone che tu voglia assumere il pieno controllo dell'intero processo di data science. Tuttavia, se hai appena iniziato con l'ispezione di qualità all'edge, ti consigliamo Amazon Lookout per la visione. Fornisce un modo per addestrare il proprio modello di ispezione della qualità senza dover creare, mantenere o comprendere il codice ML. Per ulteriori informazioni, fare riferimento a Amazon Lookout for Vision ora supporta l'ispezione visiva dei difetti del prodotto ai margini.

Tuttavia, se vuoi avere il pieno controllo, il diagramma seguente mostra come potrebbe apparire un'architettura.

Analogamente a prima, esaminiamo il flusso di lavoro passo dopo passo e identifichiamo quali servizi AWS soddisfano i nostri requisiti:

Servizio di archiviazione semplice Amazon (Amazon S3) viene utilizzato per archiviare i dati delle immagini grezze perché ci fornisce una soluzione di archiviazione a basso costo.
Il flusso di lavoro di etichettatura viene orchestrato utilizzando Funzioni AWS Step, un motore di flusso di lavoro serverless che semplifica l'orchestrazione dei passaggi del flusso di lavoro di etichettatura. Come parte di questo flusso di lavoro, utilizziamo Amazon SageMaker verità fondamentale automatizzare completamente l'etichettatura utilizzando lavori di etichettatura e forza lavoro umana gestita. AWS Lambda viene utilizzato per preparare i dati, avviare i lavori di etichettatura e archiviare le etichette Negozio di funzionalità Amazon SageMaker.
SageMaker Feature Store memorizza le etichette. Ci consente di gestire e condividere centralmente le nostre funzionalità e ci fornisce funzionalità integrate di controllo delle versioni dei dati, che rendono la nostra pipeline più solida.
Orchestramo la creazione del modello e la pipeline di formazione utilizzando Pipeline di Amazon SageMaker. Si integra con le altre funzionalità di SageMaker richieste tramite passaggi integrati. Lavori di formazione SageMaker vengono utilizzati per automatizzare l'addestramento del modello e SageMaker Lavori di elaborazione vengono utilizzati per preparare i dati e valutare le prestazioni del modello. In questo esempio, stiamo utilizzando il file Ultralitici YOLOv8 Pacchetto Python e architettura del modello per addestrare ed esportare un modello di rilevamento di oggetti nel file ONNX Formato del modello ML per la portabilità.
Se la prestazione è accettabile, il modello addestrato viene registrato Registro dei modelli di Amazon SageMaker con un numero di versione incrementale allegato. Funziona come la nostra interfaccia tra le fasi di training del modello e di distribuzione edge. Qui gestiamo anche lo stato di approvazione dei modelli. Similmente agli altri servizi utilizzati, è completamente gestito, quindi non dobbiamo occuparci della gestione della nostra infrastruttura.
Il flusso di lavoro di distribuzione perimetrale è automatizzato utilizzando Step Functions, in modo simile al flusso di lavoro di etichettatura. Possiamo utilizzare le integrazioni API di Step Functions per chiamare facilmente le varie API del servizio AWS richieste come AWS IoT Greengrass per creare nuovi componenti del modello e successivamente distribuire i componenti sul dispositivo edge.
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 all'edge. Ci consente di distribuire facilmente nuove versioni del nostro modello e dei componenti di inferenza utilizzando semplici chiamate API. Inoltre, i modelli ML all'edge solitamente non vengono eseguiti in modo isolato; possiamo usare i vari AWS ed comunità componenti forniti di AWS IoT Greengrass per connettersi ad altri servizi.

L'architettura delineata assomiglia alla nostra architettura di alto livello mostrata in precedenza. Amazon S3, SageMaker Feature Store e SageMaker Model Registry fungono da interfacce tra le diverse pipeline. Per ridurre al minimo lo sforzo necessario per eseguire e far funzionare la soluzione, utilizziamo servizi gestiti e serverless ove possibile.

Fusione in un robusto sistema CI/CD

Le fasi di etichettatura dei dati, formazione del modello e distribuzione perimetrale sono fondamentali per la nostra soluzione. Pertanto, qualsiasi modifica relativa al codice o ai dati sottostanti in una qualsiasi di queste parti dovrebbe innescare una nuova esecuzione dell'intero processo di orchestrazione. Per raggiungere questo obiettivo, dobbiamo integrare questa pipeline in un sistema CI/CD che ci consenta di distribuire automaticamente le modifiche al codice e all'infrastruttura da un repository di codice con versione alla produzione. Similmente all’architettura precedente, anche qui l’autonomia del team è un aspetto importante. Il diagramma seguente mostra come potrebbe apparire utilizzando i servizi AWS.

Esaminiamo l'architettura CI/CD:

AWS CodeCommit funge da nostro repository Git. Per motivi di semplicità, nell'esempio fornito, abbiamo separato le parti distinte (etichettatura, training del modello, distribuzione edge) tramite sottocartelle in un unico repository git. In uno scenario reale, ogni team potrebbe utilizzare repository diversi per ciascuna parte.
La distribuzione dell'infrastruttura è automatizzata utilizzando AWS CDK e ogni parte (etichettatura, formazione ed edge) ottiene la propria app AWS CDK per consentire distribuzioni indipendenti.
La funzionalità della pipeline AWS CDK utilizza AWS Code Pipeline per automatizzare l'infrastruttura e le distribuzioni del codice.
AWS CDK distribuisce due pipeline di codice per ogni fase: una pipeline di risorse e una pipeline di flusso di lavoro. Abbiamo separato il flusso di lavoro dalla distribuzione delle risorse per consentirci di avviare i flussi di lavoro separatamente nel caso in cui non vi siano modifiche alle risorse (ad esempio, quando sono disponibili nuove immagini per la formazione).
- La pipeline del codice asset distribuisce tutta l'infrastruttura necessaria per il corretto funzionamento del flusso di lavoro, ad esempio Gestione dell'identità e dell'accesso di AWS (IAM), funzioni Lambda e immagini del contenitore utilizzate durante l'addestramento.
- La pipeline del codice del flusso di lavoro esegue il flusso di lavoro effettivo di etichettatura, formazione o distribuzione edge.
Le pipeline delle risorse vengono attivate automaticamente al momento del commit e al completamento di una pipeline del flusso di lavoro precedente.
L'intero processo viene attivato in base a una pianificazione utilizzando un file Amazon EventBridge regola per la riqualificazione regolare.

Con l'integrazione CI/CD, l'intera catena end-to-end è ora completamente automatizzata. La pipeline viene attivata ogni volta che il codice cambia nel nostro repository git e secondo una pianificazione per accogliere le modifiche dei dati.

Pensare al futuro

L'architettura della soluzione descritta rappresenta i componenti di base per costruire una pipeline MLOps end-to-end all'edge. Tuttavia, a seconda delle tue esigenze, potresti pensare di aggiungere funzionalità aggiuntive. I seguenti sono alcuni esempi:

Conclusione

In questo post, abbiamo delineato la nostra architettura per la creazione di una pipeline MLOps end-to-end per l'ispezione della qualità visiva all'edge utilizzando i servizi AWS. Questa architettura semplifica l'intero processo, comprendendo l'etichettatura dei dati, lo sviluppo del modello e l'implementazione edge, consentendoci di addestrare e implementare in modo rapido e affidabile nuove versioni del modello. Con i servizi serverless e gestiti, possiamo concentrare la nostra attenzione sulla fornitura di valore aziendale piuttosto che sulla gestione dell'infrastruttura.

In Parte 2 di questa serie, approfondiremo un livello e osserveremo l'implementazione di questa architettura in modo più dettagliato, in particolare l'etichettatura e la costruzione del modello. Se vuoi passare direttamente al codice, puoi controllare l'allegato Repository GitHub.

Circa gli autori

Michael Roth è un Senior Solutions Architect presso AWS che supporta i clienti del settore manifatturiero in Germania per risolvere le loro sfide aziendali attraverso la tecnologia AWS. Oltre al lavoro e alla famiglia, è interessato alle auto sportive e gli piace il caffè italiano.

Jörg Wöhrle è un Solutions Architect presso AWS e lavora con clienti manifatturieri in Germania. Con una passione per l'automazione, Joerg ha lavorato come sviluppatore di software, ingegnere DevOps e Site Reliability Engineer nella sua vita pre-AWS. Al di là delle nuvole, è un corridore ambizioso e ama trascorrere del tempo di qualità con la sua famiglia. Quindi, se hai una sfida DevOps o vuoi fare una corsa: faglielo sapere.

Giovanni Langer è Senior Solutions Architect presso AWS e lavora con clienti aziendali in Germania. Johannes è appassionato di applicazione dell'apprendimento automatico per risolvere problemi aziendali reali. Nella sua vita personale, Johannes ama lavorare su progetti di miglioramento della casa e trascorrere del tempo all'aperto con la sua famiglia.