MLOps — дитя DevOps и ML

Один ML-проект в проде вам или два другому? Внедрение машинного обучения в производственную среду остаётся одной из главных проблем индустрии. По статистике, 80% ML-проектов никогда не доходят до продакшена. Однако хитрые опсы и тут решили выделиться, и в результате появился MLOps — методология, которая поможет вам сократить путь от эксперимента до деплоя с месяцев до дней. В этой статье мы пройдёмся по верхам MLOps и посмотрим на фундаментальные принципы и конкретные инструменты.

Почему нельзя просто взять DevOps и приделать к нему ML?

Казалось бы, у нас уже есть отлаженные процессы: CI/CD, мониторинг, IaC. Бери и применяй. Но тут уже не всё так просто.

В классическом DevOps центральный артефакт — это код. Написал, протестировал, задеплоил. В MLOps у нас всё чуть сложнее: код, данные и модель. И все три компонента живые — меняются независимо друг от друга. Код может быть идентичным, но если данные поменялись, модель будет вести себя по-другому.

Жизненный цикл тоже отличается. Привычный Build ? Test ? Deploy ? Monitor превращается в Data Prep ? Train ? Validate ? Deploy ? Monitor ? Retrain. Причём триггеры для CI/CD срабатывают не только на изменения в коде, но и на изменения в данных. И самое весёлое — предсказуемость. Обычное ПО детерминировано: один и тот же вход даёт один и тот же выход. ML-модели хаотичны и зависят от данных, на которых обучались.

Четыре столпа методологии MLOps

MLOps — DevOps с обширным набором DLC. Но эти DLC действительно качественные, контента там много и он хорош.

• Continuous Integration (CI) — если раньше мы тестировали только код, то теперь область расширяется. Модели и данные так же нуждаются в тестировании и валидации.

• Continuous Delivery (CD) здесь означает автоматический деплой не просто приложения, а целого ML-пайплайна плюс сервис предсказаний.

• Continuous Training (CT) — вот это уже уникальная для ML штука. Модели деградируют со временем, данные меняются, а мы же не хотим что-либо делать сами руками, поэтому нужно как-то автоматически переобучаться. Без этого ваша красивая модель через полгода превратится в тыкву.

• Continuous Monitoring (CM) отслеживает не только стандартные метрики вроде latency и error rate, но и специфичные ML-показатели: accuracy, drift, качество данных.

Google выделяет три уровня зрелости MLOps. На нулевом всё делается руками через Jupyter Notebooks. На первом уровне автоматизируется переобучение модели при появлении новых данных. На втором — полная автоматизация сборки, тестирования, деплоя и обучения. Большинство команд застревают где-то между нулём и единицей.

Уникальные вызовы ML-проектов

Давайте чуть подробнее разберём, с какими главными проблемами могут столкнуться MLOps-инженеры.

Дрейф данных — ваш главный враг в проде

Самая неприятная проблема в ML-продакшене — это дрейф. Модель обучилась на одних данных, но прошло время и в реальном мире данные изменились. И однажды вы обнаруживаете, что модель предсказывает полную чушь.

Дрейф бывает нескольких выдов:

• Дрейф признаков — когда меняется распределение входных данных.

• Концептуальный дрейф — когда меняется сама связь между входом и выходом. Классический пример — COVID-19, который за пару месяцев поломал все модели прогнозирования поведения потребителей.

• Дрейф предсказаний — когда распределение выходов модели начинает отличаться от ожидаемого.

Для обнаружения дрейфа применяются статистические тесты: критерий Колмогорова-Смирнова для сравнения распределений, индекс стабильности популяции (PSI), который любят финансисты, дивергенция Йенсена-Шеннона. Из инструментов самые популярные — Evidently AI, Fiddler, WhyLabs.

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

Feature Store — чтобы не считать одно и то же сто раз

Моделируем ситуацию: у вас пять команд дата-саентистов, и каждая считает одни и те же признаки для своих моделей. Отдельно для обучения, отдельно для инференса. И, конечно, считают они все немного по-разному. Звучит не очень хорошо?

Feature Store решает эту проблему. Архитектура простая: есть офлайн-хранилище для исторических данных (Hive, S3) и онлайн-хранилище для быстрого доступа (Redis, DynamoDB). Feast — одно из популярных open-source решений. Он заранее загружает значения признаков в быстрое хранилище, поэтому при запросе предсказания данные отдаются мгновенно.

