MLOps (Machine Learning Operations)

  • Articolo

Questo articolo descrive tre architetture di Azure per le operazioni per l'apprendimento automatico con pipeline di integrazione continua e recapito continuo (CI/CD) end-to-end e pipeline di ripetizione del training. Le architetture sono destinate a queste applicazioni di IA:

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

Queste architetture sono il prodotto del progetto MLOps v2. Incorporano procedure consigliate identificate dagli architetti di soluzioni nel processo di sviluppo di varie soluzioni di machine learning. Il risultato è distribuibile, ripetibile e gestibile. Tutte e tre le architetture usano il servizio Azure Machine Learning.

Per un'implementazione con modelli di distribuzione di esempio per MLOps v2, vedere Repository GitHub di Azure MLOps v2.

Potenziali casi d'uso

  • Machine Learning classico: le previsioni, la regressione e la classificazione delle serie temporali sui dati strutturati tabulari sono i casi d'uso più comuni in questa categoria. Alcuni esempi:

    • Classificazione binaria e con più etichette.

    • Regressione lineare, polinomiale, ridge, lasso, quantile e Bayesian.

    • ARIMA, autoregressive, SARIMA, VAR, SES, LSTM.

  • CV: il framework MLOps, in questo articolo, è incentrato principalmente sui casi d'uso CV di segmentazione e classificazione immagini.

  • Elaborazione del linguaggio naturale: è possibile usare questo framework MLOps per implementare:

    • 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 IA, l'apprendimento avanzato per rinforzo e altre forme di IA non sono descritte in questo articolo.

Architettura

Il modello di architettura MLOps v2 include quattro componenti modulari principali, o fasi, del ciclo di vita mlops:

  • Patrimonio di dati
  • Amministrazione e installazione
  • Sviluppo di modelli o fase del ciclo interno
  • Distribuzione modello o fase del ciclo esterno

I componenti precedenti, le connessioni tra di essi e i tipici utenti coinvolti sono standard in tutte le architetture di scenari MLOps v2. Le variazioni nei dettagli di ogni componente dipendono dallo scenario.

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

MLOps v2 illustra le architetture seguenti descritte in questo articolo:

Architettura di Machine Learning classica

Diagramma che mostra 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. Patrimonio di dati

    Questo componente 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 componente del ciclo di vita di MLOps v2. Le piattaforme dati di Azure in questo diagramma non sono esaustive o prescrittive. Un segno di spunta verde indica le origini dati e le destinazioni che rappresentano le procedure consigliate basate sul caso d'uso del cliente.

  2. Amministrazione e installazione

    Questo componente è il primo passaggio della distribuzione della soluzione MLOps v2. È costituito da tutte le attività correlate alla creazione e alla gestione di risorse e ruoli associati al progetto. Ad esempio, il team dell'infrastruttura potrebbe:

    1. Creare repository di codice sorgente del progetto.
    2. Usare Bicep o Terraform per creare aree di lavoro di Machine Learning.
    3. Creare o modificare set di dati e risorse di calcolo per lo sviluppo e la distribuzione di modelli.
    4. Definire gli utenti del team di progetto, i ruoli e i controlli di accesso ad altre risorse.
    5. Creare pipeline CI/CD.
    6. Creare componenti di monitoraggio per raccogliere e creare avvisi per le metriche del modello e dell'infrastruttura.

    L'utente principale associato a questa fase è il team dell'infrastruttura, ma un'organizzazione potrebbe avere anche data engineer, ingegneri di Machine Learning o data scientist.

  3. Sviluppo di modelli (fase del ciclo interno)

    La fase del ciclo interno è costituita da un flusso di lavoro iterativo di data science che agisce all'interno di un'area di lavoro di Machine Learning dedicata e sicura. Il diagramma precedente mostra un flusso di lavoro tipico. Il processo inizia con l'inserimento dati, passa attraverso l'analisi esplorativa dei dati, la sperimentazione, lo sviluppo e la valutazione del modello e quindi registra un modello per l'uso in produzione. Questo componente modulare è indipendente e adattabile al processo usato dal team di data science per sviluppare modelli.

    Le figure 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 che può essere distribuito nell'ambiente di produzione, registra il modello nel registro delle aree di lavoro di Machine Learning. Le 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 figure associate a questa fase sono in genere ingegneri di Machine Learning.

  5. Distribuzione del modello (fase del ciclo esterno)

    La fase di distribuzione del modello, o ciclo esterno, è costituita dalla fase di staging e test della preproduzione, dalla distribuzione di produzione e dal monitoraggio del modello, dei dati e dell'infrastruttura. Quando il modello soddisfa i criteri dell'organizzazione e del caso d'uso, le pipeline CD promuovono il modello e gli asset correlati tramite produzione, monitoraggio e potenziale ripetizione del training.

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

  6. Staging e test

    La fase di staging e test varia in base alle procedure dei clienti. Questa fase include in genere operazioni quali 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 dedicate e sicure di Machine Learning.

  7. Distribuzione di produzione

    Dopo che un modello ha superato la fase di gestione temporanea e test, gli ingegneri di Machine Learning possono usare l'approvazione controllata dall'utente nel ciclo per promuoverla alla produzione. Le opzioni di distribuzione del modello includono un endpoint batch gestito per scenari batch o un endpoint online gestito o una distribuzione Kubernetes che usa Azure Arc per scenari online quasi in tempo reale. La produzione viene generalmente eseguita in una o più aree di lavoro dedicate e sicure di Machine Learning.

  8. Monitoraggio

    Gli ingegneri di Machine Learning monitorano i componenti nella gestione temporanea, nei test e nella produzione per raccogliere metriche correlate alle modifiche apportate alle prestazioni del modello, dei dati e dell'infrastruttura. Possono usare queste metriche per intervenire. Il monitoraggio dei modelli e dei dati può includere la verifica della deriva del modello e dei dati, delle prestazioni del modello sui nuovi dati e dei problemi di IA responsabili. Il monitoraggio dell'infrastruttura potrebbe identificare la risposta lenta degli endpoint, la capacità di calcolo inadeguata o i problemi di rete.

  9. Monitoraggio dati e modelli: eventi e azioni

    In base a criteri di modello e dati, ad esempio soglie o pianificazioni delle metriche, trigger e notifiche automatizzati possono implementare azioni appropriate da intraprendere. Ad esempio, un trigger potrebbe ripetere il training di un modello per usare nuovi dati di produzione e quindi eseguire il loopback del modello allo staging e al test per una valutazione di preproduzione. In alternativa, un modello o un problema di dati potrebbe attivare un'azione che richiede un loopback alla fase di sviluppo del modello in cui i data scientist possono analizzare il problema e potenzialmente sviluppare un nuovo modello.

  10. Monitoraggio infrastruttura: eventi e azioni

    I trigger e le notifiche automatizzati possono implementare azioni appropriate da intraprendere in base ai criteri dell'infrastruttura, ad esempio un ritardo di risposta dell'endpoint o un calcolo insufficiente per la distribuzione. I trigger automatici e le notifiche possono attivare un loopback alla fase di installazione e amministrazione in cui il team dell'infrastruttura può analizzare il problema e potenzialmente riconfigurare le risorse di calcolo e di rete.

