Echtzeit-Personalisierung – ein Leitfaden für Entwickler

BalanceFormCreative | shutterstock.com

Für Software Engineers, die High-Concurrency-Applikationen für den E-Commerce-, Fintech- oder Mediensektor entwickeln, ist das Limit von 200 Millisekunden gesetzt: Das ist die psychologische Schwelle, bis zu der die Benutzer eine Interaktion als „augenblicklich“ empfinden. Dauert es länger, eine personalisierte Startseite, Suchergebnisse oder Queues zu laden, steigt die Abwanderungsrate drastisch an. Das unterstreicht auch eine vielzitierte Studie von Amazon: Demnach kostet jede Latenz von 100 Millisekunden ein Unternehmen ein Prozent seines Umsatzes.

Das Problem ist an dieser Stelle vor allem, dass Unternehmen nach immer intelligenteren und komplexeren Modellen streben: LLMs sollen Zusammenfassungen generieren, neuronale Netze Kundenabwanderung vorhersagen und komplexe Reinforcement-Learning-Agenten die Preisgestaltung optimieren. All das bringt die Latenz-Budgets an ihre Grenzen. Als leitender Engineer fungiere ich oft als Vermittler zwischen Data-Science-Teams, die massive Parameter einsetzen wollen – und Site Reliability Engineers (SREs), die dabei zusehen, wie p99-Latenzdiagramme ins Rot abdriften. Um die Nachfrage nach optimierten KI-Systemen mit der Realität von Antwortzeiten im Subsekundenbereich in Einklang zu bringen, müssen wir unsere Architektur überdenken, uns von monolithischen Anfrage-Antwort-Mustern lösen und die Inferenz vom Retrieval entkoppeln.

In diesem Artikel möchte ich Ihnen eine Blaupause für die Architektur von Echtzeitsystemen vorstellen, die skalierbar sind, ohne dafür die Geschwindigkeit zu opfern.

Die Two-Tower-Architektur

Ein häufiger Fehler, den ich bei Personalisierungs-Teams in der Anfangsphase beobachte: der Versuch, jedes Item im Katalog in Echtzeit zu bewerten. Wenn es davon 100.000 gibt (etwa Filme, Produkte oder Songs), ist es mathematisch unmöglich, sämtliche Items innerhalb von 200 Millisekunden durch ein komplexes Scoring-Modell zu „jagen“.

Manoj Yerrasani

Um dieses Problem zu lösen, implementieren wir bei NBC Universal diese Two-Tower-Architektur:

1. Die Kandidaten-Generierung (der Retrieval Layer) stellt einen schnellen Durchlauf dar. Wir nutzen Vektorsuche oder einfache kollaborative Filterung, um die 100.000 Elemente auf die 500 besten Kandidaten einzugrenzen. Bei diesem Schritt hat die Wiederauffindbarkeit Vorrang vor der Genauigkeit – er muss in weniger als 20 Millisekunden ablaufen.
2. Beim Ranking (dem Scoring-Layer) kommt die leistungsstarke KI zum Einsatz. Wir lassen die zuvor ermittelten 500 Kandidaten durch ein ausgeklügeltes Deep-Learning-Modell (etwa XGBoost oder ein neuronales Netzwerk) laufen, das Hunderte von Merkmalen berücksichtigt – beispielsweise den Benutzerkontext, die Tageszeit und den Gerätetyp.

Indem wir diesen Prozess auf diese Weise splitten, nutzen wir unser teures Compute-Budget bei NBC Universal nur für diejenigen Items, die tatsächlich eine Chance haben, angezeigt zu werden. Dieser Funnel-Ansatz ist die einzige Möglichkeit, Umfang und Komplexität in Einklang zu bringen.

Das Kaltstart-Problem lösen

Die erste Hürde, vor der jeder Entwickler steht, ist der „Kaltstart“ – und die damit verbundene Frage: Wie personalisiert man einen Nutzer ohne Historie oder im Rahmen einer anonymen Session? An dieser Stelle versagt traditionelles Collaborative Filtering, weil es sich auf eine spärliche Matrix historischer Interaktionen stützt. Ein riesiges Data Warehouse nach demografischen Clustern abzufragen, können Sie sich vor dem Hintergrund der 200-Millisekunden-Grenze nicht leisten. Sie benötigen deshalb eine Strategie, die auf Session-Vektoren aufbaut.

