MLOps (Machine Learning Operations)

Executive summary

Quando un'organizzazione sviluppa modelli predittivi basati sui dati, la sfida principale non risiede nella costruzione del modello stesso, ma nel renderlo affidabile, aggiornabile e controllabile all'interno dei processi aziendali reali. Questo articolo analizza le pratiche e gli strumenti che consentono di gestire l'intero ciclo di vita di questi sistemi, dalla sperimentazione iniziale al funzionamento continuativo in produzione, con la stessa disciplina ingegneristica applicata al software tradizionale. Dall'analisi emerge che la maturità operativa si raggiunge attraverso un percorso incrementale di automazione, in cui il monitoraggio continuo del comportamento del sistema e la capacità di aggiornarlo in risposta ai cambiamenti nei dati rappresentano le capacità più critiche e, al contempo, le meno consolidate nella pratica industriale.

Background

Il passaggio dalla sperimentazione alla produzione rappresenta il collo di bottiglia più critico nell'adozione industriale del machine learning. Un modello che raggiunge metriche soddisfacenti in ambiente di sviluppo non genera valore fino a quando non viene integrato in un sistema software che ne garantisca l'affidabilità, la riproducibilità e la capacità di adattarsi a dati in evoluzione. Sculley et al. [1] hanno formalizzato questa asimmetria nel 2015, dimostrando che il codice di addestramento del modello costituisce una frazione marginale di un sistema di machine learning in produzione, mentre la maggior parte della complessità risiede in componenti infrastrutturali: pipeline di dati, sistemi di monitoraggio, gestione della configurazione e meccanismi di serving.

Il termine MLOps, contrazione di Machine Learning Operations, designa l'insieme di principi, pratiche e strumenti finalizzati a unificare lo sviluppo dei modelli (ML development) con la loro operazionalizzazione (ML operations) in ambienti di produzione [2]. La disciplina eredita concetti consolidati dalla cultura DevOps, continuous integration, continuous delivery, infrastructure as code, e li estende per affrontare le specificità dei sistemi basati su machine learning, dove il comportamento dell'applicazione dipende non soltanto dal codice sorgente, ma anche dai dati di addestramento, dagli iperparametri e dallo stato statistico dell'ambiente operativo [3]. Google ha ulteriormente codificato questi principi nella propria guida operativa per il practitioner [19], definendo un framework di riferimento per l'implementazione incrementale di pratiche MLOps in ambienti enterprise.

L'esigenza di una disciplina ingegneristica specifica per il machine learning è stata documentata da Amershi et al. [4] attraverso un'analisi empirica su larga scala condotta in Microsoft. Lo studio ha identificato tre dimensioni che differenziano lo sviluppo ML dal software tradizionale: la complessità nella gestione e nel versionamento dei dati, la difficoltà nel riutilizzo e nella personalizzazione dei modelli, e l'impossibilità di trattare i componenti ML come moduli isolati nel senso classico dell'ingegneria del software. Queste osservazioni hanno consolidato il consenso accademico e industriale sulla necessità di framework operativi dedicati.

La letteratura recente ha prodotto diverse sistematizzazioni del campo. Kreuzberger et al. [2] hanno proposto una tassonomia dei principi, dei componenti e dei ruoli che compongono un'architettura MLOps, basata su una revisione sistematica della letteratura e su interviste con esperti di dominio. Paleyes et al. [5] hanno mappato le sfide del deployment di sistemi ML su un workflow end-to-end, evidenziando come i problemi emergano in ogni fase del ciclo di vita, dalla raccolta dati al monitoraggio post-deployment. Più di recente, Eken et al. [6] hanno condotto una multivocal literature review su 198 fonti, producendo una concettualizzazione unificata delle best practice, delle sfide di adozione e dei problemi aperti nel campo.

Il presente articolo analizza lo stato dell'arte in MLOps seguendo un approccio strutturale: dopo aver definito i componenti architetturali di una pipeline MLOps, si esaminano i modelli di maturità proposti dai principali cloud provider, le soluzioni per experiment tracking e model registry, le tecniche di monitoraggio e rilevamento del drift in produzione, e il ruolo dei feature store nella gestione dei dati. L'analisi si conclude con una discussione dei limiti attuali e delle direzioni di ricerca aperte.

Architettura e componenti di una pipeline MLOps

Anatomia del debito tecnico nei sistemi ML

La motivazione fondamentale dell'approccio MLOps risiede nella struttura asimmetrica dei sistemi di machine learning in produzione. Sculley et al. [1] hanno introdotto la metafora del "debito tecnico nascosto" per descrivere come i sistemi ML accumulino costi di manutenzione in modo non evidente. Il codice di addestramento del modello, la componente su cui si concentra tradizionalmente l'attenzione dei data scientist, rappresenta una porzione ridotta del sistema complessivo. Attorno ad esso si sviluppano componenti infrastrutturali critici: sistemi di raccolta e validazione dati, pipeline di feature engineering, infrastrutture di serving, strumenti di monitoraggio e meccanismi di gestione della configurazione.

