Вопросы по ML System Design на собеседовании

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

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

• Мониторинг и дрифт11
• Масштабирование и трейдофы10
• Дизайн рекомендаций9
• Сервинг и деплой9
• Фичсторы и пайплайны9

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• ML System Design: фичсторы и пайплайны9 вопросов
• ML System Design: мониторинг и дрифт11 вопросов
• ML System Design: дизайн рекомендаций9 вопросов
• ML System Design: масштабирование и трейдофы10 вопросов
• ML System Design: сервинг и деплой9 вопросов

Примеры вопросов с разбором

1. #feature_stores_pipelines1 / 9
   Что такое point-in-time correctness при сборке обучающей выборки и чем грозит её нарушение?

   A)Строгое требование обязательно запускать процесс обучения модели ровно в полночь по серверу

   B)Обычная синхронизация часовых поясов между разными серверами системы

   C)Требование строгой монотонности всех используемых временных рядов фичей

   D)Фича — только по данным на момент таргета; иначе утечка из будущего

   показать ответ и разбор

   +D)Фича — только по данным на момент таргета; иначе утечка из будущего

   // разбор: Пример: предсказываем отток на 1 марта, а фича «число заказов за месяц» посчитана по витрине, обновлённой 5 марта — модель подсмотрела будущее. В проде такой информации нет, и качество рушится. Лечение: as-of join по таймстемпам (валидность фичи ≤ момента предсказания), snapshot'ы витрин, time-travel в feature store; сплиты — строго по времени.

2. #monitoring_drift2 / 9
   Что такое training-serving skew и какой архитектурный приём его устраняет?

   A)Разница размеров обучающей и продовой выборок; лечится увеличением датасета

   B)Обычное отставание версии какой-либо служебной библиотеки на боевом сервере инференса

   C)Различие форматов сериализации модели между pickle и, например, ONNX

   D)Фичи в трейне и проде считаются по-разному; лечит feature store и логи

   показать ответ и разбор

   +D)Фичи в трейне и проде считаются по-разному; лечит feature store и логи

   // разбор: Классика: в офлайне фичу считали по чистой витрине с завтрашней полнотой данных, в проде — по сырому стриму с задержками; модель офлайн блистала, в бою — нет. Лекарства: один код фичей для трейна и прода, point-in-time-корректные выборки, логирование фактически поданных фичей и переобучение именно на них.

3. #recsys_design3 / 9
   Почему рекомендательные системы строят в две стадии — кандидат-генерация и ранжирование?

   A)Так просто исторически сложилось ещё на давнем примере компании Netflix и её конкурса

   B)Скоринг всех айтемов нереален по латентности; лёгкая стадия сужает до сотен

   C)Две стадии на самом деле нужны для удобства A/B-тестов

   D)Кандидат-генерация повышает точность, а стадия ранжирования — скорость

   показать ответ и разбор

   +B)Скоринг всех айтемов нереален по латентности; лёгкая стадия сужает до сотен

   // разбор: Воронка «recall дёшево → precision дорого»: two-tower эмбеддинги с ANN-индексом (HNSW/FAISS) отбирают ~1000 кандидатов за миллисекунды, ранкер (бустинг/нейросеть с кросс-фичами) скорит только их. Разделение даёт и независимую эволюцию стадий, и смешение источников кандидатов. Практически стандарт: от ленты ВК до маркетплейсов.

4. #scaling_tradeoffs4 / 9
   P99-латентность ML-сервиса 900 мс при SLA 200 мс; профиль: 80% времени — подсчёт фичей с походами в 3 внешних сервиса. С чего начать оптимизацию?

   A)С фичей, а не модели: параллелить и кэшировать вызовы, таймауты с fallback

   B)Первым же делом просто закупить существенно более мощный и производительный GPU-ускоритель

   C)Сразу уменьшить саму модель через дистилляцию в компактного ученика

   D)Немедленно поднять число реплик сервиса ровно в два раза под нагрузкой

   показать ответ и разбор

   +A)С фичей, а не модели: параллелить и кэшировать вызовы, таймауты с fallback

   // разбор: Оптимизируют bottleneck: модель здесь — 20%. Сеть внешних вызовов — классический убийца хвостовых латентностей (P99 суммируется по худшим). Ходы: fan-out параллельно с бюджетом времени, онлайн-стор с предрассчитанными агрегатами, деградация до дефолтов фичей вместо таймаута всего запроса. Анализ importance vs стоимость фичи часто позволяет просто выкинуть дорогое.

