MLOps, abbreviazione di Machine Learning Operations, è un set di pratiche e strumenti mirati a soddisfare le esigenze specifiche degli ingegneri che creano modelli e li trasferiscono in produzione. Alcune organizzazioni iniziano con alcuni strumenti sviluppati internamente che eseguono il versioning dei set di dati dopo ogni esperimento e controllano i modelli dopo ogni epoca di training. D'altro canto, molte organizzazioni hanno scelto di adottare uno strumento formale che ha il tracciamento degli esperimenti, funzionalità di collaborazione, capacità di model serving e persino funzionalità di pipeline per l'elaborazione dei dati e dei modelli di training.
Per fare la scelta migliore per la tua organizzazione, dovresti comprendere tutte le capacità disponibili dagli strumenti MLOps leader del settore. Se scegli la strada homegrown, dovresti comprendere le capacità a cui stai rinunciando. Un approccio homegrown è perfetto per i piccoli team che devono muoversi rapidamente e potrebbero non avere tempo per valutare un nuovo strumento. Se scegli di implementare uno strumento di terze parti, dovrai scegliere lo strumento che meglio si adatta al flusso di lavoro di progettazione della tua organizzazione. Questo potrebbe essere complicato perché gli strumenti principali oggi variano in modo significativo nel loro approccio e nelle loro capacità. Indipendentemente dalla tua scelta, avrai bisogno di un'infrastruttura dati in grado di gestire grandi volumi di dati e servire set di formazione in modo performante. I modelli di checkpoint e il versioning di grandi set di dati richiedono una capacità scalabile e, se stai utilizzando GPU costose, avrai bisogno di un'infrastruttura performante per ottenere il massimo dal tuo investimento.
In questo post, presenterò un elenco di funzionalità che gli architetti dovrebbero considerare indipendentemente dall'approccio o dagli strumenti che scelgono. Questo elenco di funzionalità deriva dalla mia ricerca e dai miei esperimenti con tre dei principali fornitori MLOps odierni:
Prima di immergerci nelle funzionalità e nei requisiti infrastrutturali, cerchiamo di capire meglio l'importanza di MLOps. Per farlo, è utile confrontare la creazione di modelli con lo sviluppo di applicazioni convenzionali.
Lo sviluppo di applicazioni convenzionali, come l'implementazione di un nuovo microservizio che aggiunge una nuova funzionalità a un'applicazione, inizia con la revisione di una specifica. Nuove strutture dati o modifiche a strutture dati esistenti vengono progettate per prime. La progettazione dei dati non dovrebbe cambiare una volta iniziata la codifica. Il servizio viene quindi implementato e la codifica è l'attività principale in questo processo. Vengono anche codificati test unitari e test end-to-end. Questi test dimostrano che il codice non è difettoso e implementa correttamente la specifica. Possono essere eseguiti automaticamente da una pipeline CI/CD prima di distribuire l'intera applicazione.
Creare un modello e addestrarlo è diverso. Il primo passo è comprendere i dati grezzi e la previsione necessaria. Gli ingegneri ML devono scrivere del codice per implementare le loro reti neurali o impostare un algoritmo, ma la codifica non è l'attività dominante. L'attività principale è la sperimentazione ripetuta. Durante la sperimentazione, la progettazione dei dati, la progettazione del modello e i parametri utilizzati cambieranno tutti. Dopo ogni esperimento, vengono create delle metriche che mostrano come si è comportato il modello durante l'addestramento. Vengono inoltre generate delle metriche per determinare le prestazioni del modello rispetto a un set di convalida e un set di test. Queste metriche vengono utilizzate per dimostrare la qualità del modello. Dovresti salvare il modello dopo ogni esperimento e ogni volta che modifichi i tuoi set di dati, dovresti salvarli. Una volta che un modello è pronto per essere incorporato in un'applicazione, deve essere impacchettato e distribuito.
Per riassumere, MLOps sta al machine learning come DevOps sta allo sviluppo software tradizionale. Entrambi sono un insieme di pratiche e principi volti a migliorare la collaborazione tra i team di ingegneria (Dev o ML) e i team di IT operations (Ops). L'obiettivo è semplificare il ciclo di vita dello sviluppo, dalla pianificazione e sviluppo alla distribuzione e alle operazioni, utilizzando l'automazione. Uno dei principali vantaggi di questi approcci è il miglioramento continuo.
Approfondiamo un po' di più l'argomento MLOps e analizziamo le caratteristiche specifiche da prendere in considerazione.
Il monitoraggio degli esperimenti e la collaborazione sono le funzionalità più associate a MLOps, ma gli strumenti MLOps più moderni di oggi possono fare molto di più. Ad esempio, alcuni possono fornire un ambiente di runtime per i tuoi esperimenti. Altri possono impacchettare e distribuire modelli una volta che sono pronti per essere integrati in un'applicazione.
Di seguito è riportato un superset di funzionalità presenti negli strumenti MLOps odierni. Questo elenco include anche altre cose da considerare, come supporto e integrazione dei dati.
Supporto da un attore importante : le tecniche e le funzionalità di MLOps sono in continua evoluzione. Vuoi uno strumento supportato da un attore importante (rispettivamente Google, Databricks o McKinsey and Company supportano Kubeflow, MLflow e MLRun), che garantisca sviluppo e miglioramento costanti. Come esempio concreto, molti strumenti popolari oggi sono stati creati prima dei grandi modelli linguistici (LLM); di conseguenza, molti stanno aggiungendo nuove funzionalità per supportare l'IA generativa.
Integrazione Modern Datalake - Gli esperimenti generano molti dati strutturati e non strutturati. Uno strumento MLOps perfettamente integrato con Modern Datalake (o Data Lakehouse) memorizzerebbe i dati non strutturati nel Data Lake (questo è MinIO direttamente) e i dati strutturati andrebbero nel Data Warehouse. Sfortunatamente, molti strumenti MLOps esistevano prima degli Open Table Formats che hanno dato origine a Modern Datalake, quindi la maggior parte avrà una soluzione separata per i propri dati strutturati. Questo è in genere un database relazionale open source che la tua infrastruttura dati dovrà supportare. Per quanto riguarda i dati non strutturati (dataset e checkpoint del modello), tutti i principali strumenti del settore utilizzano MinIO da quando siamo in circolazione dal 2014.
Monitoraggio degli esperimenti : probabilmente la caratteristica più importante di uno strumento MLOps è tenere traccia di set di dati, modelli, iperparametri e metriche per ogni esperimento. Il monitoraggio degli esperimenti dovrebbe anche facilitare la ripetibilità: se hai ottenuto un risultato desiderabile cinque esperimenti fa e gli esperimenti successivi hanno degradato le prestazioni del tuo modello, allora dovresti essere in grado di usare il tuo strumento MLOps per tornare indietro e ottenere gli iperparametri esatti e le caratteristiche del set di dati utilizzati che producono il risultato desiderabile.
Facilita la collaborazione — Una componente importante di uno strumento MLOps è il portale o l'interfaccia utente utilizzata per presentare i risultati di ogni esperimento. Questo portale dovrebbe essere accessibile a tutti i membri del team in modo che possano vedere gli esperimenti degli altri e fare raccomandazioni. Alcuni strumenti MLOps hanno funzionalità grafiche sofisticate che consentono di creare grafici personalizzati confrontando i risultati degli esperimenti.
Model Packaging - Questa capacità impacchetta un modello in modo che sia accessibile da altri ambienti di programmazione, in genere come microservizio. Questa è una bella funzionalità da avere. Un modello addestrato non è altro che un oggetto serializzato. Molte organizzazioni potrebbero averlo già capito.
Model Serving - Una volta che un modello è confezionato come servizio, questa funzionalità consentirà la distribuzione automatizzata del servizio contenente il modello negli ambienti formali dell'organizzazione. Non avrai bisogno di questa funzionalità se hai un
Registro modelli - Un registro modelli fornisce una vista di tutti i modelli attualmente gestiti dal tuo strumento MLOps. Dopotutto, la creazione di modelli di livello di produzione è l'obiettivo di tutti i MLOps. Questa vista dovrebbe mostrare i modelli che sono stati distribuiti in produzione e i modelli che non sono mai entrati in produzione. I modelli che sono entrati in produzione dovrebbero essere contrassegnati in modo tale da poter anche determinare la versione dell'applicazione o del servizio in cui sono stati distribuiti.
Funzioni senza server : alcuni strumenti forniscono funzionalità che consentono di annotare il codice in modo che una funzione o un modulo possano essere distribuiti come servizio containerizzato per l'esecuzione di esperimenti in un cluster. Se decidi di utilizzare questa funzionalità, assicurati che tutti i tuoi ingegneri siano a loro agio con questa tecnica. Potrebbe essere una curva di apprendimento: gli ingegneri con un background DevOps avranno vita più facile, mentre gli ingegneri che hanno studiato in precedenza l'apprendimento automatico con poca esperienza di codifica faranno fatica.
Capacità di Data Pipeline - Alcuni strumenti MLOps mirano a fornire capacità end-to-end complete e hanno caratteristiche specifiche per la creazione di data pipeline per il recupero di dati grezzi, l'elaborazione e l'archiviazione di dati puliti. Le pipeline sono solitamente specificate come
Capacità della pipeline di training : è simile alle pipeline di dati, ma una pipeline di training riprende da dove le pipeline di dati si fermano. Una pipeline di training consente di chiamare il codice di accesso ai dati, inviare dati alla logica di training e annotare artefatti e modelli di dati in modo che vengano salvati automaticamente. Simile alle pipeline di dati, questa funzionalità può essere utilizzata insieme a funzioni serverless per creare DAG e pianificare esperimenti. Se si sta già utilizzando uno strumento di training distribuito, questa funzionalità potrebbe non essere necessaria. È possibile avviare il training distribuito da una pipeline di training, ma potrebbe essere troppo complesso.
Dopo aver esaminato le differenze tra lo sviluppo di applicazioni tradizionali e l'apprendimento automatico, dovrebbe essere chiaro che per avere successo con l'apprendimento automatico, è necessaria una qualche forma di MLOps e un'infrastruttura dati in grado di offrire prestazioni e capacità scalabili.
Le soluzioni homegrown vanno bene se devi avviare un progetto rapidamente e non hai tempo di valutare uno strumento MLOps formale. Se adotti questo approccio, la buona notizia è che tutto ciò di cui hai bisogno per la tua infrastruttura dati è MinIO. MinIO è compatibile con S3, quindi se hai iniziato con un altro strumento e hai utilizzato un'interfaccia S3 per accedere ai tuoi set di dati, il tuo codice funzionerà. Se stai iniziando, puoi utilizzare il nostro
Adottare uno strumento MLOps di terze parti è il modo migliore per le grandi organizzazioni con diversi team AI/ML che creano modelli di diversi tipi. Lo strumento MLOps con più funzionalità non è necessariamente lo strumento migliore. Guarda le funzionalità sopra e prendi nota delle funzionalità di cui hai bisogno, delle funzionalità che hai attualmente come parte della tua pipeline CI/CD esistente e, infine, delle funzionalità che non desideri, questo ti aiuterà a trovare la soluzione migliore. Gli strumenti MLOps hanno un appetito vorace per grandi petabyte di storage di oggetti. Molti di loro eseguono automaticamente la versione dei tuoi set di dati con ogni esperimento e controllano automaticamente i tuoi modelli dopo ogni epoca. Anche in questo caso, MinIO può aiutare poiché la capacità non è un problema. Similmente alla soluzione homegrown, prendi in considerazione l'utilizzo dell'edizione enterprise di MinIO. Le funzionalità di memorizzazione nella cache funzionano automaticamente una volta configurate per un bucket, quindi anche se lo strumento MLOps non richiede l'uso della cache, MinIO memorizzerà automaticamente nella cache gli oggetti a cui si accede di frequente come un set di addestramento.
Molti degli strumenti MLOps oggi sul mercato utilizzano un database relazionale open source per archiviare i dati strutturati generati durante l'addestramento del modello, che di solito sono metriche e iperparametri. Sfortunatamente, questo sarà un nuovo database che deve essere supportato dalla tua organizzazione. Inoltre, se un'organizzazione si sta muovendo verso un Modern Datalake (o Data Lakehouse), non è necessario un database relazionale aggiuntivo. Ciò che sarebbe bello per i principali fornitori MLOps da considerare è l'utilizzo di un data warehouse basato su OTF per archiviare i propri dati strutturati.
Tutti i principali fornitori di MLOps utilizzano MinIO sotto il cofano per archiviare dati non strutturati. Sfortunatamente, questo viene generalmente distribuito come una piccola istanza separata che viene installata come parte dell'installazione complessiva più ampia dello strumento MLOps. Inoltre, di solito è una versione precedente di MinIO, il che va contro la nostra etica di eseguire sempre il
In questo post, ho presentato una guida per architetti a MLOps esaminando sia le funzionalità di MLOps sia l'infrastruttura dati necessaria per supportare tali funzionalità. Ad alto livello, le organizzazioni possono creare una soluzione interna o possono distribuire una soluzione di terze parti. Indipendentemente dalla direzione scelta, è importante comprendere tutte le funzionalità disponibili nel settore oggi. Le soluzioni interne consentono di avviare rapidamente un progetto, ma la soluzione potrebbe presto diventare troppo grande. È anche importante comprendere le proprie esigenze specifiche e il modo in cui MLOps funzionerà con una pipeline CI/CD esistente. Molti strumenti MLOps sono ricchi di funzionalità e contengono funzionalità che potresti non utilizzare mai o che hai già come parte della tua pipeline CI/CD.
Per implementare con successo MLOps, hai bisogno di un'infrastruttura dati in grado di supportarlo. In questo post, ho presentato una soluzione semplice per coloro che hanno scelto una soluzione homegrown e ho descritto cosa aspettarsi da strumenti di terze parti e le risorse di cui hanno bisogno.
Ho concluso con una lista dei desideri per un ulteriore sviluppo degli strumenti MLOps che li aiuterebbero a integrarsi meglio con il Modern Datalake.
Per ulteriori informazioni sull'utilizzo del Modern Datalake per supportare carichi di lavoro AI/ML, consultare
Se hai domande, non esitare a contattarci su