Привет, Хакернун! В этой статье я подробно рассмотрю концепцию MLOps. Причем сделаю это 3 способами. Сначала теоретически — через самую разумную схему MLOps. Затем концептуально через артефакты, заложенные в подходе. И, наконец, через понимание MLOps как информационной системы. Итак, начнем. Что такое МЛОпс? Этот вопрос уже давно занимает умы многих команд разработчиков систем машинного обучения. Под такой системой в этой статье я буду понимать информационную систему, один или несколько компонентов которой содержат обученную модель, выполняющую некоторую часть общей бизнес-логики. Как и любой другой компонент системы, эту часть бизнес-логики необходимо обновлять, чтобы она соответствовала меняющимся ожиданиям бизнеса и клиентов. MLOps посвящен этому регулярному обновлению. Определение и объяснение MLOps Единого и согласованного определения MLOps еще не существует. Многие авторы пытались его дать, но найти одновременно четкое и систематическое описание было непросто. Есть , который можно считать таким: один MLOps — это инженерная дисциплина, целью которой является унификация разработки (разработки) систем ML и развертывания систем ML (ops) для стандартизации и оптимизации непрерывной поставки высокопроизводительных моделей в производство. Давайте выделим критические части определения MLOps: Инженерная дисциплина Направлен на унификацию процессов разработки и развертывания систем машинного обучения. Стандартизирует и оптимизирует непрерывную доставку новых версий. Высокопроизводительные модели Итак, MLOps — это разновидность DevOps для моделей ML. История возникновения МЛОпс Несложно поверить, что такая инженерная дисциплина зародилась в крупной ИТ-компании. Так что можно доверять теории о том, что MLOps как осмысленный подход зародился в Google, где Д. Скалли пытался сэкономить свои нервы и время от рутинных задач по выводу моделей ML в расширения. Д. Скалли сейчас широко известен как «Крестный отец MLOps» — одноименный легко найти в сети. подкаст Д. Скалли стал рассматривать работу с моделями с точки зрения технического долга команды. Да, можно быстро выпускать новые версии моделей, но стоимость поддержки получившейся системы окажет существенное влияние на бюджет компании. Результатом его работы стала статья « опубликовано в 2015 году на конференции NeurIPS. Дату публикации этой статьи можно считать отправной точкой существования MLOps. Скрытый технический долг в системах машинного обучения Уровни зрелости MLOps: самые известные модели Как и большинство ИТ-процессов, MLOps имеют уровни зрелости. Они помогают компаниям понять, где они сейчас находятся и как могут перейти на следующий уровень (если есть такая цель). Также общепринятые методы определения зрелости позволяют определить свое место среди конкурентов. Модель зрелости GigaOm MLOps Наиболее подробно описанная и во многом понятная модель — от аналитической компании . Из всех моделей он наиболее близок к интеграции модели зрелости возможностей (CMMI). Это комплекс методологий улучшения организационных процессов, который также состоит из 5 уровней – от 0 до 4. GigaOm Модель GigaOm раскрывает каждый уровень зрелости по 5 категориям: стратегия, архитектура, моделирование, процессы и управление. Руководствуясь этой моделью на ранних этапах построения системы ML, вы сможете заранее продумать существенные аспекты и снизить вероятность неудачи. Переход от одного уровня зрелости к более высокому ставит перед командой новые задачи, о существовании которых они, возможно, раньше не подозревали. Модель зрелости Google MLOps Стоит отметить, что у Google также есть своя . Оно появилось одним из первых. Он лаконичный и состоит из 3 уровней: модель уровней зрелости MLOps Уровень 0: Ручной процесс Уровень 1: автоматизация конвейера машинного обучения Уровень 2: автоматизация конвейера CI/CD Трудно отделаться от мысли, что эта модель напоминает инструкцию по рисованию совы. Сначала сделайте все вручную, соберите конвейеры ML и доработайте MLOps. Тем не менее, это хорошо описано. Модель зрелости Azure MLOps Сегодня многие крупные компании, использующие ML, разработали свои модели зрелости. , который использует аналогичный подход для различения уровней. Однако их больше, чем у Google: Лазурный Уровень 0: Нет MLOps Уровень 1: DevOps, но без MLOps Уровень 2: Автоматизированное обучение Уровень 3: Автоматическое развертывание модели Уровень 4: Полная автоматизация операций MLOps Все выделенные модели сходятся примерно в одном. На нулевом уровне – отсутствие каких-либо практик ОД. На последнем уровне у них автоматизация процессов MLOps. В середине всегда есть что-то особенное, связанное с постепенной автоматизацией процессов. В Azure есть автоматизация процесса обучения и последующего развертывания модели. Концептуальная основа MLOps Как вы опишете все процессы, связанные с концепцией MLOps? Удивительно, но трое немцев – авторов статьи» » — даже удалось инкапсулировать их в одну диаграмму. Они провели настоящее исследование и очень подробно описали концепцию MLOps. Операции машинного обучения (MLOps): обзор, определение и архитектура Это может напугать, поскольку в нем много элементов, взаимодействующих друг с другом. Однако в нем можно найти многие характеристики упомянутых выше уровней зрелости. По крайней мере, автоматизированные конвейеры, CI/CD, мониторинг, реестр моделей, оркестровка рабочих процессов и обслуживающий компонент. Давайте обсудим эту диаграмму и поговорим о каждой более подробно. Основные процессы MLOps Основные части схемы представляют собой горизонтальные блоки, в которых описаны процедурные аспекты MLOps (им присвоены буквы А, В, С и D). Каждый из них предназначен для решения конкретных задач в рамках обеспечения бесперебойной работы ML-сервисов компании. Для простоты понимания схемы лучше начинать по порядку. Экспериментирование Если в компании есть сервисы ML, сотрудники работают в Jupyter. Во многих компаниях это инструмент, на котором сосредоточены все процессы разработки ML. Именно здесь начинается большинство задач, требующих внедрения практик MLOps. Компании А необходимо автоматизировать часть некоторых процессов с помощью машинного обучения (предположим, что есть соответствующий отдел и специалисты). Вряд ли путь решения задачи известен заранее. Поэтому исполнителям необходимо изучить постановку задачи и апробировать возможные пути ее реализации. Давайте рассмотрим пример. Для этого ML-инженер/ML-разработчик пишет код для различных реализаций задач и оценивает полученные результаты по целевым метрикам. Все это почти всегда делается в Jupyter Lab. В таком виде приходится вручную собирать много важной информации и потом сравнивать реализации между собой. Такая деятельность называется экспериментированием. Это означает получение работающей модели МО, которую в дальнейшем можно использовать для решения соответствующих задач. Блок C, показанный на схеме, описывает процесс проведения экспериментов по ML. Анализ данных, доступных в рамках задачи Многие решения в разработке ML принимаются на основе анализа данных, имеющихся в компании. Невозможно обучить модель с целевыми показателями качества на данных низкого качества или данных, которых не существует. Поэтому важно разобраться, какие данные мы получили и что мы можем с ними сделать. Для этого, например, мы можем: Проведите исследование ADHoc с использованием Jupyter или Superset. Стандартный EDA (исследовательский анализ данных) Лучшее понимание данных можно получить только в сочетании с семантическим и структурным анализом. Однако лишь иногда подготовка данных находится под контролем команды проекта. В этом случае дополнительные трудности обеспечены. Иногда на этом этапе становится понятно, что дальше развивать проект нет смысла, поскольку данные не пригодны для работы. Формирование качественного датасета Когда есть уверенность в имеющихся данных, необходимо задуматься о правилах предварительной обработки. Даже если имеется большой набор подходящих данных, нет гарантии, что он не содержит пропусков, искаженных значений и т.п. Следует упомянуть термин «качество входных данных» и известную фразу «Мусор на входе – мусор на выходе». здесь. Независимо от того, насколько хороша модель, она даст плохие результаты на данных низкого качества. На практике многие ресурсы проекта тратятся на создание качественного набора данных. Обучение и проверка модели ML После предыдущего этапа имеет смысл учитывать метрики обученной модели при проведении экспериментов. В рамках рассматриваемого блока эксперимент заключается в соединении обучения и валидации модели ML. Эксперимент состоит из классической схемы обучения нужной версии модели с выбранным набором гиперпараметров на подготовленном наборе данных. Для этого сам набор данных разделен на обучающую, тестовую и проверочную выборки: Первые два используются для выбора оптимального набора гиперпараметров. Третий — окончательная проверка и подтверждение того, что модель, обученная на выбранном наборе гиперпараметров, адекватно ведет себя на неизвестных данных, не участвовавших в процессе выбора и обучения гиперпараметров. Подробнее о проверочных образцах можно прочитать в . Эта статья Сохранение кода и гиперпараметров в репозитории Если метрики обучения модели хорошие, код модели и выбранные параметры сохраняются в корпоративном репозитории. Фундаментальной целью процесса экспериментирования является разработка модели, которая подразумевает выбор наилучшего алгоритма и выбор наилучшей настройки гиперпараметров. Сложность проведения экспериментов состоит в том, что разработчику необходимо проверить множество комбинаций параметров работы ML-модели. И речь не идет о разных вариантах используемого математического аппарата. В общем, это требует работы. А что делать, если желаемые метрики не достигаются в рамках комбинаций параметров модели? Разработка функций Если желаемые метрики работы ML-модели не могут быть достигнуты, вы можете попытаться расширить описание возможностей объектов набора данных новыми функциями. За счет них контекст для модели расширится, а значит, искомые метрики могут улучшиться. Новые функции могут включать в себя: Для табличных данных: произвольные преобразования уже существующих атрибутов объекта - например, X^2, SQRT(X), Log(x), X1*X2 и т.д. По предметной области: индекс массы тела, количество просроченных платежей по кредиту за год и т.д. Давайте посмотрим на часть диаграммы, которая относится к разработке функций. Блок Б1 направлен на формирование набора требований для преобразования имеющихся исходных данных и получения из них признаков. Сам расчет компонентов производится из этих самых предварительно обработанных и очищенных данных по «формулам», введенным разработчиком ML. Важно сказать, что работа с функциями является итеративной. Применяя один набор функций, в голову может прийти новая идея, реализованная в другом наборе функций, и так до бесконечности. Это явно показано на диаграмме как петля обратной связи. Блок B2 описывает непосредственный процесс добавления новых функций к данным. Подключение к источникам данных и их получение — это технические операции, которые могут быть довольно сложными. Для простоты объяснения буду считать, что существует несколько источников, к которым у команды есть доступ, и инструменты для выгрузки данных из этих источников (хотя бы Python-скрипты). Этот этап практически повторяет аналогичный этап блока экспериментов (В) – подготовку данных. Уже при постановке первых экспериментов появляется понимание, какие данные и в каком формате нужны для обучения моделей ML. Остается только правильно сгенерировать и протестировать новые функции, но процесс подготовки данных для этого должен быть максимально автоматизирован. Очистка и преобразование данных. Как отмечалось выше, эти действия могут состоять из простого преобразования нескольких элементов кортежа данных. Другой вариант — запустить отдельный большой конвейер обработки, чтобы добавить одну функцию в один и тот же кортеж данных. В любом случае существует набор действий, которые последовательно выполняются. Расчет новых функций. Результат предыдущих действий добавляется в набор данных. Чаще всего объекты добавляются в набор данных пакетно, чтобы уменьшить нагрузку на базу данных. Но иногда это необходимо делать «на лету» (стриминг), чтобы ускорить выполнение бизнес-задач. Добавляем результат. Полученные возможности важно использовать максимально эффективно: сохранять и повторно использовать их в задачах других ML-разработчиков компании. Для этой цели в схеме имеется хранилище функций. Он должен быть доступен внутри компании, администрироваться отдельно и иметь версии всех входящих в него функций. Хранилище функций состоит из двух частей: онлайн (для потоковых сценариев) и автономно (для пакетных сценариев). Автоматизированный рабочий процесс машинного обучения В начале статьи я указал, что под системой ML я подразумеваю информационную систему, один или несколько компонентов которой содержат обученную модель, выполняющую некоторую часть общей бизнес-логики. Чем лучше модель МО, полученная в результате разработки, тем больший эффект от ее работы. Обученная модель обрабатывает входящий поток запросов и предоставляет в ответ некоторые прогнозы, автоматизируя тем самым некоторые части процесса анализа или принятия решений. Процесс использования модели для генерации прогнозов называется логическим выводом, а обучение модели — обучением. Четкое объяснение разницы между ними можно позаимствовать у Gartner. Здесь я буду практиковаться на кошках. Для эффективной работы производственной системы машинного обучения крайне важно следить за метриками вывода модели. Как только они начнут падать, модель следует либо переобучить, либо заменить на новую. Чаще всего это происходит из-за изменения входных данных (дрейфа данных). Например, есть бизнес-задача, в которой модель может распознавать кексы на фотографиях, и это передается ей в качестве входных данных. Собаки чихуахуа в примере созданы для баланса: Модель в исходном наборе данных ничего не знает о собаках чихуахуа, поэтому прогнозирует неправильно. Значит, необходимо менять набор данных и проводить новые эксперименты. Новая модель должна поступить в производство как можно скорее. Никто не запрещает пользователям загружать изображения собак чихуахуа, но они получат неправильный результат. Рассмотрим для маркетплейса. Теперь более реальные примеры. разработку рекомендательной системы На основе истории покупок пользователя, покупок похожих пользователей и других параметров модель или ансамбль моделей генерирует блок с рекомендациями. Он содержит продукты, доход от покупки которых регулярно подсчитывается и отслеживается. Что-то происходит, и потребности клиентов меняются. Следовательно, их рекомендации больше не актуальны. Спрос на рекомендуемую продукцию падает. Все это приводит к снижению доходов. Дальше менеджеры кричат и требуют, чтобы к завтрашнему дню все восстановили, что ни к чему не приводит. Почему? Данных о новых предпочтениях клиентов недостаточно, поэтому даже сделать новую модель невозможно. Вы можете взять несколько базовых алгоритмов генерации рекомендаций (совместная фильтрация на основе элементов) и добавить их в производство. Таким образом, рекомендации как-то сработают, но это лишь временный обходной путь. В идеале процесс должен быть построен таким образом, чтобы процесс переобучения или экспериментирования с различными моделями начинался на основе показателей без указаний менеджеров об этом. И лучший из них со временем заменит нынешний в производстве. На схеме это Automated ML Workflow Pipeline (блок D), который запускается триггерами в каком-то инструменте оркестрации. Это самый нагруженный участок схемы. В работе блока D задействовано несколько ключевых сторонних компонентов: Компонент оркестратора рабочих процессов, отвечающий за запуск конвейера по заданному расписанию или событию. Feature Store, из которого берутся данные о необходимых для модели функциях. Model Registry и хранилище метаданных ML, куда помещаются модели и их метрики, полученные после работы запущенного Pipeline. Структура самого блока объединяет этапы блоков экспериментирования и разработки функций (В2). Это неудивительно, учитывая, что именно эти процессы необходимо автоматизировать. Основные различия заключаются в последних двух этапах: Экспортировать модель Отправить в реестр моделей Остальные шаги идентичны описанным выше. Отдельно хочу упомянуть сервисные артефакты, необходимые оркестратору для запуска конвейеров переобучения модели. Это код, который хранится в репозитории и запускается на выбранных серверах. Он версионируется и обновляется с соблюдением всех правил разработки программного обеспечения. Этот код реализует конвейеры переобучения модели, и от его корректности зависит результат. Чаще всего внутри кода запускаются различные инструменты ML, внутри которых происходит выполнение шагов конвейеров, например: Оркестратор воздушного потока запускает код для выполнения этапов конвейеров. Feast выгружает данные об объектах в наборе данных по команде. Затем ClearML создает новый набор данных и проводит эксперимент с необходимым набором метрик производительности модели, которые он берет из собственного репозитория. После завершения расследования ClearML сохраняет модель и ее показатели производительности в хранилище. Здесь стоит отметить, что автоматизировать эксперименты вообще невозможно. Конечно, в этот процесс можно добавить концепцию AutoML. Однако в настоящее время не существует признанного решения, которое можно было бы использовать с одинаковыми результатами для любого субъекта эксперимента. В общем случае AutoML работает следующим образом: Каким-то образом генерирует набор из множества комбинаций параметров работы модели. Запускает эксперимент для каждой полученной комбинации. Фиксирует метрики для каждого эксперимента, на основе которых выбирается лучшая модель. AutoML выполняет все манипуляции, которые проделал бы младший/средний специалист по данным в кругу более-менее стандартных задач. Немного поработали над автоматизацией. Далее нам необходимо организовать поставку новой версии модели в производство. Модели обслуживания и мониторинга Модель ML необходима для генерации прогнозов. Но сама модель ML — это файл, который невозможно заставить генерировать их так быстро. В Интернете часто можно встретить такое решение: команда берет FastAPI и пишет вокруг модели обертку на Python, чтобы можно было «следить за предикатами». С момента получения файла модели ML все может развиваться несколькими способами. Команда может пойти: Напишите весь код для создания службы RESTfull. Реализуйте всю обертку вокруг него Встройте все это в образ Docker И затем где-то из этого образа вы собираетесь создать контейнер. Масштабируйте как-нибудь Организовать сбор метрик Настройка оповещений Настройка правил развертывания новых версий модели Много других вещей Проделать это для всех моделей и поддерживать всю кодовую базу в будущем — трудоемкая задача. Чтобы было проще, появились специальные обслуживающие инструменты, в которых введены 3 новые сущности: Экземпляр вывода/сервис Сервер вывода Обслуживание двигателя — это конкретная модель машинного обучения, подготовленная для приема запросов и генерации прогнозов ответов. Такая сущность может представлять собой подгруппу в кластере Kubernetes с контейнером с необходимой моделью машинного обучения и техническими инструментами для ее запуска. Экземпляр вывода или служба вывода является создателем экземпляров/сервисов вывода. Существует множество реализаций сервера вывода. Каждый из них может работать с конкретными платформами машинного обучения, преобразуя обученные в них модели в готовые к использованию модели для обработки входных запросов и генерации прогнозов. Сервер вывода выполняет основные функции управления. Он определяет, какой сервер вывода будет использоваться, сколько копий полученного экземпляра вывода следует запустить и как их масштабировать. Обслуживающий механизм В рассматриваемой схеме нет такой детализации обслуживающих компонентов модели, но обозначены схожие аспекты: Компонент CI/CD, который развертывает модели, готовые к запуску в производство (его можно рассматривать как одну из версий Serving Engine). Model Serving в рамках доступной ему инфраструктуры организует схему генерации прогнозов для моделей ML, как для потоковых, так и для пакетных сценариев (можно рассматривать как одну из версий Inference Server). В качестве примера полного стека для обслуживания мы можем обратиться к стеку от Селдона: Seldon Core — обслуживающий механизм Seldon ML Server — это сервер вывода, который подготавливает доступ к модели через REST или gRPC. Пользовательская среда выполнения Seldon MLServer — это экземпляр вывода, экземпляр оболочки для любой модели машинного обучения, пример которой необходимо запустить для генерации прогнозов. Существует даже стандартизированный протокол реализации Serving, поддержка которого де-факто обязательна во всех подобных инструментах. Он называется V2 Inference Protocol и был разработан несколькими известными игроками рынка — KServe, Seldon и Nvidia Triton. Обслуживание и развертывание В различных статьях вы можете найти ссылки на инструменты обслуживания и развертывания как единого целого. Однако важно понимать разницу в целях обоих. Это спорный вопрос, но в этой статье он будет поставлен так: Обслуживание — создание API-модели и возможность получать от нее прогнозы. В итоге вы получаете единственный экземпляр сервиса с моделью внутри. Развертывание — распространение экземпляра сервиса в необходимом количестве для обработки входящих запросов (может быть представлено как набор реплик в развертывании Kubernetes). , но они не предназначены только для машинного обучения. Кстати, платная версия Селдона поддерживает несколько стратегий, поэтому вы можете просто выбрать этот стек и наслаждаться тем, как все работает. Для развертывания моделей можно использовать множество стратегий Помните, что показатели производительности модели необходимо отслеживать. В противном случае вы не сможете вовремя решить проблемы. Как именно отслеживать метрики — большой вопрос. построила на этом целый бизнес, но Grafana и VictoriaMetrics никто не отменял. Arize AI Инициирование проекта Учитывая все написанное выше, получается, что команда ML: Генерирует наборы данных Проводит над ними эксперименты на моделях ML Разрабатывает новые функции для расширения наборов данных и улучшения качества моделей. Сохраняет лучшие модели в реестре моделей для повторного использования в будущем. Настраивает обслуживание и развертывание моделей Настраивает мониторинг моделей в производстве и автоматическое переобучение текущих моделей или создание новых моделей. Это выглядит затратно и лишь иногда оправдано. Поэтому на схеме есть отдельный блок MLOps Project Initiation (A), отвечающий за рациональную постановку целей. Образ мышления здесь можно продемонстрировать на примере рассуждений ИТ-директора. К нему приходит вдохновленный менеджер проекта и просит установить новую платформу для построения системы ML. Если оба действуют в интересах компании, от ИТ-директора последуют уточняющие вопросы: Какую бизнес-задачу вы собираетесь решить с помощью новой системы машинного обучения? Почему вы решили, что новая система ML должна решить эту проблему? Было бы проще и дешевле изменить процессы или нанять больше людей в службу технической поддержки? Где можно увидеть сравнительный анализ компонентов ML-системы, которые легли в основу вашего текущего выбора? Как выбранная архитектура ML-системы поможет решить бизнес-задачу? Вы уверены, что ML обладает необходимым математическим аппаратом для решения выявленной проблемы? Какова постановка задачи для решения? Откуда вы возьмете данные для обучения моделей? Знаете ли вы, какие данные вам нужны для подготовки моделей? Вы уже изучили имеющиеся данные? Достаточно ли качества данных для решения модели? ИТ-директора уволят с должности преподавателя в университете, но это сэкономит деньги компании. Если на все вопросы даны ответы, значит, существует реальная потребность в системе ML. Следующий вопрос: Нужно ли мне в нем делать MLOps? Зависит от проблемы. Если вам нужно найти разовое решение, например PoC (Proof of Concept), MLOps вам не нужны. Если необходимо обработать много входящих запросов, то необходим MLOps. По сути, подход аналогичен оптимизации любого корпоративного процесса. Чтобы обосновать необходимость МЛОпса перед руководством, нужно подготовить ответы на вопросы: Что станет лучше? Сколько денег мы сэкономим? Нужно ли нам расширять штат? Что нам нужно купить? Где получить экспертизу? Следующее, что нужно сделать, это пересдать экзамен на ИТ-директора. Проблемы сохраняются, поскольку команда также должна быть убеждена в необходимости изменить свои рабочие процессы и набор технологий. Иногда это сложнее, чем просить у руководства бюджет. Чтобы убедить команду, стоит подготовить ответы на вопросы: Почему старый способ работы больше невозможен? Какова цель изменения? Каким будет стек технологий? Чему и у кого учиться? Как компания будет способствовать внедрению изменений? Сколько времени нужно, чтобы внести изменения? Что происходит с теми, кто этого не делает? Как видите, этот процесс непрост. Небольшой вывод На этом я закончил детальное изучение схемы MLOps. Однако это лишь теоретические аспекты. Практическая реализация всегда выявляет дополнительные детали, которые могут многое изменить. В следующей статье я расскажу: Артефакты МЛОпс MLOps как информационная система Открытый исходный код для MLOps: Kubeflow против MLflow против Pachyderm Спасибо за внимание!
