Платформа операций машинного обучения (MLOps) для вертикального увеличения масштаба жизненного цикла машинного обучения с помощью Машинного обучения Azure

Этот клиентский проект помог компании Fortune 500 продуктов питания улучшить прогноз спроса. Компания поставляет продукты непосредственно в несколько розничных точек. Улучшение помогло им оптимизировать запасы своих продуктов в разных магазинах в нескольких регионах США. Чтобы достичь этого, группа разработчиков коммерческого программного обеспечения (CSE) Майкрософт работала с специалистами по обработке и анализу данных клиента в пилотном исследовании для разработки настраиваемых моделей машинного обучения для выбранных регионов. Модели учитывают:

• Демографические данные по покупателям
• Данные о погоде за прошлые годы и прогнозы
• Прошедшие поставки
• Возвраты товаров
• Особые события

Цель оптимизации запасов представляет собой основной компонент проекта, и клиент реализовал значительный подъем продаж в ранних испытаниях на местах. Кроме того, команда сократилась на 40 % при прогнозировании средней процентной ошибки (MAPE) по сравнению с исторической средней базовой моделью.

Ключевая часть проекта состоит в том, чтобы определить, как масштабировать рабочий процесс обработки и анализа данных от пилотного исследования до уровня рабочей среды. Для этого команде разработки коммерческого ПО было необходимо выполнить следующее:

• Разработать модели для различных регионов.
• Непрерывно обновляйте и отслеживайте производительность моделей.
• Упростить совместную работу между группами данных и инженерами.

Типичный рабочий процесс обработки и анализа данных сегодня ближе к одноуровневой лабораторной среде, чем рабочему процессу рабочей среды. Среда для специалистов по обработке и анализу данных должна быть подходит для следующих целей:

• Подготовка данных.
• Эксперименты с различными моделями.
• Настройте гиперпараметры.
• Создайте цикл проверки сборки и оценки.

Большинство инструментов, используемых для этих задач, имеют определенные цели и не подходят для автоматизации. При работе с машинным обучением на уровне рабочей среды необходимо учитывать более подробное руководство по управлению жизненным циклом приложений и DevOps.

Команда CSE помогла клиенту увеличить масштаб операции до рабочих уровней. Они реализовали различные аспекты возможностей непрерывной интеграции и непрерывной доставки (CI/CD) и устраняли такие проблемы, как наблюдаемость и интеграция с возможностями Azure. Во время реализации команда обнаружила пробелы в существующих рекомендациях MLOps. Эти пробелы должны быть заполнены таким образом, чтобы MLOps был лучше понят и применен в масштабе.

Общие сведения о методиках MLOps помогают организациям гарантировать, что модели машинного обучения, создаваемые системой, являются моделями качества производства, которые повышают производительность бизнеса. При реализации MLOps организация больше не должна тратить больше времени на низкоуровневые сведения, касающиеся инфраструктуры и инженерных работ, необходимых для разработки и запуска моделей машинного обучения для операций на рабочем уровне. Реализация MLOps также помогает сообществам по обработке и анализу данных и программному обеспечению научиться работать вместе, чтобы обеспечить рабочая система, готовая к работе.

Команда CSE использовала этот проект для решения потребностей сообщества машинного обучения путем решения таких проблем, как разработка модели зрелости MLOps. Эти усилия были направлены на улучшение внедрения MLOps путем понимания типичных проблем ключевых игроков в процессе MLOps.

Взаимодействие и технические сценарии

Сценарий взаимодействия обсуждает реальные проблемы, которые команда CSE должна была решить. Технический сценарий определяет требования к созданию жизненного цикла MLOps, который является надежным, как хорошо установленный жизненный цикл DevOps.

Сценарий взаимодействия

Клиент поставляет товары напрямую в предприятия розничной торговли согласно регулярному расписанию. Каждый розничный магазин зависит от его шаблонов использования продукта, поэтому инвентаризация продуктов должна различаться в каждой еженедельной доставке. Максимизация продаж и минимизация возврата продуктов и потерянных возможностей продаж — это цели методологий прогнозирования спроса, которые использует клиент. Этот проект ориентирован на использование машинного обучения для улучшения прогнозов.

Команда разработки коммерческого ПО разделила проект на две фазы. Этап 1 посвящен разработке моделей машинного обучения для поддержки пилотного исследования по эффективности прогнозирования машинного обучения для выбранного региона продаж. Успех этапа 1 привел к этапу 2, в котором команда масштабировала начальное пилотное исследование с минимальной группы моделей, которая поддерживала один географический регион до набора устойчивых моделей уровня производства для всех регионов продаж клиента. Основное внимание к масштабируемому решению является необходимость размещения большого количества географических регионов и их местных розничных точек. Команда выделила модели машинного обучения как для крупных, так и для мелких магазинов в каждом регионе.