Wir behandeln die aktuelle Session eines Users (Klicks, Hovers und Suchbegriffe) als Echtzeit-Stream und setzen ein leichtgewichtiges rekurrentes neuronales Netzwerk (RNN) oder ein einfaches Transformer-Modell direkt am Edge oder im Inferenz-Service ein. Wenn der Benutzer auf „Artikel A“ klickt, leitet das Modell sofort einen Vektor basierend auf dieser Interaktion ab und fragt über eine Vektordatenbank den „Nearest Neighbour“ ab. So wird es für uns möglich, die Personalisierung in Echtzeit anpassen: Klickt der Benutzer auf einen Horrorfilm, wird die Startseite neu angeordnet und zeigt sofort entsprechende Thriller an.

Der Trick, um dabei stets den Speed aufrechtzuerhalten, besteht darin, sogenannte „Hierarchical Navigable Small World“-Graphen (HNSW) für die Indizierung zu verwenden. Im Gegensatz zu einer Brute-Force-Suche, bei der der Benutzer-Vektor mit jedem Element-Vektor abgeglichen wird, navigiert HNSW durch eine Graph-Struktur, um die besten Übereinstimmungen mit logarithmischer Komplexität zu finden. Die Abfragezeiten sinken hierdurch von Hunderten von Millisekunden in den einstelligen Bereich. Entscheidend ist dabei, dass wir nur das Delta der aktuellen Session berechnen. Wir aggregieren nicht die gesamte User-Historie, wodurch die Inferenz-Nutzlast überschaubar bleibt.

Eine Entscheidungsmatrix

Ein weiterer architektonischer Fehler, auf den ich häufig stoße, ist der dogmatische Versuch, alles in Echtzeit auszuführen. Das führt unweigerlich zu hohen Cloud-Kosten und Latenzspitzen. Um genau zu bestimmen, was passiert, wenn ein User einen Ladevorgang anstößt, benötigen Sie eine strikte Entscheidungsmatrix. Wir unterteilen in unserer Strategie nach „Head“ und „Tail“.

Werfen Sie zunächst einen Blick auf Ihre Head-Inhalte: Für die 20 Prozent der aktivsten Benutzer oder Inhalte, die trenden (etwa der Super Bowl-Stream oder ein viraler Sneaker-Drop), sollten Sie Empfehlungen vorab berechnen. Wenn Sie VIP-Benutzer haben, die täglich vorbeischauen, führen Sie diese umfangreichen Modelle stündlich im Batch-Modus über Airflow oder Spark aus. Die Ergebnisse speichern Sie in einem Key-Value-Speicher mit geringer Latenz – etwa Redis, DynamoDB oder Cassandra. Wenn der Request dann eingeht, handelt es sich um einen einfachen O(1)-Fetch, der statt Milli- nur Mikrosekunden dauert.

Für Tail-Inhalte nutzen Sie Just-in-Time-Inferenz: Für Nischeninteressen oder neue Benutzer, die durch Vorberechnungen nicht abgedeckt werden können, leiten Sie den Request an einen Echtzeit-Inferenzdienst weiter. Optimieren Sie aggressiv mit Modellquantisierung: In Forschungslaboren trainieren Datenwissenschaftler Modelle mit einer 32-Bit-Gleitkomma-Genauigkeit (FP32). In der Produktion benötigen Sie für ein Empfehlungs-Ranking selten diese Granularität.

Wir komprimieren unsere Modelle auf 8-Bit-Ganzzahlen (INT8) oder sogar 4-Bit, indem wir Techniken wie Post-Training-Quantisierung einsetzen. Dadurch wird die Modellgröße um das Vierfache reduziert und die Bandbreitennutzung des Speichers auf der GPU deutlich verringert. Oft ist der Genauigkeitsverlust vernachlässigbar (weniger als 0,5 Prozent), während die Inferenzgeschwindigkeit sich verdoppelt. Das macht mit Blick auf das Einhalten des 200-Millisekunden-Limits regelmäßig den Unterschied.

Resilienz und Circuit Breaker

Geschwindigkeit ist allerdings wenig wert, wenn das System zusammenbricht. In einem verteilten System ist ein 200-Millisekunden-Timeout ein „Vertrag“ mit dem Frontend. Wenn Ihr ausgeklügeltes KI-Modell hängenbleibt und zwei Sekunden braucht, um eine Antwort zu liefern, dreht sich das Frontend im Kreis – und der Benutzer ist weg.

