MLOps: come dati, modelli e governance si integrano in produzione

Molti team iniziano a occuparsi di MLOps partendo dal modello: come è stato addestrato, dove verrà distribuito e con quale rapidità potrà essere riaddestrato. In produzione, tuttavia, il modello è solo un elemento di un sistema molto più ampio: ci sono la tabella che lo ha alimentato, la definizione della feature che lo ha plasmato, l’etichetta arrivata con tre giorni di ritardo, lo schema modificato a monte e la policy di accesso che stabilisce chi può utilizzare l’output.

Per questo il significato di MLOps non si può ridurre a “DevOps per i modelli”. MLOps adotta dal DevOps l’automazione, la CI/CD e la disciplina di rilascio, ma deve anche considerare problemi specifici dei modelli che i team software in genere non affrontano: data drift, concept drift, riutilizzo delle feature, disallineamento tra training e serving, spiegabilità dei modelli, lineage dei modelli e riaddestramento basato sui nuovi risultati ottenuti in produzione. MLOps collega queste dipendenze affinché i modelli possano essere integrati in app che rimangono affidabili mentre cambiano l’attività aziendale, i dati e l’ambiente operativo.

MLOps è l’insieme di pratiche che automatizza e standardizza il deployment, il monitoraggio e la manutenzione dei modelli ML in produzione. Queste pratiche consentono di gestire l’intero ciclo di vita del machine learning.

Come il software, anche un modello dipende dal codice. Dipende però anche da dati di training, feature, etichette, parametri, metriche di valutazione, dipendenze di runtime, infrastruttura di serving e feedback provenienti dall’ambiente in cui vengono utilizzate le previsioni. MLOps consente di creare versioni di questi asset, testarli, sottoporli ai passaggi di approvazione, distribuirli in modo coerente e monitorare se continuano a comportarsi come previsto.

Un modello che assegna punteggi ai lead, prevede la domanda, instrada i ticket di assistenza o segnala transazioni sospette non è solo un asset di data science. È ormai parte di un workflow operativo: i team aziendali dipendono dai suoi output e i team tecnici devono mantenerlo disponibile, aggiornato e spiegabile.

Processi MLOps solidi consentono di gestire meglio questa responsabilità su larga scala. “MLOps viene spesso descritto come una sfida legata agli strumenti, ma nella pratica l’ostacolo principale è rappresentato dai workflow frammentati”, spiega Trace Smith, Senior AI/ML Architect, Applied Field Engineering presso Snowflake. “La tendenza attuale punta verso un ambiente di dati e ML più unificato, nel quale la governance e i workflow dei modelli confluiscono in un unico modello operativo. Questo riduce le complessità operative e accelera il passaggio alla produzione”.

Anziché trattare ogni modello come un progetto isolato, si possono utilizzare pipeline ripetibili, monitoraggio, controllo delle versioni e controlli di governance per portare più rapidamente i modelli in produzione, rilevare variazioni delle prestazioni e apportare aggiornamenti senza ricostruire da zero il processo operativo.

MLOps supporta i team in tre modi concreti:

• Riduzione del time-to-market: le pipeline automatizzate sostituiscono i passaggi manuali con processi ripetibili di addestramento, test, pacchettizzazione e deployment.
• Maggiore affidabilità: il monitoraggio consente di rilevare variazioni delle prestazioni, drift, problemi di qualità dei dati ed errori di runtime prima che compromettano le decisioni a valle.
• Maggiore scalabilità e governance: il controllo delle versioni, il lineage, i workflow di approvazione e i controlli degli accessi consentono alle organizzazioni di gestire più modelli in più team senza ricorrere a un coordinamento informale.

DevOps si concentra sul rilascio del software. MLOps estende questo approccio ai dati e al comportamento statistico dei sistemi ML.

Il processo MLOps funziona come un ciclo, non come una sequenza lineare di passaggi. I team raccolgono e convalidano i dati, preparano le feature, addestrano e valutano i modelli, registrano ed eseguono il deployment delle versioni approvate, quindi reimmettono i segnali di produzione nel ciclo successivo di monitoraggio e riaddestramento.

Raccolta e ingestion dei dati

Il ciclo di vita inizia con i dati provenienti da sistemi di origine come database, file, stream, API, app e set di dati di terze parti. Per il ML in produzione, l’ingestion non consiste soltanto nel trasferire i dati in un ambiente di addestramento. Conserva il contesto necessario per capire da dove provengono i dati, quanto sono aggiornati e se possono essere utilizzati per lo scopo previsto.

Convalida dei dati e controlli di qualità

