MLOps Pipeline

87% ML-моделей так и не попадают в продакшен. Разрыв между работающим Jupyter-ноутбуком и надежной production-системой огромен - и MLOps закрывает этот разрыв инструментами для версионирования, отслеживания и автоматизации.

• **Uber Michelangelo** - внутренняя MLOps-платформа, через которую проходят все ML-модели компании: от предсказания времени прибытия до обнаружения мошенничества. Без единой системы отслеживания и деплоя каждая команда изобретала свои велосипеды
• **Spotify** использует Kubeflow для оркестрации рекомендательных пайплайнов: сотни моделей обучаются параллельно на данных миллионов пользователей, а experiment tracking позволяет откатиться к предыдущей версии модели за минуты
• **Tesla Autopilot** - каждая итерация модели версионируется вместе с данными (миллионы кадров с камер). Без DVC-подобного инструмента невозможно отследить, на каких именно данных обучена модель, которая сейчас ездит в реальных машинах

Предварительные знания

• Cross-Validation and Overfitting Prevention

Когда машинное обучение встретило технический долг

Годами команды считали обученную модель финишной чертой, а потом наблюдали, как она гниёт в продакшене по причинам, которым никто не дал имени. В 2015 группа из Google под руководством D. Sculley опубликовала на NeurIPS статью 'Hidden Technical Debt in Machine Learning Systems', и она прозвучала громко. Мысль была прямой: модель это крошечный квадратик на гораздо большей схеме. Вокруг неё сбор данных, извлечение признаков, конфигурация, раздача предсказаний и мониторинг, и именно в этой обвязке копится настоящая стоимость. Авторы каталогизировали режимы отказов, которые практики чувствовали, но не могли сформулировать: запутанность (поменяешь одно, меняется всё), скрытые петли обратной связи, незадекларированные зависимости по данным и 'glue code', держащий систему вместе. Статья дала индустрии общий словарь для объяснения, почему ML в продакшене это сложно. Около 2018 года оформился сам термин MLOps, заимствовавший дисциплину DevOps и адаптировавший её к системам, где поведение определяет не только код, но и данные. Практика CD4ML (Continuous Delivery for Machine Learning) расширила CI/CD на версионирование данных и моделей, автоматическое переобучение и валидацию, превратив предупреждения Скалли в инженерный процесс.

MLflow

MLflow - это open-source платформа от Databricks для управления полным жизненным циклом ML-моделей. Она решает три ключевые задачи: **отслеживание экспериментов** (Tracking) - логирование параметров, метрик и артефактов каждого запуска; **реестр моделей** (Model Registry) - версионирование и стадии моделей (Staging, Production, Archived); **деплой моделей** (Models) - единый формат упаковки для развертывания на любой платформе. MLflow не привязан к конкретной ML-библиотеке: он работает с scikit-learn, PyTorch, TensorFlow, XGBoost и любым другим фреймворком.

Ядро MLflow - это Tracking API. Каждый запуск обучения (run) записывается с полным контекстом: какие гиперпараметры использовались (`log_param`), какие метрики получены (`log_metric`), какие файлы созданы (`log_artifact`). Runs группируются в эксперименты (experiments). Все данные доступны через веб-интерфейс `mlflow ui`, где можно сравнивать запуски, фильтровать по метрикам, строить графики.

**MLflow Model Registry - управление жизненным циклом модели:** После обучения модель регистрируется в реестре с версией: ``` mlflow.register_model( "runs:/<run_id>/random-forest-model", "IrisClassifier" ) ``` Каждая зарегистрированная модель проходит стадии: - **None** - только что зарегистрирована - **Staging** - проходит тестирование - **Production** - обслуживает реальный трафик - **Archived** - снята с продакшена Это позволяет откатиться к предыдущей версии одной командой, если новая модель деградирует в продакшене.

MLflow Models предоставляет единый формат упаковки моделей - **MLmodel**. Независимо от того, обучена модель в scikit-learn, PyTorch или TensorFlow, MLflow оборачивает её в стандартный интерфейс с методом `predict()`. Это позволяет деплоить модель как REST API (`mlflow models serve`), Docker-контейнер, или в облачные сервисы (AWS SageMaker, Azure ML, Databricks) без изменения кода.

DVC - Data Version Control