Deswegen implementieren wir bei NBC Universal strenge Circuit Breaker und Degraded Modes: Wir legen ein festes Timeout für den Inferenzdienst fest (etwa 150 Millisekunden). Wenn das Modell innerhalb dieses Zeitfensters kein Ergebnis zurückgibt, löst der Circuit Breaker aus. Das führt aber nicht dazu, dass eine Fehlerseite angezeigt wird. Stattdessen greifen wir auf eine „sichere“ Standardeinstellung zurück – eine zwischengespeicherte Liste mit „Popular Now“- oder „Trending“-Elementen.

Aus Sicht des Benutzers wurde die Seite sofort geladen – möglicherweise wird eine weniger personalisierte Liste angezeigt, aber die Anwendung bleibt reaktionsfähig. Merke: Es ist besser, postwendend eine generische Empfehlung zu liefern, als eine perfekte und dafür langsam.

Data Contracts als Zuverlässigkeits-Layer

In Hochgeschwindigkeitsumgebungen verändern sich die vorgelagerten Datenschemata ständig. Ein Entwickler fügt dem Benutzerobjekt ein Feld hinzu oder ändert das Zeitstempelformat von Millisekunden zu Nanosekunden. Und plötzlich stürzt Ihre Personalisierungs-Pipeline aufgrund eines Typen-Mismatchs ab.

Das lässt sich verhindern, indem Sie Data Contracts auf dem Ingestion Layer implementieren. Stellen Sie sich einen solchen Data Contract als API-Spezifikation für Ihre Datenströme vor: Er erzwingt die Schema-Validierung, bevor die Daten überhaupt in die Pipeline gelangen. Um genau zu definieren, wie die Daten aussehen sollen, nutzen wir Protobuf- oder Avro-Schemata.

Wenn ein Produzent fehlerhafte Daten übersendet, werden diese durch den Data Contract am Gate abgelehnt (und in einer Dead-Letter-Queue abgelegt), anstatt das Personalisierungsmodell zu verfälschen. Dadurch ist gewährleistet, dass Ihre Laufzeit-Inferenz-Engine immer mit sauberen, vorhersehbaren Features gefüttert wird. Und: Dieser Ansatz verhindert außerdem „Garbage-in, Garbage-out”-Szenarien, die zu stillen Produktionsausfällen führen können.

Überdurchschnittliche Observability

Geht es darum, den Erfolg zu messen, betrachten die meisten Teams die durchschnittliche Latenzzeit. Die ist jedoch eine irreführende Kennzahl, die die Erfahrungen wichtiger User verschleiert. Denn Durchschnittswerte glätten die Ausreißer. In Personalisierungssystemen sind diese jedoch oft Ihre Power-User. Ein Nutzer mit einer fünfjährigen Verlaufshistorie erfordert mehr Datenverarbeitung als ein Nutzer mit einer fünfminütigen. Wenn Ihr System nur bei großen Datenmengen langsam ist, bestrafen Sie damit also Ihre treuesten Kunden.

Bei NBC Universal betrachten wir ausschließlich die Latenzzeiten p99 und p99,9. Diese geben Auskunft darüber, wie das System bei den langsamsten ein Prozent, beziehungsweise 0,1 Prozent der Anfragen abschneidet. Wenn unser p99 unter 200 Millisekunden liegt, wissen wir, dass alles in Ordnung ist.

Die Architektur der Zukunft

Wir bewegen uns weg von statischen, regelbasierten Systemen hin zu agentenbasierten Architekturen. In diesem neuen Modell empfiehlt das System nicht nur eine statische Liste von Elementen. Es erstellt aktiv eine Benutzeroberfläche, die auf Intent abstellt. Diese Veränderung macht es noch schwieriger, das 200-Millisekunden-Limit zu halten. Sie erfordert ein grundlegendes Umdenken in Bezug auf unsere Dateninfrastruktur. Wir müssen die Rechenleistung über Edge-KI näher an den Benutzer bringen, die Vektorsuche als primäres Zugriffsmuster einführen und die Stückkosten jeder Inferenz rigoros optimieren.

Für den modernen Softwarearchitekten ist das Ziel insofern nicht mehr nur Genauigkeit, sondern Genauigkeit bei hoher Geschwindigkeit. Mit dem Handwerkszeug dieses Artikels können Sie Systeme aufbauen, die nicht nur auf Ihre User reagieren, sondern sie antizipieren. (fm)

Dieser Beitrag wurde im Rahmen des englischsprachigen Experten-Netzwerks von Foundry veröffentlicht.