Operazioni di Machine Learning (MLOps) v2

  • Articolo

Questo articolo descrive tre architetture di Azure per le operazioni di Machine Learning. Tutti dispongono di integrazione continua (CI), recapito continuo (CD) end-to-end e pipeline di ripetizione del training. Le architetture sono destinate a queste applicazioni di intelligenza artificiale:

  • Machine Learning classico
  • Visione artificiale (CV)
  • Elaborazione del linguaggio naturale (NLP)

Le architetture sono il prodotto del progetto MLOps v2. Incorporano le procedure consigliate individuate dagli architetti delle soluzioni nel processo di creazione di più soluzioni di Machine Learning. Il risultato è distribuibile, ripetibile e gestibile come descritto qui.

Tutte le architetture usano il servizio Azure Machine Learning.

Per un'implementazione con modelli di distribuzione di esempio per MLOps v2, vedere Acceleratore di soluzioni Azure MLOps (v2) in GitHub.

Potenziali casi d'uso

  • Machine Learning classico: previsione, regressione e classificazione delle serie temporali nei dati strutturati tabulari sono i casi d'uso più comuni in questa categoria. Di seguito sono riportati alcuni esempi:
    • Classificazione binaria e con più etichette
    • Regressione lineare, polinomiale, ridge, lasso, quantile e Bayesian
    • ARIMA, autoregressive (AR), SARIMA, VAR, edizione Standard S, LSTM
  • CV: il framework MLOps presentato qui è incentrato principalmente sui casi d'uso cv di segmentazione e classificazione delle immagini.
  • NLP: questo framework MLOps può implementare uno di questi casi d'uso e altri non elencati:
    • Riconoscimento entità denominata
    • Classificazione testo
    • Generazione testo
    • Analisi valutazione
    • Traduzione
    • Risposta alle domande
    • Riepilogo
    • Rilevamento frasi
    • Rilevamento lingua
    • Tag delle parti del discorso

Le simulazioni, l'apprendimento avanzato per rinforzo e altre forme di intelligenza artificiale non sono trattate in questo articolo.

Architettura

Il modello di architettura MLOps v2 è costituito da quattro elementi modulari principali che rappresentano queste fasi del ciclo di vita mlops:

  • Data estate
  • Amministrazione e installazione
  • Sviluppo di modelli (ciclo interno)
  • Distribuzione del modello (ciclo esterno)

Questi elementi, le relazioni tra di essi e gli utenti personali in genere associati a essi sono comuni per tutte le architetture di scenario MLOps v2. Possono essere presenti variazioni nei dettagli di ognuno, a seconda dello scenario.

L'architettura di base per MLOps v2 per Machine Learning è lo scenario classico di Machine Learning sui dati tabulari. Le architetture CV e NLP si basano su e modificano questa architettura di base.

Architetture correnti

Le architetture attualmente trattate da MLOps v2 e descritte in questo articolo sono:

Architettura classica di Machine Learning

Diagramma per l'architettura classica di Machine Learning.

Scaricare un file di Visio di questa architettura.

