MLOps: універсальний гайд з моніторингу моделей на проді

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Стаття написана у співавторстві з Дмитром Біліченком і Тарасом Ільящуком.

Привіт! Ми команда Operational Intelligence з EPAM Systems, де займаємось ML/AIOps, моніторингом та логуванням. Крім того, ми сертифіковані фахівці з машинного навчання на провідних хмарних платформах.

Одне з наших ключових завдань — це забезпечувати observability систем та застосунків. Коли справа стосується Machine Learning (ML), точність результатів моделі повинна максимально задовольняти очікування користувачів і дозволяти бізнесу здобувати вигоду. Відповідно, щоб make this happen, вищезгадане observability має бути на висоті.

У цій статті ми поділимось:

  • лайфхаками для ефективного моніторингу ML-моделей;
  • підводними каменями, які часто зустрічають MLOps-інженери;
  • (не)найкращими практиками для моніторингу моделей у продакшн-середовищі.

Стаття буде корисна:

  • MLOps-інженерам;
  • фахівцям з науки про дані;
  • Big Data/Data Science менеджерам;
  • Monitoring professionals;
  • всім, хто любить дані та все, що з ними пов’язано.

Погнали!

А якого дідька мені треба моніторити ML-модель?

Якщо ми думаємо, що після розгортання моделі процес розробки успішно завершився, то ми помиляємось, адже виконано лише половину роботи :) І швидше за все, ми переходимо у нову стадію «Monitoring, Observability, and Maintenance», яка містить багато аспектів.

Власне, грамотний моніторинг забезпечить довготривалу надійність системи та дозволить запобігти критичним проблемам у проді.

Source

Які проблеми виникають з ML-рішенням при відсутності моніторингу

Додаткова причина для моніторингу ML-моделі — це необхідність розуміти, як вона перфомить і чи вирішує поставлену бізнес-задачу. Наприклад, на найбільш ранніх ML-проєктах у рітейл-компанії GAP, яка займається виробництвом одягу, створили модель, яка визначала необхідну кількість товару певного розміру, щоб задовольнити потребу клієнтів. Data Science команда розробила алгоритм і Java-інженер конвертував його у код.

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

Чи можна уникнути цієї ситуації? Так. Яким чином? Моніторити модель, а також здійснювати ітеративну валідацію.

Приклади, чому варто моніторити та вдосконалювати модель після змін, пов’язаних з пандемією COVID-19:

  • Точність моделі для прогнозування потреби в товарі в магазинах Instacart впала з 93% to 61% через різку зміну поведінкових патернів користувачів.
  • Фахівці банківської сфери поставили під сумніви здатність кредитних моделей, навчених у доковідні часи, успішно працювати під час кризи COVID-19. Це пов’язано з тим, що після початку локдауну люди почали активно здійснювати онлайн-покупки — моделі не знали як «відреагувати».
  • Трейдинг-алгоритми не були здатні ефективно прогнозувати тренди ринку через невизначені коливання на біржах.
  • Моделі класифікації зображень перейшли до «нової нормальності»: тепер зображення людини з ноутбуком вдома класифікуються як «праця», а не «проведення вільного часу».
  • Прогнози погоди стали менш точними, оскільки багато цінних даних перестали збиратись через зменшення кількості комерційних авіарейсів.

Отож, справді, у ML (та й не тільки) все доволі мінливе — виникають помилки, пайплайни ламаються, поведінка користувачів змінюється. І якщо модель отримує незрозумілий чи невідповідний запит, то й відповідь на нього буде ще більш незрозумілою та ненадійною.

ML модель, попри свою «гнучкість» у знаходженні взаємозв’язків у великих наборах даних, має безліч ахілесових п’ят (aka вразливостей). Тому моніторинг потрібний з наступних причин:

  1. Якість вхідних даних та їхня структура.
  2. Перфоманс моделі з часом схильний погіршуватись.
  3. Взаємозалежні моделі або своєрідний pipeline моделей.
  4. Анормальні значення або невідомий prediction на невідомий для моделі сценарій.
  5. Розуміння, яким чином модель вирішує бізнес-проблему.
  6. У багатьох випадках відсутність істинних значень у запитах апріорі — ми не знаємо 100% до якого класу/кластеру може належати певний користувач, на це потрібен час.
  7. Ендпойнт, де розгорнута модель, може стати недоступним.
  8. Зміна бізнес-логіки застосунка.
  9. Вразливість моделі до кібератак.
  10. Втрата даних.

Ці та інші причини роблять моніторинг ML-моделі необхідним, якщо ми бажаємо досягти та підтримувати високий рівень точності.

