Real-Time ML (kurz für Real-Time Machine Learning, also „Maschinelles Lernen in Echtzeit") bezeichnet die Ausführung eines fertig trainierten Vorhersage-Modells auf ein einzelnes Ereignis mit sehr kurzer Antwortzeit, typischerweise Millisekunden bis wenige Sekunden. Der Ansatz verbindet zwei Bausteine: laufend berechnete Merkmale aus einem Ereignisstrom (Streaming-Features, im Sekundentakt aktualisierte Kennzahlen je Kunde, Konto oder Gerät) und eine direkt beantwortete Modell-Anfrage über eine Online-Schnittstelle (Model Serving, ein aufrufbarer Endpunkt für einzelne Vorhersagen).
Was ist Real-Time ML?
Ein Ereignis trifft ein, etwa eine Karten-Zahlung, ein Seitenaufruf oder ein Sensor-Wert. Das System liest die zum Ereignis passenden Merkmale aus einem Online-Feature-Store (einem schnellen Speicher, der aktuelle Merkmale je Kunde, Gerät oder Konto in wenigen Millisekunden ausliefert), ruft ein Modell hinter einem Online-Endpunkt (einer aufrufbaren Schnittstelle für einzelne Vorhersagen) auf und gibt die Vorhersage direkt an den Aufrufer zurück. Die Ziel-Antwortzeit reicht je nach Anwendungsfall von rund zehn Millisekunden (Ad-Bidding, also Werbeplatz-Auktionen im Bruchteil einer Sekunde) bis zu wenigen Sekunden (Kundendialog). Klassisches Batch-ML (Vorhersagen im Stapel, nicht pro Ereignis) rechnet den gleichen Vorhersage-Wert dagegen einmal pro Nacht über alle Kunden und legt das Ergebnis in einer Tabelle ab, die am nächsten Morgen im Kundensystem sichtbar ist.
Der Begriff hat sich als eigene Kategorie etabliert, weil er zwei getrennte Bausteine bündelt, die beide für die niedrige Latenz gebraucht werden. Der erste Baustein ist die Feature-Berechnung im Streaming: Aggregate über gleitende Zeitfenster („Anzahl Zahlungen dieses Kontos in den letzten 60 Sekunden"), Change-Data-Capture-basierte Aktualisierung von Stammdaten (jede Änderung im Quellsystem fließt sofort in den Feature-Store) und der Online-Feature-Store als schneller Nachschlage-Speicher. Der zweite Baustein ist die Modell-Inferenz per Online-Endpunkt: eine Model-Serving-Plattform mit Autoscaling, Traffic-Routing und Versionierung, hinter der das trainierte Modell läuft. Beide Bausteine zusammen ergeben Real-Time ML; ein einzelner reicht nicht aus.
Der entscheidende Trade-off in Real-Time-ML-Architekturen ist selten die reine Modell-Antwortzeit. Model Serving liefert Antwortzeiten unter 100 Millisekunden für viele Modellklassen. Kritisch sind Frische und Konsistenz der Merkmale: Ein Modell, das in 50 Millisekunden antwortet, aber mit Merkmalen aus dem gestrigen Stand rechnet, ist keine Real-Time-Lösung. Zusätzlich müssen die Feature-Definitionen im Training exakt so berechnet werden wie im Online-Betrieb, sonst weichen Trainings- und Betriebsverteilung auseinander (Online-/Offline-Skew). Der Feature-Store übernimmt dafür beide Zweige: den Offline-Zweig für das Training und den Online-Zweig für die Live-Inferenz, aus einer gemeinsamen Definition.
Terminologisch wird „Online ML" häufig als Synonym verwendet. In der engeren Fachlesart bezeichnet Online ML jedoch das kontinuierliche Weiter-Trainieren eines Modells im Betrieb (Online Learning). Real-Time ML im hier verwendeten Sinne bezieht sich auf die Inferenz-Seite mit frischen Features, nicht auf laufendes Nachtrainieren aus dem eigenen Output.
Abgrenzung: Batch ML, Model Serving, Streaming Analytics, Real-Time Analytics, Reinforcement Learning
Real-Time ML wird häufig mit Nachbarbegriffen vermischt, die eine Ebene tiefer oder auf einer ganz anderen Achse liegen. Die wichtigsten Abgrenzungen:
| Nachbar-Begriff | Verhältnis zu Real-Time ML |
|---|---|
| Batch ML / Batch-Inferenz | Modell läuft periodisch (nächtlich, stündlich) über einen abgeschlossenen Datensatz, Ergebnisse landen gesammelt in einer Tabelle. Kein wartender Aufrufer, keine Latenz-SLA pro Anfrage. Real-Time ML rechnet pro Ereignis synchron. |
| Model Serving | Deployment-Ebene für synchrone Modell-Aufrufe. Notwendige Voraussetzung, deckt aber nur die Inferenz-Seite ab. Real-Time ML ist Model Serving plus Streaming-Feature-Berechnung plus Online-Feature-Store. |
| Streaming Analytics | Analytische Kennzahlen (Umsatz pro Minute, aktive Nutzer, Fehlerrate) auf kontinuierlichen Ereignisströmen, ohne Modell-Vorhersage. Fasst Daten zusammen. Real-Time ML trifft eine Modell-Entscheidung pro Ereignis. |
| Real-Time Analytics | Analytische Query-Latenz auf einer OLAP-Engine (Druid, Pinot, ClickHouse, Lakehouse mit Photon). Antwort auf eine analytische Frage in Sekunden statt Minuten, ohne ML. |
| Reinforcement Learning | Modell lernt kontinuierlich aus Umgebungs-Feedback und passt seine Strategie an. Real-Time ML nutzt in der Regel ein statisches, offline trainiertes Modell und tauscht es über Registry-Deployments aus. |
Beispiel: Betrugserkennung im Zahlungsverkehr
Ein Zahlungsdienstleister entscheidet pro Karten-Transaktion in unter 300 Millisekunden, ob sie freigegeben, zur Prüfung markiert oder abgelehnt wird. Ein Streaming-Job aggregiert pro Karte laufend die letzten Sekunden (Anzahl der Transaktionen, Beträge, Länder, Geräte-IDs) in einen Online-Feature-Store. Trifft eine neue Transaktion ein, ruft das Anti-Fraud-System einen Online-Endpunkt auf. Der Endpunkt erhält die aktuelle Transaktion plus die aggregierten Merkmale, ein Klassifikationsmodell (etwa ein Gradient-Boosting-Modell oder ein neuronales Netz) berechnet einen Betrugs-Score, und die Antwort geht synchron zurück an das Zahlungssystem.
Die gleichen Feature-Definitionen laufen offline auf dem Lakehouse, wenn das Modell neu trainiert wird. Beide Zweige greifen auf die gleiche Berechnungslogik im Feature-Store zu, damit sich Trainings- und Betriebsverteilung nicht auseinanderentwickeln. Weitere typische Anwendungsfelder folgen demselben Muster: Empfehlungen zur Session-Laufzeit im E-Commerce, dynamische Preise, Ad-Bidding, IoT-Anomalie-Erkennung und Next-Best-Action-Entscheidungen im Kundendialog.
Real-Time ML im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.
Entscheidungs-Frame Feature-Frische, Latenz-Ziele, Online-/Offline-Konsistenz
Model ServingDeployment-Ebene für die synchrone Modell-Antwort
Feature StoreOnline- und Offline-Zweig für Trainings-/Serving-Konsistenz
DatenstreamingStreaming-Fundament für laufend aktualisierte Features
Streaming Analyticsanalytische Kennzahlen auf Ereignisströmen ohne Modell
Real-Time Analyticsanalytische Query-Latenz als Nachbarkategorie ohne ML
Batch-InferenzBetriebsform ohne wartenden Aufrufer als Gegenstück
Reinforcement Learningkontinuierliches Lernen aus Feedback als andere Achse