RecSys на собеседовании (FAANG)

2020 год. TikTok обгоняет Instagram по time spent на пользователя за два года: 95 мин/день против 53 мин/день. Главный секрет - не более красивые видео, а более точный RecSys: For You feed работает на multi-objective ranking с тонко выверенными весами engagement, satisfaction, и retention. ByteDance публикует Monolith paper в 2022 - архитектура их feature store. Это становится reference для RecSys инженеров. На собеседовании в Meta/ByteDance/Pinterest сейчас спрашивают именно эту глубину: не просто 'two-tower', а 'почему watch_time вытеснил CTR в 2016 и какой класс проблем это решило'. Staff ML engineer в этой области получает USD 500K+ total compensation - и платят именно за способность видеть эту production глубину.

• **Meta News Feed**: 1B+ users, two-tower retrieval (FAISS) + DLRM ranking с тысячами фичей, multi-objective с weights для clicks/comments/likes/shares
• **TikTok For You**: ByteDance Monolith feature store, real-time user behavior signals, per-user model fine-tuning
• **Spotify Discover Weekly**: collaborative filtering + audio embeddings + multi-objective (relevance + novelty + diversity)
• **Pinterest Visual Search**: CLIP-style multimodal embeddings, hybrid retrieval, billions of pins indexed

Предварительные знания

• Two-stage retrieval: candidate generation + ranking
• Архитектуры Netflix / YouTube / TikTok
• Метрики RecSys: CTR, watch-time, NDCG, retention

• RecSys at Scale: Netflix, YouTube, TikTok
• Введение в рекомендательные системы

Two-stage retrieval как канонический ответ на ML system design

Дисциплина RecSys-собеседования в FAANG оформилась вокруг одного шаблона ответа: two-stage retrieval - сначала candidate generation, затем ranking. Шаблон закрепился после статьи Google «Deep Neural Networks for YouTube Recommendations» (Covington et al. 2016), которая показала эту декомпозицию на промышленном масштабе. С тех пор кандидата на ML system design ждут, что он начнёт с разбивки на retrieval и ranking, обсудит выбор метрик (CTR против watch-time против retention), и честно проговорит tradeoffs: latency budget, cold start, feedback loop. Интервьюер оценивает не знание конкретной модели, а умение структурировать задачу и защищать каждое решение бизнес-сигналом.

Design Feed: Instagram, TikTok, Twitter

Один из самых частых вопросов на собеседовании в Meta/ByteDance/X: *"Спроектируйте ленту Instagram/TikTok/Twitter."* Это ML system design, и подход тот же, что у Grokking, но с RecSys-спецификой. **Шаг 1: уточнить scope**. Сколько пользователей (1B как Instagram или 100M как Pinterest)? Какой content type (видео, фото, текст)? Какой target metric - engagement (time spent), revenue (clicks), satisfaction (long-term retention)? Без этого ответ - один сплошной handwaving. **Шаг 2: latency budget**. Лента грузится за 200-500 мс на mobile - значит у вас 100-300 мс на all-server-side processing (rest съест network + render). Это сразу диктует архитектуру: **нельзя** scoring 10M items в реальном времени, нужна two-stage: candidate generation (1K-10K items) + ranking (top 100).

Каноничный 'two-tower' ответ для feed (используется в Meta, YouTube, Pinterest). **Candidate generation**: тысячи кандидатов из 10M item pool через ANN (Annoy, FAISS, ScaNN), отбираемых по dot product user_embedding @ item_embedding. Узкий слой - **400 мкс на запрос** для FAISS HNSW index с 10M items на 256-dim embeddings. **Ranking**: 1000 кандидатов через тяжёлую модель (DNN, gradient boosting на тысячах фичей: user history, item content, contextual signals). Латентность ranking - 50-150 мс. Сумма даёт latency budget. Это та же логика, что в search engines (Google, Bing) - они тоже two-stage: BM25/recall stage + neural reranker. На собеседовании в Meta любят, когда кандидат сам предлагает two-tower до того, как интервьюер задаст наводящий вопрос.

Подвох на staff interview: *"Как избежать filter bubble и cold start одновременно?"* Это **explore-exploit** проблема, и хороший ответ упомянет несколько уровней. **Уровень рандомизации**: вставлять 5-10% random/diverse кандидатов в ленту, чтобы получить обратную связь по новым items. **Контекстуальный bandit**: Thompson sampling для выбора между 'safe' (что точно понравится) и 'exploratory' (что может расширить интересы) - применяется Spotify Discover Weekly. **Diversity penalty**: в re-ranking штрафовать слишком похожие items (через DPP - Determinantal Point Process). Cold start решается отдельно: для новых users - демографические fallbacks; для новых items - content-based boost первые 48 часов, потом переход на collaborative signal. То же напряжение в обучении ML моделей: explore (новые архитектуры) vs exploit (оптимизация известного) - универсальный паттерн.