Questa asimmetria genera specifiche categorie di debito tecnico assenti nel software tradizionale. L'entanglement dei segnali di input implica che la modifica di una singola feature possa alterare il comportamento del modello su tutte le altre feature, rendendo impossibile l'isolamento dei cambiamenti secondo il principio CAID (Changing Anything Changes Everything) [1]. I feedback loop nascosti si verificano quando le predizioni del modello influenzano i dati futuri su cui il modello stesso verrà riaddestrato, creando cicli di rinforzo difficili da diagnosticare. Le dipendenze dai dati, a differenza delle dipendenze dal codice, non possono essere gestite con gli strumenti statici tradizionali (compilatori, linter) e richiedono meccanismi dedicati di validazione e monitoraggio. Polyzotis et al. [18] hanno analizzato sistematicamente queste sfide nel contesto delle pipeline ML in produzione di Google, identificando problemi critici nella comprensione, validazione, pulizia e preparazione dei dati che richiedono soluzioni ingegneristiche specifiche, distinte dagli approcci tradizionali di data management.

Componenti architetturali fondamentali

Un'architettura MLOps matura si articola attorno a un insieme di componenti che coprono l'intero ciclo di vita del modello. Google, nel proprio documento architetturale di riferimento [3], identifica i seguenti elementi come costitutivi di una pipeline ML di livello produttivo:

• Data ingestion e validation: raccolta dei dati da sorgenti eterogenee e validazione automatica rispetto a uno schema atteso. Strumenti come TensorFlow Data Validation (TFDV) [7] consentono di calcolare statistiche descrittive sui dati, generare automaticamente schemi e rilevare anomalie (valori mancanti, distribuzione fuori range, skew tra training e serving) su scala di petabyte.

• Feature engineering e feature store: trasformazione dei dati grezzi in feature utilizzabili dal modello, con garanzia di consistenza tra ambiente di addestramento e ambiente di inferenza. Questo componente è trattato in dettaglio nella sezione dedicata ai feature store.

• Training e hyperparameter tuning: esecuzione dell'addestramento in modo riproducibile, con tracciamento automatico di parametri, metriche e artefatti. L'orchestrazione del training avviene tipicamente attraverso pipeline dichiarative eseguite su infrastruttura gestita.

• Model validation: valutazione automatica del modello addestrato rispetto a criteri di qualità predefiniti prima della promozione in produzione. Questo include non soltanto metriche aggregate (accuracy, F1-score, AUC-ROC) ma anche analisi di fairness e performance su segmenti specifici dei dati.

• Model registry: repository centralizzato per il versionamento, la catalogazione e la gestione del ciclo di vita dei modelli. Ogni modello registrato conserva la propria lineage, esperimento di origine, dataset di addestramento, iperparametri, metriche di validazione.

• Model serving: infrastruttura per il deployment del modello come servizio di predizione, con supporto per strategie di rilascio graduali (canary deployment, A/B testing, shadow mode).

• Monitoring e feedback loop: osservabilità continua delle performance del modello in produzione, con rilevamento automatico di degradazioni e trigger per il riaddestramento. Questo componente chiude il ciclo, collegando l'ambiente di produzione alla pipeline di training.

Il diagramma seguente sintetizza il flusso architetturale di una pipeline MLOps di livello produttivo, evidenziando le dipendenze tra i componenti e il ciclo chiuso tra monitoraggio e riaddestramento.

flowchart LR
    A[Data Sources] --> B[Data Ingestion\n& Validation]
    B --> C[Feature Store]
    C --> D[Training\nPipeline]
    D --> E[Model\nValidation]
    E --> F[Model\nRegistry]
    F --> G[Model\nServing]
    G --> H[Monitoring\n& Drift Detection]
    H -->|trigger retraining| D
    H -->|alerts| I[Alerting\n& Dashboards]

    J[Experiment\nTracking] -.-> D
    K[CI/CD\nPipeline] -.-> D
    K -.-> G

Figura 1, Architettura di riferimento di una pipeline MLOps con ciclo di feedback chiuso. Le linee continue indicano il flusso dei dati e degli artefatti; le linee tratteggiate indicano i flussi di controllo e orchestrazione.

Pipeline come artefatto di prima classe

Un principio architetturale centrale in MLOps è il trattamento della pipeline come artefatto di prima classe, distinto dal singolo modello [3]. Al livello di maturità più elementare (Level 0 nella tassonomia Google), il deployment consiste nel rilascio di un modello addestrato manualmente. A livelli di maturità superiori, l'unità di deployment diventa l'intera pipeline di training, un grafo aciclico diretto (DAG) di componenti containerizzati, ciascuno responsabile di una fase specifica del workflow.

