Databricks zeigt Echtzeit-Empfehlungssystem für Mode-E-Commerce

Eine Plattform statt fragmentierter ML-Infrastruktur

Der Blogbeitrag argumentiert, der Aufbau eines produktionsreifen Empfehlungssystems gehöre zu den schwierigsten Aufgaben im ML-Engineering. Nötig seien Datenerfassung in Echtzeit, komplexes Feature Engineering, mehrere zusammenarbeitende Modelle und eine Serving-Infrastruktur, die in Millisekunden antwortet, während Lagerbestand, Standort und Geschäftsregeln synchron bleiben.

Databricks zufolge ersetzt das Design fragmentierte ML-Infrastruktur durch eine einzige, über Unity Catalog gesteuerte Plattform. Das Unternehmen gibt an, dass dadurch Glue-Code entfällt, Iterationszyklen schneller werden und eine durchgängige Lineage von rohen Clickstream-Ereignissen bis zu Produktionsvorhersagen entsteht. Zudem verweist es auf Branchen-Benchmarks, wonach wirksame Personalisierung die Konversionsraten um 10 bis 30 % steigern und den durchschnittlichen Bestellwert deutlich erhöhen kann.

Das System kombiniert vorab berechnete Batch-Empfehlungen mit einem Echtzeit-Scoring-Pfad. Databricks AI Search übernimmt die Kandidatensuche, Lakebase stellt Online-Features bereit, und Model Serving liefert Inferenz mit niedriger Latenz.

Vom Clickstream zu den Medallion-Schichten

Die Plattform verarbeitet rund 1.000 Ereignisse pro Sekunde, darunter Produktansichten, Suchanfragen, Warenkorb-Aktionen, Käufe und Sitzungsmetadaten. Zerobus Ingest von Lakeflow Connect schreibt diese Ereignisse direkt in Delta-Tabellen im Unity Catalog, ganz ohne selbst betriebenen Message Broker. Laut Databricks akzeptiert Zerobus Daten von jedem gängigen Kafka-Producer-Client in Java, Python oder Go, wenn per Konfigurationsänderung der Bootstrap-Server auf den Zerobus-Endpunkt zeigt. Teams, die bereits Kafka betreiben, können stattdessen Structured Streaming mit Declarative Pipelines nutzen, bei gleicher nachgelagerter Architektur.

Die Daten durchlaufen anschließend eine Medallion-Architektur:

• Bronze: rohe, nur anfügende Ereignisströme plus Referenzdaten, die Nutzersignale (Verhalten, Transaktionen, Präferenzen, Demografie), Artikelsignale (Katalog, Performance, Bildmerkmale, Aktualität) und Kontextsignale (zeitlich, geografisch, Umgebung, Sitzung) abdecken.
• Silver: in Sitzungen gegliedertes Nutzerverhalten, bereinigte Produktmerkmale, aggregierte Engagement-Signale wie 7-Tage-Aufrufzahlen und Trending-Scores sowie Interaktionsmatrizen zwischen Nutzern und Produkten.
• Gold: Feature-Vektoren für Nutzer und Artikel, gelabelte Trainingsdatensätze und vorab berechnete Empfehlungslisten.

Verhaltensaggregate werden täglich über geplante Databricks Workflows aktualisiert, der vollständige Produktkatalog wird wöchentlich synchronisiert. Die Embeddings für Nutzer und Artikel werden täglich neu berechnet. Der Databricks Feature Store verwaltet Offline-Features für das Training und Online-Features für das Serving, sodass dieselben Feature-Definitionen bei der Inferenz über Lakebase-Online-Tabellen zur Verfügung stehen. Unity Catalog ergänzt eine fein abgestufte Zugriffskontrolle, die nach Angaben des Unternehmens personenbezogene Daten schützt, während aggregierte Features ins Modelltraining fließen.

Pfad A: vorab berechnete Empfehlungen

