Підходи до тестування моделей Amazon SageMaker ML

Цю публікацію було написано спільно з Тобіасом Венцелем, менеджером з розробки програмного забезпечення для платформи машинного навчання Intuit.

Ми всі цінуємо важливість високоякісної та надійної моделі машинного навчання (ML), наприклад, коли використовуємо автономне водіння або взаємодіємо з Alexa. Моделі ML також відіграють важливу роль у менш очевидних аспектах — їх використовують бізнес-додатки, охорона здоров’я, фінансові установи, amazon.com, TurboTax тощо.

Оскільки додатки з підтримкою ML стають основними для багатьох компаній, моделі повинні дотримуватися такої ж енергійності та дисципліни, як і програмні додатки. Важливим аспектом MLOps є надання нової версії попередньо розробленої моделі ML у виробництві за допомогою усталених практик DevOps, таких як тестування, керування версіями, безперервна доставка та моніторинг.

Є кілька наказовий вказівки щодо MLOps, і ця публікація містить огляд процесу, який ви можете дотримуватися, і які інструменти використовувати для тестування. Це засновано на співпраці між Осягати інтуїтивно і AWS. Ми разом працювали над впровадженням рекомендацій, викладених у цій публікації, на практиці та в масштабах. Мета Intuit — стати Експертна платформа на основі ШІ значною мірою залежить від стратегії збільшення швидкості початкової розробки моделі, а також тестування нових версій.

Вимога

Нижче наведено основні напрямки розгляду під час розгортання нових версій моделі:

1. Показники точності моделі – Це важливо відслідковувати метрик оцінки моделі, таких як точність, точність і запам’ятовування, і гарантувати, що об’єктивні метрики залишаються відносно незмінними або покращуються з новою версією моделі. У більшості випадків розгортання нової версії моделі не має сенсу, якщо досвід кінцевих користувачів не покращиться.
2. Перевірте якість даних – Дані в невиробничих середовищах, будь то змодельовані чи копії на певний момент часу, мають бути репрезентативними для даних, які модель отримає після повного розгортання, з точки зору обсягу чи розподілу. Якщо ні, ваші процеси тестування не будуть репрезентативними, і ваша модель може по-іншому поводитися у виробництві.
3. Важливість і парність ознаки – Важливість функцій у новій версії моделі має бути порівняно зі старішою моделлю, хоча можуть бути представлені нові функції. Це робиться для того, щоб модель не стала упередженою.
4. Тестування бізнес-процесів – Важливо, щоб нова версія моделі могла відповідати вашим бізнес-цілям у прийнятних параметрах. Наприклад, одним із бізнес-показників може бути те, що наскрізна затримка для будь-якої служби не повинна перевищувати 100 мілісекунд, або вартість розміщення та перенавчання певної моделі не може перевищувати 10,000 XNUMX доларів США на рік.
5. Коштувати – Простий підхід до тестування полягає в тому, щоб відтворити все виробниче середовище як тестове середовище. Це звичайна практика в розробці програмного забезпечення. Однак такий підхід у випадку моделей ML може не дати належної рентабельності інвестицій залежно від розміру даних і може вплинути на модель з точки зору бізнес-проблеми, яку вона вирішує.
6. Безпека – Часто очікується, що тестові середовища матимуть вибіркові дані замість реальних даних клієнтів, і, як наслідок, обробка даних і правила відповідності можуть бути менш суворими. Однак, як і вартість, якщо ви просто дублюєте виробниче середовище в тестове середовище, ви можете створити ризики безпеки та відповідності.
7. Масштабованість магазину функцій – Якщо організація вирішує не створювати окреме сховище тестових функцій через вартість або міркування безпеки, тоді тестування моделі має відбуватися у сховищі виробничих функцій, що може спричинити проблеми з масштабованістю, оскільки трафік подвоюється протягом періоду тестування.
8. Виконання моделі онлайн – Онлайн-оцінки відрізняються від офлайн-оцінок і можуть бути важливими в деяких випадках, як моделі рекомендацій, оскільки вони вимірюють задоволеність користувачів у реальному часі, а не сприйняту задоволеність. Важко змоделювати реальні моделі трафіку в невиробничому режимі через сезонність чи іншу поведінку користувачів, тому ефективність онлайн-моделі можна виконувати лише в робочому режимі.
9. Оперативна продуктивність – Оскільки моделі стають більшими та дедалі частіше розгортаються децентралізованим способом на різному обладнанні, важливо перевірити модель на бажану робочу продуктивність, як-от затримку, частоту помилок тощо.

Більшість команд ML мають багатосторонній підхід до тестування моделі. У наступних розділах ми пропонуємо способи вирішення цих проблем на різних етапах тестування.

Офлайн тестування моделі

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

Цей етап виконується в середовищі постановки.

Вам слід зафіксувати робочий трафік, який можна використовувати для повторного відтворення під час офлайн-тестування. Бажано використовувати попередній робочий трафік замість синтетичних даних. The Монітор моделі Amazon SageMaker функція захоплення даних дозволяє фіксувати робочий трафік для моделей, розміщених на Amazon SageMaker. Це дозволяє розробникам моделей тестувати свої моделі з даними з пікових робочих днів або інших важливих подій. Потім отримані дані відтворюються з новою версією моделі в пакетному режимі Пакетне перетворення Sagemaker. Це означає, що запуск пакетного перетворення може тестувати дані, які збиралися тижнями або місяцями, лише за кілька годин. Це може значно пришвидшити процес оцінки моделі порівняно із запуском двох або більше версій моделі в реальному часі поруч і надсиланням повторюваних запитів на прогноз до кожної кінцевої точки. Крім того, що цей підхід швидше знаходить ефективнішу версію, він також використовує обчислювальні ресурси протягом коротшого періоду часу, зменшуючи загальну вартість.

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

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

