Architettura di una ML platform: feature store, model registry, serving

Le lezioni precedenti del Modulo 10 hanno percorso le preoccupazioni trasversali che ogni piattaforma matura deve gestire: deployment multi-region, alta disponibilità, compliance. Questa lezione applica la stessa lente alla ML platform. Cinque anni fa una “machine learning platform” significava qualunque forma il team più grande dell’azienda fosse riuscito a mettere insieme con script Python, bucket S3, e un job Jenkins che lanciava un training run. Entro il 2026 l’architettura si è standardizzata. Il vocabolario è condiviso, i layer sono riconoscibili tra le aziende, e la domanda build-versus-buy per ogni layer ha una risposta difendibile per la maggior parte dei team.

Questa lezione è il giro architetturale di quei layer. Il Modulo 9 del corso Python copre il lavoro di modellazione vero e proprio; il Modulo 10 copre le specificità del deep learning. La preoccupazione architetturale è diversa. Non è “quale modello allenare” ma “qual è il substrato che consente a un team di allenare, deployare, monitorare, e riallenare modelli senza che ogni passaggio sia uno sforzo eroico una tantum”. Con quel substrato, i modelli diventano un normale tipo di artefatto software, con una pipeline prevedibile dall’idea alla produzione.

I cinque layer

flowchart LR
    DW[(Data warehouse / lakehouse)] --> FS_off[Feature store: offline]
    FS_off --> Train[Training pipeline]
    Train --> Track[Experiment tracking]
    Track --> Reg[Model registry]
    Reg --> Serve[Serving: real-time / batch / streaming]
    FS_on[Feature store: online] --> Serve
    DW --> FS_on
    Serve --> Mon[Monitoring: drift, decay, latency]
    Mon -.retraining trigger.-> Train

Il flusso si legge da sinistra a destra. Il data warehouse o lakehouse del Modulo 5 è la source of truth a monte. Le feature vengono calcolate una volta e memorizzate in due facce del feature store: una faccia offline per il training e una faccia online a bassa latenza per l’inferenza. Le pipeline di training tirano feature offline, eseguono esperimenti tracciati in un sistema che cattura codice, dati, parametri, e metriche, e producono artefatti di modello che vengono registrati con metadata di versione. L’infrastruttura di serving consuma il registry più il feature store online ed espone le predizioni alle applicazioni. Il monitoring chiude il loop, sorvegliando drift dell’input e decay dell’output, e rimandando segnali al retraining.

Ogni box è un layer con un vocabolario, un set di tool standard, e un calcolo build-versus-buy.

Feature store

Il feature store è l’innovazione architetturale che ha reso il resto dello stack ragionabile. Il suo lavoro è centralizzare il calcolo, lo storage, e il serving delle feature in modo che la stessa feature sia calcolata nello stesso modo in training e in produzione.

Il bug per cui è stato costruito ha un nome: train-serve skew. Il team di data science calcola una feature in un notebook contro il warehouse, con una particolare definizione SQL, una particolare gestione dei null, un particolare timezone per l’aritmetica delle date. Il modello viene allenato, valutato, e approvato. Il team di engineering reimplementa poi la stessa feature in un servizio di produzione, in un linguaggio diverso, con una gestione dei null sottilmente diversa. Il modello in produzione vede input che assomigliano quasi ma non del tutto ai dati di training, e le predizioni degradano in modi difficili da rilevare perché il modello sta ancora restituendo numeri che sembrano ragionevoli. Il fix architetturale è spostare il calcolo delle feature in un singolo layer che sia training sia serving consumano.

Un feature store ha tipicamente due facce:

Offline store. Il record storico dei valori delle feature. Supportato da una tabella di warehouse o lakehouse, ottimizzato per letture batch al training time. La pipeline di training chiede “feature X per questi entity id a questi timestamp” e ottiene un dataframe in risposta, con la point-in-time correctness preservata (il valore della feature come era conosciuto al timestamp richiesto, non come è conosciuto ora).
Online store. L’ultimo valore di ogni feature, indicizzato per entity id, ottimizzato per lookup a bassa latenza al momento dell’inferenza. Supportato da un key-value store (lezione 18) come Redis, DynamoDB, o un servizio costruito ad hoc.

La definizione della feature è il contratto tra le due facce. Una singola definizione di feature produce sia il batch fill storico nell’offline store sia il refresh streaming o schedulato dell’online store, in modo che la pipeline di training e quella di serving siano garantite di vedere la stessa logica.

