Lo scopo di questo modello di maturità è quello di chiarire i principi e le procedure di Machine Learning Operations (MLOps). Il modello di maturità mostra il miglioramento continuo della creazione e del funzionamento di un ambiente applicativo di Machine Learning a livello di produzione. È possibile usarlo come metrica per stabilire i requisiti progressivi necessari per misurare la maturità di un ambiente di produzione di Machine Learning e i relativi processi associati.
Modello di scadenza
Il modello di maturità MLOps consente di chiarire i principi e le procedure di sviluppo (DevOps) necessari per eseguire un ambiente MLOps riuscito. È progettato per identificare le lacune nel tentativo di un'organizzazione esistente di implementare tale ambiente. È anche un modo per mostrare come aumentare le funzionalità MLOps in incrementi anziché sovraccaricare i requisiti di un ambiente completamente maturo. Usarlo come guida per:
Stimare l'ambito del lavoro per i nuovi impegni.
Stabilire criteri realistici per il successo.
Identificare i risultati finali che verranno consegnati alla conclusione dell'impegno.
Come per la maggior parte dei modelli di maturità, il modello di maturità MLOps valuta qualitativamente persone/cultura, processi/strutture e oggetti/tecnologia. Con l'aumentare del livello di maturità, la probabilità aumenta che gli eventi imprevisti o gli errori porteranno a miglioramenti nella qualità dei processi di sviluppo e produzione.
Il modello di maturità MLOps comprende cinque livelli di funzionalità tecniche:
| Livello |
Descrizione |
Caratteristiche salienti |
Tecnologia |
| 0 |
Nessun MLOps |
- Difficile gestire il ciclo di vita completo del modello di Machine Learning
- I team sono diversi e le versioni sono dolorose
- La maggior parte dei sistemi esiste come "caselle nere", poco feedback durante/post-distribuzione
|
- Compilazioni e distribuzioni manuali
- Test manuali del modello e dell'applicazione
- Nessun rilevamento centralizzato delle prestazioni del modello
- Il training del modello è manuale
|
| 1 |
DevOps ma non MLOps |
- Le versioni sono meno dolorose di Nessun MLOps, ma si basano sul team dati per ogni nuovo modello
- Feedback ancora limitato sul funzionamento di un modello nell'ambiente di produzione
- Difficile tracciare/riprodurre i risultati
|
- Compilazioni automatiche
- Test automatizzati per il codice dell'applicazione
|
| 2 |
Training automatizzato |
- L'ambiente di training è completamente gestito e tracciabile
- Facile riproduzione del modello
- Le versioni sono manuali, ma con un basso attrito
|
- Training di modelli automatizzato
- Rilevamento centralizzato delle prestazioni di training del modello
- Gestione dei modelli
|
| 3 |
Distribuzione automatica del modello |
- Le versioni sono a basso attrito e automatiche
- Tracciabilità completa dalla distribuzione ai dati originali
- Intero ambiente gestito: eseguire il training > della produzione di test >
|
- Test A/B integrati delle prestazioni del modello per la distribuzione
- Test automatizzati per tutto il codice
- Rilevamento centralizzato delle prestazioni di training del modello
|
| 4 |
Operazioni automatizzate MLOps completo |
- Sistema completo automatizzato e facilmente monitorato
- I sistemi di produzione forniscono informazioni su come migliorare e, in alcuni casi, migliorare automaticamente con i nuovi modelli
- Approccio a un sistema senza tempi di inattività
|
- Training e test automatizzati dei modelli
- Metriche centralizzate dettagliate dal modello distribuito
|
Le tabelle che seguono identificano le caratteristiche dettagliate per il livello di maturità del processo. Il modello continuerà a evolversi.
Livello 0: Nessun MLOps
| People |
Creazione del modello |
Versione del modello |
Integrazione di applicazioni |
- Data scientist: silo, non in comunicazioni regolari con il team più grande
- Data engineer (se esistente): isolato, non nelle normali comunicazioni con il team più grande
- Ingegneri software: isolato, ricevere il modello in remoto dagli altri membri del team
|
- Dati raccolti manualmente
- È probabile che l'ambiente di calcolo non sia gestito
- Gli esperimenti non vengono monitorati in modo prevedibile
- Il risultato finale potrebbe essere un singolo file di modello passato manualmente con input/output
|
- Processo manuale
- Lo script di assegnazione dei punteggi potrebbe essere creato manualmente dopo gli esperimenti, non controllato dalla versione
- Rilasciato da solo data scientist o data engineer
|
- Fortemente dipendente dalle competenze del data scientist per implementare
- Versioni manuali ogni volta
|
Livello 1: DevOps senza MLOps
| People |
Creazione del modello |
Versione del modello |
Integrazione di applicazioni |
- Data scientist: silo, non in comunicazioni regolari con il team più grande
- Data engineer (se esistente): isolato, non nelle normali comunicazioni con il team più grande
- Ingegneri software: isolato, ricevere il modello in remoto dagli altri membri del team
|
- La pipeline di dati raccoglie automaticamente i dati
- L'ambiente di calcolo è o non è gestito
- Gli esperimenti non vengono monitorati in modo prevedibile
- Il risultato finale potrebbe essere un singolo file di modello passato manualmente con input/output
|
- Processo manuale
- Lo script di assegnazione dei punteggi potrebbe essere creato manualmente dopo gli esperimenti, probabilmente controllato dalla versione
- Viene consegnato ai software engineer
|
- Esistono test di integrazione di base per il modello
- Fortemente dipendente dalle competenze del data scientist per implementare il modello
- Versioni automatizzate
- Il codice dell'applicazione contiene unit test
|
Livello 2: Training automatizzato
| People |
Creazione del modello |
Versione del modello |
Integrazione di applicazioni |
- Data scientist: lavorare direttamente con i data engineer per convertire il codice di sperimentazione in script/processi ripetibili
- Data engineers: Working with data scientist (Lavorare con data scientist)
- Ingegneri software: isolato, ricevere il modello in remoto dagli altri membri del team
|
- La pipeline di dati raccoglie automaticamente i dati
- Ambiente di calcolo gestito
- Risultati dell'esperimento rilevati
- Sia il codice di training che i modelli risultanti sono controllati dalla versione
|
- Rilascio manuale
- Lo script di assegnazione dei punteggi è controllato dalla versione con i test
- Rilascio gestito dal team di progettazione software
|
- Esistono test di integrazione di base per il modello
- Fortemente dipendente dalle competenze del data scientist per implementare il modello
- Il codice dell'applicazione contiene unit test
|
Livello 3: Distribuzione automatica del modello
| People |
Creazione del modello |
Versione del modello |
Integrazione di applicazioni |
- Data scientist: lavorare direttamente con i data engineer per convertire il codice di sperimentazione in script/processi ripetibili
- Data engineers: Working with data scientist and software engineers to manage inputs/outputs (Ingegneri dei dati e ingegneri del software per gestire input/output)
- Ingegneri software: uso dei data engineer per automatizzare l'integrazione dei modelli nel codice dell'applicazione
|
- La pipeline di dati raccoglie automaticamente i dati
- Ambiente di calcolo gestito
- Risultati dell'esperimento rilevati
- Sia il codice di training che i modelli risultanti sono controllati dalla versione
|
- Rilascio automatico
- Lo script di assegnazione dei punteggi è controllato dalla versione con i test
- Rilascio gestito dalla pipeline di recapito continuo (CI/CD)
|
- Unit test e integration per ogni versione del modello
- Meno dipendente dalle competenze del data scientist per implementare il modello
- Il codice dell'applicazione contiene unit test/test di integrazione
|
Livello 4: Ripetizione automatizzata completa di MLOps
| People |
Creazione del modello |
Versione del modello |
Integrazione di applicazioni |
- Data scientist: lavorare direttamente con i data engineer per convertire il codice di sperimentazione in script/processi ripetibili. Lavorare con i software engineer per identificare i marcatori per i data engineer
- Data engineers: Working with data scientist and software engineers to manage inputs/outputs (Ingegneri dei dati e ingegneri del software per gestire input/output)
- Ingegneri software: uso dei data engineer per automatizzare l'integrazione dei modelli nel codice dell'applicazione. Implementazione della raccolta delle metriche post-distribuzione
|
- La pipeline di dati raccoglie automaticamente i dati
- Ripetizione del training attivata automaticamente in base alle metriche di produzione
- Ambiente di calcolo gestito
- Risultati dell'esperimento rilevati
- Sia il codice di training che i modelli risultanti sono controllati dalla versione
|
- Rilascio automatico
- Lo script di assegnazione dei punteggi è controllato dalla versione con i test
- Rilascio gestito dall'integrazione continua e dalla pipeline CI/CD
|
- Unit test e test di integrazione per ogni versione del modello
- Meno dipendente dalle competenze del data scientist per implementare il modello
- Il codice dell'applicazione contiene unit test/test di integrazione
|
Passaggi successivi