Доволі цікавими є кейси з вразливістю моделей, особливо для оцінки кредитного ризику, у певних фінтех-рішеннях тощо. Є підтверджені випадки, коли зловмисники намагаються «обхитрити» модель, щоб шахрайська транзакція була класифікована як нормальна. Саме для цього потрібен фахівець, а не алгоритм, щоб провести додаткову валідацію.

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

Як це виявити? Один із способів: порівняти data distribution попереднього та свіжого наборів даних. І завжди слід проявляти скептицизм щодо даних та їх достовірності.

Чому ML-моніторинг є складним

Перед тим як перейти до аспектів моніторингу ML-моделі та їхнього детального опису, доцільно пояснити, у чому полягають найбільші складності цього процесу і як з ними змиритись впоратись.

Потрібно моніторити щось більше, ніж сервіс

У класичному програмному забезпечені, або як кажуть «софті», наприклад вебсайті для електронної комерції, основні метрики — це тривалість запиту, частота помилок, Apdex, CPU/Memory Utilization. З ML-моделлю потрібно моніторити ці операційні метрики, а також і специфічні для перевірки функціональності ML-рішення: точність, якість даних, працездатність data pipelines тощо.

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

Критичним залишається і розуміння доменної галузі. Наприклад, у задачах spam detection точність може становити 99%. Нас повинні турбувати такі значення:

  • false positive — листи, які не є спамом, але потрапили у папку «Спам»;
  • false negative — листи, які є спамом, та потрапили у папку «Вхідні».

Якщо ми вважаємо хоча б одне з вищезгаданих значень надто високим і незадоволені ним, точність 99% практично нічого не означає.

Source

Відсутність істинних значень

Чи можливо визначити наскільки точним є output моделі у одному конкретному випадку? Дуже часто на проді істинні значення відсутні, а іноді потрібен час, щоб їх отримати. І звісно ж, потрібна окрема логіка для збору істинних значень, складність якої залежить від технічного рішення, галузі, бізнес-проблеми тощо.

Тому нам одразу важко оцінити, чи модель видала правильний прогноз, скажімо, для певного користувача.

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

Ще один приклад: результат на запит до моделі свідчить, що для задоволення потреб відвідувачів ресторану на найближчі вихідні необхідно замовити 25 кілограм охолодженого лосося. Бізнес діє згідно з рекомендацією і готується приймати відвідувачів на вихідних. Чи можемо ми сказати наскільки точним є цей конкретний прогноз? Ні, це буде відомо лише після вихідних. І можливі безліч сценаріїв, зокрема, лосося виявилось достатньо/недостатньо/забагато.

Або модель спрогнозувала, що користувач зацікавлений у купівлі нових пар кросівок, відповідно ми їх таргетуємо. Проте чи насправді це так? Наш покупець може їх придбати сьогодні, через тиждень або й взагалі ніколи. Як варіант, можна спитати користувача — чи ця рекомендація/пропозиція доречна? Ми отримуємо like/dislike та розуміння, в якому напрямку рухаємось.

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

Дані, дані, дані

Крім необхідності писати і оновлювати код, інфраструктуру, потрібно дбати і про вхідні дані, їхній збір для майбутнього перенавчання.

Проблемні запити

Наявність виняткових та незвичних значень (outliers), відсутність даних для всіх параметрів (наприклад, користувач не заповнив всіх необхідні поля), прогноз класу, якого модель не навчена визначати.

Найгірше, що у деяких з цих випадків модель не поверне 4XX або 5XX HTTP код помилки, а спрогнозоване значення, яке може виявитись неточним.

Аспекти моніторингу моделі на проді

Ми вважаємо доцільним поділити моніторинг ML моделі на 4 частини:

  1. Дані.
  2. Модель.
  3. Інфраструктура.
  4. Бізнес KPIs.

Дані

Найбільш поширені проблеми:

  • Data skew — відмінність статистичних властивостей між навчальним та продакшн набором даних.
  • Data drift — зміна статистичних властивостей даних з проду через певний період.
  • Concept drift — зміна взаємозалежностей між незалежними та залежними змінними у даних з проду в порівнянні до навчальних/тестувальних даних. Дуже часто виявляється за відмінністю у розподілі target variable у навчальному датасеті та проді.
  • Schema skew — зміна структури, формату даних, методів їх опрацювання у пайплайнах.

Як і людина на 80% складається з води, так і ML модель на 80% складається з даних (це жарт, у моделях значення варіюється — прим. авторів). Будь-які зміни з даними впливають на результати та точність моделі. Тому до питання даних кожному експерту варто підходити з дозою скептицизму.

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

1. Розподіл даних — наскільки він відмінний у реальних даних з проду та навчальному датасеті, а також з проду колись і зараз. Часто трапляється, що точність моделі на training/testing/validation datasets відповідає очікуванням, проте для даних з проду цей показник значно менший. Одна з причин — розподіл даних відрізняється, і модель нездатна до належного узагальнення та прийняття рішень. Проблему, відображену на графіку нижче, прийнято називати Data skew.

