Eseguire l'aggiornamento passando alla versione 2
Le API REST v2 di Azure Machine Learning, l'estensione dell'interfaccia della riga di comando di Azure e l'SDK di Python introducono coerenza e un set di nuove funzionalità per accelerare il ciclo di vita di Machine Learning di produzione. Questo articolo offre una panoramica dell'aggiornamento alla versione 2 con consigli utili per decidere la versione 1, la versione 2 o entrambi.
Prerequisiti
- Familiarità generale con Azure Machine Learning e con l'SDK di Python v1.
- Informazioni sulla versione 2
È consigliabile usare la versione 2?
È consigliabile usare la versione 2 se si avvia un nuovo progetto o flusso di lavoro di Machine Learning. È consigliabile usare v2 se si vogliono usare le nuove funzionalità offerte nella versione 2. Queste funzionalità comprendono:
- Inferenza gestita
- Componenti riutilizzabili nelle pipeline
- Miglioramento della pianificazione delle pipeline
- Dashboard di IA responsabile
- Registro degli asset
Un nuovo progetto v2 può riutilizzare risorse v1 esistenti come aree di lavoro e risorse di calcolo ed esistenti, ad esempio modelli e ambienti creati con v1.
Alcune lacune di funzionalità nella versione 2 includono:
- Supporto di Spark nei processi: è attualmente disponibile in anteprima nella versione 2.
- Pubblicazione di processi (pipeline nella versione 1) come endpoint. È tuttavia possibile pianificare le pipeline senza pubblicazione.
- Supporto per gli archivi dati sql/database.
- Possibilità di usare i componenti predefiniti classici nella finestra di progettazione con v2.
È quindi necessario assicurarsi che le funzionalità necessarie nella versione 2 soddisfino i requisiti dell'organizzazione, ad esempio essere disponibili a livello generale.
Importante
Le nuove funzionalità di Azure Machine Learning verranno avviate solo nella versione 2.
Quale API v2 è consigliabile usare?
Nelle interfacce v2 tramite l'API REST, sono disponibili l'interfaccia della riga di comando e l'SDK di Python. L'interfaccia da usare dipende dallo scenario e dalle preferenze.
| API | Note |
|---|---|
| REST | Minor numero di dipendenze e overhead. Usare per la creazione di applicazioni in Azure Machine Learning come piattaforma, direttamente nei linguaggi di programmazione senza un SDK fornito o in base alla preferenza personale. |
| CLI | Consigliato per l'automazione con CI/CD o per preferenza personale. Consente un'iterazione rapida con i file YAML e una separazione semplice tra il codice del modello di Azure Machine Learning e ML. |
| Python SDK | Consigliato per la creazione di script complessi (ad esempio, la generazione di processi di pipeline di grandi dimensioni a livello di codice) o per preferenza personale. Consente un'iterazione rapida con file YAML o sviluppo esclusivamente in Python. |
Mapping di Python SDK v1 a v2
Per un mapping del codice di confronto per SDK v1 e v2, vedere ognuno degli articoli seguenti.
| Risorse e asset | Articolo |
|---|---|
| Area di lavoro | Gestione dell'area di lavoro in SDK v1 e SDK v2 |
| Datastore | Gestione dell'archivio dati in SDK v1 e SDK v2 |
| Dati | Asset di dati in SDK v1 e v2 |
| Calcolo | Gestione degli ambienti di calcolo in SDK v1 e SDK v2 |
| Formazione | Esegui uno script |
| Formazione | Esecuzioni locali |
| Formazione | Ottimizzazione degli iperparametri |
| Formazione | Esecuzione parallela |
| Formazione | Pipeline |
| Formazione | AutoML |
| Modelli | Gestione dei modelli in SDK v1 e SDK v2 |
| Distribuzione | Aggiornare gli endpoint di distribuzione all'SDK v2 |
Risorse e asset nella v1 e v2
Questa sezione offre una panoramica di risorse e asset specifici in Azure Machine Learning. Per informazioni dettagliate sull'utilizzo in v2, vedere l'articolo relativo al concetto per ogni entità.
Area di lavoro
Non è necessario aggiornare le aree di lavoro con v2. È possibile usare la stessa area di lavoro, indipendentemente dal fatto che si usi la versione 1 o la versione 2.
Se si creano aree di lavoro usando l'automazione, è consigliabile aggiornare il codice per la creazione di un'area di lavoro alla versione 2. In genere le risorse di Azure vengono gestite tramite Azure Resource Manager (e Bicep) o strumenti di provisioning di risorse simili. In alternativa, è possibile usare i file dell'interfaccia della riga di comando di (v2) e YAML.
Per un confronto tra il codice SDK v1 e v2, vedere Gestione dell'area di lavoro in SDK v1 e SDK v2.
Importante
Se l'area di lavoro usa un endpoint privato, il flag v1_legacy_mode sarà abilitato automaticamente, impedendo l'uso delle API v2. Per informazioni dettagliate, vedere come configurare l'isolamento rete con v2.
Connessione (connessione dell'area di lavoro nella versione 1)
Le connessioni all'area di lavoro dalla versione 1 sono persistenti nell'area di lavoro e sono completamente disponibili con v2.
Per un confronto tra il codice SDK v1 e v2, vedere Gestione dell'area di lavoro in SDK v1 e SDK v2.
Archivio dati
I tipi di archivio dati di archiviazione oggetti creati con v1 sono completamente disponibili per l'uso nella versione 2. Gli archivi dati del database non sono supportati; l'esportazione nell'archivio oggetti (in genere BLOB di Azure) è il percorso di migrazione consigliato.
Per un confronto tra il codice dell'SDK v1 e v2, vedere Gestione dell'archivio dati nell'SDK v1 e nell'SDK v2.
Dati (set di dati nella versione 1)
I set di dati vengono rinominati in asset di dati. Viene fornita la compatibilità con le versioni precedenti, il che significa che è possibile usare i set di dati V1 nella versione 2. Quando si utilizza un set di dati V1 in un processo V2, si noterà che vengono mappati automaticamente ai tipi V2 come indicato di seguito:
- V1 FileDataset = V2 Folder (
uri_folder) - V1 TabularDataset = V2 Table (
mltable)
Si noti che Inoltra la compatibilità non è fornita, il che significa che non è possibile usare asset di dati V2 nella versione 1.
Questo articolo illustra come gestire i dati nella versione 2: Leggere e scrivere dati in un processo
Per un confronto del codice dell'SDK v1 e v2, vedere Asset di dati nell'SDK v1 e v2.
Calcolo
Calcolo di tipo AmlCompute e ComputeInstance completamente disponibile per l'uso nella versione 2.
Per un confronto tra codice nell'SDK v1 e v2, vedere Gestione delle risorse di calcolo nell'SDK v1 e SDK v2.
Processi (esperimenti, esecuzioni, pipeline nella versione 1)
Nella versione 2 gli "esperimenti", le "esecuzioni" e le "pipeline" sono stati consolidati nei processi. Un processo ha un tipo. La maggior parte dei processi sono command processi che eseguono un comando, ad esempio python main.py. Ciò che viene eseguito in un processo è indipendente da qualsiasi linguaggio di programmazione, quindi è possibile eseguire script bash, richiamare interpreti python, eseguire una serie di comandi curl o qualsiasi altra operazione. Un altro tipo comune di processo è pipeline, che definisce i processi figlio che possono avere relazioni di input/output, formando un grafo aciclico diretto (DAG).
Per un confronto tra il codice dell’SDK v1 e v2, vedere
- Esegui uno script
- Esecuzioni locali
- Ottimizzazione degli iperparametri
- Esecuzione parallela
- Pipeline
- AutoML
Progettista
È possibile usare la finestra di progettazione per compilare pipeline usando i propri componenti personalizzati v2 e i nuovi componenti predefiniti dal Registro di sistema. In questo caso, è possibile usare asset di dati v1 o v2 nella pipeline.
È possibile continuare a usare la finestra di progettazione per compilare pipeline usando i componenti predefiniti classici e i tipi di set di dati v1 (tabulare, file). Non è possibile usare i componenti predefiniti della finestra di progettazione esistente con asset di dati v2.
Non è possibile compilare una pipeline usando sia i componenti predefiniti della finestra di progettazione esistenti che i componenti personalizzati v2.
Modello
I modelli creati dalla versione 1 possono essere usati nella versione 2.
Per un confronto del codice dell'SDK v1 e v2, vedere Gestione dei modelli nell'SDK v1 e SDK v2
Endpoint e distribuzione (endpoint e servizio Web nella v1)
Con SDK/CLI v1 è possibile distribuire modelli in ACI o in servizio Azure Kubernetes come servizi Web. Le distribuzioni di modelli v1 esistenti e i servizi Web continueranno a funzionare così come sono, ma l'uso dell'SDK/dell'interfaccia della riga di comando v1 per distribuire modelli in ACI o nel servizio Azure Kubernetes come servizi Web ora è considerato legacy. Per le nuove distribuzioni di modelli, è consigliabile eseguire l'aggiornamento alla versione 2. Nella versione 2 sono disponibili endpoint gestiti o endpoint Kubernetes. Nella tabella seguente viene guidata la raccomandazione:
| Tipo di endpoint nella versione 2 | Aggiornamento da | Note |
|---|---|---|
| Locale | ACI | Test rapido della distribuzione del modello in locale; non per la produzione. |
| Endpoint online gestito | ACI, SERVIZIO AZURE KUBERNETES | Infrastruttura di distribuzione del modello gestito di livello aziendale con risposte quasi in tempo reale e scalabilità massiccia per la produzione. |
| Endpoint batch gestito | ParallelRunStep in una pipeline per l'assegnazione dei punteggi batch | Infrastruttura di distribuzione del modello gestito di livello aziendale con elaborazione batch parallela elevata per la produzione. |
| Servizio Azure Kubernetes (AKS) | ACI, SERVIZIO AZURE KUBERNETES | Gestire i cluster del servizio Azure Kubernetes personalizzati per la distribuzione del modello, offrendo flessibilità e controllo granulare al costo del sovraccarico IT. |
| Kubernetes con Azure Arc | N/D | Gestire i propri cluster Kubernetes in altri cloud o in locale, offrendo flessibilità e controllo granulare al costo del sovraccarico IT. |
Per un confronto tra codice dell'SDK v1 e v2, vedere Aggiornare gli endpoint di distribuzione per l'SDK v2. Per i passaggi di migrazione dai servizi Web ACI esistenti agli endpoint online gestiti, vedere l'articolo di guida all'aggiornamento e il blog.
Ambiente
Gli ambienti creati dalla versione 1 possono essere usati nella versione 2. Nella versione 2 gli ambienti hanno nuove funzionalità, ad esempio la creazione da un contesto Docker locale.
Gestione dei segreti
La gestione dei segreti di Key Vault differisce in modo significativo nella versione 2 rispetto alla versione 1. I metodi V1 set_secret e GET_SECRET SDK non sono disponibili nella versione 2. È invece consigliabile usare l'accesso diretto usando le librerie client di Key Vault. Quando si accede ai segreti da uno script di training, è possibile usare l'identità gestita dell'ambiente di calcolo o dell'identità.
Per informazioni dettagliate su Key Vault, vedere Usare i segreti delle credenziali di autenticazione nei processi di training di Azure Machine Learning.
Scenari nel ciclo di vita di Machine Learning
Esistono alcuni scenari comuni nel ciclo di vita di Machine Learning con Azure Machine Learning. Verranno esaminate alcune indicazioni generali per l'aggiornamento alla versione 2.
Configurazione di Azure
Azure consiglia i modelli di Azure Resource Manager (spesso tramite Bicep per semplificare l'uso) per creare risorse. Lo stesso approccio è valido anche per la creazione di risorse di Azure Machine Learning.
Se il team usa solo Azure Machine Learning, è possibile prendere in considerazione il provisioning dell'area di lavoro e di qualsiasi altra risorsa tramite file YAML e l'interfaccia della riga di comando.
Modelli di prototipazione
È consigliabile v2 per la creazione di prototipi di modelli. È possibile prendere in considerazione l'uso dell'interfaccia della riga di comando per un uso interattivo di Azure Machine Learning, mentre il codice di training del modello è Python o qualsiasi altro linguaggio di programmazione. In alternativa, è possibile adottare un approccio full-stack con Python esclusivamente usando Azure Machine Learning SDK o un approccio misto con i file Python SDK e YAML di Azure Machine Learning.
Training del modello di produzione
È consigliabile la versione 2 per il training del modello di produzione. I processi consolidano la terminologia e forniscono un set di coerenza che consente una transizione più semplice tra i tipi (ad esempio, da command a sweep) e un processo semplice per GitOps per la serializzazione dei processi in file YAML.
Con la versione 2, è necessario separare il codice di Machine Learning dal codice del piano di controllo. Questa separazione consente un'iterazione più semplice e consente una transizione più semplice tra locale e cloud. È anche consigliabile usare MLflow per il rilevamento e la registrazione dei modelli. Per informazioni dettagliate, vedere l'articolo sul concetto di MLflow.
Distribuzione del modello di produzione
È consigliabile la versione 2 per la distribuzione del modello di produzione. Gli endpoint gestiti astraggono il sovraccarico IT e offrono una soluzione efficiente per la distribuzione e l'assegnazione di punteggi ai modelli, sia per gli scenari online (quasi in tempo reale) che per gli scenari batch (in parallelo massiccio).
Le distribuzioni di Kubernetes sono supportate nella versione 2 tramite il servizio Azure Kubernetes o Azure Arc, abilitando le distribuzioni cloud e locali di Azure gestite dall'organizzazione.
MLOps (Machine Learning Operations)
Un flusso di lavoro MLOps prevede in genere CI/CD tramite uno strumento esterno. In genere un'interfaccia della riga di comando viene usata in CI/CD, anche se in alternativa è possibile richiamare Python o usare direttamente REST.
L'acceleratore di soluzioni per MLOps con v2 è in fase di sviluppo a https://github.com/Azure/mlops-v2 e può essere usato come riferimento o adottato per la configurazione e l'automazione del ciclo di vita di Machine Learning.
Nota su GitOps con v2
Un paradigma chiave con la v2 consiste nel serializzare le entità di Machine Learning come file YAML per il controllo del codice sorgente con git, consentendo approcci GitOps migliori rispetto a quelli possibili con la v1. Ad esempio, è possibile applicare criteri in base ai quali solo un'entità servizio usata nelle pipeline CI/CD può creare/aggiornare/eliminare alcune o tutte le entità, assicurando che le modifiche vengano eseguite in un processo regolamentato, ad esempio richieste pull con revisori necessari. Poiché i file nel controllo del codice sorgente sono YAML, sono facili da diff e tengono traccia delle modifiche nel tempo. L'utente e il team possono prendere in considerazione il passaggio a questo paradigma durante l'aggiornamento alla versione 2.
È possibile ottenere una rappresentazione YAML di qualsiasi entità con l'interfaccia della riga di comando tramite az ml <entity> show --output yaml. Si noti che questo output avrà proprietà generate dal sistema, che possono essere ignorate o eliminate.
È consigliabile aggiornare il codice esistente da v1 a v2
È possibile riutilizzare gli asset v1 esistenti nei flussi di lavoro v2. Ad esempio, è possibile usare un modello creato nella versione 1 per eseguire l'inferenza gestita nella versione 2.
Facoltativamente, se si desidera aggiornare parti specifiche del codice v1 esistente alla versione 2, vedere i collegamenti di confronto forniti in questo documento.
È possibile usare insieme v1 e v2?
V1 e v2 possono coesistere in un'area di lavoro. È possibile riutilizzare gli asset esistenti nei flussi di lavoro v2. Ad esempio, è possibile usare un modello creato nella versione 1 per eseguire l'inferenza gestita nella versione 2. Le risorse come l'area di lavoro, il calcolo e l'archivio dati funzionano tra v1 e v2, con eccezioni. Un utente può chiamare l'SDK di Python v1 per modificare la descrizione di un'area di lavoro, quindi usare di nuovo l'estensione dell'interfaccia della riga di comando v2. I processi (esperimenti/esecuzioni/pipeline nella versione 1) possono essere inviati alla stessa area di lavoro da SDK di Python v1 o v2. Un'area di lavoro può avere endpoint di distribuzione modello v1 e v2.
Usare insieme il codice della v1 e della v2
Non è consigliabile usare gli SDK v1 e v2 nello stesso codice. È tecnicamente possibile usare la v1 e la v2 nello stesso codice perché usano spazi dei nomi di Azure diversi. Esistono tuttavia molte classi con lo stesso nome in questi spazi dei nomi(ad esempio Area di lavoro, Modello) che possono causare confusione e rendere difficile la leggibilità e il debug del codice.
Importante
Se l'area di lavoro usa un endpoint privato, il flag v1_legacy_mode sarà abilitato automaticamente, impedendo l'uso delle API v2. Per informazioni dettagliate, vedere come configurare l'isolamento rete con v2.