Prima di utilizzare i dati per l’addestramento o l’inferenza, occorre verificare la presenza di valori mancanti, modifiche dello schema, valori anomali, record duplicati, bias, problemi di privacy e dati non aggiornati. Questi controlli impediscono che input errati influenzino il comportamento del modello. Ad esempio, una colonna che passa dal tipo intero al tipo stringa, un feed che smette di aggiornarsi o un’etichetta che diventa disponibile più tardi del previsto possono compromettere la qualità del modello molto prima che si manifesti un errore visibile in produzione.

Preparazione dei dati e feature engineering

Il feature engineering trasforma i dati grezzi in segnali utilizzabili dai modelli attraverso operazioni di pulizia, trasformazione, unione, etichettatura e arricchimento. Negli ambienti MLOps maturi, i team dati definiscono una sola volta le feature di uso comune e le riutilizzano in modo coerente durante l’addestramento e l’inferenza. Questo riduce il rischio di calcolare “cliente attivo” o “volume delle transazioni recenti” in modo diverso tra team, oppure che un modello in produzione utilizzi una logica delle feature non più corrispondente alla versione impiegata durante l’addestramento.

Sviluppo dei modelli

Data scientist e ML engineer addestrano i modelli utilizzando notebook, script, machine learning automatizzato (AutoML) o framework ML. Confrontano algoritmi, parametri, finestre di training e set di dati per individuare l’approccio più adatto al problema di previsione. Il requisito MLOps fondamentale per lo sviluppo dei modelli è che la sperimentazione produca metadati sufficienti per consentire a un’altra persona, pipeline o workflow di approvazione di comprendere che cosa è stato addestrato, quali dati sono stati utilizzati e quali prestazioni ha ottenuto il modello.

Tracciamento degli esperimenti

Il tracciamento degli esperimenti registra versioni dei modelli, set di dati, codice, parametri, metriche, artefatti e risultati. Senza questo tracciamento, i team possono sapere che un’esecuzione ha prodotto risultati migliori di un’altra, ma non perché. Con questo tracciamento, invece, possono confrontare i modelli candidati, riprodurre un risultato e spiegare quale versione del modello è stata promossa in produzione.

Validazione e valutazione dei modelli

La valutazione dei modelli verifica se un modello addestrato è accurato, affidabile e adatto al processo aziendale che deve supportare. La valutazione comprende il monitoraggio di metriche tecniche come accuratezza, precisione, recall, F1, AUC, RMSE e latenza, oltre a equità, robustezza e KPI aziendali. Il processo di valutazione deve inoltre verificare se il modello si comporta in modo accettabile per segmenti, aree geografiche, linee di prodotto o categorie di rischio importanti, non soltanto se in media offre buone prestazioni.

Pacchettizzazione e registrazione dei modelli

Una volta superata la valutazione, il modello viene pacchettizzato con le relative dipendenze e i metadati, quindi lo archiviano in un registro dei modelli. Il registro fornisce un ambiente controllato in cui gestire versioni, stato di approvazione, lineage, stato del deployment e metadati operativi.

Deployment dei modelli

Il deployment dei modelli rilascia il modello in produzione come processo batch, API in tempo reale, pipeline di inferenza in streaming, feature integrata in un’applicazione o deployment all’edge. Il modello di serving dipende dai requisiti aziendali e da latenza, costi e aggiornamento dei dati. Ad esempio, un modello di rilevamento delle frodi può richiedere l’inferenza in tempo reale, mentre un modello mensile di propensione può essere eseguito come processo di scoring batch che riscrive le previsioni in una tabella per gli utilizzi downstream.

Serving dei modelli

Dopo il deployment, il modello deve essere distribuito in modo conforme ai requisiti dell’applicazione in termini di latenza, scalabilità, costi e aggiornamento dei dati. Il serving dei modelli è il livello runtime che rende disponibili le previsioni tramite scoring batch, API in tempo reale, inferenza in streaming, logica applicativa integrata o ambienti edge. Questo livello deve gestire la preparazione degli input, il recupero delle feature, le dipendenze runtime, la scalabilità, i controlli degli accessi, la latenza e la gestione degli errori, affinché la versione approvata del modello possa essere utilizzata in modo affidabile in produzione.

Monitoraggio dei modelli

Il monitoraggio dei modelli verifica se, dopo il deployment, un modello continua a comportarsi come previsto. In genere, i team dati monitorano prestazioni in produzione, latenza, errori, data drift, concept drift, qualità del modello, costi e stato operativo.

Feedback e nuovo addestramento

Le previsioni in produzione generano nuove informazioni: etichette, azioni degli utenti, risultati aziendali, feedback umano e segnali di drift. MLOps reintegra queste informazioni nel ciclo di vita, consentendo di addestrare, convalidare e distribuire nuovamente i modelli quando la versione corrente non offre più prestazioni adeguate. L’avvio del nuovo addestramento può essere pianificato, basato su eventi o associato a soglie di monitoraggio, a seconda del rischio e della variabilità del caso d’uso.

