Real-Time Machine Learning auf Databricks: Warum Feature-Frische entscheidet
Die Kernaussagen auf einen Blick.
- Real-Time Machine Learning scheitert am häufigsten an veralteten Features und an Feature-Definitionen, die im Training anders berechnet werden als im Serving. Schnelle Modellantworten allein helfen wenig, wenn die Eingaben nicht stimmen.
- Nicht jedes Feature im Modell braucht Echtzeit. Streaming, Batch und On-Demand sind drei getrennte Pfade, und welcher Pfad für welches Feature passt, ist die wichtigste Architekturentscheidung.
- Vor dem nächsten Use Case sollten drei Punkte stehen: Latenz-Ziele für p50 und p99, eine laufende Messung der Online-/Offline-Konsistenz und eine klare Verantwortung für die Streaming-Pipeline im Störungsfall.
- Für Fraud, Personalisierung oder Pricing reicht die Lakehouse-Plattform mit Online Tables, Feature Store und Mosaic AI Model Serving in den meisten Fällen aus. Ein separater Streaming-Stack mit Kafka oder Flink lohnt erst, wenn der Use Case Latenzen unter einer Millisekunde verlangt.
Inhaltsverzeichnis
Feature-Frische schlägt Antwortzeit
In vielen Real-Time-ML-Reviews zeigt sich dasselbe Muster. Das Modell ist produktiv im Einsatz. Der Serving-Endpunkt antwortet in weniger als 100 Millisekunden. Durchsatz und Fehlerrate sehen im Monitoring gut aus. Trotzdem trifft das Modell im Betrieb schlechtere Entscheidungen als im Test.
Die Ursache liegt fast immer bei den Eingabedaten. Ein Personalisierungsmodell nutzt eine Kennzahl aus einer Streaming-Pipeline, die bei hoher Last 90 Sekunden hinterherläuft. Ein Fraud-Modell bekommt ein Feature, das im Training anders berechnet wurde als im Serving. Ein Pricing-Modell läuft im Test sauber, liefert im echten Checkout aber schlechtere Margen.
Das eigentliche Real-Time-ML-Problem entsteht damit in der Feature-Pipeline. Im Monitoring wird es trotzdem über die Antwortzeiten des Modells sichtbar und führt dort regelmäßig zu einer falschen Diagnose.
Vor dem nächsten Modell-Rollout sollten deshalb diese Fragen geklärt werden:
Feature-Aktualität
Welche Features müssen laufend aktualisiert werden, und welche reichen aus einem regelmäßigen Batch?
Training-Serving-Konsistenz
Wie stellen wir sicher, dass Training und produktiver Betrieb dieselben Feature-Werte verwenden?
Antwortzeit-Ziel
Welche Antwortzeit muss der Anwendungsfall wirklich einhalten, und wird sie End-to-End gemessen?
Incident-Ownership
Wer reagiert, wenn die Streaming-Pipeline nachts ausfällt: Plattform-Team oder ML-Team?
Plattform-Fit
Reicht die bestehende Lakehouse-Plattform, oder braucht der Use Case eine separate Streaming-Architektur?
Solange diese Punkte offen sind, kann Real-Time-ML im Dashboard stabil wirken und im Betrieb trotzdem ausfallen.
Was ist Real-Time-ML? Antwortzeit und Feature-Frische getrennt betrachtet
Real-Time-ML ist ein Betriebsmodell, in dem ein Modell einzelne Anfragen direkt beantwortet und dabei Features nutzt, die innerhalb eines definierten Zeitfensters aktuell gehalten werden. Entscheidend ist zuerst die Aktualität dieser Features. Die Modellantwortzeit ist nur ein Teil der Gesamtentscheidung.
Verwechslungsgefahr besteht mit zwei verwandten Begriffen. Online-ML bedeutet im engeren Sinn, dass das Modell während des Betriebs weiterlernt: die Inferenz ist online, das Training ebenfalls. Continual Learning verfolgt ein ähnliches Ziel, arbeitet aber mit kontrollierten Aktualisierungen und einer Bewertung jeder neuen Modellversion. Beide Disziplinen sind deutlich komplexer als Real-Time-ML und sollten nicht damit verwechselt werden. In den meisten operativen Use Cases bleibt das Modell stabil; aktuell gehalten werden vor allem die Features.
Praktisch lassen sich drei Klassen unterscheiden:
| Klasse | End-to-End-Latenz | Feature-Frische | Typische Architektur |
|---|---|---|---|
| Online / Streaming | sehr schnelle End-to-End-Antwortzeiten, zum Beispiel p99 unter 200 Millisekunden | Features müssen innerhalb weniger Sekunden aktuell sein | Online-Store mit laufenden Aktualisierungen, Features, die während der Anfrage berechnet werden |
| Near Real-Time | Antwortzeit im Sekundenbereich, zum Beispiel p99 unter 5 Sekunden | Features dürfen wenige Minuten alt sein | Streaming-Pipeline mit kurzen Mikrobatches, Online-Store als schneller Zwischenspeicher |
| Batch | Aktualisierung im Minuten- bis Stundenbereich | Stunden bis Tag | klassische Datenpipeline mit regelmäßig aktualisierten Feature-Tabellen |
Die gewählte Klasse bestimmt Aufwand, Kosten, Architektur und Verantwortlichkeiten. Sie ergibt sich aus dem Use Case und aus dem fachlichen Wert einer schnelleren Reaktion, nicht aus dem Modell oder dem eingesetzten Tool.
Eine Fraud-Prüfung während einer Kartenzahlung muss extrem schnell antworten, sonst wird der Bezahlvorgang gestört. Eine Produktempfehlung auf einer Listing-Seite darf meist etwas länger dauern; Features im Minutenbereich können dort oft ausreichen, weil sich Nutzerverhalten in dem Fenster ohnehin nicht stark verschiebt. Pricing am Checkout liegt dazwischen.
Wenn diese Klassen früh geklärt werden, wird nur so viel Echtzeit gebaut, wie der Anwendungsfall wirklich braucht. Ohne diese Klärung wird oft überall Sub-Sekunden-Streaming eingeplant. Das erhöht Komplexität, Kosten und Betriebsaufwand unnötig. Im AI-Pillar auf Databricks zeigen wir den Gesamtrahmen im Überblick zu Artificial Intelligence auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Streaming, Batch oder On-Demand Features?
Die Architektur hängt vor allem von einer Frage ab: woher die Features im Moment der Modellanfrage kommen. Auf Databricks gibt es dafür drei Klassen, die sich klar trennen lassen.
Streaming-Features
Werden laufend aus neuen Ereignissen berechnet und in einem schnellen Online-Store bereitgestellt. Beispiele sind Kennzahlen über kurze Zeitfenster: Klicks pro Session, Transaktionen pro Karte und Stunde oder aktuelle Aktivität eines Nutzers. Der Modellendpunkt ruft diese Werte während der Anfrage ab.
Batch-Features
Werden regelmäßig in bestehenden Datenpipelines berechnet (zum Beispiel nachts oder stündlich) und über den Feature Store zugänglich gemacht. Beispiele sind Kundenwert, RFM-Score oder Produktsegment. Diese Werte in eine Streaming-Pipeline zu verschieben, bringt meist wenig Nutzen.
On-Demand-Features
Werden direkt während der Anfrage berechnet, aus Informationen, die bereits in der Anfrage enthalten sind: zum Beispiel Entfernungen oder Zeitabstände seit dem letzten Ereignis. Dafür braucht es keinen separaten Online-Store, die Berechnung muss aber in Training und Serving identisch definiert sein.
Die Streaming-Berechnung läuft in Spark Structured Streaming oder in einer Lakeflow Declarative Pipeline.
Die Entscheidung folgt einer einfachen Logik:
| Frage | Streaming-Feature | Batch-Feature | On-Demand-Feature |
|---|---|---|---|
| Wann ändert sich der Wert fachlich relevant? | Sekunden bis Minuten | Stunden bis Tage | direkt in der Anfrage |
| Wo wird gerechnet? | im Streaming-Job, vor dem Online-Store | in der Batch-Pipeline | im Serving-Pfad zur Inferenz |
| Online-/Offline-Konsistenz | muss gemessen werden: Trainings-Lauf braucht denselben Berechnungs-Pfad | weniger kritisch, weil Trainings- und Inferenz-Wert aus derselben Tabelle kommen | muss gemessen werden: die Funktion muss in Training und Inferenz identisch sein |
| Kosten- und Betriebsprofil | hoch, weil der Streaming-Job 24/7 läuft und der Online-Store pro Lookup kostet | niedrig, mit bekannten Pipelines und ohne neues Betriebsmodell | niedrig, ohne Pipeline, dafür mit Test-Pflicht der Funktion |
| Typische Use-Cases | Verhaltens-Aggregate, Live-Counter, Session-Metriken | Stammdaten, Lifetime-Werte, Segment-Zuordnungen | Distanzen, Zeitdifferenzen, Request-abgeleitete Werte |
Wichtig ist, jedes Feature einzeln zu bewerten. Ein Personalisierungsmodell nutzt häufig Streaming-, Batch- und On-Demand-Features parallel. Alle Features zu streamen, nur weil der Use Case Real-Time heißt, erzeugt unnötige Komplexität. Werden alle im Batch berechnet, fehlt dem Modell die benötigte Aktualität.
Diese Feature-Einteilung ist die wichtigste praktische Entscheidung im Real-Time-ML-Design. Wie der Feature Store als Plattform-Komponente die drei Klassen verbindet, zeigen wir im Überblick zum Feature Store auf Databricks.
Wie vermeidet man Training-Serving-Skew?
Online-/Offline-Konsistenz bedeutet hier, dass das Modell im produktiven Betrieb Feature-Werte nach derselben Logik sieht wie im Training. Wird das nicht laufend gemessen, sinkt die Modellqualität im Betrieb schleichend, ohne dass ein technischer Fehler angezeigt wird. Dieses Risiko trägt den Namen Training-Serving-Skew.
Operativ entstehen daraus drei Anforderungen an die Plattform.
Einmalige Feature-Definition
Eine Feature-Definition sollte nur einmal verbindlich gepflegt werden, etwa in einer Streaming-Pipeline oder als Feature-Spec, und im Training wie im Online-Store nach derselben Logik laufen. Unterschiedliche Berechnung beidseitig erzeugt einen Fehler, der im Monitoring oft monatelang unentdeckt bleibt.
Historisch korrekte Trainingswerte
Das Training muss genau die Feature-Werte verwenden, die zum Zeitpunkt des damaligen Ereignisses bekannt waren. Auf Databricks läuft das über Point-in-Time-Lookups gegen die Feature-Tabelle. Wird der Schritt übersprungen, wirken Testergebnisse besser, als das Modell im Betrieb tatsächlich ist.
Laufender Serving-Offline-Vergleich
Die im Serving verwendeten Feature-Werte werden regelmäßig mit den offline berechneten Referenzwerten verglichen, mit klaren Grenzwerten für Abweichungen. Lakehouse Monitoring richtet diese Vergleichspipeline ein, sobald Online- und Offline-Werte in Unity-Catalog-Tabellen landen.
Auf derselben Pipeline lassen sich zusätzlich Feature-Drift gegenüber der Trainingsverteilung und Drift in den Modellantworten überwachen, jeweils mit eigenen Alertschwellen. Konsistenz wird dadurch zu einer überwachten Betriebskennzahl.
Genau an dieser Stelle wird ein separater Streaming-Stack neben dem Lake oft teurer als geplant. Wenn Trainings- und Online-Pfad in zwei Plattformwelten leben, muss die Konsistenzmessung beide Welten zusammenführen: Daten aus dem Lake, Daten aus dem Online-Store, alles in eine gemeinsame Vergleichs-Tabelle. Auf der Lakehouse-Plattform bleibt diese Messung in einer einzigen Governance-Domäne mit Unity Catalog als gemeinsamer Grundlage.
Databricks Online Tables und Mosaic AI Model Serving im Real-Time-ML-Stack
Damit ein Modell wirklich online arbeiten kann, braucht es zwei zentrale Bausteine: einen Online-Store für schnelle Feature-Abfragen und einen Modellendpunkt, der die Anfrage annimmt, Features ergänzt und das Modell ausführt.
Auf Databricks fügen sich diese Bausteine in eine Linie ein:
- Der Feature Store bleibt die zentrale Quelle für Feature-Definitionen im Lakehouse. Feature-Definitionen werden über Unity Catalog verwaltet und sind die Quelle für Training und Inferenz.
- Databricks Online Tables stellen ausgewählte Feature-Tabellen für schnelle Abfragen bereit, in einer für schnelle Lookups optimierten Schicht, die pro Lookup sehr niedrige Latenzen ermöglicht. Aktualisierungen kommen aus Streaming-Pipelines oder inkrementellen Aktualisierungen.
- Mosaic AI Model Serving stellt den Modellendpunkt bereit, hält das Modell aus der MLflow Model Registry und reichert Anfragen aus Online Tables oder On-Demand-Funktionen an. Feature-Lookups laufen im gleichen Serving-Pfad. Die aufrufende Anwendung sendet nur die benötigten IDs. Die Features werden im Serving-Pfad ergänzt.
- Lakehouse Monitoring beobachtet Drift in Features und Modell-Output, gegen die Trainings-Verteilung als Referenz.
Von der Foundation nach oben gliedert sich der Stack in fünf Schichten: Speicher mit Delta Lake, Pipelines mit Spark Structured Streaming und Lakeflow, Features mit Feature Store und Online Tables, Modell und Serving mit MLflow und Mosaic AI Model Serving sowie Observability mit Lakehouse Monitoring als oberste Cross-Cutting-Schicht. Unity Catalog läuft als Governance-Spine durch alle Schichten hindurch.
Diese Architektur hält Training, Features, Serving und Monitoring in einer gemeinsamen Plattformlinie. Ein zusätzlicher Streaming-Stack neben dem Lakehouse, etwa mit Kafka, Flink und Redis oder Cassandra kann bei extremen Antwortzeit-Anforderungen schneller sein, erzeugt aber zusätzliche Governance-, Berechtigungs- und Audit-Aufwände sowie eine Integrationsbrücke, die dauerhaft betrieben werden muss.
Die Grenzen liegen vor allem bei extremen Latenzanforderungen: Antwortzeiten unter einer Millisekunde, zum Beispiel algorithmisches Trading oder Paketanalysen im Netzwerk, bedienen spezialisierte Streaming-Stacks weiterhin besser. Für viele operative Use Cases wie Fraud, Personalisierung, Pricing, Recommendations oder Churn Scoring reicht der Lakehouse-Ansatz häufig aus. Wie die zugehörige niedriglatente Engine im Lake selbst aussieht, zeigen wir im Überblick zu Lakehouse-RT auf Databricks.
Fraud Detection, Personalisierung und Dynamic Pricing
Damit die Architekturentscheidung konkreter wird, helfen drei typische Profile mit jeweils anderem Latenz- und Feature-Mix.
Fraud Detection bei Kartenzahlungen
End-to-End-Latenz unter 100 Millisekunden. Streaming-Features für aktuelle Transaktionsmuster, Batch für Karten- und Händlerstammdaten, On-Demand für Zeitabstände seit der letzten Transaktion. Serving über Mosaic AI Model Serving mit niedriglatentem Lookup. Jede Verzögerung in den Streaming-Features schwächt den Score, ohne in der Endpoint-Latenz sichtbar zu werden.
Personalisierung auf der Listing-Seite
p99 unter 200 Millisekunden, Features im Minutenbereich reichen meist aus. Streaming für aktuelle Session-Kennzahlen, Batch für Produkt-Stammdaten und Kunden-Segmente, On-Demand für Sortier-Distanzen. Die Lakehouse-Architektur trägt hier häufig ohne zusätzliche Spezialplattform.
Dynamic Pricing im Checkout
p99 unter 300 Millisekunden. Streaming für aktuelle Nachfragekennzahlen, Batch für Marge, Bestand und kaufmännische Regeln, On-Demand für die konkrete Checkout-Situation. Pricing-Entscheidungen müssen später nachvollziehbar sein: der Online-Pfad sollte die verwendeten Feature-Werte protokollieren.
Die drei Profile zeigen dieselbe Grundlogik mit drei verschiedenen Latenz-Klassen und Feature-Mischungen. Die technischen Bausteine bleiben ähnlich. Unterschiedlich ist vor allem, welche Features wie aktuell sein müssen.
Real-Time-ML vs Model Serving vs Lakehouse-RT
Real-Time-ML wird häufig mit Model Serving oder Lakehouse-RT verwechselt.
Model Serving bedeutet zunächst nur, ein Modell über einen Endpunkt verfügbar zu machen, unabhängig davon, ob Anfragen einzeln oder gesammelt verarbeitet werden und wie aktuell die verwendeten Features sind. Mosaic AI Model Serving deckt diese Disziplin auf Databricks ab und bildet die Grundlage für Real-Time-ML. Damit aus einem Endpunkt ein Real-Time-ML-Use-Case wird, müssen zusätzlich die Features zur Anforderung passend aktuell sein. Wie der Serving-Pfad als eigene Disziplin aufgebaut wird, zeigen wir im Überblick zu Model Serving auf Databricks.
Lakehouse-RT beschreibt schnelle Abfragen direkt auf Lakehouse-Tabellen: Aggregationen und gezielte Lookups, ohne dass dafür ein separates OLTP-System gebaut werden muss. Für Real-Time-ML kann Lakehouse-RT ein wichtiger Plattformbaustein sein. Modellendpunkt und Online-Feature-Abfrage bleiben dabei eigene Bausteine.
Das Verhältnis wird klarer, wenn die Frage in den Vordergrund rückt, welche Engine welche Latenz-Klasse trägt. Online Tables und Mosaic AI Model Serving bedienen den Online-Pfad mit Lookups in einstelligen Millisekunden. Lakehouse-RT hilft bei schnellen Lakehouse-Abfragen und Near-Real-Time-Szenarien. SQL Warehouses bleiben stark für Reporting, Analyse und Batch-nahe Workloads. Die drei Bausteine sind komplementär und sollten in dieser Rollenverteilung eingesetzt werden.
Damit lösen sich zwei verbreitete Fehlannahmen auf. Lakehouse-RT alleine ergibt noch kein Real-Time-ML. Und ein schneller Modellendpunkt ohne frische Features bleibt Model Serving.
Woran scheitert Real-Time-ML im Betrieb?
Die Schwächen von Real-Time-ML zeigen sich häufig erst nach dem Go-live. Dann treffen Annahmen aus dem Pilot auf echte Last, echte Fehler und echte Betriebsprozesse. Die meisten Probleme entstehen dabei außerhalb des Modells.
Typisch ist der stille Ausfall der Streaming-Pipeline. Das Modell antwortet weiter, weiß aber nicht, dass die Eingabedaten veraltet sind. Ohne klare Eskalationskette und ohne automatische Erkennung veralteter Feature-Werte landet das Ticket beim Verantwortlichen für den Modellendpunkt, obwohl dieser die Pipeline weder betreibt noch reparieren darf. Ähnlich heikel sind Pipeline-Neustarts. Spark Structured Streaming kann mit Checkpoints und Watermarks kontrolliert neu starten und verspätete Daten behandeln (Watermarks für Late-Data-Toleranz). Checkpoints halten den Verarbeitungs-Stand persistent, sodass die Pipeline nach einem Crash genau dort weiterläuft, wo sie unterbrochen wurde. Watermarks definieren, wie lange späte Events berücksichtigt werden dürfen, und schließen Fenster zu einem deterministischen Zeitpunkt. Wenn diese Mechanik nicht sauber konfiguriert ist, entstehen nach Neustarts falsche oder doppelte Aggregate. Im Pilot fällt das selten auf, im Produktivbetrieb wird es zum Qualitätsrisiko.
Die Probleme entstehen nicht aus fehlenden Tools. Es sind organisatorische Lücken, die auf einer Lakehouse-Plattform leichter zu schließen sind als auf zwei getrennten Stacks, weil Feature-Definition, Online-Store, Endpoint und Monitoring im selben Governance-Modell laufen.
Grenzen von Real-Time Machine Learning auf Databricks
Die Lakehouse-Linie aus Online Tables, Mosaic AI Model Serving und Feature Store trägt die operative Mehrheit der Real-Time-ML-Anwendungsfälle. In einigen Szenarien stößt die Plattform jedoch an klare Grenzen, und ein spezialisierter Streaming-Stack bleibt die bessere Antwort.
Sub-Millisekunden-Latenz
Algorithmischer Hochfrequenzhandel, In-Network-Paketanalyse oder hardware-nahe Steuerungssysteme verlangen End-to-End-Antwortzeiten unter einer Millisekunde. Online Tables und Mosaic AI Model Serving bewegen sich im einstelligen bis zweistelligen Millisekundenbereich pro Lookup, nicht gebaut für Tickets im Mikrosekundenbereich. Solche Anforderungen brauchen eine spezialisierte In-Memory-Engine, der Rest der ML-Plattform kann im Lakehouse bleiben.
Replikationszeit in den Online-Store
Online Tables spiegeln Feature-Tabellen aus dem Lakehouse asynchron in den Online-Store; je nach Last und Konfiguration liegen dazwischen Sekunden bis kurze Minuten. Aggregate, die sich innerhalb von Millisekunden ändern müssen, sind damit nicht abgedeckt.
Cold-Start bei Model Serving
Selten aufgerufene Endpunkte haben beim ersten Request nach längerer Inaktivität eine Latenz deutlich über dem stabilen Betriebswert. Bei konstantem Traffic spielt das keine Rolle, sporadisch genutzte Endpunkte mit harten SLAs brauchen eine Warmhaltestrategie oder Provisioned Throughput.
Komplexität von On-Demand-Funktionen
On-Demand-Funktionen sind im Serving-Pfad nützlich, werden aber schnell schwer testbar, sobald die enthaltene Logik komplex wird. Geometrische Berechnungen oder Zeitzonen-Konvertierungen lohnen sich nur, wenn die Funktion deterministisch und in Training und Serving identisch implementierbar bleibt.
Cross-Region-Replikation
Ein Modellendpunkt, der in mehreren AWS- oder Azure-Regionen mit identischem Feature-Stand laufen muss, ist im Lakehouse-Modell heute begrenzt unterstützt und verlangt eigene Replikations- und Failover-Logik, oft mit mehr Engineering-Tiefe als geplant.
Diese Grenzen ändern sich nicht durch eine größere Cluster-Größe. Sie sind Architekturentscheidungen, die früh getroffen werden müssen. Eine ehrliche Einschätzung der Latenz-, Frische- und Verteilungs-Anforderungen am Anfang spart später die Diskussion, ob die Plattform „stärker" werden müsste, als sie für ihren Workload designt ist.
Fazit
Real-Time-ML auf Databricks ist sinnvoll, wenn ein Use Case wirklich Features im Sekunden- oder Minutenbereich benötigt und die Lakehouse-Plattform bereits produktive ML-Anwendungen unterstützt.
Wenn Online Store, Mosaic AI Model Serving und Unity Catalog bereits produktiv genutzt werden, kann der Schritt zu Streaming-Features häufig ohne separate Streaming-Plattform erfolgen.
Besonders relevant ist das für Plattformen mit konkreten operativen ML-Anwendungsfällen in Planung (Fraud, Personalisierung, Pricing), bei denen Model Serving bereits produktiv genutzt wird, die benötigten Features aber noch aus nächtlichen Batch-Jobs stammen. Dann ist das Problem sichtbar und der Nutzen aktuellerer Features klar.
Real-Time-ML sollte nicht der nächste Schritt sein, wenn die grundlegende Lakehouse-Plattform noch nicht stabil ist, wenn keine klare Antwortzeit-Anforderung für den Anwendungsfall definiert ist oder wenn Feature-Pipeline und Modellendpunkt in unterschiedlichen Governance- und Betriebsmodellen laufen. Dann sollte zuerst das Fundament aus Datenplattform, Feature Store, Serving und Governance stabilisiert werden.
Mein Vorschlag: Den ersten Real-Time-Use-Case auf der vorhandenen Lakehouse-Plattform aufsetzen, mit klarer Einteilung in Streaming-, Batch- und On-Demand-Features und mit Online-/Offline-Konsistenz als messbarer Betriebskennzahl von Anfang an. Wenn ein Anwendungsfall wirklich Antwortzeiten unter einer Millisekunde benötigt, kann genau dieser Sonderfall gezielt in eine Spezialarchitektur ausgelagert werden, ohne die gesamte ML-Plattform in zwei getrennte Welten zu zerlegen.
Das Ziel ist eine ML-Plattform, in der Features genau so aktuell sind, wie der Anwendungsfall es erfordert, und so zuverlässig, wie die fachliche Entscheidung es verlangt. Ein zusätzlicher Streaming-Stack bleibt dann eine gezielte Ausnahme und wird nicht zum neuen Standard.
FAQ
Real-Time-ML beschreibt ML-Systeme, in denen ein Modell auf einen einzelnen Request hin antwortet und dabei Feature-Werte sieht, die innerhalb eines definierten Zeitfensters aktualisiert wurden. Die Abgrenzung zu Batch-ML zieht sich an der Feature-Frische: Sekunden bis Minuten für Real-Time, Stunden bis Tag für Batch.
