Point-in-Time-Joins im Feature-Store: Training-Serving-Skew technisch ausschalten.

Es gibt einen Fehler im quantitativen Machine Learning, der subtiler ist als Data Leakage und ebenso teuer: Training-Serving-Skew. Das Modell wird auf Feature-Werten trainiert, die das Live-System später nie genau so reproduziert — sei es durch andere Berechnungslogik, andere Aktualisierungszeitpunkte oder schlicht durch Werte, die offline rückblickend, online aber in Echtzeit entstehen. Die Folge: Ein Modell, das im Backtest profitabel aussieht, trifft live systematisch andere Entscheidungen, weil es andere Eingaben sieht. Point-in-Time-Joins im Feature-Store sind die technische Antwort darauf. Sie erzwingen, dass für jeden historischen Zeitpunkt exakt die Feature-Werte zusammengeführt werden, die zu diesem Moment real verfügbar waren — und dass dieselbe Logik offline wie online gilt. Dieser Beitrag erklärt, wie Training-Serving-Skew entsteht, warum naive Joins ihn unbemerkt erzeugen, wie Point-in-Time-Joins ihn technisch ausschalten und wo die Grenzen und Kosten dieser Architektur liegen.

Was Training-Serving-Skew konkret bedeutet.

Training-Serving-Skew bezeichnet die Diskrepanz zwischen den Feature-Werten, mit denen ein Modell trainiert wurde, und denen, die es im Live-Betrieb tatsächlich erhält. Im Trading ist diese Diskrepanz besonders gefährlich, weil schon kleine Abweichungen über Profit oder Verlust entscheiden können.

Ein einfaches Beispiel: Ein Feature ist die durchschnittliche Order-Imbalance der letzten Stunde. Im Backtest wird dieser Wert sauber aus der vollständigen Historie berechnet. Live aber kommen die Daten verzögert an, manche Ticks fehlen, die Berechnung läuft zu einem anderen Taktzeitpunkt. Das Modell sieht einen leicht anderen Wert — und reagiert anders, als es der Backtest vorhergesagt hat.

Das Tückische: Anders als bei Leakage sieht der Backtest hier nicht unbedingt zu gut aus. Er ist einfach inkonsistent mit der Live-Realität. Die Kennzahlen können sogar realistisch wirken, und trotzdem stimmt das, was live passiert, nicht mit ihnen überein. Skew ist deshalb schwer zu diagnostizieren — er versteckt sich in der Lücke zwischen zwei Systemen, die niemand direkt vergleicht.

Warum naive Joins die Zukunft hereinlassen.

Ein Feature-Store hält Feature-Werte über die Zeit vor. Will man Trainingsdaten erzeugen, muss man für jedes Trainingsbeispiel — also für jeden Entscheidungszeitpunkt — die passenden Feature-Werte heranziehen. Genau hier passiert der klassische Fehler.

Ein naiver Join verknüpft einfach den jeweils neuesten verfügbaren Feature-Wert mit jedem Zeitpunkt. Das klingt harmlos, ist aber falsch: Der neueste Wert in der Datenbank kann ein Wert sein, der erst nach dem Entscheidungszeitpunkt entstanden oder korrigiert wurde. Damit fließt Zukunft in die Vergangenheit — Leakage durch die Hintertür.

Ein Point-in-Time-Join löst das, indem er für jeden Zeitpunkt t exakt den Feature-Wert auswählt, der zu t bereits bekannt und gültig war. Technisch ist das ein As-of-Join: Zu jedem Label-Zeitstempel wird der letzte Feature-Eintrag gesucht, dessen Gültigkeits- beziehungsweise Verfügbarkeitszeitpunkt nicht in der Zukunft liegt. Das setzt voraus, dass der Feature-Store nicht nur den Wert speichert, sondern auch, ab wann er real verfügbar war.

Die zwei Zeitachsen, die man trennen muss.

Korrekte Point-in-Time-Joins brauchen ein sauberes Verständnis von zwei unterschiedlichen Zeiten, die in der Praxis ständig vermischt werden:

• Ereigniszeit (event time): Wann ist das Ereignis passiert, auf das sich der Wert bezieht? Etwa der Zeitpunkt eines Trades oder das Ende einer Aggregationsperiode.
• Verfügbarkeitszeit (availability time): Wann war dieser Wert im System tatsächlich abrufbar? Erst dann hätte ein Live-Modell ihn nutzen können.

