Feature Store

Un feature store è un sistema di dati che definisce, calcola, archivia e fornisce le caratteristiche di input dei modelli di machine learning, in modo che il modello veda durante l'addestramento gli stessi valori delle caratteristiche che usa per le previsioni in tempo reale. Una caratteristica è un input del modello, come il numero di transazioni effettuate con una carta nell'ultima ora, la valutazione media di un prodotto o l'embedding di un'immagine. Il feature store conserva la definizione di ogni caratteristica insieme all'intera cronologia in un archivio offline, per creare set di addestramento, e al suo valore più recente in un archivio online, per consultazioni rapide al momento della previsione. Nel 2017 Uber ha descritto un feature store condiviso in un articolo sulla piattaforma di machine learning Michelangelo. In seguito sono arrivati Feast, un feature store open source avviato da Gojek con Google Cloud, e i feature store gestiti di Amazon SageMaker, Google Vertex AI, Azure Machine Learning e Databricks.

Come funziona un feature store#

Le caratteristiche partono da eventi e tabelle grezzi; le pipeline li trasformano in input del modello tramite la progettazione delle caratteristiche, ad esempio contando le transazioni di una carta nell'arco di una finestra mobile di un'ora, oppure tramite l'estrazione delle caratteristiche con una rete neurale. Un feature store organizza questo lavoro in alcuni componenti:

• Registro delle caratteristiche: Il nome di ogni caratteristica, la chiave dell'entità (il cliente, la carta, il prodotto o la videocamera che descrive), il tipo di dato, il codice di trasformazione, il proprietario e la versione; il registro è consultabile per consentire ai team di riutilizzare le caratteristiche invece di ricrearle.
• Archivio offline: Tutti i valori storici con la rispettiva data e ora dell'evento, conservati in un data warehouse o in un data lake e usati per creare set di addestramento ed eseguire valutazioni in batch.
• Archivio online: Il valore più recente per ogni entità in un database chiave-valore come Redis o DynamoDB, letto in pochi millisecondi durante l'inferenza.
• Materializzazione: Processi in batch o in streaming che calcolano nuovi valori e copiano quelli più aggiornati dall'archivio offline a quello online.

Al momento della previsione, un servizio come un controllo antifrode invia l'ID della carta, riceve dall'archivio online le caratteristiche attuali della carta e le passa al modello, mantenendo la latenza di inferenza abbastanza bassa per l'inferenza in tempo reale durante il pagamento.

Correttezza temporale puntuale#

Ogni riga di training deve usare i valori delle feature così come erano al momento dell'evento etichettato. Un valore calcolato successivamente contiene informazioni future: una forma di data leakage che fa sembrare accurato un modello nelle valutazioni offline, ma lo porta a fallire in produzione. I feature store prevengono questo problema con join point-in-time, che associano ogni etichetta all'ultimo valore della feature disponibile al momento o prima del timestamp dell'etichetta per la stessa entità. La funzione pandas merge_asof esegue lo stesso join:

import pandas as pd

# Feature store offline: il numero di transazioni di ogni carta nell'ultima ora, registrato nel tempo
features = pd.DataFrame(
    {
        "card_id": ["A", "B", "A", "A"],
        "time": pd.to_datetime(["2026-10-01 09:00", "2026-10-01 10:00", "2026-10-01 12:00", "2026-10-01 15:00"]),
        "txn_count_1h": [1, 2, 4, 9],
    }
)

# Eventi etichettati su cui eseguire il training: ogni transazione era una frode?
labels = pd.DataFrame(
    {
        "card_id": ["B", "A"],
        "time": pd.to_datetime(["2026-10-01 11:00", "2026-10-01 13:30"]),
        "is_fraud": [0, 1],
    }
)

# Join point-in-time: ogni etichetta riceve l'ultimo valore della feature della sua carta disponibile al momento o prima dell'evento
training_rows = pd.merge_asof(labels, features, on="time", by="card_id")
print(training_rows)

L'etichetta di frode della carta A alle 13:30 riceve il conteggio pari a 4 registrato alle 12:00; il conteggio pari a 9 registrato alle 15:00, dopo la transazione, resta escluso dal set di training. L'etichetta della carta B alle 11:00 riceve il proprio valore pari a 2, perché l'argomento by associa le righe in base alla chiave dell'entità.

Discrepanza tra training e serving#

La discrepanza tra training e serving è una differenza tra le feature su cui è stato addestrato un modello e quelle che riceve in produzione. Si verifica quando un processo SQL batch calcola le feature di training mentre del codice applicativo scritto separatamente calcola le feature di serving, e i due approcci differiscono per fusi orari, limiti delle finestre, unità o modalità di gestione dei valori mancanti. Le Rules of Machine Learning di Google dedicano una sezione a questa discrepanza e raccomandano di registrare le feature usate durante il serving, così che le successive esecuzioni del training possano utilizzare esattamente quegli stessi valori. Un feature store elimina il percorso di codice duplicato calcolando ogni feature una sola volta a partire da un'unica definizione per entrambi gli usi; inoltre, registra l'aggiornamento, i valori mancanti e il data drift di ogni feature, così che il monitoraggio del modello possa ricondurre un calo di accuratezza a un input non valido.

Feature store e sistemi correlati#

• Data lake: Archivia file grezzi ed elaborati in qualsiasi formato. Molti feature store offline risiedono all'interno di un data lake; il feature store aggiunge chiavi di entità, timestamp, recupero point-in-time e serving online.
• Database vettoriale: Trova gli embedding archiviati più simili a un vettore di query. Un feature store recupera i valori tramite ID entità e può contenere embedding come una feature accanto a conteggi, medie e categorie.
• Registro dei modelli: Assegna versioni ai modelli addestrati e ai relativi metadati, mentre il feature store assegna versioni agli input utilizzati da quei modelli.
• Serving del modello: Esegue il modello dietro un'API e chiama il feature store online per recuperare le feature per ogni richiesta.

Feature dalla computer vision#

L'analisi video trasforma i flussi delle telecamere in feature per le previsioni, il rilevamento delle anomalie e la modellazione predittiva: conteggi orari dei visitatori all'ingresso di un negozio, lunghezze delle code alle casse o tassi di difetti per linea di produzione, ciascuno associato all'ID e al timestamp della telecamera o della linea. Nel retail, il conteggio delle persone alimenta i modelli di personale e domanda; nel settore manifatturiero, i conteggi dei difetti per turno alimentano i modelli di manutenzione. Il conteggio degli oggetti di Ultralytics YOLO produce direttamente questi valori: traccia ogni oggetto rilevato tra i fotogrammi e restituisce i totali progressivi in_count e out_count e i conteggi per classe quando gli oggetti attraversano una linea o una regione, pronti per essere scritti in un feature store come valori con timestamp per ogni telecamera.