Preparare un modello per la distribuzione
Per ottenere valore da un modello di Machine Learning, distribuirlo in modo che possa generare stime ogni volta che l'azienda ne ha bisogno. Prima di effettuare la distribuzione, tuttavia, prendi alcune decisioni che influenzano il modo in cui funziona il resto della pipeline.
In Proseware, una società di tecnologie sanitarie, il team di data science esegue il training di un modello di classificazione che stima se un paziente potrebbe perdere un prossimo appuntamento di clinica. Il personale della clinica usa questo punteggio di rischio no-show per decidere quali pazienti chiamare in anticipo per confermare, in modo che la clinica possa riempire slot che altrimenti andrebbero vuoti. Il modello è abbastanza accurato per l'uso in produzione. La sfida consiste nel far funzionare le stime in modo affidabile, in un processo che il team può ripetere ogni volta che il modello viene sottoposto nuovamente a training.
Scegliere un tipo di endpoint
Azure Machine Learning supporta due tipi di endpoint e la scelta dipende dalla modalità di utilizzo della stima. Un batch endpoint genera previsioni per un ampio insieme di record secondo una pianificazione, il che lo rende adatto ai processi periodici di scoring. Un endpoint online restituisce una stima in modo sincrono, con bassa latenza, al momento in cui riceve una richiesta.
Il sistema di pianificazione di Proseware chiama il modello non appena il personale prenota o riprogramma un appuntamento, in modo da poter contrassegnare immediatamente gli appuntamenti ad alto rischio per una chiamata di conferma quel giorno. Poiché la previsione deve essere restituita immediatamente, il team distribuisce il modello in un endpoint online gestito.
Registrare il modello con MLflow
Il team di data science esegue il training del modello di rischio no-show e lo inserisce in pacchetti con MLflow, una piattaforma open source per tenere traccia degli esperimenti di Machine Learning e dei modelli di creazione di pacchetti in un formato standard. Quando lo script di training chiama mlflow.autolog(), MLflow registra automaticamente il modello, i relativi parametri e le relative metriche come parte dell'output del processo di training.
Poiché il modello è in pacchetto come modello MLflow, è possibile registrarlo direttamente dall'output del processo senza scrivere uno script di assegnazione dei punteggi personalizzato o definire manualmente un ambiente. Azure Machine Learning genera entrambi dai metadati MLflow del modello durante la distribuzione, una funzionalità nota come distribuzione senza codice. Un team che lavora con un formato di modello personalizzato, ad esempio un file pickle, deve creare e gestire lo script di assegnazione dei punteggi e l'ambiente.
Tip
Altre informazioni sulla distribuzione di modelli MLflow in Azure Machine Learning.
Per registrare il modello, è possibile specificare l'output di un processo di addestramento completato oppure un file del modello archiviato in un datastore dell'area di lavoro. Dopo la registrazione, il modello diventa un asset con versione nell'area di lavoro, a cui tu o un flusso di lavoro automatizzato potete fare riferimento per nome e versione quando create una distribuzione.
Man mano che il modello si evolve, registrare gli artefatti modificati come nuove versioni anziché sostituire una versione esistente. È possibile aggiornare la descrizione e i tag di una versione, ma altre modifiche richiedono una nuova versione. Archiviare le versioni che non si desiderano più negli elenchi predefiniti. L'archiviazione non elimina un modello e i flussi di lavoro possono comunque fare riferimento a una versione archiviata quando necessario.
Tip
Altre informazioni sulla gestione dei modelli registrati.
Pianificazione delle distribuzioni ripetibili
La registrazione e la distribuzione di un modello funzionano manualmente per una prima versione, ma Proseware prevede di ripetere il training del modello no-show regolarmente man mano che arrivano nuovi dati di appuntamento. La ripetizione degli stessi passaggi manuali per ogni nuova versione è lenta e soggetta a errori, quindi l'obiettivo del team è automatizzare la registrazione, la distribuzione e il test tramite una pipeline, ovvero il resto di questo modulo.