Створіть наскрізний конвеєр MLOps для візуального контролю якості на краю – Частина 1 | Веб-сервіси Amazon

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

Впровадження конвеєра MLOps на межі створює додаткові складності, які ускладнюють процеси автоматизації, інтеграції та обслуговування через збільшення операційних витрат. Однак використання спеціально створених служб, як-от Amazon SageMaker та AWS IoT Greengrass дозволяє значно скоротити ці зусилля. У цій серії ми ознайомимо вас із процесом розробки та побудови інтегрованого наскрізного конвеєра MLOps для сценарію використання комп’ютерного бачення на межі за допомогою SageMaker, AWS IoT Greengrass та Набір хмарних розробок AWS (AWS CDK).

Ця публікація присвячена розробці загальної архітектури конвеєра MLOps; Частина 2 та Частина 3 цієї серії зосереджено на реалізації окремих компонентів. Ми надали зразок впровадження у супроводі GitHub сховище щоб ви спробували самі. Якщо ви тільки починаєте працювати з MLOps на краю AWS, зверніться до MLO на межі з Amazon SageMaker Edge Manager і AWS IoT Greengrass для огляду та еталонної архітектури.

Випадок використання: Перевірка якості металевих міток

Як інженеру ML важливо розуміти бізнес-кейс, над яким ви працюєте. Отже, перш ніж ми заглибимося в архітектуру конвеєра MLOps, давайте розглянемо приклад використання для цієї публікації. Уявіть собі виробничу лінію виробника, який гравірує металеві бирки для виготовлення індивідуальних багажних бирок. Процес забезпечення якості є дорогим, оскільки металеві бирки потрібно перевіряти вручну на наявність таких дефектів, як подряпини. Щоб зробити цей процес ефективнішим, ми використовуємо ML для виявлення несправних тегів на ранніх стадіях процесу. Це допомагає уникнути дорогих дефектів на наступних етапах виробничого процесу. Модель повинна майже в реальному часі визначати можливі дефекти, такі як подряпини, і позначати їх. У виробничих цехах вам часто доводиться мати справу з відсутністю підключення або обмеженою пропускною здатністю та підвищеною затримкою. Таким чином, ми хочемо впровадити on-edge ML-рішення для візуальної перевірки якості, яке може запускати висновки локально в цеху та зменшити вимоги щодо підключення. Щоб зробити наш приклад простим, ми навчаємо модель, яка позначає виявлені подряпини обмежувальними рамками. Наступне зображення є прикладом тега з нашого набору даних із трьома позначеними подряпинами.

Визначення архітектури конвеєра

Тепер ми отримали ясність щодо нашого випадку використання та конкретної проблеми машинного навчання, яку ми прагнемо вирішити, яка обертається навколо виявлення об’єктів на межі. Тепер настав час скласти проект архітектури для нашого конвеєра MLOps. На цьому етапі ми ще не розглядаємо технології чи конкретні послуги, а радше високорівневі компоненти нашого конвеєра. Щоб швидко перенавчати та розгортати, нам потрібно автоматизувати весь наскрізний процес: від маркування даних до навчання та висновків. Однак існує кілька проблем, які ускладнюють налаштування конвеєра для крайнього випадку:

• Побудова різних частин цього процесу вимагає різних наборів навичок. Наприклад, маркування та навчання даних мають сильний фокус на науці про дані, розгортання периферії потребує спеціаліста з Інтернету речей (IoT), а автоматизація всього процесу зазвичай виконується кимось із набором навичок DevOps.
• Залежно від вашої організації весь цей процес може виконуватися кількома командами. Для нашого випадку використання ми працюємо з припущенням, що окремі групи відповідають за маркування, навчання та розгортання.
• Більше ролей і наборів навичок означає інші вимоги до інструментів і процесів. Наприклад, дослідники даних можуть захотіти контролювати та працювати зі своїм знайомим середовищем ноутбука. Інженери MLOps хочуть працювати з використанням інструментів інфраструктури як коду (IaC) і можуть бути більш знайомі з ними Консоль управління AWS.

