ML system design на собеседовании Data Scientist
Что такое ML system design
ML system design — это собеседовательный формат, в котором кандидат проектирует production ML-систему end-to-end: от данных и фичей до деплоя и мониторинга. Главный отличающий этап senior DS от middle.
В отличие от обычной задачи про ML («какой алгоритм выберешь»), system design просит спроектировать ВСЁ: какие данные, как их собирать, как валидировать модель, как замерить online-эффект, как поддерживать в production. На собесе Data Scientist этот этап даёт 60-90 минут и часто решает оффер.
Структура ответа на ML system design
1. Уточняющие вопросы (5-10 минут)
Не прыгай к решению. Уточни:
- Бизнес-цель. Что улучшаем — revenue / retention / CR / NPS
- Метрика успеха. Что значит «модель работает»
- Масштаб. Сколько юзеров, сколько событий в день
- Ограничения. Latency, бюджет, регуляторика
- Существующее решение. Есть ли baseline, который нужно перебить
Без этих вопросов невозможно дать структурированный ответ — и интервьюер это знает.
2. Декомпозиция системы
Раскладываешь на компоненты:
- Data collection — где брать данные, как логировать
- Feature engineering — какие фичи, как их вычислять (offline / online / real-time)
- Modeling — какой алгоритм, как валидировать
- Inference — где деплоить, какая latency
- Monitoring — как мерить online-эффект, как ловить drift
- A/B testing — как замерить impact в production
3. Углубление по запросу
Интервьюер выберет один-два компонента для углубления: «расскажи про feature engineering подробнее», «как ты будешь решать cold start», «что делать, если модель деградирует через 3 месяца».
4. Trade-off-ы
В каждом решении называй trade-off. «Real-time фичи дороже offline, но дают актуальность. Здесь нужны offline — поток данных и так с задержкой 4 часа».
Главные шаблоны кейсов
Recommender system
Сценарий: «Спроектируй рекомендации для главной страницы маркетплейса».
Структура ответа:
- Уточнения. Какой контекст показа (карточка / главная / поиск), какая цель (CR / GMV / retention).
- Данные. Юзер-логи (просмотры, корзины, покупки), товарные характеристики, контекстуальные данные (время, сегмент юзера).
- Подход. Two-stage: candidate generation (collaborative filtering, content-based) → ranking (gradient boosting на feature interactions).
- Метрики. Offline: NDCG, MAP, recall@k. Online: CR, GMV, time-to-purchase.
- Cold start. Для новых юзеров — popularity-based. Для новых товаров — content-based на товарных характеристиках.
- Production. Pre-compute embeddings, real-time ranking. Batch update раз в день.
Fraud detection
«Модель для детекции фрода в платёжной системе».
- Уточнения. Каков baseline rate fraud (обычно <1%), что считается fraud, во время или после транзакции.
- Данные. История транзакций, поведение юзера, гео, устройство, network эффект (друзья, общие IP).
- Подход. Несбалансированный класс → весовые классы, sampling. Gradient boosting (interpretable) или anomaly detection.
- Метрики. Precision при заданном recall (бизнес-критерий — сколько false positives бизнес может терпеть). Cost-aware: разные ошибки имеют разную цену.
- Production. Real-time inference (≤100ms), online learning или частое retraining (drift сильный).
- Adversarial. Fraudster адаптируется, модель устаревает. Нужно постоянное retraining.
Search ranking
«Ранжирование результатов поиска товаров».
- Уточнения. Какой query type (specific / broad / browse), что измеряем (CR / GMV).
- Данные. Query + product pairs, юзер-клики, покупки, returns.
- Подход. Learning-to-rank (LambdaMART, нейросеть с pairwise loss).
- Метрики. Offline: NDCG@10, MRR. Online: CR в поиске, GMV per search.
- Personalization. Контекст юзера (segment, history) как фичи.
Demand forecasting
«Прогноз спроса для склада».
- Уточнения. Гранулярность (товар / категория / регион), горизонт (день / неделя / квартал).
- Данные. История продаж, цены, акции, сезонность, погода.
- Подход. ARIMA / Prophet baseline. CatBoost с временными фичами. Для нейросетей — LSTM или Temporal Fusion Transformer.
- Метрики. MAPE, WAPE (для разных категорий). Business metric — stockout / overstock rate.
- Production. Batch inference раз в день. Retraining раз в неделю.
Churn prediction
«Модель оттока для подписочного продукта».
- Уточнения. Что считаем churn (cancel / inactive 30d / etc), горизонт (когда уйдёт).
- Данные. Активность юзера, payment history, поддержка, segments.
- Подход. Survival analysis или классификация с временным окном. Gradient boosting.
- Метрики. Offline: AUC, calibration. Online: retention rate в группе обработанных.
- Action. Не модель сама по себе, а связка модель + retention интервенция (push / скидка / звонок CS).
Частые ошибки
- Прыгать к модели без уточнений. «Возьму XGBoost» в первые 30 секунд — провал
- Игнорировать data layer. ML начинается с данных. Как они собираются, как очищаются — важнее модели
- Не назвать online-метрики. Offline AUC — не доказательство успеха. Нужен A/B и бизнес-метрика
- Игнорировать deployment. Latency, batching, A/B инфраструктура — часть system design
- Зубрить «two-tower»/«embedding» без понимания. На уточнение «как именно учить embeddings» нужен ответ
- Не учитывать cold start. Любая система рано или поздно встречается с новыми entities
Подготовка: план
- Прорешать 10+ кейсов вслух. На запись, по 20-30 минут каждый.
- Книга: «Designing Machine Learning Systems» Чип Хюэн — фундамент.
- Изучить production-кейсы. Блоги Yandex, Tinkoff, Ozon, Авито, Netflix, Uber.
- Освоить термины: two-tower, online learning, batch vs streaming, drift detection.
- Знать инфраструктуру: PyTorch, ONNX, Triton, Spark, Kafka, feature stores.
FAQ
Что важнее — точность модели или production-надёжность?
Production. Модель с AUC 0.85, падающая раз в неделю, хуже, чем AUC 0.78 со стабильной работой. На собесе ждут понимания этого баланса.
Сколько минут говорить на каждый компонент?
Грубо: 5 минут уточнений → 15 минут общая структура → 20-30 минут углубление по запросу → 5 минут trade-off-ы и заключение.
Можно ли просить нарисовать на доске?
Да, нужно. Диаграмма «данные → фичи → модель → inference → метрики» помогает структурировать ответ и понятнее интервьюеру.
Что делать, если не знаю конкретный инструмент?
Честно: «Я не работал с конкретно этим инструментом, но решал похожую задачу через X». Делать вид что знаешь — хуже.
Спрашивают ли low-level детали (memory, latency)?
В senior+ позициях — да. Готовь mental model «как обучить модель на 1B примерах», «как сократить inference с 50ms до 10ms».