Le opzioni principali al 2026: Feast (il feature store open-source dominante, leggero e framework-agnostic), Tecton (managed, dal team che ha costruito Michelangelo di Uber, con stream feature engineering come preoccupazione di prima classe), Databricks Feature Store (incluso in Databricks e integrato con Unity Catalog e MLflow), e AWS SageMaker Feature Store (l’opzione AWS-native). Il calcolo build-versus-buy corrisponde alla lezione 71. Un team con due data scientist e un ML engineer non dovrebbe costruire un feature store; dovrebbe adottare Feast o qualunque cosa offra il loro cloud vendor. Un team che fa girare migliaia di modelli con stream features e requisiti di bassa latenza potrebbe genuinamente aver bisogno di costruire, o di comprare un’opzione più pesante come Tecton.

Experiment tracking

Ogni training run produce un esperimento: una combinazione di codice a un particolare commit, dati a un particolare snapshot, iperparametri, metriche di training, metriche di valutazione, e l’artefatto del modello risultante. L’experiment tracking è il layer che cattura tutto ciò, lo indicizza, e lo rende ricercabile.

La ragione per cui è una preoccupazione di piattaforma e non di notebook è la riproducibilità a livello di team. Senza tracking, “il modello che abbiamo spedito lo scorso trimestre” è un binario sul laptop di qualcuno con un vago ricordo di come è stato allenato. Con il tracking, lo stesso modello è una riga in un database con link al codice esatto, ai dati, e alle metriche, e riprodurlo è un click di un bottone.

Il componente di tracking di MLflow è diventato lo standard open-source. Weights and Biases è la popolare alternativa commerciale, con feature di collaborazione più forti. Neptune e Comet occupano nicchie simili. Le offerte dei cloud vendor (SageMaker Experiments, Vertex AI Experiments) coprono le basi per team già dentro un cloud. Il tracker deve scalare al volume di run che il team produce e deve integrarsi con il feature store e il registry su entrambi i lati; la maggior parte dei team sotto-investe qui finché il giorno in cui un’outage del tracker blocca l’intera pipeline ML.

Model registry

Il registry è la source of truth per quali modelli esistono, quali versioni di ciascuno, qual è la loro lineage, e quale versione è attualmente deployata dove. Un modello nel registry è una tupla: nome, versione, riferimento al training run, signature, metriche, stage (development, staging, production, archived), e metadata sui dati e sul codice di training.

MLflow Model Registry è di nuovo lo standard open-source de facto, e i cloud vendor ne hanno tutti uno proprio. Il valore architetturale è lo stesso di qualsiasi source of truth: ogni altro layer della piattaforma fa riferimento al registry piuttosto che a un path su disco. Il serving chiede al registry “la versione di produzione del modello X”. Il monitoring chiede “le metriche promesse al training time, così posso confrontarle con quello che stiamo vedendo ora”. Il registry è anche dove vive la governance: un modello promosso in produzione deve aver passato controlli sulla lineage dei dati di training, sulle soglie di valutazione, sulla completezza della model card, e sui piani di deployment, e il registry è dove quei controlli sono applicati e registrati.

Serving

Il serving è dove il modello incontra l’applicazione. Le scelte architetturali ricadono in tre pattern, ognuno con la propria forma di infrastruttura.

Real-time inference. Il modello è incapsulato in un servizio che espone un endpoint REST o gRPC. Un’applicazione invia un feature vector o una richiesta che il servizio arricchisce con feature dell’online store, e il servizio restituisce una predizione entro decine di millisecondi. Questo è il pattern per personalizzazione, fraud detection, search ranking, e qualsiasi superficie user-facing.
Batch inference. Il modello gira su una schedulazione contro un grande dataset di input e scrive le predizioni su una tabella di warehouse o object store. Questo è il pattern per fare scoring di tutti i clienti ogni notte, generare raccomandazioni per una campagna email, o qualsiasi caso d’uso in cui il budget di latenza sia in ore piuttosto che in millisecondi.
Streaming inference. Il modello consuma eventi da un topic Kafka (lezione 42), li arricchisce con feature online, fa una predizione, e scrive la predizione su un altro topic. Questo è il pattern per casi d’uso in cui le decisioni vanno prese mano a mano che gli eventi arrivano ma il consumer è esso stesso un sistema downstream piuttosto che un utente.

I tool spaziano su un ampio range. SageMaker, Vertex AI, e Azure ML sono le opzioni cloud-managed. BentoML e KServe sono framework di serving open-source che si inseriscono in Kubernetes (lezione 55). Seldon e Triton occupano nicchie simili, con Triton particolarmente forte per l’inferenza GPU. Il punto architetturale non ovvio: il layer di serving è infrastruttura applicativa, non infrastruttura dati. I suoi requisiti di uptime, latenza, e capacità si allineano con l’applicazione che serve, non con il warehouse contro cui è stato allenato, e il confine tra ownership del data team e dell’application team deve riflettere questo.

Monitoring

Il monitoring chiude il loop. Ci sono tre preoccupazioni distinte.

