MLOps Beyond Training: упрощение и автоматизация операционного конвейера

Развивающееся значение «MLOPs»

Когда вы говорите «MLOPs», что вы имеете в виду? По мере развития технологической экосистемы, связанной с машинным обучением, «MLOPs» теперь, по-видимому, имеет (по крайней мере) два совершенно разных значения:

  1. Одно распространенное использование «MLops» относится к циклу обучения модели ИИ: подготовка данных, оценка и обучение модели. Эта итеративная или интерактивная модель часто включает возможности AutoML, и то, что происходит за рамками обученной модели, не входит в это определение.
  2. Мое предпочтительное определение MLOps относится к полному процессу обработки данных, от приема данных до фактического реального приложения, которое работает в бизнес-среде и оказывает влияние на бизнес-уровень. В этой статье я объясню разницу между этими двумя подходами и почему это важно для вашей команды специалистов по данным и для успеха вашей организации в целом.

Исследовательский подход к MLOps

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

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

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

Исследовательский подход: как он работает и почему он неполный

Обычный способ заняться проектами ИИ — начать с разработки модели. Data Scientist получает данные, которые извлекаются вручную из различных источников, он или она исследует и подготавливает данные в интерактивном режиме (наиболее распространенным инструментом на этом этапе являются ноутбуки), обучение и эксперименты проводятся с отслеживанием всех результатов, модель создается и тестируется/проверяется до тех пор, пока не будут получены удовлетворительные результаты. С полученной моделью разные группы специалистов по машинному обучению или инженеров по данным будут выяснять, как встроить ее в бизнес-приложение, как обрабатывать интеграцию API, создавать конвейеры данных, применять мониторинг и т. д. Во многих случаях первоначальная наука о данных будет отложена и повторно реализована надежным и масштабируемым способом, который подходит для производства, но может не соответствовать тому, что первоначально планировал ученый по данным.

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

Как видно из двух приведенных выше диаграмм, между фазой разработки модели и производственной средой мало общего.

Развертывание производства:

  • Включает гораздо больше компонентов, которые должны работать и управляться вместе.
  • Значительные усилия направлены на обработку данных, интеграцию приложений и задачи мониторинга.
  • Интерактивная разработка заменяется управляемыми микросервисами, которые могут выполнять масштабирование и автоматическое (повторное) развертывание.
  • Ориентирован на отказоустойчивость, наблюдаемость, безопасность и непрерывную работу.

Обычный подход к разработке моделей в изолированном хранилище данных приводит к пустой трате ценных ресурсов и значительному увеличению времени производства.

Обучение сделано! Что теперь?

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

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

Принятие производственного мышления

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

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

Производственный подход к MLOps и его преимущества

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

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

  1. Магазин функций: собирает, подготавливает, каталогизирует и предоставляет функции данных для разработки (в автономном режиме) и использования в режиме реального времени (в сети).
  2. Конвейер ML CI/CD: автоматически обучает, тестирует, оптимизирует и развертывает или обновляет модели с помощью моментального снимка производственных данных (созданного хранилищем функций) и кода из системы управления версиями (Git).
  3. Конвейер приложений в реальном времени/управляемый событиями: включает обработку API, подготовку/обогащение данных, обслуживание моделей, ансамбли, управление и измерение действий и т. д.
  4. Мониторинг данных и моделей в режиме реального времени: отслеживает данные, модели и производственные компоненты и обеспечивает цикл обратной связи для изучения производственных данных, выявления дрейфа, оповещения об аномалиях или проблемах с качеством данных, запуска заданий повторного обучения, измерение влияния на бизнес и т. д.

Хотя каждый из этих шагов может быть независимым, они все же требуют тесной интеграции.

Например:

  • Задания обучения должны получать функции из хранилища функций и обновлять хранилище функций метаданными, которые будут использоваться при обслуживании или мониторинге.
  • Конвейер реального времени должен обогащать входящие события функциями, хранящимися в хранилище функций, и может использовать метаданные функций (политики, статистика, схема и т. д.) для вменения отсутствующих данных или проверки качества данных.
  • Уровень мониторинга должен собирать входные и выходные данные в режиме реального времени из конвейера реального времени и сравнивать их с данными/метаданными объектов из хранилища объектов или метаданными модели, сгенерированными на уровне обучения, и ему необходимо записывать все свежие производственные данные обратно в хранилище функций, поэтому его можно использовать для различных задач, таких как анализ данных, переобучение модели (на свежих данных), улучшение модели.

Автоматизация и оркестрация MLOps

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

Поскольку эти четыре компонента настолько тесно связаны, ими нельзя управлять изолированно. Именно здесь на помощь приходит оркестровка MLOps. Командам машинного обучения нужен способ совместной работы с использованием одного и того же набора инструментов, методов, API-интерфейсов, метаданных и контроля версий. Это сотрудничество может происходить на специально созданной платформе, построенной из отдельных компонентов, которые должны быть склеены вместе и поддерживаться большими внутренними командами, или с использованием готового автоматизированного решения, такого как платформа Iguazio MLOps или среда оркестровки MLOps с открытым исходным кодом. МЛРан.

MLOps должны обеспечивать реальную ценность для бизнеса!

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

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

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

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