Che cos'è un archivio di funzionalità?

Aggiornato: 15 maggio 2025

Informazioni sugli autori:
Mike Del Balso, CEO e cofondatore di Tecton
Willem Pienaar, creatore di Feast

I team che si occupano di dati stanno iniziando a rendersi conto che il machine learning operativo richiede la risoluzione di problemi sui dati che vanno ben oltre la creazione di pipeline di dati.

In un post precedente, Why We Need DevOps for ML Data, abbiamo evidenziato alcune delle principali sfide legate ai dati che i team devono affrontare quando portano i sistemi di ML in produzione.

• Accesso ai dati grezzi corretti
• Creazione di feature a partire da dati grezzi
• Integrazione delle feature in dati di addestramento
• Calcolo e serving delle feature in produzione
• Monitoraggio delle feature in produzione

I sistemi di dati di produzione, sia per l'analisi su larga scala che per lo streaming in tempo reale, non sono una novità. Tuttavia, il machine learning operativo, ovvero l'intelligenza basata sul ML integrata nelle applicazioni rivolte ai clienti, è un concetto ancora recente per la maggior parte dei team. La sfida di distribuire il machine learning in produzione per finalità operative (ad esempio, sistemi di raccomandazione, rilevamento delle frodi, personalizzazione, ecc.) introduce nuovi requisiti per i nostri strumenti di gestione dei dati.

Un nuovo tipo di infrastruttura dati specifica per il ML rende possibile tutto ciò.

Sempre più spesso i team di data science e data engineering si rivolgono ai feature store per gestire i set di dati e le pipeline di dati necessari a portare in produzione le loro applicazioni di ML. Questo post descrive i componenti chiave di un feature store moderno e come l'insieme di questi elementi agisca come un moltiplicatore di forza per le organizzazioni, riducendo la duplicazione degli sforzi di data engineering, accelerando il ciclo di vita del machine learning e sbloccando una nuova forma di collaborazione tra i team di data science.

Breve ripasso: nel ML, una feature è un dato utilizzato come segnale di input per un modello predittivo.

Ad esempio, se una società di carte di credito sta cercando di prevedere se una transazione sia fraudolenta, una feature utile potrebbe essere se la transazione avviene in un paese estero, o come l'importo di questa transazione si confronta con l'importo tipico delle transazioni del cliente. Quando ci riferiamo a una feature, di solito ci riferiamo al concetto di quel segnale (ad es. "transaction_in_foreign_country"), e non a un valore specifico della feature (ad es. non "la transazione n. 1364 è avvenuta in un paese estero").

Qual è lo scopo principale di un feature store?

"L'interfaccia tra modelli e dati"

Abbiamo introdotto per la prima volta i feature store nel post del nostro blog che descrive la piattaforma Michelangelo di Uber. Da allora, i feature store sono emersi come un componente necessario dello stack di machine learning operativo.

I vantaggi dei feature store includono:

1. Portare in produzione nuove feature senza un ampio supporto di ingegneria
2. Automatizzare il calcolo delle feature, i backfill e il logging
3. Condividere e riutilizzare le pipeline di feature tra i team
4. Tracciare versioni, lineage e metadati delle feature
5. Garantire la coerenza tra i dati di addestramento e di serving
6. Monitorare lo stato di salute delle pipeline di feature in produzione

I feature store mirano a risolvere tutti i problemi di gestione dei dati che emergono durante la costruzione e l'uso di applicazioni di ML operativo.

Un feature store è un sistema di dati specifico per il ML che:

• Esegue pipeline di dati che trasformano dati grezzi in valori di feature
• Archivia e gestisce i dati delle feature stesse, e
• Fornisce i dati delle feature in modo coerente sia per l'addestramento che per l'inferenza