Source

2. Якість та структура даних — чи приходять дані у правильному форматі, відповідність структури даних, яку очікує ML-модель, відсутні значення або NAs, опрацювання даних у конвеєрі (pipeline), назви фіч, одиниць вимірювань.

Source

3. Наявність анормальних значень або викиднів (outliers).

Source

4. Відсоток запитів з відсутніми значенням (nulls, NAs).

5. Описова статистика про вхідні дані та метадані — залежить від задачі, наприклад, яскравість зображення, середня тривалість голосового повідомлення, медіана/дельта/мода певної фічі тощо.

Перед тим як гортати вниз, пропонуємо проаналізувати таблицю з «брудними» даними та визначити, скільки помилок є у структурі та форматі. Адже дуже часто саме так виглядають реальні дані користувачів, тому потрібні механізми для запобіганню вводу таких значень. Опис всіх проблем подано нижче.

Source

  1. Значення 231 у колонці Age — викид (outlier) і в принципі неможливе.
  2. Колонка Income — відсутність узгодженості стосовно періоду, за який визначається прибуток: per year чи per month?
  3. У другому рядку колонки Education подано значення «Бакалавр» китайською мовою. Модель зійде з розуму.
  4. У колонці State замість назви штату подано освітній ступінь — Bachelor. Здається, хтось ввів неправильне значення в потрібне поле.
  5. Наявність майна кодується значеннями Yes/No чи 1/0 у колонці Property?
  6. Пропущені дані.
  7. Викид у колонці Income — 3 000 000/year. На перший погляд, не дуже критично, але на перфоманс моделі може вплинути.

Модель

Модель відповідає за прийняття рішення, відповідно основне завдання цього аспекту — це моніторити поведінку, а також результати, які модель прогнозує.

На що слід звернути увагу:

  1. Training/Serving skew — різниця у перфомансі моделі під час навчання та у проді.
  2. Model Target drift — моніторимо перформанс метрики у динаміці — тобто їхній тренд за певний період, чи відповідають вони встановленій цілі. Важлива нотатка: ML-модель схильна до деградації з часом та потребує перенавчання.
  3. Fairness — чи не прийматиме наша модель упереджені рішення стосовно певної категорії користувачів? У застосунка для покращення якості зображень за допомогою штучного інтелекту Let’s Enhance був цікавий казус: алгоритм «відбілював» фотографії чорношкірих користувачів.
  4. Точність моделі для певного сегменту користувачів — припустимо, у нас є три типи клієнтів, для двох з них точність прогнозів становить по 99%, тоді як для третього — близько 75%. Середня accuracy становитиме 91%, що загалом ОК. Тому ми знаємо, яка група користувачів отримує менш точні рекомендації/прогнози і потребує вдосконалення. Як вирішення проблеми, ми можемо зібрати ground truth, здійснювати додаткове опрацювання даних або додати певну логіку до моделі.
  5. Прогнози моделей у конвеєрі: деякі кейси передбачають передачу output однієї моделі як input іншої. Якщо попередня модель зробила неточний прогноз, то висока ймовірність, що поточна і наступна моделі видадуть також нерелевантний результат. Така собі ланцюгова реакція.

Під час навчання моделі ми відштовхуємось від наведених нижче метрик для валідації, проте в проді у нас можуть виникнути труднощі в їх обчисленні для:

  1. Регресії (Residuals, MAE, MSE, RMSE, R-squared). Рекомендовано візуалізовувати: residuals як гістограму — дозволяє побачити, наскільки модель робить over- або underestimate числового значення; regression trendline. Іноді може бути корисно змоделювати лінійну регресію як частину data exploration, це дасть змогу зрозуміти кореляцію між фічами, їх особливості.
  2. Класифікації (Accuracy, F1 Score, Precision & Recall, AU-ROC, Gini and KS -Statistics, Confusion Matrix). Якщо працюємо з класами, ми рекомендуємо також візуалізовувати Contingency Table — ефективний спосіб побачити розподіл класів, виявити imbalance, взаємозв’язок та взаємодію ними. Також доволі важливою є AUC крива, її часто застосовують для порівняння перфомансу декількох моделей. Якщо коротко, то вона відображає співвідношення між True Positive та False Positive rates.
  3. Кластеризації (середня дистанція між центроїдами та кластерами).
  4. Навчання з підсиленням (sum of discounted rewards, the sum of rewards, time to achieve the desired performance per episode; percentage of successful episodes when solving an episodic task; other metrics related to the domain).