Kubeflow Pipelines [8] implementa questo paradigma su Kubernetes, consentendo la definizione dichiarativa delle pipeline in Python, la containerizzazione di ogni componente, l'orchestrazione automatica delle dipendenze e il tracciamento di metadati e artefatti. Ogni task della pipeline viene eseguito come un pod Kubernetes, con il backend che gestisce il passaggio dei dati e il flusso di controllo tra i componenti. I metadati vengono archiviati in un database MySQL, mentre gli artefatti sono conservati in un object store (Cloud Storage o equivalenti).

Vertex AI Pipelines [9] offre un'implementazione managed dello stesso paradigma, estendendo la compatibilità sia a Kubeflow Pipelines sia a TFX (TensorFlow Extended). L'integrazione nativa con Vertex ML Metadata consente il tracciamento automatico di tutti i parametri e gli artefatti prodotti e consumati dalla pipeline, implementando di fatto un registro di lineage che collega ogni modello ai dati e al codice che lo hanno generato.

Modelli di maturità e livelli di automazione

La tassonomia Google: tre livelli di automazione

Il documento architetturale di Google Cloud [3] propone un modello di maturità a tre livelli che descrive la progressione da un processo interamente manuale a un'automazione completa con continuous integration e continuous delivery per le pipeline ML.

Level 0, Processo manuale. Il data scientist sviluppa il modello in un ambiente sperimentale (tipicamente un notebook), esporta l'artefatto risultante e lo consegna al team di ingegneria per il deployment. Ogni fase, raccolta dati, preprocessing, training, validazione, deployment, è eseguita manualmente. Non esistono pipeline automatizzate, il passaggio tra sperimentazione e produzione è mediato da trasferimenti informali di artefatti, e il monitoraggio post-deployment è assente o rudimentale. Questo livello è adeguato esclusivamente per modelli che non richiedono aggiornamento frequente e operano in contesti con distribuzione dei dati stabile nel tempo.

Level 1, Automazione della pipeline ML. L'unità di deployment non è più il singolo modello ma l'intera pipeline di training. L'obiettivo è il continuous training: il modello viene automaticamente riaddestrato in produzione in risposta a trigger definiti (nuovi dati disponibili, degradazione delle performance, schedule temporali). La pipeline è orchestrata, i componenti sono riutilizzabili, e i metadati di ogni esecuzione vengono tracciati automaticamente. L'introduzione del feature store a questo livello garantisce la consistenza tra le feature utilizzate in training e quelle calcolate in serving. Tuttavia, il codice della pipeline stessa viene ancora aggiornato manualmente dai data scientist.

Level 2, CI/CD per pipeline ML. A questo livello, il ciclo di sviluppo della pipeline è completamente automatizzato. Le modifiche al codice della pipeline, nuove architetture, nuove feature, modifiche agli iperparametri, attivano una catena di continuous integration (build, test unitari e di integrazione sulla pipeline) e continuous delivery (deployment automatico della pipeline aggiornata in produzione). Il continuous training, già presente al Level 1, viene integrato in un ciclo completo di CI/CD/CT (Continuous Integration, Continuous Delivery, Continuous Training).

Il modello Microsoft: cinque livelli di capacità

Microsoft propone un modello di maturità più granulare, articolato su cinque livelli (da 0 a 4), che valuta tre dimensioni organizzative: persone e cultura, processi e strutture, tecnologia [10]. Rispetto al modello Google, la tassonomia Microsoft disaggrega la transizione dall'automazione del training (Level 2) al deployment automatizzato (Level 3) e introduce un livello finale (Level 4) di operazioni completamente automatizzate con meccanismi di auto-riparazione.

Al Level 0 (No MLOps), i team operano in isolamento, le release sono manuali e problematiche, e il tracciamento delle performance del modello non è centralizzato. Al Level 1 (DevOps but no MLOps), le pratiche DevOps standard vengono applicate al codice applicativo, ma il ciclo di vita del modello rimane gestito manualmente. La distinzione è significativa: un'organizzazione può avere CI/CD maturi per il codice software e contemporaneamente operare in modo completamente artigianale per i modelli ML.

Il Level 2 (Automated Training) segna il punto di svolta: l'ambiente di training è interamente gestito e tracciabile, i risultati degli esperimenti sono centralizzati, il codice di training e i modelli sono versionati. Il feature store è adottato a questo livello. Al Level 3 (Automated Model Deployment), il rilascio diventa automatico con CI/CD pipeline dedicata, A/B testing integrato e traceability completa dal deployment ai dati originali. Al Level 4 (Full MLOps Automated Operations), il sistema emette metriche di produzione granulari, i segnali di drift o regressione triggerano automaticamente il riaddestramento, e la promozione dei modelli è basata su policy automatizzate [10].