Architettura di Machine Learning CV

Diagramma che mostra l'architettura di visione artificiale.

Scaricare un file di Visio di questa architettura.

Flusso di lavoro per l'architettura CV

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

  1. Patrimonio di dati

    Questo componente mostra 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 componente del ciclo di vita in MLOps v2. Le piattaforme dati di Azure in questo diagramma non sono esaustive o prescrittive. Le immagini per gli scenari CV possono provenire da varie origini dati. Per garantire l'efficienza durante lo sviluppo e la distribuzione di modelli CV con Machine Learning, è consigliabile Archiviazione BLOB di Azure e Azure Data Lake Storage.

  2. Amministrazione e installazione

    Questo componente è il primo passaggio della distribuzione 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 include un passaggio aggiuntivo. Il team dell'infrastruttura usa la funzionalità di etichettatura di Machine Learning o un altro strumento per creare progetti di etichettatura e annotazione delle immagini.

  3. Sviluppo di modelli (fase del ciclo interno)

    La fase del ciclo interno è costituita da un 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 componente chiave di questo ciclo di sviluppo.

  4. Registri di Machine Learning

    Dopo che il team di data science sviluppa un modello che può essere distribuito nell'ambiente di produzione, registra il modello nel registro delle aree di lavoro di Machine Learning. Le 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.

  5. Distribuzione del modello (fase del ciclo esterno)

    La fase di distribuzione del modello, o ciclo esterno, è costituita dalla fase di staging e test della preproduzione, dalla distribuzione di produzione e dal monitoraggio del modello, dei dati e dell'infrastruttura. Quando il modello soddisfa i criteri dell'organizzazione e del caso d'uso, le pipeline CD promuovono il modello e gli asset correlati tramite produzione, monitoraggio e potenziale ripetizione del training.

  6. Staging e test

    La fase di staging e test varia in base alle procedure dei clienti. Questa fase include in genere 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, gli ingegneri di Machine Learning non devono ripetere il 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. Il modello candidato registrato dal ciclo di sviluppo viene valutato per la produzione. Questa fase viene eseguita in una o più aree di lavoro dedicate e sicure di Machine Learning.

  7. Distribuzione di produzione

    Dopo che un modello ha superato la fase di gestione temporanea e test, gli ingegneri di Machine Learning possono usare l'approvazione controllata dall'utente nel ciclo per promuoverla alla produzione. Le opzioni di distribuzione del modello includono un endpoint batch gestito per scenari batch o un endpoint online gestito o una distribuzione Kubernetes che usa Azure Arc per scenari online quasi in tempo reale. La produzione viene generalmente eseguita in una o più aree di lavoro dedicate e sicure di Machine Learning.

  8. Monitoraggio

    Gli ingegneri di Machine Learning monitorano i componenti nella gestione temporanea, nei test e nella produzione per raccogliere metriche correlate alle modifiche apportate alle prestazioni del modello, dei dati e dell'infrastruttura. Possono usare queste metriche per intervenire. Il monitoraggio dei modelli e dei dati può includere il controllo delle prestazioni del modello nelle nuove immagini. Il monitoraggio dell'infrastruttura potrebbe identificare la risposta lenta degli endpoint, la capacità di calcolo inadeguata o i problemi di rete.

  9. Monitoraggio dati e modelli: eventi e azioni

    Le fasi di monitoraggio dati e modello ed evento e azione di MLOps per l'elaborazione del linguaggio naturale 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, è necessario un processo umano nel ciclo per esaminare e annotare nuovi dati di testo per il modello con prestazioni scarse. L'azione successiva spesso torna al ciclo di sviluppo del modello per aggiornare il modello con le nuove immagini.

  10. Monitoraggio infrastruttura: eventi e azioni

    I trigger e le notifiche automatizzati possono implementare azioni appropriate da intraprendere in base ai criteri dell'infrastruttura, ad esempio un ritardo di risposta dell'endpoint o un calcolo insufficiente per la distribuzione. I trigger automatici e le notifiche possono attivare un loopback alla fase di installazione e amministrazione in cui il team dell'infrastruttura può analizzare il problema e potenzialmente riconfigurare l'ambiente, le risorse di calcolo e di rete.

