Feature store: Feast e Tecton

I team reimplementano continuamente le stesse feature e le pipeline di training le calcolano in modo diverso dal codice di serving. Un feature store centralizza definizioni, riutilizzo e serving delle feature, eliminando il lavoro duplicato e il disallineamento tra training e serving.

Due feature store di riferimento:

• Feast: open source e leggero, con infrastruttura a carico dell'utente
• Tecton: commerciale e gestito, aggiunge pipeline di feature in streaming e funzionalità di governance

Entrambi condividono i concetti fondamentali di entità, feature e feature store offline/online.

Un'entità è l'elemento descritto dalle feature, ad esempio un utente o un prodotto. Una feature view raggruppa le feature correlate di un'entità e indica un'origine dati. Queste definizioni risiedono nel codice e sono versionate come qualsiasi altro artefatto.

feast apply registra le definizioni di entità e feature view nel registro del feature store. È il comando con cui il feature store apprende quali feature esistono e da dove provengono i relativi dati.

Prima del serving, le feature devono essere caricate nel feature store online. La materializzazione calcola i valori delle feature fino a un determinato momento e li scrive nel feature store online, ad esempio Redis, così che siano pronti per letture a bassa latenza.

feast materialize riceve una data di inizio e una di fine e carica nel feature store online i valori delle feature relativi a quell'intervallo. Lo si esegue secondo una pianificazione per mantenere aggiornate le feature online.

Al momento dell'inferenza, si recuperano le feature più recenti per determinate entità con get_online_features, passando entity_rows che identificano le entità da cercare. Il comando restituisce i valori più aggiornati in pochi millisecondi.

Per il training si uniscono i valori delle feature alle label storiche. Il feature store legge dal feature store offline e restituisce un dataset allineato al timestamp di ciascuna label, garantendo che gli input di training corrispondano a quelli che verranno forniti durante il serving.

La garanzia fondamentale del feature store è il join point-in-time: per ogni label di training recupera solo i valori delle feature che erano noti al momento o prima del timestamp della label. In questo modo si impedisce l'uso di informazioni future.

Senza la correttezza point-in-time si rischia il data leakage: si esegue il training su valori delle feature calcolati dopo l'evento della label, ottenendo metriche offline gonfiate che però crollano in produzione. Il feature store applica automaticamente la correttezza temporale.

Il ciclo di vita del feature store riunisce tutti questi aspetti:

• feast apply registra le definizioni
• feast materialize carica il feature store online
• il training usa join point-in-time dal feature store offline
• il serving legge i valori aggiornati tramite get_online_features

Verifichi la Sua conoscenza dei feature store.

Ha imparato a usare i feature store con Feast e Tecton:

• feast apply registra entità e feature view
• feast materialize carica il feature store online per le date indicate
• get_online_features fornisce valori aggiornati per entity_rows
• i join point-in-time creano dati di training privi di leakage