Чому? Як вже було зазначено, після того як модель здійснила прогноз, у більшості випадків істинне значення може бути відсутнім одразу. Потрібно придумувати окрему логіку для збору реального значення залежної змінної Y. Лише тоді валідацію точності моделі можна здійснити і в проді.

Проте якщо не знаємо, якому запиту і яке істинне значення належить — це не біда. У таких випадках можна порівняти розподіл спрогнозованих та реальних значень. Дозволить швидко оцінити наявність skew і обчислити певні performance метрики.

Інфраструктура

Це відносно найпростіший аспект моніторингу, який не є залежним від типу моделі, структури та набору даних. Проте він важливий, оскільки слід пам’ятати, що ML-модель — це додаткове навантаження на інфраструктуру. Іноді доцільніше розгорнути на проді модель з трішки нижчим performance, але меншим використанням обчислювальних ресурсів.

Крім того, моделі, які споживають багато обчислювальних ресурсів, можуть обходитись «дорого» не лише для бізнесу, але й довкілля: під час тренування, state-of-the-art трансформери виробляють 50% загального CO2 упродовж процесу вдосконалення фінальної точності на 0.3%. Тому розробникам невдовзі доведеться шукати trade-off між точністю моделі та впливом на довкілля.

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

Що стосується інфраструктури, то найчастіше йдеться про модель як сервіс. Цей аспект містить наступні «операційні» метрики:

  1. Prediction rate — скільки запитів опрацювала модель за певний період часу.
  2. Prediction latency — тривалість опрацювання запиту (з/без ML обчислень).
  3. Загальний час відповіді для ML Endpoint.
  4. Доступність сервісу.
  5. CPU/Memory Utilization.
  6. Error rate.
  7. Throughput & Saturation.

Бізнеc KPI

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

А іноді, попри високу точність моделей, вона не приносить жодного business value. Це виявив сервіс Booking.com після розгортання 150 моделей у проді.

Відповідно, у цьому аспекті варто звертати увагу чи застосування моделі дало бажані результати для бізнесу, які можуть відображатись у наступних метриках:

  1. Customer Satisfaction Score (CSAT).
  2. Коефіцієнт конверсії.
  3. Фінансові результати.

Метрик у цьому аспекті може бути неймовірно багато і, зазвичай, вони залежать від специфіки галузі. Наприклад, якщо говорити про Security, можна брати до уваги наскільки зменшились витрати на моніторинг загроз і вразливостей, який вдалось автоматизувати за допомогою ML-моделі. У випадку з маркетплейсом, доцільно спостерігати, чи збільшилась кількість покупок товарів, які модель рекомендує.

Типи моніторингу

Модель, розгорнута в хмарі

Хмарні платформи набувають все більшої популярності у багатьох Data Science та Machine Learning-проєктах. Причини очевидні:

  1. Відсутність потреби самостійно менеджити 100% інфраструктури.
  2. Можливість експериментувати з ML та швидко масштабуватись в прод.
  3. Велика кількість готових AI рішень та сервісів.
  4. Вартість розробки та розгортання моделі у багатьох випадках є нижчою в Cloud, ніж on-prem.
  5. Наявність гнучкого та еластичного сховища даних.

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

AWS

Поточний лідер ринку хмарних обчислень AWS пропонує Amazon SageMaker для фахівців з науки про дані. Якщо вірити офіційному опису сервісу, пропонується окремний інструментарій для ефективного здійснення MLOps-активностей:

  1. Створення CI/CD конвеєрів.
  2. Автоматизація виробничих процесів ML Engineering.
  3. Автоматичне виявлення bias, mode/data/concept drifts.
  4. Моніторинг якості розгорнутих моделей.
  5. Трекінг коду, даних та артефактів.

У цьому підрозділі нас найбільше цікавлять 3 та 4 пункти, відповідно ми розглянемо їх у контексті сервісу SageMaker.

Звісно ж, доступна інтеграція зі стандартними для моніторингу та логування сервісами AWS:

  • CloudWatch — логування, сповіщення, збір та візуалізації метрик з AWS Sagemaker.
  • CloudTrail — збір інформації про запити до ендпойнтів, де розгорнуті ML-моделі.

Для задоволення потреб моніторингу існує SageMaker Model Monitor — функціонал, який забезпечує постійний контроль моделі у проді та повідомляє розробників про відхилення у якості моделі/даних, наявність bias, дріфт у фічах. При налаштування певних конфігурацій, метрики, сформовані у Model Monitor, можна надсилати у CloudWatch.

Також, AWS SageMaker пропонує можливість використовувати готовий інструментарій або ж «накодити» власний набір правил для моніторингу за допомогою SageMaker SDK, що є достатньо гнучко.