Architettura di elaborazione del linguaggio naturale di Machine Learning

Diagramma per l'architettura di elaborazione del linguaggio naturale.

Scaricare un file di Visio di questa architettura.

Flusso di lavoro per l'architettura di elaborazione del linguaggio naturale

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

  1. Patrimonio di dati

    Questo componente mostra 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 componente del ciclo di vita in MLOps v2. Le piattaforme dati di Azure in questo diagramma non sono esaustive o prescrittive. Un segno di spunta verde indica le origini e le destinazioni che rappresentano le procedure consigliate basate sul caso d'uso del cliente.

  2. Amministrazione e installazione

    Questo componente è il primo passaggio della distribuzione mlops v2. È costituito da tutte le attività correlate alla creazione e alla gestione di risorse e ruoli associati al progetto. Per gli scenari di elaborazione del linguaggio naturale, l'amministrazione e la configurazione dell'ambiente MLOps v2 sono in gran parte uguali a quella di Machine Learning 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 (fase del ciclo interno)

    La fase del ciclo interno è costituita da un flusso di lavoro iterativo di data science eseguito all'interno di un'area di lavoro di Machine Learning dedicata e sicura. Il tipico ciclo di sviluppo di modelli NLP differisce dallo scenario classico di Machine Learning in quanto i passaggi di sviluppo tipici per questo scenario includono annotatori per frasi e tokenizzazione, normalizzazione e incorporamenti per i dati di testo.

  4. Registri di Machine Learning

    Dopo che il team di data science sviluppa un modello che può essere distribuito nell'ambiente di produzione, registra il modello nel registro delle aree di lavoro di Machine Learning. Le 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.

  5. Distribuzione del modello (fase del ciclo esterno)

    La fase di distribuzione del modello, o ciclo esterno, è costituita dalla fase di staging e test della preproduzione, dalla distribuzione di produzione e dal monitoraggio del modello, dei dati e dell'infrastruttura. Quando il modello soddisfa i criteri dell'organizzazione e del caso d'uso, le pipeline CD promuovono il modello e gli asset correlati tramite produzione, monitoraggio e potenziale ripetizione del training.

  6. Staging e test

    La fase di staging e test varia in base alle procedure dei clienti. Questa fase include in genere operazioni quali 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 dedicate e sicure di Machine Learning.

  7. Distribuzione di produzione

    Dopo che un modello ha superato la fase di gestione temporanea e test, gli ingegneri di Machine Learning possono usare l'approvazione controllata dall'utente nel ciclo per promuoverla alla produzione. Le opzioni di distribuzione del modello includono un endpoint batch gestito per scenari batch o un endpoint online gestito o una distribuzione Kubernetes che usa Azure Arc per scenari online quasi in tempo reale. La produzione viene generalmente eseguita in una o più aree di lavoro dedicate e sicure di Machine Learning.

  8. Monitoraggio

    Gli ingegneri di Machine Learning monitorano i componenti nella gestione temporanea, nei test e nella produzione per raccogliere metriche correlate alle modifiche apportate alle prestazioni del modello, dei dati e dell'infrastruttura. Possono usare queste metriche per intervenire. Il monitoraggio dei modelli e dei dati può includere la verifica della deriva del modello e dei dati, delle prestazioni del modello sui nuovi dati di testo e dei problemi di IA responsabili. Il monitoraggio dell'infrastruttura potrebbe identificare i problemi, ad esempio la risposta lenta degli endpoint, la capacità di calcolo inadeguata e i problemi di rete.

  9. Monitoraggio dati e modelli: eventi e azioni

    Come per l'architettura CV, le fasi di monitoraggio dati e modello ed evento e azione di MLOps per l'elaborazione del linguaggio naturale sono le differenze principali rispetto all'apprendimento automatico classico. La ripetizione automatica del training non viene in genere eseguita in scenari di elaborazione del linguaggio naturale quando viene rilevata una riduzione delle prestazioni del modello sul nuovo testo. In questo caso, è necessario un processo umano nel ciclo per esaminare e annotare nuovi dati di testo per il modello con prestazioni scarse. 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 infrastruttura: eventi e azioni

    I trigger e le notifiche automatizzati possono implementare azioni appropriate da intraprendere in base ai criteri dell'infrastruttura, ad esempio un ritardo di risposta dell'endpoint o un calcolo insufficiente per la distribuzione. I trigger automatici e le notifiche possono attivare un loopback alla fase di installazione e amministrazione in cui il team dell'infrastruttura può analizzare il problema e potenzialmente riconfigurare le risorse di calcolo e di rete.