Input drift. La distribuzione degli input al modello cambia nel tempo. I clienti che si iscrivono oggi non sono i clienti di quando il modello è stato allenato. Le feature si sono spostate, e le predizioni del modello sulla distribuzione spostata possono essere peggiori delle sue predizioni sulla distribuzione di training. Il drift detection esegue test statistici sulle feature di input contro la distribuzione di training e fa alert quando la divergenza supera una soglia.

Output decay. Le predizioni del modello sono ancora nella forma giusta, ma la qualità si è degradata. Questo richiede ground truth, che spesso arriva in ritardo (la predizione era se un utente avrebbe fatto churn; la ground truth è se ha effettivamente fatto churn, osservabile trenta giorni dopo). Il monitoring dell’output decay confronta le predizioni con la ground truth su una rolling window e fa alert quando accuracy, precision, recall, o un’altra metrica rilevante per il business cala.

Performance. Latenza, throughput, error rate. Le stesse preoccupazioni di osservabilità che ha il resto della piattaforma (lezione 59), con la preoccupazione aggiuntiva che la latenza di un modello ML tende a essere più variabile di quella di un servizio tipico, perché la distribuzione di input influenza il percorso di inferenza.

I tool dedicati all’osservabilità ML includono Arize, WhyLabs, Evidently (open-source), e Fiddler. Alcuni team costruiscono le basi sopra il loro stack di osservabilità esistente (Prometheus, Datadog, Grafana) e adottano un tool dedicato solo quando il volume lo giustifica. Il principio architetturale è lo stesso di altrove: il layer di monitoring deve dare feedback alla retraining pipeline, in modo che drift o decay aprano automaticamente un ticket, triggerino un training run, o nei setup più automatizzati schedulino un refresh del modello.

Il calcolo build-versus-buy, ancora una volta

Il pattern della lezione 71 si ripete qui, layer per layer. Un piccolo team che fa girare una manciata di modelli dovrebbe comprare o adottare tool managed su tutto lo stack: il feature store di un cloud vendor, MLflow per tracking e registry, l’infrastruttura di serving del cloud, un tool di monitoring open-source. Comprare è il default; il carico di manutenzione di far girare la piattaforma da soli è più pesante di quanto sembri, e il costo del vendor lock-in a piccola scala è piccolo.

Un team che fa girare centinaia di modelli con serving a bassa latenza e stream features inizia a vedere il calcolo spostarsi, e un team alla scala di Uber o Netflix ha costruito tutto, perché alla loro scala anche le offerte managed non sono costruite per loro. La piattaforma Michelangelo su cui Uber ha pubblicato (lezione 48) e l’ecosistema Metaflow di Netflix sono gli artefatti di case study. La lezione non è “costruisciti la tua ML platform”. La lezione è che i layer sono reali, il vocabolario è condiviso, e la forma architetturale è riconoscibile in tutta l’industria. Un team che conosce i layer può leggere un job posting, un engineering blog, o un pitch di un vendor e capire cosa si sta descrivendo, che è il livello a cui questo corso punta.

Riferimenti incrociati

La ML platform sta sopra quasi tutto quello che i Moduli da 5 a 9 hanno introdotto. Il data warehouse e il lakehouse delle lezioni da 33 a 40 sono il monte del feature store. L’infrastruttura di streaming delle lezioni da 41 a 48 è quella su cui viaggiano le stream features. Il layer di orchestrazione delle lezioni 57 e 58 schedula training e batch inference. Le pratiche di osservabilità e SLO delle lezioni 59 e 60 si applicano direttamente ai layer di serving e monitoring. Il lavoro di ottimizzazione costi del Modulo 9 è ciò che impedisce alla bolletta GPU di raddoppiare ogni trimestre. La prossima lezione è il capstone del corso.

Citazioni e letture aggiuntive

Progetto Feast, https://feast.dev/ (consultato 2026-05-01). Il feature store open-source dominante.
Progetto MLflow, https://mlflow.org/ (consultato 2026-05-01). Lo standard open-source de facto per tracking e registry.
Tecton, https://www.tecton.ai/ (consultato 2026-05-01). Feature store managed dal team di Michelangelo.
Uber Engineering, “Meet Michelangelo: Uber’s Machine Learning Platform”, https://www.uber.com/blog/michelangelo-machine-learning-platform/ (consultato 2026-05-01). Il case study che ha messo i feature store sulla mappa dell’industria.
Netflix Tech Blog, “Metaflow: Open-source framework for real-life ML”, https://netflixtechblog.com/ (consultato 2026-05-01). L’altra grande ML platform pubblicata.
Chip Huyen, “Designing Machine Learning Systems”, O’Reilly, 2022. Il riferimento da manuale per le preoccupazioni architetturali coperte da questa lezione.
Documentazione di Evidently AI sul ML monitoring, https://docs.evidentlyai.com/ (consultato 2026-05-01). Il tool di monitoring open-source che vale la pena conoscere anche se un team usa qualcos’altro.