Но тут тоже нужно не переусердствовать. Feature Store нужен, когда модель должна отвечать мгновенно, несколько команд используют одни признаки или когда важна воспроизводимость данных на определённый момент времени. Для простых моделей, работающих по расписанию в маленьких командах, это оверкилл.

Популярные инструменты

Теперь предлагаю пройтись по самым популярным инструментам MLOps, в ходе которого сделаем обзор на каждый.

MLflow: эксперименты под контролем

Истории, о которых невозможно молчать: дата-саентист прибегает и говорит «модель, которую я обучал в прошлый вторник, была лучше». Какая модель? С какими параметрами? На каких данных?

MLflow решает эту проблему. Это открытая платформа, которая включает:

• Tracking — сердце системы, по сути состоит из API и веб-интерфейса для логирования всего, что только можно: параметры, метрики, артефакты, версии кода.

• Projects — компонент для структурирования и упаковки кода. Обеспечивает стандартизацию, чтобы эксперимент можно было воспроизвести на другой машине без танцев с бубном

• Models — единый формат для моделей. И тут уже неважно, sklearn это, PyTorch или что-то экзотическое.

• Model Registry — централизованное хранилище, где модели версионируются и проходят через все стадии до прода, как релизы в нормальном CI/CD.

На практике выглядит просто:

import mlflow from sklearn.ensemble import RandomForestClassifier  with mlflow.start_run():     clf = RandomForestClassifier(n_estimators=100, max_depth=5)     clf.fit(X_train, y_train)          mlflow.log_param("n_estimators", 100)     mlflow.log_param("max_depth", 5)     mlflow.log_metric("accuracy", accuracy_score(y_test, clf.predict(X_test)))     mlflow.sklearn.log_model(clf, "model")

Для совсем ленивых есть отличная функция mlflow.autolog(). Добавляем одну строчку в начало скрипта, и MLflow сам подтянет параметры и метрики из популярных фреймворков. Магия? Нет, хорошая работа инженеров.

Weights & Biases — MLflow на стероидах

W&B — это как MLflow, только в облаке и с очень красивыми графиками. Серьёзно, их визуализация — одна из лучших, что я видел. Если MLflow надо разворачивать и поддерживать самому, то W&B работает из коробки: зарегистрировался, поставил библиотеку, и можно уже предсказывать стоимость жилья в Лос-Анджелесе.

Система включает не только трекинг экспериментов, там также есть ещё несколько полезных компонентов:

• Sweeps даёт нам возможность автоматически подобрать гиперпараметры. По сути мы просто задаём пространство поиска, алгоритм сам перебирает комбинации, пока вы пьёте кофе и листаете рилсы.

• Artifacts — версионирование данных и моделей, чтобы бесконечно не плодить файлы с названиями по типу model_final_v2_FINAL_real.pkl.

• Reports — интерактивные отчёты, которые можно шарить с командой. Это ваше спасение, когда надо показать результаты менеджеру, который хочет смотреть на красивый график, а не страшный код

Минус один — это облачный сервис, и данные уходят на их серверы. Не каждая компания, может себе это позволить, сливать чувствительные данные не хочется никому. Есть self-hosted версия, но она платная и недешёвая.

Kubeflow — когда у вас много GPU и ещё больше амбиций

До этого мы смотрели на инструменты для трекинга экспериментов, но нам же ещё нужно как-то строить инфраструктуру и работать с ней. Для этого есть Kubeflow — целый комбайн для ML на Kubernetes, включающий все необходимые инструменты, начиная от разработки и экспериментов и заканчивая деплоем с последующей оркестрацией.

Звучит круто, но есть нюанс. Kubeflow сложный. Очень сложный. Если у вас ещё нет Kubernetes-кластера и команды, которая умеет его готовить, даже не смотрите в эту сторону. Потратите месяц на настройку вместо работы над моделями.

Kubeflow оправдан, когда у вас масштабные ML-проекты с распределённым обучением на нескольких GPU, десятки дата-сайентистов, которым нужны изолированные окружения и сложные пайплайны с кучей зависимостей. Если же это просто стартап на 3 человек, то будет оверкилл.