Componenti

  • Machine Learning è un servizio cloud che viene usato per eseguire il training, la scalabilità e la gestione di modelli di Machine Learning su larga scala.

  • Azure Pipelines è un sistema di compilazione e test basato su Azure DevOps e usato per le pipeline di compilazione e versione. Azure Pipelines suddivide queste pipeline in passaggi logici denominati attività.

  • GitHub è una piattaforma di hosting di codice per il controllo della versione, la collaborazione e i flussi di lavoro CI/CD.

  • Azure Arc è una piattaforma che usa Azure Resource Manager per gestire le risorse di Azure e le risorse locali. Le risorse possono includere macchine virtuali, cluster Kubernetes e database.

  • Kubernetes è un sistema open source che è possibile utilizzare per automatizzare la distribuzione, il ridimensionamento e la gestione delle applicazioni in contenitori.

  • Azure Data Lake Storage è un file system compatibile con Hadoop. È caratterizzato da uno spazio dei nomi gerarchico integrato e dalla grande quantità di scalabilità ed economia di Archiviazione BLOB.

  • Azure Synapse Analytics è un servizio di analisi senza limiti che riunisce funzionalità di integrazione dei dati, archiviazione dati aziendali e analisi di Big Data.

  • Hub eventi di Azure è un servizio che inserisce flussi di dati generati da applicazioni client. Inserisce e archivia i dati di streaming mantenendo la sequenza di eventi ricevuti. I clienti possono connettersi agli endpoint degli hub per recuperare i messaggi da elaborare. Questa architettura usa l'integrazione di Data Lake Storage.

Altre considerazioni

Il modello di architettura MLOps v2 precedente include diversi componenti critici, tra cui il controllo degli accessi in base al ruolo (RBAC) allineato agli stakeholder aziendali, una gestione efficiente dei pacchetti e meccanismi di monitoraggio affidabili. Questi componenti contribuiscono collettivamente alla corretta implementazione e gestione dei flussi di lavoro di Machine Learning.

RBAC basato su persona

È fondamentale gestire l'accesso ai dati e alle risorse di Machine Learning. RBAC offre un framework affidabile che consente di gestire chi può eseguire azioni specifiche e accedere a aree specifiche all'interno della soluzione. Progettare la strategia di segmentazione delle identità per allinearsi al ciclo di vita dei modelli di Machine Learning in Machine Learning e alle figure coinvolte nel processo. Ogni figura ha un set specifico di responsabilità che si riflettono nei ruoli controllo degli accessi in base al ruolo e nell'appartenenza ai gruppi.

Figura di esempio

Per supportare una segmentazione appropriata in un carico di lavoro di Machine Learning, considerare le figure comuni seguenti, che informano la progettazione del gruppo RBAC basato sull'identità.

Data scientist e ingegneri di Machine Learning

I data scientist e gli ingegneri di Machine Learning eseguono varie attività di machine learning e data science nel ciclo di vita dello sviluppo software di un progetto. I compiti includono l'analisi esplorativa dei dati e la pre-elaborazione dei dati. I data scientist e i tecnici di Machine Learning sono responsabili del training, della valutazione e della distribuzione di modelli. Queste responsabilità dei ruoli includono anche attività di correzione delle interruzioni per modelli, pacchetti e dati di Machine Learning. Questi compiti non rientrano nell'ambito del team di supporto tecnico della piattaforma.

Tipo: persona
Progetto specifico: Sì

Analista dei dati

Gli analisti dei dati forniscono l'input necessario per le attività di data science, ad esempio l'esecuzione di query SQL per business intelligence. Le responsabilità di questo ruolo includono l'uso dei dati, l'esecuzione dell'analisi dei dati e il supporto dello sviluppo di modelli e della distribuzione modello.

Tipo: persona
Progetto specifico: Sì

Tester del modello

I tester di modelli eseguono test negli ambienti di test e di gestione temporanea. Questo ruolo fornisce la separazione funzionale dai processi CI/CD.

Tipo: persona
Progetto specifico: Sì

Stakeholder aziendali

Gli stakeholder aziendali sono associati al progetto, ad esempio un responsabile marketing.

Tipo: persona
Progetto specifico: Sì

Responsabile del progetto o responsabile data science

