Feature Platform

Eine Feature Platform ist eine Software-Schicht, die alle Eingabewerte für Machine-Learning-Modelle (sogenannte Features, also berechnete Kennzahlen aus Rohdaten) an einer Stelle definiert, berechnet, speichert, ausliefert und überwacht. Sie stellt sicher, dass ein Modell im Training und im Produktivbetrieb (Inferenz, also das Anwenden des fertigen Modells auf neue Daten) mit denselben Zahlen arbeitet, und verhindert damit den sogenannten Train-Serve-Skew, also die abweichende Berechnung derselben Kennzahl zwischen Trainings- und Produktivpfad.

Was ist eine Feature Platform?

Ein Feature ist im Machine Learning eine Eingabegröße, mit der ein Modell trainiert und im Betrieb bedient wird, also ein Wert, den das Modell als Kennzahl liest. Typische Beispiele sind die Anzahl der Bestellungen eines Kunden in den letzten 24 Stunden, die Summe im aktuellen Warenkorb, die Klick-Zahl in einer Web-Session oder ein durchschnittlicher Messwert über ein Zeitfenster. Diese Größen werden aus den Rohdaten berechnet, meist durch Aggregation (Summen, Zählungen, Durchschnitte), Fenster-Operationen (Werte über einen Zeitraum) oder Encoding (Umwandlung von Text- in Zahlenwerte). Eine Feature Platform ist die Software-Schicht, die diese Berechnung, das Speichern und das Ausliefern der Werte an Trainings- und Produktiv-Systeme organisiert.

Die Referenzarchitektur einer Feature Platform besteht aus fünf Komponenten. Die Feature-Definition beschreibt deklarativ, wie ein Feature aus Rohdaten berechnet wird, häufig in Python oder SQL oder in einer domänenspezifischen Sprache. Die Compute-Engine führt diese Definitionen aus, wahlweise als Batch-Job über historische Daten oder als Streaming-Job über Live-Ereignisse. Die Feature-Store-Komponente speichert die berechneten Werte in einem Offline-Store für Training und Batch-Inferenz (typisch Delta Lake, Iceberg oder Parquet auf Object Storage) und in einem Online-Store für Low-Latency-Inferenz (typisch Redis, DynamoDB, Cassandra oder ein integrierter Store wie Databricks Lakebase). Die Feature-Serving-API stellt die Feature-Werte im Millisekunden-Bereich per REST oder gRPC bereit. Das Monitoring beobachtet Freshness, Nullwert-Anteil, Verteilungs-Drift und Feature-Statistiken pro Version.

Der Begriff hat sich als Antwort auf drei wiederkehrende Probleme in produktiven ML-Setups etabliert. Erstens: dieselbe Kennzahl wird an mehreren Stellen unterschiedlich berechnet, weil das Trainings-Notebook eine andere Aggregations-Definition nutzt als der Produktions-Service. Diese Abweichung heißt Train-Serve-Skew und ist eine der häufigsten Ursachen für abfallende Modellqualität im Betrieb. Zweitens: mehrere Teams entwickeln redundant ähnliche Features (Nutzer-Aktivitätsscore, Kunden-Segment, Session-Wert), weil es keine zentrale Registry gibt. Drittens: historische Trainings-Datensätze lassen sich nicht reproduzierbar erzeugen, weil kein Point-in-Time-Zugriff auf die zum damaligen Zeitpunkt gültigen Feature-Werte existiert. Eine Feature Platform adressiert alle drei Punkte durch eine einheitliche Definitions-, Speicher- und Auslieferungsschicht.