DVC: Git для данных

Git отлично справляется с кодом, но нам же надо хранить не только нашу кодовую базу, но и датасет. А что делать, если датасет весит несколько ГБ? Не будем же мы пушить это всё на Git. DVC (Data Version Control) решает эту проблему.

Принцип работы реализован красиво и со вкусом: вместо самих данных в репозитории мы храним только их метаданные в виде .dvc файлов с хешами, а вот сами датасеты лежат во внешнем хранилище. И когда мы переключимся на другую ветку, DVC автоматически подтянет нужную версию данных из хранилища. Поддерживаются все популярные стораджи: S3, GCS, Azure Blob, SSH, HDFS, и даже Google Drive для небольшого стратапа на коленке.

Давайте взглянем на работе с DVC на практике. Базовый алгоритм для инициализации нового проекта:

dvc init dvc remote add -d myremote s3://mybucket/dvcstore dvc add data/dataset.csv git add data/dataset.csv.dvc .gitignore git commit -m "Add dataset v1" dvc push

Теперь Ваш коллега просто клонирует репозиторий, делает dvc pull — и вот у него те же данные, что у Вас. В итоге получили версионирование, воспроизводимость и никаких «а у меня другой датасет был».

Feast: золотой стандарт Feature Store

Про Feature Store я уже упоминал выше и теперь хочу обсудить самый популярный инструмент для его реализации

Для начала взглянем на его архитектуру:

• Offline store — хранилище для исторических данных, тут живут BigQuery, Snowflake или просто Parquet-файлы. Используется для обучения моделей.

• Online store — быстрое хранилище для инференса, обычно Redis или DynamoDB. Здесь нам важна скорость отклика. Также большой плюс, что Feast умеет синхронизировать данные между этими двумя слоями.

Теперь давайте взглянем на пример, как это работает в деле. Допустим, у нас есть признак «средний чек клиента за последние 30 дней». Для обучения модели мы считаем его из исторических данных. А вот при инференсе лезть в хранилище и считать на лету мы себе позволить не можем, это слишком медленно. Поэтому Feast заранее вычислит и положит в быстрое хранилище, и тогда при запросе предсказания мы получим данные за миллисекунды.

Ещё один бонус — point-in-time корректность. Суть простая: при обучении модели признаки должны соответствовать тому моменту времени, когда произошло событие. Иначе мы получим data leakage — когда наша модель смотрит в будущее, на тесте выдаёт accuracy 95%, а в проде выдаёт рандомные предсказания. Например, мы случайно считаем средний чек клиента на сегодня, а не на момент его покупки, и модель видит транзакции, которых по сути ещё не было. Feast гарантирует нам, что подобных ситуаций не будет, и признаки соответствуют моменту времени, когда произошло событие.

Seldon Core и BentoML: деплой моделей в продакшен

Модель мы обучили, метрики хорошие, теперь нам надо её как-то задеплоить так, чтобы она отвечала на запросы. Тут нас встречают два инструмента:

Seldon Core — решение под Kubernetes. Поддерживает почти всё, что может понадобиться: TensorFlow, PyTorch, XGBoost, sklearn, Hugging Face. Также из коробки даёт A/B-тестирование, канареечные релизы, автомасштабирование, позволяет строить графы вывода, когда одна модель вызывает другую. Сильный инструмент для сильной команды.

BentoML — Python-фреймворк, он попроще в использовании. Мы просто пишем декоратор над функцией предсказания, а BentoML сам генерирует Docker-образ, API и документацию. Также умеет группировать мелкие запросы в один для эффективной обработки на GPU.

Summary: если уже есть Kubernetes и сильные инженеры, которые его администрируют, и при этом нужны сложные сценарии деплоя, то Seldon Core — ваш выбор. Если хочется быстро завернуть модель в API без лишней инфраструктуры, то советую BentoML.

Apache Airflow и Prefect: оркестрация пайплайнов

ML-пайплайн — это не просто обучил модель и доставил в прод. Пайплайн сложный и долгий: загрузка данных, валидация, препроцессинг, обучение, оценка, деплой. И всё это надо как-то запускать по расписанию или по триггеру.

