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

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

Обзор решения

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

Автоматизация маркировки данных

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

• Предоставьте разработчикам этикеток инструмент для рисования ограничивающих рамок.
• Управляйте штатом этикетировщиков
• Обеспечьте хорошее качество этикетки
• Управляйте нашими данными и метками и проверяйте их версии.
• Организуйте весь процесс
• Интегрируйте его в систему CI/CD

Все это мы можем сделать с помощью сервисов AWS. Чтобы облегчить маркировку и управление нашей рабочей силой, мы используем Amazon SageMaker Ground Truth, сервис маркировки данных, который позволяет вам создавать и управлять собственными рабочими процессами и рабочей силой маркировки данных. Вы можете управлять собственным персоналом этикетировщиков или использовать возможности внешних этикетировщиков через Амазонка Механический Турок или сторонние поставщики.

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

Задания маркировки используются для управления рабочими процессами маркировки. SageMaker Ground Truth предоставляет готовые шаблоны для множества различных типов задач по маркировке, включая рисование ограничивающих рамок. Дополнительные сведения о настройке задания маркировки для задач ограничивающего прямоугольника см. в статье Оптимизация маркировки данных для обнаружения объектов YOLO в Amazon SageMaker Ground Truth. В нашем случае мы адаптируем шаблон задачи для задач с ограничивающей рамкой и используем человеческие аннотаторы, предоставленные Mechanical Turk, для маркировки наших изображений по умолчанию. На следующем снимке экрана показано, что видит создатель меток при работе с изображением.

Далее поговорим о качестве этикеток. Качество наших этикеток повлияет на качество нашей модели ML. При автоматизации маркировки изображений с привлечением внешнего персонала, такого как Mechanical Turk, сложно обеспечить хорошее и стабильное качество этикеток из-за отсутствия опыта в данной области. Иногда требуется частная рабочая сила экспертов в предметной области. Однако в нашем примере решения мы используем Mechanical Turk для автоматической маркировки наших изображений.

Существует множество способов обеспечить хорошее качество этикеток. Дополнительную информацию о передовом опыте можно найти в докладе AWS re:Invent 2019, Создавайте точные наборы обучающих данных с помощью Amazon SageMaker Ground Truth.. В рамках этого примера решения мы решили сосредоточиться на следующем:

Наконец, нам нужно подумать о том, как хранить наши метки, чтобы их можно было повторно использовать для обучения позже, и обеспечить возможность отслеживания используемых данных обучения модели. Результатом задания по маркировке SageMaker Ground Truth является файл в формате строк JSON, содержащий метки и дополнительные метаданные. Мы решили использовать автономный магазин Amazon SageMaker Feature Store для хранения наших этикеток. По сравнению с простым хранением этикеток в Amazon Simple Storage Service (Amazon S3) это дает нам несколько явных преимуществ:

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

Знакомство с хранилищем функций SageMaker см. в разделе «Начало работы с хранилищем функций Amazon SageMaker». SageMaker Feature Store поддерживает хранение функций в табличном формате. В нашем примере мы сохраняем следующие функции для каждого помеченного изображения:

• Место хранения изображения на Amazon S3.
• Размеры изображения
• Координаты ограничивающего прямоугольника и значения класса
• Флаг состояния, указывающий, одобрена ли метка для использования в обучении.
• Имя задания по маркировке, использованное для создания этикетки.

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

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

Организация маркировки данных

Наконец, пришло время автоматизировать и организовать каждый этап процесса маркировки! Для этого мы используем AWS Step Functions, бессерверный сервис рабочих процессов, который предоставляет нам интеграцию API для быстрой координации и визуализации шагов нашего рабочего процесса. Мы также используем набор функций AWS Lambda для некоторых более сложных шагов, в частности следующих:

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

На следующем рисунке показано, как выглядит полный конечный автомат маркировки Step Functions.

Маркировка: развертывание инфраструктуры и интеграция в CI/CD

Последним шагом является интеграция рабочего процесса Step Functions в нашу систему CI/CD и обеспечение развертывания необходимой инфраструктуры. Для выполнения этой задачи мы используем AWS Cloud Development Kit (AWS CDK) для создания всей необходимой инфраструктуры, такой как функции Lambda и рабочий процесс Step Functions. С помощью CDK Pipelines, модуля AWS CDK, мы создаем конвейер в AWS CodePipeline, который развертывает изменения в нашей инфраструктуре и запускает дополнительный конвейер для запуска рабочего процесса Step Functions. Интеграция Step Functions в CodePipeline значительно упрощает эту задачу. Мы используем действия Amazon EventBridge и CodePipeline Source, чтобы гарантировать, что конвейер запускается по расписанию, а также при отправке изменений в git.

На следующей диаграмме подробно показано, как выглядит архитектура CI/CD для маркировки.

Резюме: автоматизация маркировки данных

Теперь у нас есть работающий конвейер для автоматического создания этикеток из немаркированных изображений металлических бирок с помощью SageMaker Ground Truth. Изображения берутся с Amazon S3 и передаются в программу маркировки SageMaker Ground Truth. После маркировки изображений мы проверяем качество с помощью задания по проверке этикеток. Наконец, метки сохраняются в группе функций в SageMaker Feature Store. Если вы хотите попробовать рабочий пример самостоятельно, ознакомьтесь с прилагаемым Репозиторий GitHub. Давайте посмотрим, как автоматизировать построение моделей дальше!

Автоматизация построения моделей

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

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

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

1. Преобразуйте существующий код предварительной обработки, обучения и оценки в сценарии командной строки.
2. Создайте определение конвейера SageMaker для управления построением модели. Используйте сценарии, созданные на первом этапе, как часть этапов обработки и обучения.
3. Интегрируйте конвейер в рабочий процесс CI/CD.

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

• preprocess.py – Это извлекает помеченные изображения из хранилища функций SageMaker, разбивает набор данных и преобразует его в необходимый формат для обучения нашей модели, в нашем случае входной формат для YOLOv8.
• поезд.py – Это тренирует Модель обнаружения объектов Ultralytics YOLOv8 использование PyTorch для обнаружения царапин на изображениях металлических меток

Организация построения модели

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

Он состоит из следующих шагов:

1. Шаг обработки для загрузки новейших функций из хранилища функций SageMaker; разделить набор данных на обучающий, проверочный и тестовый наборы; и сохраните наборы данных в виде архивов для обучения.
2. TrainingStep для обучения модели с использованием наборов данных обучения, проверки и тестирования и экспорта средней метрики средней точности (mAP) для модели.
3. ConditionStep для оценки того, превышает ли значение метрики mAP обученной модели настроенный порог. В этом случае выполняется шаг RegisterModel, который регистрирует обученную модель в реестре моделей SageMaker.

Если вас интересует подробный код конвейера, см. определение конвейера в нашем демонстрационном репозитории.

Обучение: Развертывание инфраструктуры и интеграция в CI/CD

Теперь пришло время для шага 3: интеграции в рабочий процесс CI/CD. Наш конвейер CI/CD следует той же схеме, что показана в разделе маркировки ранее. Мы используем AWS CDK для развертывания необходимых конвейеров из CodePipeline. Единственное отличие состоит в том, что мы используем конвейеры Amazon SageMaker вместо пошаговых функций. Определение конвейера SageMaker создается и запускается как часть действия CodeBuild в CodePipeline.

Заключение

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

Ознакомьтесь с третьей частью этой серии, где мы более подробно рассмотрим последний этап нашего рабочего процесса MLOps. Мы создадим конвейер, который компилирует и развертывает модель на периферийном устройстве с помощью AWS IoT Greengrass!

Об авторах

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

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

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