Convergenze e divergenze

I due modelli convergono su un punto fondamentale: la maturità MLOps è un percorso incrementale, non un requisito binario. Entrambi identificano l'automazione del training come il primo traguardo critico e il continuous training come la capacità distintiva che separa MLOps dal DevOps tradizionale. La convergenza si estende anche al ruolo del feature store, che in entrambe le tassonomie compare come componente necessario a partire dai livelli intermedi di maturità, e al riconoscimento del monitoraggio come prerequisito per qualsiasi forma di automazione del ciclo di vita.

La divergenza principale risiede nella granularità e nella prospettiva adottata. Il modello Microsoft è più descrittivo delle dinamiche organizzative, ruoli, comunicazione tra team, evoluzione culturale, e disaggrega la transizione tra automazione del training e automazione del deployment in due livelli distinti, riconoscendo che l'automazione del rilascio richiede una maturità ingegneristica ulteriore rispetto all'automazione dell'addestramento. Il modello Google è più prescrittivo sull'architettura tecnica dei componenti e identifica il CI/CD per la pipeline stessa, non soltanto per il modello, come il traguardo finale. Questa differenza riflette le rispettive esperienze: Google enfatizza l'automazione end-to-end derivante dalla propria esperienza con sistemi ML su scala planetaria [1, 3], mentre Microsoft privilegia un approccio che riconosce le diverse velocità di maturazione dei team all'interno di organizzazioni enterprise eterogenee [10].

Gestione degli esperimenti e model registry

Il problema della riproducibilità

La riproducibilità degli esperimenti è un prerequisito per qualsiasi forma di automazione del ciclo di vita ML. Un esperimento non riproducibile non può essere automatizzato, perché l'automazione presuppone la capacità di rieseguire una configurazione nota ottenendo risultati equivalenti. Eppure, la riproducibilità nei progetti ML è strutturalmente fragile: dipende non soltanto dal codice e dai dati, ma anche dall'ordine di esecuzione, dallo stato del generatore di numeri casuali, dalla versione delle librerie, dall'hardware utilizzato e, in alcuni casi, dal non-determinismo intrinseco di operazioni parallelizzate su GPU [4].

Zaharia et al. [11] hanno identificato tre sfide principali che ostacolano la gestione del ciclo di vita ML: il tracciamento degli esperimenti (parametri, metriche, artefatti), la riproducibilità delle esecuzioni e il deployment dei modelli in produzione. La risposta proposta è MLflow, una piattaforma open-source strutturata attorno a componenti modulari che affrontano ciascuna di queste sfide.

MLflow: architettura e componenti

MLflow si articola in quattro componenti principali, ciascuno utilizzabile indipendentemente [11, 12]:

MLflow Tracking fornisce un'API e un'interfaccia utente per il logging di parametri, metriche, artefatti e versioni del codice durante l'addestramento. Ogni esecuzione (run) è associata a un esperimento e conserva l'intera configurazione che l'ha prodotta. Il sistema supporta il confronto visuale tra run, consentendo l'analisi sistematica degli effetti delle variazioni sperimentali.

MLflow Models definisce un formato standard per il packaging dei modelli che ne consente il deployment su ambienti eterogenei (REST API, batch inference, edge). Il formato è agnostico rispetto al framework di addestramento: un modello addestrato con PyTorch, scikit-learn o TensorFlow viene serializzato in una struttura comune che include il codice di inferenza e le dipendenze.

MLflow Model Registry è un repository centralizzato per la gestione del ciclo di vita dei modelli. Ogni modello registrato supporta il versionamento, l'assegnazione di alias (ad esempio, "champion" e "challenger"), l'annotazione con metadati e la transizione tra stadi (staging, production, archived). Il registry mantiene la lineage completa: per ogni versione è possibile risalire all'esperimento, al run e ai dati che l'hanno generata.

MLflow Projects definisce un formato per il packaging del codice di training in unità riproducibili, specificando dipendenze e entry point. Con il rilascio di MLflow 3, l'architettura è stata ulteriormente raffinata introducendo il concetto di LoggedModel come entità di prima classe, superando l'approccio tradizionale centrato sui run e consentendo una migliore organizzazione di agenti GenAI, checkpoint di deep learning e varianti di modello attraverso esperimenti diversi [12].

Alternative e complementi

L'ecosistema degli strumenti di experiment tracking si è ampliato significativamente. Weights & Biases (W&B) offre funzionalità analoghe a MLflow Tracking con un'interfaccia orientata alla collaborazione e alla visualizzazione interattiva degli esperimenti [13]. DVC (Data Version Control) estende il paradigma Git al versionamento dei dati e delle pipeline, affrontando una dimensione complementare della riproducibilità: mentre MLflow traccia esperimenti e modelli, DVC traccia i dataset e le trasformazioni che li producono, consentendo di ricostruire la catena completa di dipendenze dati-codice-modello.

