Оскільки корпоративні підприємства використовують машинне навчання (ML) у своїх організаціях, ручні робочі процеси для створення, навчання та розгортання моделей машинного навчання, як правило, стають вузькими місцями для інновацій. Щоб подолати це, підприємствам необхідно сформувати чітку операційну модель, яка визначатиме, як різні особи, такі як науковці з даних, інженери з даних, інженери ML, IT та зацікавлені сторони бізнесу, повинні співпрацювати та взаємодіяти; як розділити турботи, відповідальність та навички; і як оптимально використовувати служби AWS. Ця комбінація ML та операцій (MLOps) допомагає компаніям упорядкувати їхній життєвий цикл від кінця до кінця та підвищити продуктивність науковців із даними, зберігаючи високу точність моделі та підвищуючи безпеку та відповідність.
У цій публікації ви дізнаєтеся про ключові етапи створення основи MLOps, про те, як кілька людей працюють разом над цим фундаментом, а також Amazon SageMaker спеціально створені інструменти та вбудовані інтеграції з іншими службами AWS, які можуть прискорити впровадження ML у корпоративному бізнесі.
Модель зрілості MLOps
Створити базу MLOps, яка може покривати потреби корпоративних клієнтів, операцій, людей і технологій, є складною справою. Тому ми визначаємо наступну модель зрілості, яка визначає необхідні можливості MLOps на чотирьох ключових етапах.
- Початкова фаза: На цьому етапі науковці з даних можуть експериментувати та створювати, навчати й розгортати моделі на AWS за допомогою служб SageMaker. Пропоноване середовище розробки Студія Amazon SageMaker, в якому науковці даних можуть експериментувати та співпрацювати на основі ноутбуків Studio.
- Повторювана фаза – Завдяки можливості експериментувати на AWS, наступним кроком є створення автоматичних робочих процесів для попередньої обробки даних, а також створення й навчання моделей (конвеєри ML). Дослідники даних співпрацюють з інженерами ML в окремому середовищі для створення надійних і готових до виробництва алгоритмів і вихідного коду, організованого за допомогою Трубопроводи Amazon SageMaker. Згенеровані моделі зберігаються та перевіряються в реєстрі моделей Amazon SageMaker.
- Надійна фаза – Незважаючи на те, що моделі були створені за допомогою конвеєрів ML, їх потрібно протестувати, перш ніж вони будуть запущені у виробництво. Тому на цьому етапі вводиться методологія автоматичного тестування як для моделі, так і для інфраструктури запуску в ізольованому проміжному (попередньовиробничому) середовищі, яке імітує виробництво. Після успішного запуску тесту моделі розгортаються в ізольованому середовищі виробництва. Для просування моделей серед багатьох середовищ необхідна ручна оцінка та схвалення.
- Масштабована фаза – Після створення першого рішення ML необхідно масштабувати базу MLOps, щоб підтримувати декілька команд із науки про дані для співпраці та виробництва десятків чи сотень випадків використання машинного навчання. На цьому етапі ми вводимо шаблонизацію рішень, яка прискорює досягнення цінності за рахунок скорочення часу розробки нових виробничих рішень з тижнів до днів. Крім того, ми автоматизуємо створення безпечних середовищ MLOps, щоб дати можливість кільком командам працювати зі своїми даними, зменшуючи залежність та накладні витрати на ІТ.
У наступних розділах ми покажемо, як побудувати основу MLOps на основі попередньої моделі зрілості та наступних принципів:
- Гнучкість – Дослідники даних можуть вмістити будь-який фреймворк (наприклад, TensorFlow або PyTorch)
- Відтворюваність – Дослідники даних можуть відтворювати або спостерігати минулі експерименти (код, дані та результати)
- Багаторазовість – Дослідники даних та інженери з машинного навчання можуть повторно використовувати вихідний код і конвеєри ML, уникаючи невідповідностей та витрат
- масштабованість – Дослідники даних та інженери ML можуть масштабувати ресурси та послуги за потребою
- Аудит – Дослідники даних, IT та юридичні відділи можуть перевіряти журнали, версії та залежності артефактів та даних
- консистенція – Оскільки MLOps складається з кількох середовищ, фундамент повинен усунути розбіжності між середовищами
Початкова фаза
На початковому етапі мета полягає в тому, щоб створити безпечне експериментальне середовище, де науковець з даних отримує знімки даних і експерименти за допомогою ноутбуків SageMaker, щоб довести, що ML може вирішити конкретну бізнес-проблему. Щоб досягти цього, рекомендується середовище Studio зі спеціальним доступом до служб через кінцеві точки VPC. Вихідний код еталонної архітектури доступний у прикладах, наданих командою SageMaker на сайті Безпечна наука про дані за допомогою довідкової архітектури Amazon SageMaker Studio Репо GitHub.
На додаток до сервісів SageMaker, науковці даних можуть використовувати інші сервіси для обробки даних, наприклад Amazon EMR, Амазонка Афіна та Клей AWS, із зошитами, які зберігаються та версії Комісія AWS репозиторії (див. наступний малюнок).
Повторювана фаза
Після того, як науковці довели, що ML може вирішити бізнес-проблеми, і ознайомилися з експериментами, навчанням та розгортанням моделей SageMaker, наступним кроком буде розпочати виробництво рішення ML. Наступний малюнок ілюструє цю архітектуру.
На цьому етапі необхідно розділити турботу. Ми розділили середовище на кілька облікових записів AWS:
- Озеро даних – Зберігає всі втрачені дані з локальних (або інших систем) у хмарі. Інженери даних можуть створювати конвеєри вилучення, перетворення та завантаження (ETL), поєднуючи кілька джерел даних, і готувати необхідні набори даних для випадків використання ML. Дані каталогізуються через каталог AWS Glue Data Catalog і надаються іншим користувачам та обліковим записам через Формування озера AWS (рівень керування даними). У тому ж обліковому записі, Магазин функцій Amazon SageMaker може бути розміщений, але ми не розглядаємо це в цій публікації. Для отримання додаткової інформації див Увімкніть повторне використання функцій в облікових записах і командах за допомогою Amazon SageMaker Feature Store.
- Експериментація – Дозволяє науковцям з даних проводити свої дослідження. Єдина відмінність полягає в тому, що джерелом знімків даних є озеро даних. Дослідники даних мають доступ лише до певних наборів даних, які можна анонімізувати у разі GDPR або інших обмежень конфіденційності даних. Крім того, обліковий запис експерименту може мати доступ до Інтернету, щоб дати науковцям дозволити використовувати нові рамки для науки про дані або сторонні бібліотеки з відкритим кодом. Тому експериментальний рахунок розглядається як частина невиробничого середовища.
- Розробка (розробник) – Перший етап виробничого середовища. Дослідники даних переходять від ноутбуків до світу автоматичних робочих процесів і конвеєрів SageMaker. Їм потрібно співпрацювати з інженерами ML, щоб абстрагувати свій код і забезпечити охоплення тестування, обробки помилок і якості коду. Метою є розробка конвеєрів ML, які є автоматичними робочими процесами, які попередньо обробляють, навчають, оцінюють та реєструють моделі в реєстрі моделей SageMaker. Розгортання конвеєрів ML здійснюється лише через конвеєри CI/CD, а доступ до Консоль управління AWS обмежено. Підключення до Інтернету заборонено, оскільки конвеєр ML має доступ до виробничих даних в озері даних (лише для читання).
- Інструмент (або автоматизація) – Розміщує репозиторії CodeCommit, AWS CodePipeline Конвеєри CI/CD, реєстр моделі SageMaker і Amazon ECR для розміщення спеціальних контейнерів. Оскільки озеро даних є єдиною точкою істини для даних, обліковий запис інструментів призначений для коду, контейнерів і створених артефактів.
Зауважте, що ця конвенція щодо найменування облікових записів і стратегія кількох облікових записів можуть відрізнятися залежно від потреб вашого бізнесу, але ця структура призначена для показу рекомендованих рівнів ізоляції. Наприклад, ви можете перейменувати обліковий запис розробки на обліковий запис для навчання або створення моделі.
Щоб досягти автоматичного розгортання, важливо розуміти, як перейти від блокнотів до конвеєрів машинного навчання та стандартизувати сховища коду та структуру даних, які ми обговорюємо в наступних розділах.
Від ноутбуків до конвеєрів ML
Метою середовища розробки є реструктуризація, розширення, покращення та масштабування коду в блокнотах і переміщення його до конвеєрів ML. Конвеєр ML — це набір кроків, які відповідають за попередню обробку даних, навчання чи використання моделей, а також постобробку результатів. Кожен крок повинен виконувати одне завдання (конкретне перетворення) і бути достатньо абстрактним (наприклад, передавати імена стовпців як вхідні параметри), щоб забезпечити можливість повторного використання. Наступна діаграма ілюструє приклад конвеєра.
Щоб реалізувати конвеєри ML, науковці даних (або інженери ML) використовують SageMaker Pipelines. Конвеєр SageMaker — це серія взаємопов’язаних кроків (завдання обробки SageMaker, навчання, HPO), які визначаються визначенням конвеєра JSON за допомогою Python SDK. Це визначення конвеєра кодує конвеєр за допомогою орієнтованого ациклічного графа (DAG). Ця DAG надає інформацію про вимоги та взаємозв’язки між кожним кроком вашого конвеєра ML.
Залежно від варіанту використання ви можете розділити конвеєр ML на два основних типи: навчальний і пакетний висновок.
Наступний малюнок ілюструє потік конвеєра навчання ML.
Фаза попередньої обробки може складатися з кількох кроків. Поширені перетворення науки про дані — це розділення та вибірка даних (поїзд, перевірка, тестовий набір), одноразове кодування або векторізація, збирання та масштабування. Крок навчання моделі може бути або одним завданням навчання, якщо науковець з даних знає про найкращу конфігурацію моделі, або завданням оптимізації гіперпараметрів (HPO), в якому AWS визначає найкращі гіперпараметри для моделі (байєсіанський метод) і виробляє відповідні модельний артефакт. На етапі оцінки створений артефакт моделі використовується для виконання висновку щодо набору даних перевірки. Потім конвеєр ML перевіряє, чи отримані показники точності (такі як F1, точність і децилі посилення) перевершують необхідні пороги. Якщо цей крок успішний, артефакти моделі та метадані переміщуються до реєстру моделі для виробництва. Зауважте, що базовий етап експорту використовує експлойти Монітор моделі Amazon SageMaker функціональність, створюючи об’єкт JSON зі статистикою, яка пізніше використовується для виявлення дрейфу моделі та може бути розміщена в реєстрі моделі SageMaker як метадані моделі.
У разі групового висновку науковці даних можуть створювати подібні конвеєри, як показано на наступному малюнку.
Крок попередньої обробки пакетного висновку часто такий самий, як і навчання, виключаючи вибірку даних і стовпець основної істини. Пакетний висновок – це крок, який пакетами надсилає дані для висновку відповідній кінцевій точці і може бути реалізований за допомогою пакетне перетворення. Крок постобробки створює додаткову статистику, наприклад розподіл результатів, або об’єднує результати із зовнішніми ідентифікаторами. Потім крок моніторингу моделі може порівняти базову статистику даних, що використовуються для навчання (модель метаданих JSON у реєстрі моделі), з новими вхідними даними для висновку.
Ви можете пропустити етапи попередньої обробки, якщо науковці даних створюють моделі конвеєрів, які можна зберігати в реєстрі моделей SageMaker. Для отримання додаткової інформації див Моделі хостів разом із логікою попередньої обробки як конвеєр послідовного висновку за однією кінцевою точкою.
Стандартизація репозиторіїв
Щоб забезпечити співпрацю між науковцями з даних та інженерами ML, необхідна стандартизація структури сховища коду. Крім того, стандартизація корисна для структури конвеєра CI/CD, що дозволяє включити автоматичну перевірку, побудову (наприклад, створення спеціального контейнера) та етапи тестування.
Наступний приклад ілюструє поділ рішень ML на два репозиторії: сховище для створення та навчання для навчання (і, за бажанням, модель конвеєра) і розгортання для просування моделей конвеєра пакетного висновку або створення екземплярів кінцевих точок у реальному часі:
Будівництво/навчальний репозиторій
Репозиторій розгортання
Репозиторій будівель і навчання розділений на три основні папки:
- Алгоритми – Дослідники даних розробляють код для кожного кроку конвеєрів ML у кореневій папці algorithms. Етапи можна згрупувати в попередню обробку, навчання, груповий висновок та постобробку (оцінку). У кожній групі можна визначити кілька кроків у відповідних підпапках, які містять папку для модульних тестів (включаючи додаткові входи та виходи), основні функції, readme та файл Docker у разі потреби в спеціальному контейнері. На додаток до основного, в одній папці може бути розміщено кілька файлів коду. Загальні допоміжні бібліотеки для всіх кроків можуть бути розміщені в папці спільної бібліотеки. Дослідники даних відповідають за розробку модульних тестів, оскільки вони володіють логікою кроків, а інженери ML відповідають за покращення обробки помилок і рекомендації щодо покриття тестів. Конвеєр CI/CD відповідає за виконання тестів, автоматичне створення контейнерів (якщо необхідно) та упаковку кількох файлів вихідного коду.
- Трубопроводи ML – Після того як ви розробите вихідний код та тести кожного кроку, наступним кроком буде визначення конвеєрів SageMaker в іншій кореневій папці. Кожне визначення конвеєра ML розміщується у підпапці, яка містить файл .py і файл JSON або .yaml для вхідних параметрів, таких як діапазони гіперпараметрів. Для опису конвеєрів ML необхідний файл readme.
- Ноутбуки – У цій папці зберігаються вихідні блокноти, які науковець даних використовував під час експериментів.
Репозиторій розгортання складається з трьох основних частин:
- Конфігурація висновку – Містить конфігурацію кінцевих точок у реальному часі або пакетного висновку для кожного середовища розробки, наприклад типи екземплярів.
- Інфраструктура додатків – Розміщує вихідний код інфраструктури, необхідної для виконання висновку, якщо це необхідно. Це може бути механізмом запуску через Amazon EventBridge, API -шлюз Amazon, AWS Lambda функції або конвеєри SageMaker.
- Випробування – Складається з кількох вкладених папок залежно від методології тестування клієнта. Як мінімальний набір тестів ми пропонуємо інтеграційний тест (наскрізний запуск висновку, включаючи інфраструктуру додатків), стрес-тест (вивчення граничних випадків) і тести ML (наприклад, розподіл показників довіри або ймовірностей).
Вносячи зміни до сховища побудови та навчання, конвеєр CI/CD відповідає за перевірку структури сховища, виконання тестів, а також розгортання та запуск конвеєрів ML. За просування моделей відповідає інший конвеєр CI/CD, який ми розглянемо в наступному розділі.
Стандартизація розгалуження репозиторію та CI/CD
Щоб забезпечити надійність конвеєрів ML в обліковому записі розробника, пропонується стратегія сховища з багатьма розгалуженнями, тоді як розгортання виконується лише через конвеєри CI/CD. Дослідники даних повинні використовувати гілку функцій для розробки своєї нової функціональності (вихідного коду). Коли вони будуть готові розгорнути відповідні конвеєри ML, вони можуть передати це до гілки розробки. Альтернативою цьому підходу є можливість розгортання конвеєрів ML для кожної гілки функції. Для отримання додаткової інформації див Покращуйте свій робочий процес науки про дані за допомогою багатогалузевого навчального конвеєра MLOps за допомогою AWS.
Наступний малюнок ілюструє стратегію розгалуження та необхідні кроки конвеєра CI/CD, які ми виконуємо в середовищі розробника для конвеєру ML та побудови моделі.
Приклад коду багатогалузевого підходу доступний у Багатогалузевий навчальний конвеєр MLOps. Ми можемо зберігати моделі, створені конвеєром ML на основі гілок, в окремій групі моделей функцій і виводити їх з експлуатації під час запиту на злиття з основною гілкою. Моделі в основній групі моделей – це ті, які висуваються до виробництва.
Стандартизація структури даних
Не менш важливою для стандартизації вихідного коду є стандартизація структури даних, яка дозволяє науковцям з даних та інженерам з машинного машинного навчання налагоджувати, аудити та контролювати походження та історію моделей і конвеєрів машинного машинного навчання. Наведена нижче діаграма ілюструє такий приклад.
Для простоти припустимо, що вхідні історичні дані потрапляють у відро облікового запису розробки під підключом введення (зазвичай він знаходиться в озері даних). Для кожного випадку використання ML необхідно створити окремий підключ. Щоб запустити новий конвеєр ML, науковець даних повинен виконати git commit та push, що запускає конвеєр CI/CD. Потім конвеєр CI/CD створює підключ шляхом копіювання артефактів коду ( code
підключ) і вхідні дані ( input
підключ) у підрозділі ідентифікатора збірки. Як приклад, ідентифікатор збірки cбути комбінацією дати-часу та хешу git або ідентифікатором запуску конвеєра SageMaker. Ця структура дозволяє досліднику даних проводити аудит і запитувати попередні розгортання та запуски. Після цього конвеєр CI/CD розгортає та запускає конвеєр ML. Поки конвеєр ML працює, кожен крок експортує проміжні результати до ml-pipeline-outputs
. Важливо пам’ятати, що різні гілки функцій розгортають і запускають новий екземпляр конвеєра ML, і кожній з них потрібно експортувати проміжні результати в іншу підтеку з новим підключом та/або стандартизованим префіксом або суфіксом, який включає ідентифікатор гілки функції.
Цей підхід підтримує повну ревізійність кожного експерименту. Однак багатогалузевий підхід стратегії розвитку генерує велику кількість даних. Тому необхідна стратегія життєвого циклу даних. Ми пропонуємо видаляти принаймні дані кожного конвеєра гілки функцій ML у кожному успішному запиті на витяг/злиття. Але це залежить від операційної моделі та деталізації аудиту, яку потрібно підтримувати вашому бізнесу. Ви можете використовувати подібний підхід у конвеєрах ML для пакетного висновку
Надійна фаза
Після початкового розділення проблем між науковцями з даних, інженерами ML та інженерами даних за допомогою кількох облікових записів, наступним кроком є просування створених моделей із реєстру моделей до ізольованого середовища для виконання висновків. Однак ми повинні забезпечити надійність розгорнутих моделей. Тому імітація розгорнутої моделі в дзеркальному середовищі виробництва є обов’язковою, а саме перед виробництвом (або етапом).
Наступний малюнок ілюструє цю архітектуру.
Просування розгортання моделі та кінцевої точки в середовищі попереднього виробництва здійснюється за допомогою подій оновлення статусу реєстру моделі (або git push у сховищі розгортання), що запускає окремий конвеєр CI/CD за допомогою подій EventBridge. Перший крок конвеєра CI/CD вимагає схвалення вручну від провідного спеціаліста з обробки даних (і за бажанням власника продукту, бізнес-аналітика чи іншого провідного спеціаліста з даних). Затверджувач повинен перевірити KPI продуктивності моделі та QA коду в репозиторії розгортання. Після затвердження конвеєр CI/CD запускає тестовий код у репозиторій розгортання (тест інтеграції, стрес-тест, тест ML). На додаток до кінцевої точки моделі, CI/CD також тестує інфраструктуру запуску, таку як EventBridge, функції Lambda або API Gateway. На наступній схемі показано цю оновлену архітектуру.
Після успішного запуску тестів конвеєр CI/CD повідомляє нових (або тих самих) схвалювачів про те, що модель готова до запуску у виробництво. На цьому етапі бізнес-аналітик може захотіти виконати деякі додаткові перевірки статистичних гіпотез на основі результатів моделі. Після затвердження моделі та інфраструктура запуску розгортаються у виробництво. SageMaker підтримує кілька методів розгортання, наприклад синій/зелений, Canary та A/B-тестування (докладніше див. Розгортання огорож). Якщо конвеєр CI/CD виходить з ладу, механізм відкату повертає систему до останнього надійного стану.
Наступна діаграма ілюструє основні кроки конвеєра CI/CD для просування моделі та інфраструктури для запуску кінцевої точки моделі, наприклад шлюзу API, функцій Lambda і EventBridge.
Інтеграція озера даних та MLOps
На цьому етапі важливо зрозуміти вимоги до даних для кожного етапу розробки або облікового запису, а також спосіб об’єднання MLOps із централізованим озером даних. Наступна діаграма ілюструє шари MLOps і озера даних.
В озері даних інженери даних відповідають за об’єднання кількох джерел даних і створення відповідних наборів даних (наприклад, однієї таблиці даних структури або однієї папки з файлами PDF або зображеннями) для випадків використання ML шляхом створення ETL. трубопроводи, як визначено науковцями з даних (під час фази аналізу даних розвідки). Ці набори даних можна розділити на історичні дані та дані для висновку та тестування. Усі дані каталогізуються (наприклад, за допомогою каталогу AWS Glue Data Catalog) і можуть бути надані іншим обліковим записам та користувачам за допомогою Lake Formation як рівня керування даними (для структурованих даних). На момент написання цієї статті Lake Formation сумісний лише із запитами Athena, завданнями AWS Glue та Amazon EMR.
З іншого боку, середовище MLOps має зрошувати конвеєри ML певними наборами даних, розташованими в локальних відрах у dev, pre-prod і prod. Середовище розробника відповідає за створення та навчання моделей на вимогу за допомогою конвеєрів SageMaker, які витягують дані з озера даних. Тому ми пропонуємо в якості першого кроку конвеєра або мати крок Athena, де потрібні лише вибірки даних і запити, або крок Amazon EMR, якщо потрібні більш складні перетворення. Крім того, ви можете використовувати завдання AWS Glue через крок зворотного виклику, але поки що не в якості основного кроку для SageMaker Pipelines.
Pre-prod і prod відповідають за тестування або проведення в режимі реального часу та групового висновку. У разі висновку в режимі реального часу надсилання даних до облікових записів MLOps pre-prod і prod не є необхідним, оскільки вхід для висновку може підключатися до корисного навантаження запиту шлюзу API. У разі пакетного висновку (або вхідних даних великого розміру), необхідні набори даних, або тестові дані, або дані для висновку, повинні потрапити в локальні корзини даних ML (pre-prod або prod). У вас є два варіанти переміщення даних у pre-prod і prod: або запустити Athena або Amazon EMR і витягнути дані з озера даних, або передати дані з озера даних до цих облікових записів MLOps. Перший варіант вимагає розробки додаткових механізмів в облікових записах MLOps, наприклад, створення запланованих подій EventBridge (не знаючи, чи були дані в озері даних оновлені) або надходження даних до подій S3 EventBridge в озері даних (для детальніше див Спрощення доступу між обліковими записами за допомогою політик ресурсів Amazon EventBridge). Після перехоплення події на стороні MLOps запит Athena або Amazon EMR можуть отримати дані локально та ініціювати асинхронний висновок or пакетне перетворення. Це можна загорнути в конвеєр SageMaker для простоти. Другий варіант — додати на останньому кроці конвеєра ETL функціональність передачі даних у сегменти MLOps. Однак цей підхід змішує відповідальність (озеро даних ініціює висновок) і вимагає від Lake Formation надати доступ до озера даних для запису в сегменти MLOps.
Останнім кроком є переміщення результатів висновку назад до озера даних. Щоб каталогизувати дані та зробити їх доступними для інших користувачів, дані мають повернутися як нове джерело даних назад у цільовий сегмент.
Масштабована фаза
Після розробки основи MLOps і наскрізного виробництва першого випадку використання ML, інфраструктура dev, pre-prod, prod і репозиторій, конвеєр CI/CD і структура даних були протестовані та завершені. . Наступним кроком є включення нових варіантів використання ML і команд на платформу. Щоб забезпечити швидкість одержання вартості, SageMaker дозволяє створювати власні шаблони проектів SageMaker, які можна використовувати для автоматичного створення екземплярів шаблонів і конвеєрів CI/CD. За допомогою таких шаблонів проектів SageMaker провідні спеціалісти з даних відповідають за створення екземплярів нових проектів і виділення спеціальної команди для нових випадків використання ML.
Наступна діаграма ілюструє цей процес.
Проблема стає складнішою, якщо різні команди науковців з даних (або кілька бізнес-підрозділів, яким потрібно розробити ML) мають доступ до різних конфіденційних даних, а кілька власників продуктів відповідають за оплату окремого рахунку за навчання, розгортання та запуск моделей. . Тому для кожної команди необхідний окремий набір облікових записів MLOps (експериментація, розробник, попередня продукція та prod). Щоб полегшити створення нових облікових записів MLOps, ми представляємо ще один обліковий запис, обліковий запис для керування розширеною аналітичною інформацією, який доступний для ІТ-членів і дозволяє їм каталогізувати, створювати або вилучати облікові записи MLOps за запитом. Зокрема, цей обліковий запис містить репозиторії з кодом інфраструктури облікових записів MLOps (VPC, підмережі, кінцеві точки, сегменти, Управління ідентифікацією та доступом AWS (IAM) ролі та політика, AWS CloudFormation стеки), an Каталог послуг AWS продукт для автоматичного розгортання стеків інфраструктури CloudFormation для кількох облікових записів одним клацанням миші та Amazon DynamoDB таблицю для каталогізації метаданих, наприклад, яка команда відповідає за кожен набір облікових записів. Завдяки цій можливості IT-команда створює екземпляри облікових записів MLOps за запитом і виділяє необхідних користувачів, доступ до даних для кожного облікового запису та послідовні обмеження безпеки.
Виходячи з цього сценарію, ми розділяємо облікові записи на ефемерні та тривалі. Озеро даних і інструменти є довготривалими обліковими записами і відіграють роль єдиної точки істини для даних і вихідного коду відповідно. Облікові записи MLOps здебільшого не мають громадянства і створюються або вилучаються за запитом, що робить їх нетривалими. Навіть якщо набір облікових записів MLOps знято з експлуатації, користувачі або аудитори можуть перевірити минулі експерименти та результати, оскільки вони зберігаються в довготривалому середовищі.
Якщо ви хочете використовувати Studio UI для MLOps, обліковий запис інструментів є частиною облікового запису розробника, як показано на наступному малюнку.
Якщо користувач хоче використовувати інтерфейс Sagemaker Studio для MLOps, обліковий запис інструментів є частиною розробника
рахунок, як показано на малюнку вище. Приклад вихідного коду цього фонду MLOPs можна знайти в
Безпечна база MLOps для кількох облікових записів на основі CDK.
Зауважте, що Sagemaker надає можливість замінити CodeCommit і CodePipeline іншими інструментами розробки сторонніх розробників, такими як GitHub і Jenkins (додаткову інформацію можна знайти в Створюйте проекти Amazon SageMaker за допомогою стороннього контролю джерел і Jenkins та Проекти Amazon SageMaker MLOps Шаблон з GitLab і GitLab Pipelines).
Резюме персон, операцій та технологій
За допомогою моделі зрілості MLOps ми можемо визначити чіткий дизайн архітектури та дорожню карту доставки. Однак кожна особа повинна мати чітке уявлення про ключові облікові записи та сервіси AWS, з якими потрібно взаємодіяти, і операції, які потрібно проводити. Наступна діаграма підсумовує ці категорії.
Висновок
Надійна основа MLOps, яка чітко визначає взаємодію між кількома особами та технологіями, може збільшити швидкість одержання вартості та знизити вартість, а також дати науковцям з даних зосередитися на інноваціях. У цій публікації ми показали, як поетапно побудувати таку основу, що приведе до плавної моделі зрілості MLOps для бізнесу та можливості підтримки кількох груп із наукових досліджень даних та випадків використання машинного машинного навчання у виробництві. Ми визначили операційну модель, яка складається з кількох персон із різними навичками та обов’язками. Нарешті, ми поділилися прикладами того, як стандартизувати розробку коду (сховища та конвеєри CI/CD), зберігання та обмін даними, а також забезпечення безпечної інфраструктури MLOps для корпоративних середовищ. Багато корпоративних клієнтів скористалися цим підходом і можуть виробляти свої рішення ML протягом кількох днів, а не місяців.
Якщо у вас є коментарі чи запитання, залиште їх у розділі коментарів.
Про автора
Доктор Сократіс Картакіс є старшим спеціалістом з машинного навчання архітектором рішень для веб-сервісів Amazon. Sokratis зосереджується на тому, щоб дати можливість корпоративним клієнтам індустріалізувати свої рішення з машинного навчання (ML), використовуючи послуги AWS і формуючи їх операційну модель, тобто основу MLOps, і дорожню карту трансформації, використовуючи найкращі методи розробки. Він витратив понад 15 років на винайдення, проектування, керівництво та впровадження інноваційних наскрізних рішень ML та Інтернету речей (IoT) у сферах енергетики, роздрібної торгівлі, охорони здоров’я, фінансів/банківської справи, автоспорту тощо. Сократіс любить проводити вільний час з родиною та друзями або кататися на мотоциклах.
Георгіос Схінас є спеціалістом архітектора рішень для AI/ML у регіоні EMEA. Він знаходиться в Лондоні і тісно співпрацює з клієнтами у Великобританії та Ірландії. Georgios допомагає клієнтам розробляти та розгортати програми машинного навчання у виробництві на AWS, особливо цікавлячись практиками MLOps і дозволяючи клієнтам виконувати машинне навчання в масштабі. У вільний час він любить подорожувати, готувати і проводити час з друзями та родиною.
Джузеппе Анджело Порчеллі є головним спеціалістом з машинного навчання архітектором рішень для веб-сервісів Amazon. Маючи кілька років розробки програмного забезпечення та досвіду машинного навчання, він працює з клієнтами будь-якого розміру, щоб глибоко зрозуміти їхні бізнес- та технічні потреби та розробити рішення для штучного інтелекту та машинного навчання, які найкращим чином використовують хмару AWS та стек машинного навчання Amazon. Він працював над проектами в різних областях, включаючи MLOps, Computer Vision, NLP, і залучаючи широкий набір послуг AWS. У вільний час Джузеппе любить грати у футбол.
Шелбі Айгенброде є головним архітектором рішень спеціалістів із штучного інтелекту та машинного навчання в Amazon Web Services (AWS). Вона працює в технологіях протягом 24 років, охоплюючи різні галузі, технології та ролі. Наразі вона зосереджується на поєднанні свого досвіду DevOps і ML у сфері MLOps, щоб допомогти клієнтам доставляти та керувати робочими навантаженнями ML у масштабі. Маючи понад 35 патентів, наданих у різних технологічних областях, вона має пристрасть до постійних інновацій та використання даних для досягнення результатів бізнесу. Шелбі є співавтором і викладачем спеціалізації з практичних наук про дані на Coursera. Вона також є співдиректором відділу Women In Big Data (WiBD) у Денвері. У вільний час вона любить проводити час з родиною, друзями та надмірно активними собаками.
- Coinsmart. Найкраща в Європі біржа біткойн та криптовалют.
- Платоблокчейн. Web3 Metaverse Intelligence. Розширені знання. БЕЗКОШТОВНИЙ ДОСТУП.
- CryptoHawk. Альткойн Радар. Безкоштовне випробування.
- Джерело: https://aws.amazon.com/blogs/machine-learning/mlops-foundation-roadmap-for-enterprises-with-amazon-sagemaker/
- "
- 100
- a
- здатність
- МЕНЮ
- РЕЗЮМЕ
- прискорювати
- доступ
- доступною
- розмістити
- рахунки
- Achieve
- через
- доповнення
- Додатковий
- Прийняття
- просунутий
- проти
- AI
- алгоритми
- ВСІ
- дозволяє
- альтернатива
- Amazon
- Amazon Web Services
- серед
- кількість
- аналіз
- аналітик
- аналітика
- Інший
- API
- додаток
- застосування
- підхід
- архітектура
- аудит
- автоматизувати
- автоматичний
- автоматично
- Автоматизація
- доступний
- уникає
- AWS
- фон
- Базова лінія
- оскільки
- ставати
- перед тим
- за
- корисний
- КРАЩЕ
- між
- Великий даних
- Білл
- підвищення
- будувати
- Створюємо
- вбудований
- бізнес
- підприємства
- можливості
- випадок
- випадків
- централізована
- складні
- Глава
- Перевірки
- classic
- хмара
- код
- співпрацювати
- співробітництво
- Колонка
- поєднання
- коментарі
- commit
- загальний
- Компанії
- сумісний
- повний
- комплекс
- дотримання
- комп'ютер
- Проводити
- Проведення
- довіра
- конфігурація
- зв'язку
- послідовний
- Контейнер
- Контейнери
- містить
- контроль
- копіювання
- Відповідний
- може
- обкладинка
- створювати
- створений
- створює
- створення
- створення
- В даний час
- виготовлений на замовлення
- клієнт
- Клієнти
- дані
- доступ до даних
- аналіз даних
- конфіденційність даних
- наука про дані
- вчений даних
- зберігання даних
- Днів
- присвячених
- доставка
- Попит
- Денвер
- Залежно
- залежить
- розгортання
- розгорнути
- розгортання
- розгортання
- розгортання
- розгортає
- описувати
- дизайн
- проектування
- деталі
- Виявлення
- DEV
- розвивати
- розробка
- інструменти розробки
- різниця
- різний
- обговорювати
- розподіл
- Docker
- домен
- домени
- управляти
- керований
- під час
- кожен
- край
- усунутий
- обійняти
- включіть
- дозволяє
- дозволяє
- кінець в кінець
- Кінцева точка
- енергія
- Машинобудування
- Інженери
- підприємство
- підприємств
- Навколишнє середовище
- і т.д.
- оцінювати
- оцінка
- Event
- Події
- точно
- приклад
- Приклади
- виключення
- експеримент
- подвигів
- дослідження
- сім'я
- особливість
- Рисунок
- в кінці кінців
- Перший
- потік
- Сфокусувати
- фокусується
- фокусування
- після
- футбол
- освіта
- знайдений
- фонд
- Підвалини
- Рамки
- каркаси
- Безкоштовна
- від
- функціональність
- Функції
- Крім того
- шлюз
- GDPR
- генерується
- Git
- GitHub
- мета
- управління
- надається
- Group
- Обробка
- мішанина
- здоров'я
- допомога
- допомогу
- допомагає
- Високий
- історичний
- історія
- відбувся
- Як
- How To
- Однак
- HTTPS
- Сотні
- Особистість
- зображень
- здійснювати
- реалізовані
- реалізації
- важливо
- удосконалювати
- includes
- У тому числі
- Augmenter
- промисловості
- інформація
- Інфраструктура
- інновація
- інновації
- інноваційний
- вхід
- екземпляр
- інтеграція
- інтеграцій
- взаємодія
- інтерес
- інтерфейс
- інтернет
- Інтернет речей
- КАТО
- Ірландія
- ізоляція
- IT
- робота
- Джобс
- приєднання
- з'єднання
- тримати
- ключ
- знання
- великий
- останній
- шар
- вести
- провідний
- УЧИТЬСЯ
- вивчення
- Залишати
- легальний
- рівні
- використання
- бібліотека
- загрузка
- місцевий
- локально
- Лондон
- машина
- навчання за допомогою машини
- зробити
- Робить
- управляти
- управління
- обов'язковий
- керівництво
- зрілість
- механізм
- члени
- Злиття
- Методологія
- методика
- Метрика
- може бути
- mind
- мінімальний
- дзеркало
- ML
- модель
- Моделі
- монітор
- місяців
- більше
- Автоспорт
- рухатися
- переміщення
- множинний
- а саме
- Імена
- іменування
- необхідно
- потреби
- наступний
- нормально
- працювати
- операційний
- операції
- оптимізація
- варіант
- Опції
- порядок
- організації
- оригінал
- Інше
- власний
- власник
- Власники
- частина
- приватність
- партія
- пристрасть
- Патенти
- Люди
- продуктивність
- виконанні
- фаза
- платформа
- Play
- ігри
- будь ласка
- точка
- Політика
- Готувати
- Головний
- недоторканність приватного життя
- Проблема
- процес
- обробка
- Вироблений
- Product
- Production
- продуктивність
- проект
- проектів
- сприяти
- просування
- забезпечувати
- за умови
- забезпечує
- тягне
- якість
- RE
- реального часу
- зменшити
- зниження
- регіон
- реєструвати
- Відносини
- надійний
- Сховище
- запросити
- запитів
- вимагається
- Вимога
- Вимагається
- дослідження
- ресурс
- ресурси
- обов'язки
- відповідальний
- результати
- роздрібна торгівля
- повертати
- Умови повернення
- Дорожня карта
- стійкість
- Роль
- корінь
- прогін
- біг
- то ж
- масштабовані
- шкала
- Масштабування
- плановий
- наука
- вчений
- Вчені
- Sdk
- безпечний
- безпеку
- послідовний
- Серія
- обслуговування
- Послуги
- комплект
- установка
- кілька
- Форма
- загальні
- поділ
- Показувати
- аналогічний
- моделювання
- один
- Розмір
- навички
- Софтвер
- розробка програмного забезпечення
- рішення
- Рішення
- ВИРІШИТИ
- деякі
- вихідні
- спеціаліст
- конкретний
- конкретно
- швидкість
- витрачати
- Витрати
- розкол
- стек
- Стажування
- етапи
- старт
- стан
- статистичний
- статистика
- Статус
- зберігання
- зберігати
- магазинів
- Стратегія
- раціоналізувати
- стрес
- структурований
- студія
- успішний
- підтримка
- Підтриманий
- Опори
- система
- Systems
- команда
- команди
- технічний
- Технології
- Технологія
- Шаблони
- тест
- Тестування
- Тести
- Команда
- Джерело
- світ
- отже
- речі
- третя сторона
- три
- час
- разом
- інструменти
- поїзд
- Навчання
- Перетворення
- Перетворення
- перетворень
- Подорож
- Типи
- ui
- Uk
- при
- розуміти
- одиниць
- Оновити
- використання
- користувачі
- використовувати
- перевірка достовірності
- значення
- різний
- вид
- бачення
- Web
- веб-сервіси
- в той час як
- в
- без
- жінки
- Work
- працював
- Робочі процеси
- працює
- світ
- лист
- років
- вашу