Apache Airflow — ветеран рынка, которому уже почти десять лет. Работает через DAG (направленные ациклические графы), где каждый узел — это таска. Огромное количество готовых операторов для интеграции с чем угодно: базы данных, облака, мессенджеры. Минус — DAG определяется статически, динамически генерировать задачи неудобно. И настройка Airflow — не самая приятная вещь, придётся покопаться в документации в поисках scheduler, webserver, executor, базы данных, очередей сообщений и т. д.

Prefect позиционирует себя как «Airflow нового поколения». Вместо статических DAG — декоративный Python-код, граф строится динамически при выполнении. Можно запустить пайплайн локально без какой-либо инфраструктуры, как обычный Python-скрипт. Также есть облачная версия Prefect Cloud с красивым UI.

Если у вас уже есть Airflow и команда его знает — смысла мигрировать нет. Если начинаете с нуля — Prefect проще в освоении. Я считаю это большим плюсом, что можно сначала отладить пайплайн локально, а потом уже думать про инфраструктуру.

Great Expectations и Evidently: качество данных и мониторинг

Две библиотеки, которые решают разные, но связанные задачи.

Great Expectations реализует задачу валидации данных. Нам достаточно описать что мы хотим видеть. Например, «в этой колонке не должно быть null», «значения должны быть от 0 до 100», «уникальных значений должно быть не больше 1000». А библиотека уже сама проверяет датасет и генерирует отчёт.

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

Evidently — решение для мониторинга дрейфа. Сравнивает распределения данных между обучением и продом, считает метрики дрейфа, генерирует отчёты. Большой плюс — простота интеграции с Prometheus, что даёт нам красивые дашборды в Grafana и алерты.

Они отлично работают в связке. Great Expectations проверяет данные перед обучением, Evidently мониторит дрейф в проде. Если Evidently увидит сильный дрейф, то кидает алерт, который в свою очередь триггернёт запуск переобучения.

CI/CD: всё знакомо, но какое-то другое

В ML CI/CD главное отличие в том, что мы тестируем не только код, но и данные с моделями. Давайте взглянем, что именно хочется тестировать:

• Unit-тесты: здесь мы проверяем обработку пропущенных значений, форму выходных данных, диапазон предсказаний;

• Интеграционные тесты: прогоняем полный пайплайн от начала до конца и проверяем интеграцию с Feature Store;

• Валидация модели: мы обязательно должны сравнить новую модель и актуальную в проде, так как нередко при деплое происходит деградация.

Плюс появляется Continuous Training — автоматическое переобучение при поступлении новых данных, обнаружении дрейфа или деградации метрик

Мониторинг моделей в продакшене

Метрики можно разделить на несколько категорий:

• Операционные: тут классика: latency, throughput, error rate.

• Качество модели: accuracy, F1, AUC, RMSE, могут варьироваться в зависимости от задач.

• Качество данных: смотрим на пропущенные значения, нарушения схемы, аномалии.

• Дрейф: мониторим распределения входных данных и предсказаний.

• Бизнес-метрики: то, ради чего всё затевалось. Включают конверсию, влияние на выручку.

Классический стек состоит из Evidently, который вычисляет ML-метрики, затем экспортирует в Prometheus и далее всё это визуализируется в Grafana. В целом ничего нового.

A/B-тестирование и многорукие бандиты

Давайте посмотрим на общепринятые стратегии выкатки ML-моделей. Многие из них, я думаю, вы уже видели:

• Shadow deployment — новая модель работает параллельно, но не влияет на пользователей.

• Canary — постепенно увеличиваем трафик от 1% до 100% на новую модель. Если что, безопасно откатываемся при проблемах.

• A/B-тестирование — здесь всё по классике: делим пользователей на группы и сравниваем бизнес-метрики.

• Blue/Green — мгновенное переключение между версиями. Большой плюс — быстрый откат, но для этого нужно держать две версии.

• Multi-Armed Bandits — интересная альтернатива A/B. Вместо фиксированного распределения 50/50, алгоритм динамически направляет больше трафика на лучшую модель. Thompson Sampling — популярный алгоритм этого семейства, использует бета-распределение для оценки вероятности успеха каждой модели.

Собираем всё вместе

Отлично, мы прошлись по куче инструментов. Но как же нам собрать всех этих рейнджеров в одного? Давайте посмотрим на типичный MLOps-пайплайн, который можно собрать из open-source компонентов:

??????????????????????????????????????????????????????????????????????????????? ?                            DATA LAYER                                       ? ?  ???????????????    ???????????????    ???????????????                      ? ?  ?   Sources   ???> ?     DVC     ????>?    Feast    ?                      ? ?  ?  (S3, DB)   ?    ? (версии)    ?    ?  (features) ?                      ? ?  ???????????????    ???????????????    ???????????????                      ? ???????????????????????????????????????????????????????????????????????????????                                                 ?                                                 ? ??????????????????????????????????????????????????????????????????????????????? ?                         TRAINING PIPELINE                                   ? ?  ???????????????    ???????????????    ???????????????    ???????????????   ? ?  ?    Great    ????>?   Training  ????>?   MLflow    ????>?   Model     ?   ? ?  ?Expectations ?    ?   (GPU)     ?    ?  (tracking) ?    ?  Registry   ?   ? ?  ???????????????    ???????????????    ???????????????    ???????????????   ? ?                                                                  ?          ? ?                         Orchestration: Airflow / Prefect         ?          ? ???????????????????????????????????????????????????????????????????????????????                                                                    ?                                                                    ? ??????????????????????????????????????????????????????????????????????????????? ?                          SERVING LAYER                                      ? ?  ???????????????    ???????????????    ???????????????                      ? ?  ?   BentoML   ????>? Kubernetes  ????>?   Canary    ?                      ? ?  ? / Seldon    ?    ?  (deploy)   ?    ?  / A|B      ?                      ? ?  ???????????????    ???????????????    ???????????????                      ? ???????????????????????????????????????????????????????????????????????????????                                                 ?                                                 ? ??????????????????????????????????????????????????????????????????????????????? ?                        MONITORING LAYER                                     ? ?  ???????????????    ?????????????????    ???????????????                      ? ?  ?  Evidently  ????>? Prometheus  ????>?   Grafana   ????                   ? ?  ?  (drift)    ?    ?  (metrics)  ?    ? (dashboards)?  ?                   ? ?  ???????????????    ???????????????    ???????????????  ?                   ? ?                                                         ?  ???????????????  ? ?                       Alerting <??????????????????????????>?  Retrain    ?  ? ?                                                            ?  Trigger    ?  ? ?                                                            ???????????????  ? ???????????????????????????????????????????????????????????????????????????????

Теперь разберём, как данные проходят по этому пайплайну

Data Layer. Сырые данные лежат в S3 или базе, DVC следит за версиями датасетов, Feast готовит признаки и раздаёт их для обучения и инференса. На этом этапе важно, чтобы DS-команда и прод использовали одни и те же признаки — иначе будете неделю искать, почему модель в проде ведёт себя странно.

Training Pipeline. Данные пришли, значит можно запускать обучение. Сначала Great Expectations проверяет качество, и если проверка упала, то пайплайн останавливается. Дальше собственно обучение на GPU, MLflow пишет все метрики и параметры, лучшая модель уходит в Model Registry со статусом Staging. Весь этот оркестр дирижирует Airflow или Prefect, их главная задача — следить за зависимостями, ретраями, расписанием.

Serving Layer. Модель прошла валидацию, а значит можно и в прод. BentoML или Seldon упаковывают всё в контейнер, затем деплоимся в Kubernetes. Далее канареечный релиз. Тут же не забываем A/B-тестирование для сравнения новой модели со старой.

Monitoring Layer. Модель уже крутится в продуктовом окружении, Evidently считает дрейф и метрики качества, экспортирует в Prometheus, Grafana рисует дашборды. Настроен алертинг: кидаем сообщения об аномалиях, а если видим большой дрейф, то триггерим переобучение.

На практике не обязательно использовать все эти инструменты сразу. Как и везде, начинаем с малого и постепенно строим систему.

Заключение

MLOps — это не просто очередной набор модных инструментов, которые можно установить и забыть. Это скорее способ сделать так, чтобы дата-сайентисты, ML-инженеры и админы наконец-то начали разговаривать на одном языке и перестали перекидывать модели по коворкингу со словами «у меня локально всё работало».

P. S.: 10% от выручки с оперативной памяти себя заберут MLOps-инженеры, успевайте залететь в этот поезд невиданной щедрости.

© 2026 ООО «МТ ФИНАНС»