La scelta tra queste soluzioni dipende dal contesto organizzativo. MLflow è la piattaforma con la base di adozione più ampia, oltre 60 milioni di download mensili [12], e il vantaggio di essere completamente open-source. W&B offre un'esperienza utente superiore per team di ricerca che privilegiano la visualizzazione. DVC è particolarmente adatto per team che operano in ambienti con vincoli di data governance stringenti.

Monitoraggio in produzione e rilevamento del drift

Tipologie di drift

Il deployment di un modello in produzione non conclude il ciclo di vita ML ma ne avvia una fase critica: il monitoraggio continuo. I modelli di machine learning operano sotto un'assunzione fondamentale, che la distribuzione dei dati in produzione sia coerente con quella dei dati di addestramento. Quando questa assunzione viene violata, le performance del modello degradano, spesso in modo silente [5, 14].

Si distinguono tre tipologie principali di drift:

Data drift (covariate shift): la distribuzione delle feature di input $P(X)$ cambia nel tempo, mentre la relazione tra input e output $P(Y|X)$ rimane invariata. Questo accade, ad esempio, quando la composizione demografica degli utenti di un servizio cambia o quando un sensore industriale inizia a operare in condizioni ambientali diverse.

Concept drift: la relazione stessa tra input e output $P(Y|X)$ si modifica. Un modello di scoring creditizio addestrato prima di una crisi economica subisce concept drift perché le variabili che predicevano il default in condizioni normali hanno un significato diverso in condizioni di stress finanziario. Il concept drift è intrinsecamente più insidioso del data drift perché può verificarsi senza cambiamenti osservabili nella distribuzione degli input.

Prediction drift: la distribuzione delle predizioni $P(\hat{Y})$ cambia nel tempo. Il prediction drift è un segnale proxy utile quando le etichette reali (ground truth) non sono disponibili in tempo reale, una condizione frequente nei sistemi di produzione, dove il feedback sul comportamento corretto può arrivare con ritardi di giorni o settimane.

Approcci al rilevamento

Il rilevamento del drift si basa su test statistici che confrontano le distribuzioni osservate in produzione con quelle di riferimento (baseline). Per feature numeriche, i test più utilizzati includono il Kolmogorov-Smirnov test, il Population Stability Index (PSI) e la divergenza di Jensen-Shannon. Per feature categoriche, il chi-squared test e il Cramér's V sono approcci consolidati. La scelta della soglia di allarme è un compromesso tra sensibilità (rilevare drift reali) e specificità (evitare falsi allarmi che triggerano riaddestramento non necessario) [14].

Un aspetto critico è la granularità temporale del monitoraggio. Una verifica troppo frequente su batch piccoli genera rumore statistico e falsi positivi. Una verifica troppo rada ritarda la rilevazione di drift genuini, causando una degradazione prolungata delle performance. La letteratura suggerisce approcci adattivi che modulano la frequenza di verifica in funzione della volatilità osservata nei dati [6].

Strumenti di monitoraggio

L'ecosistema degli strumenti di monitoraggio ML si è consolidato attorno a due categorie: librerie open-source integrabili nelle pipeline esistenti e piattaforme managed offerte dai cloud provider.

Evidently AI [15] è una libreria open-source Python che fornisce oltre 100 metriche predefinite per la valutazione, il testing e il monitoraggio di sistemi ML. Si struttura attorno a tre componenti: Report (analisi visuale interattiva), Test Suite (validazione automatizzata per pipeline CI/CD) e Monitor (monitoraggio in tempo reale). Evidently supporta il rilevamento di data drift, prediction drift, target drift e la valutazione della qualità del modello su segmenti specifici dei dati.

WhyLogs [16] adotta un approccio architetturale differente, basato sulla profilazione statistica dei dati con garanzie di privacy. WhyLogs calcola profili statistici leggeri (statistical profiles) durante l'inferenza, separando la fase di raccolta dalla fase di analisi. I profili possono essere aggregati nel tempo e confrontati con baseline di riferimento senza esporre i dati grezzi, una proprietà rilevante per contesti con vincoli normativi sulla privacy.

Vertex AI Model Monitoring [9] offre un servizio managed per il monitoraggio di training-serving skew e inference drift, con generazione automatica di allarmi quando la distribuzione dei dati in ingresso devia oltre soglie configurabili. L'integrazione con l'infrastruttura Vertex consente di collegare automaticamente i segnali di monitoraggio a trigger di riaddestramento, implementando un ciclo chiuso.

Strategie di riaddestramento

La risposta al drift rilevato non è univoca. Tre strategie principali emergono dalla letteratura e dalla pratica industriale:

Il riaddestramento periodico (scheduled retraining) esegue il training a intervalli fissi, indipendentemente dai segnali di drift. È la strategia più semplice ma inefficiente: riaddestrare quando non necessario spreca risorse computazionali, non riaddestrare quando necessario degrada le performance.