Der Abstand zwischen beiden ist die Datenlatenz, und sie ist der eigentliche Knackpunkt. Ein Fundamentaldatum bezieht sich vielleicht auf das Quartalsende, wird aber erst Wochen später veröffentlicht. Ein berechnetes Feature bezieht sich auf den Schlusskurs, steht aber erst nach Verarbeitung zur Verfügung. Wer im Join die Verfügbarkeitszeit ignoriert und nur die Ereigniszeit nutzt, baut Leckagen ein, die im Live-Betrieb sofort auffallen — weil die Werte dort schlicht noch nicht da sind.

Ein guter Feature-Store macht die Verfügbarkeitszeit zur erstklassigen Eigenschaft jedes Eintrags und nutzt ausschließlich sie für die Join-Logik. Das ist konzeptionell einfach und in der Implementierung trotzdem leicht zu vergessen.

Eine Logik für Offline und Online.

Der zweite Hebel gegen Skew ist, dass dieselbe Feature-Berechnung sowohl die Trainingsdaten als auch die Live-Werte erzeugt. Wenn das Offline-Training eine Pandas-Pipeline nutzt und das Live-System dieselbe Logik in einer anderen Sprache neu implementiert, entstehen fast unweigerlich Abweichungen — gerundete Werte, andere Behandlung von Lücken, abweichende Fensterränder.

Moderne Feature-Stores adressieren das, indem die Transformationslogik einmal definiert und sowohl im Batch (für Trainingsdaten) als auch im Streaming (für Live-Inferenz) ausgeführt wird. Im Idealfall ist es derselbe Code. Wo das nicht möglich ist, braucht es zumindest automatisierte Konsistenztests, die regelmäßig prüfen, ob beide Pfade für identische Eingaben identische Ausgaben liefern.

In der Trading-Praxis ist die vollständige Vereinheitlichung anspruchsvoll, weil die Anforderungen unterschiedlich sind: Batch optimiert auf Durchsatz über Jahre an Daten, Streaming auf niedrige Latenz pro Tick. Ein realistischer Mittelweg ist, die fachliche Transformationslogik in einer gemeinsamen, gut getesteten Bibliothek zu kapseln, die beide Pfade aufrufen — statt zwei voneinander unabhängige Implementierungen zu pflegen.

Wo ein Feature-Store sich lohnt und wo nicht.

Ein Feature-Store mit Point-in-Time-Joins ist Infrastruktur, und Infrastruktur kostet. Die ehrliche Frage ist, ab wann sich der Aufwand rechnet:

Für eine einzelne Strategie in der Forschungsphase ist ein voller Feature-Store häufig überdimensioniert — eine disziplinierte As-of-Join-Logik in der bestehenden Pipeline reicht. Sobald aber mehrere Modelle dieselben Features nutzen, mehrere Personen am System arbeiten oder Live-Inferenz mit niedriger Latenz gefragt ist, kippt die Rechnung. Dann verhindert der Feature-Store, dass jedes Team seine eigene, leicht abweichende Feature-Definition pflegt.

Grenzen, Kosten und der ehrliche Aufwand.

Ein Feature-Store ist kein Selbstläufer. Die Einrichtung kostet Zeit, die Pflege bindet Ressourcen, und falsch aufgesetzt verlagert er das Problem nur. Ein Point-in-Time-Join ist außerdem rechenintensiv: As-of-Joins über Millionen von Zeitstempeln und hunderte Features sind aufwendiger als einfache Verknüpfungen, und die Generierung großer Trainings-Datensätze kann von Minuten auf Stunden wachsen.

Realistisch liegt die initiale Einrichtung eines schlanken Feature-Stores für einen Trading-Stack im Bereich mehrerer Wochen Entwicklungsaufwand, abhängig davon, ob man auf eine bestehende Lösung aufsetzt oder selbst baut. Der laufende Betrieb erfordert Monitoring, denn ein Feature-Store, der falsche Verfügbarkeitszeiten speichert, ist schlimmer als keiner — er erzeugt falsches Vertrauen.

Die wichtigste Grenze ist konzeptioneller Natur: Ein Feature-Store macht die Feature-Erzeugung konsistent und reproduzierbar, aber er macht die Features nicht besser. Wer schlechte Features sauber serviert, hat sauber servierte schlechte Features. Der Wert liegt darin, dass man dem Backtest trauen kann — nicht darin, dass die Strategie automatisch profitabel wird. Diese Erwartung sollte man von Anfang an klar haben.

Sie wollen Gewissheit, dass Ihr Live-Trading-System genau die Feature-Werte sieht, mit denen das Modell trainiert wurde — ohne stillen Training-Serving-Skew? Unverbindlich anfragen — wir analysieren gemeinsam Ihre Feature-Pipeline, die Join-Logik und die Konsistenz zwischen Offline und Online und zeigen, ob ein Feature-Store für Ihren Stack der richtige Schritt ist.