Wie man in 5 Wochen ein Empfehlungssystem in TravelTech aufbaut: Kafka und MongoDB statt Feature-Store
Tutu
Ein MLOps-Ingenieur von Tutu beschreibt, wie ein Empfehlungssystem in fünf Wochen von Grund auf mit Kafka, MongoDB und ClickHouse aufgebaut wurde, wobei bewusst auf einen Feature-Store verzichtet wurde, um schneller zu sein. Das System schlägt Hotels nach dem Kauf eines Transporttickets vor, nutzt Echtzeit-Bestelldaten aus Kafka und nächtliche Batch-Features aus ClickHouse, die alle in MongoDB für schnelle Inferenz gespeichert werden.
Christina, eine MLOps-Ingenieurin bei Tutu, erklärt, wie ihr Team in nur fünf Wochen ein Empfehlungssystem (RecSys v1) eingeführt hat, um eine Deadline in der Hochsaison einzuhalten. Anstatt einen vollwertigen Feature Store zu bauen, was Monate gedauert hätte, verwendeten sie MongoDB als temporären Online-Store, wobei sie Echtzeit-Bestellungen aus Kafka und nächtliche Batch-Features aus ClickHouse in ein einziges Dokument pro Nutzer schrieben. Die größte technische Herausforderung bestand darin, den Kontext einer spezifischen Reise zu berücksichtigen – Zielstadt, Daten und Anzahl der Gäste –, den kollaboratives Filtern allein nicht erfassen konnte. Sie entwarfen den API-Vertrag so, dass er eine Zielbestellung aus der Kaufhistorie des Nutzers akzeptiert und UTC-Daten in die lokale Zeit der Ankunftsstadt umrechnet, um korrekte Check-in-/Check-out-Daten sicherzustellen. Der Dienst liest während der Inferenz nur aus MongoDB, mit einem Fallback auf die Top-Hotels nach Bestellanzahl, wenn ALS-Vektoren fehlen. Später führten sie CatBoost für das Ranking ein, wobei sie das Modell beim Start des Dienstes aus dem Objektspeicher laden. Sie füllten auch historische Bestellungen über Snapshot-Kafka-Topics nach, um sicherzustellen, dass Warm-Path-Nutzer eine Historie hatten, und führten doppelte Bestellungen per Order-ID zusammen. Dieser pragmatische Ansatz ermöglichte es ihnen, die Hypothese auf echtem Traffic zu validieren, ohne perfekte Architektur.
Quelle: Habr — хаб ML —
Original