Feature store

Wat is een feature store?

Een feature store is een centrale opslag voor machine-learning-features: de afgeleide, berekende variabelen die een model als input gebruikt. "Gemiddelde bestelwaarde van de klant over de afgelopen dertig dagen", "aantal keer dat een gebruiker deze week inlogde", "geografische clustering van het IP-adres". Niet de ruwe data zelf, maar de features die ervan afgeleid zijn.

Zonder een feature store bouwt elk team zijn eigen features in zijn eigen notebook. Dezelfde "actieve klant"-definitie komt zes keer voor, met subtiel verschillende formules. Training-data wijkt af van wat het model tijdens predictie krijgt (training-serving skew), en niemand weet waarom het model in productie slechter scoort dan in evaluatie.

Een feature store lost drie problemen tegelijk op.

Training-serving skew voorkomen
Dezelfde feature-code levert dezelfde waarden, of je nu een historische trainset bouwt of een live predictie-request verwerkt. Feast, Databricks Feature Store, Tecton en Vertex AI Feature Store bouwen hun hele product rond dat principe.

Hergebruik over teams
De feature "gemiddeld transactievolume per dag" uit het fraude-team is ook bruikbaar voor het retentie-team. Eén keer gebouwd, getest en gevalideerd, door iedereen geraadpleegd.

Point-in-time correctness
Bij het bouwen van een trainset wil je de feature-waarde zoals die was op het moment van het label, niet van vandaag. Een feature store houdt per feature een tijdreeks bij, zodat historische training correct reconstrueerbaar is.

Offline versus online store

Een feature store heeft typisch twee lagen.

Offline store
Voor batch-training van modellen. Grote historische dataset, gequeryd per job. Typische backends: Snowflake, BigQuery, Databricks Delta, S3 of ADLS met Parquet. Latency speelt geen rol (een query mag minuten duren), schaalbaarheid en historische correctheid wel.

Online store
Voor realtime predictie. Een webshop die bij een checkout een fraude-score nodig heeft, vraagt de features voor die specifieke gebruiker op binnen milliseconden. Typische backends: Redis, DynamoDB, PostgreSQL. Bevat enkel de meest recente waarde van elke feature, geoptimaliseerd voor low-latency key-value lookups.

De uitdaging: dezelfde feature-definitie voedt beide stores, zodat de waarde die je offline gebruikt voor training identiek is aan wat je online serveert. Dat is de kern van wat Feast, Databricks Feature Store (geïntegreerd met Unity Catalog), Tecton en Vertex AI Feature Store als hun waardepropositie naar voren schuiven.

Wanneer gebruik je een feature store?

Niet elk ML-project heeft er een nodig.

Een feature store rendeert zich vooral uit zodra:

• Meerdere modellen features delen. Eén model in productie kan prima met een notebook en een batch-job. Drie modellen met overlappende features bouwen sneuvelen op inconsistentie.

• Realtime predictie vereist is. Zodra je features binnen milliseconden moet kunnen ophalen, heb je een online store nodig. Zelf bouwen kan, maar Feast of Databricks Feature Store besparen maanden werk.

• Regulatoire auditability nodig is. In sectoren als financiën en gezondheidszorg moet je kunnen reconstrueren welke feature-waardes een model op een bepaald moment zag. Point-in-time correct reproduceren zonder feature store wordt al snel handwerk.

Voor één enkel model dat maandelijks draait op batch-data uit een warehouse: skip de feature store. Een dbt-model met duidelijke definities en tests doet het werk, en je spaart jezelf een extra infrastructuurlaag.

Waar moet je op letten bij het gebruik van een feature store

Prematuur een feature store bouwen
De verleiding om eerst de infrastructuur op te zetten en dan pas de modellen, eindigt vaak in een lege feature store en modellen die alsnog in notebooks leven. Bouw de feature store pas als je drie of meer productie-modellen hebt die features delen, of als realtime serving je echt dwingt.

Geen governance op features
Een feature store kan binnen een jaar duizenden features bevatten, waarvan de helft niet meer gebruikt wordt. Zonder eigenaar per feature, zonder levenscyclusbeheer en zonder automatische retirement-logica wordt het een kerkhof. Dezelfde discipline die je op data-assets legt, hoort ook op features.

Silo tussen ML-engineers en data-engineers
Features worden bedacht door mensen die het bedrijfsprobleem kennen (ML-engineers, data-scientists), geserveerd door mensen die de infrastructuur beheren (data-engineers, platform-teams). Als die twee groepen niet praten, krijg je features die technisch netjes draaien maar het business-probleem niet oplossen. Gedeeld eigenaarschap per feature-familie werkt in de praktijk beter dan strikte rolindeling.

Hype-mismatch
De marketing rond feature stores is groter dan de productiepraktijk. Veel organisaties die claimen er een te gebruiken, draaien feitelijk een Redis-cache voor één model. Vraag bij tool-selectie concreet welke drie gebruikscases gedekt worden, niet welke marketing-woorden de vendor gebruikt.