Пилотное исследование этапа 1 показало, что модель, предназначенная для розничных точек одного региона, может использовать локальную историю продаж, местную демографические данные, погоду и специальные события для оптимизации прогноза спроса для точек в регионе. Четыре модели прогнозирования машинного обучения обслуживают рыночные точки в одном регионе. Они обрабатывали данные еженедельными пакетами. Также команда разработала две базовые модели с помощью данных за прошедшие периоды для сравнения.

Для первой версии масштабируемого решения этапа 2 команда CSE выбрала 14 географических регионов для участия, включая небольшие и крупные торговые точки. Разработчики использовали более 50 моделей машинного обучения для прогнозирования. Они ожидали, что система продолжит разрастаться, а модели машинного обучения — совершенствоваться. Стало ясно, что это широкомасштабное решение машинного обучения устойчиво только в том случае, если оно основано на рекомендациях DevOps для среды машинного обучения.

Среда	Регион продаж	Формат	Модели	Подраздел модели	Описание модели
Среда разработки	Каждый географический регион продаж (например, северный Техас)	Магазины большого формата (супермаркеты, большие магазины коробки и т. д.)	Две модели ансамбля	Товары медленного потребления	Медленный и быстрый оба имеют ансамбль наименьшего абсолютного сжатия и оператора выделения (LASSO) линейной регрессии модели и нейронной сети с категориальными внедрениями
				Товары широкого потребления	Медленные и быстрые оба имеют ансамбль модели линейной регрессии LASSO и нейронной сети с категориальными внедрениями
			Одна модель ансамбля	Н/П	Средний показатель за прошедшие периоды
		Небольшие магазины формата (аптеки, удобные магазины и т. д.)	Две модели ансамбля	Товары медленного потребления	Медленные и быстрые оба имеют ансамбль модели линейной регрессии LASSO и нейронной сети с категориальными внедрениями
				Товары широкого потребления	Медленный и оба имеют ансамбль модели линейной регрессии LASSO и нейронной сети с категориальным внедрением
			Одна модель ансамбля	Н/П	Средний показатель за прошедшие периоды
	То же, что и для дополнительных 13 географических регионов
То же, что и выше для среды prod

Процесс MLOps предоставил платформу для масштабируемой системы, которая рассмотрела полный жизненный цикл моделей машинного обучения. Платформа включает разработку, тестирование, развертывание, операцию и мониторинг. Он соответствует потребностям классического процесса CI/CD. Однако по сравнению с DevOps она достаточно неразвита, и стало очевидно, что в существующей методологии MLOps есть пробелы. Группа проектов работала над заполнением некоторых из этих пробелов. Они хотели предоставить модель функционального процесса, которая обеспечивает жизнеспособность масштабируемого решения машинного обучения.

Процесс MLOps, разработанный из этого проекта, сделал значительный реальный шаг для перемещения MLOps на более высокий уровень зрелости и жизнеспособности. Новый процесс можно применять непосредственно к другим проектам машинного обучения. Команда CSE использовала то, что они узнали для создания проекта модели зрелости MLOps, которую любой пользователь может применить к другим проектам машинного обучения.

Технический сценарий

MLOps, также известный как DevOps для машинного обучения, является зонтичным термином, охватывающим философии, практики и технологии, связанные с реализацией жизненных циклов машинного обучения в рабочей среде. Это все еще достаточно новая концепция. Было много попыток определить, что такое MLOps, и многие люди поставили под сомнение, могут ли MLOps подсутить все, от того, как специалисты по обработке и анализу данных подготавливают данные к тому, как они в конечном итоге доставляют, отслеживают и оценивают результаты машинного обучения. Хотя DevOps было много лет для разработки набора фундаментальных методик, MLOps все еще начал разработки. По мере развития мы обнаруживаем проблемы объединения двух дисциплин, которые часто работают с различными наборами навыков и приоритетами: проектирование программного обеспечения и операций, а также анализ данных.

При реализации MLOps в практических рабочих средах встречаются уникальные сложности, которые необходимо преодолеть. Teams может использовать Azure для поддержки шаблонов MLOps. Azure также может предоставлять клиентам службы управления активами и оркестрации для эффективного управления жизненным циклом машинного обучения. Службы Azure являются основой решения MLOps, описанного в этой статье.

Требования к моделям машинного обучения

Большая часть работы на этапе 1 пилотного исследования заключалась в создании моделей машинного обучения, которые команда CSE применяла к крупным и небольшим розничным магазинам в одном регионе. Важные требования для моделей:

• Использование службы Машинное обучение Azure.

• Первоначальные экспериментальные модели, разработанные в записных книжках Jupyter и реализованные в Python.

  Примечание.

  Teams использовали тот же подход машинного обучения для крупных и небольших магазинов, но данные обучения и оценки зависят от размера хранилища.

• Данные, требующие подготовки к использованию модели.

• Данные, обрабатываемые на пакетной основе, а не в режиме реального времени.

• Переобучение модели всякий раз, когда код или данные изменяются, или модель становится устаревшей.

• Просмотр производительности модели на панелях мониторинга Power BI.

• Производительность модели при оценке, которая считается важной, если MAPE <= 45 % по сравнению с исторической средней базовой моделью.