Die Serving-Schicht hat zwei Pfade. Pfad A deckt die volumenstarken, vorhersehbaren Flächen ab: Carousels auf der Startseite, Rankings auf Kategorieseiten, E-Mail-Kampagnen und Push-Benachrichtigungen. Hier sind Nutzer und Flächentyp im Voraus bekannt, sodass sich die Ergebnisse vorab berechnen lassen.

Ein nächtlicher Batch-Job, orchestriert von Databricks Workflows, führt den vollständigen dreistufigen Funnel offline für jeden aktiven Nutzer aus. Er ruft die aktuellen Nutzer-Embeddings ab, führt Batch-ANN-Abfragen gegen den Artikelindex von AI Search aus, um Kandidaten zu erzeugen, bewertet diese mit einem LightGBM-Modell anhand von Gold-Features und wendet Geschäftsregeln an, etwa Bestandsbewertung, Lieferentfernung, Diversität und Promotion-Boosting. Das Ergebnis ist eine nach Rang sortierte Top-N-Liste pro Nutzer, typischerweise 50 bis 100 Artikel pro Fläche, die in Lakebase-Online-Tabellen geschrieben wird, indiziert nach Nutzer-ID und Flächentyp.

Zur Anfragezeit führt die App lediglich einen einfachen Key-Value-Lookup aus Nutzer-ID und Fläche durch. Es gibt keine Modellinferenz, keine Vektorsuche und kein Zusammenstellen von Features. Databricks beziffert die Latenz dieses Pfads mit unter zweistelligen Millisekunden. Weil der Job nachts läuft, spiegeln die Ergebnisse die Signale und den Bestand des Vortags wider. Das reiche für die meisten Flächen mehr als aus, so das Unternehmen, da sich langfristige Präferenzen und Markenaffinitäten über Tage entwickeln und neue Produkte mit initialen Embeddings innerhalb von 24 Stunden in den Empfehlungen auftauchen.

Pfad B: sitzungsbezogenes Scoring zur Anfragezeit

Pfad B kommt zum Einsatz, wenn der Kontext erst zur Anfragezeit vorliegt, etwa bei „Ähnliche Artikel“ auf einer Produktdetailseite, Vorschlägen für „Complete the look“ oder Suchergebnissen, die während des Stöberns neu sortiert werden. Die App sendet aktuelle Sitzungssignale, darunter in den letzten Minuten angesehene Artikel, aktive Suchanfragen, Warenkorbinhalt und Verweildauermuster, per REST direkt als Request-Payload an den Model-Serving-Endpunkt. Databricks betont, dass dies die Lakehouse-Speicherung während der Inferenz umgeht, sodass Echtzeitkontext ohne Ingestion-Latenz verfügbar ist.

Der Endpunkt führt den vollständigen dreistufigen Funnel synchron in einem Request-Response-Zyklus aus. In Stufe 1 wandelt er Sitzungssignale in ein Abfrage-Embedding um. Das ist entweder das Embedding des angesehenen Produkts oder ein kombiniertes Nutzer-Embedding, das das langfristige Profil aus Lakebase mit dem Verhalten in der Sitzung verbindet und jüngere Signale stärker gewichtet. Databricks AI Search führt dann eine hybride Suche durch, die ANN-Ähnlichkeitssuche mit harten Metadatenfiltern für Kategorie-Eignung, regionalen Bestand und Mindestbestandsschwellen kombiniert, sodass vergriffene oder nicht infrage kommende Artikel gar nicht erst in die Kandidatenmenge gelangen.

Was das für Retail-Teams bedeutet

Der Beitrag ist ein Referenzdesign und keine Produkteinführung, Angaben zu Preisen oder Verfügbarkeit enthält er nicht. Für Datenteams im Handel zeigt er, wie Databricks seine Komponenten für Ingestion, Features, Vektorsuche und Serving für die Personalisierung kombinieren will. Die zentrale Designentscheidung ist die Trennung zwischen einem günstigen Key-Value-Pfad für vorhersehbare Flächen und einem synchronen Scoring-Pfad für sitzungsgetriebene. Teams, die bereits auf Databricks oder Kafka setzen, können erkennen, welche Teile eines bestehenden Stacks das Unternehmen ersetzen oder weiterverwenden würde.