Інтеграція та тестування продуктивності

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

Це тестування має проводитися в проміжному середовищі.

Як інтеграційне тестування, так і тестування продуктивності мають бути реалізовані окремими командами за допомогою їх конвеєра MLOps. Для тестування інтеграції ми рекомендуємо випробуваний метод підтримки функціонально еквівалентного попереднього середовища та тестування з кількома різними корисними навантаженнями. Робочий процес тестування можна автоматизувати, як показано в цей семінар. Для тестування продуктивності ви можете використовувати Amazon SageMaker Inference Recommender, який пропонує чудову відправну точку для визначення типу екземпляра та кількості цих екземплярів для використання. Для цього вам знадобиться використовувати інструмент генератора навантаження, наприклад проекти з відкритим кодом perfsizesagemaker та perfsize який розробив Intuit. Perfsizesagemaker дозволяє автоматично тестувати конфігурації кінцевих точок моделі з різноманітними вимогами до корисного навантаження, часу відгуку та максимальної кількості транзакцій за секунду. Він генерує докладні результати тестування, які порівнюють різні версії моделей. Perfsize — це допоміжний інструмент, який пробує різні конфігурації, враховуючи лише максимальну кількість транзакцій за секунду та очікуваний час відповіді.

A / B тестування

У багатьох випадках, коли необхідна реакція користувача на негайний вихід моделі, наприклад, у програмах електронної комерції, функціональної оцінки офлайн-моделі недостатньо. У цих сценаріях вам потрібно тестувати A/B моделі у виробництві, перш ніж приймати рішення про оновлення моделей. Тестування A/B також має свої ризики, оскільки це може мати реальний вплив на клієнтів. Цей метод тестування служить остаточною перевіркою продуктивності машинного навчання, легкою інженерною перевіркою розумності. Цей метод також стосується завдань 8 і 9 (продуктивність онлайн-моделі та операційна досконалість).

A/B-тестування слід проводити у робочому середовищі.

За допомогою SageMaker ви можете легко виконувати A/B-тестування моделей ML шляхом запуску кілька варіантів виробництва на кінцевій точці. Трафік можна поступово скеровувати до нової версії, щоб зменшити ризик, який може мати погана модель у виробництві. Якщо результати тесту A/B виглядають добре, трафік спрямовується до нової версії, зрештою охоплюючи 100% трафіку. Ми рекомендуємо використовувати огорожі розгортання для переходу від моделі A до B. Для більш повного обговорення тестування A/B використовуйте Амазонка персоналізувати моделі як приклад див Використання A/B-тестування для вимірювання ефективності рекомендацій, створених Amazon Personalize.

Онлайн тестування моделі

У цьому сценарії нова версія моделі суттєво відрізняється від тієї, яка вже обслуговує живий трафік у виробництві, тому підхід до автономного тестування більше не підходить для визначення ефективності нової версії моделі. Найпомітнішою причиною цього є зміна функцій, необхідних для створення прогнозу, тому раніше записані транзакції не можна використовувати для перевірки моделі. У цьому випадку ми рекомендуємо використовувати тіньове розгортання. Тіньове розгортання пропонує можливість розгортати тінь (або претендент) модель поряд із виробництвом (або чемпіон) модель, яка зараз обслуговує прогнози. Це дає змогу оцінити ефективність тіньової моделі в робочому трафіку. Прогнози тіньової моделі не надаються програмі, яка запитує; вони зареєстровані для офлайн-оцінки. За допомогою тіньового підходу до тестування ми вирішуємо завдання 4, 5, 6 і 7 (тестування бізнес-процесів, вартість, безпека та масштабованість магазину функцій).

Тестування онлайн-моделі слід проводити в постановочному або робочому середовищі.

Цей метод тестування нових версій моделі слід використовувати в крайньому випадку, якщо всі інші методи не можуть бути використані. Ми рекомендуємо це як крайній засіб, оскільки дуплексні виклики до кількох моделей створюють додаткове навантаження на всі вихідні служби у виробництві, що може призвести до вузьких місць у продуктивності, а також до збільшення витрат у виробництві. Найбільш очевидний вплив це має на рівень надання функцій. Для варіантів використання, які мають спільні функції із загального пулу фізичних даних, ми повинні мати можливість імітувати кілька варіантів використання, які одночасно отримують доступ до однієї таблиці даних, щоб переконатися, що не існує конфлікту ресурсів перед переходом до робочого режиму. Усюди, де це можливо, слід уникати повторних запитів до сховища функцій, а функції, необхідні для обох версій моделі, слід повторно використовувати для другого висновку. Магазини функцій на основі Amazon DynamoDB, як створений Intuit, можна реалізувати Прискорювач Amazon DynamoDB(DAX), щоб кешувати та уникати подвоєння вводу-виводу до бази даних. Ці та інші параметри кешування можуть пом’якшити проблему 7 (масштабованість сховища функцій).

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

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

Висновок

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

---

Про авторів

Тобіас Венцель є менеджером з розробки програмного забезпечення для платформи машинного навчання Intuit у Маунтін-В’ю, Каліфорнія. Він працював над платформою з моменту її створення в 2016 році та допомагав розробляти та створювати її з нуля. У своїй роботі він зосереджувався на операційній досконалості платформи та її успішному застосуванні через сезонний бізнес Intuit. Крім того, він захоплений безперервним розширенням платформи за допомогою новітніх технологій.

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

Алан Тан є старшим менеджером із продуктів у SageMaker, керуючи зусиллями з виведення великих моделей. Він захоплений застосуванням машинного навчання в галузі аналітики. Поза роботою він любить прогулянки на природі.