Що це означає для нашої конвеєрної архітектури?

По-перше, дуже важливо чітко визначити основні компоненти наскрізної системи, яка дозволяє різним командам працювати незалежно. По-друге, для підвищення ефективності співпраці необхідно визначити чітко визначені інтерфейси між командами. Ці інтерфейси допомагають мінімізувати перебої між командами, дозволяючи їм змінювати свої внутрішні процеси за потреби, якщо вони дотримуються визначених інтерфейсів. Наступна діаграма ілюструє, як це може виглядати для нашого конвеєра комп’ютерного зору.

Давайте детально розглянемо загальну архітектуру конвеєра MLOps:

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

Важливо відзначити, що необроблені дані зображення, позначений набір даних і навчена модель служать чітко визначеними інтерфейсами між окремими конвеєрами. Інженери MLOps і дослідники обробки даних мають можливість гнучко вибирати технології в рамках своїх конвеєрів, якщо вони постійно створюють ці артефакти. Найважливіше те, що ми встановили замкнутий цикл зворотного зв’язку. Помилкові або низьконадійні прогнози, зроблені у виробництві, можна використовувати для регулярного розширення нашого набору даних і автоматичного перенавчання та вдосконалення моделі.

Цільова архітектура

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

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

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

1. Служба простого зберігання Amazon (Amazon S3) використовується для зберігання необроблених даних зображень, оскільки це надає нам недороге рішення для зберігання.
2. Робочий процес маркування організовано за допомогою Функції кроку AWS, механізм безсерверного робочого процесу, який полегшує організацію етапів робочого процесу маркування. У рамках цього робочого процесу ми використовуємо Основна правда Amazon SageMaker для повної автоматизації маркування за допомогою завдань маркування та керованої робочої сили. AWS Lambda використовується для підготовки даних, запуску завдань маркування та зберігання етикеток Магазин функцій Amazon SageMaker.
3. SageMaker Feature Store зберігає мітки. Це дозволяє нам централізовано керувати нашими функціями та ділитися ними, а також надає нам вбудовані можливості керування версіями даних, що робить наш конвеєр більш надійним.
4. Ми керуємо створенням моделі та використанням конвеєра навчання Трубопроводи Amazon SageMaker. Він інтегрується з іншими необхідними функціями SageMaker за допомогою вбудованих кроків. Навчальні завдання SageMaker використовуються для автоматизації навчання моделі, і Завдання обробки SageMaker використовуються для підготовки даних і оцінки ефективності моделі. У цьому прикладі ми використовуємо Ultralytics YOLOv8 Пакет Python і архітектура моделі для навчання та експорту моделі виявлення об’єктів до ONNX Формат моделі ML для портативності.
5. Якщо продуктивність прийнятна, навчена модель реєструється в Реєстр моделей Amazon SageMaker із доданим номером версії. Він діє як наш інтерфейс між етапами навчання моделі та розгортання країв. Тут також ми керуємо станом затвердження моделей. Подібно до інших використовуваних послуг, він повністю керований, тому нам не потрібно піклуватися про роботу власної інфраструктури.
6. Робочий процес розгортання краю автоматизовано за допомогою покрокових функцій, подібних до робочого процесу маркування. Ми можемо використовувати API-інтеграції Step Functions для легкого виклику різноманітних необхідних API сервісів AWS, таких як AWS IoT Greengrass, для створення нових компонентів моделі та подальшого розгортання компонентів на крайньому пристрої.
7. AWS IoT Greengrass використовується як середовище виконання периферійних пристроїв. Він керує життєвим циклом розгортання нашої моделі та компонентів висновку на межі. Це дозволяє нам легко розгортати нові версії нашої моделі та компонентів висновку за допомогою простих викликів API. Крім того, моделі ML на краю зазвичай не працюють ізольовано; ми можемо використовувати різні AWS та співтовариство надав компоненти AWS IoT Greengrass для підключення до інших сервісів.

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

Об'єднання в надійну систему CI/CD

