Welches Problem löst ein Feature Store, das du nicht mit einer guten Datenpipeline lösen kannst?

Es löst die Konsistenz zwischen Training und Serving. Dasselbe Feature muss fürs Training aus Batch-Historie und fürs Serving aus frischen Daten mit niedriger Latenz berechnet werden, und wenn das zwei getrennte Implementierungen sind, driften sie auseinander. Ein Feature Store definiert ein Feature einmal, materialisiert es in einen Offline Store für Point-in-time-korrekte Trainingsdaten und in einen Online Store für Lookups im Millisekundenbereich, und liefert Point-in-time-korrekte Joins.

Das Problem ist, dass dasselbe Feature zwei Leben hat. Fürs Training brauche ich seinen Wert zu einem historischen Zeitpunkt, gejoint, ohne aus Versehen etwas mitzunehmen, das danach passiert ist. Fürs Serving brauche ich es jetzt sofort, in unter zehn Millisekunden, keyed nach Entity. Wenn das zwei Codebasen sind, und es fängt immer als zwei Codebasen an, driften sie. Jemand ändert im Trainingsjob ein Fenster von dreißig auf achtundzwanzig Tage, niemand fasst den Serving-Pfad an, und jetzt scort das Modell gegen Features, auf denen es nie trainiert wurde. Diese Drift ist still, und genau das macht sie teuer. Ein Feature Store gibt dir eine Definition, die sowohl in eine Offline-Tabelle fürs Training als auch in einen Online-Key-Value-Store fürs Serving materialisiert, dazu Point-in-time-Joins, damit die historische Abfrage die Zukunft nicht durchsickern lassen kann. Trotzdem würde ich für ein Team mit zwei Modellen keinen aufsetzen. Der Overhead ist real, und den größten Teil des Nutzens bekommst du aus einer geteilten Transformationsbibliothek plus einem geplanten Job, der in einen Cache schreibt. Zu einem Managed Feature Store greife ich, sobald mehrere Teams Features teilen, weil sich dann doppelte Definitionen zu vermehren beginnen.