Il responsabile data science è un ruolo di amministrazione del progetto per l'area di lavoro di Machine Learning. Questo ruolo esegue anche attività di correzione dell'interruzione per i modelli e i pacchetti di Machine Learning.

Tipo: persona
Progetto specifico: Sì

Proprietario del progetto o del prodotto (proprietario dell'azienda)

Gli stakeholder aziendali sono responsabili dell'area di lavoro di Machine Learning in base alla proprietà dei dati.

Tipo: persona
Progetto specifico: Sì

Supporto tecnico della piattaforma

Il supporto tecnico della piattaforma è il personale di supporto tecnico responsabile delle attività di correzione delle interruzioni nella piattaforma. Questo ruolo riguarda l'infrastruttura o il servizio, ma non i modelli, i pacchetti o i dati di Machine Learning. Questi componenti rimangono sotto il ruolo di data scientist o di ingegneria di Machine Learning e sono responsabilità del responsabile del progetto.

Tipo: persona
Specifico del progetto: No

Utente finale del modello

Gli utenti finali del modello sono i consumer finali del modello di Machine Learning.

Tipo: Persona o Processo
Progetto specifico: Sì

Processi CI/CD

Processi CI/CD rilascia o esegue il rollback delle modifiche in ambienti della piattaforma.

Tipo: Processo
Specifico del progetto: No

Area di lavoro di Machine Learning

Le aree di lavoro di Machine Learning usano identità gestite per interagire con altre parti di Azure. Questa figura rappresenta i vari servizi che costituiscono un'implementazione di Machine Learning. Questi servizi interagiscono con altre parti della piattaforma, ad esempio l'area di lavoro di sviluppo che si connette all'archivio dati di sviluppo.

Tipo: Processo
Specifico del progetto: No

Processi di monitoraggio

I processi di monitoraggio sono processi di calcolo che monitorano e avvisano in base alle attività della piattaforma.

Tipo: Processo
Specifico del progetto: No

Processi di governance dei dati

I processi di governance dei dati analizzano il progetto di Machine Learning e gli archivi dati per la governance dei dati.

Tipo: Processo
Specifico del progetto: No

Appartenenza a un gruppo Microsoft Entra

Quando si implementa RBAC, i gruppi di Microsoft Entra offrono un modo flessibile e scalabile per gestire le autorizzazioni di accesso in diversi utenti. È possibile usare i gruppi di Microsoft Entra per gestire gli utenti che necessitano degli stessi accessi e autorizzazioni per le risorse, ad esempio app e servizi potenzialmente limitati. Invece di aggiungere autorizzazioni speciali ai singoli utenti, si crea un gruppo che applica le autorizzazioni speciali a ogni membro del gruppo.

In questo modello di architettura, è possibile associare questi gruppi a una configurazione dell'area di lavoro di Machine Learning, ad esempio un progetto, un team o un reparto. È possibile associare gli utenti a gruppi specifici per definire criteri di accesso con granularità fine. I criteri concedono o limitano le autorizzazioni a varie aree di lavoro di Machine Learning in base alle funzioni del processo, ai requisiti del progetto o ad altri criteri. Ad esempio, è possibile avere un gruppo che concede a tutti i data scientist l'accesso a un'area di lavoro di sviluppo per un caso d'uso specifico.

RBAC Identity

Si consideri come usare i ruoli predefiniti di RBAC di Azure seguenti per applicare RBAC agli ambienti di produzione e preproduzione. Per l'architettura in questo articolo, gli ambienti di produzione includono ambienti di gestione temporanea, test e produzione. Gli ambienti di preproduzione includono ambienti di sviluppo. I ruoli di RBAC seguenti si basano sugli utenti personali descritti in precedenza in questo articolo.

Ruoli standard

Ruoli specifici del componente

Queste abbreviazioni di RBAC di Azure corrispondono alle tabelle seguenti.

Ambiente di produzione
Utente tipo Area di lavoro di Machine Learning Azure Key Vault Registro Container account di archiviazione di Azure Azure DevOps Azure Artifacts area di lavoro Log Analytics Monitoraggio di Azure
Scienziato dei dati R LAR MR
Analista dei dati
Tester del modello
Stakeholder aziendali MR
Responsabile progetto (responsabile data science) R R, KVR R LAR MR
Proprietario progetto/prodotto MR
Supporto tecnico della piattaforma O O, KVA DOPCA O O O
Utente finale del modello
Processi CI/CD O O, KVA AcrPush DOPCA O O O
Area di lavoro di Machine Learning R A A
Processi di monitoraggio R LAR MR
Processi di governance dei dati R R R R R
Ambiente di pre-produzione
Utente tipo Area di lavoro di Machine Learning Insieme di credenziali delle chiavi di Registro Container Account di archiviazione Azure DevOps Azure Artifacts area di lavoro Log Analytics Monitoraggio di Azure
Scienziato dei dati ADS R, KVA A A A A LAC MC
Analista dei dati R A LAR MC
Tester del modello R R, KVR R R R R LAR MR
Stakeholder aziendali R R R R R
Responsabile progetto (responsabile data science) A C, KVA A A A A LAC MC
Proprietario progetto/prodotto R R MR
Supporto tecnico della piattaforma O O, KVA O O DOPCA O O O
Utente finale del modello
Processi CI/CD O O, KVA AcrPush O DOPCA O O O
Area di lavoro di Machine Learning R, KVR A A
Processi di monitoraggio R R R R R R LAC
Processi di governance dei dati R R R

Nota

Ogni utente mantiene l'accesso per la durata del progetto, ad eccezione del supporto tecnico della piattaforma, che ha accesso temporaneo o just-in-time a Microsoft Entra Privileged Identity Management (PIM).

RBAC svolge un ruolo fondamentale nella protezione e nella semplificazione dei flussi di lavoro MLOps. RBAC limita l'accesso in base ai ruoli assegnati e impedisce agli utenti non autorizzati di accedere ai dati sensibili, attenuando così i rischi per la sicurezza. I dati sensibili includono i dati di training o i modelli e l'infrastruttura critica, ad esempio le pipeline di produzione. È possibile usare RBAC in base al ruolo per garantire la conformità alle normative sulla privacy dei dati. RBAC fornisce anche un record chiaro di accesso e autorizzazioni, che semplifica il controllo, semplifica l'identificazione delle lacune di sicurezza e tiene traccia delle attività degli utenti.

Gestione pacchetti

Le dipendenze da vari pacchetti, librerie e file binari sono comuni in tutto il ciclo di vita di MLOps. Queste dipendenze, spesso sviluppate e in rapida evoluzione, richiedono conoscenze di esperti in materia per un uso e una comprensione appropriate. È necessario assicurarsi che le persone appropriate abbiano accesso sicuro a risorse diverse, ad esempio pacchetti e librerie, ma è anche necessario prevenire le vulnerabilità. I data scientist riscontrano questo problema quando assemblano blocchi predefiniti specializzati per le soluzioni di Machine Learning. Gli approcci di gestione software tradizionali sono costosi e inefficienti. Altri approcci offrono un valore maggiore.

Per gestire queste dipendenze, è possibile usare un processo di gestione dei pacchetti sicuro, self-service basato sul modello quarantena. È possibile progettare questo processo per consentire ai data scientist di self-service da un elenco curato di pacchetti e assicurarsi che i pacchetti siano sicuri e conformi agli standard dell'organizzazione.

Questo approccio include tre repository di pacchetti di Machine Learning standard del settore: Registro artefatti Microsoft, Python Package Index (PyPI) e Conda. L'elenco sicuro consente l'uso self-service da singole aree di lavoro di Machine Learning. Usare quindi un processo di test automatizzato durante la distribuzione per analizzare i contenitori di soluzioni risultanti. Gli errori escono elegantemente dal processo di distribuzione e rimuovono il contenitore. Il diagramma e il flusso di processo seguenti illustrano questo processo:

Diagramma che mostra l'approccio sicuro del pacchetto di Machine Learning.

Flusso del processo

  1. I data scientist che lavorano in un'area di lavoro di Machine Learning con una configurazione di rete possono eseguire il self-service di pacchetti di Machine Learning su richiesta dai repository dei pacchetti di Machine Learning. Un processo di eccezione è necessario per tutto il resto usando il modello di archiviazione privato, che viene sottoposto a seeding e gestito tramite una funzione centralizzata.

  2. Machine Learning offre soluzioni di Machine Learning come contenitori Docker. Man mano che queste soluzioni vengono sviluppate, vengono caricate nel Registro contenitori. Microsoft Defender per contenitori genera valutazioni delle vulnerabilità per l'immagine del contenitore.

  3. La distribuzione della soluzione avviene tramite un processo CI/CD. Microsoft Defender per DevOps viene usato nello stack per fornire la gestione del comportamento di sicurezza e la protezione dalle minacce.

  4. Il contenitore della soluzione viene distribuito solo se passa ognuno dei processi di sicurezza. Se il contenitore della soluzione non riesce un processo di sicurezza, la distribuzione ha esito negativo con notifiche di errore e audit trail completi. Il contenitore della soluzione viene rimosso.

Il flusso di processo precedente fornisce un processo di gestione dei pacchetti sicuro, self-service per i data scientist e garantisce che i pacchetti siano sicuri e conformi agli standard dell'organizzazione. Per bilanciare l'innovazione e la sicurezza, è possibile concedere ai data scientist l'accesso self-service a pacchetti, librerie e file binari comuni di Machine Learning in ambienti di pre-produzione. Richiedere eccezioni per pacchetti meno comuni. Questa strategia garantisce che i data scientist possano rimanere produttivi durante lo sviluppo, impedendo un collo di bottiglia importante durante il recapito.

Per semplificare i processi di rilascio, inserire in contenitori gli ambienti da usare negli ambienti di produzione. Gli ambienti in contenitori riducono il lavoro e garantiscono una sicurezza continua tramite l'analisi delle vulnerabilità. Questo flusso di processo offre un approccio ripetibile che è possibile usare nei diversi casi d'uso al momento del recapito. Riduce il costo complessivo per compilare e distribuire soluzioni di Machine Learning all'interno dell'azienda.

Monitoraggio

In MLOps, il monitoraggio è fondamentale per mantenere l'integrità e le prestazioni dei sistemi di Machine Learning e garantire che i modelli rimangano efficaci e allineati agli obiettivi aziendali. Il monitoraggio supporta controlli di governance, sicurezza e costi durante la fase del ciclo interno. Fornisce inoltre l'osservabilità delle prestazioni, della riduzione del modello e dell'utilizzo durante la distribuzione di soluzioni durante la fase del ciclo esterno. Le attività di monitoraggio sono rilevanti per persone come Scienziato dei dati, stakeholder aziendali, lead di progetto, proprietari di progetti, supporto tecnico della piattaforma, processi CI/CD e processi di monitoraggio.

Scegliere la piattaforma di monitoraggio e verificare a seconda della configurazione dell'area di lavoro di Machine Learning, ad esempio un progetto, un team o un reparto.

Prestazioni modello

Monitorare le prestazioni del modello per rilevare i problemi del modello e la riduzione anticipata delle prestazioni. Tenere traccia delle prestazioni per garantire che i modelli rimangano accurati, affidabili e allineati agli obiettivi aziendali.

Deriva dei dati

La deriva dei dati tiene traccia delle modifiche nella distribuzione dei dati di input di un modello confrontandoli con i dati di training del modello o con i dati di produzione del passato recente. Queste modifiche sono il risultato di cambiamenti nelle dinamiche di mercato, nelle modifiche di trasformazione delle funzionalità o nelle modifiche dei dati upstream. Tali modifiche possono ridurre le prestazioni del modello, quindi è importante monitorare la deriva per garantire una correzione tempestiva. Per eseguire un confronto, il refactoring della deriva dei dati richiede set di dati e output di produzione recenti.

Ambiente: Produzione
Facilitazione di Azure: Machine Learning – Monitoraggio modello

Deriva della stima

La deviazione della previsione tiene traccia delle modifiche nella distribuzione degli output di previsione di un modello confrontandola con i dati di convalida, con etichetta di test o di produzione recenti. Per eseguire un confronto, il refactoring della deriva dei dati richiede set di dati e output di produzione recenti.

Ambiente: Produzione
Facilitazione di Azure: Machine Learning – Monitoraggio modello

Conto risorse

Usare diversi modelli che servono metriche degli endpoint per indicare qualità e prestazioni, ad esempio l'utilizzo della CPU o della memoria. Questo approccio consente di apprendere dalla produzione per favorire investimenti o cambiamenti futuri.

Ambiente: Tutti
Facilitazione di Azure: Monitoraggio - Metriche degli endpoint online

Metriche di utilizzo

Monitorare l'utilizzo degli endpoint per assicurarsi di soddisfare indicatori di prestazioni chiave specifici dell'organizzazione o specifici del carico di lavoro, tenere traccia dei modelli di utilizzo e diagnosticare e correggere i problemi riscontrati dagli utenti.

Richieste client

Tenere traccia del numero di richieste client all'endpoint del modello per comprendere il profilo di utilizzo attivo degli endpoint, che possono influire sulle attività di ridimensionamento od ottimizzazione dei costi.

Ambiente: Produzione
Facilitazione di Azure: Monitoraggio - Metriche degli endpoint online , ad esempio RequestsPerMinute. Note:

  • È possibile allineare le soglie accettabili al dimensionamento o alle anomalie personalizzate in base alle esigenze del carico di lavoro.
  • Ritirare i modelli che non sono più in uso dall'ambiente di produzione.
Ritardi di limitazione

I ritardi di limitazione sono rallentamenti nella richiesta e nella risposta dei trasferimenti di dati. La limitazione avviene a livello di Resource Manager e a livello di servizio. Tenere traccia delle metriche a entrambi i livelli.

Ambiente: Produzione
Facilitazione di Azure:

  • Monitoraggio - Resource Manager, somma di RequestThrottlingDelayMs, ResponseThrottlingDelayMs.
  • Machine Learning: per controllare le informazioni sulle richieste degli endpoint, è possibile abilitare i log del traffico degli endpoint online. È possibile usare un'area di lavoro Analisi dei log per elaborare i log.

Note: allineare le soglie accettabili agli obiettivi del livello di servizio del carico di lavoro (SLO) o ai contratti di servizio (SLA) e ai requisiti non funzionali della soluzione.

Errori generati

Tenere traccia degli errori del codice di risposta per misurare l'affidabilità del servizio e garantire il rilevamento anticipato dei problemi del servizio. Ad esempio, un aumento improvviso di 500 risposte di errore del server potrebbe indicare un problema critico che richiede attenzione immediata.

Ambiente: Produzione
Facilitazione di Azure: Machine Learning - Abilitare i log del traffico degli endpoint online per controllare le informazioni sulla richiesta. Ad esempio, è possibile controllare il conteggio di XRequestId usando ModelStatusCode o ModelStatusReason. È possibile usare un'area di lavoro Analisi dei log per elaborare i log.
Note:

  • Tutti i codici delle risposte HTTP nell'intervallo 400 e 500 vengono classificati come errore.

Ottimizzazione dei costi

La gestione dei costi e l'ottimizzazione in un ambiente cloud sono fondamentali perché consentono ai carichi di lavoro di controllare le spese, allocare le risorse in modo efficiente e ottimizzare il valore dei servizi cloud.

Ambiente di calcolo dell'area di lavoro

Quando le spese operative mensili raggiungono o superano un importo predefinito, generare avvisi per notificare agli stakeholder rilevanti, ad esempio lead di progetto o proprietari di progetti, in base ai limiti di configurazione dell'area di lavoro. È possibile determinare la configurazione dell'area di lavoro in base ai limiti correlati a progetto, team o reparto.

Ambiente: Tutti
Facilitazione di Azure: Gestione costi Microsoft - Avvisi relativi al budget
Note:

  • Impostare le soglie di budget in base alle stime iniziali dei costi e alle route NFR.
  • Usare più livelli di soglia. Più livelli soglia assicurano che gli stakeholder ottengano un avviso appropriato prima che il budget venga superato. Questi stakeholder possono includere lead aziendali, proprietari di progetti o lead di progetto a seconda dell'organizzazione o del carico di lavoro.
  • Gli avvisi di budget coerenti possono anche essere un trigger per il refactoring per supportare una maggiore domanda.
Decadimento dell'area di lavoro

Se un'area di lavoro di Machine Learning non mostra segni di utilizzo attivo in base all'utilizzo dell'ambiente di calcolo associato per il caso d'uso previsto, un proprietario del progetto potrebbe rimuovere le autorizzazioni dell'area di lavoro se non è più necessario per un determinato progetto.

Ambiente: Pre-produzione
Facilitazione di Azure:

Note:

  • I core attivi devono essere uguali a zero con l'aggregazione del conteggio.
  • Allineare le soglie di data alla pianificazione del progetto.

Sicurezza

Monitorare per rilevare le deviazioni dai controlli di sicurezza e dalle baseline appropriati per assicurarsi che le aree di lavoro di Machine Learning siano conformi ai criteri di sicurezza dell'organizzazione. È possibile usare una combinazione di criteri predefiniti e personalizzati.

Ambiente: Tutti
Facilitazione di Azure: Criteri di Azure per Machine Learning

Sicurezza degli endpoint

Per ottenere visibilità sulle API critiche per l'azienda, implementare il monitoraggio della sicurezza mirato di tutti gli endpoint di Machine Learning. È possibile analizzare e migliorare la postura di sicurezza delle API, assegnare priorità alle correzioni delle vulnerabilità e rilevare rapidamente minacce attive in tempo reale.

Ambiente: Produzione
Facilitazione di Azure: Microsoft Defender per API offre un'ampia protezione del ciclo di vita, rilevamento e copertura delle risposte per le API. Note: Defender per API fornisce sicurezza per le API pubblicate in API Management di Azure. È possibile eseguire l'onboarding di Defender per API nel portale di Microsoft Defender per il cloud o all'interno dell'istanza di API Management nel portale di Azure. È necessario integrare gli endpoint online di Machine Learning con API Management.

Monitoraggio distribuzione

Il monitoraggio della distribuzione garantisce che gli endpoint creati siano conformi ai criteri del carico di lavoro o dell'organizzazione e siano liberi dalle vulnerabilità. Questo processo richiede l'applicazione di criteri di conformità per le risorse di Azure prima e dopo la distribuzione, garantire la sicurezza continua tramite l'analisi delle vulnerabilità e assicurarsi che il servizio soddisfi gli SLO durante l'esecuzione.

Standard e governance

Monitorare per rilevare le deviazioni dagli standard appropriati e assicurarsi che il carico di lavoro sia conforme alle protezioni.

Ambiente: Tutti
Facilitazione di Azure:

  • Assegnazione e ciclo di vita dei criteri gestiti tramite Azure Pipelines per considerare i criteri come codice.
  • PSRule per Azure offre un framework di test per l'infrastruttura di Azure come codice.
  • È possibile usare i criteri di Azure aziendali come codice nei criteri di distribuzione di sistemi basati su CI/CD, set di criteri, assegnazioni, esenzioni dei criteri e assegnazioni di ruolo.

Nota: per maggiori, consultare la sezione Linee guida di Azure per la conformità alle normative sul Machine Learning.

Analisi della sicurezza

Implementare analisi di sicurezza automatizzate come parte dei processi di integrazione e distribuzione automatizzati.

Ambiente: Tutti
Facilitazione di Azure: Defender per DevOps
Nota: è possibile usare le app in Azure Marketplace per estendere questo processo per i moduli di test di sicurezza non Microsoft.

Manutenzione in corso

Monitorare la manutenzione in corso di un'API per l'ottimizzazione delle prestazioni, la sicurezza e l'utilizzo delle risorse. Garantire il rilevamento tempestivo degli errori, la risoluzione dei problemi efficiente e la conformità agli standard.

Ambiente: Produzione
Facilitazione di Azure:

Collaboratori

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

Autori principali:

Altri contributori:

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

Passaggi successivi