MLOps: разрыв между экспериментом и производством
Почему большинство ML-экспериментов не доходят до продакшна и что с этим делать на организационном уровне.
Есть характерная ситуация, которую я наблюдаю в компаниях, начавших работу с машинным обучением. Data scientist обучил хорошую модель. Метрики на тестовой выборке выглядят убедительно. Демонстрация на встрече впечатляет. Потом начинается "передача в разработку" - и что-то идёт не так.
Иногда модель так и не появляется в продакшне. Иногда появляется, но ведёт себя не так, как на демонстрации. Иногда работает первый месяц, а потом незаметно деградирует, потому что данные изменились, а никто не следит.
Это называется ML production gap - разрывом между экспериментом и работающей системой. И это организационная проблема не меньше, чем техническая.
Почему эксперимент и продакшн живут в разных мирах
Эксперимент оптимизирован для скорости и гибкости. Ноутбук, история версий в локальных файлах, данные загружены однажды, модель обучена и оценена. Цель - понять, работает ли идея.
Продакшн оптимизирован для надёжности и воспроизводимости. Данные должны приходить регулярно и в стандартном формате. Модель должна работать одинаково в любое время суток. Должен быть мониторинг. Должен быть процесс обновления при деградации.
Это принципиально разные требования к одному и тому же артефакту - модели. И разрыв между ними не закрывается сам по себе.
Что входит в MLOps и зачем это знать руководителю
MLOps - это набор практик и инструментов, которые помогают переводить ML-эксперименты в надёжно работающие системы. Руководителю не нужно знать детали реализации, но полезно понимать, что входит в эту работу.
Версионирование данных и кода - чтобы любой результат можно было воспроизвести. Конвейеры обучения - чтобы модель можно было переобучить без ручной работы при изменении данных. Деплой и версионирование моделей - чтобы откатиться, если новая версия хуже старой. Мониторинг качества в продакшне - чтобы знать, когда модель начинает деградировать.
Без этого слоя ML-проект либо застрянет на этапе эксперимента, либо создаст непрозрачную систему, которую страшно трогать.
Признаки, что проблема есть
Несколько сигналов, которые я слышу как симптомы:
"У нас есть хорошие модели, но мы не можем их быстро выкатить" - нет процесса деплоя.
"Модель работала хорошо, а потом начала давать странные результаты" - нет мониторинга дрейфа данных или качества.
"Только Иван знает, как переобучить эту модель" - нет воспроизводимых конвейеров.
"Мы запустили новую версию, старая уже не вернуть" - нет версионирования.
Каждый из этих симптомов - отдельный организационный и технический долг.
Практические шаги
Для большинства небольших ML-проектов не нужна сложная MLOps-платформа. Нужно минимальное, но работающее:
- Любой эксперимент записывается - данные, параметры, метрики. Минимум: структурированный журнал, лучше специализированный трекер экспериментов.
- Деплой модели - не ручная операция, а повторяемый процесс. Хотя бы скрипт с документацией.
- В продакшне есть метрики качества модели, а не только метрики производительности системы.
- Есть ответственный за здоровье модели в продакшне - человек, который получает алерт и принимает решения.
Это не MLOps в полном объёме. Но это разница между системой, которая живёт, и системой, которая деградирует незаметно.