Требования к MLOps

Команда должна была соответствовать нескольким ключевым требованиям для увеличения масштаба решения из пилотного исследования этапа 1, в котором для одного региона продаж было разработано лишь несколько моделей. Этап 2 реализует пользовательские модели машинного обучения для нескольких регионов. Реализована реализация:

• Еженедельная пакетная обработка больших и небольших хранилищ в каждом регионе для повторного обучения моделей с новыми наборами данных.

• Непрерывное совершенствование моделей машинного обучения.

• Интеграцию процессов разработки, тестирования, создания пакетов и развертывания для непрерывной поставки и непрерывной интеграции в среде обработки, аналогичной DevOps, для MLOps.

  Примечание.

  Это свидетельствует об изменении в совместной работе специалистов по обработке и анализу данных и инженеров данных.

• Уникальная модель, представляющая каждый регион для крупных и небольших магазинов на основе истории магазинов, демографических данных и других ключевых переменных. Модель должна была обработать весь набор данных, чтобы свести к минимуму риск ошибки обработки.

• Возможность первоначально увеличить масштаб до 14 регионов продаж с планами дальнейшего увеличения масштаба.

• Планы по внедрению дополнительных моделей для более долгосрочного прогнозирования в регионах и других кластерах магазинов.

Решение модели машинного обучения

Жизненный цикл машинного обучения, также известный как жизненный цикл обработки и анализа данных, соответствует примерно следующему потоку процессов высокого уровня:

Развертывание модели здесь означает любое фактическое использование проверенной модели машинного обучения. По сравнению с DevOps, MLOps представляет дополнительную задачу интеграции жизненного цикла машинного обучения в типичный процесс CI/CD.

Жизненный цикл обработки и анализа данных не соответствует типичному жизненному циклу разработки программного обеспечения. Она включает использование Машинное обучение Azure для обучения и оценки моделей, поэтому эти шаги должны быть включены в автоматизацию CI/CD.

Пакетная обработка данных является основой архитектуры. В основе процесса лежат два конвейера Машинного обучения Azure, один для обучения, другой — для оценки. На этой схеме показана методология обработки и анализа данных, используемая для начального этапа клиентского проекта:

Разработчики протестировали несколько алгоритмов. В конечном счете они выбрали ансамблевой дизайн модели линейной регрессии LASSO и нейронную сеть с категориальным внедрением. Для крупных и мелких торговых предприятий они использовали одну и ту же модель, определяемую уровнем товаров, которые клиент мог хранить в точке продаж. Затем команда разделила модель на товары медленного и широкого потребления.

Специалисты по обработке и анализу данных обучают модели машинного обучения, когда команда выпускает новый код и когда новые данные доступны. Обучение обычно происходит еженедельно. Следовательно, каждый запуск обработки затрагивает значительный объем данных. Так как команда собирает данные из многих источников в разных форматах, требуется, чтобы данные были помещены в потребляемый формат, прежде чем специалисты по обработке и анализу данных смогут обработать их. Для кондиционирования данных требуются значительные усилия вручную, и команда CSE определила ее в качестве основного кандидата для автоматизации.

Как упоминание, специалисты по обработке и анализу данных разработали и применили экспериментальные модели Машинное обучение Azure к одному региону продаж в пилотном исследовании этапа 1, чтобы оценить полезность этого подхода прогнозирования. Команда CSE судила, что продажи лифта для магазинов в пилотном исследовании были значительными. Этот успех оправдан применение решения к полному рабочему уровню на этапе 2, начиная с 14 географических регионов и тысяч магазинов. Затем команда могла бы использовать тот же шаблон, чтобы добавлять дополнительные регионы.

Пилотная модель служила основой для масштабируемого решения, но команда CSE знала, что модель требует дальнейшего уточнения на постоянной основе для повышения производительности.

Решение MLOps

По мере того как понятия MLOps зрелы, команды часто обнаруживают проблемы при совместном привлечении дисциплин обработки и анализа данных и DevOps. Причина заключается в том, что основные игроки в дисциплинах, инженеры программного обеспечения и специалисты по обработке и анализу данных работают с различными наборами навыков и приоритетами.

Но существуют сходства, на которые следует опираться. MLOps, например DevOps, — это процесс разработки, реализованный цепочкой инструментов. Цепочка инструментов MLOps включает такие вещи, как:

• Управление версиями
• Анализ кода
• Автоматизация сборки
• Непрерывная интеграция
• Платформы тестирования и автоматизация
• Политики соответствия требованиям, интегрированные в конвейеры непрерывной поставки и непрерывной интеграции
• Автоматизация развертывания
• Наблюдение
• Аварийное восстановление и высокий уровень доступности
• Управление пакетами и контейнерами

Как отмечалось выше, решение использует существующие рекомендации DevOps, но дополнено для создания более зрелой реализации MLOps, которая соответствует потребностям клиента и сообщества по обработке и анализу данных. MLOps основывается на методологии DevOps со следующими дополнительными требованиями:

• Управление версиями данных и моделей не совпадает с версиями кода: необходимо использовать управление версиями наборов данных в качестве изменений в схеме и источниках данных.
• Требования к цифровому журналу аудита. Отслеживание всех изменений при работе с кодом и данными клиента.
• Обобщение. Модели отличаются от кода для повторного использования, так как специалисты по обработке и анализу данных должны настраивать модели на основе входных данных и сценария. Чтобы повторно использовать модель для нового сценария, может потребоваться точно настроить или передать или научиться на нем. Также понадобится конвейер обучения.
• Устаревшие модели. Модели устаревают со временем, и их необходимо повторно обучать по мере необходимости, чтобы они оставались актуальными в рабочей среде.

Сложности в использовании MLOps

Несформированный стандарт MLOps

Стандартный шаблон для MLOps продолжает развиваться. Решение обычно создается с нуля и выполняется в соответствии с потребностями конкретного клиента или пользователя. Обнаружив этот недостаток, команда по разработке коммерческого ПО воспользовалась методиками DevOps в своем проекте. Она дополнила процесс DevOps в соответствии с дополнительными требованиями MLOps. Это перспективный пример того, как должен выглядеть стандартный шаблон MLOps.

Различия в наборах навыков

Инженеры программного обеспечения и специалисты по обработке и анализу данных приносят уникальные наборы навыков команде. Эти различные наборы навыков могут сделать поиск решения, которое соответствует потребностям всех пользователей. Важно создать понятный рабочий процесс для поставки модели с уровня эксперимента в рабочую среду. Участники команды должны понять, как они могут интегрировать изменения в систему, не нарушая процесс MLOps.

Управление несколькими моделями

Часто существует необходимость решения нескольких моделей для сложных сценариев машинного обучения. Одной из сложностей MLOps является управление этими моделями, включая:

• Наличие последовательной схемы управления версиями.
• Непрерывное вычисление и мониторинг всех моделей.

Трассировка трассировки кода и данных также необходима для диагностики проблем модели и создания воспроизводимых моделей. Пользовательские панели мониторинга могут определить, как выполняются развернутые модели, и указать, когда следует вмешиваться. Для этого проекта команда создала такие панели мониторинга.

Необходимость согласования данных

Данные, используемые в этих моделях, поступают из множества частных и общедоступных источников. Так как исходные данные не упорядочены, модель машинного обучения не может использовать ее в его необработанном состоянии. Специалисты по обработке и анализу данных должны подготовить данные в стандартный формат для использования модели машинного обучения.

Большая часть пробного опытного исследования была посвящена подготовке необработанных данных, чтобы их могла обработать модель машинного обучения. В системе MLOps команде необходимо автоматизировать этот процесс и отслеживать его выходные данные.

Модель зрелости MLOps

Цель модели зрелости MLOps заключается в том, чтобы уточнить принципы и методики и выявить пробелы в реализации MLOps. Это также способ показать клиенту, как постепенно увеличивать свои возможности MLOps, а не пытаться сделать это все одновременно. Клиент может использовать ее в качестве руководства для:

• Оценки масштаба работы в проекте.
• Задания критериев успешного выполнения.
• Определите доставить.

Модель зрелости MLOps определяет пять уровней технических возможностей:

Level	Description
0	Операции не используются
1	Используются DevOps без MLOps
2	Автоматическое обучение
3	Автоматическое развертывание модели
4	Автоматизированные операции (full MLOps)

Текущую версию модели зрелости MLOps см. в статье Модель зрелости MLOps.

Определение процесса MLOps

MLOps включает все действия от получения необработанных данных до доставки выходных данных модели, также известных как оценка:

• Согласование данных
• Обучение модели
• Тестирование и оценка модели
• Определение и конвейер сборки
• Конвейер выпуска
• Развертывание
• Очки

Базовый процесс машинного обучения

Базовый процесс машинного обучения напоминает традиционную разработку программного обеспечения, но существуют значительные различия. На следующей схеме изображены основные этапы процесса машинного обучения:

Этап эксперимента является уникальным для жизненного цикла обработки и анализа данных, который отражает, как специалисты по обработке и анализу данных традиционно выполняют свою работу. Это отличается от того, как разработчики кода выполняют свою работу. На следующей схеме этот жизненный цикл изображен более подробно.

Интеграция разработки данных в MLOps представляет определенные трудности. Здесь вы увидите шаблон, используемый командой для интеграции процесса в форму, которую может поддерживать MLOps:

Роль MLOps заключается в создании согласованного процесса, который может эффективно поддерживать крупномасштабные среды CI/CD, распространенные в системах производственного уровня. Фактически модель MLOps должна включать все требования к процессу от уровня эксперимента до оценки.

Команда CSE усовершенствовала процесс MLOps в соответствии с конкретными потребностями клиента. Наиболее заметной необходимостью была пакетная обработка вместо обработки в режиме реального времени. По мере того как команда разработала масштабируемую систему, они определили и устранили некоторые недостатки. Наиболее значительные из этих недостатков привели к развитию моста между Фабрика данных Azure и Машинное обучение Azure, которые команда реализовала с помощью встроенного соединителя в Фабрика данных Azure. Этот компонент предназначен для упрощения активации и мониторинга состояния, которые необходимы для корректной автоматизации процесса.

