В этой статье мы описываем блок D, посвященный автоматизированному рабочему процессу машинного обучения.
Всю схему, описывающую ключевые процессы MLOps, вы найдете здесь. Основные части схемы представляют собой горизонтальные блоки, внутри которых описаны процедурные аспекты MLOps (им присвоены буквы A, B, C, D). Каждый из них предназначен для решения конкретных задач в рамках обеспечения бесперебойной работы ML-сервисов компании.
С самого начала хотелось бы отметить, что в этой статье под системой ML мы понимаем информационную систему, содержащую один или несколько компонентов с обученной моделью, выполняющей некоторую часть общей бизнес-логики. Чем лучше развита модель МО, тем больше эффект от ее работы. Обученная модель обрабатывает входящий поток запросов и предоставляет в ответ некоторые прогнозы, автоматизируя некоторые части процесса анализа или принятия решений.
Процесс использования модели для генерации прогнозов называется выводом, а процесс обучения модели — обучением. Понятное объяснение разницы между ними можно позаимствовать у Gartner — здесь в качестве примера мы будем использовать кошек.
Для эффективной работы производственной системы ML важно отслеживать метрики вывода модели. Как только они начнут снижаться, модель необходимо переобучить или заменить на новую. Часто это происходит из-за изменения входных данных (дрейф данных). Например, есть бизнес-задача, в которой модель узнает хлеб на фотографиях, но вместо нее ей дают фотографию корги. Собаки в примере предназначены для баланса:
Модель в исходном наборе данных ничего не знала о корги, поэтому прогнозирует неправильно. Следовательно, набор данных необходимо изменить и провести новые эксперименты. В то же время новая модель должна быть запущена в производство как можно скорее. Пользователям не запрещено загружать изображения корги, и они получат ошибочный результат.
Теперь давайте посмотрим на более реальные примеры: давайте рассмотрим систему рекомендаций торговой площадки. На основе истории покупок пользователя, покупок похожих пользователей и других параметров модель или ансамбль моделей генерирует блок с рекомендациями. Сюда входят продукты, доход от покупки которых регулярно рассчитывается и отслеживается.
Что-то происходит, и потребности покупателей меняются. Поэтому рекомендации для них устаревают, а спрос на рекомендуемую продукцию снижается. Все это приводит к снижению доходов.
Дальше идут крики менеджеров и требования все восстановить к завтрашнему дню, которые ни к чему не приводят. Почему? Данных о новых предпочтениях покупателей недостаточно, поэтому невозможно даже создать новую модель. Конечно, вы можете взять некоторые базовые алгоритмы генерации рекомендаций (совместная фильтрация на основе элементов) и добавить их в производство. Таким образом, рекомендации хоть как-то подействуют, но это лишь временный «лейкопластырь».
В идеале процесс должен быть построен так, чтобы на основе метрик и без руководства со стороны менеджеров запускался процесс переобучения или экспериментирования с разными моделями. И лучший из них со временем заменяет текущий в производстве. На диаграмме это Автоматизированный конвейер рабочих процессов ML (блок D), который запускается в каком-либо инструменте оркестрации.
Это, наверное, самый нагруженный участок схемы. В работе Блока D задействовано несколько ключевых внешних компонентов:
- компонент оркестратора рабочего процесса отвечает за запуск конвейера по указанному расписанию или событию.
- хранилище функций предоставляет данные о функциях, необходимых для модели.
- реестр моделей и хранилище метаданных ML, куда помещаются модели и их метрики, полученные после завершения запущенного конвейера.
Структура блока по существу объединяет этапы экспериментирования © и разработки признаков (Б2). Это неудивительно, учитывая, что эти процессы необходимо автоматизировать. Основные различия заключаются в последних двух этапах:
- экспортная модель
- отправить в реестр моделей
Остальные этапы идентичны описанным выше.
Отдельно стоит отметить артефакты сервиса, необходимые оркестратору для запуска конвейеров переобучения модели. По сути, это код, который хранится в репозитории и выполняется на выделенных серверах. Версионируется и модернизируется по всем правилам разработки программного обеспечения. Именно этот код реализует конвейер переобучения модели, и от его корректности зависит результат.
Стоит отметить, что автоматизировать эксперименты вообще невозможно. Конечно, в процесс можно добавить концепцию AutoML, но на сегодняшний день не существует признанного решения, которое можно было бы использовать с одинаковыми результатами для любой темы эксперимента.
В целом AutoML работает следующим образом:
- Оно каким-то образом формирует набор комбинаций параметров работы модели.
- Он запускает эксперимент для каждой полученной комбинации.
- Он записывает метрики для каждого эксперимента, на основании которых выбирается лучшая модель.
По сути, AutoML выполняет все манипуляции, которые мог бы выполнить гипотетический Junior/Middle Data Scientist в кругу более-менее стандартных задач.
Мы немного рассмотрели автоматизацию. Далее необходимо организовать поставку новой версии модели в производство.
💡 Вас также может заинтересовать наша статья Ключевые процессы MLOps (часть 2): Feature Engineering, или разработка фич → https://hystax.com/key-mlops-processes-part-2-feature-engineering -или-развитие-функций.
✔️ OptScale, платформа с открытым исходным кодом FinOps и MLOps, которая помогает компаниям оптимизировать затраты на облако и повысить прозрачность использования облака, полностью доступна под Apache 2.0 на GitHub → https://github.com/hystax/optscale.