Was ist ein Feature Store und wann braucht man einen?
Direkte Antwort
Ein Feature Store ist eine zentrale Infrastruktur, die Feature-Berechnungslogik einmal definiert und sowohl für das Modelltraining (Batch, historische Daten) als auch für die Live-Inferenz (niedrige Latenz, aktuelle Werte) konsistent bereitstellt. Er lohnt sich, sobald mehrere Modelle oder Teams dieselben Features wiederverwenden oder Training-Serving-Skew ein wiederkehrendes Problem ist.
"Ein Feature Store löst kein Modellierungsproblem, sondern ein Organisationsproblem — dieselbe Definition eines Merkmals soll überall dieselbe sein.
In vielen ML-Projekten wird dieselbe fachliche Kennzahl, etwa "Anzahl Bestellungen der letzten 30 Tage", mehrfach unabhängig voneinander implementiert — einmal für das Training, einmal für die Produktion, mit dem Risiko subtiler Abweichungen.
Das Problem doppelter Feature-Implementierungen
Ohne zentrale Infrastruktur berechnet ein Data-Science-Team ein Feature für das Training oft in einem Python-Batch-Job auf historischen Daten, während ein Engineering-Team dieselbe Kennzahl für die Live-Inferenz erneut implementiert, meist in einer anderen Sprache oder mit anderer Logik.
Kleine Unterschiede, etwa ein anderer Zeitzonen-Umgang oder eine leicht abweichende Filterlogik, führen zu Training-Serving-Skew, der schwer zu diagnostizieren ist, weil beide Implementierungen für sich genommen korrekt aussehen.
Was ein Feature Store konkret bereitstellt
Ein Feature Store definiert Features einmal zentral und stellt zwei Zugriffspfade bereit — einen Offline-Store für historische Batch-Daten zum Training und einen Online-Store mit niedriger Latenz für Live-Vorhersagen, beide gespeist aus derselben Berechnungslogik.
Tools wie Feast oder Tecton übernehmen diese Synchronisation und stellen sicher, dass ein Feature zum Trainingszeitpunkt und zum Inferenzzeitpunkt exakt gleich berechnet wird.
Wann sich der zusätzliche Infrastrukturaufwand lohnt
Für ein einzelnes Modell mit wenigen, einfachen Features ist ein Feature Store meist überdimensioniert — der Mehraufwand rechnet sich erst, wenn mehrere Modelle oder Teams dieselben Features teilen oder Training-Serving-Skew bereits nachweislich zu Produktionsproblemen geführt hat.
Ein pragmatischer Zwischenschritt ist, Feature-Berechnungslogik zumindest in einer gemeinsam genutzten Code-Bibliothek zu bündeln, bevor die volle Feature-Store-Infrastruktur eingeführt wird.
Wann passt es — wann nicht?
Passt gut
- ✓Mehrere Modelle oder Teams nutzen dieselben oder ähnliche Features
- ✓Training-Serving-Skew ist bereits als konkretes Problem aufgetreten
Passt nicht
- ✗Es gibt ein einzelnes Modell mit wenigen, einfachen Features und einem kleinen Team