Esplorare l'architettura della soluzione
Si esamini ora l'architettura delle operazioni di Machine Learning (MLOps) per comprendere lo scopo di ciò che si sta tentando di ottenere.
Si supponga che, insieme al team di data science e sviluppo software, sia stata concordata l'architettura seguente per eseguire il training, testare e distribuire il modello di classificazione del diabete:
Nota
Il diagramma è una rappresentazione semplificata di un'architettura MLOps. Per visualizzare un'architettura più dettagliata, esaminare i vari casi d'uso nell'acceleratore di soluzioni MLOps (v2).
L'architettura include:
- Installazione: creare tutte le risorse di Azure necessarie per la soluzione.
- Sviluppo di modelli (ciclo interno): esplorare ed elaborare i dati per eseguire il training e valutare il modello.
- Integrazione continua: creare un pacchetto e registrare il modello.
- Distribuzione del modello (ciclo esterno): distribuire il modello.
- Distribuzione continua: testare il modello e promuovere l'ambiente di produzione.
- Monitoraggio: monitorare le prestazioni del modello e dell'endpoint.
Il team di data science è responsabile dello sviluppo del modello. Il team di sviluppo software è responsabile dell'integrazione del modello distribuito con l'app Web usata dai professionisti per valutare se un paziente ha il diabete. Si è responsabili dell'acquisizione del modello dallo sviluppo di modelli alla distribuzione del modello.
Si prevede che il team di data science proponi costantemente modifiche agli script usati per eseguire il training del modello. Ogni volta che viene apportata una modifica allo script di training, è necessario ripetere il training del modello e ridistribuire il modello all'endpoint esistente.
Si vuole consentire al team di data science di sperimentare, senza toccare il codice pronto per la produzione. Si vuole anche assicurarsi che qualsiasi codice nuovo o aggiornato venga eseguito automaticamente in base ai controlli di qualità concordati. Dopo aver verificato il codice per eseguire il training del modello, si userà lo script di training aggiornato per eseguire il training di un nuovo modello e distribuirlo.
Per tenere traccia delle modifiche e verificare il codice prima di aggiornare il codice di produzione, è necessario lavorare con i rami. Si è concordato con il team di data science che ogni volta che vogliono apportare una modifica, creeranno un ramo di funzionalità per creare una copia del codice e apportare le modifiche alla copia.
Qualsiasi data scientist può creare un ramo di funzionalità e lavorare in questa posizione. Dopo aver aggiornato il codice e aver desiderato che il codice sia il nuovo codice di produzione, sarà necessario creare una richiesta pull. Nella richiesta pull, sarà visibile per gli altri cosa sono le modifiche proposte, offrendo ad altri l'opportunità di esaminare e discutere le modifiche.
Ogni volta che viene creata una richiesta pull, si vuole verificare automaticamente se il codice funziona e che la qualità del codice è fino agli standard dell'organizzazione. Dopo che il codice ha superato i controlli di qualità, il responsabile del data scientist deve esaminare le modifiche e approvare gli aggiornamenti prima che la richiesta pull possa essere unita e il codice nel ramo principale può essere aggiornato di conseguenza.
Importante
Nessuno dovrebbe mai essere autorizzato a eseguire il push delle modifiche nel ramo principale. Per proteggere il codice, in particolare il codice di produzione, è necessario imporre che il ramo principale possa essere aggiornato solo tramite richieste pull che devono essere approvate.