Самокат RecSys ML System Design: TikTok-like лента видео с товарами

Начать с цели и ограничений, запустить offline MVP с простым ранжированием и exploration, залогировать события, затем обучать ranker и проверять через A/B.

Хороший дизайн начинается не с модели, а с product objective: GMV/profit, discovery non-food ассортимента, guardrails по заказам и UX. Для 1500 видео можно на первом этапе скорить всех кандидатов offline и хранить top-N на пользователя или сегмент. MVP строится на popularity/GMV/маркетинговом приоритете, свежести и availability, но часть трафика нужно оставить под exploration.

После запуска нужно собрать impression logs, позицию, user context, video/product features и downstream-события: open, watchtime, переход к товарам, add-to-cart, purchase, attributed GMV. Следующая итерация - pointwise/pairwise ranker, diversity, frequency caps, freshness и fallback для новых пользователей.

Использовать popularity/GMV/content-based baseline с фильтрами доступности и свежести, обязательно добавить controlled exploration.

Для первого запуска можно ранжировать видео по агрегированному потенциалу привязанных товаров: GMV, маржа, популярность, availability, маркетинговый приоритет, свежесть и категория. Если продуктовая цель - discovery нового non-food ассортимента, полезно задать квоты или boosts на нужные категории.

Exploration нельзя оставлять случайностью без логики: часть позиций можно отдавать epsilon-greedy, rotation по категориям или свежему контенту. Это снижает popularity bias и дает данные для обучения следующего ranker.

Логировать impression, позицию, контекст, click/open, watchtime, swipe, переход к товарам, add-to-cart, purchase и attributed GMV.

Единица датасета - показ конкретного video candidate пользователю в конкретном request context. Нужны user_id, video_id, позиция, timestamp, источник ранжирования, признаки пользователя, видео, товаров и контекста на момент показа. Labels строятся в окнах: click, dwell/watchtime, product-list open, add-to-cart, purchase, GMV/profit.

Важно хранить именно serving-time features, иначе легко получить leakage. Негативами должны быть показанные, но не выбранные видео, а не все непоказанные кандидаты.

Pointwise предсказывает score для user-item, pairwise учит относительный порядок пар, listwise оптимизирует качество целого списка.

Pointwise проще всего запустить: модель предсказывает вероятность click/purchase или expected GMV для пары user-video. Pairwise ближе к ранжированию, потому что учит, какой объект должен быть выше другого, но требует генерации пар и hard negatives. Listwise лучше соответствует top-K метрикам, но сложнее в реализации и стабильности.

Практически часто начинают с pointwise GBDT/NN, сравнивают offline по NDCG/MAP/Recall@K и только потом усложняют loss, если есть качество и масштаб для этого.

Для 1500 видео рационален offline scoring с хранением top-N; online inference нужен при высокой свежести фичей или сложной персонализации в момент запроса.

Offline путь: регулярный job считает рекомендации, кладет user_id -> list(video_id, score) в Redis/Postgres/feature store, а API быстро отдает список с fallback. Online путь: сервис получает user/context, собирает свежие фичи, скорит модель и отвечает в latency budget.

В обоих вариантах нужны Docker/CI, orchestration, мониторинг freshness, coverage, latency, errors, data/model drift и fallback на baseline при пустом ответе или деградации сервиса.

Primary metric: incremental GMV/profit или attributed purchases; proxy: CTR, переходы к товарам, add-to-cart, watchtime; длительность считать через MDE, variance, traffic и power.

Нужно задать unit randomization, attribution window и guardrails: latency, retention, order conversion, cannibalization основного заказа. Если GMV долго созревает, прокси-метрики помогают диагностировать, но финальное решение нужно связывать с business metric.

Длительность теста не выбирается как фиксированная неделя. Она зависит от baseline metric, ожидаемого MDE, alpha, power, дисперсии, трафика и сезонности. Минимально полезно покрыть полный недельный цикл.