Il riaddestramento trigger-based avvia il training solo quando i sistemi di monitoraggio rilevano drift o degradazione delle metriche. È più efficiente, ma la sua efficacia dipende dalla qualità del sistema di detection e dalla configurazione delle soglie.

Il riaddestramento adattivo modula dinamicamente la frequenza e l'intensità del riaddestramento in base ai segnali osservati, combinando monitoraggio continuo con strategie di aggiornamento incrementale. Analisi empiriche recenti suggeriscono che il riaddestramento adattivo possa produrre miglioramenti medi dell'accuratezza superiori rispetto alle strategie trigger-based e periodiche, sebbene i risultati dipendano fortemente dal dominio applicativo e dalla velocità del drift nei dati [5, 6]. La scelta della strategia ottimale rimane un problema aperto che richiede la considerazione congiunta del costo computazionale del riaddestramento, della tolleranza alla degradazione delle performance e della disponibilità di ground truth in tempo reale.

Feature store e gestione dei dati

Il problema del training-serving skew

Una delle sfide più insidiose nei sistemi ML in produzione è il training-serving skew: la discrepanza tra le feature calcolate durante l'addestramento e quelle calcolate durante l'inferenza. Lo skew emerge quando il codice di feature engineering viene implementato due volte, una volta nella pipeline di training (tipicamente in batch su dati storici) e una volta nel servizio di inferenza (in tempo reale su singole richieste). Anche piccole differenze nell'implementazione, una diversa gestione dei valori nulli, una differenza nell'ordine delle operazioni, un arrotondamento diverso, possono produrre discrepanze sistematiche che degradano le performance del modello in modo difficile da diagnosticare [3, 7].

Il feature store è l'astrazione architetturale progettata per eliminare questa categoria di errori. Un feature store definisce la trasformazione delle feature una sola volta e garantisce che i valori vengano calcolati e serviti in modo consistente sia nell'ambiente di addestramento (feature storiche per il training su dati passati) sia nell'ambiente di produzione (feature fresche per l'inferenza in tempo reale) [17].

Architettura di un feature store

Un feature store moderno si compone di cinque componenti principali [17]:

Transformation engine: definisce le trasformazioni delle feature come codice dichiarativo, applicabile sia in modalità batch (su dati storici) sia in modalità streaming (su eventi in tempo reale).

Offline store: archivio ottimizzato per l'accesso a grandi volumi di dati storici, utilizzato per la generazione di training set. Tipicamente implementato su data warehouse (BigQuery, Redshift) o object storage (S3, GCS) con formato colonnare (Parquet).

Online store: archivio a bassa latenza per il serving delle feature durante l'inferenza in tempo reale. Implementato su database chiave-valore (Redis, DynamoDB, Bigtable) con latenza target nell'ordine dei millisecondi.

Feature registry: catalogo centralizzato delle feature disponibili, con metadati sulla definizione, l'ownership, la lineage e le statistiche di utilizzo. Il registry abilita la scoperta e il riutilizzo delle feature tra team e progetti diversi.

Monitoring: verifica continua della qualità e della freschezza delle feature, con allarmi in caso di anomalie nei valori serviti.

Feast e l'ecosistema open-source

Feast [17] è il feature store open-source più adottato, progettato per gestire l'infrastruttura di feature serving in modo portabile tra ambienti cloud diversi. Feast consente di definire le feature come codice (infrastructure as code), materializzarle dall'offline store all'online store, e servirle a bassa latenza durante l'inferenza. L'architettura è modulare: il backend di storage può essere configurato per utilizzare diversi provider (Redis, DynamoDB, PostgreSQL per l'online store; BigQuery, Snowflake, file Parquet per l'offline store).

Tecton, il principale contributore al progetto Feast, offre una piattaforma managed che estende le funzionalità open-source con feature engineering in tempo reale, governance avanzata e tracciamento automatico della lineage [17]. La distinzione tra Feast e Tecton riflette una tensione ricorrente nell'ecosistema MLOps: il compromesso tra controllo e operabilità (open-source self-hosted) e semplicità operativa con governance integrata (piattaforma managed).

Validazione dei dati nelle pipeline ML

Complementare al feature store è la validazione automatica dei dati nelle pipeline di training. TensorFlow Data Validation (TFDV) [7] affronta questo problema attraverso un approccio basato su schema. TFDV calcola statistiche descrittive sui dati in modo scalabile (l'implementazione è basata su Apache Beam, consentendo l'esecuzione su Flink, Spark o Cloud Dataflow), genera automaticamente uno schema atteso e rileva anomalie quali feature mancanti, valori fuori range, cambiamenti nel tipo di dato e skew tra distribuzione di training e serving.

