Создание сквозного конвейера MLOps для визуального контроля качества на периферии — Часть 1

Переиздано Платоном

Читают: 0

Успешное развертывание модели машинного обучения (ML) в производственной среде во многом зависит от сквозного конвейера ML. Хотя разработка такого конвейера может быть сложной задачей, она становится еще более сложной, когда имеешь дело с Вариант использования Edge ML. Машинное обучение на периферии — это концепция, которая обеспечивает возможность локального запуска моделей машинного обучения на периферийных устройствах. Для развертывания, мониторинга и обслуживания этих моделей на периферии требуется надежный конвейер MLOps. Конвейер MLOps позволяет автоматизировать полный жизненный цикл машинного обучения: от маркировки данных до обучения и развертывания модели.

Реализация конвейера MLOps на периферии создает дополнительные сложности, которые усложняют процессы автоматизации, интеграции и обслуживания из-за увеличения эксплуатационных накладных расходов. Однако использование специально созданных сервисов, таких как Создатель мудреца Амазонки и AWS IoT Greengrass позволяет существенно сократить эти усилия. В этой серии мы познакомим вас с процессом проектирования и построения интегрированного сквозного конвейера MLOps для сценария использования компьютерного зрения на периферии с использованием SageMaker, AWS IoT Greengrass и Комплект для разработки облачных сервисов AWS (АВС ЦДК).

Этот пост посвящен проектированию общей архитектуры конвейера MLOps; Часть 2 и Часть 3 В этой серии основное внимание уделяется реализации отдельных компонентов. Мы предоставили пример реализации в сопроводительном документе. Репозиторий GitHub чтобы ты попробовал себя. Если вы только начинаете использовать MLOps на периферии AWS, см. MLOps на периферии с помощью Amazon SageMaker Edge Manager и AWS IoT Greengrass для обзора и эталонной архитектуры.

Вариант использования: проверка качества металлических бирок.

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

Определение архитектуры конвейера

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

Создание различных частей этого процесса требует разных навыков. Например, маркировка данных и обучение имеют сильный акцент на науке о данных, периферийное развертывание требует специалиста по Интернету вещей (IoT), а автоматизация всего процесса обычно выполняется кем-то с набором навыков DevOps.
В зависимости от вашей организации весь этот процесс может даже выполняться несколькими командами. В нашем случае мы работаем исходя из предположения, что за маркировку, обучение и развертывание отвечают отдельные команды.
Больше ролей и наборов навыков означает разные требования, когда дело касается инструментов и процессов. Например, специалисты по обработке данных могут захотеть отслеживать и работать в привычной среде записной книжки. Инженеры MLOps хотят работать с использованием инструментов «инфраструктура как код» (IaC) и могут быть более знакомы с Консоль управления AWS.

Что это означает для нашей конвейерной архитектуры?

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

Давайте подробно рассмотрим общую архитектуру конвейера MLOps:

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

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

Целевая архитектура

Теперь, когда высокоуровневая архитектура создана, пришло время пойти на один уровень глубже и посмотреть, как мы можем построить ее с помощью сервисов AWS. Обратите внимание: архитектура, показанная в этом посте, предполагает, что вы хотите получить полный контроль над всем процессом обработки данных. Однако, если вы только начинаете с контроля качества на границе, мы рекомендуем Amazon Lookout для видения. Он дает возможность обучить вашу собственную модель контроля качества без необходимости создавать, поддерживать или понимать код ML. Для получения дополнительной информации см. Amazon Lookout for Vision теперь поддерживает визуальную проверку дефектов продукта на периферии..

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

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