Ausprägungen gibt es sowohl als managed SaaS (Tecton, Chalk), als Open-Source-Framework ([Feast](https://feast.dev/)) und als plattformintegrierte Komponente in Cloud- und Lakehouse-Ökosystemen (Databricks Feature Engineering in Unity Catalog kombiniert mit Lakebase Online Feature Store, Vertex AI Feature Store, SageMaker Feature Store). Die konzeptionelle Grundlage des Begriffs geht auf Ubers interne ML-Plattform [Michelangelo](https://www.uber.com/blog/michelangelo-machine-learning-platform/) zurück (2017); die heute gebräuchliche Trennung zwischen Feature Store und Feature Platform hat vor allem [Chip Huyen (2023)](https://huyenchip.com/2023/01/08/self-serve-feature-platforms.html) geprägt.

Abgrenzung zu Feature Store, Feature Engineering und ML Platform

Der Begriff wird in Marketing- und Vendor-Texten oft synonym mit „Feature Store" verwendet und mit dem tätigkeits-orientierten „Feature Engineering" vermischt. Die Abgrenzung sitzt an klaren funktionalen Grenzen.

Der Unterschied zwischen Feature Platform und Feature Store ist der zwischen End-to-End-Framework und Speicherkomponente. Ein Feature Store ist die Persistenz- und Registry-Schicht: Offline-Store für Training, Online-Store für Inferenz, Metadaten-Katalog mit Owner und Schema. Eine Feature Platform enthält den Feature Store als Teilkomponente und ergänzt ihn um Compute-Engine, Feature-Serving-API, Point-in-Time-Joins und Monitoring. Der Hopsworks-Katalog fasst diese Grenze knapp: eine Feature Platform ist ein Feature Store mit zusätzlicher Sprache für Feature-Logik und Feature-Pipelines. Die Databricks-Terminologie führt diese Trennung nicht scharf durch, sondern subsumiert beide Ebenen unter „Feature Store" plus Feature Engineering in Unity Catalog.

Feature Engineering bezeichnet die Aktivität des Ableitens aussagekräftiger Merkmale aus Rohdaten durch Aggregationen, Encodings, Fenster-Operationen, Interaktions-Features oder Domain-spezifische Transformationen. Eine Feature Platform ist die Software-Schicht, die diese Aktivität operationalisiert: Sie führt die Berechnung aus, speichert das Ergebnis, versioniert die Definition und liefert es an Trainings- und Inferenzpfade aus. Feature Engineering ist der methodische Job der Data Scientists, die Feature Platform der Werkzeugsatz, in dem dieser Job umgesetzt wird.

Gegenüber einer generischen Data Pipeline oder einem ETL-Framework hat die Feature Platform ML-spezifische Semantik. Point-in-Time-Korrektheit heißt, dass ein Trainings-Datensatz die Feature-Werte enthält, die zum Zeitpunkt des historischen Ereignisses gültig waren. Online/Offline-Konsistenz garantiert, dass dieselbe Feature-Definition sowohl im Batch- als auch im Serving-Pfad identische Werte liefert. Latenz-Anforderungen im einstelligen Millisekunden-Bereich für Online-Feature-Serving liegen deutlich unter typischen ETL-Zielen. Diese Eigenschaften machen die Feature Platform zu einer spezialisierten Schicht oberhalb einer generischen Datenpipeline. Sie ergänzt die Pipeline um ML-spezifische Semantik, ohne deren allgemeine Transformations-Aufgaben zu übernehmen.

Innerhalb einer umfassenden ML Platform ist die Feature Platform die feature-spezifische Teilschicht. Sie steht neben Experiment-Tracking (MLflow, Weights & Biases), Model Registry und Model Serving, deckt aber deren Aufgaben nicht ab. Ein Modell wird über die ML Platform trainiert und ausgerollt; die Feature Platform liefert diesem Modell konsistente Eingabewerte zu.

Beispiel: Fraud Detection mit Online- und Offline-Features

Ein E-Commerce-Anbieter betreibt ein Fraud-Detection-Modell mit einer Latenz-Anforderung von unter 100 Millisekunden pro Scoring-Request. Das Modell konsumiert rund 40 Features pro Transaktion: aggregierte Nutzer-Historie über 1 Stunde, 24 Stunden und 30 Tage, Session-Kontext (Anzahl Klicks, Geräte-Fingerprint-Änderungen), Warenkorb-Aggregate (Summe, Kategorie-Verteilung, Preisspanne) und Kreditkarten-Nutzungsprofile.

Die Feature Platform organisiert diese 40 Features in einer zentralen Registry. Jedes Feature ist in Python oder SQL definiert, hat einen Owner, ein Schema und eine Versionsnummer. Ein Streaming-Job berechnet die kurzfristigen Aggregate (1 Stunde, 24 Stunden) kontinuierlich aus dem Klick- und Transaktions-Event-Stream und schreibt sie parallel in zwei Ziele: in eine Delta-Tabelle im Offline-Store für Training und Batch-Analyse und in einen Key-Value-Online-Store für die Millisekunden-Auslieferung im Scoring. Die längerfristigen Aggregate (30 Tage) laufen als täglicher Batch-Job über die historische Ereignistabelle.

Beim Training des Modells führt die Platform einen Point-in-Time-Join durch. Für 500.000 historische Transaktionen aus den vergangenen sechs Monaten werden die Feature-Werte zum jeweiligen Transaktionszeitpunkt zusammengetragen, also die zum damaligen Datum gültigen Zahlen statt der heutigen. Ein Kunde, der vor drei Monaten 12 Bestellungen in seiner Historie hatte, erscheint im Trainings-Datensatz mit genau diesem Wert von damals. Ohne diesen Zeitbezug würde das Modell mit heutigen Feature-Werten auf historische Zielgrößen trainiert und dadurch systematisch überschätzen (Feature-Leak).

Im Produktivbetrieb ruft der Scoring-Service die Feature-Serving-API auf, gibt eine Kunden-ID mit und erhält innerhalb weniger Millisekunden die 40 aktuellen Feature-Werte für diesen Kunden. Die Berechnungslogik ist dieselbe wie im Training, weil beide Pfade auf derselben Feature-Definition in der Registry aufsetzen. Das Feature-Monitoring vergleicht kontinuierlich die Verteilung jedes Features im produktiven Verkehr mit der Trainings-Verteilung. Verschiebt sich zum Beispiel das durchschnittliche Warenkorb-Volumen um mehr als 20 Prozent, meldet das Monitoring einen Drift-Alarm, bevor die Fraud-Erkennungsrate im Betrieb einbricht.