Lo schema generato da TFDV opera come un contratto tra i dati e la pipeline ML: ogni nuova esecuzione della pipeline valida i dati in ingresso rispetto allo schema, bloccando l'addestramento in caso di violazioni significative. Questo approccio previene una categoria di errori particolarmente pericolosa, quella in cui un modello viene riaddestrato su dati corrotti o non rappresentativi senza che l'errore venga rilevato.

Limiti, problemi aperti e direzioni future

Complessità operativa e costo di adozione

La principale barriera all'adozione di pratiche MLOps mature non è tecnologica ma organizzativa. Eken et al. [6] identificano la frammentazione delle competenze tra team di data science, ingegneria software e operations come il fattore limitante più citato nella letteratura. L'implementazione di una pipeline MLOps completa richiede competenze che attraversano almeno tre domini disciplinari, machine learning, software engineering e infrastructure engineering, e le organizzazioni faticano a costruire team con questa combinazione di expertise.

Il costo computazionale dell'automazione è un ulteriore fattore critico. Il continuous training, il monitoraggio continuo e il mantenimento di feature store con latenza garantita richiedono risorse infrastrutturali significative. Per organizzazioni con un numero limitato di modelli in produzione o con frequenza di aggiornamento bassa, l'investimento in un'infrastruttura MLOps completa può non essere giustificato. Il modello di maturità incrementale proposto da Microsoft [10] affronta questo problema suggerendo una progressione graduale, ma non fornisce criteri quantitativi per valutare il punto di equilibrio tra costo dell'infrastruttura e beneficio dell'automazione.

Riproducibilità imperfetta

Nonostante i progressi negli strumenti di experiment tracking, la riproducibilità completa dei risultati ML rimane un problema aperto. Il non-determinismo delle operazioni su GPU, le differenze tra versioni di librerie e framework, e la sensibilità dei modelli alle condizioni iniziali rendono la riproduzione esatta dei risultati strutturalmente difficile in molti contesti [4]. Gli strumenti attuali migliorano significativamente la situazione rispetto alla pratica pre-MLOps, consentendo di tracciare e confrontare le configurazioni, ma non risolvono il problema alla radice.

Monitoraggio di modelli generativi e LLM

L'emergere dei large language model (LLM) e dei sistemi generativi ha evidenziato i limiti degli approcci di monitoraggio tradizionali. Le metriche di drift basate su distribuzioni statistiche sono progettate per modelli discriminativi con output strutturato. Per sistemi generativi, dove l'output è testo libero e la qualità è multidimensionale (correttezza, coerenza, sicurezza, aderenza alle istruzioni), le tecniche consolidate risultano insufficienti [6]. La valutazione della qualità di un LLM in produzione richiede approcci qualitativamente diversi, evaluation harness, red teaming automatizzato, monitoraggio semantico dell'output, che sono ancora in fase di maturazione.

Interoperabilità e vendor lock-in

L'ecosistema degli strumenti MLOps è frammentato. Ogni cloud provider offre una propria suite integrata (Vertex AI per Google Cloud [9], SageMaker per AWS, Azure Machine Learning per Microsoft), e le soluzioni open-source non sempre garantiscono interoperabilità tra piattaforme diverse. Il rischio di vendor lock-in è concreto: un'organizzazione che adotta l'intero stack di un singolo provider, feature store, pipeline orchestration, model registry, monitoring, può trovarsi vincolata a quell'ecosistema con costi di migrazione elevati.

Iniziative di standardizzazione come il formato ONNX per l'interoperabilità dei modelli e le specifiche di Kubeflow per l'orchestrazione delle pipeline rappresentano passi nella direzione corretta, ma la standardizzazione a livello di piattaforma MLOps end-to-end è ancora lontana [8].

Governance, compliance e audit trail

Con l'entrata in vigore di regolamentazioni come l'AI Act europeo, la capacità di documentare il ciclo di vita completo di un modello, dati di addestramento, decisioni di design, metriche di validazione, comportamento in produzione, diventa un requisito legale, non soltanto una best practice ingegneristica. Gli strumenti MLOps attuali forniscono i building block per l'audit trail (versionamento dei dati, logging degli esperimenti, lineage dei modelli), ma l'integrazione di questi componenti in un framework di governance coerente e dimostrabile è un'area di sviluppo attivo [5, 6].

Direzioni di ricerca

Il monitoraggio di sistemi generativi e agentici rappresenta la direzione di ricerca con il maggiore impatto potenziale sull'evoluzione delle pratiche MLOps. Le tecniche attuali di drift detection sono progettate per distribuzioni di feature numeriche e categoriche; la loro estensione a output testuali, multimodali e a catene di ragionamento richiede metriche di qualità semantica che la comunità sta ancora definendo [6]. Il problema non è puramente tecnico: a differenza dei modelli discriminativi, dove la degradazione si manifesta in metriche quantitative osservabili, la degradazione di un sistema generativo può essere sottile, contestuale e percepita diversamente da utenti diversi.