Простой сервис хранения Amazon (Amazon S3) используется для хранения необработанных данных изображений, поскольку предоставляет нам недорогое решение для хранения.
Рабочий процесс маркировки организуется с помощью Шаговые функции AWS, бессерверный механизм рабочего процесса, который упрощает координацию этапов рабочего процесса маркировки. В рамках этого рабочего процесса мы используем Amazon SageMaker - основа правды полностью автоматизировать маркировку, используя рабочие места по маркировке и управляемую рабочую силу. AWS Lambda используется для подготовки данных, запуска заданий по маркировке и сохранения этикеток в Магазин функций Amazon SageMaker.
В магазине функций SageMaker хранятся метки. Это позволяет нам централизованно управлять нашими функциями и делиться ими, а также предоставляет нам встроенные возможности управления версиями данных, что делает наш конвейер более надежным.
Мы организуем процесс построения и обучения моделей, используя Конвейеры Amazon SageMaker. Он интегрируется с другими функциями SageMaker, необходимыми с помощью встроенных шагов. Вакансии: обучение SageMaker используются для автоматизации обучения модели и SageMaker Обработка заданий используются для подготовки данных и оценки производительности модели. В этом примере мы используем Ультралитики YOLOv8 Архитектура пакета и модели Python для обучения и экспорта модели обнаружения объектов в ОННКС Формат модели ML для переносимости.
Если производительность приемлема, обученная модель регистрируется в Реестр моделей Amazon SageMaker с прикрепленным дополнительным номером версии. Он действует как интерфейс между этапами обучения модели и периферийного развертывания. Здесь мы также управляем состоянием утверждения моделей. Как и другие используемые сервисы, он полностью управляем, поэтому нам не нужно заботиться о работе собственной инфраструктуры.
Рабочий процесс периферийного развертывания автоматизирован с помощью Step Functions, аналогично рабочему процессу маркировки. Мы можем использовать API-интеграцию Step Functions, чтобы легко вызывать различные необходимые API-интерфейсы сервисов AWS, такие как AWS IoT Greengrass, для создания новых компонентов модели и последующего развертывания этих компонентов на периферийном устройстве.
AWS IoT Greengrass используется в качестве среды выполнения периферийных устройств. Он управляет жизненным циклом развертывания нашей модели и компонентов вывода на периферии. Это позволяет нам легко развертывать новые версии нашей модели и компонентов вывода, используя простые вызовы API. Кроме того, модели машинного обучения на периферии обычно не работают изолированно; мы можем использовать различные AWS и сообщество предоставил компоненты AWS IoT Greengrass для подключения к другим сервисам.

Описанная архитектура напоминает нашу высокоуровневую архитектуру, показанную ранее. Amazon S3, SageMaker Feature Store и SageMaker Model Registry выступают в качестве интерфейсов между различными конвейерами. Чтобы свести к минимуму усилия по запуску и эксплуатации решения, мы везде, где это возможно, используем управляемые и бессерверные сервисы.

Объединение в надежную систему CI/CD

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

Давайте пройдемся по архитектуре CI/CD:

AWS CodeCommit действует как наш репозиторий Git. Для простоты в нашем примере мы разделили отдельные части (маркировка, обучение модели, периферийное развертывание) через подпапки в одном репозитории git. В реальном сценарии каждая команда может использовать разные репозитории для каждой части.
Развертывание инфраструктуры автоматизировано с помощью AWS CDK, и каждая часть (маркировка, обучение и периферия) получает собственное приложение AWS CDK, позволяющее осуществлять независимое развертывание.
Функция конвейера AWS CDK использует Кодовый конвейер AWS для автоматизации развертывания инфраструктуры и кода.
AWS CDK развертывает два конвейера кода для каждого шага: конвейер активов и конвейер рабочих процессов. Мы отделили рабочий процесс от развертывания ресурсов, чтобы иметь возможность запускать рабочие процессы отдельно в случае отсутствия изменений ресурсов (например, когда для обучения доступны новые изображения).
- Конвейер кода актива развертывает всю инфраструктуру, необходимую для успешного выполнения рабочего процесса, например Управление идентификацией и доступом AWS (IAM), функции Lambda и образы контейнеров, используемые во время обучения.
- Конвейер кода рабочего процесса запускает фактический рабочий процесс маркировки, обучения или периферийного развертывания.
Конвейеры активов автоматически запускаются при фиксации, а также при завершении предыдущего конвейера рабочего процесса.
Весь процесс запускается по расписанию с использованием Amazon EventBridge правило регулярной переподготовки.

Благодаря интеграции CI/CD вся сквозная цепочка теперь полностью автоматизирована. Конвейер запускается при каждом изменении кода в нашем репозитории git, а также по расписанию, учитывающему изменения данных.

Думать о будущем

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

Заключение

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

In Часть 2 В этой серии мы углубимся на один уровень и рассмотрим реализацию этой архитектуры более подробно, в частности, маркировку и построение моделей. Если вы хотите сразу перейти к коду, вы можете просмотреть прилагаемый Репо GitHub.

Об авторах

Майкл Рот — старший архитектор решений в AWS, помогающий клиентам-производителям в Германии решать их бизнес-задачи с помощью технологий AWS. Помимо работы и семьи, он увлекается спортивными автомобилями и любит итальянский кофе.

Йорг Верле — архитектор решений в AWS, работающий с производственными заказчиками в Германии. Будучи страстным поклонником автоматизации, Йорг до прихода в AWS работал разработчиком программного обеспечения, DevOps-инженером и инженером по надежности объектов. Помимо облаков, он амбициозный бегун и любит проводить время со своей семьей. Так что, если у вас есть задача DevOps или вы хотите пробежаться: сообщите ему об этом.

Йоханнес Лангер — старший архитектор решений в AWS, работающий с корпоративными клиентами в Германии. Йоханнес увлечен применением машинного обучения для решения реальных бизнес-задач. В личной жизни Йоханнес любит работать над проектами по благоустройству дома и проводить время на свежем воздухе со своей семьей.