Если вы какое-то время занимаетесь разработкой программного обеспечения, вы, несомненно, сталкивались с многочисленными терминами, к которым добавляется слово «Ops», например «DevOps», «TestOps» или «DataOps». Из них «DevOps» (сокращение от «разработка и операции с информационными технологиями»), вероятно, является наиболее известным. Это относится к набору методов разработки программного обеспечения, которые способствуют автоматизации и перекрестному сотрудничеству между командами разных дисциплин, чтобы сократить время доставки программного обеспечения при достижении желаемого уровня качества.

И теперь, с ростом машинного обучения (ML), был придуман новый термин под названием «MLOps» (сокращение от «операций машинного обучения»). И хотя вам может показаться недовольным необходимостью вспоминать еще один термин «Ops», важно понимать потребности в подходе, подобном DevOps, который решает уникальные проблемы, требования и проблемы, связанные с машинным обучением.

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

Непрерывные сокращения

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

MLOps включает в себя непрерывную интеграцию и непрерывную доставку, но добавляет еще одну важную «непрерывную» методологию (и аббревиатуру): «непрерывное обучение» (также называемое «CT»). Непрерывное обучение направлено на автоматическое и непрерывное переобучение. модель для поддержки непрерывной доставки в системе ML. Это включает в себя создание конвейера для автоматической проверки и обучения данных и модели, а также разработку «триггера», запускающего переобучение.

Рабочий процесс машинного обучения

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

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

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

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

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

  • Недетерминированный характер машинного обучения, который усложняет тестирование, а также прогнозирование того, насколько хорошо модель будет работать и продолжит работать в реальном мире.
  • Необходимость развертывания «обученной» модели, часто в дополнение к коду, выполняющему вывод по модели.
  • Новые и различные типы соавторов проекта, которые могут охватывать специалистов по данным, инженеров ML, руководителей проектов ML, исследователей ML, разработчиков и даже владельцев бизнеса системы.
  • Исследовательский и экспериментальный характер дизайна модели, который по своей сути является итеративным и может развиваться с течением времени даже после развертывания.
  • «Распад модели», который происходит по мере изменения профиля реальных данных, что требует переобучения моделей или даже их перепроектирования.
  • Необходимость объяснить, как работает модель ML.

Уровни зрелости MLOps

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

  • Уровень 1 MLOps: обычно описывает организации, которые начинают с машинного обучения и делают все вручную. У них может быть мало или совсем нет MLOps, что означает, что у них может быть мало или совсем не быть автоматизации и, возможно, ограниченное сотрудничество между теми, кто занимается ML (например, учеными и разработчиками данных).
  • Уровень MLOps 2: организации с «более зрелыми» MLOps. Они могли разработать автоматизированные конвейеры для определенных аспектов рабочего процесса машинного обучения, например конвейер для автоматического обучения и развертывания модели.
  • Уровень MLOps 3: организации, полностью вовлеченные в MLOps. Они настолько автоматизировали рабочий процесс машинного обучения, что специалисты по данным могут обновлять некоторые или все конвейеры практически без вмешательства разработчиков.

Конечно, MLOps — это как совместная работа и формализация процессов, так и автоматизация.

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

Где PerceptiLabs подходит

Инструмент визуального моделирования PerceptiLabs в настоящее время поддерживает этапы «Архитектура и сборка» и «Оценка и настройка» «Управления моделями» в описанном выше рабочем процессе, предлагая ряд функций и преимуществ, которые помогают организациям в их усилиях по MLOps.

Визуальный характер PerceptiLabs обеспечивает общую среду и «язык», вокруг которого несколько участников, от специалистов по данным до инженеров машинного обучения и руководителей проектов, могут совместно работать над моделями — ключевой основой как для DevOps, так и для MLOps. Специалисты по данным могут создавать и экспериментировать с моделями с разным уровнем помощи разработчиков (в зависимости от их технических возможностей) и просматривать обширный набор статистических данных о производительности модели. Разработчики могут видеть, как именно была спроектирована модель, как каждый объект преобразует данные, а также просматривать и редактировать базовый код модели. Обладая этими знаниями, разработчики также могут разрабатывать и развертывать любой внешний код (например, JavaScript), который использует модель для выполнения логических выводов, синхронно, так что модель и внешний код могут быть формально упакованы вместе.

Пример простой модели нейронной сети в PerceptiLabs и всплывающее окно для установки параметров.

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

Эти функции важны для непрерывного обучения MLOps, которое требует проверки архитектуры модели и обученной модели в дополнение к выполнению тестов «на уровне кода» (например, модульных тестов, интеграционных тестов и т. д.), традиционно выполняемых в DevOps. эпоха. Кроме того, благодаря непрерывному обучению MLOps, направленному на автоматизацию повторного обучения развернутых моделей, присущая PerceptiLabs прозрачность помогает заинтересованным сторонам быстро понять и сравнить результаты новых итераций обучения.

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

Пример, показывающий некоторые статистические данные, представленные в PerceptiLabs.

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

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

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

Таким образом, точно так же, как традиционная разработка программного обеспечения привела к эволюции DevOps, уникальные аспекты машинного обучения привели к созданию MLOps. Несмотря на свое зачаточное состояние, MLOps завоевывает признание и популярность по мере роста машинного обучения, и рабочие процессы машинного обучения, несомненно, будут развиваться, как и решения PerceptiLabs. И хотя мы не можем избавиться от необходимости запоминать еще один термин «Ops», мы рады сообщить, что PerceptiLabs ускоряет машинное обучение, помогая командам проектировать, обучать и генерировать обученные модели в рамках их собственных «MLOps».

Чтобы ознакомиться с некоторыми практическими руководствами по началу работы с PerceptiLabs, обязательно ознакомьтесь с Видеоуроками PerceptiLabs.

Первоначально опубликовано на https://blog.perceptilabs.com.