MLOps-пайплайн: навчання, валідація, деплой та моніторинг

ML-проєкт без MLOps — це Jupyter-ноутбук на ноутбуці дата-саєнтиста, модель у вигляді .pkl-файлу десь на файловій шари та деплой через «скопіюй на сервер вручну». Коли модель потрібно перенавчити на нових даних або відкотитися до попередньої версії — починається ручна робота. Відтворити експеримент через місяць неможливо: ніхто не пам'ятає, який датасет використовувався і які гіперпараметри були. Результат — втрачені 30–40% часу на відтворення та зростання MTTR до 2–3 днів. DevOps для ML — наша спеціалізація. Ми автоматизуємо повний цикл: від навчання до моніторингу, використовуючи MLflow та Evidently AI.

Ми будуємо MLOps-пайплайни під ключ: автоматизуємо навчання, валідацію, деплой та моніторинг. Наш досвід — 15+ проєктів із впровадження MLOps на Kubernetes. Гарантуємо відтворюваність та швидкий відкат моделі. Типова економія часу на налагодження — 50%. Хочете так само? Отримайте консультацію — оцінимо ваш проєкт за 1 день.

Чому validation gate критичний для MLOps-пайплайну?

Костиль, який часто пропускають, але дарма. Validation gate — етап порівняння метрик нової моделі з production-моделлю. Якщо f1-score нової моделі нижчий на 2% — пайплайн зупиняється, модель не деплоїться.

def validate_model(new_model_uri: str, production_model_name: str, threshold: float = 0.02):
    client = mlflow.tracking.MlflowClient()
    prod_model = client.get_latest_versions(production_model_name, stages=["Production"])[0]
    prod_metrics = client.get_run(prod_model.run_id).data.metrics
    new_run_id = mlflow.get_run(mlflow.active_run().info.run_id).info.run_id
    new_metrics = client.get_run(new_run_id).data.metrics
    f1_delta = new_metrics["f1_score"] - prod_metrics["f1_score"]
    if f1_delta < -threshold:
        raise ValueError(
            f"New model f1={new_metrics['f1_score']:.4f} is worse than "
            f"production f1={prod_metrics['f1_score']:.4f} by {abs(f1_delta):.4f}"
        )
    return True

Додатково перевіряється data drift: якщо розподіл вхідних ознак нового датасету значно відрізняється від тренувальних даних — це сигнал, що модель навчена на нерелевантних даних. Для цього використовуємо Evidently AI або scipy.stats для статистичних тестів (KS-test, PSI).

Як деплоїти модель з мінімальним ризиком?

Після проходження validation gate модель реєструється в Model Registry (MLflow Registry, Vertex AI, Sagemaker) і деплоїться. Стратегії деплою для ML-моделей:

Canary deployment — нова модель отримує 10% трафіку, стара — 90%. Метрики бізнес-якості (CTR, конверсія, RMSE) порівнюються протягом 24–48 годин. Якщо добре — поступово перемикається весь трафік. Shadow mode — нова модель отримує всі запити, але її відповіді не використовуються клієнтом. Відповіді логуються та порівнюються з production-моделлю. Нульовий ризик для користувачів, повна інформація про поведінку нової моделі. Порівняння: canary deployment дозволяє скоротити час виявлення проблем у 2–3 рази порівняно з blue-green, а shadow mode — єдиний спосіб протестувати модель на повному трафіку без наслідків.

Оркестрація: Kubeflow vs Airflow vs Argo Workflows

Kubeflow у 3 рази скорочує час налаштування пайплайнів порівняно з написанням скриптів вручну. Для команд з існуючим Kubernetes-кластером — Argo Workflows (мінімальний overhead) або Kubeflow Pipelines (якщо потрібна повна MLOps-платформа). Airflow — якщо вже використовується для data engineering пайплайнів.

Моніторинг у production та автоматичний відкат

Деплой моделі — не фінал. Потрібен моніторинг:

• Data drift: розподіл вхідних ознак з часом змінюється. Evidently AI генерує HTML-звіти щодо дрейфу, інтегрується з Grafana через custom metrics.
• Prediction drift: розподіл прогнозів змінюється без зміни даних — ознака проблеми з моделлю або даними.
• Business metrics: CTR, конверсія, RMSE на реальних даних — збирається окремо та порівнюється з baseline.

При виявленні значущого дрейфу (наприклад, PSI > 0.2) — автоматичний тригер перенавчання. Якщо нова модель на продакшені показує погіршення метрик більш ніж на 5% — налаштуємо автоматичний rollback до попередньої стабільної версії. Час відкату — не більше 30 секунд. Забезпечуємо 99.9% uptime кластера та 95th percentile latency моделі менше 50 ms.

Кроки побудови MLOps-пайплайну

1. Аудит поточного ML-процесу: виявлення вузьких місць (відтворюваність, швидкість деплою).
2. Вибір стеку: Kubeflow / Argo Workflows, MLflow, Evidently AI.
3. Організація Feature Store та версіонування даних (DVC або S3-based).
4. Розробка пайплайну навчання з тригерами (CronJob, подієвий).
5. Налаштування validation gate (метрики + дрейф).
6. Реалізація деплою (canary / shadow).
7. Налаштування моніторингу та алертів (Grafana + Telegram/Slack).
8. Документація runbook та навчання команди.

---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: ml-training-cron
spec:
  schedule: "0 3 * * 1"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: ml-training
              image: registry.example.com/trainer:latest
              env:
                - name: DATASET_VERSION
                  value: "latest"
          restartPolicy: Never

Що входить у нашу роботу

• Проєктування пайплайну під ваш стек (PyTorch, TensorFlow, sklearn, XGBoost)
• Налаштування MLflow для експериментів та Model Registry
• Розгортання Kubeflow або Argo Workflows на вашому Kubernetes
• Інтеграція з GitLab CI / GitHub Actions для CI/CD пайплайнів
• Моніторинг дрейфу та алертинг (Grafana + Telegram/Slack)
• Документація runbook та навчання команди

Отримайте консультацію з автоматизації ML-процесу. Оцінимо ваш проєкт за 1 день — просто напишіть нам. Свяжіться з нами для демонстрації готових рішень. Типовий бюджет впровадження — від 3000 до 10000 у.о.