Построение полноценного конвейера MLOps для визуальной проверки качества на краю – Часть 1

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

Успешное развертывание модели машинного обучения (ML) в производственной среде тесно связано с ML-конвейером от начала до конца. Хотя разработка такого конвейера может быть сложной, она становится еще более сложной при работе с кейсами использования edge ML. Машинное обучение на краю – это концепция, которая позволяет запускать модели ML локально на устройствах края. Чтобы развернуть, отслеживать и поддерживать эти модели на краю, требуется надежный конвейер MLOps. Конвейер MLOps позволяет автоматизировать полный жизненный цикл ML от разметки данных до обучения и развертывания модели.

Внедрение конвейера MLOps на краю вводит дополнительные сложности, которые усложняют автоматизацию, интеграцию и процессы поддержки из-за увеличенной нагрузки на операционные задачи. Однако использование специальных сервисов, таких как Amazon SageMaker и AWS IoT Greengrass, позволяет значительно снизить затраты. В этой серии мы рассмотрим процесс проектирования и создания интегрированного конвейера MLOps от начала до конца для задачи компьютерного зрения на краю, используя SageMaker, AWS IoT Greengrass и AWS Cloud Development Kit (AWS CDK).

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

Пример использования: проверка качества металлических ярлыков

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

• Автоматизируйте предварительное разрешение с использованием CRD с помощью CDS Hooks и AWS HealthLake.
• LangChain 101 Часть 2с. Тонкая настройка LLM с использованием PEFT, LORA и RL
• 10 способов оптимизировать расходы на Azure

Defining the pipeline architecture

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

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

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

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

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

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

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

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

Теперь, когда установлена общая архитектура, пришло время спуститься на уровень глубже и рассмотреть, как мы можем построить это с помощью сервисов AWS. Обратите внимание, что архитектура, показанная в этой статье, предполагает, что вы хотите получить полный контроль над всем процессом науки о данных. Однако, если вы только начинаете с инспекции качества на краю, мы рекомендуем воспользоваться Amazon Lookout for Vision. Это предоставляет возможность обучить вашу собственную модель инспекции качества, не обладая знаниями ML-кода и не затратив усилия на ее создание и поддержку. Для получения дополнительной информации обратитесь к статье Amazon Lookout for Vision now supports visual inspection of product defects at the edge.

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

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

1. Простой сервис хранения Amazon (Amazon S3) используется для хранения сырых изображений, поскольку он обеспечивает нам экономичное решение для хранения данных.
2. Процесс разметки оркестрируется с помощью AWS Step Functions, безсерверный рабочий процессный движок, который облегчает оркестрацию шагов рабочего процесса разметки. В рамках этого рабочего процесса мы используем Amazon SageMaker Ground Truth для полностью автоматизированной разметки с использованием заданий разметки и управления трудовыми коллективами. Для подготовки данных, запуска заданий разметки и хранения меток мы используем AWS Lambda и хранилище функций Amazon SageMaker (Amazon SageMaker Feature Store).
3. Хранилище функций SageMaker хранит метки. Оно позволяет нам централизованно управлять и делиться нашими функциями и обеспечивает встроенные возможности версионирования данных, что делает нашу конвейерную систему более надежной.
4. Мы оркестрируем создание и обучение модели с помощью Amazon SageMaker Pipelines. Он интегрируется с другими необходимыми функциями SageMaker при помощи встроенных шагов. Используются задания обучения SageMaker (SageMaker Training jobs) для автоматизации обучения модели и задания обработки SageMaker (SageMaker Processing jobs) для подготовки данных и оценки производительности модели. В этом примере мы используем пакет и архитектуру модели Ultralytics YOLOv8, написанные на Python, для обучения и экспорта модели обнаружения объектов в формат модели машинного обучения ONNX для удобства переноса.
5. Если производительность удовлетворительна, обученная модель регистрируется в Amazon SageMaker Model Registry с прикрепленным инкрементным номером версии. Он действует как наш интерфейс между обучением моделей и развертыванием на устройствах. Здесь мы также управляем состоянием одобрения моделей. Как и другие используемые сервисы, он полностью управляемый, поэтому нам не нужно обеспечивать собственную инфраструктуру.
6. Рабочий процесс развертывания на устройстве автоматизирован с использованием Step Functions, аналогично рабочему процессу разметки. Мы можем использовать API-интеграции Step Functions для вызова различных требуемых API-интерфейсов служб AWS, таких как AWS IoT Greengrass, для создания новых компонентов модели и последующего развертывания этих компонентов на устройстве на краю сети.
7. AWS IoT Greengrass используется в качестве среды выполнения на устройстве на границе сети. Он управляет жизненным циклом развертывания нашей модели и компонентов вывода на границе сети. С помощью простых API-вызовов мы можем легко развернуть новые версии нашей модели и компонентов вывода. Кроме того, модели машинного обучения на пограничных устройствах обычно не работают изолированно; мы можем использовать различные AWS и предоставленные сообществом компоненты AWS IoT Greengrass для подключения к другим службам.

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

Включение в надежную систему CI/CD

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

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

1. AWS CodeCommit выступает в качестве нашего Git-репозитория. В нашем образце мы разделили отдельные части (разметка, обучение модели, развертывание на краю) с помощью подпапок в одном репозитории git для упрощения. В реальной ситуации каждая команда может использовать разные репозитории для каждой части.
2. Автоматизация развертывания инфраструктуры осуществляется с использованием AWS CDK, и каждая часть (разметка, обучение и край) получает свое собственное приложение AWS CDK для независимого развертывания.
3. Функция AWS CDK Pipeline использует AWS CodePipeline для автоматизации развертывания инфраструктуры и кода.
4. AWS CDK развертывает два кодовых конвейера для каждого шага: конвейер активов и конвейер рабочего процесса. Мы разделили рабочий процесс от развертывания активов, чтобы иметь возможность запускать рабочие процессы отдельно, если нет изменений активов (например, когда доступны новые изображения для обучения).
   • Конвейер развертывания активов разворачивает всю необходимую для успешного выполнения рабочего процесса инфраструктуру, такую как IAM-роли AWS Identity and Access Management, функции Lambda и контейнерные образы, используемые во время обучения.
   • Конвейер кода рабочего процесса запускает фактический рабочий процесс разметки, обучения или развертывания на краю.
5. Конвейеры активов автоматически запускаются при фиксации, а также после завершения предыдущего конвейера рабочего процесса.
6. Весь процесс запускается по расписанию с использованием правила Amazon EventBridge для регулярного переобучения.

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

Предвидение

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

• Внедрите многоконтурную настройку, чтобы улучшить уровень безопасности. Дополнительные сведения можно найти в статье MLOps в области с помощью Amazon SageMaker Edge Manager и AWS IoT Greengrass.
• Разместите архитектуру в шаблон, чтобы ее можно было использовать другими командами, например, с помощью SageMaker Projects. Дополнительную информацию можно найти в статье Создание пользовательских шаблонов проектов SageMaker – лучшие практики.

Заключение

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

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