Git отлично версионирует код, но не справляется с большими файлами данных. Попытка закоммитить CSV на 10 GB или папку с миллионом изображений превратит репозиторий в неуправляемого монстра. **DVC (Data Version Control)** решает эту проблему: он работает *поверх* Git, добавляя версионирование для данных и моделей. Данные хранятся в удалённом хранилище (S3, GCS, Azure Blob, SSH), а в Git попадают только легковесные `.dvc`-файлы с хешами - указатели на конкретные версии данных.

Рабочий процесс с DVC начинается с `dvc init` в Git-репозитории. Затем `dvc add data.csv` создает файл `data.csv.dvc` - метафайл с md5-хешем, размером и путем к данным. Сам `data.csv` добавляется в `.gitignore`, а `.dvc`-файл коммитится в Git. При `dvc push` данные загружаются в настроенное удаленное хранилище. Коллега клонирует репозиторий, запускает `dvc pull` - и получает те же данные.

**DVC Pipelines - автоматизация ML-процесса:** DVC умеет не только версионировать данные, но и описывать ML-пайплайны. Файл `dvc.yaml` определяет стадии (stages), их зависимости и выходы: ``` stages: preprocess: cmd: python src/preprocess.py deps: - src/preprocess.py - data/raw.csv outs: - data/processed.csv train: cmd: python src/train.py deps: - src/train.py - data/processed.csv params: - train.n_estimators - train.max_depth outs: - models/model.pkl metrics: - metrics.json: cache: false ``` Команда `dvc repro` запускает только те стадии, чьи зависимости изменились. Если изменился только `train.py`, preprocess не перезапускается.

Главное преимущество DVC - **воспроизводимость через Git-историю**. Каждый Git-коммит фиксирует конкретную версию кода, параметров и данных. Через полгода можно вернуться к любому коммиту, запустить `dvc checkout` и `dvc repro` - и получить в точности те же результаты. Без DVC типичная ситуация: "модель работала месяц назад, но мы не помним, на каких данных и с какими параметрами".

Kubeflow и оркестрация

Когда ML-проект вырастает из одного скрипта `train.py` в систему из десяти связанных этапов (сбор данных, очистка, feature engineering, обучение нескольких моделей, оценка, A/B тестирование, деплой), возникает потребность в **оркестрации**. Оркестратор управляет порядком выполнения шагов, перезапускает упавшие, масштабирует на кластер, отслеживает статус. **Kubeflow** - наиболее популярный оркестратор для ML, работающий на базе Kubernetes.

Kubeflow Pipelines SDK позволяет описывать ML-пайплайны на Python. Каждый шаг оформляется как **компонент** - функция с явными входами и выходами. Компоненты автоматически упаковываются в Docker-контейнеры и запускаются в Kubernetes. Между компонентами данные передаются через артефакты. SDK автоматически строит DAG (направленный ациклический граф) зависимостей и оптимизирует порядок выполнения.

**Когда MLflow достаточно, а когда нужен оркестратор:** **MLflow достаточно, если:** - Один человек или маленькая команда - Пайплайн линейный: данные -> обучение -> оценка - Запуск вручную или по cron - Нет требований к масштабированию на кластер **Оркестратор нужен, если:** - Сложные зависимости между шагами (DAG) - Нужна автоматическая обработка ошибок и retry - Параллельное обучение нескольких моделей - Масштабирование на кластер GPU - Расписания, триггеры, условная логика - Требуется аудит и compliance MLflow и Kubeflow не конкуренты - они дополняют друг друга. Kubeflow оркестрирует шаги, а MLflow внутри каждого шага логирует параметры и метрики.

Выбор оркестратора зависит от контекста. Если в компании уже есть Kubernetes и сильная инфраструктурная команда - Kubeflow. Если ML-команда маленькая и нужен быстрый старт - Prefect или Dagster. Если основная задача - воспроизводимость экспериментов, а не масштабирование - DVC Pipelines. Главное - не выбирать инструмент сложнее, чем требует задача: для одной модели с еженедельным переобучением Kubeflow - это перебор.

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

Experiment Tracking и воспроизводимость

В ML существует **кризис воспроизводимости**: по исследованиям, значительная часть опубликованных результатов не воспроизводится другими исследователями. Причина - не злой умысел, а сложность ML-экспериментов. Результат зависит не только от кода и данных, но и от **десятков скрытых факторов**: версии библиотек, порядка данных, seed генератора случайных чисел, типа GPU, версии CUDA-драйвера. Experiment tracking фиксирует все эти факторы, делая каждый эксперимент воспроизводимым.