Governance e compliance

La governance si estende all’intero ciclo di vita del ML. I team dati devono gestire accessi, audit trail, spiegabilità, lineage, privacy, sicurezza, approvazioni e requisiti normativi, dai dati grezzi all’inferenza in produzione. Questo aspetto è particolarmente importante per le organizzazioni che operano in Italia, quando i modelli influenzano decisioni ad alto impatto in ambiti quali credito, determinazione dei prezzi, assistenza sanitaria, occupazione, rilevamento delle frodi e sicurezza, anche alla luce dell’AI Act dell’Unione europea e dei relativi obblighi applicabili ai sistemi AI ad alto rischio. La governance aiuta inoltre a rispondere a domande operative fondamentali: Quale versione del modello è in esecuzione? Con quali dati è stato addestrato? Quali feature utilizza? Chi lo ha approvato? Che cosa è cambiato rispetto alla versione precedente?

MLOps richiede un insieme interconnesso di componenti. Alcune organizzazioni distribuiscono questi componenti tra più sistemi, mentre altre preferiscono una piattaforma integrata che mantenga più strettamente connessi dati, gestione delle feature, operazioni sui modelli e governance.

La maturità del MLOps aumenta generalmente man mano che si automatizzano più fasi del ciclo di vita e introducono controlli più rigorosi su riproducibilità, monitoraggio e governance. Il modello di maturità MLOps di Google Cloud è un riferimento comune.

Livello 0: processo manuale

Al livello 0, le attività di ML sono incentrate sui notebook e richiedono numerosi interventi manuali. I data scientist preparano i dati, eseguono il training dei modelli, valutano i risultati e trasferiscono gli artefatti tramite processi informali. Questo approccio può essere adatto alla sperimentazione, ma comporta rischi quando occorre riprodurre, aggiornare o monitorare i modelli in produzione.

Livello 1: automazione della pipeline ML

Al livello 1, la pipeline ML viene automatizzata per sottoporre nuovamente i modelli a training su nuovi dati mediante fasi ripetibili di convalida, training e valutazione L’obiettivo è il training continuo: un metodo controllato per aggiornare i modelli quando diventano disponibili nuovi dati. Questo livello riduce i passaggi manuali, ma la pipeline può comunque richiedere una gestione separata dei rilasci.

Livello 2: automazione della pipeline CI/CD

Al livello 2, le attività necessarie vengono automatizzate per sviluppare, testare ed eseguire il deployment delle pipeline ML. Le modifiche al codice, alla logica di convalida dei dati, ai workflow di training e alle definizioni di deployment passano attraverso processi CI/CD. A questo livello, le operazioni ML assumono le caratteristiche di una disciplina di ingegneria della produzione, con pipeline sottoposte a controllo delle versioni, test automatizzati e promozione controllata tra gli ambienti.

Maturità avanzata: operazioni autonome e governate

Alcuni modelli di maturità prevedono un livello superiore per le operazioni avanzate o autonome. In questa fase, i segnali di monitoraggio possono attivare workflow di retraining, i controlli di governance sono integrati nei percorsi di promozione e si possono gestire numerosi modelli applicando policy coerenti. L’obiettivo non è eliminare il giudizio umano, soprattutto per i modelli ad alto impatto, ma rendere più sistematiche le attività ordinarie di rilevamento, convalida ed escalation.

Scopri come usare Snowflake ML per sviluppare e rendere operativi modelli su larga scala:

La gestione operativa dei large language model (LLMOps) estende le pratiche MLOps alle app di AI generativa. LLMOps amplia il MLOps introducendo nuovi aspetti operativi legati a prompt, retrieval, contesto, utilizzo dei token, sicurezza e valutazione.

LLMOps include generalmente:

• Controllo delle versioni dei prompt e delle istruzioni di sistema
• Framework di valutazione per accuratezza fattuale, pertinenza, tono, sicurezza e completamento delle attività
• Monitoraggio delle pipeline RAG, inclusi l’aggiornamento dei documenti e la qualità del recupero
• Monitoraggio dei costi dei token e ottimizzazione della latenza
• Monitoraggio dei guardrail per privacy, tossicità, fondatezza e violazioni delle policy
• Cicli di feedback per la revisione umana e il miglioramento dei modelli

Tuttavia, si applica lo stesso principio operativo: l’applicazione è affidabile quanto i dati, il contesto, la valutazione e la governance su cui si basa.

