MLOps на собеседовании Data Scientist

Зачем MLOps на собесе DS

MLOps — про то, как ML-модель доставляется в продакшен и поддерживается. На собесе junior-DS глубоко не спросят, но базовое понимание ожидается. Middle+ — обязательно.

Что проверяют:

• Понимание пайплайна от обучения до prod
• Serving: batch vs online, latency
• Мониторинг и переобучение
• A/B-тесты моделей

DS, который умеет только тренировать модели в Jupyter — junior. DS, который понимает, как модель попадает к пользователю и как поддерживается — middle+.

Pipelines: train, validate, deploy

Полный цикл ML-модели:

1. Data collection — собираем данные из source-систем
2. Data validation — проверяем качество, schema, distribution
3. Feature engineering — создаём фичи (часто из feature store)
4. Training — обучаем модель
5. Validation — проверяем метрики на held-out set
6. Registration — сохраняем модель в model registry
7. Deployment — выкатываем в serving
8. Monitoring — следим за метриками в проде

Инструменты:

• MLflow, Kubeflow, Vertex AI — оркестрация
• DVC, lakeFS — версионирование данных
• Airflow — оркестрация ETL для ML

Model serving

Главное архитектурное решение — batch vs online.

Batch inference

Модель применяется на больших объёмах данных раз в N часов/дней. Результаты сохраняются в БД, фронт читает оттуда.

Плюсы: простой, дёшев. Минусы: задержка от события до предсказания.

Подходит для: рекомендации (раз в день), churn prediction, scoring.

Online inference

Модель отвечает на запрос в реальном времени. Latency 10-100 ms.

Плюсы: актуальные предсказания. Минусы: нужна инфраструктура (REST/gRPC, autoscaling, monitoring).

Стек: FastAPI/BentoML/TorchServe + Kubernetes + Prometheus.

Подходит для: anti-fraud, ad ranking, dynamic pricing.

Streaming inference

Гибрид. Модель применяется к стриму событий (Kafka), результат пишется в БД или другой стрим.

На собесе спросят: «Когда выберешь batch, когда online?» Ответ: если допустима задержка > 1 час и предсказание не зависит от свежайших фичей — batch. Иначе online.

Мониторинг моделей

В проде модель деградирует со временем. Что мониторим:

Технические метрики

• Latency (p50, p95, p99)
• Error rate (5xx, timeouts)
• QPS (queries per second)
• Memory, CPU

ML-метрики

• Distribution входных фичей (feature drift)
• Distribution предсказаний (prediction drift)
• Качество предсказаний (когда есть ground truth)
• Калибровка (для классификации)

Бизнес-метрики

• CTR, conversion для рекомендаций
• True positive rate для anti-fraud
• Revenue lift

Data drift и model drift

Data drift

Распределение входных данных меняется. Например, средний возраст пользователей вырос, или появилась новая категория продуктов.

Метрики drift:

• PSI (Population Stability Index) — для категориальных и binned numerical
• KL divergence, JS divergence — для распределений
• Kolmogorov-Smirnov test — для непрерывных

Model drift / concept drift

Связь между фичами и target меняется. Модель работала, теперь работает хуже.

Например: covid изменил поведение пользователей в e-commerce, старая модель recommendations стала менее точной.

Решение — переобучение по расписанию или триггеру (drift detected).

A/B тесты моделей в проде

Перед раскатом новой модели — A/B-тест. Стандарт:

1. Контрольная группа — текущая модель (baseline)
2. Тестовая группа — новая модель
3. Случайное разделение по user_id (50/50, 90/10 на старте)
4. Метрики — primary (бизнес-метрика), secondary (ML-метрика), guardrails (latency, error rate)
5. Длительность — пока не наберём statistical power

На собесе спросят: «Что если модель показывает лучший recall, но хуже precision?» Ответ: смотрим, какая метрика была primary, и какие guardrails. Финальный решение принимается по primary, но с проверкой, что guardrails не сломаны.

Multi-armed bandit

Альтернатива A/B — динамически перераспределяем трафик в пользу лучшей модели. Используется для рекомендаций и ads.

Эксперимент-трекинг и feature store

MLflow / Weights & Biases

Записывают каждый эксперимент: гиперпараметры, метрики, артефакты, версия датасета. Без этого — хаос.

Feature store

Централизованное хранение фичей с consistency между training и serving.

Главная проблема без feature store: фича вычислялась одним способом в обучении (на pandas), другим — в проде (на Spark/streaming). Result — silent prediction errors.

Инструменты: Feast, Tecton, Hopsworks. В РФ — обычно собственные решения на ClickHouse или Hive.

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

Тренировать модели только в Jupyter. Без воспроизводимого пайплайна — модель не попадёт в prod.

Не версионировать данные. Если данные меняются, и нет версии — не можешь воспроизвести эксперимент.

Игнорировать latency. Тяжёлая модель с лучшим качеством — может быть неприемлема при requirement 50ms.

Не мониторить input distribution. Distribution shift ловится за пару дней, если есть мониторинг. Без мониторинга — спустя месяцы, когда падают бизнес-метрики.

Деплоить без A/B. Новая модель может быть хуже на distribution prod (отличается от train). A/B — единственный надёжный способ проверки.

FAQ

Сколько MLOps нужно для junior DS?

Минимум: понимать batch vs online inference, использовать MLflow для tracking, уметь развернуть модель через FastAPI.

Сколько MLOps для middle?

Дополнительно: feature store basics, drift detection, A/B-тесты моделей, deployment patterns.

Чем MLOps отличается от DevOps?

DevOps — деплой кода. MLOps — деплой моделей + данных. Главное отличие — модели деградируют без изменений в коде, потому что меняются данные. Поэтому мониторинг и переобучение — часть процесса.

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

Нет. Статья основана на индустриальных практиках и опыте кандидатов.