Per supportare una gestione semplice delle feature, i feature store forniscono astrazioni dei dati che agevolano la costruzione, l'implementazione e la comprensione delle pipeline di feature tra ambienti diversi. Ad esempio, consentono di definire una trasformazione di feature una sola volta, per poi calcolarne e fornirne i valori in modo coerente sia nell'ambiente di sviluppo (per l'addestramento su valori storici) sia nell'ambiente di produzione (per l'inferenza con valori di feature aggiornati).

I feature store fungono da hub centrale per i dati e i metadati delle feature lungo l'intero ciclo di vita di un progetto di ML. I dati in un feature store vengono utilizzati per:

• Esplorazione e ingegnerizzazione delle feature
• Iterazione, addestramento e debug dei modelli
• Scoperta e condivisione delle feature
• Serving in produzione a un modello per l'inferenza
• Monitoraggio dello stato di salute operativo

I feature store apportano economie di scala alle organizzazioni di ML, abilitando la collaborazione. Quando una feature viene registrata in un feature store, diventa immediatamente disponibile per il riutilizzo da parte di altri modelli in tutta l'organizzazione. Questo riduce la duplicazione degli sforzi di data engineering e consente a nuovi progetti di ML di avviarsi rapidamente facendo leva su una libreria di feature curate e pronte per la produzione.

I feature store efficaci sono progettati come sistemi modulari che possono essere adattati all'ambiente in cui vengono distribuiti. Di norma, un feature store include cinque componenti principali. Nel prosieguo del post, analizzeremo questi componenti e descriveremo il loro ruolo nel supportare applicazioni di ML operativo.

Quali sono i componenti di un feature store?

I 5 componenti principali di un feature store moderno sono: trasformazione, archiviazione, serving, monitoraggio e registro delle feature.

Nelle prossime sezioni forniremo una panoramica dello scopo e delle funzionalità tipiche di ciascuno di questi componenti.

Serving dei dati di feature

I feature store forniscono dati di feature ai modelli. Questi modelli richiedono una visione coerente delle feature tra l'addestramento e il serving. Le definizioni delle feature utilizzate per addestrare un modello devono corrispondere esattamente alle feature fornite durante il serving online. Quando ciò non avviene, si introduce un disallineamento tra addestramento e serving ("training-serving skew"), che può causare problemi di prestazioni del modello catastrofici e difficili da individuare e risolvere.

I feature store incapsulano la logica e l'elaborazione utilizzate per generare una feature, fornendo agli utenti un modo semplice e canonico per accedere in modo coerente a tutte le feature di un'azienda in tutti gli ambienti in cui sono necessarie.

Nel recupero offline dei dati (ad esempio, per l'addestramento), l'accesso ai valori delle feature avviene comunemente tramite SDK dei feature store pensati per l'uso in notebook. Essi forniscono viste point-in-time corrette dello stato del mondo per ciascun esempio utilizzato per addestrare un modello (cosiddetto "time-travel").

Per il serving online, un feature store fornisce un singolo vettore di feature alla volta, composto dai valori di feature più aggiornati. Le risposte vengono fornite tramite un'API ad alte prestazioni supportata da un database a bassa latenza.

Archiviazione dei dati per il machine learning

I feature store rendono persistenti i dati delle feature per supportarne il recupero tramite i livelli di serving delle feature. In genere includono sia un livello di archiviazione online che uno offline per soddisfare i requisiti dei diversi sistemi di serving delle feature.

I livelli di archiviazione offline vengono tipicamente utilizzati per conservare mesi o anni di dati di feature a fini di addestramento. I dati offline dei feature store vengono spesso archiviati in data warehouse o data lake come S3, BigQuery, Snowflake o Redshift. L'estensione di un data lake o data warehouse esistente per l'archiviazione offline delle feature è in genere preferita per evitare la creazione di silos di dati.

I livelli di archiviazione online vengono utilizzati per rendere persistenti i valori delle feature a supporto di lookup a bassa latenza durante l'inferenza. Generalmente, memorizzano solo i valori di feature più recenti per ciascuna entità, modellando di fatto lo stato corrente del mondo. Gli store online sono di solito a coerenza finale ("eventually consistent") e, per la maggior parte dei casi d’uso di ML, non richiedono garanzie di consistenza rigorose. Di norma sono implementati tramite store key-value come DynamoDB, Redis o Cassandra.

I feature store utilizzano un modello di dati basato su entità in cui ogni valore di feature è associato a un'entità (ad esempio un utente) e a un timestamp. Un modello di dati basato su entità fornisce una struttura minima per supportare una gestione standardizzata delle feature, si integra naturalmente con i comuni flussi di lavoro di feature engineering e consente semplici query di recupero in produzione.

Trasformazione dei dati nel machine learning

Le applicazioni di ML operativo richiedono l'elaborazione regolare di nuovi dati in valori di feature, in modo che i modelli possano effettuare previsioni basate su una visione aggiornata del mondo. I feature store gestiscono e orchestrano le trasformazioni dei dati che producono questi valori, oltre ad acquisire valori prodotti da sistemi esterni. Le trasformazioni gestite dai feature store sono configurate tramite definizioni presenti in un registro delle feature comune (descritto di seguito).

I feature store interagiscono comunemente con tre principali tipologie di trasformazioni dei dati:

Un vantaggio chiave dei feature store è quello di rendere semplice l'utilizzo congiunto di diverse tipologie di feature all’interno degli stessi modelli.

I modelli necessitano di accesso a valori di feature aggiornati per l'inferenza. I feature store conseguono questo obiettivo ricalcolando le feature su base continuativa. I job di trasformazione sono orchestrati per garantire che i nuovi dati vengano elaborati e convertiti in valori di feature aggiornati. Questi job vengono eseguiti su motori di elaborazione dati (ad esempio Spark o Pandas) a cui è collegato il feature store.

Lo sviluppo dei modelli introduce requisiti di trasformazione differenti. Durante l'iterazione su un modello, vengono spesso progettate nuove feature da utilizzare in dati di addestramento che corrispondono a eventi storici (ad esempio, tutti gli acquisti negli ultimi 6 mesi). Per supportare questi casi d'uso, i feature store consentono di eseguire facilmente job di backfill che generano e memorizzano i valori storici di una feature a fini di addestramento. Alcuni feature store eseguono automaticamente il backfill delle feature appena registrate per intervalli di tempo preconfigurati associati ai set di dati di addestramento registrati.

Il codice di trasformazione viene riutilizzato tra gli ambienti, prevenendo il disallineamento tra addestramento e serving ("training-serving skew") e liberando i team dalla necessità di riscrivere il codice da un ambiente all'altro.

Monitoraggio del machine learning

Quando qualcosa va storto in un sistema di ML, di solito si tratta di un problema legato ai dati. I feature store si trovano nella posizione ideale per rilevare e far emergere questo tipo di problemi. Possono calcolare metriche in grado di descrivere la correttezza e la qualità delle feature memorizzate e messe a disposizione. I feature store monitorano queste metriche per fornire un segnale dello stato di salute complessivo di un'applicazione di ML.

I dati delle feature possono essere validati sulla base di schemi definiti dall'utente o di altri criteri strutturali. La qualità dei dati viene tracciata tramite il monitoraggio del drift e del training-serving skew. Ad esempio, i dati delle feature forniti ai modelli vengono confrontati con i dati sui quali il modello è stato addestrato per rilevare incongruenze che potrebbero compromettere le prestazioni del modello.

Durante l’esecuzione di sistemi in produzione, è inoltre fondamentale monitorare le metriche operative. I feature store raccolgono metriche operative relative alle funzionalità principali, ad esempio metriche relative allo storage (disponibilità, capacità, utilizzo, obsolescenza) o al serving delle feature (throughput, latenza, tassi di errore). Altre metriche descrivono il funzionamento di componenti di sistema adiacenti rilevanti, come le metriche operative per motori di elaborazione dati esterni (ad esempio, tasso di successo dei job, throughput, ritardo di elaborazione e velocità di elaborazione).

I feature store rendono queste metriche disponibili per l'integrazione con l'infrastruttura di monitoraggio esistente. Ciò consente di monitorare e gestire lo stato di salute delle applicazioni di ML utilizzando gli strumenti di osservabilità già presenti nello stack di produzione.

Avendo visibilità su quali feature vengono utilizzate da quali modelli, i feature store possono aggregare automaticamente alert e metriche di salute in viste pertinenti per utenti, modelli o consumatori specifici.

Registro dei modelli di machine learning

Un componente fondamentale di tutti i feature store è un registro centralizzato di definizioni di feature e metadati standardizzati. Il registro funge da unica fonte di verità per le informazioni relative a una feature all'interno di un'organizzazione.

Il registro è un'interfaccia centrale per le interazioni degli utenti con il feature store. I team utilizzano il registro come catalogo comune per esplorare, sviluppare, collaborare e pubblicare nuove definizioni all'interno dei team e tra team diversi.

Le definizioni presenti nel registro configurano il comportamento del sistema di feature store. I job automatizzati utilizzano il registro per pianificare e configurare l'ingestione, la trasformazione e lo storage dei dati. Esso costituisce la base per stabilire quali dati vengono archiviati nel feature store e come sono organizzati. Le API di serving utilizzano il registro per avere una comprensione coerente di quali valori di feature debbano essere disponibili, chi debba potervi accedere e come debbano essere forniti.

Il registro consente di associare metadati rilevanti alle definizioni di feature. Ciò fornisce un mezzo per tracciare la proprietà, informazioni specifiche di progetto o di dominio e un percorso per una facile integrazione con sistemi adiacenti. Questo include informazioni su dipendenze e versioni che vengono utilizzate per il tracciamento del lineage.

Per supportare i comuni flussi di lavoro di debug, conformità e auditing, il registro funge da record immutabile di ciò che è disponibile a livello analitico e di ciò che è effettivamente in esecuzione in produzione.

Finora abbiamo esaminato i componenti fondamentali e minimi di un feature store. Nella pratica, le aziende hanno spesso esigenze come conformità normativa, governance e sicurezza che richiedono funzionalità aggiuntive orientate all'ambito enterprise. Questo sarà l'argomento di un futuro post sul blog.

Primi passi con i feature store

Riteniamo che i feature store siano il cuore del flusso di dati nelle moderne applicazioni di ML. Si stanno rapidamente dimostrando un'infrastruttura critica per i team di data science che portano il ML in produzione. Prevediamo che il numero di organizzazioni che utilizzano feature store quadruplicherà entro il 2028.

Ecco alcune opzioni per iniziare a usarli:

• Feast è un'ottima opzione se si dispone già di pipeline di trasformazione per il calcolo delle feature, ma si necessita di un solido livello di storage e serving per utilizzarle in produzione. Attualmente Feast è supportato solo su GCP, ma stiamo lavorando alacremente per renderlo disponibile come feature store leggero utilizzabile in tutti gli ambienti. Restate sintonizzati.
• Tecton è una feature platform erogata come servizio ("feature-platform-as-a-service"). Una differenza sostanziale tra Feast e Tecton è che Tecton supporta le trasformazioni, consentendo di gestire le pipeline di feature end-to-end all'interno di Tecton. Tecton è un'offerta gestita e rappresenta un'ottima scelta come feature store per chi ha bisogno di SLA di produzione, hosting, collaborazione avanzata, trasformazioni gestite (batch/streaming/in tempo reale) e/o funzionalità enterprise.

Abbiamo scritto questo articolo per proporre una definizione condivisa dei feature store, che stanno emergendo come componente primario dello stack di ML operativo. Riteniamo che il settore stia per assistere a un'esplosione di attività in questo ambito.