Registri di Machine Learning per MLOps
Questo articolo illustra come dimensionare MLOps in ambienti di sviluppo, test e produzione. Gli ambienti possono variare da pochi a molti in base alla complessità dell'ambiente IT e ciò dipende da fattori come:
- Criteri di sicurezza e conformità: gli ambienti di produzione devono essere isolati dagli ambienti di sviluppo in termini di controlli di accesso, architettura di rete, esposizione dei dati e così via?
- Sottoscrizioni: Gli ambienti di sviluppo si trovano in una sottoscrizione e quelli di produzione in una sottoscrizione diversa? Spesso le sottoscrizioni separate vengono usate per tenere conto di fatturazione, budget e gestione dei costi.
- Aree: è necessario eseguire la distribuzione in aree di Azure diverse per supportare i requisiti di latenza e ridondanza?
In questi scenari, è possibile usare aree di lavoro di Azure Machine Learning diverse per lo sviluppo, il test e la produzione. Questa configurazione presenta le sfide seguenti per il training e la distribuzione del modello:
- È necessario eseguire il training di un modello in un'area di lavoro di sviluppo, ma distribuirlo in un endpoint in un'area di lavoro di produzione, possibilmente in una sottoscrizione o un'area di Azure diversa. In questo caso, è necessario essere in grado di tenere traccia del processo di training. Ad esempio, per analizzare le metriche, i log, il codice, l'ambiente e i dati usati per eseguire il training del modello se si verificano problemi di accuratezza o prestazioni con la distribuzione di produzione.
- È necessario sviluppare una pipeline di training con dati di test o dati anonimi nell'area di lavoro di sviluppo, ma ripetere il training del modello con i dati di produzione nell'area di lavoro di produzione. In questo caso, potrebbe essere necessario confrontare le metriche di training sui dati di esempio e di produzione per garantire che le ottimizzazioni del training siano soddisfacenti con i dati effettivi.
MLOps tra aree di lavoro con registri
I registri, in modo analogo a un repository Git, separano gli asset di ML dalle aree di lavoro e li ospitano in una posizione centrale, rendendoli disponibili per tutte le aree di lavoro dell'organizzazione.
Per alzare di livello i modelli tra gli ambienti (sviluppo, test, produzione), iniziare con lo sviluppo iterativo di un modello nell'ambiente di sviluppo. Quando si dispone di un modello candidato valido, è possibile pubblicarlo in un registro. È quindi possibile distribuire il modello dal registro di sistema agli endpoint in aree di lavoro diverse.
Suggerimento
Se sono già stati registrati modelli in un'area di lavoro, è possibile alzarli di livello a un registro. È anche possibile registrare un modello direttamente in un registro dall'output di un processo di training.
Se si vuole sviluppare una pipeline in un'area di lavoro e quindi eseguirla in altre, iniziare registrando i componenti e gli ambienti che formano i blocchi predefiniti della pipeline. Quando si invia il processo della pipeline, l'area di lavoro in cui viene eseguito viene selezionata dai dati di calcolo e training, univoci per ogni area di lavoro.
Il diagramma seguente illustra l'innalzamento di livello delle pipeline tra aree di lavoro esplorative e di sviluppo, quindi l'innalzamento di livello del modello tra ambienti di sviluppo, test e produzione.
