Recsys ML system design на собеседовании Data Scientist

Постановка задачи

System design рекомендаций — один из самых частых кейсов на собесе DS в продуктовых командах. Формулировка обычно звучит как «спроектируй рекомендации для маркетплейса / стриминга / ленты». Первое, что от вас ждут, — не сразу назвать модель, а уточнить требования и ограничения.

Типичные ограничения, которые стоит проговорить вслух:

• Масштаб. Например, 100M пользователей и 10M товаров. При таком каталоге ранжировать все товары под каждый запрос невозможно — отсюда многоступенчатость.
• Latency. Рекомендации нужны в реальном времени, на выдачу есть десятки миллисекунд. Это диктует, что тяжёлые модели работают офлайн, а онлайн остаётся лёгкий этап.
• Рост каталога. Товары и пользователи постоянно добавляются, значит нужно решать проблему cold start и регулярно переобучать модели.
• Цель оптимизации. CTR, конверсия, выручка или удержание — от этого зависит и функция потерь, и метрики. Уточнить целевую метрику в самом начале — сильный сигнал для интервьюера.

Гибридная архитектура

Ни один подход в одиночку не закрывает задачу, поэтому в проде почти всегда гибрид.

• Коллаборативная фильтрация (collaborative filtering). Работает по принципу «похожим на вас пользователям заходило вот это». Сильна на популярных товарах и активных пользователях, но беспомощна на новых объектах, где ещё нет истории взаимодействий.
• Контентная (content-based). Использует эмбеддинги самих товаров (текст через BERT, картинки через CNN/ViT). Сильна как раз на cold start: новому товару не нужна история, достаточно его описания.
• Гибрид. На практике оба сигнала объединяют в многоступенчатый пайплайн.

Стандартная многоступенчатая схема выглядит так:

Этап 1: Candidate generation (генерация кандидатов, из миллионов → тысячи)
  - Two-tower модель (collaborative)         → top-1000
  - Контентные эмбеддинги для новых товаров   → top-100
  - Trending / популярное для cold start      → top-50
  Объединяем → ~1500 кандидатов.
Этап 2: Ranking (ранжирование тяжёлой моделью на богатых признаках).
Этап 3: Re-ranking (диверсификация, бизнес-правила, дедуп).

Смысл разделения: на первом этапе нужна дешёвая модель, которая за миллисекунды отберёт из миллионов товаров пару тысяч (обычно через ANN-поиск по эмбеддингам двухбашенной модели). На втором тяжёлая модель ранжирует только этих кандидатов, используя сотни признаков (история, контекст, кросс-фичи). На третьем правят выдачу под продуктовые требования: разнообразие категорий, свежесть, скрытие уже купленного, бизнес-приоритеты.

Cold start

Cold start — что рекомендовать, когда истории ещё нет. Разбирают три случая:

• Новый пользователь. Онбординг-опрос с явными интересами; дефолт по демографии или источнику трафика; популярное и трендовое как безопасная стартовая выдача. По мере накопления кликов система быстро переходит на персонализацию.
• Новый товар. Контентный эмбеддинг из текста и картинок позволяет рекомендовать товар без истории. Двухбашенную модель обучают на признаках товара, а не только на его ID, чтобы новый объект сразу попадал в пространство эмбеддингов. Плюс bandit-исследование: показываем товар небольшой доле пользователей, чтобы быстро собрать сигнал.
• Новый домен или категория. Помогает transfer learning: переносим представления из похожей категории, где данных много.

Online learning

Батч-переобучение раз в сутки не успевает за поведением пользователя в моменте, поэтому его дополняют онлайн-обучением.

• Свежие признаки в реальном времени. Последнее действие, случившееся секунды назад, уже влияет на выдачу.
• Инкрементальные обновления модели. Стриминговые алгоритмы вроде FTRL или Vowpal Wabbit дообучаются на потоке событий, не дожидаясь полного ретрейна.
• Баланс exploration/exploitation. Bandit-подходы позволяют не застревать на уже известном хорошем, а прощупывать новое и не давать системе схлопнуться в «фильтр-пузырь».

Real-time обновления

Ключевая идея — свежесть признаков. Клик пользователя порождает событие, которое обновляет feature store, и следующий запрос уже использует эти данные.

Пользователь: viewed_item_recently = item_xyz, last_active = now.
Следующий запрос: ранжировщик берёт свежие признаки.

Отдельно важны сигналы с затуханием по времени (time-decay): недавнее взаимодействие весит больше, чем то, что было месяц назад. Это удерживает выдачу актуальной интересам «здесь и сейчас», а не усреднённой истории за год.

Метрики

Метрики делят на офлайн (для сравнения моделей до выката) и онлайн (в A/B-тесте).

Офлайн:

• NDCG, Recall@K, HitRate@K — качество ранжирования: попал ли релевантный товар в топ-K и на какой позиции.
• Coverage — какая доля каталога вообще попадает в рекомендации. Низкое покрытие означает, что система крутит одно и то же.