Flusso di lavoro per l'architettura classica di Machine Learning

  1. Data estate

    Questo elemento illustra il patrimonio di dati dell'organizzazione e le potenziali origini dati e le destinazioni per un progetto di data science. I data engineer sono i proprietari principali di questo elemento del ciclo di vita di MLOps v2. Le piattaforme dati di Azure in questo diagramma non sono né esaustive né prescrittive. Le origini dati e le destinazioni che rappresentano le procedure consigliate in base al caso d'uso del cliente sono indicate da un segno di spunta verde.

  2. Amministrazione e installazione

    Questo elemento è il primo passaggio della distribuzione dell'acceleratore MLOps v2. È costituito da tutte le attività correlate alla creazione e alla gestione di risorse e ruoli associati al progetto. Possono includere le attività seguenti e, ad esempio, altre:

    1. Creazione di repository di codice sorgente del progetto
    2. Creazione di aree di lavoro di Machine Learning con Bicep o Terraform
    3. Creazione o modifica di set di dati e risorse di calcolo usate per lo sviluppo e la distribuzione di modelli
    4. Definizione di utenti del team di progetto, ruoli e controlli di accesso ad altre risorse
    5. Creazione di pipeline CI/CD
    6. Creazione di monitoraggi per la raccolta e la notifica delle metriche del modello e dell'infrastruttura

    L'utente principale associato a questa fase è il team dell'infrastruttura, ma possono essere presenti anche data engineer, ingegneri di Machine Learning e data scientist.

  3. Sviluppo di modelli (ciclo interno)

    L'elemento del ciclo interno è costituito dal flusso di lavoro iterativo di data science che agisce all'interno di un'area di lavoro di Machine Learning dedicata e sicura. Un flusso di lavoro tipico è illustrato nel diagramma. Procede dall'inserimento dati, dall'analisi esplorativa dei dati, dalla sperimentazione, dallo sviluppo e dalla valutazione dei modelli, alla registrazione di un modello candidato per la produzione. Questo elemento modulare implementato nell'acceleratore MLOps v2 è indipendente e adattabile al processo usato dal team di data science per sviluppare modelli.

    Le persone associate a questa fase includono data scientist e ingegneri di Machine Learning.

  4. Registri di Machine Learning

    Dopo che il team di data science sviluppa un modello candidato per la distribuzione in produzione, il modello può essere registrato nel registro delle aree di lavoro di Machine Learning. Pipeline CI attivate, automaticamente dalla registrazione del modello o dall'approvazione del ciclo human-in-the-loop controllata, alzano di livello il modello e qualsiasi altra dipendenza del modello alla fase di distribuzione del modello.

    Le persone associate a questa fase sono in genere ingegneri di Machine Learning.

  5. Distribuzione del modello (ciclo esterno)

    La fase di distribuzione del modello o di ciclo esterno è costituita da staging e test di pre-produzione, distribuzione di produzione e monitoraggio di modelli, dati e infrastruttura. Le pipeline cd gestiscono la promozione del modello e degli asset correlati tramite produzione, monitoraggio e potenziale ripetizione del training, in quanto vengono soddisfatti i criteri appropriati per l'organizzazione e il caso d'uso.

    Le persone associate a questa fase sono principalmente ingegneri di Machine Learning.

  6. Gestione temporanea e test

    La fase di staging e test può variare con le procedure dei clienti, ma in genere include operazioni come la ripetizione del training e il test del candidato del modello sui dati di produzione, le distribuzioni di test per le prestazioni degli endpoint, i controlli della qualità dei dati, gli unit test e i controlli di intelligenza artificiale responsabili per il modello e la distorsione dei dati. Questa fase viene eseguita in una o più aree di lavoro di Machine Learning dedicate e sicure.

  7. Distribuzione di produzione

    Dopo che un modello ha superato la fase di staging e test, può essere promossa alla produzione usando un'approvazione controllata dall'utente nel ciclo. Le opzioni di distribuzione del modello includono un endpoint batch gestito per scenari batch o, per scenari online quasi in tempo reale, un endpoint online gestito o una distribuzione Kubernetes usando Azure Arc. La produzione viene in genere eseguita in una o più aree di lavoro di Machine Learning dedicate e sicure.

  8. Monitoraggio

    Il monitoraggio nella gestione temporanea, nei test e nell'ambiente di produzione consente di raccogliere le metriche e di agire sulle prestazioni del modello, dei dati e dell'infrastruttura. Il monitoraggio dei modelli e dei dati può includere il controllo della deriva dei modelli e dei dati, le prestazioni del modello sui nuovi dati e i problemi di intelligenza artificiale responsabili. Il monitoraggio dell'infrastruttura può controllare la risposta lenta degli endpoint, la capacità di calcolo inadeguata o i problemi di rete.

  9. Monitoraggio di dati e modelli: eventi e azioni

    In base ai criteri relativi a modelli e dati, ad esempio soglie o pianificazioni delle metriche, trigger e notifiche automatizzati possono implementare azioni appropriate da intraprendere. È possibile pianificare regolarmente la ripetizione automatica del training del modello sui dati di produzione più recenti e un loopback alla gestione temporanea e al test per la valutazione di pre-produzione. In alternativa, può essere dovuto a trigger su problemi di modello o dati che richiedono un loopback alla fase di sviluppo del modello in cui i data scientist possono analizzare e potenzialmente sviluppare un nuovo modello.

  10. Monitoraggio dell'infrastruttura: eventi e azioni

    In base ai criteri per le questioni relative all'infrastruttura, ad esempio il ritardo di risposta dell'endpoint o il calcolo insufficiente per la distribuzione, i trigger e le notifiche automatizzati possono implementare azioni appropriate da intraprendere. Attivano un loopback alla fase di configurazione e amministrazione in cui il team dell'infrastruttura può analizzare e potenzialmente riconfigurare le risorse di calcolo e di rete.