L'automazione della selezione delle strategie di riaddestramento rappresenta un secondo asse di sviluppo. Attualmente, la scelta tra riaddestramento periodico, trigger-based e adattivo è una decisione ingegneristica statica. Un approccio più sofisticato prevede modelli di costo-beneficio che ottimizzino congiuntamente il costo computazionale del riaddestramento e il costo della degradazione delle performance, adattando la strategia in funzione delle condizioni operative osservate [2].

L'integrazione di meccanismi di causal inference nel rilevamento del drift è una terza area promettente. I test statistici attuali rilevano correlazioni nelle distribuzioni ma non distinguono tra cambiamenti che causano degradazione delle performance e cambiamenti innocui nella distribuzione degli input. Un approccio causale consentirebbe di triggerare il riaddestramento solo quando il cambiamento osservato ha un effetto causale dimostrabile sulle metriche di performance del modello.

Infine, la progettazione di architetture MLOps federate, che consentano la collaborazione tra organizzazioni mantenendo la segregazione dei dati, è resa urgente dalla diffusione di regolamentazioni sulla privacy e dalla crescente necessità di addestrare modelli su dati distribuiti tra entità organizzative distinte [6].

Riferimenti

[1] D. Sculley et al., "Hidden Technical Debt in Machine Learning Systems," in Proc. NeurIPS, 2015. https://proceedings.neurips.cc/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html

[2] D. Kreuzberger, N. Kühl, S. Hirschl, "Machine Learning Operations (MLOps): Overview, Definition, and Architecture," IEEE Access, vol. 11, pp. 31866-31879, 2023. https://arxiv.org/abs/2205.02302

[3] Google Cloud, "MLOps: Continuous Delivery and Automation Pipelines in Machine Learning," Cloud Architecture Center, 2024. https://docs.cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

[4] S. Amershi et al., "Software Engineering for Machine Learning: A Case Study," in Proc. IEEE/ACM ICSE-SEIP, 2019, pp. 291-300. https://ieeexplore.ieee.org/document/8804457

[5] A. Paleyes, R.-G. Urma, N. D. Lawrence, "Challenges in Deploying Machine Learning: A Survey of Case Studies," ACM Computing Surveys, vol. 55, no. 6, art. 114, 2022. https://dl.acm.org/doi/10.1145/3533378

[6] B. Eken et al., "A Multivocal Review of MLOps Practices, Challenges and Open Issues," ACM Computing Surveys, 2024. https://arxiv.org/abs/2406.09737

[7] E. Breck et al., "TensorFlow Data Validation: Data Analysis and Validation in Continuous ML Pipelines," in Proc. ACM SIGMOD, 2019. https://research.google/pubs/tensorflow-data-validation-data-analysis-and-validation-in-continuous-ml-pipelines/

[8] Kubeflow Project, "Kubeflow Pipelines," 2024. https://www.kubeflow.org/docs/components/pipelines/

[9] Google Cloud, "MLOps on Vertex AI," 2024. https://docs.cloud.google.com/vertex-ai/docs/start/introduction-mlops

[10] Microsoft, "MLOps Maturity Model," Azure Architecture Center, 2025. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/mlops-maturity-model

[11] M. Zaharia et al., "Accelerating the Machine Learning Lifecycle with MLflow," IEEE Data Engineering Bulletin, vol. 41, no. 4, pp. 39-45, 2018. https://people.eecs.berkeley.edu/~matei/papers/2018/ieee_mlflow.pdf

[12] MLflow Project, "MLflow — Open Source AI Platform for Agents, LLMs & Models," 2026. https://mlflow.org/

[13] Weights & Biases, "Experiment Tracking," 2024. https://wandb.ai/

[14] Evidently AI, "What is Data Drift in ML, and How to Detect and Handle It," 2024. https://www.evidentlyai.com/ml-in-production/data-drift

[15] Evidently AI, "Evidently — Open-Source ML and LLM Observability Framework," GitHub repository, 2024. https://github.com/evidentlyai/evidently

[16] WhyLabs, "WhyLogs: The Open Standard for Data Logging," 2025. https://whylabs.ai/

[17] Feast Project, "Feast — The Open Source Feature Store for Machine Learning," 2024. https://feast.dev/

[18] N. Polyzotis et al., "Data Lifecycle Challenges in Production Machine Learning: A Survey," ACM SIGMOD Record, vol. 47, no. 2, pp. 17-28, 2018. https://sigmodrecord.org/publications/sigmodRecord/1806/pdfs/04_Surveys_Polyzotis.pdf

[19] Google Cloud, "Practitioners Guide to Machine Learning Operations (MLOps)," 2021. https://services.google.com/fh/files/misc/practitioners_guide_to_mlops_whitepaper.pdf