Як працює Model Monitor у AWS?

  • Слід дозволити збір даних запитів та результатів предікшнс моделі з ендпойнта. Зазвичай, ці дані йдуть в окремий S3 Bucket. Водночас, в додатковий S3 Bucket ми зберігаємо Ground Truth — істинний лейбл, який модель намагалась спрогнозувати раніше.
  • Наступна функція — моніторинг baselines (статистика про початковий стан навчального датасету). SageMaker достатньо розумний, щоб пропонувати розробникам порогові значення та обмеження для певних метрик. Порівнюється якісь продакшн даних з training dataset з використанням правил для виявлення дрифтів, та при їх недотриманні формуються порушення.
  • Формування звітів на основі регулярного аналізу даних запитів з вищеописаних джерел, метрик щодо якості даних, моделі, інформації про порушення бейслайнів, сповіщень з CloudWatch.

Слід зазначити, що Model Monitor на момент написання статті працює виключно з табличними даними і можливий моніторинг ендпойнтів лише з однією розгорнутою моделлю.

Azure

Azure Machine Learning — хмарний сервіс для розробки моделей та управління їх життєвим циклом, який пропонує Microsoft. Однією з особливостей цього інструментарію є здатність виконувати та автоматизовувати MLOps-задачі, у тому числі й моніторингу та логування моделей і ендпойнтів.

Azure ML надає такі методи моніторингу, організації і відстеження запусків та експериментів:

Application Insights — основний сервіс для моніторингу, так званий Application Performance Monitoring (APM) інструмент, який містить сховища для зберігання метрик і логів з ресурсів Azure, у тому числі й Machine Learning Service, у режимі реального часу.

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

Source

Source

Azure Dataset Monitor — інструменти всередині ML Service, який:

  • аналізує дріфт у даних;
  • моніторить навчальні і продівські дані;
  • слідкує за статистичними показниками фіч та їхній зміні з часом;
  • дозволяє створювати «алерти» для нотифікацій.

Також особливістю цього інструменту є можливість створювати версії датасетів для тренування і виявлення дріфтів. А за допомогою Python SDK можна налаштовувати виявлення (DataDriftDetector) і сповіщення (AlertConfiguration) дата дріфтів, а також «кверяти» відповідні метрики.

Azure ML Service дозволяє здійснювати вищеописані задачі моніторингу з використанням:

  • AzureML SDK для Python.
  • Machine Learning CLI.
  • REST API.

Крім того, слід зазначити, що якщо модель розгорнута на Azure Kubernetes Service (AKS) кластері, є можливість зберігати дані з проду в Azure Blob Storage. У контексті моніторингу та оптимізації ML-моделі це дає такі переваги:

  1. Моніторинг data drifts.
  2. Аналіз даних за допомогою аналітичних сервісів.
  3. Перенавчання моделей на свіжих даних.

Для більш детального розуміння збору даних з моделей, розгорнутих на кінцевих точках з використанням Azure Application Insights та Python SDK, додається посилання на технічну документацію.

GCP

Якщо йдеться про можливості хмарної платформи «гугла», то їхні AI/ML сервіси суттєво перевершують Azure та AWS. Згідно з Магічним Квадратом Гартнер 2021, Google вважається лідером на ринку Cloud AI-сервісів.

Першість GCP у цьому сегменті зумовлені наступними чинниками:

  • Наявність TPU (Tensor Processing Unit), що дозволяє пришвидшувати AI обчислення.
  • Google — ключовий розробник та контриб’ютор в open-source проєктах — Kubeflow; TensorFlow.
  • Неймовірні інвестиції в AI Research та регулярне відкриття дослідницьких лабораторій.

GCP пропонує ML-інжерам Vertex AI — сервіс для розробки, розгортання та управління життєвим циклом моделей. Набір інструментів Model Monitoring, як вже зрозуміло з назви, забезпечує моніторинг Machine Learning пайплайнів, моделей, та ендпойнтів, на яких вони розгорнуті.

Доволі цікава та корисна особливість: Model Monitor — це здатність визначати data skew та data drift. Між цими двома поняттями є суттєва різниця і Vertex AI успішно справляється із їх виявленням.

Конфігурація цих індикаторів не є суттєво відмінна від двох попередніх платформ: порівнюються встановлені бейслайни та обчислені на продакшн даних distance scores. У випадку їх порушення — приходять сповіщення. Все ясно, як білий день.

Як все відбувається behind the closed door?

Відсоток даних запитів, які «прилітають» до ендпойнту з моделлю, зберігаються в BiqQuery таблиці проєкту. GCP парсить фічі з цих запитів для подальшого аналізу.

А тим часом інженер налаштовує data drift/skew detection, де вказує набір параметрів. Детальніше з ними можна ознайомитись тут.