Design Search: Spotify, Amazon, Pinterest

Вопрос *"Спроектируйте search Amazon/Spotify/Pinterest"* - типичный staff round в этих компаниях. Главное отличие от feed: search **driven by intent** (пользователь явно запросил query), feed **driven by interest** (пассивная подача контента). Это меняет архитектуру. **Stage 1 - retrieval** должен учитывать query relevance: traditional BM25 (текстовый матч) + dense retrieval (query embedding похож на item embedding) - hybrid score. **Stage 2 - ranking** дополнительно учитывает personalization: тот же item для двух users получит разные scores из-за разной user history. Это hybrid search, и его архитектура усложняется: retrieval pipeline теперь требует **lexical index** (Elasticsearch, Lucene) + **vector index** (FAISS) с fusion - обычно через Reciprocal Rank Fusion.

Тонкое место - **query understanding**. Часто на собеседовании в Amazon ловят кандидатов на упрощённом ответе 'просто embed query через BERT'. Правильный ответ многоуровневый. **Уровень 1**: query normalization - lowercase, spell correction ("adidash shoes" → "adidas shoes"), синонимы ("sneakers" ↔ "shoes"). **Уровень 2**: intent classification - 'navigational' (пользователь знает что хочет: 'macbook pro 16'), 'informational' ('how to cook salmon'), 'transactional' ('buy iphone'); разные intents требуют разной ranking стратегии. **Уровень 3**: query rewriting - LLM-based expansion, особенно у Pinterest и Spotify. **Уровень 4**: personalized query: тот же 'shoes' от runner и от fashion enthusiast - разные запросы. Знание этой иерархии отделяет ML engineer от research scientist - последний может одно, первый знает все слои.

Любимый trap-вопрос на собеседовании в Pinterest: *"Что если query - изображение, а не текст?"* Здесь архитектура переходит к **multimodal retrieval**. CLIP (OpenAI) и его варианты дают единое embedding space для image+text - можно индексировать images через CLIP image encoder, искать как через CLIP text encoder, так и через CLIP image encoder (для visual similarity). Pinterest использует именно такой стек: 'Visual Search' - upload image, найти похожее. Альтернатива - старая школа: extract features через ResNet, индексировать в FAISS, classifier для tags. CLIP побеждает потому что zero-shot generalization работает на out-of-distribution images. Знание этого перехода между approaches - сильный сигнал на staff interview.

Метрики: что измерять и как защищать выбор

Самый недооценённый вопрос на staff interview: *"Какую метрику оптимизировать в этом дизайне?"* Кандидаты часто отвечают 'CTR' и быстро попадают в ловушку - интервьюер ждёт глубокого ответа. CTR можно гнать вверх sensational content (clickbait), и это убивает long-term retention. Поэтому современные RecSys работают с **multi-objective optimization**: weighted sum нескольких targets - p(click), p(watch_time>30s), p(satisfaction_rating), p(return_next_day). Weights tuned под business objective - и сами эти weights становятся ML/business собеседоваельным вопросом. **Каноничный пример**: YouTube в 2012 оптимизировал CTR, получил clickbait взрыв; в 2016 переключился на watch_time, получил длинные видео но снижение satisfaction; в 2019 ввёл satisfaction surveys как ground truth target. Эта эволюция метрик - история всего YouTube algorithm changes.

Различение **online vs offline metrics**. **Offline** (на held-out data): precision@k, recall@k, NDCG, MAP, AUC - дешёвые для итераций, но не отражают behaviour change. **Online** (A/B tests): CTR, watch_time, retention, revenue per user - истина в последней инстанции, но дорогие (нужно 2-4 недели, миллионы пользователей в эксперименте). Корреляция между offline и online метриками НЕ всегда хорошая - это classic Meta lesson 2018. **Counterfactual evaluation** (Inverse Propensity Scoring, Off-Policy Evaluation) пытается оценить online через offline данные, но имеет ограничения. На собеседовании staff/principal спрашивают про опыт развязывания offline/online divergence - это глубокая проблема, и ответ показывает зрелость инженера.

На principal/distinguished interview частый вопрос - **proxy metrics**. Watch time как proxy для satisfaction - окей? Нет: длинное видео может означать 'втянулся' или 'скучно скроллит'. Совет: **triangulate** через несколько proxy метрик с разными failure modes. Аналогия в ML obsersity: loss на validation set - proxy для quality on production. Кандидат, который умеет говорить *"наши proxies могут разойтись с истинной целью; вот мониторинг и validation, который ловит drift"* - сильный кандидат на staff role. Это та же логика, что в Goodhart's Law: 'When a measure becomes a target, it ceases to be a good measure' - и RecSys engineers это испытали на YouTube CTR maximization 2012.

