Cos’è il MLOps
L’azienda in cui lavora Tom vuole arricchirsi, quindi il suo capo gli chiede di utilizzare le conoscenze appena acquisite (3 giorni di workshop) sul Machine Learning (ML) per prevedere il prezzo delle azioni di Apple nei prossimi 2 anni (non è possibile, non provateci!). Chiamatemi se ci riuscite…
Inizia il suo ambizioso progetto e fa quanto segue:
- Costruisce un Web scraper per ottenere tutti i dati di cui ha bisogno e li salva localmente sul suo computer.
- Ha sentito parlare bene di XGBoost e ha deciso di utilizzarlo.
- Inizia alcuni esperimenti per trovare i parametri migliori per il suo modello.
- Tom e il suo capo sono soddisfatti dei risultati e decidono di mettere in produzione il trading bot (con un budget di 200.000 euro).
Dopo qualche settimana, il New York Times pubblica un rapporto che dimostra che Apple ha spiato tutti i suoi utenti e il prezzo delle azioni di Apple crolla. Il trading bot perde tutti i suoi soldi e il capo di Tom è indignato. “Come hai fatto a non prevederlo?”, chiede a Tom. Poiché Tom non è in grado di rispondere a questa domanda, viene sostituito da David. David è un ingegnere ML esperto ed è scioccato dallo stato del progetto.
Tom non ha usato git per la versione del suo codice. Tutti i dati sono sul suo disco rigido locale e non ha mai sentito parlare di CI/CD prima d’ora, quindi David deve partire da zero. Come possiamo fare in modo che questa volta l’esperienza sia migliore per tutti?
Perché MLOps?
L’obiettivo principale di MLOps è rendere la vita di tutti gli ingegneri ML in un progetto il più piacevole possibile. La comunicazione deve essere chiara (chi ha fatto cosa e quando?) e provare nuove cose e rilasciarle deve essere il più semplice possibile. Nella prossima parte parleremo dei passi da compiere per garantire tutto ciò.
Perché MLOps?
L’obiettivo principale di MLOps è rendere la vita di tutti gli ingegneri ML in un progetto il più piacevole possibile. La comunicazione deve essere chiara (chi ha fatto cosa e quando?) e provare nuove cose e rilasciarle deve essere il più semplice possibile. Nella prossima parte parleremo dei passi da compiere per garantire tutto ciò.
Tenere traccia di tutto
La differenza principale tra il software tradizionale e il ML è che non avete solo il codice. Ci sono anche i dati, i modelli e gli esperimenti.
La scrittura di un software tradizionale è relativamente semplice, ma nel ML è necessario provare molte cose diverse per trovare il modello migliore e più veloce per il caso d’uso. Si possono scegliere molti tipi di modelli diversi e ognuno di essi ha i suoi iperparametri specifici. Anche se si lavora da soli, questa situazione può sfuggire di mano molto rapidamente.
Esperimenti
Git + DVC = ❤️
Ogni sviluppatore conosce Git. Probabilmente, però, non avete sentito parlare di DVC (Data Version Control). Si basa su git ed è la combinazione perfetta per il controllo delle versioni del codice e dei dati. È possibile salvare i dati ovunque nel cloud. Sono supportati Amazon S3, Microsoft Azure Blob Storage, Google Drive e altri ancora. Consiglio vivamente la pagina “Get Started” se volete immergervi direttamente nel codice.
Git + DVC è tutto ciò di cui avete bisogno per il versionamento del codice e dei dati!
Pipeline di creazione e distribuzione
Dopo aver scritto il codice e ottenuto i dati e averli versionati bene, possiamo iniziare con il divertente lavoro di ML. Ora dobbiamo scegliere un algoritmo di ML e iniziare l’addestramento. Per evitare di eseguire due volte lo stesso esperimento e rendere l’esperimento trasparente per tutti i membri del team, abbiamo bisogno di un buon metodo per documentare i nostri esperimenti. È qui che entra in gioco mlflow Tracking.
Potete usare mlflow anche per altre grandi cose, ma qui voglio concentrarmi sulla sua funzione di tracciamento degli esperimenti. Fondamentalmente, si tratta di un’applicazione web con un’API che potete distribuire ovunque per farne il vostro spazio centrale per la registrazione e la visualizzazione dei vostri esperimenti. Anche l’interfaccia utente è molto intuitiva.
Dopo aver eseguito gli esperimenti e addestrato il modello, abbiamo un modello ML pronto per la produzione. Questo è fantastico, ma non è la fine della storia. Nella prossima parte, vorrei parlare del processo di creazione e distribuzione automatica delle applicazioni di ML.
Pipeline di creazione e distribuzione
Questo processo è chiamato anche CI/CD ed è l’acronimo di Continous Integration / Continous Delivery.
L’obiettivo di CI/CD è costruire, testare e distribuire automaticamente e in modo sicuro la vostra applicazione, in modo da poter iterare rapidamente quando sviluppate un nuovo software.
Qui voglio concentrarmi sul CI/CD nel contesto del ML. Se volete leggere qualcosa su questo argomento in senso più generale, vi consiglio vivamente questo articolo.
ML è un microservizio e Docker è fantastico
Un microservizio è un componente software che ha le seguenti proprietà:
– Fa esattamente una cosa e la fa bene.
– È stateless.
– Ha un’API REST per la comunicazione.
Se volete creare facilmente un microservizio, dovete usare Docker. Consente di containerizzare l’applicazione. Ciò significa che si può essere sicuri che venga eseguita esattamente allo stesso modo in ogni ambiente (ci sono alcune eccezioni). È come una piccola macchina virtuale per la vostra applicazione.
Il modello addestrato sarà il cuore del contenitore. Si otterrà l’input del modello tramite un’API REST e l’output sarà la previsione del modello.
Quando si è soddisfatti del proprio microservizio, è possibile costruirlo e inviarlo a un registro di immagini Docker. In pratica è come GitHub per i microservizi.
Integrazione continua
Quando si costruisce il microservizio, si crea un’immagine Docker. Si tratta di un modello che indica a Docker esattamente come costruire il microservizio a partire dal codice. Qui è possibile eseguire la parte CI (integrazione continua) del paradigma CI/CD.
Qui si può testare la qualità del codice, eseguire test unitari e misurare il tempo di previsione dei modelli. Solo dopo che questi test sono stati superati con successo, si costruisce e si invia l’immagine Docker. In questo modo ci si assicura che il microservizio funzioni correttamente.
Un grosso problema che dovrete affrontare è che la maggior parte dei modelli di ML (soprattutto di Deep Learning) funzionano solo su GPU. Ciò significa che dovrete eseguire la vostra pipeline CI su una macchina virtuale con GPU nel cloud. Questo potrebbe diventare costoso, ma non c’è modo di evitarlo. L’unica soluzione è assicurarsi che il modello venga eseguito anche sulla CPU (in molti casi è possibile). È necessario valutare questo aspetto per il proprio caso d’uso.
Distribuzione continua
Dopo aver creato le modifiche e aver costruito e caricato con successo l’immagine Docker, è il momento di eseguire il nuovo fantastico microservizio ML. Non importa dove viene eseguita l’applicazione. Potrebbe essere nel cloud, su una macchina locale o sul bordo, il processo di distribuzione è sempre lo stesso.
Esecuzione di più microservizi
Spesso in produzione si hanno più microservizi (container) in esecuzione insieme, che devono anche parlare tra loro. In questo caso è necessario un orchestratore di container. Kubernetes è un ottimo strumento per farlo. In pochi minuti è possibile creare un cluster Kubernetes in esecuzione su Google Cloud Platform o Azure.
Monitoraggio
Per tenere sotto controllo l’applicazione è necessario un buon sistema di monitoraggio. In produzione, si vuole essere sicuri che il modello preveda cose sensate. Il sistema di registrazione deve includere informazioni sull’input del modello e sull’output previsto. Esistono soluzioni comuni che si possono usare per il monitoraggio. Uno strumento che mi è piaciuto particolarmente è lo stack ELK di Elastic. Ha alcuni strumenti di visualizzazione molto belli e si scala bene. (Probabilmente è eccessivo quando si ha un piccolo sistema di microservizi).
Riqualificare il nostro modello
Questo è l’ultimo e il più interessante passo quando si fa ML. Con il tempo, il set di dati disponibili su cui possiamo allenarci cresce. Il modello che abbiamo creato in questo processo può essere migliorato attraverso un nuovo addestramento su questi nuovi dati disponibili. Questo è anche il motivo per cui è così importante fare una versione dei nostri dati. Senza DVC perderemmo molto rapidamente la visione complessiva del nostro set di dati.
Conclusioni
L’MLOps è un campo molto giovane e le migliori pratiche non sono ancora disponibili. Gli approcci e gli strumenti di cui ho parlato qui sono solo un modo di fare le cose. Penso che sia un campo molto interessante e spero di avervi mostrato chiaramente il mio approccio. Se avete idee su come migliorare questo approccio, mi farebbe molto piacere se le lasciaste nei commenti qui sotto. Abbiamo bisogno e troveremo queste cose solo insieme come comunità.
Articolo originale di Sharif Elfouly
Share:
