Як Yara використовує функції MLOps Amazon SageMaker для оптимізації енергоспоживання на своїх аміачних заводах

Yara є провідною світовою компанією з живлення рослин і постачальником екологічних і сільськогосподарських рішень. Амбіції Yara зосереджені на вирощуванні харчового майбутнього з позитивним впливом на природу, яке створює цінність для клієнтів, акціонерів і суспільства в цілому, а також забезпечує більш стійкий ланцюжок створення вартості продуктів харчування. Підтримуючи наше бачення світу без голоду та шанобливої ​​планети, Yara дотримується стратегії сталого зростання вартості, сприяючи екологічно безпечному живленню рослин і енергетичним рішенням з нульовим викидом. Yara також є найбільшим у світі виробником аміаку, нітратів та НПК добрива. Таким чином, їх виробничий сегмент є невід’ємним будівельним блоком для виконання їхньої місії — з чітко сформульованим прагненням стати світовим лідером за такими показниками, як безпека, вплив на навколишнє середовище, якість і витрати на виробництво. Довгостроковою метою Yara є «Завод майбутнього» з нульовими викидами та низькими витратами.

Спираючись на економічну трансформацію, Yara посилює свою увагу до цифрових рішень, щоб допомогти їм досягти своїх амбіцій. Щоб керувати цими зусиллями, Yara створила глобальний підрозділ під назвою Digital Production. Успіх цифрового виробництва та його рішень є ключовим пріоритетом для Yara, і Yara значно збільшила свої зусилля в цій галузі. Найважливішою сферою уваги є використання переваг величезної кількості даних, створених у рамках їх операцій. Тому Yara створює продукти на основі даних, які допомагають оптимізувати виробництво, підвищити якість продукції, підвищити надійність виробничих ділянок, зменшити викиди, підвищити безпеку та продуктивність працівників, автоматизувати ручні процеси тощо.

Енергія є основною складовою витрат для багатьох виробничих підприємств; отже, енергоефективність має істотний вплив на прибутковість. Однак часто не вистачає надійних довідок про те, як виглядає хороша продуктивність і як її досягти. Крива енергетичного навантаження Yara (ELC) — це рішення, яке використовує найкращі історичні показники споживання енергії в порівнянні з поточними показниками. Якщо поточне споживання занадто сильно відхиляється від історичного найкращого, інструмент дає рекомендації операторам, щоб керувати споживанням енергії.

Щоб розгорнути ELC на виробничих підприємствах і масштабувати його на кількох майданчиках по всьому світу, Yara потрібно було створити платформу MLOps. Це забезпечило б Yara надійне та ефективне навчання, розгортання та підтримку моделей. Крім того, щоб масштабувати це на кількох сайтах, Yara потрібно було автоматизувати процеси розгортання та обслуговування. У цій публікації ми обговорюємо, як Yara використовує Amazon SageMaker функції, включаючи реєстр моделі, Монітор моделі Amazon SageMaker та Трубопроводи Amazon SageMaker оптимізувати життєвий цикл машинного навчання (ML) шляхом автоматизації та стандартизації практик MLOps. Ми надаємо огляд налаштування, демонструючи процес створення, навчання, розгортання та моніторингу моделей ML для заводів у всьому світі.

Огляд рішення

ELC використовує дані датчиків Інтернету речей (IoT) із заводу. Ці датчики вимірюють такі показники, як продуктивність виробництва, умови навколишнього середовища, стан сировини тощо. Ці дані використовуються для навчання моделі прогнозування енергії, яка потім використовується для створення погодинних прогнозів. Оператори установки відстежують фактичне споживання енергії та порівнюють його з оптимальним споживанням, передбаченим ELC. Якщо поточне енергоспоживання занадто сильно відхиляється від оптимальної точки, ELC забезпечує дію для коригування внутрішніх змінних процесу для оптимізації енергоефективності на основі аналітичних моделей.

ELC розміщено в хмарі. Щоб передавати дані датчиків із заводу в реальному часі, Yara використовує AWS IoT Greengrass для безпечного спілкування Ядро AWS IoT і експортувати дані IoT у хмару AWS. AWS IoT SiteWise це керована служба, яка може збирати, організовувати, шукати та споживати дані про обладнання з промислового обладнання в масштабі. Yara створила API за допомогою API -шлюз Amazon щоб надати дані датчика таким програмам, як ELC.

Сервер програми ELC розгортається через Amazon ECS і підтримує інформаційні панелі ELC на передній частині, якими користуються оператори заводу. Додаток ELC відповідає за надання погодинних прогнозованих показників енергоспоживання операторам станцій. На кожну установку встановлюється своя модель, тому що характеристики енергоспоживання відрізняються. Крім того, заводи групуються в різні регіони AWS на основі їх розташування.

Наступна схема ілюструє цю архітектуру.

Для створення ELC і масштабування для кількох заводів нам знадобилося рішення MLOps, яке підтримує наступне:

• масштабованість – Він може масштабуватися відповідно до обсягів даних. Деякі рослини виробляють більше даних, ніж інші; кожен завод може виробляти кілька гігабайт даних на день.
• Розширюваність – Його можна розгортати в нових регіонах і облікових записах.
• Повторюваність – У ньому є загальні шаблони, які ми можемо використовувати для створення нового заводу.
• Гнучкість – Він може змінювати конфігурацію розгортання на основі потреб кожного підприємства.
• Надійність і моніторинг – Він може запускати тести та мати чітке бачення стану всіх активних установок. У разі збою він може повернутися до попереднього стабільного стану.
• технічне обслуговування – Рішення має мати низькі витрати на обслуговування. Він повинен використовувати безсерверні служби, де це можливо, щоб зменшити інфраструктурний слід.

Для ML Yara вирішила використати SageMaker. SageMaker — це повністю керована служба, яка охоплює весь робочий процес машинного навчання. При виборі SageMaker вирішальними були такі характеристики:

• Контейнери каркаса SageMaker – Yara навчила прогностичні моделі ELC на TensorFlow, і за допомогою контейнерів фреймворку SageMaker Yara змогла підняти та перемістити ці моделі з мінімальними змінами коду в SageMaker.
• Трубопроводи SageMaker – SageMaker Pipelines пропонує інтерфейс Python для науковців з обробки даних для написання конвеєрів ML. Значна частина коду ELC складається з конвеєра навчання та виведення, які визначені в Python.
• Реєстр моделі SageMaker – Реєстр моделей SageMaker дає змогу каталогізувати та керувати моделями. Крім того, це полегшує керування метаданими моделі, такими як показники навчання.
• Монітор моделі SageMaker – Yara хотіла контролювати якість і розподіл вхідних даних, а також продуктивність моделі ELC. API монітора моделі SageMaker пропонують моніторинг якості даних і моделі.

Для керування безперервною інтеграцією та безперервною доставкою (CI/CD) для конвеєрів ML Yara використовує Платформа розгортання Amazon (АПД). ADF — це платформа з відкритим вихідним кодом, розроблена AWS для керування та розгортання ресурсів у кількох облікових записах і регіонах AWS в організації AWS. ADF дозволяє поетапне, паралельне, кілька облікових записів і міжрегіональне розгортання програм або ресурсів за допомогою структури, визначеної в Організації AWS, використовуючи такі послуги, як AWS CodePipeline, AWS CodeBuild, Комісія AWS та AWS CloudFormation щоб полегшити підйом важких речей і керування ними порівняно з традиційною конфігурацією CI/CD.

Огляд рішення

Все рішення для платформи MLOps було створено протягом двох місяців у спільній роботі з Професійні послуги AWS. Команда, яка працювала над проектом, складалася з науковців з даних, інженерів із обробки даних та спеціалістів DevOps. Щоб сприяти швидшому розвитку в середовищі кількох команд, Yara вирішила використовувати AWS Landing Zone і організації для централізованого створення, керування та керування різними обліковими записами AWS. Наприклад, Yara має обліковий запис центрального розгортання та використовує облікові записи робочого навантаження для розміщення бізнес-додатків. ELC – це варіант використання оптимізації процесів, який розгортається для оптимізації робочого навантаження облікових записів. Команда Yara Digital Production також працює над сценаріями використання машинного навчання в інших сферах, окрім оптимізації. Платформа MLOps підтримує розгортання в облікових записах будь-якого робочого навантаження, якщо облікові записи створено через організації.

Наступна схема ілюструє цю архітектуру.

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

Що стосується стратегії облікового запису, у Yara є налаштування пісочниці, DEV, TEST і PROD. Обліковий запис пісочниці використовується для експериментів і випробування нових ідей. Обліковий запис DEV є відправною точкою конвеєрів CI/CD, і всі розробки починаються з нього. Обліковий запис розгортання містить визначення конвеєра CI/CD і може розгортатися в облікових записах DEV, TEST і PROD. Це налаштування облікового запису зображено на малюнку нижче.

Розробка нового сценарію використання

Для цієї публікації ми припускаємо, що у нас є робочий прототип варіанту використання, і тепер ми хочемо його ввести в дію. Якщо цей варіант використання належить до нової області продукту, нам спочатку потрібно надати облікові записи за допомогою організацій, що автоматично запускає ADF для завантаження цих облікових записів для розгортання. Yara дотримується стратегії облікового запису DEV>TEST>PROD; однак ця конфігурація не є обов’язковою. Облікові записи даних надають API для доступу до даних, і для нового випадку використання потрібно надати необхідні ролі Управління ідентифікацією та доступом AWS (IAM), щоб вони могли отримати доступ до API даних.

Далі нам потрібно визначити, для яких облікових записів буде розгорнуто цей варіант використання. Це робиться за допомогою карти розгортання в ADF. Карта розгортання — це файл конфігурації, який містить відображення етапів і цілей для конвеєра. Щоб запустити карту розгортання, ADF використовує CodePipeline. ADF забезпечує гнучкість керування параметрами для кожного цільового середовища, у якому розгорнуто стек. Це полегшує керування розгортаннями та тестування з меншими екземплярами.

Для шифрування всіх артефактів, таких як код, дані та файли моделі, ми створюємо Служба управління ключами AWS (AWS KMS). Ви також можете використовувати шифрування на стороні сервера. Однак, оскільки доступ до деяких згенерованих артефактів доступний з різних облікових записів, нам потрібно створити власний ключ і керувати його політикою дозволів, щоб надати доступ між обліковими записами.

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

Модель навчального конвеєра

Для кожного нового заводу, підключеного до ELC, ми створюємо новий навчальний конвеєр SageMaker. Цей конвеєр складається з етапів попередньої обробки даних і навчання моделі. Конвеєри SageMaker добре підходять для Yara, оскільки вони пропонують інтерфейс Python для визначення робочого процесу ML. Крім того, різні кроки робочого процесу можна налаштувати для різного масштабування. Наприклад, ви можете визначити набагато більший екземпляр для навчання, ніж для етапу оцінки моделі. Вхідні та вихідні параметри для кожного кроку конвеєра зберігаються, що полегшує відстеження кожного запуску та його виходів. Загальна схема навчального процесу така.

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

Моделі контролюються версіями за допомогою реєстру моделей, при цьому кожна установка має власну групу пакетів моделей. Крім того, ви можете використовувати реєстр моделей, щоб відстежувати, які версії моделі розгортаються в яких середовищах. Модель може бути в Відхилений, Очікує на затвердження вручнуабо Затверджений стані, і тільки моделі, які знаходяться в Затверджений стан може бути розгорнуто. Це також забезпечує захист від випадкового розгортання несхваленої версії моделі.

Виведення моделі та конвеєр моніторингу

Щоб розгорнути модель і налаштувати моніторинг моделі, ми налаштували другий конвеєр SageMaker. Програма ELC надає прогнози операторів заводу на вимогу, тому доступ до моделей здійснюється через виклики API, зроблені з серверної частини ELC. Кінцеві точки висновку SageMaker забезпечують повністю кероване рішення для розміщення моделі з рівнем API; кінцеві точки приймають вхідні дані моделі як корисне навантаження та повертають прогнози. Оскільки затримка також є вирішальним фактором для кінцевих користувачів, які не хочуть довго чекати, перш ніж отримати оновлені прогнози, Yara вибрала кінцеві точки висновку в реальному часі SageMaker, які особливо підходять для робочих навантажень із дуже низькими вимогами до затримки. Нарешті, оскільки програма ELC не може перебувати в простої під час розгортання оновлених моделей, вона покладається на синьо-зелену здатність розгортання кінцевих точок реального часу SageMaker, щоб гарантувати, що стара версія моделі продовжує обслуговувати прогнози, доки не буде розгорнуто нову версію. .

На наступній діаграмі показано налаштування розгортання та моніторингу.

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

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

Потік CI/CD

Потік CI/CD для конвеєрів навчання починається в обліковому записі DEV. Yara дотримується моделі розробки, заснованої на функціях, і коли розробляється нова функція, гілка функції об’єднується в стовбур, який починає розгортання. Моделі ELC навчаються в обліковому записі DEV, і після того, як модель навчена та оцінена, вона реєструється в реєстрі моделей. Схвалювач моделі виконує перевірку правильності перед оновленням статусу моделі Затверджений. Ця дія генерує подію, яка запускає розгортання конвеєра виведення моделі. Конвеєр виведення моделі розгортає нову версію моделі на кінцевій точці SageMaker у DEV.

Після розгортання кінцевої точки запускаються тести для перевірки поведінки налаштування. Для тестування Yara використовує Звіти про тестування CodeBuild. Ця функція дозволяє розробникам запускати модульні тести, тести конфігурації та функціональні тести до та після розгортання. У цьому випадку Yara запускає функціональні тести, передаючи тестове навантаження кінцевим точкам SageMaker і оцінюючи відповідь. Після проходження цих тестів конвеєр переходить до розгортання кінцевих точок SageMaker для TEST. Сервер ELC також розгорнуто для TEST, що робить можливим наскрізне тестування програми в цьому середовищі. Крім того, Yara запускає тестування прийнятності для користувачів у TEST. Тригером від TEST до розгортання PROD є дія затвердження вручну. Після того, як нова версія моделі пройшла як функціональне тестування, так і тестування на прийнятність користувачами в TEST, команда інженерів схвалює розгортання моделі в PROD.

Наступний малюнок ілюструє цей робочий процес.

Загальні компоненти

Для ELC ми використовуємо кілька компонентів, які є загальними для всіх етапів розгортання (DEV, TEST, PROD) і моделей. Ці компоненти знаходяться в нашому обліковому записі розгортання та включають керування версіями моделі, сховище зображень контейнера, ключ шифрування та відро для зберігання типових артефактів.

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

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

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

Висновок

У цій публікації ми продемонстрували, як Yara використовувала SageMaker і ADF для створення високомасштабованої платформи MLOps. ML — це багатофункціональна можливість, і команди розгортають моделі в облікових записах різних бізнес-підрозділів. Тому ADF, який пропонує вбудовану інтеграцію з організаціями, робить його ідеальним кандидатом для завантаження облікових записів для налаштування конвеєрів CI/CD. Оперативно конвеєри ADF працюють у центральному обліковому записі розгортання, що дозволяє легко отримати загальний огляд справності розгортань. Нарешті, ADF використовує керовані служби AWS, такі як CodeBuild, CodeDeploy, CodePipeline і CloudFormation, що полегшує налаштування та обслуговування.

SageMaker надає широкий спектр можливостей ML, що дозволяє командам більше зосереджуватися на вирішенні бізнес-проблем, а не на розбудові та підтримці інфраструктури. Крім того, SageMaker Pipelines надає багатий набір API для створення, оновлення та розгортання робочих процесів машинного навчання, що робить його чудовим пристосуванням для MLO.

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

Щоб отримати додаткові відомості про те, як розгортати програми за допомогою ADF, див Приклади.

---

Про авторів

Шахір Мансур є спеціалістом з обробки даних в AWS. Його увага зосереджена на створенні платформ машинного навчання, які можуть розміщувати рішення штучного інтелекту в масштабі. Сфери його інтересів — MLO, магазини функцій, хостинг моделей і моніторинг моделей.

Тім Беккер є старшим спеціалістом із обробки даних у Yara International. У Digital Production він зосереджується на оптимізації процесу виробництва аміаку та азотної кислоти. Він має ступінь доктора філософії з термодинаміки та захоплений поєднанням інженерних процесів і машинного навчання.

Йонгьос Кевпітаккун є старшим спеціалістом із обробки даних у групі цифрового виробництва Yara International. Він має ступінь доктора філософії зі штучного інтелекту/машинного навчання та багаторічний практичний досвід використання машинного навчання, комп’ютерного зору та моделей обробки природної мови для вирішення складних бізнес-завдань.