Solide pratiche MLOps evitano che il ML in produzione diventi un insieme di passaggi di consegne una tantum. Quando i modelli passano dallo sviluppo ai workflow operativi, si devono adottare metodi coerenti per controllare le versioni degli asset che ne influenzano il comportamento, testare le modifiche prima del rilascio, monitorare le prestazioni in produzione e aggiornare i modelli senza perdere la tracciabilità.

Controllare le versioni di tutto ciò che influenza il comportamento del modello

MLOps deve controllare le versioni di codice, set di dati, definizioni delle feature, parametri, artefatti dei modelli, dipendenze, risultati delle valutazioni e metadati di deployment. Quando un modello cambia, occorre sapere se le variazioni delle prestazioni dipendono da nuovi dati di addestramento, da una nuova logica delle feature, da un diverso insieme di parametri o da un nuovo ambiente runtime.

Automatizzare test e CI/CD per ridurre i rischi

L’automazione deve includere i controlli che i team dati devono ripetere in modo affidabile: convalida dei dati, convalida delle feature, valutazione dei modelli, packaging, deployment e rollback. La CI/CD per il ML deve includere anche test specifici per i modelli, come controlli del drift, test dei bias, soglie di latenza e guardrail per i KPI aziendali.

Monitorare continuamente i modelli in produzione

Il monitoraggio della produzione deve rilevare lo stato dei sistemi e il comportamento dei modelli. Latenza, errori e costi sono importanti, così come le distribuzioni degli input e delle previsioni, le prestazioni dei modelli, il drift e l’aggiornamento dei dati.

Progettare per la riproducibilità

Un team dati deve poter spiegare come è stato prodotto un modello, con quali set di dati e feature è stato addestrato, quali codice e parametri sono stati utilizzati, quali metriche ne hanno giustificato la promozione e quale versione genera attualmente le previsioni. La riproducibilità facilita il debugging, l’auditabilità, la collaborazione e la compliance.

Partire da un livello di maturità sostenibile per il team dati

Il livello di maturità del MLOps deve essere adeguato alle esigenze, alle competenze e al profilo di rischio dell’organizzazione. Un team con un solo modello batch a basso rischio potrebbe non aver bisogno del riaddestramento autonomo fin dal primo giorno. Un team con numerosi modelli rivolti alla clientela, casi d’uso regolamentati o dati in rapida evoluzione avrà prima bisogno di automazione, monitoraggio e governance più solidi.

Molte architetture MLOps trasferiscono i dati tra sistemi separati per preparazione, addestramento, gestione delle feature, registro, serving e monitoraggio. Questa separazione può generare copie aggiuntive, un lineage frammentato e più punti in cui le policy di accesso o le definizioni delle feature possono divergere. L’approccio Snowflake consiste nel portare una parte più ampia del ciclo di vita del ML sui dati governati nell’AI Data Cloud Snowflake.

Con Snowflake ML, i team possono sviluppare, addestrare, distribuire e monitorare i modelli più vicino ai dati che utilizzano. Snowflake ML include funzionalità come Snowpark ML API per lo sviluppo, Snowflake Notebooks per l’esplorazione e la collaborazione, Snowflake Feature Store per la gestione delle feature e Snowflake Model Registry per il controllo delle versioni e la governance. ML Observability consente di monitorare i modelli registrati in produzione, incluse le metriche di prestazioni, drift e volume, e attualmente supporta i modelli di regressione e classificazione binaria.

Le feature possono essere definite una sola volta, governate tramite controlli degli accessi e tracciate mediante il lineage nel passaggio dall’addestramento all’inferenza, mentre un registro conserva i metadati, la cronologia delle versioni e lo stato di deployment dei modelli. I data scientist possono continuare a sperimentare nei notebook, mantenendo il lavoro più vicino ai dati governati e utilizzando il monitoraggio per rilevare quando gli input di produzione iniziano a divergere dalle ipotesi adottate durante la valutazione.

MLOps viene spesso descritto attraverso i meccanismi di deployment: pipeline, registri, CI/CD, monitoraggio e riaddestramento. Questi meccanismi sono validi, ma risolvono il problema più ampio solo se rimangono collegati ai dati e al contesto di governance del modello. Una versione del modello è più affidabile quando si possono tracciare i dati utilizzati per addestrarla, comprendere le feature che usa, verificarne le prestazioni durante la valutazione e rilevare quando il comportamento in produzione inizia a cambiare.

Poiché il ML entra in un numero crescente di app e workflow aziendali, questo contesto operativo non può essere considerato facoltativo. I team dati devono poter procedere rapidamente senza perdere il lineage, riutilizzare le feature senza duplicare la logica, monitorare i modelli senza separarli dai dati da cui dipendono e aggiornare i sistemi di produzione senza affidarsi a passaggi di consegne manuali. MLOps fornisce questa struttura.