Aggiornare i flussi di lavoro ml ai modelli di destinazione nel catalogo unity

Questo articolo illustra come eseguire la migrazione e aggiornare i flussi di lavoro ml ai modelli di destinazione nel catalogo unity.

Requisiti

Prima di iniziare, assicurarsi di soddisfare i requisiti in Requisiti. In particolare, assicurarsi che gli utenti o le entità usate per eseguire il training, la distribuzione e i flussi di lavoro di inferenza del modello abbiano i privilegi necessari per un modello registrato nel catalogo unity:

• Training: proprietà del modello registrato (necessaria per creare nuove versioni del modello), oltre USE CATALOG USE SCHEMA ai privilegi per il catalogo e lo schema di inclusione.
• Distribuzione: proprietà del modello registrato (necessario per impostare gli alias nel modello), oltre USE CATALOG USE SCHEMA ai privilegi per il catalogo e lo schema che lo racchiude.
• Inferenza: EXECUTE privilegio per il modello registrato (necessario per leggere ed eseguire l'inferenza con le versioni del modello), oltre USE CATALOG ai privilegi USE SCHEMA nel catalogo e nello schema contenitore.

Creazione di training, distribuzione e flussi di lavoro paralleli

Per aggiornare i flussi di lavoro di training e inferenza del modello a Unity Catalog, Databricks consiglia un approccio incrementale in cui si crea una pipeline di training, distribuzione e inferenza parallela che sfrutta i modelli in Unity Catalog. Quando si ha familiarità con i risultati usando Il catalogo unity, è possibile cambiare consumer downstream per leggere l'output dell'inferenza batch o aumentare il traffico indirizzato ai modelli nel catalogo unity per la gestione degli endpoint.

Flusso di lavoro di training del modello

Clonare il flusso di lavoro di training del modello. Assicurarsi quindi che:

1. Il cluster del flusso di lavoro ha accesso a Unity Catalog e soddisfa i requisiti descritti in Requisiti.
2. L'entità che esegue il flusso di lavoro dispone delle autorizzazioni necessarie per un modello registrato in Unity Catalog.

Modificare quindi il codice di training del modello nel flusso di lavoro clonato. Potrebbe essere necessario clonare il notebook eseguito dal flusso di lavoro oppure creare e specificare come destinazione un nuovo ramo Git nel flusso di lavoro clonato. Seguire questa procedura per installare la versione necessaria di MLflow, configurare il client in modo che sia destinato a Unity Catalog nel codice di training e aggiornare il codice di training del modello per registrare i modelli in Unity Catalog.

Flusso di lavoro di distribuzione del modello

Clonare il flusso di lavoro di distribuzione del modello seguendo i passaggi simili del flusso di lavoro di training del modello per aggiornare la configurazione di calcolo per abilitare l'accesso a Unity Catalog.

Verificare che l'entità proprietaria del flusso di lavoro clonato disponga delle autorizzazioni necessarie. Se nel flusso di lavoro di distribuzione è presente una logica di convalida del modello, aggiornarla per caricare le versioni del modello dal punto di controllo dell'utilità. Usare gli alias per gestire le implementazioni del modello di produzione.

Flusso di lavoro di inferenza del modello

Flusso di lavoro di inferenza batch

Seguire passaggi simili come nel flusso di lavoro di training del modello per clonare il flusso di lavoro di inferenza batch e aggiornare la configurazione di calcolo per abilitare l'accesso a Unity Catalog. Verificare che l'entità che esegue il processo di inferenza batch clonata disponga delle autorizzazioni necessarie per caricare il modello per l'inferenza.

Flusso di lavoro di gestione del modello

Se si usa Mosaic AI Model Serving, non è necessario clonare l'endpoint esistente. È invece possibile sfruttare la funzionalità di suddivisione del traffico per instradare una piccola frazione di traffico ai modelli in Unity Catalog.

Verificare innanzitutto che l'entità proprietaria dell'endpoint di gestione del modello disponga delle autorizzazioni necessarie per caricare il modello per l'inferenza. Aggiornare quindi il flusso di lavoro di distribuzione del modello clonato per assegnare una piccola percentuale di traffico alle versioni del modello nel catalogo unity.

Alzare di livello un modello in ambienti diversi

Databricks consiglia di distribuire pipeline di Machine Learning come codice. In questo modo si elimina la necessità di promuovere i modelli in ambienti, poiché tutti i modelli di produzione possono essere prodotti tramite flussi di lavoro di training automatizzati in un ambiente di produzione.

In alcuni casi, tuttavia, potrebbe essere troppo costoso ripetere il training dei modelli in ambienti diversi. È invece possibile copiare le versioni del modello tra i modelli registrati nel catalogo unity per promuoverle in ambienti diversi.

Per eseguire il codice di esempio seguente sono necessari i privilegi seguenti:

• USE CATALOG nei staging cataloghi e prod .
• USE SCHEMA negli staging.ml_team schemi e prod.ml_team .
• EXECUTE su staging.ml_team.fraud_detection.

Inoltre, è necessario essere il proprietario del modello prod.ml_team.fraud_detectionregistrato.

Il frammento di codice seguente usa l'API copy_model_version client MLflow, disponibile in MLflow versione 2.8.0 e successive.

import mlflow
mlflow.set_registry_uri("databricks-uc")

client = mlflow.tracking.MlflowClient()
src_model_name = "staging.ml_team.fraud_detection"
src_model_version = "1"
src_model_uri = f"models:/{src_model_name}/{src_model_version}"
dst_model_name = "prod.ml_team.fraud_detection"
copied_model_version = client.copy_model_version(src_model_uri, dst_model_name)

Dopo che la versione del modello si trova nell'ambiente di produzione, è possibile eseguire qualsiasi convalida di pre-distribuzione necessaria. È quindi possibile contrassegnare la versione del modello per la distribuzione usando alias.

client = mlflow.tracking.MlflowClient()
client.set_registered_model_alias(name="prod.ml_team.fraud_detection", alias="Champion", version=copied_model_version.version)

Nell'esempio precedente solo gli utenti che possono leggere dal staging.ml_team.fraud_detection modello registrato e scrivere nel prod.ml_team.fraud_detection modello registrato possono promuovere i modelli di staging nell'ambiente di produzione. Gli stessi utenti possono anche usare alias per gestire le versioni del modello distribuite all'interno dell'ambiente di produzione. Non è necessario configurare altre regole o criteri per gestire la promozione e la distribuzione dei modelli.

È possibile personalizzare questo flusso per alzare di livello la versione del modello in più ambienti che corrispondono alla configurazione, ad esempio dev, qae prod. Il controllo di accesso viene applicato come configurato in ogni ambiente.

Usare webhook di processo per l'approvazione manuale per la distribuzione del modello

Databricks consiglia di automatizzare la distribuzione del modello, se possibile, usando controlli e test appropriati durante il processo di distribuzione del modello. Tuttavia, se è necessario eseguire approvazioni manuali per distribuire i modelli di produzione, è possibile usare webhook di processo per chiamare sistemi CI/CD esterni per richiedere l'approvazione manuale per la distribuzione di un modello, al termine del processo di training del modello. Dopo aver fornito l'approvazione manuale, il sistema CI/CD può quindi distribuire la versione del modello per gestire il traffico, ad esempio impostando l'alias "Campione" su di esso.