Эта статья была первоначально опубликована на MLOpsHowTo.com
TLDR; Реестр моделей MLflow позволяет отслеживать различные модели машинного обучения и их версии, а также отслеживать их изменения, этапы и артефакты. Сопутствующий Github Repo для этого поста
В нашем последнем посте мы обсудили важность отслеживания экспериментов, метрик и параметров Machine Learning. Мы также показали, как легко начать работать в этой области, используя возможности MLflow (для тех, кто не знает, MLflow в настоящее время является стандартной платформой де-факто для управления экспериментами и моделями машинного обучения).
В частности, Databricks еще больше упрощает использование MLflow, поскольку предоставляет вам полностью управляемую версию платформы.
Это означает, что вам не нужно беспокоиться о базовой инфраструктуре для запуска MLflow, и она полностью интегрирована с другими функциями машинного обучения из Databricks Workspaces, такими как Feature Store, AutoML и многими другими.
Возвращаясь к обсуждению экспериментов и управления моделями, хотя мы рассмотрели часть экспериментов в предыдущем посте, мы все еще не обсудили, как управлять моделями, которые мы получаем в ходе проведения экспериментов. Именно здесь на помощь приходит реестр моделей MLflow.
Необходимость в реестре моделей
По мере развития процессов создания, управления и развертывания моделей машинного обучения организациям необходима централизованная платформа, позволяющая различным персоналиям, таким как data scientist и инженеры машинного обучения, сотрудничать, обмениваться кодом, артефактами и контролировать этапы создания моделей машинного обучения. Разбивая это на функциональные требования, мы говорим о следующих желаемых возможностях:
- обнаружение моделей, визуализация результатов экспериментов и кода, связанного с моделями
- переход моделей через различные стадии развертывания, такие как Staging, Production и Archived
- развертывание различных версий зарегистрированной модели на разных этапах, предоставляя инженерам Machine Learning и MLOps возможность развертывать и проводить тестирование различных версий модели (например, A/B тестирование, многорукие бандиты и т.д.)
- архивирование старых моделей для отслеживания и соблюдения нормативных требований
- обогащение метаданных модели текстовыми описаниями и тегами
- управление авторизацией и управлением переходами и изменениями модели с помощью списков контроля доступа (ACL).
Типичный жизненный цикл модели MLOps с использованием MLflow
Начало работы с реестром моделей MLflow
Теперь перейдем к практической части. Мы запустим некоторый код для обучения модели и продемонстрируем возможности реестра моделей MLflow. Здесь мы представляем два возможных варианта запуска блокнотов из этого квикстартера: вы можете запустить их в Jupyter Notebooks с локальным экземпляром MLflow или в рабочем пространстве Databricks.
Блокноты Jupyter
Если вы хотите запустить эти примеры с помощью Jupyter Notebooks, выполните следующие шаги:
- Клонируйте это репозиторий Github на вашу локальную машину
- Убедитесь, что вы используете Python 3.8.7 (небольшая подсказка: вы можете использовать несколько версий Python на одной машине, установив pyenv).
- После установки Python 3.8.7 создайте виртуальную среду, выполнив команду python -m venv .venv
- Настройте виртуальную среду, выполнив make env. В качестве альтернативы вы можете сделать это вручную, выполнив следующие действия в терминале:
export SYSTEM_VERSION_COMPAT=1 &&
source .venv/bin/activate &&
pip install --upgrade pip &&
pip install wheel &&
pip install -r requirements.txt &&
pre-commit install
- Запустите первый блокнот jupyter/01_train_model.ipynb. Это создаст эксперимент и несколько запусков с различными гиперпараметрами для модели предсказания диабета.
- Запустите второй блокнот jupyter/02_register_model.ipynb. Этим мы зарегистрируем наш артефакт модели в реестре моделей MLflow. Мы также выполним несколько основных проверок на вменяемость, чтобы подтвердить, что наша модель может быть переведена в Staging.
- В этом примере мы запускаем простой локальный экземпляр MLflow с бэкендом SQLite — это достаточно хорошо для игрушечного примера, но не рекомендуется для тестовой или производственной установки. MLflow также можно запустить локально или удаленно как отдельное веб-приложение, а также с бэкендом Postgresql. Для получения более подробной информации о том, как этого достичь, пожалуйста, обратитесь к различным сценариям, представленным в этой ссылке.
Databricks
- Выполнение того же кода с Databricks Managed MLflow еще проще, поскольку среда уже настроена, когда вы используете кластер LTS ML. Пожалуйста, убедитесь, что у вас есть такой кластер, а затем клонируйте репозиторий в свое рабочее пространство. Для получения более подробной информации об интеграции Databricks с репо, пожалуйста, обратитесь к этой статье.
- Запустите первый блокнот
databricks/01_train_model.py. - Запустите второй блокнот
databricks/02_register_model.py. - Бонус: если вы запустите эти блокноты в рабочем пространстве Databricks, вы сможете визуализировать различные прогоны, связанные с вашим экспериментом:
Эксперименты, прогоны и модели
Глядя на скриншот выше, вы можете заметить, что в первой строке нашей таблицы, в столбце models, у нас есть значок, который отличается от других строк. Это связано с тем, что артефакт модели для этого конкретного прогона был зарегистрирован как модель, и была создана новая версия модели (версия 1).
Если мы нажмем на ее ссылку, мы будем перенаправлены в следующее окно.
В окне выше мы видим обзор версии модели, которая была зарегистрирована. Мы видим, что она имеет тег prediction_works = true. Мы также видим, что она находится в стадии Staging. В зависимости от того, какое лицо имеет доступ к этим данным, можно вручную изменить стадию (например, перевести модель в Production) или вернуть ее обратно в None.
Более того, с помощью списков контроля доступа к объектам рабочего пространства можно ограничить разрешения для каждого типа пользователей. Допустим, вы хотите запретить специалистам по анализу данных переходить на другие стадии модели, в то время как менеджеру команды вы хотите разрешить это делать. В таком сценарии специалисты по анализу данных должны будут запрашивать переход на определенную стадию.
Затем эти переходы должны быть одобрены кем-то с соответствующими полномочиями. Наконец, все запросы и переходы на стадии модели отслеживаются в одном окне (и, конечно, они также доступны программно).
После того, как модель переведена в Production, ее довольно просто развернуть либо как автоматизированное задание, либо как конечную точку REST API в режиме реального времени. Но это тема для другого поста.
Весь код, использованный в этом посте, доступен в этом Github Repo.