Другим фундаментальным изменением было то, что специалисты по обработке и анализу данных нуждались в возможности экспортировать экспериментальный код из записных книжек Jupyter в процесс развертывания MLOps, а не запускать обучение и оценку напрямую.

Далее приведена окончательная концепция модели MLOps:

Поток процессов MLOps

На следующей схеме описывается применение рабочих процессов разработки и выпуска CI/CD в жизненном цикле машинного обучения:

• При создании запроса на вытягивание (PR) из ветвь компонента конвейер выполняет тесты проверки кода для проверки качества кода с помощью модульных тестов и тестов качества кода. Для проверки качества на следующем этапе конвейер также выполняет базовые проверочные тесты модели, чтобы проверить непрерывное обучение и оценку с помощью образцов макетов данных.
• При слиянии запроса на вытягивание с главной ветвью конвейер непрерывной интеграции выполнит те же проверочные тесты кода и модели с увеличенным периодом. Затем он создаст пакет артефактов, содержащий код и двоичные файлы, для выполнения в среде машинного обучения.
• После того как артефакты будут доступны, активируется конвейер cd проверки модели. Он выполняет непрерывную проверку в среде разработки машинного обучения. Опубликован механизм оценки. Для сценария пакетной оценки конвейер оценки публикуется в среде машинного обучения и активируется для создания результатов. Если вы хотите использовать сценарий оценки в режиме реального времени, можно опубликовать веб-приложение или развернуть контейнер.
• После создания и объединения в ветвь выпуска запускается тот же конвейер CI и конвейер проверки модели CD. На этот раз они выполняются в коде из ветви выпуска.

Вы можете рассмотреть поток данных обработки MLOps, показанный выше, как платформу архетипа для проектов, которые делают аналогичные архитектурные варианты.

Проверочные тесты кода

Проверочные тесты кода для машинного обучения направлены на проверку качества базы кода. Это та же концепция, что и любой инженерный проект, имеющий тесты качества кода (linting), модульные тесты и измерения покрытия кода.

Базовые проверочные тесты модели

Проверка модели обычно подразумевает проверку всех этапов непрерывного процесса создания эффективной модели машинного обучения. Он включает такие шаги:

• Проверка данных. Проверяет допустимость входных данных.
• Проверка обучения. Проверяет возможность успешного обучения модели.
• Проверка оценки. Проверяет возможность использования обученной модели для оценки с входными данными.

Выполнение всех этих этапов в среде машинного обучения — дорогостоящий и длительный процесс. В результате команда выполнила базовые тесты проверки модели локально на компьютере разработки. Он выполнил описанные выше шаги и использовал следующие действия:

• Локальный набор данных тестирования: небольшой набор данных, который часто затеняется, который проверка в репозиторий и используется в качестве входного источника данных.
• Локальный флаг. Флаг или аргумент в коде модели, который указывает, что набор данных необходимо запустить локально. Флаг сообщает коду обходить любой вызов среды машинного обучения.

Цель этих проверочных тестов не заключается в оценке производительности обученной модели. Скорее, это проверка того, что код для комплексного процесса является хорошим качеством. Это гарантирует качество кода, который отправляется вышестоящий, как включение тестов проверки модели в сборке PR и CI. Кроме того, инженеры и специалисты по обработке и анализу данных могут поместить точки останова в код для отладки.

Конвейер непрерывного развертывания проверки модели

Цель конвейера проверки модели заключается в проверке непрерывного обучения и оценки модели в среде машинного обучения с фактическими данными. Все обученные модели, созданные, будут добавлены в реестр моделей и помечены, чтобы ожидать повышения после завершения проверки. Для пакетного прогнозирования повышение может быть публикацией конвейера оценки, использующего эту версию модели. Для оценки в режиме реального времени модели присваивается тег для указания повышения уровня.

Конвейер непрерывного развертывания оценки

Конвейер оценки CD применим для сценария вывода пакетной службы, где тот же оркестратор моделей, используемый для проверки модели, активирует опубликованный конвейер оценки.

Среда разработки и рабочая среда

Рекомендуется отделять среду разработки (разработки) от рабочей среды (prod). Разделение позволяет системе активировать конвейер CD проверки модели и конвейер CD оценки по разным расписаниям. Для описанного потока MLOps конвейеры, предназначенные для выполнения основной ветви в среде разработки, и конвейер, предназначенный для ветви выпуска, выполняется в среде prod.

Изменения кода и данных

В предыдущих разделах в основном рассматриваются способы обработки изменений кода от разработки к выпуску. Однако изменения данных должны соответствовать той же строгости, что и изменения кода, чтобы обеспечить одинаковое качество проверки и согласованность в рабочей среде. С помощью триггера изменения данных или триггера таймера система может активировать конвейер cd проверки модели и конвейер CD оценки из оркестратора модели, чтобы выполнить тот же процесс, который выполняется для изменений кода в среде выпуска prod.