**Weights & Biases (wandb)** - один из самых популярных инструментов для experiment tracking. В отличие от MLflow, wandb предоставляет облачную платформу с богатой визуализацией: графики обучения в реальном времени, сравнение экспериментов, автоматическое логирование hardware-метрик (GPU utilization, RAM), интеграция с PyTorch, TensorFlow, Hugging Face. Бесплатный тариф покрывает нужды одиночного исследователя.

На практике experiment tracking начинается с малого: логирование гиперпараметров и метрик через MLflow или wandb. Со временем добавляются: версионирование данных (DVC), логирование окружения (pip freeze, Docker image), сохранение артефактов (модели, графики). Важно начать **до того, как проект станет сложным** - ретроспективно восстановить контекст экспериментов почти невозможно.

**Минимальный MLOps для одиночного Data Scientist:** 1. **Git** - версионирование кода (обязательно с первого дня) 2. **DVC** - версионирование данных и моделей (добавить при первом датасете > 100 MB) 3. **MLflow/wandb** - логирование экспериментов (добавить при втором эксперименте) 4. **Docker** - фиксация окружения (добавить перед деплоем) 5. **CI/CD** - автоматизация тестов и деплоя (добавить при регулярном переобучении) Каждый следующий уровень добавляется по мере роста сложности проекта. Не нужно настраивать Kubeflow для модели, которая обучается за 5 минут на ноутбуке.

Итоги

• **MLflow** - платформа для отслеживания экспериментов (log_param, log_metric, log_artifact), реестра моделей (Staging/Production/Archived) и деплоя: не привязана к фреймворку и запускается одной командой
• **DVC** - Git для данных: .dvc файлы с хешами хранятся в Git, а реальные данные - в S3/GCS. `dvc repro` запускает только измененные стадии пайплайна, а `git checkout + dvc checkout` возвращает к любой версии кода + данных
• **Kubeflow и оркестрация** - когда пайплайн вырастает из одного скрипта в DAG из десятков шагов, оркестратор управляет порядком, перезапусками, масштабированием. Kubeflow для больших команд, Prefect/Dagster для маленьких, DVC Pipelines для одиночек
• **Experiment tracking** - кризис воспроизводимости решается фиксацией полного контекста: код, данные, параметры, окружение, hardware. Те самые 87% моделей, не дошедших до продакшена, - во многом жертвы отсутствия систематического отслеживания экспериментов

Связанные темы

MLOps Pipeline связывает инструменты ML с инженерными практиками - от обучения модели до её жизни в продакшене:

• Model Serving — Следующий шаг после MLOps - как развернуть обученную модель для обслуживания запросов: REST API, gRPC, batch inference, и выбор между real-time и offline предсказаниями
• Monitoring — После деплоя модели нужно отслеживать её поведение в продакшене: data drift, concept drift, деградацию метрик. MLOps обеспечивает инфраструктуру для мониторинга и автоматического переобучения
• Cross-Validation — MLflow и wandb логируют результаты cross-validation как метрики эксперимента. DVC фиксирует конкретные split-ы данных, обеспечивая воспроизводимость оценки модели
• Hyperparameter Tuning — Experiment tracking незаменим при подборе гиперпараметров: каждый запуск grid search или Bayesian optimization автоматически логируется, и лучшая конфигурация находится одним запросом к MLflow или wandb

Вопросы для размышления

• допустим, что вы работаете над ML-проектом в одиночку. Какие элементы MLOps вы бы внедрили на первой неделе, а какие отложили бы? Почему?
• Компания хочет перейти от ручного деплоя моделей к автоматизированному MLOps-пайплайну. С какого инструмента вы бы начали: MLflow, DVC или Kubeflow? Какие факторы определяют этот выбор?
• Как связаны версионирование данных (DVC) и воспроизводимость экспериментов? Достаточно ли только версионировать код в Git для полной воспроизводимости ML-модели?

Связанные уроки

• ml-44-cross-validation — Валидация - этап пайплайна
• ml-46-model-serving — Пайплайны выкатывают модели в serving
• ml-47-model-monitoring — Пайплайны питают мониторинг после деплоя
• ml-43-hyperparameters — Автотюнинг работает в пайплайне
• sd-09-message-queue — Очереди оркеструют этапы пайплайна
• devops-09