Онлайн (в A/B-тесте):

• CTR — кликают ли по рекомендациям.
• Conversion rate — доходит ли до целевого действия (покупка, подписка).
• Revenue per user — выручка на пользователя.
• Retention — долгосрочное удержание, самая важная и самая инертная метрика.
• Diversity / serendipity — разнообразие и «приятные неожиданности» в выдаче.

Важная оговорка на собесе: нельзя оптимизировать только CTR. Модель, заточенная под клики, скатывается в кликбейт — заголовки и обложки, которые провоцируют клик, но не приносят ценности. Поэтому целевой метрикой держат удержание и выручку, а CTR остаётся вспомогательным сигналом.

Как спрашивают на собесе

Кейс почти всегда открытый: «спроектируй рекомендательную систему для X». Хороший ответ идёт по структуре, а не сразу к модели:

• Сначала уточнить. Кто пользователи, что рекомендуем, какая цель (клики / выручка / удержание), масштаб, требования к latency. Вопросы к постановке ценят выше, чем немедленный ответ.
• Предложить многоступенчатую архитектуру. Объяснить, почему нельзя ранжировать весь каталог и зачем нужен отдельный этап генерации кандидатов.
• Разобрать cold start. Почти гарантированный подвопрос — что делать с новыми пользователями и товарами.
• Обсудить обратную связь и смещения. Position bias, feedback loop, фильтр-пузырь: как система не замыкается на собственных прошлых показах.
• Замкнуть на метрики и A/B. Как измерять успех офлайн и как валидировать онлайн, какие guardrail-метрики следить.

Частые ошибки

• Сразу назвать модель, не уточнив задачу. Без цели и ограничений выбор архитектуры выглядит наугад. Интервьюер ждёт уточняющих вопросов.
• Одноступенчатая система на большом каталоге. Ранжировать 10M товаров под каждый запрос невозможно по latency — нужен отдельный этап отбора кандидатов.
• Игнорировать cold start. Реальный продукт постоянно получает новых пользователей и товары; без ответа на это дизайн неполный.
• Оптимизировать только CTR. Ведёт к кликбейту и деградации удержания. Целевой метрикой держат долгосрочную ценность.
• Забывать про feedback loop и position bias. Система учится на собственных показах и на позиции элемента; без коррекции она усиливает уже показанное и сужает выдачу.
• Не думать про сервинг. Красивая офлайн-модель бесполезна, если не укладывается в latency-бюджет выдачи.

Связанные темы

• Collaborative filtering для DS
• Two-tower DSSM для DS
• Feed ranking system design для DS
• Multi-armed bandit для DS
• Подготовка к собесу Data Scientist

FAQ

Зачем рекомендациям несколько этапов, а не одна модель?

Каталог слишком велик, чтобы ранжировать его целиком под каждый запрос за отведённые миллисекунды. Поэтому дешёвый этап генерации кандидатов быстро отбирает пару тысяч из миллионов (обычно ANN-поиском по эмбеддингам), а тяжёлая ranking-модель работает уже только с ними. Это компромисс между качеством и latency.

Как решать cold start для нового товара?

Использовать контентные эмбеддинги из текста и картинок, чтобы товар попадал в пространство рекомендаций без истории, и обучать модель на признаках товара, а не только на его ID. Дополнительно — bandit-исследование: показать товар небольшой доле пользователей и быстро собрать сигнал о его релевантности.

Почему нельзя оптимизировать только CTR?

CTR легко хакнуть кликбейтом: обложки и заголовки, которые провоцируют клик, но не дают ценности. Со временем это снижает удержание и выручку. Поэтому CTR держат как вспомогательную метрику, а целевыми считают конверсию, выручку на пользователя и долгосрочный retention.

Что такое feedback loop в рекомендациях?

Система учится на данных, которые сама же и породила: пользователи кликают только по тому, что им показали. Из-за этого популярное становится ещё популярнее, а выдача сужается в «фильтр-пузырь». Борются exploration-механизмами (bandits), коррекцией position bias и явным контролем разнообразия на этапе re-ranking.

Какие метрики называть на system design собесе?

Разделите офлайн и онлайн. Офлайн — NDCG, Recall@K, HitRate@K и coverage для сравнения моделей до выката. Онлайн, в A/B-тесте, — CTR, конверсия, выручка на пользователя, удержание и разнообразие. Обязательно упомяните guardrail-метрики, чтобы улучшение основной цели не ломало продукт в другом месте.

Это официальная информация?

Нет. Статья основана на публичных описаниях индустриальных рекомендательных систем (Netflix, YouTube, Spotify) и типичных практиках. Конкретный формат кейса зависит от компании, команды и уровня позиции.

Тренируйте Data Science — откройте тренажёр с 1500+ вопросами для собесов.