System design: production-уровень и tradeoffs

На принципал level спрашивают про **production realities**, которые не разбираются в курсах. **Online vs Offline serving**. User embeddings обновляются как? Раз в день батч-джобом (Spark) - дешево, но 24-часовое отставание; user behaviour за день не отражается. Real-time updates - стримя через Kafka в feature store (Redis или TikTok-style monolith feature service) - дорого, но <1 sec latency. Middle ground - hybrid: stable features батчем, fast features (last_10_items_watched) стримом. **Item embeddings** обычно батч раз в час, потому что generative по definition (item content не меняется быстро). **Negative sampling** - часто упускается, но критично: model нужны негативы, и uniform sampling даёт плохое качество (popular items dominate), in-batch sampling даёт смещение. Кандидат, который сам предлагает 'mixed negative sampling: 50% in-batch + 50% uniform' - явный сигнал production experience.

**Model serving latency** - частый trap. Допустим, ваш ranking DNN - 100M parameters, BERT-style. Inference на CPU - 200-500 мс per query (1000 candidates). Это убьёт latency budget. Решения три. **Решение 1**: модель меньше (distill через knowledge distillation в 10x меньшую модель, потеря качества <1% if done правильно). **Решение 2**: GPU serving (TensorRT, ONNX Runtime) - 10-20 мс per query, но стоит USD 2-5 per million queries. **Решение 3**: caching: для top-1% queries (top_searches) предкэшировать ranking результаты - удар по latency, но bias к head запросам. В реальности Meta, YouTube используют все три одновременно: distilled models на CPU для tail, GPU для high-revenue traffic, cache для head. Знание этой стратификации трафика - сильный сигнал.

Финальный сигнал зрелости - **обсуждение неудач** и **failure modes**. Что происходит, если FAISS index упал? Fallback на popularity-based feed (top items by recent engagement) - degraded UX, но не пустой экран. Что происходит, если ranking model отвечает 5 секундами? Timeout с deadline на 200 мс, использовать candidate generation scores как fallback. Что происходит при cold start (new user)? Demographic-based defaults + diversity-heavy exploration. Что при cold start item? Content-based boost 48 часов, потом collaborative signal. Канди dat, который ПРОАКТИВНО обсуждает эти scenarios без интервьюер pushing - сильный сигнал staff/principal level. Та же интуиция в SRE: 'design for failure' - типичная mantra Netflix Chaos Monkey культуры.

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

RecSys-собеседования пересекаются с несколькими дисциплинами:

• Архитектуры RecSys на масштабе — Netflix, YouTube, TikTok системы - canonical references для FAANG интервью
• Основы Collaborative Filtering — Базовый ML фундамент - без этого design ответы непонятны
• ML general interview — Тот же паттерн: формула, tradeoff, production reality
• Bayesian methods — A/B test stats и CTR estimation на байесовских моделях

Ключевые идеи

• **Design feed**: two-stage (candidate generation через ANN + ranking через DNN); latency budget определяет архитектуру; multi-objective с весами для CTR/watch_time/satisfaction
• **Design search**: hybrid retrieval (BM25 + dense), query understanding (normalize/intent/rewrite/personalize), multimodal (CLIP) для image search
• **Metrics**: multi-objective optimization, offline (NDCG, MAP) vs online (A/B); честное обсуждение Goodhart's Law и proxy-target gap
• **Production realities**: negative sampling (mixed: in-batch + hard + uniform), cold start (demographic + content-based), model serving (distill + GPU + cache), failure modes (FAISS down, ranking timeout)

Вопросы для размышления

• YouTube эволюция метрик 2012 → 2016 → 2019 (CTR → watch_time → satisfaction) - какой класс ошибок повторяется и какие инструменты могли бы их предупредить заранее?
• ByteDance Monolith vs Meta DLRM - архитектурно разные подходы к feature store. Какие операционные tradeoffs за каждым - и в каких командах какой подход применим?
• Если staff ML engineer получает USD 500K+, а PhD student в RecSys research - $80K stipend, какие конкретные production навыки создают эту разницу - и как их получить вне FAANG?

Связанные уроки

• rec-13 — Netflix/YouTube/TikTok архитектуры - база для большинства design вопросов
• rec-01 — Базовые понятия CF/content-based нужны как фундамент для архитектуры
• ml-13-svm — ML interview паттерн - тот же подход: формулы + tradeoffs + production realities
• ds-04-consistent-hashing — Шардинг user embeddings - прямая application distributed systems
• rt-13 — Realtime backend design - параллельный фреймворк system design
• prob-04-bayes — Метрики типа CTR estimation и A/B тесты на байесовских моделях
• ml-01-intro