Пилот показал точность на отложенной выборке, презентация прошла, спонсор доволен. Через полгода модель так и не работает в продакшене. Это типичный финал: по отраслевым оценкам до 80% корпоративных ML-проектов не доходят до промышленной эксплуатации. Причина почти никогда не в самой модели – она в инфраструктуре, процессах и ответственности за работу системы после запуска. MLOps закрывает именно этот разрыв между ноутбуком дата-сайентиста и нагруженным сервисом.

Чем продакшен отличается от пилота

В пилоте данные статичны, метрики считаются один раз, а код живёт в Jupyter. В эксплуатации всё иначе: данные приходят потоком, распределение признаков смещается, а сервис должен отвечать под SLA и переживать перезапуски. Поэтому первый шаг – воспроизводимость. Версионируйте не только код, но и данные, признаки и сами артефакты модели. Без фиксации версии обучающего датасета вы не воспроизведёте инцидент и не докажете регулятору, на чём обучалась модель, – а для госсектора и финансов это обязательное требование.

Второй разрыв – данные. Признаки в обучении и в инференсе должны считаться одинаково, иначе вы получите training-serving skew: модель видит в бою не то, на чём училась. Решает это единый слой признаков поверх корпоративного хранилища. Если вы строили DWH на отечественном стеке, как мы разбирали ранее, feature store логично разворачивать там же – тогда офлайн-обучение и онлайн-инференс берут данные из одного источника.

Конвейер: от обучения до отката

Промышленный ML – это автоматизированный конвейер, а не ручной запуск скрипта. Минимальный рабочий контур включает:

  • CI/CD для моделей – тесты на данные, обучение, валидацию метрик и упаковку артефакта запускает пайплайн, а не человек.
  • Реестр моделей – каждая версия со своими метриками, датасетом и стадией (staging, production, archived).
  • Канареечный или теневой выкат – новая версия сначала обслуживает малую долю трафика или работает параллельно без влияния на ответ.
  • Быстрый откат – переключение на предыдущую версию занимает минуты и не требует пересборки.

Контейнеризация и оркестрация дают переносимость: один и тот же образ едет в облако, в on-premise и в закрытый контур госзаказчика без переписывания. Это особенно важно, когда инфраструктура распределена между средами – здесь применима та же дисциплина выкатов, что и в мобильной разработке, о которой мы писали в обзоре года RuStore.

Мониторинг и переобучение

Модель деградирует молча. Точность падает не из-за бага, а из-за дрейфа данных: меняется поведение клиентов, ассортимент, законодательство. Поэтому в проде нужно мониторить три слоя – технический (латентность, ошибки), статистический (распределение входов и предсказаний) и бизнес-метрики (конверсия, доля отказов). На отклонения вешайте алерты и триггеры переобучения.

Отдельный контур – генеративные модели и LLM. Их нельзя оценивать классической метрикой точности, нужны проверки на галлюцинации, утечку данных в промптах и стабильность ответов; базовый разбор того, как устроены эти модели, мы давали в материале о ChatGPT и LLM. Для корпоративного контура к этому добавляется обязательный человек в петле на критичных решениях и журналирование всех запросов для аудита.

Вывод

MLOps – это не набор инструментов, а инженерная дисциплина: воспроизводимость, автоматизированный конвейер, мониторинг и понятная ответственность за модель в бою. Пилот доказывает гипотезу, продакшен приносит деньги и между ними лежит именно эта работа: от feature store до мониторинга дрейфа и регламентов переобучения, выстроенных под конкретный контур и регуляторные требования при внедрении интеллектуальных систем в промышленную эксплуатацию.