ML в производстве требует процессов ещё до появления MLOps
Почему компании, которые серьёзно занимаются машинным обучением, неизбежно приходят к необходимости версионировать не только код, но и данные, модели и эксперименты.
Команды, которые переходят от экспериментов с машинным обучением к реальному использованию моделей в продакшне, рано или поздно сталкиваются с одной и той же проблемой. Модель работает. Потом что-то меняется - данные, гиперпараметры, библиотека, - и никто не может точно воспроизвести то, что работало три месяца назад.
Это не академическая проблема. Это то, что происходит в реальных командах. И это сигнал, что машинное обучение требует другого уровня дисциплины по сравнению с обычной разработкой.
Что нужно версионировать и почему
В обычной разработке версионируется код. Git справляется с этим хорошо. В ML код - только одна из нескольких составляющих результата.
Данные. Если на одних и тех же данных обучается несколько вариантов модели - воспроизвести эксперимент можно. Если данные изменились, и исходный снимок не сохранён - воспроизвести нельзя. Изменение обучающего набора - это изменение, которое так же важно зафиксировать, как изменение кода.
Эксперименты. Дата-сайентист пробует разные конфигурации: архитектуры, гиперпараметры, наборы признаков. Через месяц сложно вспомнить, что именно давало лучший результат и почему. Эксперименты нужно логировать систематически - не в блокноте и не в памяти.
Модели. Файл с весами модели, который лежит на сервере без истории - это не версионирование. Нужно знать: какая версия модели работает в продакшне сейчас, от каких данных и с какими гиперпараметрами она обучена, каковы были метрики при обучении.
Среда. Версии библиотек, Python, зависимостей. Модель, которая давала хорошие результаты на Python 3.5 и scikit-learn 0.19, может вести себя иначе на другой версии. Среда - это часть воспроизводимости.
Почему это важно для бизнеса
Я разговариваю с руководителями, для которых версионирование модели звучит как техническая деталь. Это не деталь.
Первый практический аргумент: аудит. Если модель принимает решения, влияющие на клиентов - кредитный скоринг, ценообразование, приоритизация - нужна возможность воспроизвести, какая именно модель приняла конкретное решение в конкретный момент.
Второй аргумент: восстановление. Если новая версия модели дала худшие результаты, нужна возможность быстро откатиться. Без версионирования это либо невозможно, либо требует нескольких дней работы.
Третий аргумент: накопление знаний. Команда дата-сайентистов меняется. Знания о том, что работает, а что нет, должны жить не только в головах людей.
С чего начать
У этих процессов нет общепринятого названия в 2018 году. Через несколько лет это назовут MLOps. Но необходимость в них возникает раньше, чем появляется удобный термин.
Начать можно с малого:
- Логировать все эксперименты в простой структуре - дата, параметры, метрики результата.
- Хранить снимки обучающих данных с явными идентификаторами версий.
- Сохранять артефакты модели (файлы весов) с привязкой к коммиту кода и версии данных.
- Документировать среду - хотя бы в формате requirements.txt или Docker-образа.
- Ввести процесс: любое изменение модели в продакшне проходит через фиксированный набор шагов.
Это не требует специализированного инструментария сразу. Это требует дисциплины и договорённостей внутри команды. Инструменты можно добавить позже - на готовую культуру они ложатся значительно лучше.