Architettura cv di Machine Learning

Diagramma per l'architettura di Visione artificiale.

Scaricare un file di Visio di questa architettura.

Flusso di lavoro per l'architettura cv

L'architettura cv di Machine Learning si basa sull'architettura classica di Machine Learning, ma presenta modifiche specifiche per gli scenari CV supervisionati.

  1. Data estate

    Questo elemento illustra il patrimonio di dati dell'organizzazione e le potenziali origini dati e destinazioni per un progetto di data science. I data engineer sono i proprietari principali di questo elemento del ciclo di vita di MLOps v2. Le piattaforme dati di Azure in questo diagramma non sono né esaustive né prescrittive. Le immagini per gli scenari CV possono provenire da molte origini dati diverse. Per un'efficienza durante lo sviluppo e la distribuzione di modelli CV con Machine Learning, le origini dati di Azure consigliate per le immagini sono Archiviazione BLOB di Azure e Azure Data Lake Archiviazione.

  2. Amministrazione e installazione

    Questo elemento è il primo passaggio della distribuzione dell'acceleratore MLOps v2. È costituito da tutte le attività correlate alla creazione e alla gestione di risorse e ruoli associati al progetto. Per gli scenari cv, l'amministrazione e la configurazione dell'ambiente MLOps v2 sono in gran parte uguali a quella per l'apprendimento automatico classico, ma con un passaggio aggiuntivo: creare progetti di etichettatura e annotazione delle immagini usando la funzionalità di etichettatura di Machine Learning o un altro strumento.

  3. Sviluppo di modelli (ciclo interno)

    L'elemento del ciclo interno è costituito dal flusso di lavoro iterativo di data science eseguito all'interno di un'area di lavoro di Machine Learning dedicata e sicura. La differenza principale tra questo flusso di lavoro e lo scenario classico di Machine Learning è che l'etichettatura e l'annotazione delle immagini sono un elemento chiave di questo ciclo di sviluppo.

  4. Registri di Machine Learning

    Dopo che il team di data science sviluppa un modello candidato per la distribuzione in produzione, il modello può essere registrato nel registro delle aree di lavoro di Machine Learning. Le pipeline di integrazione continua attivate automaticamente dalla registrazione del modello o dall'approvazione del ciclo umano gestito promuovono il modello e qualsiasi altra dipendenza del modello alla fase di distribuzione del modello.

  5. Distribuzione del modello (ciclo esterno)

    La fase di distribuzione del modello o di ciclo esterno è costituita da staging e test di pre-produzione, distribuzione di produzione e monitoraggio di modelli, dati e infrastruttura. Le pipeline cd gestiscono la promozione del modello e degli asset correlati tramite produzione, monitoraggio e potenziale ripetizione del training in base ai criteri appropriati per l'organizzazione e vengono soddisfatti i casi d'uso.

  6. Gestione temporanea e test

    La fase di staging e test può variare con le procedure dei clienti, ma in genere include operazioni come le distribuzioni di test per le prestazioni degli endpoint, i controlli della qualità dei dati, gli unit test e i controlli di intelligenza artificiale responsabili per il modello e la distorsione dei dati. Per gli scenari CV, è possibile omettere la ripetizione del training del candidato del modello sui dati di produzione a causa di vincoli di risorse e tempo. Il team di data science può invece usare i dati di produzione per lo sviluppo di modelli e il modello candidato registrato dal ciclo di sviluppo è il modello valutato per la produzione. Questa fase viene eseguita in una o più aree di lavoro di Machine Learning dedicate e sicure.

  7. Distribuzione di produzione

    Dopo che un modello ha superato la fase di gestione temporanea e test, può essere promossa alla produzione tramite approvazioni a controllo umano nel ciclo. Le opzioni di distribuzione del modello includono un endpoint batch gestito per scenari batch o, per scenari online quasi in tempo reale, un endpoint online gestito o una distribuzione Kubernetes usando Azure Arc. La produzione viene in genere eseguita in una o più aree di lavoro di Machine Learning dedicate e sicure.

  8. Monitoraggio

    Il monitoraggio nella gestione temporanea, nei test e nella produzione consente di raccogliere metriche per e agire sulle prestazioni del modello, dei dati e dell'infrastruttura. Il monitoraggio dei modelli e dei dati può includere il controllo delle prestazioni del modello nelle nuove immagini. Il monitoraggio dell'infrastruttura può controllare la risposta lenta degli endpoint, la capacità di calcolo inadeguata o i problemi di rete.

  9. Monitoraggio di dati e modelli: eventi e azioni

    Le fasi di monitoraggio e azione dei dati e del modello di MLOps per NLP sono le differenze principali rispetto all'apprendimento automatico classico. La ripetizione automatica del training non viene in genere eseguita negli scenari CV quando viene rilevata una riduzione delle prestazioni del modello sulle nuove immagini. In questo caso, le nuove immagini per le quali il modello esegue prestazioni scarse devono essere esaminate e annotate da un processo umano nel ciclo, e spesso l'azione successiva torna al ciclo di sviluppo del modello per aggiornare il modello con le nuove immagini.

  10. Monitoraggio dell'infrastruttura: eventi e azioni

    In base ai criteri per le questioni relative all'infrastruttura, ad esempio il ritardo di risposta dell'endpoint o il calcolo insufficiente per la distribuzione, i trigger e le notifiche automatizzati possono implementare azioni appropriate da intraprendere. In questo modo viene attivato un loopback alla fase di installazione e amministrazione in cui il team dell'infrastruttura può analizzare e riconfigurare potenzialmente le risorse di ambiente, calcolo e rete.

