Прибуток:
- Здатність розпізнавати особливі проблеми машинного навчання, пов’язані з тріо код-дані-модель і пакетом, і представляти модель онлайн або пакетно відповідно до потреб бізнесу.
- Можливість реалізації шаблонів поступового розгортання та розгортання відкату (тінь, канарка, A/B, відкат) і додавання перевіреного плану відкоту до кожного розгортання
- Можливість відстежувати зв’язок дані-код-метрика моделі, запущеної у виробництво, за допомогою CI/CD з контрольованим пороговим значенням оцінки та реєстру моделей
Змусити модель досягти 95% точності в ноутбуку – це лише половина справи. Інша половина (часто складна частина) полягає в тому, щоб забезпечити реальним користувачам цю модель надійним, масштабованим і придатним для обслуговування способом. MLOps (Machine Learning Operations: дисципліна введення, експлуатації та підтримки моделей ML у виробництві) поєднує в собі методи розробки програмного забезпечення DevOps з унікальними викликами ML. У цьому розділі ми розповідаємо про етапи переміщення моделі до виробництва та про те, як штучний інтелект допомагає в цьому процесі.
Чому ML відрізняється від звичайного програмного забезпечення?
У звичайному програмному забезпеченні поведінка знаходиться в коді; Якщо код не змінюється, поведінка не змінюється. У ML поведінка залежить від коду, даних і моделі. Ці три виміри створюють додаткові виклики MLOps:
- Дрейф даних: дані у виробництві з часом віддаляються від даних у навчанні; модель застаріває.
- Вам потрібно версії трьох речей: коду, даних і моделі — усіх трьох.
- Тихий збій: модель може вийти з ладу без збою, без помилок, просто виробляючи неправильні прогнози. Для виявлення цього потрібен моніторинг.
Тому існує велика різниця між «робочою моделлю» і «готовою до виробництва моделлю».
Упаковка та презентація моделі
Першим кроком у введенні моделі у виробництво є її упаковка: файл моделі, необхідні бібліотеки, код попередньої обробки та інформація про версію разом у відтворюване ціле. Контейнерізація (наприклад, Docker: розміщення програми в ізольованій коробці з усіма її залежностями) є стандартною тут; Це усуває проблему «це працювало на моїй машині».
Дві основні схеми подачі моделі:
- Онлайн/реальний час (онлайн): модель стоїть за API, повертаючи миттєвий прогноз для кожного вхідного запиту. Низька затримка є критичною.
- Пакетно: модель періодично обробляє великі набори даних (наприклад, генерує бали для всіх клієнтів вночі). Затримка не має значення, важлива ефективність.
Який із них правильний, залежить від бізнес-потреб: миттєва онлайн-рекомендація, щомісячна оцінка ризику в групі.
Порада: "У реальному часі" є платною, а не за умовчанням. Пакет набагато дешевше і простіше, якщо результат буде використаний протягом годин. Вам дійсно потрібна миттєва відповідь? Спитайте це спочатку.
Стратегії безпечного розподілу
Відкривати нову модель безпосередньо для всього трафіку ризиковано; Якщо це неправильно, це стосується всіх. Безпечні моделі розподілу:
- Тіньове розгортання: нова модель отримує робочий трафік, але його прогнози не відображаються користувачеві, а лише реєструються. Її порівнюють зі старою моделлю, щоб перевірити, чи безпечна вона в реальних даних.
- Розгортання Canary: нова модель спочатку розгортається для невеликого відсотка трафіку (наприклад, 5%); Якщо проблем немає, її поступово збільшують.
- A/B тестування: дві моделі паралельно представлені реальному користувачеві та порівнюються бізнес-метрики (конверсія, кліки).
- Відкат: можливість швидкого повернення до старої версії, якщо нова модель виявиться поганою. Кожне розгортання має мати план відкату.
Застереження: розгортання без плану відкоту не є завершеним. Можливість повернутися до старої версії за лічені хвилини захищає користувача, якщо нова модель поводиться несподівано під час виробництва. Перевірте це перед розгортанням.
Слабкий підхід / Сильний підхід
Слабкий: «Модель була хороша під час тестування, ми вийшли в ефір, ми відкрили її для всіх».
Гючлю: «Ми контейнеризували модель, позначили її як версію. Спочатку ми запустили її в тіньовому режимі з робочим трафіком протягом 3 днів, порівнюючи прогнози зі старою моделлю — відхилення було прийнятним. Потім ми відкрили її з 5% canary, відстежували показники пропускної здатності та затримку. Коли проблем не виникло, ми поступово збільшили її до 100%. Попередньо ми перевірили команду відкоту».
Відмінність: сильний підхід поступовий, розмірений і оборотний. Ризик обмежений на кожному кроці.
CI/CD та автоматизація
CI/CD (безперервна інтеграція/безперервне розгортання: конвеєр автоматичного тестування та випуску змін коду) у ML охоплює не лише код, але й дані та кроки моделі. Хороший конвеєр ML CI/CD: запускає тести, коли код змінюється, виконує перевірку даних, перенавчає модель (за потреби), перевіряє порогові значення оцінки та просуває розгортання, лише якщо порогові значення зберігаються. Принцип «навчання відбувається автоматично, розгортання здійснюється на основі порогових значень» запобігає тихому витоку поганої моделі у виробництво.
AI дуже корисний під час налаштування цих конвеєрів: написання чернеток файлу конфігурації (YAML), тестів, сценаріїв розгортання. Але ви визначаєте пороги розподілу (незалежно від того, яка метрика перевищує опубліковане значення) і політику відкату; це рішення щодо бізнес-ризику.
Інфраструктура відтворюваності
Щоб відтворити поведінку моделі у виробництві, реєстр моделей: запис, який зберігає, яка модель була навчена з якими даними та кодом, а також які показники вона отримала. Для кожної робочої моделі слід відстежувати наступне: версія навчальних даних, версія коду (git-комміт), гіперпараметри, бали оцінювання та дата розгортання. Коли виникає проблема, ви повинні бути в змозі відповісти на запитання "яка модель створила цей прогноз, з якими даними?" протягом хвилин. Ми поглибимо це в розділі 11.
три міні-чохла
Випадок 1. Проблема виникла через тіньовий розподіл. Рекомендаційна модель перевершила стару під час тестування. Виявилося, що його запуск із робочим трафіком у тіньовому режимі дає дуже погані рекомендації для певного сегмента користувачів (нових користувачів) — тестові дані були недостатньо репрезентативними для цього сегмента. Модель було виправлено без жодного показу користувачеві. Якби його було відкрито безпосередньо, нова робота користувача була б порушена.
Випадок 2 - Безповоротний розподіл. Команда запровадила нову модель ціноутворення для всього трафіку без планів відкату. Модель неочікувано дуже дешево оцінила деякі продукти. Повернення до старої версії зайняло години, оскільки процес не був готовий. Була серйозна втрата доходу. Пізніше до кожного розгортання було додано обов’язкове тестування відкату.
Випадок 3 – Тихий дрейф даних. Шаблон шахрайства з’являвся місяцями без будь-яких помилок. Але тактика шахраїв змінилася (дрейф даних), і відкликання моделі мовчки впало. Ніхто не помітив, тому що моніторингу не було. Після створення панелі моніторингу розподілу прогнозу дрейф став помітним на ранній стадії. Ми розглянемо моніторинг у блоці 8.
Шаблони, які можна копіювати
Напишіть проект плану розгортання цієї моделі. Модель: [що вона робить], використання: [онлайн чи пакетне?] Має включати: 1) Упаковка (контейнер, версії) 2) Стратегія поступового розгортання (shadow/canary/A-B) і чому 3) Метрики для відстеження (бізнес + технічні + затримка) 4) План відкату та як тестувати 5) Порогові значення розгортання (який показник має перевищувати яке значення)
Перевірте цей конвеєр ML CI/CD: 1) Чи виконується перевірка даних? 2) Чи може розгортання продовжитися без утримання порогового значення оцінки (чи не повинно бути)? 3) Чи відбувається відкат автоматично? 4) Чи відстежуються дані+код+метрики в реєстрі моделі?Конфігурація Pline: [config]
Допоможіть мені вирішити, яка онлайн-презентація чи пакетна презентація підходить для цієї моделі. Як довго використовуватиметься результат: [миттєво / хвилина / година / день] Очікуваний обсяг запиту: [кількість] Чи існує обмеження затримки: [мс] Який із них ви б порекомендували з точки зору вартості та складності та чому?
Напишіть процедуру відкоту для цієї моделі.- Який показник/порогове значення викликає низьку продуктивність?- Які кроки відкоту?- Скільки часу має тривати відкат (цільове значення)?- Як перевірити цю процедуру перед виробництвом?
Таблиця шаблонів презентації
критерій
Онлайн (реальний час)
партія
затримка
Критичний (мс)
незначний
Використання
Потрібна миттєва відповідь
Періодична оцінка
Вартість
висока
низький
складність
висока
низький
приклад
Жива рекомендація, афера
Місячна оцінка ризику
Поширені помилки
- Розповсюджувати без плану вилучення. Неправильна модель вражає всього користувача.
- Відкриття безпосередньо до 100% трафіку. Обмежте ризик за допомогою розподілу в шаховому порядку.
- Не встановлення моніторингу. Модель видає помилки тихо, без помилок.
- Резервна презентація в реальному часі. Хоча пакетування достатньо, вартість і складність зростають.
- Немає зв’язку версій моделі-даних-коду. Ви не можете відтворити проблему.
- Автоматичний випуск без порогу розповсюдження. Погана модель мовчки підкрадається.
Підсумовуючи
Переміщення моделі у виробництво є іншим і часто складнішим інженерним завданням, ніж її навчання. ML вимагає додаткової дисципліни, оскільки воно залежить від тріо код-дані-модель: упаковка та версії, схема доставки (онлайн/пакет), яка відповідає потребам бізнесу, поступове та оборотне розгортання, CI/CD із контрольованим порогом і реєстрація моделі. Штучний інтелект є потужним помічником у створенні коду та конфігурації цієї інфраструктури; але пороги розповсюдження, політика повернення та рішення щодо ризиків залишаються за вами. Розповсюдження без плану відкату не є повним.
Аплікаційне завдання
Контейнеруйте (Docker) модель і позначте її версією. Вирішіть, чи будете ви пропонувати онлайн чи пакетно на основі потреб вашого бізнесу, і напишіть своє обґрунтування. Задокументуйте план поетапного розгортання (тіньовий або канарковий) і перевірену процедуру відкату. Переконайтеся, що записали версію даних, фіксацію коду та бали оцінки в реєстрі моделі.
контрольний список
- [ ] Модель упакована та має версії (контейнер + етикетка).
- [ ] Модель презентації (онлайн/пакет) було обрано відповідно до потреб бізнесу.
- [ ] Реалізовано стратегію поетапного розгортання (тінь/канарка).
- [ ] Процедура відкату написана та протестована.
- [ ] CI/CD не прискорює розгортання до досягнення порогового значення оцінки.
- [ ] Реєстр моделі містить посилання дані+код+метрика.