Vertex AI експортує метрики в Cloud Monitoring. Крім інформації про використання ресурсів (CPU/Memory/Network Usage тощо), існує корисний набір метрик перфомансу моделі на ендпойнті, яка приймає запити і обслуговує користувачів:

  • кількість опрацьованих запитів за секунду;
  • частота помилок під час прогнозування;
  • тривалість ML-обчислень;
  • тривалість запиту без ML-обчислень;
  • загальна тривалість.

Повний список метрик, які доступні з сервісів Vertex AI & AI Platform, доступні тут.

Разом з тим, Vertex AI пропонує збір логів з ендпойнтів після розгортання моделі: Container (stdout, stderr) та Access Logs. За потреби можна вимкнути/ввімкнути логування з ендпойнта, що вимагає редеплойменту.

Навіть у аспекті моніторингу ML-моделей на проді, рішення GCP виграють у конкурентів з Azure та AWS. Рішення від Vertex AI дозволяє моніторити одразу декілька моделей, розгорнутих на одному ендпойнті, а конкуренти — ні. Багатий функціонал та велика кількість метрик роблять цей процес простішим та ефективнішим.

Інструменти для моніторингу ML-моделей

Разом з швидким розвитком Data Science & Machine Learning-індустрії та появою нових кваліфікацій (той же MLOps-інженер), так само стрімко з’являються нові інструменти для вирішення та автоматизації задач галузі. Для вирішення задач observability & моніторингу моделей існує як багато open-source, так і пропрієтарних засобів.

Доволі популярним залишається використання наступного набору інструментів:

  • Prometheus Exporters — для збору метрик.
  • Grafana — для візуалізації.

Зрештою, збір та візуалізацію метрик можна здійснювати за допомогою багатьох інших «класичних» для логування і моніторингу рішень, типу ELK, Splunk, Datadog, NewRelic, Fluentd тощо.

SaaS-платформа для моніторингу New Relic пропонує доволі гнучке MLOps-рішення, щоб покращити «видимість» моделей на різних етапах розробки та проді. Дані можуть збиратись завдяки двом наступними способам:

  1. Партнерські інтеграція з ML-платформами (Datarobot (Algorithmia), Aporia, Comet, DagsHub, Superwise та інші, список оновлюється).

  2. Інтаграція з AWS SageMaker (з іншими хмарними платформами у New Relic поки що такий коннектор відсутній).
  3. Bring Your Own (BYO) data, незалежно від платформи, за допомогою ml-performance-monitoring Python бібліотеки, яка під капотом використовує newrelic-telemetry-sdk-python.

На нашу суб’єктивну думку, це рішення є доволі конкурентним для моніторингу ML моделей і заслуговує на увагу. Користувач отримує перфоманс дані, можливість конфігурації сповіщень та набір дашбордів у єдиній платформі. Це особливо корисно, якщо компанія раніше використовувала New Relic для моніторингу, а після появи ML рішення є можливість інтеграції в цей сервіс для подальшої кореляції.

Приклад одного з таких дашбодів зображено нижче.

Source

Ресурс mlops.toys пропонує набір інструментів для вирішення різноманітних задач у галузі, у тому числі моніторингу. Рекомендуємо ознайомитись зі списком репрезентованих проєктів.

MLflow

Вважаємо доцільним згадати про цей засіб, оскільки його функціонал дозволяє ефективно та з легкістю керувати ML-моніторингом під час розробки моделі та поведінкою у проді.

MLflow — це фреймворк з відкритим програмним кодом для менеджменту життєвого циклу моделей машинного навчання.

Основні причини, чому Data Science світ любить його:

  • функціонал для менеджменту моделей та трекінгу експериментів;
  • забезпечує MLOps-friendly зберігання файлів та суміжних артефактів;
  • дозволяє здійснювати просте і швидше розгортання моделі;
  • сумісність з багатьма платформами та ML-фреймворками;
  • працює з Python, R, Java, REST;
  • моніторинг моделі.

Оскільки нас найбільше цікавить саме моніторинг, ми зосередимось на особливостях його реалізації за допомогою MLfLow.

MLflow Tracking — це компонент фреймворку, який відповідає за логування подій та метрик моделі машинного навчання і дозволяє здійснювати їх повноцінний моніторинг. Працює за принципом моніторингу окремих виконань коду (runs), які можна згрупувати у експерименти.

На схемі, поданій нижче, відображено, що під час окремого виконання ми отримуємо наступні інформаційні «активи»:

  1. Сутності (Entities) — дані про окремий «run» (дата і час, версія, метрики, теги, метадані тощо).
  2. Артефакти (Artifacts) — файли, модель, графіки.

Відповідно, логування можна здійснювати як локально? так і у віддалені файлові сховища (AWS S3, Azure Blob, Google Storage), SQL бази даних.

