Le operazioni di machine learning (MLOps) sono ormai un tema centrale per molti leader e professionisti dei dati, con un interesse cresciuto in modo significativo negli ultimi due anni. Questa ascesa vertiginosa è spinta da una sfida importante che molte organizzazioni stanno affrontando: gli investimenti in machine learning e AI non stanno offrendo il promesso ritorno sull'investimento.
Nel 2019, Venturebeat ha riportato che solo il 13% dei modelli di machine learning arriva in produzione. Sebbene un recente sondaggio di KDNuggets suggerisca un miglioramento nel 2022, il 35% dei rispondenti cita ancora ostacoli tecnici che impediscono il deployment dei propri modelli.
Il report State of AI 2021 di McKinsey mostra che l'adozione dell'AI è salita al 56%, rispetto al 50% del 2020. Man mano che le organizzazioni intensificano gli investimenti in sistemi di machine learning e talenti, la necessità di distribuire i modelli in modo efficiente ed estrarne valore diventa più evidente che mai. È qui che entrano in gioco gli MLOps. Le organizzazioni che adottano con successo gli MLOps stanno ottenendo migliori ritorni sui loro investimenti. Adottando gli MLOps, i team dati stanno riducendo il tempo necessario per prototipare, sviluppare e distribuire sistemi di machine learning.
L'obiettivo degli MLOps è combinare tecnologia e cambiamento organizzativo per applicare i concetti dell'ingegneria del software al machine learning. Considerando il machine learning come una disciplina ingegneristica, si promette un percorso lineare verso la produzione e una maggiore longevità dei modelli in produzione.
In questo articolo definiremo cosa sono gli MLOps, perché sono importanti e presenteremo cinque principi guida che oggi definiscono una pratica MLOps di successo.
Che cos'è MLOps?
Gli MLOps sono meglio definiti come "un insieme di strumenti, pratiche, tecniche e cultura che garantiscono il deployment affidabile e scalabile dei sistemi di machine learning". Gli MLOps attingono alle best practice dell'ingegneria del software come automazione e test automatizzati, controllo di versione, implementazione di principi agili e gestione dei dati per ridurre il debito tecnico.
Il debito tecnico, o debito di codice, è un concetto proprio dell'ingegneria del software. Descrive il "debito" accumulato a seguito di uno sviluppo rapido in cui processi come automazione, documentazione e unit test vengono rifattorizzati in una fase successiva. In poche parole, è il debito che i team di sviluppo si portano nel futuro quando non adottano le best practice nel presente.
I sistemi di machine learning possono accumulare alti livelli di debito tecnico, poiché i modelli prodotti dai data scientist sono una piccola parte di un puzzle più grande, composto da infrastruttura, monitoraggio dei modelli, archiviazione delle feature e molte altre considerazioni.
Cosa rende unici gli MLOps
Le best practice dell'ingegneria del software mirate a ridurre il debito tecnico sono spesso indicate come DevOps. I DevOps combinano le attività di sviluppo di scrittura del codice, versionamento e test con le operazioni IT di rilascio, deployment e monitoraggio.
I due principi cardine dei DevOps sono Continuous Integration e Continuous Delivery (CI/CD).
- Continuous Integration (CI): le nuove modifiche al codice vengono regolarmente compilate, testate e unite in un repository condiviso.
- Continuous Delivery (CD): qualsiasi modifica apportata a un'applicazione viene testata automaticamente e caricata in un repository, da cui può essere distribuita in un ambiente live.
Portare in produzione e scalare sistemi di machine learning introduce ulteriori complessità. L'ingegneria del software progetta soluzioni ben definite con input e output precisi. I sistemi di machine learning, invece, si basano su dati del mondo reale modellati tramite metodi statistici. Questo introduce ulteriori considerazioni da tenere in conto, come:
- Dati: il machine learning usa dati di input altamente complessi. Questi dati devono essere trasformati affinché i modelli di machine learning possano produrre previsioni significative.
- Modeling: sviluppare sistemi di machine learning richiede sperimentazione. Per sperimentare in modo efficiente, è essenziale tracciare le modifiche ai dati e i parametri di ogni esperimento.
- Testing: andando oltre i test unitari, in cui piccole parti testabili di un'applicazione sono testate in modo indipendente, i sistemi di machine learning richiedono test più complessi sia sui dati sia sulle prestazioni del modello. Ad esempio, verificare se i nuovi dati di input condividono proprietà statistiche simili ai dati di training.
- Model Drift: le prestazioni di un modello di machine learning tenderanno sempre a degradare nel tempo. La causa principale è duplice. Il Concept Drift si verifica quando cambiano le proprietà dell'outcome che stiamo cercando di prevedere. Un ottimo esempio è stato durante i lockdown per il COVID-19, quando molti retailer hanno registrato un picco inatteso in prodotti come la carta igienica. Come gestirebbe questo scenario un modello addestrato su dati "normali"? Il Data Drift invece si verifica quando le proprietà delle variabili indipendenti cambiano per vari fattori, tra cui stagionalità, cambiamenti nel comportamento dei consumatori o il lancio di nuovi prodotti.
- Continuous Training: i modelli di machine learning devono essere riaddestrati quando diventano disponibili nuovi dati per contrastare il model drift.
- Gestione delle pipeline: i dati devono passare attraverso vari passaggi di trasformazione prima di essere forniti a un modello e andrebbero testati regolarmente prima e dopo l'addestramento. Le pipeline combinano questi passaggi per essere monitorati e mantenuti in modo efficiente.
5 principi per MLOps di successo
Adottare gli MLOps non è semplice come ingaggiare un nuovo fornitore SaaS o attivare nuove istanze di cloud computing. Richiede una pianificazione attenta e un approccio coerente tra team e reparti. Ecco cinque principi per una implementazione MLOps di successo:
Comprendi la tua maturità MLOps
I principali provider cloud come Microsoft e Google valutano l'adozione degli MLOps attraverso un modello di maturità. Questo perché gli MLOps richiedono cambiamento organizzativo e metodi di lavoro moderni. Ciò avviene solo nel tempo, man mano che sistemi e processi dell'organizzazione maturano.
Un'adozione di successo degli MLOps richiede una valutazione onesta dei progressi dell'organizzazione nella propria maturità MLOps. Dopo una valutazione affidabile del livello di maturità, le organizzazioni possono capire quali tattiche impiegare per salire di livello. Ciò comporta cambiamenti di processo come applicare i DevOps al deployment o aggiungere nuove assunzioni al team.
È anche essenziale capire come i livelli di maturità possano aiutare le organizzazioni a dare priorità alle iniziative MLOps. Ad esempio, una feature store è un repository unico per i dati che ospita le feature di uso comune per il machine learning. Le feature store sono utili per organizzazioni relativamente mature dal punto di vista dei dati, in cui molti team dati eterogenei devono usare feature coerenti e ridurre i lavori duplicati. Se un'organizzazione ha solo pochi data scientist, probabilmente una feature store non vale il tempo.
Utilizzando un modello di maturità per gli MLOps, le organizzazioni consentono a team, processi e stack tecnologico di evolvere insieme. Si garantisce che l'iterazione possa avvenire e che gli strumenti possano essere testati prima dell'implementazione.
Applica l'automazione nei tuoi processi
L'automazione va di pari passo con il concetto di modelli di maturità. Un'automazione avanzata e diffusa facilita l'aumento della maturità MLOps per un'organizzazione. In ambienti senza MLOps, molte attività all'interno dei sistemi di machine learning vengono eseguite manualmente. Queste attività possono includere pulizia e trasformazione dei dati, feature engineering, suddivisione dei dati di training e test, scrittura del codice di training del modello, ecc. Svolgendo questi passaggi manualmente, i data scientist introducono un maggiore margine di errore e perdono tempo che sarebbe meglio dedicare alla sperimentazione.
Un ottimo esempio di automazione è il retraining continuo, in cui i team dati possono impostare pipeline per l'ingestione dei dati, la validazione, la sperimentazione, il feature engineering, il testing del modello e altro ancora. Spesso considerato uno dei primi passi nell'automazione del machine learning, il retraining continuo aiuta a evitare il model drift.
Le pipeline negli MLOps non sono diverse da quelle del data engineering o dei DevOps. Una pipeline di machine learning è una serie di passaggi che orchestrano il flusso di dati dentro e fuori un modello di machine learning.
Per illustrare la potenza delle pipeline, possiamo immaginare un esempio in cui i data scientist hanno estratto manualmente parte dei dati ma sono riusciti ad automatizzare i processi di validazione, preparazione dei dati, training ed evaluation del modello. Questa pipeline può essere poi riutilizzata quando il modello viene messo in produzione per fare previsioni su nuovi dati.
Dai priorità alla sperimentazione e al tracciamento
La sperimentazione è una parte centrale del ciclo di vita del machine learning. I data scientist sperimentano con dataset, feature, modelli di machine learning, relativi iperparametri, ecc. Ci sono molte "leve" da muovere durante la sperimentazione. Per trovare la giusta combinazione, è essenziale tracciare ogni iterazione degli esperimenti.
Nella sperimentazione tradizionale basata su notebook, i data scientist tracciano manualmente parametri e dettagli del modello. Questo può portare a incoerenze di processo e a un maggiore margine di errore umano. L'esecuzione manuale è anche dispendiosa in termini di tempo ed è un grande ostacolo a una rapida sperimentazione.
Sebbene git sia ampiamente usato per tracciare il codice, non è facile eseguire il versionamento dei diversi esperimenti condotti dai data scientist. Qui i team dati possono usare i model registry, un luogo in cui i data scientist possono archiviare i modelli, tracciarne le prestazioni e altre modifiche.
Il tracciamento degli esperimenti consente ai team dati di eseguire un rollback dei modelli se necessario e migliora l'intero processo di auditing dei modelli. Riduce un notevole sforzo manuale per i data scientist, lasciando più tempo alla sperimentazione. Tutto ciò si traduce in una riproducibilità dei risultati significativamente migliorata grazie a versionamento e tracciamento
Vai oltre il CI/CD
Abbiamo visto il CI/CD nel contesto dei DevOps, ma sono anche componenti essenziali per MLOps ad alta maturità.
- Applicando la CI agli MLOps, estendiamo i test e la validazione automatizzati del codice a dati e modelli.
- Analogamente, i concetti di CD si applicano a pipeline e modelli man mano che vengono riaddestrati.
Possiamo anche considerare altri concetti "continuos":
- Continuous Training (CT): abbiamo già accennato a come l'aumento dell'automazione consenta di riaddestrare un modello quando diventano disponibili nuovi dati.
- Continuous Monitoring (CM): un altro motivo per riaddestrare un modello è il calo delle prestazioni. Dovremmo anche capire se i modelli stanno ancora generando valore rispetto alle metriche di business.
L'applicazione dei concetti "continuous" con test automatizzati consente una rapida sperimentazione e garantisce errori minimi su larga scala. Inoltre, la corretta implementazione di tutti e quattro i concetti continuous può ridurre drasticamente il time-to-deployment.
Considera la pipeline di esempio vista nella sezione sull'automazione. Applicare i concetti di CI/CD a questa porterebbe a una base di codice archiviata in un repository. In linea con la CI, a questo repository verrebbe applicata una serie di unit test automatici, ad esempio testare le feature ingegnerizzate, assicurarsi che non ci siano valori mancanti e testare l'overfitting. I singoli componenti della pipeline possono quindi essere convalidati e distribuiti, assicurando che compatibilità e requisiti di calcolo siano testati e soddisfatti. Questo livello di automazione consente nuovi deployment rapidi, permettendo alle organizzazioni di reagire ai driver esterni e ai cambiamenti.
Adotta il cambiamento organizzativo
Il cambiamento organizzativo deve avvenire insieme all'evoluzione della maturità MLOps. Ciò richiede cambiamenti di processo che promuovano la collaborazione tra i team, con il risultato di abbattere i silos. In alcuni casi, ristrutturare i team nel loro complesso è necessario per facilitare una maturità MLOps coerente. Il modello di maturità di Microsoft illustra come il comportamento delle persone debba cambiare con l'aumentare della maturità.
Gli ambienti a bassa maturità tipicamente vedono data scientist, data engineer e software engineer lavorare in silos. Con l'aumentare della maturità, ogni membro deve collaborare. Data scientist ed engineer devono lavorare insieme per convertire il codice di sperimentazione in pipeline ripetibili, mentre software e data engineer devono collaborare per integrare automaticamente i modelli nel codice applicativo.
Una maggiore collaborazione rende l'intero processo di deployment meno dipendente da una singola persona. Garantisce che il lavoro di squadra sia applicato per ridurre costosi sforzi manuali. Queste diverse aree di competenza si uniscono per sviluppare il livello di automazione richiesto dagli MLOps ad alta maturità. Maggiore collaborazione e automazione sono essenziali per ridurre il debito tecnico.
L'ascesa degli MLOps è ancora agli inizi
Gli MLOps sono nati dall'esigenza di distribuire modelli di ML in modo rapido ed efficiente. Con le aziende che ora investono pesantemente nel machine learning, vengono sviluppati sempre più modelli, aumentando la domanda di MLOps. Sebbene gli MLOps siano ancora nelle fasi iniziali, si può affermare con sicurezza che le organizzazioni stanno cercando di convergere attorno a un insieme di principi che possono sbloccare il ROI del machine learning.
Se vuoi approfondire gli MLOps, dai un'occhiata anche alle seguenti risorse:
- Una guida pratica agli MLOps di Noah Gift
- Operationalizing Machine Learning with MLOps con Alessya Visnjic
- From Predictions to Decisions con Dan Becker
- La nostra guida alle certificazioni MLOps