Пользователи и роли MLOps

Ключевое требование для любого процесса MLOps заключается в том, что он соответствует потребностям многих пользователей процесса. В целях проектирования эти пользователи считаются отдельными пользователями. Для этого проекта команда определила следующие лица:

• Специалист по обработке и анализу данных. Создает модель машинного обучения и ее алгоритмы.
• Разработчик.
  • Инженер данных. Реализует согласование данных.
  • Разработчик программного обеспечения. Реализует интеграцию модели в пакет ресурсов и рабочий процесс CI/CD.
• Специалист по операциям или ИТ. Управляет системными операциями.
• Бизнес-заинтересованные лица: обеспокоены прогнозами, сделанными моделью машинного обучения и как они помогают бизнесу.
• Пользователь данных. Использует выходные данные модели для принятия бизнес-решений.

Команде нужно было рассмотреть следующие три аспекта исследований пользователей и ролей.

• В работе специалистов по обработке и анализу данных и разработчиков обнаружено несоответствие в подходах и навыках. Упрощая работу специалистов по обработке и анализу данных и инженеру, важно учитывать разработку потока процессов MLOps. Для этого требуются новые приобретения навыков всеми участниками команды.
• Существует необходимость объединить всех главных лиц без отчуждения кого-либо. Чтобы сделать это, сделайте следующее:
  • Убедитесь, что они понимают концептуальную модель для MLOps.
  • Договоритесь о членах команды, которые будут работать вместе.
  • Создание рабочих рекомендаций для достижения общих целей.
• Если пользователю бизнес-заинтересованных лиц и конечных пользователей данных нужен способ взаимодействия с выходными данными из моделей, удобный пользовательский интерфейс — это стандартное решение.

Другие команды столкнутся с похожими проблемами в своих проектах машинного обучения по мере их масштабирования для использования в рабочей среде.

Архитектура решений MLOps

Логическая архитектура

Данные поступают из многих источников во многих разных форматах, поэтому они обусловлены до его вставки в озеро данных. Кондиционирование выполняется с помощью микрослужб, работающих как Функции Azure. Клиенты настраивают микрослужбы для соответствия источникам данных и преобразуют их в стандартный формат CSV, который используют конвейеры обучения и оценки.

Архитектура системы

Архитектура пакетной обработки

Команда разработала архитектурную модель для поддержки схемы пакетной обработки данных. Существуют альтернативные варианты, но все, что используется, должно поддерживать процессы MLOps. Одним из требований разработки стало полноценное использование доступных служб Azure. На следующей схеме представлена архитектура:

Обзор решения

Фабрика данных Azure выполняет следующие действия.

• Активирует функцию Azure для запуска приема данных и запуска конвейера Машинное обучение Azure.
• Запускает устойчивую функцию для опроса конвейера Машинное обучение Azure для завершения.

Пользовательские панели мониторинга в Power BI отображают результаты. Другие панели мониторинга Azure, подключенные к AZURE SQL, Azure Monitor и приложению Аналитика с помощью пакета SDK для Python OpenCensus, отслеживают ресурсы Azure. Эти панели содержат сведения о работоспособности системы машинного обучения. Они также дают данные, которые клиент использует для прогнозирования заказа продукта.

Оркестрация модели

Оркестрация модели происходит следующим образом:

1. При отправке PR DevOps активирует конвейер проверки кода.
2. Конвейер выполняет модульные тесты, тесты качества кода и тесты проверки модели.
3. При слиянии с главной ветвью выполняются те же тесты проверки кода, а DevOps упаковывают артефакты.
4. DevOps сбор триггеров артефактов Машинное обучение Azure для выполнения следующих действий:
   1. Проверки данных.
   2. Проверки обучения.
   3. Проверки оценки.
5. После завершения проверки выполняется окончательный конвейер оценки.
6. Изменение данных и отправка нового pr-запроса снова активирует конвейер проверки, за которым следует окончательный конвейер оценки.

Включение экспериментальных функций

Как уже упоминалось, обычный жизненный цикл обработки и анализа данных машинного обучения не поддерживает процесс MLOps без изменений. В нем используются различные виды ручных инструментов и экспериментов, проверки, упаковки и передачи модели, которые нельзя легко масштабировать для эффективного процесса CI/CD. Для MLOps требуется высокий уровень автоматизации процессов. Независимо от того, разрабатывается ли новая модель машинного обучения или старый, необходимо автоматизировать жизненный цикл модели машинного обучения. В проекте этапа 2 команда использовала Azure DevOps для оркестрации и повторной публикации конвейеров Машинное обучение Azure для задач обучения. Долго выполняющаяся основная ветвь выполняет базовое тестирование моделей и отправляет стабильные выпуски через длинную ветвь выпуска.

Важной частью этого процесса становится система управления версиями. Git — это система управления версиями, используемая для отслеживания кода записной книжки и модели. Она также поддерживает автоматизацию процессов. Базовый рабочий процесс, реализованный для системы управления версиями, применяет следующие принципы:

• Используйте формальное управление версиями для кода и наборов данных.
• Используйте ветвь для разработки нового кода, пока код не будет полностью разработан и проверен.
• После проверки нового кода его можно объединить в основную ветвь.
• Для выпуска создается постоянная ветвь с версиями, которая отделена от основной ветви.
• Используйте версии и управление версиями для наборов данных, которые были подготовлены для обучения или потребления, чтобы обеспечить целостность каждого набора данных.
• Использование системы управления версиями для отслеживания экспериментов с Jupyter Notebook.

Интеграция с источниками данных

Специалисты по обработке и анализу данных используют множество источников необработанных данных и обработанных наборов данных для экспериментов с различными моделями машинного обучения. Объем данных в рабочей среде может казаться внушительным. Для экспериментов с различными моделями специалисты по обработке и анализу данных должны использовать такие средства управления, как Azure Data Lake. Требование для формальной идентификации и управления версиями применяется ко всем необработанным данным, подготовленным наборам данных и моделям машинного обучения.

В проекте специалисты по обработке и анализу данных условили следующие данные для ввода данных в модель:

• Исторические еженедельные данные о доставке с января 2017 г.
• Исторические и прогнозируемые ежедневные данные о погоде для каждого почтового индекса
• Данные покупателей для каждого идентификатора магазина

Интеграция с системой управления версиями

Чтобы получить специалистов по обработке и анализу данных, чтобы применить рекомендации по проектированию, необходимо удобно интегрировать средства, которые они используют с системами управления версиями, такими как GitHub. Эта практика позволяет использовать управление версиями модели машинного обучения, совместную работу между участниками команды и аварийное восстановление, если команды испытывают потерю данных или сбой системы.

Поддержка объединенных моделей

В этом проекте в качестве структуры модели использовались объединенные модели. Это значит, что специалисты по обработке и анализу данных использовали множество алгоритмов в окончательном проекте модели. В этом случае для моделей использовался одинаковый алгоритм. Единственным различием стали разные данные для обучения и оценки. В моделях использовалась комбинация алгоритма линейной регрессии LASSO и нейронной сети.

Команда изучила, но не реализовала, возможность перенести процесс вперед до точки, где она будет поддерживать множество моделей в режиме реального времени, работающих в рабочей среде для обслуживания заданного запроса. Этот параметр позволяет использовать модели ансамбля в тестах A/B и переключениях экспериментов.

Пользовательские интерфейсы

Команда разработала пользовательские интерфейсы для наблюдаемости, мониторинга и инструментирования. Как уже упоминалось, панели мониторинга визуально отображают данные модели машинного обучения. Эти панели показывают следующие данные в понятном формате:

• Этапы конвейера, включая предварительную обработку входных данных.
• Чтобы отслеживать работоспособность обработки модели машинного обучения, выполните следующие действия.
  • Какие метрики собираются из развернутой модели?
    • MAPE: средняя абсолютная процентная ошибка, метрика ключа для отслеживания общей производительности. (Целевое значение <MAPE = 0,45 для каждой модели.)
    • RMSE 0: ошибка корневого среднего квадрата (RMSE) при фактическом целевом значении = 0.
    • RMSE All: RMSE во всем наборе данных.
  • Как оценить, выполняется ли модель в рабочей среде?
  • Существует ли способ определить, насколько сильно производственные данные отклоняются от ожидаемых значений?
  • Слабая ли производительность модели в рабочей среде?
  • Есть ли у вас состояние отработки отказа?
• Отслеживание качества обработанных данных.
• Отображение оценки и прогнозов, созданных моделью машинного обучения.

Приложение заполняет панели мониторинга в соответствии со свойствами данных, их обработкой и анализом. Поэтому команде необходимо спроектировать определенный макет панелей мониторинга для каждого варианта использования. Ниже приведены два примера панелей мониторинга:

Панели мониторинга предназначены для предоставления легко используемых сведений для использования конечным пользователем прогнозов модели машинного обучения.

Компоненты

• Машинное обучение Azure
  • Вычислительная среда Машинного обучения Azure
  • конвейеры Машинное обучение Azure
  • Реестр моделей Машинного обучения Azure
• Хранилище BLOB-объектов Azure
• Хранилище озера данных Azure
• Azure Pipelines
• Фабрика данных Azure
• Функции Azure для Python
• Azure Monitor
  • Журналы
  • Application Insights
• База данных SQL Azure
• Панели мониторинга Azure
• Power BI

Рекомендации

Здесь можно найти список рекомендаций для изучения. Они составлены на основе полученных командой разработки коммерческого ПО сведений во время проекта.

Рекомендации по среде

• Специалисты по обработке и анализу данных разрабатывают большую часть своих моделей машинного обучения с помощью Python, часто начиная с записных книжек Jupyter. Реализация этих записных книжек в качестве рабочего кода может оказаться затруднительной задачей. Записные книжки Jupyter являются скорее экспериментальным инструментом. Для рабочей среды предпочтительнее использовать скрипты Python. Командам часто требуется время на рефакторинг кода создания модели в скрипты Python.
• Сделайте клиентов, которые являются новыми для DevOps и машинного обучения, зная, что экспериментирование и производство требуют разных строгости, поэтому рекомендуется разделить два.
• Такие инструменты, как Машинное обучение Azure visual Designer или AutoML, могут быть эффективными при получении базовых моделей с нуля, пока клиент наращивает стандартные методики DevOps для применения к остальной части решения.
• В Azure DevOps есть подключаемые модули, которые могут интегрироваться с Машинное обучение Azure, чтобы помочь активировать шаги конвейера. В репозитории MLOpsPython содержится несколько примеров таких конвейеров.
• Машинное обучение часто требует мощных графических процессоров (GPU) для обучения. Если у клиента нет такого оборудования, Машинное обучение Azure вычислительные кластеры могут предоставить эффективный путь к быстрой подготовке экономичного мощного оборудования, которое выполняет автомасштабирование. Если у клиента есть расширенные требования к безопасности или мониторингу, существуют другие варианты, такие как стандартные виртуальные машины, Databricks или локальные вычислительные ресурсы.
• Для успеха проекта клиента необходимо обеспечить надежный коммуникационный канал между командами создания модели (специалистами по обработке и анализу данных) и развертывания (разработчиками DevOps). Это можно сделать с помощью ежедневных собраний или официальной онлайн-службы чата. Оба подхода помогают интегрировать свои усилия по разработке в платформу MLOps.

Рекомендации по подготовке данных

• Наиболее простым решением для использования Машинного обучения Azure является хранение данных в поддерживаемом хранилище. Такие инструменты, как Фабрика данных Azure, подходят для эффективной передачи данных в обе стороны согласно расписанию.

• Важно, чтобы клиенты часто регистрируют дополнительные данные переобучения, чтобы обеспечить актуальность своих моделей. Если у клиентов еще нет конвейера данных, его создание станет важной частью решения. Такое решение, как Наборы данных службы Машинного обучения Azure, может пригодиться для управления версиями данных, чтобы обеспечить отслеживаемость модели.

Рекомендации по обучению и оценке моделей

• Это подавляющее для клиента, который только начинает работу в своем пути машинного обучения, чтобы попытаться реализовать полный конвейер MLOps. При необходимости они могут упростить работу с помощью Машинное обучение Azure для отслеживания выполнения экспериментов и использования Машинное обучение Azure вычислений в качестве целевого объекта обучения. Эти варианты являются удобной отправной точкой, чтобы начать интеграцию служб Azure.

• Переход из эксперимента записной книжки к повторяемым сценариям является грубым переходом для многих специалистов по обработке и анализу данных. Чем раньше вы сможете написать свой обучающий код в скриптах Python, тем проще, чтобы начать управление версиями кода обучения и включить переобучение.

  Это не единственное возможное решение. Databricks поддерживает планирование записных книжек в виде заданий. Но, основываясь на текущем интерфейсе клиента, этот подход трудно инструментировать с полными практиками DevOps из-за ограничений тестирования.

• Также важно понимать, какие метрики используются для определения успешной работы модели. Часто одной точности недостаточно, чтобы определить общую производительность модели по сравнению с другой моделью.

Рекомендации по вычислениям

• Для стандартизации вычислительных сред клиентам рекомендуется использовать контейнеры. Почти все целевые объекты вычислений Машинное обучение Azure поддерживаются с помощью Docker. При обработке зависимостей контейнер может значительно снизиться трение, особенно если команда использует множество целевых объектов вычислений.

Рекомендации по обслуживанию моделей

• Пакет SDK Машинное обучение Azure предоставляет возможность развертывания непосредственно в Служба Azure Kubernetes из зарегистрированной модели, создавая ограничения на то, какие метрики безопасности и метрики существуют. Вы можете попытаться найти более простое решение для клиентов, чтобы протестировать свою модель, но лучше всего разработать более надежное развертывание в AKS для рабочих нагрузок.

Следующие шаги

• Дополнительные сведения об MLOps
• MLOps в Azure
• Визуализации Azure Monitor
• Жизненный цикл машинного обучения
• Расширение машинного обучения для Azure DevOps
• Интерфейс командной строки службы "Машинное обучение Azure"
• Активация приложений, процессов или процессов CI/CD на основе событий службы "Машинное обучение Azure" (предварительная версия)
• Настройка обучения и развертывания моделей с помощью Azure DevOps

Связанные ресурсы

• Модель зрелости MLOps
• Оркестрация MLOps в Azure Databricks с помощью Записной книжки Databricks
• MLOps для моделей Python с помощью Машинное обучение Azure
• Обработка и анализ данных и машинное обучение с помощью Azure Databricks
• ИИ гражданина с помощью Power Platform
• Развертывание вычислений искусственного интеллекта и машинного обучения в локальной среде и на пограничных устройствах