Корисна фіча: навіть якщо ми розгорнули модель за допомогою MLflow на хмарній платформі, наприклад у Azure Machine Learning Workspace, ми можемо використовувати функціонал як і фреймворках MLfLow, так і сервісу хмарної платформи.

Source

Нижче подано шматочок коду для логування метрик та параметрів за допомогою MLflow:

  1. Використовуємо контекстний менеджер, щоб розпочати і керувати виконанням коду.
  2. Визначаємо змінні для лінійної регресії, тренуємо модель та виконуємо команду predict для отримання результатів.
  3. Обчислюємо метрики — RMSE, MAE, R2.
  4. Виводимо в консоль гіперпараметри та метрики.
  5. Логуємо графік, гіперпараметри та метрики з використанням методів log_param, log_metric та log_figure.
  6. Навчену модель зберігаємо як MLflow model artifacts.
with mlflow.start_run():
        linear_regression = sklearn.TweedieRegressor(power=power, alpha=alpha, link=’log’)
        linear_regression.fit(train_x, train_y)

        predicted_qualities = linear_regression.predict(test_x)

        (rmse, mae, r2) = evaluate_metrics(test_y, predicted_qualities)

        print("Tweedie Regressor model (power=%f, alpha=%f):" % (power, alpha))
        print("  RMSE: %s" % rmse)
        print("  MAE: %s" % mae)
        print("  R2: %s" % r2)

        residuals = test_y-predicted_qualities 
        residuals_plot = plt.scatter(residuals, predicted_qualities)

        mlflow.log_param("power", power)
        mlflow.log_param("alpha", alpha)
        mlflow.log_metric("rmse", rmse)
        mlflow.log_metric("r2", r2)
        mlflow.log_metric("mae", mae)
        mlflow.log_figure(residuals_plot, "residuals_plot.png")


        mlflow.sklearn.log_model(linear_regression, "model")

Доданий код ми будемо часто застосовувати під час навчання моделі, і з меншою частотою у проді. Для використання у продакшн, ефективним є MLflow Tracking Server, забезпечений User Interface та API і дозволяє переглядати метрики, логи, гіперпараметри, артефакти, ML-моделі та метадані, оцінювати service health та масштабуватись.

Якщо немає бажання/ресурсів самостійно сетапити і керувати MLflow, databricks пропонує зробити це замість вас.

Ці та інші особливості роблять MLflow ефективним інструментом інженера для автоматизації рутинних завдань роботи з моделлю.

Також сертифікаційні екзамени з Data Science & Machine Learning можуть містити питання по цьому фреймворку (наприклад, Azure Data Scientist Associate).

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

Best Practices

Перенавчання (Retraining)

Під час розгортання моделі на проді, ми очікуємо отримувати певні похибкиу предікшнах, які можуть регулярно повторюватися. Додатковою проблемою ML-моделей є їхня схильність до деградації протягом певного періоду, або як прийнято називати — model drift. Ми можемо вважати, що наша модель перформить на 99% точності зараз, проте це не означає, що так буде завжди. Тому нам потрібно, адаптувати модель та «допомогти» їй уникати повторення цих помилок. Для цього доцільно здійснювати перенавчання.

Найбільш поширені причини для ретрейнінгу моделі:

  • деградація перфомансу;
  • поточна модель не репрезентує всю популяцію користувачів;
  • зміна бізнес-проблеми;
  • зміна в розподілі/структурі даних;
  • змагальне середовище (наприклад, у галузі Security, коли постійно з’являються нові загрози і модель повинна вміти їх виявляти).

Разом з тим, бувають випадки, коли перенавчання не є потрібним через такі фактори:

  • обчислювальні витрати;
  • модель все ще перфомить добре і не досягла критичних порогових значень;
  • витрати на реалізацію рішення.

Source

Рекомендуємо, перед тим я ретрейнити модель, відповісти на такі запитання:

  1. Як часто потрібно перенавчати модель, зважаючи на регулярність попередніх model drifts?
  2. Як перфомить наша модель у цей момент і чи є потреба ретрейнити її тут і зараз?
  3. Потрібно лише перенавчити модель чи змінити пайплайн/алгоритм/архітектуру тощо?

Іноді недостатньо «згодувати» модель свіжими даними, а виникає необхідність здійснити feature engineering, тюнінг, або й оновити механізм збору даних. Тому відповідь на ці питання дозволить з’ясувати, наскільки критичним і доцільним є ретрейнінг.

Стосовно першого питання — регулярність data drifts/skews залежить від багатьох факторів. Наприклад, поведінка користувачів зазвичай змінюється доволі повільно і поступово (виняток становлять кризові ситуації), тоді як виробничі або бізнесі дані є дуже непостійними і доволі швидко втрачають актуальність.