Architettura NLP di Machine Learning

Diagramma dell'architettura N L P.

Scaricare un file di Visio di questa architettura.

Flusso di lavoro per l'architettura NLP

L'architettura NLP di Machine Learning si basa sull'architettura classica di Machine Learning, ma presenta alcune modifiche specifiche per gli scenari NLP.

  1. Data estate

    Questo elemento illustra il patrimonio di dati dell'organizzazione e le potenziali origini dati e le destinazioni per un progetto di data science. I data engineer sono i proprietari principali di questo elemento del ciclo di vita di MLOps v2. Le piattaforme dati di Azure in questo diagramma non sono né esaustive né prescrittive. Le origini dati e le destinazioni che rappresentano le procedure consigliate in base al caso d'uso del cliente sono indicate da un segno di spunta verde.

  2. Amministrazione e installazione

    Questo elemento è il primo passaggio della distribuzione dell'acceleratore MLOps v2. È costituito da tutte le attività correlate alla creazione e alla gestione di risorse e ruoli associati al progetto. Per gli scenari NLP, l'amministrazione e la configurazione dell'ambiente MLOps v2 sono in gran parte uguali a quella per l'apprendimento automatico classico, ma con un passaggio aggiuntivo: creare progetti di etichettatura e annotazione delle immagini usando la funzionalità di etichettatura di Machine Learning o un altro strumento.

  3. Sviluppo di modelli (ciclo interno)

    L'elemento del ciclo interno è costituito dal flusso di lavoro iterativo di data science eseguito all'interno di un'area di lavoro di Machine Learning dedicata e sicura. Il ciclo di sviluppo tipico del modello NLP può essere notevolmente diverso dallo scenario classico di Machine Learning in cui annotatori per frasi e tokenizzazione, normalizzazione e incorporamenti per i dati di testo sono i passaggi di sviluppo tipici per questo scenario.

  4. Registri di Machine Learning

    Dopo che il team di data science sviluppa un modello candidato per la distribuzione in produzione, il modello può essere registrato nel registro delle aree di lavoro di Machine Learning. Le pipeline di integrazione continua attivate automaticamente dalla registrazione del modello o dall'approvazione del ciclo umano gestito promuovono il modello e qualsiasi altra dipendenza del modello alla fase di distribuzione del modello.

  5. Distribuzione del modello (ciclo esterno)

    La fase di distribuzione o ciclo esterno del modello è costituita dalla gestione temporanea e dal test di pre-produzione, dalla distribuzione di produzione e dal monitoraggio del modello, dei dati e dell'infrastruttura. Le pipeline cd gestiscono la promozione del modello e degli asset correlati tramite produzione, monitoraggio e potenziale ripetizione del training, in quanto vengono soddisfatti i criteri per l'organizzazione e il caso d'uso.

  6. Gestione temporanea e test

    La fase di gestione temporanea e test può variare con le procedure dei clienti, ma in genere include operazioni come la ripetizione del training e il test del candidato del modello sui dati di produzione, le distribuzioni di test per le prestazioni degli endpoint, i controlli della qualità dei dati, gli unit test e i controlli di intelligenza artificiale responsabili per il modello e la distorsione dei dati. Questa fase viene eseguita in una o più aree di lavoro di Machine Learning dedicate e sicure.

  7. Distribuzione di produzione

    Dopo che un modello ha superato la fase di staging e test, può essere promossa alla produzione da un'approvazione controllata dall'utente nel ciclo. Le opzioni di distribuzione del modello includono un endpoint batch gestito per scenari batch o, per scenari online quasi in tempo reale, un endpoint online gestito o una distribuzione Kubernetes usando Azure Arc. La produzione viene in genere eseguita in una o più aree di lavoro di Machine Learning dedicate e sicure.

  8. Monitoraggio

    Il monitoraggio nella gestione temporanea, nei test e nella produzione consente di raccogliere e intervenire sulle modifiche apportate alle prestazioni del modello, dei dati e dell'infrastruttura. Il monitoraggio dei modelli e dei dati può includere il controllo della deriva dei modelli e dei dati, le prestazioni del modello sui nuovi dati di testo e i problemi di intelligenza artificiale responsabili. Il monitoraggio dell'infrastruttura può controllare i problemi, ad esempio la risposta lenta degli endpoint, la capacità di calcolo inadeguata e i problemi di rete.

  9. Monitoraggio di dati e modelli: eventi e azioni

    Come per l'architettura CV, le fasi di monitoraggio e evento e azione dei dati e dei modelli di MLOps per NLP sono le differenze principali rispetto all'apprendimento automatico classico. La ripetizione automatica del training non viene in genere eseguita negli scenari NLP quando viene rilevata una riduzione delle prestazioni del modello sul nuovo testo. In questo caso, i nuovi dati di testo per i quali il modello esegue prestazioni scarse devono essere esaminati e annotati da un processo umano nel ciclo. Spesso l'azione successiva consiste nel tornare al ciclo di sviluppo del modello per aggiornare il modello con i nuovi dati di testo.

  10. Monitoraggio dell'infrastruttura: eventi e azioni

    In base ai criteri per le questioni relative all'infrastruttura, ad esempio il ritardo di risposta dell'endpoint o il calcolo insufficiente per la distribuzione, i trigger e le notifiche automatizzati possono implementare azioni appropriate da intraprendere. Attivano un loopback alla fase di configurazione e amministrazione in cui il team dell'infrastruttura può analizzare e potenzialmente riconfigurare le risorse di calcolo e di rete.