5. #serving_deployment5 / 9
   Чем отличаются batch-инференс и online-инференс, и что выбрать для ежедневных персональных подборок в email-рассылке?

   A)Online-инференс предпочтительнее, потому что предсказания получаются свежее

   B)Batch подходит для сравнительно небольших по размеру моделей

   C)Batch — заранее по расписанию, online — по запросу; для рассылки batch

   D)Разница между ними лишь в размере обрабатываемого на GPU батча данных

   показать ответ и разбор

   +C)Batch — заранее по расписанию, online — по запросу; для рассылки batch

   // разбор: Правило системного дизайна: если решение не зависит от контекста «прямо сейчас» — не строй realtime. Batch снимает проблемы латентности, автоскейлинга и деградаций, а фичи можно брать тяжёлые. Online оправдан для поиска, ленты, антифрода в момент транзакции. Гибрид: предрассчитанные кандидаты + лёгкий realtime-реранкер.

6. #feature_stores_pipelines6 / 9
   Что такое feature store и какие две проблемы он решает в первую очередь?

   A)Это специальное хранилище уже обученных моделей вместе с их версиями

   B)Обычная база данных, предназначенная для хранения подобранных гиперпараметров

   C)Графический интерфейс, созданный для ручной разметки обучающих данных

   D)Централизованное хранилище фичей (офлайн+онлайн): убирает дубли и skew

   показать ответ и разбор

   +D)Централизованное хранилище фичей (офлайн+онлайн): убирает дубли и skew

   // разбор: Одна фича «активность юзера за 30 дней», посчитанная тремя командами по-разному, — норма жизни без feature store. Единое определение + материализация в офлайн (point-in-time выборки) и онлайн (низколатентное KV) слои дают переиспользование и согласованность. Честная оговорка: это инфраструктурная инвестиция — маленьким командам часто достаточно дисциплины и общего кода.

7. #monitoring_drift7 / 9
   Метки в проде приходят с задержкой в недели (дефолт по кредиту). Как мониторить деградацию модели до их появления?

   A)Прокси: дрейф фичей (PSI/KS), дрейф скоров, пропуски, бизнес-прокси

   B)Никак не мониторить — остаётся дожидаться прихода настоящих меток

   C)Отслеживать лишь техническую латентность работы сервиса модели

   D)Просто еженедельно переобучать модель вслепую на свежих данных

   показать ответ и разбор

   +A)Прокси: дрейф фичей (PSI/KS), дрейф скоров, пропуски, бизнес-прокси

   // разбор: Сдвиг входов и сдвиг скоров — ранние симптомы: если распределение предсказаний уехало, модель уже живёт в другом мире, даже если правда ещё не приехала. PSI > 0.2 — общепринятый тревожный порог. Хорошая практика — иерархия алертов: данные (пропуски/схема) → фичи (дрейф) → скоры → отложенное качество по меткам.

8. #recsys_design8 / 9
   Как решать проблему холодного старта нового айтема в рекомендациях маркетплейса?

   A)Просто не показывать новый айтем, пока он сам не наберёт статистику кликов

   B)Контентные фичи + перенос статистик с похожих + exploration-квота показов

   C)Показывать новый айтем подряд вообще всем, пока не накопятся первые клики

   D)Проблема холодного старта в рекомендациях нерешаема

   показать ответ и разбор

   +B)Контентные фичи + перенос статистик с похожих + exploration-квота показов

   // разбор: Коллаборативные сигналы у нового айтема нулевые — замещаем контентными: эмбеддинг описания/фото кладёт айтем рядом с похожими в векторном пространстве. Байесовское сглаживание CTR приором категории убирает шум ранней статистики; управляемая exploration-квота набирает сигнал без обрушения метрик (и без несправедливости к новым продавцам — это ещё и экосистемный вопрос).

9. #scaling_tradeoffs9 / 9
   Антифрод в момент платежа: бюджет 50 мс, миллионы транзакций в час, цена пропуска фрода высокая. Какой каркас системы адекватен?

   A)Каскад: правила → лёгкая модель на онлайн-счётчиках → тяжёлый разбор

   B)Одна большая нейросеть, которая скорит весь входящий трафик прямо в реалтайме без каскада

   C)Batch-скоринг раз в час — фрод вполне может немного и потерпеть

   D)Отдать весь скоринг транзакций на внешний аутсорс-сервис целиком

   показать ответ и разбор

   +A)Каскад: правила → лёгкая модель на онлайн-счётчиках → тяжёлый разбор

   // разбор: Каскад распределяет бюджет по цене ошибки: 95% явных случаев решает дешёвый слой, дорогая точность тратится на неоднозначные. Скользящие агрегаты (velocity-фичи) держат в онлайн-сторе — считать их на лету нельзя. Обязательные элементы зрелого дизайна: fallback-режим при отказе фичей, петля меток от разбора/чарджбеков, контроль дрейфа (фрод адаптируется быстрее всех).

Частые вопросы

• С чего начинать ответ на ML System Design?

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

• Зачем спрашивают про бейзлайн?

  Чтобы проверить прагматичность. Простое правило или логистическая регрессия часто закрывают большую часть эффекта и дают точку отсчёта, без которой невозможно оценить сложную модель.