MLOps (Machine Learning Operations)

Questo articolo descrive tre architetture di Azure per le operazioni di Machine Learning 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 intelligenza artificiale:

• 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 Acceleratore di soluzioni 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 delle immagini.

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

  • Riconoscimento di entità denominate:

  • Classificazione testo

  • Generazione testo

  • Analisi valutazione

  • Traduzione

  • Risposta alle domande

  • Riepilogo

  • Rilevamento frasi

  • Rilevamento lingua

  • Tag delle parti del discorso

Le simulazioni di intelligenza artificiale, l'apprendimento avanzato per rinforzo e altre forme di intelligenza artificiale 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:

• Data estate
• Amministrazione e installazione
• Sviluppo di modelli o fase del ciclo interno
• Distribuzione del 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 per 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 classica di Machine Learning
• Architettura cv di Machine Learning
• Architettura di elaborazione del linguaggio naturale di Machine Learning

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 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 dell'acceleratore 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 dei 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 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 che può essere distribuito nell'ambiente di produzione, registra il modello 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 (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 persone associate a questa fase sono principalmente ingegneri di Machine Learning.

6. Gestione temporanea 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, i tecnici 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 avviene in genere in una o più aree di lavoro dedicate e sicure di Machine Learning.

8. Monitoraggio

   I tecnici 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 di 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 dell'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 cv di Machine Learning

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 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 nel ciclo di vita di 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 un'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 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 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 di integrazione continua attivate automaticamente dalla registrazione del modello o dall'approvazione del ciclo umano gestito 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 o ciclo esterno del modello è 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. Gestione temporanea 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, i tecnici 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, i tecnici 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 avviene in genere in una o più aree di lavoro dedicate e sicure di Machine Learning.

8. Monitoraggio

   I tecnici 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 di dati e modelli: eventi e azioni

   Le fasi di monitoraggio e azione dei dati e del modello 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 dell'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 e le notifiche automatici 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, il calcolo e le risorse di rete.

Architettura di elaborazione del linguaggio naturale di Machine Learning

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. Data estate

   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 nel 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 origini e destinazioni che rappresentano le procedure consigliate consigliate in base al caso d'uso del cliente.

2. Amministrazione e installazione

   Questo componente è 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 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 di integrazione continua attivate automaticamente dalla registrazione del modello o dall'approvazione del ciclo umano gestito 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 o ciclo esterno del modello è 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. Gestione temporanea 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, i tecnici 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 avviene in genere in una o più aree di lavoro dedicate e sicure di Machine Learning.

8. Monitoraggio

   I tecnici 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 di modelli e dati, delle prestazioni del modello sui nuovi dati di testo e dei problemi di intelligenza artificiale 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 di dati e modelli: eventi e azioni

   Come per l'architettura CV, le fasi di monitoraggio e evento e azione dei dati e del modello 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 dell'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 potrebbero 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 è possibile usare per eseguire il training, assegnare punteggi, distribuire e gestire 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 del 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 usare per automatizzare la distribuzione, il ridimensionamento e la gestione delle applicazioni in contenitori.

• Azure Data Lake Storage è un file system compatibile con Hadoop. Ha uno spazio dei nomi gerarchico integrato e la scalabilità massiccia e l'economia dell'archiviazione BLOB.

• Azure Synapse Analytics è un servizio di analisi illimitato che riunisce l'integrazione dei dati, il data warehousing aziendale e l'analisi dei Big Data.

• Hub eventi di Azure è un servizio che inserisce flussi di dati generati da applicazioni client. Inserisce e archivia quindi i dati di streaming, che conservano la sequenza di eventi ricevuti. I clienti possono connettersi agli endpoint hub per recuperare i messaggi per l'elaborazione. 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.

Controllo degli accessi in base al ruolo basato su persona

È fondamentale gestire l'accesso ai dati e alle risorse di Machine Learning. Il controllo degli accessi in base al ruolo 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 ai personaggi inclusi nel processo. Ogni persona ha un set specifico di responsabilità che si riflettono nei ruoli controllo degli accessi in base al ruolo e nell'appartenenza ai gruppi.

Persona di esempio

Per supportare la segmentazione appropriata in un carico di lavoro di Machine Learning, considerare le persone comuni seguenti che informano la progettazione del gruppo di controllo degli accessi in base all'identità.

Data scientist e ingegneri di Machine Learning

I data scientist e i tecnici 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 di modelli.

Tipo: Persona
Progetto specifico: Sì

Tester del modello

I tester di modelli eseguono test negli ambienti di test e 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 dell'analisi scientifica dei dati

Il responsabile dell'analisi scientifica dei dati è 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
Specifica 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
Specifica 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 persona 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
Specifica 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
Specifica 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
Specifica del progetto: No

Appartenenza al gruppo Microsoft Entra

Quando si implementa il controllo degli accessi in base al ruolo, 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.

Controllo degli accessi in base al ruolo delle identità

Si consideri come usare i ruoli predefiniti di Controllo degli accessi in base al ruolo di Azure seguenti per applicare il controllo degli accessi in base al ruolo 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 controllo degli accessi in base al ruolo seguenti si basano sugli utenti personali descritti in precedenza in questo articolo.

Ruoli standard

• R = Lettore
• C = Collaboratore
• O = Proprietario

Ruoli specifici del componente

• ADS = Scienziato dei dati di Machine Learning

• ACO = Operatore di calcolo di Machine Learning

• AcrPush = Registro Azure Container push

• DOPA = Amministratori del progetto DevOps

• DOPCA = DevOps Project Collection Administrators

• LAR = Lettore di Log Analytics

• LAC = Collaboratore log analytics

• MR = Lettore di monitoraggio

• MC = Collaboratore al monitoraggio

• KVA = Amministratore di Key Vault

• KVR = Lettore key vault

Queste abbreviazioni del ruolo controllo degli accessi in base al ruolo 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
Data scientist			R				LAR	MR
Analista dei dati
Tester del modello
Stakeholder aziendali								MR
Responsabile del progetto (responsabile dell'analisi scientifica dei dati)	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 preproduzione

Utente tipo	Area di lavoro di Machine Learning	Key Vault	Registro Container	Account di archiviazione	Azure DevOps	Azure Artifacts	area di lavoro Log Analytics	Monitoraggio di Azure
Data scientist	ANNUNCI	R, KVA	A	A	A	A	LACCA	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 del progetto (responsabile dell'analisi scientifica dei dati)	A	C, KVA	A	A	A	A	LACCA	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	LACCA
Processi di governance dei dati	R		R	R

Il controllo degli accessi in base al ruolo svolge un ruolo fondamentale nella protezione e nella semplificazione dei flussi di lavoro MLOps. Il controllo degli accessi in base al ruolo 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 il controllo degli accessi in base al ruolo per garantire la conformità alle normative sulla privacy dei dati. Il controllo degli accessi in base al ruolo 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:

Flusso del processo

1. I data scientist che lavorano in un'area di lavoro di Machine Learning con una configurazione di rete possono self-service 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 Container. 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 preproduzione. 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 verifica 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 confrontandola con i dati di training del modello o i dati di produzione precedenti recenti. 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 del modello

Deriva della stima

La deriva della stima tiene traccia delle modifiche nella distribuzione degli output di stima di un modello confrontandoli con i dati di convalida, etichettati con test o recenti di produzione. 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 del 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 o ottimizzazione dei costi.

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

• È possibile allineare le soglie accettabili al ridimensionamento 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 Log Analytics per elaborare i log.

Note: allineare le soglie accettabili agli obiettivi del livello di servizio del carico di lavoro o ai contratti di servizio 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 Log Analytics 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.

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 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: Preproduzione
Facilitazione di Azure:

• Monitoraggio - Metriche di Machine Learning
• Machine Learning - Metriche dell'area di lavoro, ad esempio il numero di core attivi in un periodo di tempo

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 il comportamento 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 LE API offre un'ampia protezione del ciclo di vita, rilevamento e copertura delle risposte per le API. Note: Defender per le API offre sicurezza per le API pubblicate in Azure Gestione API. È possibile eseguire l'onboarding di Defender per le API nel portale di Microsoft Defender per il cloud o nell'istanza di Gestione API nel portale di Azure. È necessario integrare gli endpoint online di Machine Learning con Gestione API.

Monitoraggio della 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 i contratti di servizio 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 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.

Note: per altre informazioni, vedere Linee guida di Azure per la conformità alle normative di 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
Note: è possibile usare le app in Azure Marketplace per estendere questo processo per i moduli di test di sicurezza non Microsoft.

Servizio in corso

Monitorare il servizio 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:

• Monitoraggio - Metriche di Machine Learning
• Machine Learning: è possibile abilitare i log del traffico degli endpoint online per controllare le informazioni sul servizio.

Collaboratori

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

Autori principali:

• Scott Donohoo | Senior Cloud Solution Architect
• Merge Steller | Senior Cloud Solution Architect

Altri contributori:

• Scott Mckinnon | Cloud Solution Architect
• Nicholas Moore | Cloud Solution Architect
• Darren Turchiarelli | Cloud Solution Architect
• Leo Kozhushnik | Cloud Solution Architect

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

Passaggi successivi

• Che cos'è Azure Pipelines?
• Panoramica di Azure Arc
• Che cos'è Machine Learning?
• Dati in Machine Learning
• Acceleratore di soluzioni Azure MLOps v2
• Operazioni di Machine Learning end-to-end (MLOps) con Machine Learning
• Introduzione ad Azure Data Lake Storage Gen2
• Documentazione di Azure DevOps
• Documentazione di GitHub
• Documentazione di Synapse Analytics
• Documentazione di Hub eventi
• Funzionamento di Machine Learning: risorse e asset (v2)
• Che cosa sono le pipeline di Machine Learning?

Risorse correlate

• Scegliere una tecnologia per i servizi di intelligenza artificiale di Microsoft Azure
• Tecnologia di elaborazione del linguaggio naturale (lab)
• Confrontare i prodotti e le tecnologie di apprendimento automatico di Microsoft
• Framework operativo di Machine Learning per un ciclo di vita di Machine Learning di alto livello con Machine Learning
• Che cos'è il processo di data science per i team?