Рекомендательная система в TravelTech за 5 недель: Kafka и MongoDB вместо Feature Store

MLOps-инженер «Туту» Кристина рассказала, как команда за пять недель построила рекомендательную систему для cross-sell отелей на Kafka, MongoDB и ClickHouse, отказавшись от Feature Store ради скорости. Разбираем, какие компромиссы пришлось принять и почему контекст поездки важнее алгоритмов.

Запуск рекомендательной системы в продакшн обычно ассоциируется с долгим проектированием, тяжёлыми расчётами и идеальной архитектурой. Но что делать, когда до высокого сезона остаётся всего пять недель, а бизнесу нужно срочно проверить гипотезу на живом трафике? MLOps-инженер «Туту» Кристина поделилась опытом, как её команда справилась с этой задачей, используя привычный стек: Kafka, MongoDB и ClickHouse — и сознательно отказавшись от перфекционизма. В этой статье разбираем, какие инженерные решения помогли уложиться в срок и почему в TravelTech контекст поездки важнее сложных алгоритмов.

Как за 5 недель собрать рекомендательную систему на Kafka, MongoDB и ClickHouse

Кристина, MLOps-инженер в «Туту», рассказала о запуске рекомендательной системы для cross-sell отелей. Суть задачи: пользователь покупает билет, и ему нужно сразу показать релевантный отель. В идеальном мире для этого построили бы Feature Store, настроили пайплайны данных и потратили бы полгода. В реальности — два инженера, один DS и пять недель до старта высокого сезона.

Команда решила собрать v1 на том, что уже работало в проде. Вместо Feature Store использовали связку Kafka, MongoDB и ClickHouse. Kafka обеспечивала потоковую передачу данных о покупках, MongoDB хранила признаки и контекст, а ClickHouse использовался для аналитики и ранжирования. Такой подход позволил быстро проверить гипотезу на живом трафике, не дожидаясь идеальной архитектуры.

Ключевым инженерным вызовом стал не масштаб и не алгоритмы, а контекст. Cross-sell в travel — это не «похожие товары» из классического e-commerce. Если пользователь купил билет Москва — Сочи на 10–17 июля, нужно показать отели именно в Сочи на эти даты. Коллаборативная фильтрация без контекста поездки не знает ни город, ни даты, ни то, что заказ только что оплачен и его ещё нет в DWH. Поэтому команда сделала ставку на явное задание контекста поездки до ранжирования.

Почему Feature Store не подошёл и что выбрали вместо него

Feature Store — это хранилище признаков, которое централизованно управляет фичами для ML-моделей. В крупных компаниях это стандарт, но он требует времени на проектирование и настройку. В «Туту» решили, что пять недель — слишком мало для полноценного внедрения. Вместо этого взяли проверенные инструменты: Kafka для стриминга, MongoDB как основное хранилище и ClickHouse для аналитики.

Такой выбор оправдан: Kafka уже использовался в компании для обработки событий, MongoDB гибок для хранения разнородных признаков, а ClickHouse отлично справляется с аналитическими запросами. Команда сознательно пошла на компромиссы: например, не строили сложные пайплайны обновления фичей, а использовали простые скрипты и триггеры. Это позволило запустить систему быстро, но создало технический долг, который придётся закрывать в будущем.

Как работает рекомендательная система в TravelTech

Рекомендательная система в «Туту» работает так: когда пользователь покупает билет, событие попадает в Kafka. Оттуда оно попадает в MongoDB, где хранится контекст поездки: город назначения, даты, количество пассажиров. На основе этих данных система формирует запрос к ClickHouse, который возвращает список отелей, подходящих под контекст. Затем отели ранжируются по релевантности и показываются пользователю.

Такой подход позволяет учитывать специфику travel: отели должны быть в городе назначения и на даты поездки. Это принципиально отличается от рекомендаций в e-commerce, где важны предпочтения пользователя, а не контекст конкретной покупки. Команда подчёркивает, что алгоритмы здесь вторичны — главное правильно задать контекст и обеспечить быструю доставку данных.

Компромиссы и технический долг: что пришлось отложить

Любой быстрый запуск сопряжён с компромиссами. В «Туту» отказались от полноценного Feature Store, что означает отсутствие единого хранилища признаков и сложности с переиспользованием фичей в других моделях. Также не стали строить сложную систему мониторинга деградации модели — ограничились базовыми метриками.

Технический долг придётся закрывать: например, добавить автоматическое обновление фичей, настроить A/B-тестирование и улучшить отказоустойчивость. Но для проверки гипотезы это было приемлемо. Кристина отмечает, что важно заранее понимать, что быстрый запуск — это не финальное решение, а лишь первый шаг к полноценной ML-платформе.

Кого затронет это решение и как повлияет на бизнес

Для бизнеса это решение означает возможность быстро проверить, увеличивают ли рекомендации конверсию в покупку отеля. Если гипотеза подтвердится, можно инвестировать в полноценную платформу. Для инженеров это опыт запуска ML-системы в сжатые сроки и понимание, какие компромиссы допустимы.

Российский рынок TravelTech активно развивается, и подобные кейсы полезны для других компаний, которые сталкиваются с похожими задачами. Опыт «Туту» показывает, что даже с ограниченными ресурсами можно запустить работающую рекомендательную систему, если правильно расставить приоритеты.

Что будет дальше: планы по развитию системы

Сейчас команда продолжает развивать систему: планируется добавить больше признаков, улучшить ранжирование и внедрить A/B-тестирование. В перспективе — перейти на полноценный Feature Store, когда появится ресурс. Но главное — гипотеза проверена, и бизнес получил инструмент для роста.

Ожидается, что система будет масштабироваться на другие cross-sell-сценарии, например, рекомендации экскурсий или трансферов. Это открывает новые возможности для монетизации и улучшения пользовательского опыта.

Итог

История «Туту» — яркий пример того, как можно быстро запустить рекомендательную систему в TravelTech, используя привычный стек и осознанные компромиссы. Главный урок — в таких проектах контекст важнее алгоритмов, а скорость запуска позволяет бизнесу проверить гипотезы без долгих ожиданий. Следить за развитием этой системы будет интересно всем, кто работает с ML в продакшене.