Позначення даних, навчання моделі та етапи розгортання країв є основою нашого рішення. Таким чином, будь-яка зміна, пов’язана з основним кодом або даними в будь-якій із цих частин, має ініціювати новий запуск усього процесу оркестровки. Щоб досягти цього, нам потрібно інтегрувати цей конвеєр у систему CI/CD, яка дозволить нам автоматично розгортати код та зміни інфраструктури з версійного сховища коду у виробництво. Подібно до попередньої архітектури, тут важливим аспектом є автономія команди. На наступній діаграмі показано, як це може виглядати за допомогою служб AWS.

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

1. Комісія AWS діє як наше сховище Git. Заради простоти у наданому зразку ми розділили окремі частини (маркування, навчання моделі, розгортання країв) за допомогою підпапок в одному репозиторії git. У реальному сценарії кожна команда може використовувати різні репозиторії для кожної частини.
2. Розгортання інфраструктури автоматизовано за допомогою AWS CDK, і кожна частина (маркування, навчання та периферія) отримує власну програму AWS CDK, щоб забезпечити незалежне розгортання.
3. Функція конвеєра AWS CDK використовує AWS CodePipeline для автоматизації інфраструктури та розгортання коду.
4. AWS CDK розгортає два конвеєри коду для кожного кроку: конвеєр ресурсів і конвеєр робочого процесу. Ми відокремили робочий процес від розгортання активів, щоб дозволити нам запускати робочі процеси окремо, якщо активи не змінюються (наприклад, коли є нові зображення, доступні для навчання).
   • Конвеєр коду активів розгортає всю інфраструктуру, необхідну для успішної роботи робочого процесу, наприклад Управління ідентифікацією та доступом AWS (IAM), лямбда-функції та зображення контейнерів, які використовуються під час навчання.
   • Конвеєр коду робочого процесу запускає фактичний робочий процес маркування, навчання або розгортання країв.
5. Конвеєри активів автоматично запускаються під час фіксації, а також після завершення попереднього конвеєра робочого процесу.
6. Весь процес запускається за розкладом за допомогою Amazon EventBridge правило регулярного перенавчання.

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

Думаючи наперед

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

Висновок

У цій публікації ми окреслили нашу архітектуру для побудови наскрізного конвеєра MLOps для візуальної перевірки якості на межі за допомогою сервісів AWS. Ця архітектура оптимізує весь процес, охоплюючи маркування даних, розробку моделі та периферійне розгортання, що дозволяє нам швидко та надійно навчати та впроваджувати нові версії моделі. Завдяки безсерверним і керованим службам ми можемо зосередитися на забезпеченні бізнесу, а не на управлінні інфраструктурою.

In Частина 2 У цій серії ми заглибимося на один рівень глибше та детальніше розглянемо реалізацію цієї архітектури, зокрема маркування та створення моделі. Якщо ви хочете відразу перейти до коду, ви можете ознайомитися з супроводом GitHub репо.

---

Про авторів

Майкл Рот є старшим архітектором рішень в AWS, який підтримує клієнтів-виробників у Німеччині у вирішенні їхніх бізнес-завдань за допомогою технології AWS. Окрім роботи та сім’ї, він цікавиться спортивними автомобілями та любить італійську каву.

Йорг Верле є архітектором рішень в AWS, який працює з клієнтами-виробниками в Німеччині. Маючи пристрасть до автоматизації, Йорг працював розробником програмного забезпечення, інженером DevOps та інженером з надійності сайтів у своєму житті до AWS. Крім хмари, він амбітний бігун і насолоджується якісним часом із сім’єю. Тож якщо у вас є виклик DevOps або ви хочете побігати: повідомте йому.

Йоганнес Лангер є старшим архітектором рішень в AWS, який працює з корпоративними клієнтами в Німеччині. Йоганнес захоплюється застосуванням машинного навчання для вирішення реальних бізнес-завдань. В особистому житті Йоганнес любить працювати над проектами з благоустрою будинку та проводити час на природі з сім’єю.

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
• PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
• ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
• PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
• джерело: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/