Тому автоматизація процесу перенавчання дозволяє мінімізувати витрати і в певних кейсах є необхідною.

Autoretraining або автоматичне перенавчання — це методика, яка дозволяє системі самостійно здійснювати перенавчання моделі, якщо вона не відповідає встановленим пороговим значенням.

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

Наприклад, на платформі AWS це можна робити з використанням Lambda & Step Functions. Детальніше за посиланням.

Припустимо, середнє статистичне значення, яке прогнозує наша модель на проді, становить X. Через місяць приходять сповіщення, що це значення зросло на 15%. Це може бути індикатором, що модель дрифтить і слід тригерити перенавчання.

Незважаючи на підвищену продуктивність після перенавчання, існує ймовірність, що нова модель буде гіршою за стару. Рекомендуємо залишити стару модель, доки нова модель не обробить певну кількість запитів і тоді ми зможемо порівняти результати та обрати кращу модель. Саме для цього використовується метод A/B Testing, описаний нижче.

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

Для порівняння перформансу ML-моделі у продакшн середовищі, рекомендується застосовувати техніку A/B тестування. Часто це є фінальний крок валідації моделі перед тим, як остаточно використовувати її як основну модель на проді.

Основні use cases:

  1. Порівняння поточної та оновленої версій моделі.
  2. Порівняння двох моделей, навчених на різних наборах даних або з використанням різних алгоритмів, фреймворків тощо.

Цей метод доволі простий та зрозумілий: трафік розподіляється між двома моделями. Наприклад, у нас є стабільна версія моделі v1, яка опрацьовує 95% запитів, та оновлена версія v2, у якої ця частка становить, відповідно, 5%. Таким чином, ми можемо спостерігати як працює версія v2 на даних реальних користувачів і з’ясовуємо, чи є потреба оптимізовувати її. Якщо все ОК, надсилається 100% на оновлену версію моделі, якщо ні — віддаємо весь трафік стабільній версії v1 та удосконалюємо v2.

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

На схемі нижче ми бачимо, що endpoint містить 3 production variants, де кожен — це окрема модель. Ваговий коефіцієнт визначає відсоток трафіку, який кожен з variants буде опрацьовувати.

Source

Тестування моделі на невідомих для неї спостереженнях у Real-time

Ще один цікавий та ефективний спосіб здійснити валідацію моделі. Припустимо, команда Data Scientists розробила модель для прогнозування трьох класів автомобіля на основі N фіч:

  1. Бізнес-клас.
  2. Середній клас.
  3. Компактний або гольф-клас.

Модель розгорнута у тестувальному середовищі і ендпойнт доступний для надсилання запитів.

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

Source

У цьому випадку модель, швидше за все, спрогнозує один з трьох класів, який за характеристиками найбільш схожий до фіч Mini-Car, але це не точно ;)

Якщо ця ситуація трапляється, необхідно налаштувати механізм обробки таких типів запитів, коли намагаємось спрогнозувати невідомий для ML-моделі клас і здійснювати наступне:

  1. Повернути користувачу клас автомобіля «Інший».
  2. Провести додатковий збір даних для репрезентацію всіх можливих кейсів.
  3. Перенавчити модель.

Поради колегам у царині MLOps

Моніторинг ML-моделі — це ітеративний процес, який не завжди буде на 100% якісний та ефективний після першого деплойменту. На це потрібен час і ресурси.

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

  1. Що може піти не так з моделлю і які проблеми можуть виникнути?
  2. Які метрики доцільно моніторити у конкретному випадку?
  3. Як зібрана статистика дозволяє зрозуміти, чи вирішена бізнес-проблема?

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

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

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

Іноді доводиться чути, що моніторинг не є виправданим і його користь відсутня. Пропонуємо в коментарях поділитись власним досвідом і наскільки цінним вважався результат ;)

Недарма кажуть, що успішні ML-проєкти — це не лише якісні моделі, але й аналітика й моніторинг даних та їхніх джерел, відповідних метрик.

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ми в databand.ai якраз працюємо над розробкою повноцінної системи моніторингу дата пайплайнів. В тому числі вміємо відстеджувати операції над датасетами, детектити зміну схемі і так далі. В тому числі маємо інтеграцію із Mlflow та іншими бібліотеками та інструментами пов’язаними з data health.

На це все звісно є дашборди, візуалізації (не просто графана, а спец інтерфейс), алерти і так далі і так далі. Того року підняли інвестицій на 15$M.

Кількість рішень у цьому сегменті і demand на них продовжує зростати. Гляну на ваш продукт)

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

Гляну на ваш продукт

В нас також є опенсорсна частина для оркестрації: github.com/databand-ai/dbnd

Підписатись на коментарі