Модель, показывающая 92% точности в блокноте, не приносит компании ценности, пока не попадёт в продакшен. Главная боль data-science-команд именно здесь: путь от модели к API и от API к устойчивой эксплуатации. MLOps — дисциплина, которая этот путь карту.
Пять слоёв MLOps
- Feature Store: различия в расчёте одной и той же фичи при обучении и в проде (training-serving skew) — главная причина смерти моделей. Feast, Databricks Feature Store обеспечивают согласованность.
- Model Registry: какая версия модели обучена на каком датасете, с какими гиперпараметрами и с какой производительностью? MLflow, W&B, Azure ML registry хранят этот инвентарь.
- CI/CD for Models: модель должна быть тестируема и деплоябильна как код. Unit-тесты (схема данных), integration-тесты (пайплайн), canary-деплой (разделение трафика).
- Мониторинг: в продакшене качество модели может падать (data drift, concept drift). Мониторинг prediction distribution, feature distribution и аномалий бизнес-KPI обязателен.
- Retraining Pipeline: модель — не разовая артефакта, а актив, обновляемый через feedback-петлю. Условия авто-переобучения должны быть определены заранее (падение метрик, периодически, с новыми данными).
Уровни зрелости
Зрелость MLOps обычно оценивают по трёхуровневой модели Google:
- Level 0: ручной деплой. Data scientist копирует блокнот в прод. Подходит маленьким командам, не масштабируется.
- Level 1: автоматизированное обучение, ручной деплой.
- Level 2: полный CI/CD: автоматические обучение, деплой, мониторинг. Retraining запускается по feedback-петле.
Большинство турецких компаний находятся между Level 0 и Level 1. Переход к Level 2 — проект на 9-12 месяцев фокусированной работы.
Выбор инструментов
- Tracking: MLflow (open source, широкое распространение), W&B (сильный UX для команд), Azure ML (Azure-native).
- Pipeline: Kubeflow (Kubernetes-native), Airflow (data + ML гибрид), Prefect (Python-native).
- Serving: Seldon, BentoML, KServe, Triton (GPU-ёмкие).
- Мониторинг: Arize, WhyLabs, Evidently (open source).
Рекомендуемый поэтапный подход
У банковского клиента в Турции проект MLOps развивался по компактной последовательности: сначала перенос двух пилотных моделей в MLflow, затем CI/CD на Azure DevOps, затем drift-мониторинг с Evidently, в итоге — каталог из 15 моделей. Девятимесячный проект утроил продуктивность data-science-команды и снизил затраты на эксплуатацию моделей на 60%.
