Співавтором цього допису в блозі є Гільєрмо Рібейро, старший науковець із даних Cepsa.
Машинне навчання (ML) швидко еволюціонувало від модної тенденції, що виникла в академічному середовищі та інноваційних відділах, до того, щоб стати ключовим засобом надання цінності компаніям у кожній галузі. Цей перехід від експериментів у лабораторіях до вирішення реальних проблем у виробничому середовищі йде рука об руку MLOps, або адаптація DevOps до світу машинного навчання.
MLOps допомагає оптимізувати й автоматизувати повний життєвий цикл моделі ML, зосереджуючись на вихідних наборах даних, відтворюваності експерименту, коді алгоритму ML і якості моделі.
At Цепса, міжнародної енергетичної компанії, ми використовуємо ML для вирішення складних проблем у всіх сферах діяльності, від прогнозного обслуговування промислового обладнання до моніторингу та вдосконалення нафтохімічних процесів на наших нафтопереробних заводах.
У цій публікації ми обговорюємо, як ми побудували нашу еталонну архітектуру для MLOps, використовуючи такі ключові служби AWS:
- Amazon SageMaker, сервіс для створення, навчання та розгортання моделей ML
- Функції кроку AWS, безсерверна служба візуального робочого процесу з низьким кодом, яка використовується для оркестрування та автоматизації процесів
- Amazon EventBridge, безсерверна шина подій
- AWS Lambda, безсерверна обчислювальна служба, яка дозволяє запускати код без підготовки та керування серверами
Ми також пояснюємо, як ми застосували цю еталонну архітектуру для завантаження нових проектів машинного навчання в нашій компанії.
Змагання
Протягом останніх 4 років кілька напрямків діяльності Cepsa дали старт проектам МЛ, але незабаром почали виникати певні проблеми та обмеження.
У нас не було еталонної архітектури для ML, тому кожен проект мав різний шлях реалізації, виконуючи спеціальне навчання моделі та розгортання. Без загального методу обробки коду та параметрів проекту та без реєстру моделі ML або системи управління версіями ми втратили відстежуваність між наборами даних, кодом і моделями.
Ми також виявили можливості для вдосконалення способу роботи з моделями у виробництві, оскільки ми не відстежували розгорнуті моделі і тому не мали засобів для відстеження продуктивності моделей. Як наслідок, ми зазвичай перенавчали моделі на основі графіків, оскільки нам не вистачало правильних показників для прийняття обґрунтованих рішень щодо перенавчання.
Рішення
Виходячи з труднощів, які нам довелося подолати, ми розробили загальне рішення, яке мало на меті відокремити підготовку даних, навчання моделі, висновок і моніторинг моделі, а також включило централізований реєстр моделей. Таким чином ми спростили керування середовищами для кількох облікових записів AWS, одночасно запровадивши централізоване відстеження моделі.
Наші вчені та розробники даних використовують AWS Cloud9 (хмарна IDE для написання, запуску та налагодження коду) для боротьби з даними та експериментів з машинним навчанням, а також GitHub як сховище коду Git.
Робочий процес автоматичного навчання використовує код, створений командою з обробки даних, щоб тренувати моделі на SageMaker і реєструвати вихідні моделі в реєстрі моделей.
Інший робочий процес керує розгортанням моделі: він отримує посилання з реєстру моделі та створює кінцеву точку висновку за допомогою Функції хостингу моделі SageMaker.
Ми реалізували робочі процеси як для навчання моделі, так і для розгортання за допомогою функції Step Functions, оскільки вона надала гнучку структуру, яка дає змогу створювати окремі робочі процеси для кожного проекту та керувати різними сервісами та компонентами AWS простим способом.
Модель споживання даних
У Cepsa ми використовуємо низку озер даних, щоб задовольнити різноманітні потреби бізнесу, і всі ці озера даних мають спільну модель споживання даних, яка полегшує інженерам і дослідникам даних пошук і використання необхідних даних.
Щоб легко впоратися з витратами та відповідальністю, середовища озера даних повністю відокремлені від додатків виробників і споживачів даних і розгорнуті в різних облікових записах AWS, що належать до спільної організації AWS.
Дані, які використовуються для навчання моделей ML, і дані, які використовуються як вихідні дані для навчених моделей, стають доступними з різних озер даних через набір чітко визначених API за допомогою API -шлюз Amazon, сервіс для створення, публікації, підтримки, моніторингу та захисту API у масштабі. Сервер API використовує Амазонка Афіна (інтерактивна служба запитів для аналізу даних за допомогою стандартного SQL) для доступу до даних, які вже зберігаються в Служба простого зберігання Amazon (Amazon S3) і каталогізовано в Клей AWS Каталог даних.
На наступній діаграмі наведено загальний огляд архітектури MLOps Cepsa.
Модельний тренінг
Процес навчання є незалежним для кожної моделі та керується a Стандартний робочий процес крокових функцій, що дає нам можливість моделювати процеси на основі різних вимог проекту. У нас є визначений базовий шаблон, який ми повторно використовуємо в більшості проектів, вносячи незначні коригування за потреби. Наприклад, деякі власники проектів вирішили додати ручні ворота для схвалення розгортання нових виробничих моделей, тоді як інші власники проектів запровадили власні механізми виявлення помилок і повторних спроб.
Ми також виконуємо перетворення вхідних наборів даних, які використовуються для навчання моделі. Для цього ми використовуємо функції Lambda, які інтегровані в навчальні робочі процеси. У деяких сценаріях, де потрібні складніші перетворення даних, ми запускаємо наш код Служба еластичних контейнерів Amazon (Amazon ECS) увімкнено AWS Fargate, безсерверний обчислювальний механізм для запуску контейнерів.
Наша команда досліджень даних часто використовує спеціальні алгоритми, тому ми використовуємо цю можливість використовувати спеціальні контейнери в навчанні моделі SageMaker, спираючись на Реєстр контейнерів Amazon Elastic (Amazon ECR), повністю керований реєстр контейнерів, який спрощує зберігання, керування, спільний доступ і розгортання зображень контейнерів.
Більшість наших проектів ML базуються на бібліотеці Scikit-learn, тому ми розширили стандарт Контейнер для навчання SageMaker Scikit щоб включити змінні середовища, необхідні для проекту, такі як інформація про сховище Git і параметри розгортання.
За такого підходу нашим дослідникам даних просто потрібно зосередитися на розробці алгоритму навчання та вказати бібліотеки, необхідні для проекту. Коли вони надсилають зміни коду до репозиторію Git, наша система CI/CD (Дженкінс розміщений на AWS) створює контейнер із навчальним кодом і бібліотеками. Цей контейнер надсилається до Amazon ECR і, нарешті, передається як параметр для виклику навчання SageMaker.
Після завершення процесу навчання отримана модель зберігається в Amazon S3, до реєстру моделей додається посилання, а вся зібрана інформація та показники зберігаються в каталозі експериментів. Це забезпечує повну відтворюваність, оскільки код алгоритму та бібліотеки пов’язані з навченою моделлю разом із даними, пов’язаними з експериментом.
Наступна діаграма ілюструє модель процесу навчання та перепідготовки.
Розгортання моделі
Архітектура є гнучкою та дозволяє як автоматичне, так і ручне розгортання навчених моделей. Робочий процес розгортання моделі автоматично викликається за допомогою події, яку навчання SageMaker публікує в EventBridge після завершення навчання, але його також можна викликати вручну, якщо потрібно, передаючи правильну версію моделі з реєстру моделей. Щоб отримати додаткові відомості про автоматичний виклик, див Автоматизація Amazon SageMaker за допомогою Amazon EventBridge.
Робочий процес розгортання моделі отримує інформацію про модель із реєстру моделі та використовує AWS CloudFormation, керована інфраструктура як служба коду, щоб або розгорнути модель у кінцевій точці логічного висновку в реальному часі, або виконати пакетний логічний висновок із збереженим набором вхідних даних, залежно від вимог проекту.
Кожного разу, коли модель успішно розгортається в будь-якому середовищі, реєстр моделі оновлюється новим тегом, що вказує, у яких середовищах модель зараз працює. Кожного разу, коли кінцева точка видаляється, її тег також видаляється з реєстру моделі.
На наступній діаграмі показано робочий процес для розгортання моделі та висновку.
Реєстр експериментів і моделей
Зберігання кожного експерименту та версії моделі в одному розташуванні та наявність централізованого сховища коду дозволяє нам відокремити навчання моделі та розгортання та використовувати різні облікові записи AWS для кожного проекту та середовища.
Усі записи експерименту зберігають ідентифікатор фіксації коду навчання та висновку, тому ми маємо повну відстежуваність усього процесу експерименту та можемо легко порівнювати різні експерименти. Це запобігає повторній роботі на етапі наукового дослідження для алгоритмів і моделей і дає нам змогу розгортати наші моделі будь-де, незалежно від облікового запису та середовища, де було навчено модель. Це також стосується моделей, навчених у нашому експериментальному середовищі AWS Cloud9.
Загалом, у нас є повністю автоматизовані конвеєри навчання та розгортання моделей, а також ми маємо гнучкість для швидкого ручного розгортання моделі, коли щось працює неналежним чином або коли команді потрібна модель, розгорнута в іншому середовищі для експериментальних цілей.
Детальний варіант використання: проект YET Dragon
Проект YET Dragon спрямований на покращення продуктивності нафтохімічного заводу Cepsa в Шанхаї. Для досягнення цієї мети ми ретельно вивчили виробничий процес, шукаючи менш ефективні етапи. Наша мета полягала в тому, щоб підвищити ефективність виходу процесів, утримуючи концентрацію компонентів точно нижче порогового значення.
Для моделювання цього процесу ми побудували чотири узагальнені адитивні моделі або GAM, лінійні моделі, відповідь яких залежить від плавних функцій змінних предикторів, щоб передбачити результати двох процесів окислення, одного процесу концентрації та вищезгаданого виходу. Ми також створили оптимізатор для обробки результатів чотирьох моделей GAM і пошуку найкращих оптимізацій, які можна застосувати на заводі.
Незважаючи на те, що наші моделі навчаються з історичними даними, інколи завод може працювати за обставин, які не були зареєстровані в наборі навчальних даних; ми очікуємо, що наші імітаційні моделі не працюватимуть належним чином за таких сценаріїв, тому ми також створили дві моделі виявлення аномалій, використовуючи алгоритми ізольованих лісів, які визначають, наскільки далеко знаходяться точки даних до решти даних для виявлення аномалій. Ці моделі допомагають нам виявляти такі ситуації, щоб відключати автоматизовані процеси оптимізації, коли це трапляється.
Промислові хімічні процеси дуже різноманітні, і моделі ML мають бути добре узгоджені з роботою заводу, тому потрібне часте перенавчання, а також відстеження моделей, що застосовуються в кожній ситуації. YET Dragon був нашим першим проектом з оптимізації машинного навчання, який мав реєстр моделей, повну відтворюваність експериментів і повністю керований автоматизований процес навчання.
Тепер повний конвеєр, який передає модель у виробництво (перетворення даних, навчання моделі, відстеження експерименту, реєстр моделі та розгортання моделі), є незалежним для кожної моделі ML. Це дозволяє нам ітераційно вдосконалювати моделі (наприклад, додавати нові змінні чи тестувати нові алгоритми) і підключати етапи навчання та розгортання до різних тригерів.
Результати та майбутні вдосконалення
Зараз ми можемо автоматично навчати, розгортати та відстежувати шість моделей ML, які використовуються в проекті YET Dragon, і ми вже розгорнули понад 30 версій для кожної з виробничих моделей. Ця архітектура MLOps була розширена до сотень моделей ML в інших проектах компанії.
Ми плануємо продовжувати запускати нові проекти YET на основі цієї архітектури, яка зменшила середню тривалість проекту на 25% завдяки скороченню часу завантаження та автоматизації конвеєрів машинного навчання. Ми також оцінили економію близько 300,000 XNUMX євро на рік завдяки збільшенню врожайності та концентрації, що є прямим результатом проекту YET Dragon.
Короткострокова еволюція цієї архітектури MLOps спрямована на моніторинг моделі та автоматизоване тестування. Ми плануємо автоматично перевірити ефективність моделі порівняно з попередньо розгорнутими моделями перед розгортанням нової моделі. Ми також працюємо над впровадженням моніторингу моделі та моніторингу дрейфу даних Монітор моделі Amazon SageMaker, з метою автоматизації перенавчання моделей.
Висновок
Компанії стикаються з проблемою автоматизованого та ефективного впровадження своїх проектів МЛ у виробництво. Автоматизація повного життєвого циклу моделі ML допомагає скоротити час виконання проекту та забезпечує кращу якість моделі, а також швидше й частіше розгортання у виробництві.
Розробивши стандартизовану архітектуру MLOps, яка була прийнята різними бізнесами в усій компанії, ми в Cepsa змогли пришвидшити завантаження проекту МЛ і покращити якість моделі МЛ, забезпечивши надійну та автоматизовану структуру, на якій наші команди з обробки даних можуть швидше впроваджувати інновації. .
Для отримання додаткової інформації про MLOps на SageMaker відвідайте Amazon SageMaker для MLOps і ознайомтеся з іншими випадками використання клієнтами в Блог машинного навчання AWS.
Про авторів
Гільєрмо Рібейро Хіменес є старшим спеціалістом із обробки даних у Cepsa зі ступенем доктора філософії. Ядерна фізика. Він має 6 років досвіду роботи з науковими проектами даних, переважно в телекомунікаційній та енергетичній індустрії. Наразі він очолює групи спеціалістів із обробки даних у відділі цифрової трансформації Cepsa, зосереджуючись на масштабуванні та продуктивності проектів машинного навчання.
Гільєрмо Менендес Корраль є архітектором рішень в AWS Energy and Utilities. Він має понад 15 років досвіду проектування та створення програмних програм, і зараз надає архітектурні рекомендації клієнтам AWS в енергетичній галузі, зосереджуючись на аналітиці та машинному навчанні.
- Coinsmart. Найкраща в Європі біржа біткойн та криптовалют.
- Платоблокчейн. Web3 Metaverse Intelligence. Розширені знання. БЕЗКОШТОВНИЙ ДОСТУП.
- CryptoHawk. Альткойн Радар. Безкоштовне випробування.
- Джерело: https://aws.amazon.com/blogs/machine-learning/how-cepsa-used-amazon-sagemaker-and-aws-step-functions-to-industrialize-their-ml-projects-and-operate- їх-моделі-в-масштабі/
- "
- 000
- 100
- 15 роки
- a
- здатність
- МЕНЮ
- доступ
- рахунки
- Achieve
- через
- Ad
- доданий
- Перевага
- проти
- алгоритм
- алгоритми
- ВСІ
- дозволяє
- вже
- Amazon
- серед
- аналітика
- аналізувати
- де-небудь
- API
- Інтерфейси
- застосування
- прикладної
- підхід
- схвалювати
- архітектурний
- архітектура
- навколо
- асоційований
- автоматизувати
- Автоматизований
- автоматичний
- автоматично
- автоматизація
- Автоматизація
- доступний
- AWS
- оскільки
- становлення
- перед тим
- буття
- нижче
- КРАЩЕ
- Блог
- будувати
- Створюємо
- Будує
- бізнес
- підприємства
- випадок
- випадків
- централізована
- певний
- виклик
- проблеми
- хімічний
- хмара
- код
- commit
- загальний
- компанія
- повний
- повністю
- комплекс
- компонент
- Компоненти
- обчислення
- концентрація
- З'єднуватися
- споживати
- споживач
- споживання
- Контейнер
- Контейнери
- витрати
- може
- обкладинка
- створювати
- створює
- створення
- В даний час
- виготовлений на замовлення
- клієнт
- Клієнти
- дані
- наука про дані
- вчений даних
- вирішене
- рішення
- Залежно
- залежить
- розгортання
- розгорнути
- розгортання
- розгортання
- призначений
- проектування
- докладно
- виявлено
- Виявлення
- Визначати
- розробників
- розвивається
- різний
- цифровий
- цифрове перетворення
- прямий
- обговорювати
- дракон
- кожен
- легко
- ефективність
- ефективний
- з'являються
- дозволяє
- Кінцева точка
- енергія
- двигун
- Інженери
- Навколишнє середовище
- обладнання
- оцінка
- Event
- еволюція
- точно
- приклад
- очікувати
- досвід
- експеримент
- дослідження
- облицювання
- ШВИДКО
- швидше
- особливість
- ознаками
- в кінці кінців
- Перший
- Гнучкість
- гнучкий
- Сфокусувати
- після
- Рамки
- від
- Повний
- Функції
- майбутнє
- Гейтс
- Загальне
- Git
- GitHub
- Глобальний
- мета
- обробляти
- має
- допомога
- допомагає
- дуже
- історичний
- тримає
- відбувся
- хостинг
- Як
- HTTPS
- Сотні
- зображень
- реалізація
- реалізовані
- удосконалювати
- поліпшення
- поліпшення
- В інших
- включати
- Augmenter
- незалежний
- самостійно
- промислові
- промисловість
- інформація
- повідомив
- Інфраструктура
- інновація
- вхід
- інтегрований
- інтерактивний
- введення
- ізоляція
- питання
- IT
- тримати
- зберігання
- ключ
- запуск
- провідний
- вивчення
- бібліотека
- ліній
- розташування
- шукати
- машина
- навчання за допомогою машини
- made
- підтримувати
- обслуговування
- зробити
- РОБОТИ
- управляти
- вдалося
- управління
- манера
- керівництво
- вручну
- засоби
- Метрика
- ML
- модель
- Моделі
- монітор
- моніторинг
- більше
- найбільш
- множинний
- потреби
- працювати
- операція
- оптимізація
- Опції
- порядок
- організація
- Інше
- власний
- Власники
- Проходження
- продуктивність
- виконанні
- фаза
- Фізика
- точок
- передбачати
- проблеми
- процес
- процеси
- виробник
- Production
- проект
- проектів
- за умови
- забезпечує
- забезпечення
- публікувати
- мета
- цілей
- штовхнув
- якість
- реального часу
- зменшити
- реєструвати
- зареєстрований
- надійний
- Сховище
- вимагається
- Вимога
- відповідь
- обов'язки
- REST
- в результаті
- результати
- прогін
- біг
- шкала
- Масштабування
- наука
- вчений
- Вчені
- безпечний
- Серія
- Без сервера
- обслуговування
- Послуги
- комплект
- Шанхай
- Поділитись
- короткий термін
- простий
- моделювання
- один
- ситуація
- SIX
- So
- рішення
- Рішення
- деякі
- що в сім'ї щось
- конкретний
- швидкість
- етапи
- standard
- почалася
- зберігання
- зберігати
- раціоналізувати
- Успішно
- система
- Мета
- команда
- команди
- Telco
- тест
- Тестування
- Команда
- Джерело
- отже
- ретельно
- поріг
- через
- час
- times
- до
- Простежуваність
- трек
- Відстеження
- Навчання
- Перетворення
- перетворень
- перехід
- при
- us
- використання
- зазвичай
- комунальні послуги
- значення
- версія
- добре визначений
- в той час як
- без
- Work
- Робочі процеси
- робочий
- світ
- лист
- рік
- років
- вихід