Le complessit\u00e0 legate all’implementazione di un flusso di lavoro di Machine Learning nel Cloud sono chiamate gap di distribuzione<\/a> e vedremo insieme in questo articolo come affrontarlo combinando velocit\u00e0 e agilit\u00e0 nella modellazione e formazione, con i criteri di solidit\u00e0, scalabilit\u00e0 e resilienza richiesti da ambienti di produzione.<\/p>\n\n\n\n La procedura in cui ci addentreremo \u00e8 simile per molti aspetti al modello DevOps per lo sviluppo software “tradizionale”, e il paradigma MLOps, cos\u00ec chiamato, viene comunemente proposto come “un processo end-to-end per progettare, creare e gestire applicazioni di Machine Learning in modo riproducibile, testabile ed evolutivo<\/a>“.<\/p>\n\n\n\n Per questo motivo, man mano che ci addentreremo nei paragrafi seguenti, approfondiremo le ragioni e i principi alla base del paradigma MLOps e come si collega facilmente all’ecosistema AWS e alle migliori pratiche dell\u2019 AWS Well-Architected Framework.<\/p>\n\n\n\n Allora, iniziamo!<\/p>\n\n\n\n Come detto prima, i carichi di lavoro di Machine Learning possono essere visti essenzialmente come pezzi complessi di software, quindi possiamo ancora applicare pratiche software “tradizionali”. Tuttavia, per la sua natura sperimentale, il Machine Learning mette in gioco alcune differenze essenziali<\/strong>, che richiedono un paradigma di gestione del ciclo di vita fatto su misura per le loro esigenze.<\/p>\n\n\n\n Queste differenze si presentano in tutte le varie fasi di un carico di lavoro e contribuiscono in modo significativo al divario di distribuzione di cui abbiamo parlato, quindi una descrizione generale \u00e8, quantomeno, d\u2019obbligo:<\/p>\n\n\n\n Gestire codice nelle appliance di Machine Learning \u00e8 una questione complessa. Vediamo perch\u00e9!<\/p>\n\n\n\n La collaborazione sugli esperimenti del modello tra i data scientist<\/strong> non \u00e8 facile come la condivisione di file di codice tradizionali: i notebook Jupyter consentono di scrivere ed eseguire codice, rendendo le operazioni git pi\u00f9 complesse per mantenere il codice sincronizzato tra gli utenti, con frequenti conflitti di merge<\/strong>.<\/p>\n\n\n\n Gli sviluppatori devono scrivere codice per diversi sottoprogetti: processi ETL<\/strong>, logica del modello<\/strong>, training e convalida<\/strong>, logica di inferenza<\/strong> e modelli di Infrastructure-as-Code<\/strong>. Tutti questi progetti separati devono essere gestiti centralmente e adeguatamente versionati!<\/p>\n\n\n\n Per le moderne applicazioni software, esistono molte procedure consolidate di controllo di versione<\/strong> come il commit convenzionale<\/a>, il branching delle funzionalit\u00e0, lo squash e rebase<\/a> e l’integrazione continua<\/a>.<\/p>\n\n\n\n Queste tecniche, tuttavia, non sono sempre applicabili ai notebook Jupyter poich\u00e9, come affermato in precedenza, non sono semplici file di testo.<\/p>\n\n\n\n I data scientists devono effettuare molte combinazioni di set di dati, funzionalit\u00e0, tecniche di modellazione, algoritmi e configurazioni di parametri per trovare la soluzione che estrae al meglio il valore aziendale<\/strong>.<\/p>\n\n\n\n Il punto chiave \u00e8 trovare un sistema per tenere traccia di esperimenti riusciti<\/strong> e falliti<\/strong> mantenendo la riproducibilit\u00e0<\/strong> e la riutilizzabilit\u00e0<\/strong> del<\/strong> codice<\/strong>. Perseguire questo obiettivo significa disporre di strumenti che consentano rapidi rollback e un monitoraggio efficiente dei risultati, meglio se con strumenti visivi.<\/p>\n\n\n\n Testare un carico di lavoro di Machine Learning \u00e8 pi\u00f9 complesso<\/strong> rispetto al test di software tradizionali.<\/p>\n\n\n\n Il set di dati richiede una convalida continua<\/strong>. I modelli sviluppati dai data scientist richiedono una valutazione continua della qualit\u00e0<\/strong>, la convalida del training e controlli delle prestazioni<\/strong>.<\/p>\n\n\n\n Tutti questi controlli si aggiungono ai tipici test di unit\u00e0 e integrazione, definendo il concetto di Training Continuo<\/strong>, necessario per evitare l’invecchiamento del modello<\/strong> e il concept drift<\/a>.<\/p>\n\n\n\n Esclusivo dei flussi di lavoro di Machine Learning, il suo scopo \u00e8 di attivare il retraining e servire automaticamente i modelli.<\/p>\n\n\n\n La distribuzione di modelli di Machine Learning nel cloud \u00e8 un compito impegnativo<\/strong>. In genere richiede la creazione di varie pipeline a pi\u00f9 passaggi<\/strong> che servono per riaddestrare e distribuire automaticamente i modelli.<\/p>\n\n\n\n Questo approccio aggiunge complessit\u00e0 alla soluzione e richiede l’automazione di passaggi eseguiti manualmente dai data scientist<\/strong> durante il training e la convalida di nuovi modelli nella fase sperimentale di un progetto.<\/p>\n\n\n\n \u00c8 fondamentale creare procedure di retraining efficienti!<\/p>\n\n\n\n I modelli di Machine Learning tendono a decadere molto pi\u00f9 velocemente rispetto al software “tradizionale”<\/strong>. Possono avere prestazioni ridotte a causa di codice non ottimale, scelte hardware errate<\/strong> nelle fasi di addestramento e inferenza e set di dati in evoluzione.<\/p>\n\n\n\n Una metodologia adeguata deve tenere conto di questo degrado; pertanto, abbiamo bisogno di un meccanismo di tracciamento<\/strong> per riepilogare efficacemente le statistiche di un carico di lavoro<\/strong>, monitorare le prestazioni<\/strong> e inviare notifiche di allarme<\/strong>.<\/p>\n\n\n\n Tutte queste procedure devono essere automatizzate e sono chiamate Monitoraggio Continuo<\/strong>, che ha anche l’ulteriore vantaggio di abilitare il Training Continuo, mediante la misurazione di soglie significative.<\/p>\n\n\n\n Vogliamo anche applicare i rollback<\/strong> quando un’inferenza del modello devia dalle soglie di punteggio selezionate il pi\u00f9 rapidamente possibile per provare nuove combinazioni di funzionalit\u00e0.<\/p>\n\n\n\n Il Machine Learning condivide approcci simili alle pipeline di CI\/CD standard delle moderne applicazioni software: controllo del codice sorgente, test di unit\u00e0, test di integrazione, delivery continuo dei pacchetti applicativi.<\/p>\n\n\n\n Tuttavia, modelli e data set richiedono interventi particolari<\/strong>.<\/p>\n\n\n\n L’integrazione continua ora richiede, come detto prima, anche il test e la convalida dei dati, schemi di dati e modelli.<\/p>\n\n\n\n In questo contesto, la distribuzione continua deve essere progettata come una pipeline di training ML in grado di distribuire automaticamente l’inferenza come servizio raggiungibile dal web<\/strong>.<\/p>\n\n\n\n Come si pu\u00f2 intuire, c’\u00e8 molta carne al fuoco che rende la strutturazione di un progetto di Machine Learning un compito assai complesso.<\/p>\n\n\n\n Prima di introdurre il lettore alla metodologia MLOps, che pone sotto la sua ala tutti questi aspetti cruciali, vedremo come \u00e8 strutturato un tipico workflow di Machine Learning, tenendo conto di quanto detto fino ad ora.<\/p>\n\n\n\n Proseguiamo insieme!<\/p>\n\n\n\n <\/p>\n\n\n\n Un flusso di lavoro di Machine Learning non \u00e8 pensato per essere lineare, proprio come il software tradizionale. \u00c8 composto principalmente da tre livelli distinti: dati<\/strong>, modello<\/strong> e codice<\/strong> e ognuno fornir\u00e0 e recuperer\u00e0 continuamente feedback dagli altri<\/strong>.<\/p>\n\n\n\n Quindi, mentre con il software tradizionale, possiamo dire che ogni passaggio che compone un flusso di lavoro pu\u00f2 essere atomico e in qualche modo isolato, nel Machine Learning, questo non \u00e8 del tutto vero poich\u00e9 i livelli sono profondamente interconnessi<\/strong>.<\/p>\n\n\n\n Un tipico esempio \u00e8 quando le modifiche al set di dati richiedono il retraining o il ripensamento di un modello. Anche un modello diverso, di solito, necessita di modifiche al codice che lo esegue.<\/p>\n\n\n\n Vediamo insieme da cosa \u00e8 composto ogni Layer e come funziona.<\/p>\n\n\n\n Il livello dati comprende tutte le attivit\u00e0 necessarie per manipolare i dati e renderli disponibili per la progettazione e l’addestramento del modello: acquisizione dei dati<\/strong>, ispezione<\/strong>, pulizia<\/strong> e, infine, preelaborazione dei dati<\/strong>.<\/p>\n\n\n\n I set di Dati per problemi reali, o quantomeno realistici, possono essere nell\u2019ordine di GB o addirittura TB, in continuo aumento, quindi abbiamo bisogno di uno spazio di archiviazione adeguato per gestire enormi data lake.<\/p>\n\n\n\n Lo storage deve essere robusto, consentire un’elaborazione parallela efficiente e integrarsi facilmente con gli strumenti per i lavori ETL<\/a>.<\/p>\n\n\n\n Questo livello \u00e8 il pi\u00f9 cruciale, rappresentando l’80% del lavoro svolto in un flusso di lavoro di Machine Learning<\/a>; due famose citazioni confermano questo fatto: “garbage in, garbage out<\/em>” e “il tuo modello \u00e8 valido solo quanto i tuoi dati<\/em>“.<\/p>\n\n\n\n La maggior parte di questi concetti sono prerogativa delle buone pratiche di Data Analytics<\/strong>, profondamente intrecciata con il Machine Learning, e li analizzeremo in dettaglio pi\u00f9 avanti in questo articolo.<\/p>\n\n\n\n Il livello di Modello contiene tutte le operazioni per progettare<\/strong>, sperimentare<\/strong>, addestrare<\/strong> e convalidare<\/strong> uno o pi\u00f9 modelli di Machine Learning. I professionisti del machine learning conducono prove sui dati in questo livello, sperimentano algoritmi su diverse soluzioni hardware<\/strong> ed eseguono l’ottimizzazione degli iperparametri<\/strong>.<\/p>\n\n\n\n Questo livello \u00e8 tipicamente soggetto a frequenti modifiche dovute ad aggiornamenti sia di Dati che di Codice<\/strong>, necessari per evitare il concept drift<\/strong>. Per gestire correttamente il suo ciclo di vita su larga scala, dobbiamo definire procedure automatiche<\/strong> per il retraining e la convalida.<\/p>\n\n\n\n Il livello di Modello \u00e8 anche una fase in cui si verificano frequenti discussioni, tra Data Scientist e parti interessate, sulla convalida del modello, sulla solidit\u00e0 concettuale e sulle discordanze rispetto ai risultati attesi.<\/p>\n\n\n\n Nel livello Codice, definiamo un insieme di procedure per mettere in produzione un modello, gestire le richieste di inferenze<\/strong>, archiviare i metadati di un modello, analizzare le prestazioni complessive<\/strong>, monitorare il flusso di lavoro<\/strong> (debug, logging, auditing) e orchestrare automatismi di CI\/CD\/CT\/CM<\/strong>.<\/p>\n\n\n\n Un buon livello Codice consente un modello di feedback continuo<\/strong>, in cui il modello si evolve nel tempo, tenendo conto dei risultati delle inferenze in corso.<\/p>\n\n\n\n Tutti e tre questi livelli sono gestiti da “sub-pipeline”, che si sommano tra loro per formare una “macro-pipeline” nota come Machine Learning Pipeline<\/a>.<\/p>\n\n\n\n Progettare, costruire ed eseguire automaticamente questa pipeline, riducendo il deployment gap nel processo, \u00e8 il nucleo del paradigma MLOps.<\/p>\n\n\n\n Il paradigma MLOps mira a rendere lo sviluppo e il mantenimento dei flussi di lavoro di Machine Learning semplici<\/strong> ed efficienti<\/strong>. La comunit\u00e0 di data science generalmente concorda sul fatto che non si tratta di un’unica soluzione tecnica, ma di una serie di best practice e principi guida sull’apprendimento automatico.<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n Un approccio MLOps coinvolge operazioni, tecniche e strumenti, che possiamo raggruppare in quattro pilastri principali<\/strong>: Collaborazione<\/strong>, Riproducibilit\u00e0<\/strong>, Continuit\u00e0<\/strong> e Monitoraggio<\/strong>.<\/p>\n\n\n\n Ci concentreremo ora su ciascuno di essi, fornendo molteplici esempi pratici che mostrano come AWS, con molti dei suoi servizi, pu\u00f2 essere uno strumento prezioso per sviluppare soluzioni che aderiscono alle best practice del paradigma.<\/p>\n\n\n\n Un buon flusso di lavoro di Machine Learning dovrebbe essere collaborativo<\/strong> e la collaborazione si dovrebbe verificare su tutte le pipeline ML.<\/p>\n\n\n\n A partire dal Data Layer, abbiamo bisogno di un’infrastruttura condivisa<\/strong>, il che significa un data lake distribuito<\/strong>. AWS offre diverse soluzioni di storage per questo scopo, come Amazon Redshift<\/strong>, il pi\u00f9 adatto per il Data Warehousing, o Amazon FSx per Lustre<\/strong>, perfetto come file system distribuito. Tuttavia, il servizio pi\u00f9 comunemente utilizzato per la creazione di data lake \u00e8 Amazon S3<\/strong>.<\/p>\n\n\n\n Per mantenere correttamente un data lake, dobbiamo effettuare regolarmente l\u2019ingestion di dati da diverse fonti e gestire l’accesso condiviso tra i vari collaboratori, assicurandoci che i dati siano sempre aggiornati<\/strong>.<\/p>\n\n\n\n Sicuramente non un compito facile e per questo possiamo sfruttare S3 LakeFormation<\/strong>, un servizio gestito che aiuta a creare e mantenere un data lake, incapsulando AWS Glue<\/strong> e Glue Studio<\/strong>, in particolare semplificando il set-up dei Crawler di Glue e la loro manutenzione.<\/p>\n\n\n\n S3 LakeFormation pu\u00f2 anche occuparsi dei dati e delle regole di autorizzazione dei collaboratori, gestendo utenti e ruoli nel catalogo di AWS Glue<\/strong>. Questa funzionalit\u00e0 \u00e8 fondamentale, in quanto collaborazione significa anche mantenere la governance sul data lake<\/a>, evitando manipolazioni involontarie dei dati, consentendo o negando l’accesso a risorse specifiche all’interno di un catalogo.<\/p>\n\n\n\n Per il livello del Modello, i Data Scientist hanno bisogno di uno strumento per la progettazione collaborativa e la codifica dei modelli di Machine Learning<\/strong>. Deve consentire a pi\u00f9 utenti di lavorare sullo stesso esperimento<\/strong>, mostrare rapidamente i risultati di ciascun collaboratore, garantire la programmazione in coppia in tempo reale<\/strong> ed evitare il pi\u00f9 possibile regressioni del codice e conflitti di merge<\/strong>.<\/p>\n\n\n\n SageMaker<\/strong> \u00e8 il framework all-in-one opinionato per il Machine Learning su AWS e Amazon SageMaker Studio<\/strong> \u00e8 un IDE specializzato sviluppato esplicitamente per lavorare con i notebook Jupyter pensando alla collaborazione<\/a>.<\/p>\n\n\n\n SageMaker Studio permette di condividere un’istanza EC2 dedicata<\/strong> tra diversi utenti registrati, in cui \u00e8 possibile salvare tutti gli esperimenti fatti durante lo sviluppo di un modello di Machine Learning. Questa istanza pu\u00f2 ospitare direttamente i notebook Jupyter o ricevere risultati, allegati e grafica tramite API da altre istanze Notebook.<\/p>\n\n\n\n SageMaker Studio \u00e8 inoltre direttamente integrato con SageMaker Experiments<\/strong> e SageMaker Feature Store<\/strong>.<\/p>\n\n\n\n Il primo \u00e8 un set di API che consente ai Data Scientist di registrare e archiviare un esperimento sul modello, dall’ottimizzazione<\/strong> alla convalida<\/strong>, e riportare i risultati nella console dell\u2019IDE. Il secondo \u00e8 uno store gestito da AWS, appositamente creato per la condivisione di parametri aggiornati su diverse prove dei modelli<\/strong>.<\/p>\n\n\n\n SageMaker Feature Store rappresenta un notevole passo avanti nel mantenimento della governance sui parametri dei dati tra diversi team, principalmente perch\u00e9 evita un comportamento tipico, ma improprio, di avere set di parametri diversi<\/strong> per l’addestramento e l’inferenza. \u00c8 anche una soluzione perfetta per garantire che ogni Data Scientist che lavora su un progetto abbia una visibilit\u00e0 completa dell’etichettatura dei parametri<\/strong>.<\/p>\n\n\n\n Per essere robusto, tollerante ai guasti e corretamente scalabile, proprio come le applicazioni software “tradizionali”, un flusso di lavoro di Machine Learning deve essere riproducibile<\/strong>.<\/p>\n\n\n\n Un punto cruciale che dobbiamo affrontare con attenzione, come abbiamo detto prima, \u00e8 il Controllo di Versione<\/strong>: dobbiamo garantire che codice, dati, metadati del modello e funzionalit\u00e0 siano adeguatamente versionati.<\/p>\n\n\n\n Per i notebook Jupyter, Git o AWS CodeCommit<\/strong> sono scelte naturali, ma la gestione delle informazioni di diversi esperimenti, in particolare dei metadati del modello, richiede alcune considerazioni particolari.<\/p>\n\n\n\n Possiamo utilizzare SageMaker Feature Store per metadati e funzionalit\u00e0. Ci consente di archiviare i dati direttamente online in uno store gestito o di integrarci con AWS Glue<\/strong> (e S3 LakeFomation). Consente inoltre la crittografia dei dati utilizzando AWS KMS<\/strong> e pu\u00f2 essere controllato tramite API o all’interno di SageMaker Studio.<\/p>\n\n\n\n Se si vuole che un flusso di lavoro sia riproducibile, si intende sperimentare su larga scala<\/strong>, anche in parallelo, in modo rapido, prevedibile e automatico.<\/p>\n\n\n\n SageMaker offre diversi modi per combinare e abbinare diversi algoritmi di Machine Learning e AWS permette tre possibili approcci per l’esecuzione di un modello.<\/p>\n\n\n\n Managed Algorithm<\/strong>: SageMaker offre fino a 13 algoritmi gestiti per scenari ML comuni e, per ognuno, una documentazione dettagliata descrive le specifiche software e hardware.<\/p>\n\n\n\n Bring your own algorithm<\/strong><\/a>: i Data Scientist possono introdurre rapidamente logica personalizzata sui notebook, a condizione che il modello rispetti i requisiti di SageMaker fit()<\/strong>.<\/p>\n\n\n\n Bring your own Container<\/strong><\/a>: modelli particolari come DBScan<\/a> richiedono Kernel personalizzati per eseguire l’algoritmo, quindi SageMaker consente di registrare un container personalizzato con un Kernel speciale e il codice per l’esecuzione del modello.<\/p>\n\n\n\n I Data Scientist possono affrontare tutti questi approcci insieme.<\/p>\n\n\n\n SageMaker offre la possibilit\u00e0 di definire l’hardware su cui eseguire il training o la convalida del modello selezionando il tipo di istanza<\/strong> e la dimensione di quest\u2019ultima<\/strong> nelle propriet\u00e0 del modello, il che \u00e8 estremamente importante in quanto algoritmi diversi richiedono macchine ottimizzate per CPU o GPU.<\/p>\n\n\n\n Per mettere a punto un modello, SageMaker pu\u00f2 eseguire diverse strategie di ottimizzazione degli iperparametri<\/strong>: Ricerca Casuale<\/strong> e Ricerca Bayesiana<\/strong>. Queste due strategie sono completamente automatiche, garantendo un modo per testare un numero pi\u00f9 significativo di combinazioni di prove in una frazione di tempo normalmente necessario.<\/p>\n\n\n\n Per migliorare la ripetibilit\u00e0 degli esperimenti, dobbiamo anche gestire diversi modi di eseguire la preelaborazione dei dati (diversi set di dati applicati allo stesso modello). Per questo, abbiamo AWS Data Wrangler<\/strong>, che contiene oltre 300 trasformazioni di dati integrate<\/strong> per normalizzare, trasformare e combinare rapidamente potenziali feature senza dover scrivere alcun codice.<\/p>\n\n\n\n AWS Data Wrangler pu\u00f2 essere una buona scelta quando il problema di ML che si sta affrontando \u00e8 in qualche modo standardizzato, ma nella maggior parte dei casi i set di dati sono estremamente diversi, il che significa affrontare i lavori di ETL personalmente.<\/p>\n\n\n\n Per i lavori ETL personalizzati, AWS Glue \u00e8 ancora la scelta giusta, poich\u00e9 consente anche di salvare i crawler di lavoro e i cataloghi di Glue (per la ripetibilit\u00e0). Insieme ad AWS Glue e AWS Glue Studio, abbiamo anche provato AWS Glue Elastic Views<\/strong>, un nuovo servizio che aiuta a gestire diverse origini dati insieme<\/a>.<\/p>\n\n\n\n Per rendere continuo<\/strong> il nostro flusso di lavoro di Machine Learning, dobbiamo utilizzare il pi\u00f9 possibile l’automazione delle pipeline<\/strong> per gestirne l’intero ciclo di vita.<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n Possiamo suddividere l’intero flusso di lavoro ML in tre pipeline significative, una per ogni livello di Machine Learning.<\/p>\n\n\n\n La pipeline dei dati \u00e8 composta dalle fasi di Acquisizione<\/strong>, Esplorazione<\/strong>, Convalida<\/strong>, Pulizia<\/strong> e Suddivisione<\/strong>.<\/p>\n\n\n\n La fase di Acquisizione su AWS in genere significa portare i dati grezzi su S3, utilizzando qualsiasi strumento e tecnologia disponibile: accesso diretto all’API, crawler Lambda personalizzati, S3 LakeFormation<\/strong> o Amazon Kinesis Firehose<\/strong>.<\/p>\n\n\n\n Poi abbiamo una fase ETL di pre-elaborazione<\/a>, che \u00e8 sempre richiesta<\/strong>!<\/p>\n\n\n\n AWS Glue <\/strong>\u00e8 il pi\u00f9 versatile tra tutti gli strumenti disponibili per i processi di ETL, in quanto consente di leggere e aggregare informazioni da tutti i servizi precedenti utilizzando i Glue Crawlers<\/strong>. Queste routine possono eseguire il polling da divers datasource per ottenere nuovi dati.<\/p>\n\n\n\n Possiamo gestire le fasi di Esplorazione, Convalida e Pulizia creando script personalizzati in un linguaggio a scelta (ad es. Python) o utilizzando Jupyter Notebook, entrambi orchestrati tramite AWS Step Functions<\/strong><\/a>.<\/p>\n\n\n\n AWS Data Wrangler<\/strong> rappresenta un’altra soluzione praticabile, in quanto pu\u00f2 occuparsi automaticamente di tutti i passaggi e connettersi direttamente a Amazon SageMaker Pipelines<\/strong>.<\/p>\n\n\n\n La pipeline del Modello \u00e8 costituita da fasi di Training<\/strong>, Valutazione<\/strong>, Test<\/strong> e Packaging<\/strong>.<\/p>\n\n\n\n Queste fasi possono essere gestite direttamente dai file di Jupyter Notebook e integrate in una pipeline utilizzando AWS StepFunctions SageMaker SDK<\/strong>, che consente di chiamare le funzioni SageMaker all’interno di uno script StepFunction.<\/p>\n\n\n\n Questo exploit offre estrema flessibilit\u00e0 in quanto permette di:<\/p>\n\n\n\n Avere la logica di questa pipeline sui Notebook Jupyter ha l’ulteriore vantaggio di avere tutto sotto controllo di versione<\/strong> e facilmente testabile<\/strong>.<\/p>\n\n\n\n Il packaging pu\u00f2 essere gestito tramite le API di Elastic Container Registry<\/strong>, direttamente da un Notebook Jupyter o da uno script esterno.<\/p>\n\n\n\n La pipeline di distribuzione esegue la parte di CI\/CD<\/strong> ed \u00e8 responsabile della messa online dei modelli durante le fasi di Training<\/strong>, Test<\/strong> e Produzione<\/strong>. Un aspetto chiave durante questa pipeline \u00e8 che la domanda di risorse computazionali \u00e8 diversa per tutte e tre le fasi e cambia nel tempo.<\/p>\n\n\n\n Ad esempio, il training all’inizio richieder\u00e0 pi\u00f9 risorse rispetto ai test e alla produzione, ma in seguito, con l’aumentare della domanda di inferenze, i requisiti di produzione saranno pi\u00f9 elevati (Distribuzione Dinamica<\/strong>).<\/p>\n\n\n\n Possiamo applicare strategie di deploy avanzate tipiche dello sviluppo software “tradizionale” per affrontare i flussi di lavoro ML, inclusi test A\/B, implementazioni canary e implementazioni blue\/green.<\/p>\n\n\n\n Ogni aspetto della distribuzione pu\u00f2 trarre vantaggio dalle tecniche di Infrastructure as Code<\/a> e da una combinazione di servizi AWS come AWS CodePipeline, CloudFormation e AWS StepFunctions<\/a>.<\/p>\n\n\n\n Infine, i flussi di lavoro di Machine Learning ben fatti devono essere monitorabili<\/strong> e il monitoraggio avviene in varie fasi.<\/p>\n\n\n\n Abbiamo il monitoraggio delle prestazioni<\/strong>, che permette di capire come si comporta un modello nel tempo. Avendo continuamente feedback basati su nuove inferenze, possiamo evitare l’invecchiamento del modello (overfitting<\/strong>) e il concept drift<\/strong>.<\/p>\n\n\n\n SageMaker Model Monitor<\/strong> fornisce un ottimo aiuto durante questa fase in quanto pu\u00f2 eseguire il monitoraggio in tempo reale, rilevando bias e divergenze mediante tecniche di Anomaly Detection<\/strong> e inviando avvisi per applicare rimedi immediati.<\/p>\n\n\n\nPerch\u00e8 abbiamo bisogno del MLOps?<\/h1>\n\n\n\n
Codice<\/h3>\n\n\n\n
Sviluppo<\/h3>\n\n\n\n
Test<\/h3>\n\n\n\n
Rilascio in produzione<\/h3>\n\n\n\n
Monitoraggio in Produzione<\/h3>\n\n\n\n
Continuous Integration e Continuous Deployment<\/h3>\n\n\n\n
Un tipico flusso di Machine Learning in Cloud<\/h2>\n\n\n\n
![\"A](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/09\/image2-1-1024x529.png\")
Strato di dati<\/h3>\n\n\n\n
Strato di modello<\/h3>\n\n\n\n
Strato di codice<\/h3>\n\n\n\n
MLOps con AWS: i quattro pilastri<\/h1>\n\n\n\n
![\"MLOps](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/09\/image3-1-1024x630.png\")
Collaborazione<\/h3>\n\n\n\n
Riproducibilit\u00e0<\/h3>\n\n\n\n
Continuit\u00e0<\/h3>\n\n\n\n
![\"ML](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/09\/image1-2-1024x768.png\")
Pipeline di Data engineering<\/h4>\n\n\n\n
Pipeline di Modello<\/h4>\n\n\n\n
Pipeline di rilascio<\/h4>\n\n\n\n
Monitoraggio<\/h3>\n\n\n\n