Componenti

  • Machine Learning: un servizio cloud per il training, l'assegnazione di punteggi, la distribuzione e la gestione di modelli di Machine Learning su larga scala.
  • Azure Pipelines: questo sistema di compilazione e test si basa su Azure DevOps e viene usato per le pipeline di compilazione e versione. Azure Pipelines suddivide queste pipeline in passaggi logici denominati attività.
  • GitHub: piattaforma di hosting del codice per il controllo della versione, la collaborazione e i flussi di lavoro CI/CD.
  • Azure Arc: piattaforma per la gestione di risorse di Azure e locali tramite Azure Resource Manager. Le risorse possono includere macchine virtuali, cluster Kubernetes e database.
  • Kubernetes: sistema open source per automatizzare la distribuzione, il ridimensionamento e la gestione delle applicazioni in contenitori.
  • Azure Data Lake: file system compatibile con Hadoop. Ha uno spazio dei nomi gerarchico integrato e la scalabilità e l'economia di blob Archiviazione.
  • Azure Synapse Analytics: è un servizio di analisi senza limiti che combina integrazione dei dati, funzionalità aziendali di data warehousing e analisi di Big Data.
  • Hub eventi di Azure. Servizio che inserisce flussi di dati generati dalle applicazioni client. Inserisce e archivia quindi i dati di streaming, mantenendo la sequenza di eventi ricevuti. I consumer possono connettersi agli endpoint degli hub per recuperare i messaggi da elaborare. In questo caso si sfrutta l'integrazione con Data Lake Archiviazione.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi