MLOps: жизненный цикл машинного обучения

млн операций в секунду

MLOps: жизненный цикл машинного обучения

Жизненный цикл машинного обучения для эпохи MLOps объединяет разработку моделей и программного обеспечения для создания продуктов с поддержкой машинного обучения.

Создание продуктов машинного обучения или функций продукта с помощью ML включает в себя две отдельные дисциплины:

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

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

• Инженерия данных. Создавайте конвейеры данных для сбора данных из разрозненных источников, отбора и преобразования их, а также преобразования их в однородные, чистые данные, которые можно безопасно использовать для обучения моделей.
• Дизайн продукта: понимание потребностей бизнеса, определение важных целей и соответствующих бизнес-матриц; определить функции продукта или пользовательские истории для этих целей, распознать основные проблемы, для решения которых ML лучше подходит; спроектируйте пользовательский интерфейс, чтобы не только использовать прогнозирование модели ML без проблем с остальными функциями продукта, но также собирать (ре)действие пользователя как неявную оценку результатов модели и использовать его для улучшения моделей.
• Анализ безопасности. Убедитесь, что программная система, данные и модель защищены, а личная информация (PII) не раскрывается путем объединения результатов моделирования и другой общедоступной информации или данных.
• Этика искусственного интеллекта. Обеспечьте соблюдение всех применимых законов и добавьте меры для защиты от любого рода предвзятости (например, ограничьте масштаб модели, добавьте человеческий контроль и т. д.).

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

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

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

Жизненный цикл разработки модели

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

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

Сформулировать

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

• Бизнес-цель: сузить до небольшого набора проблем машинного обучения, которые могут служить бизнес-цели.
• Цена ошибок. Ни одна модель машинного обучения не может быть на 100 % точной. Какова стоимость ложноположительных и ложноотрицательных результатов? Например, если модель классификации изображений ошибочно предсказывает рак молочной железы у здорового человека, дальнейшие тесты исправят это. Но если модель не сможет диагностировать рак у пациента, то он может оказаться фатальным из-за позднего выявления.
• Доступность данных. Это может стать неожиданностью, но вы можете начать без данных и запустить сбор данных. По мере того, как данные становятся богаче, это может сделать жизнеспособными больше типов моделей. Например, если вы должны были выполнить обнаружение аномалий без помеченных данных, вы можете начать с различных видов неконтролируемых алгоритмов кластеризации и пометить точки, которые не входят ни в один кластер, как аномалии. Но по мере того, как вы собираете реакцию пользователей на свою модель, у вас будет помеченный набор данных. Затем вы можете попробовать, будет ли модель контролируемой классификации работать лучше.
• Метрики оценки. В зависимости от формулировки проблемы вы также должны указать метрику производительности модели для оптимизации, которая должна соответствовать бизнес-метрике для вашей бизнес-цели.

Собирать

Собирайте необходимые данные из внутренних приложений, а также из внешних источников. Это может быть удаление из Интернета, захват потоков событий из вашего мобильного приложения или веб-службы, потоков Change Data Capture (CDC) из операционных (OLTP) баз данных, журналов приложений и т. д. Вы можете загрузить все необходимые данные в свои данные. конвейер», который разработан и поддерживается инженерами данных.

Куратор

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

Трансформировать

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

Подтвердить

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

Исследовать

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

Тренироваться

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

Оценивать

Сравните характеристики модели с бизнес-целями и показателями. Некоторая обратная связь может привести к тому, что проблема машинного обучения будет изменена и сформулирована по-другому, а весь процесс будет повторяться снова и снова.

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

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

Жизненный цикл разработки программного обеспечения

Бесконечный цикл DevOps является фактическим стандартом жизненного цикла разработки программного обеспечения для быстрого создания и развертывания программных приложений и сервисов в облаке.

Он состоит из двух наборов действий: проектирование и разработка программной системы и развертывание и мониторинг программных сервисов и приложений.

План

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

Код

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

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

Строить

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

Тест

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

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

Выпускать

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

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

Развертывать

Выбор выпущенных артефактов из репозитория Docker или хранилища моделей и их развертывание в производственной инфраструктуре. В зависимости от ваших потребностей вы можете выбрать Инфраструктура как услуга (IaaS), Контейнер как услуга (CaaS) или Платформа как услуга (PaaS).

Вы также можете использовать TensorFlow Serve, PyTorch Serve или такие сервисы, как SageMaker и Vertex AI, для развертывания сервисов вашей модели.

Работать

После развертывания сервисов вы можете решить сначала отправлять небольшой процент трафика. Canary Deployment — распространенная тактика поэтапного обновления (например, 2%, 5%, 10%, 25%, 75%, 100%). В случае возникновения проблемы, непредвиденного поведения или снижения показателей можно выполнить откат развертывания.

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

Монитор

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

Жизненный цикл MLOps

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

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

Шаг плана — отправная точка

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

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

Сначала создайте продукт без машинного обучения

Я часто сначала создаю сквозное приложение с эвристикой на основе правил или фиктивной моделью, полностью отсекая цикл Data-ML. Это работает как базовая модель и полезна при сборе данных. Это также дает контекст исследователям данных, показывая, как модель будет использоваться в продукте.

Различная частота для разработки моделей и программного обеспечения

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

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

Консолидированное владение, ранняя интеграция, частые итерации

Вот мои 3 рекомендации по повышению успешности разработки и развертывания продуктов с поддержкой машинного обучения:

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

Краткое содержание

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

Если вам понравилось, пожалуйста:

Первоначально опубликовано на ML4Devs.com.