Чого очікувати та на що розраховувати, коли впроваджуєш у бізнесі машинне навчання

Мене звати Дмитро, наразі я ML Engineer у Levi9 IT Services. Маю близько 10 років досвіду в аналізі та обробці даних, розробці вебсервісів і машинному навчанні.

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

Вам вона буде корисною, якщо ви плануєте додати ШІ до свого проєкту або вже пробували таким чином його покращити, але не вдалося.

Робота з ШІ та ML: плюси й мінуси

Потреби та очікування клієнтів будь-якого сучасного бізнесу високі, і щоб надавати продукти та послуги, що їх задовольнятимуть, часто треба опрацьовувати багато даних. Через зацікавленість світових компаній у великих даних і аналітичних системах, ринок Data Science зростає — до 2026 року він має вирости до майже $323 мільярдів. Бізнес інвестує в роботу з даними та штучним інтелектом і, як наслідок, збільшується попит на спеціалістів у Data Science.

І все ж не завжди працювати з даними легко, а розібратися, що саме може піти не так, допоможе дослідження за 2022 рік, метою якого було визначити стан речей у галузі Data Science. Опитування 300 спеціалістів галузі, серед яких аналітики даних, data-scientists, ML- і data-інженери показало, що вони часто стикаються з такими проблемами:

  • впровадження елементів ШІ повільне та може тривати рік замість запланованих 2 місяців;
  • це дорожче, ніж розраховували;
  • низька якість моделі;
  • не підходить під технологічний стек;
  • дані на «проді» суттєво відрізняються чи можуть відрізнятися з часом.

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

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

Джерело: 2022 State of Data Practice Report


Джерело: 2022 State of Data Practice Report

Чому терміни виконання вищі очікуваних

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

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

Бізнес намагається виправдати очікування і часто поспішає. А якщо ще й бракує реального досвіду впровадження ШІ, то виникає «ефект доміно» і проблеми накладаються одна на одну.

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

Чому впровадити ШІ дорожче, ніж розраховували

Витрати на впровадження технологій на базі ШІ лінійно пов’язані з термінами виконання задачі. Оплачувати роботу команди, обчислювальні потужності та інші сервіси впродовж 3 місяців вигідніше, ніж рік.

Однак є й інші чинники. Наприклад, cloud-провайдери активно переконують, що передавши дані в їхню чорну скриню, ви отримаєте готову модель. Build, train and deploy, і купа прикладів на датасетах титаніка чи mnist-a. Складається враження, що все дуже просто, проте в 7 з 10 випадків задача складніша й вимагає певних workarounds.

Джерело: 2022 State of Data Practice Report

Чому якість рішення нижче очікуваної

Якість аналізу чи моделі в ML зазвичай оцінюється такими показниками:

  • бізнес-метрики (LTV, CSAT, фін. показники, і т.д.);
  • метрики «точності» окремої моделі (F1, Precision, Recall, [R]MSE, mAP, Dice, etc., залежно від «сімейства»);
  • інфраструктурні показники (throughput, latency, error rate, ram/cpu/gpu utilization, device temp, power consumption, etc.).

Натомість рішення загалом може бути неякісним, якщо цільові метрики:

  • Нереалістичні — і це цілком ок, адже такі метрики показують реальний стан речей. Якщо вам необхідний Recall у 98%, щоб рішення було прибутковим, це нормально. Інше питання — це намагатися його досягти чи взагалі відмовитись від ML.
  • Вигадані рандомно чи взяті з SOTA — це не ок, адже метрики взяті з інших або схожих даних нерелевантні для вашої проблеми та бізнесу. Можливо, вам достатньо і Recall у 85%, а націлившись на 98% ви ризикуєте ніколи їх не досягти й втратити хороше рішення.
  • Відсутні чи «якомога вищі» — це не ок, адже без метрик ні бізнес, ні спеціаліст не розуміють, навіщо їм потрібен ШІ. А якщо немає інфраструктурних метрик, то може бути така умовна ситуація: команда робить object detection&tracking на мобільних девайсах і отримує високі цільові показники точності від аналітиків.

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

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

Чому дані на «проді» відрізняються

Коли дані на «проді» змінюються, то може статися одна з таких ситуацій:

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

З часом розподіл даних змінюється, і це нормально — просто треба правильно й вчасно реагувати, як-то розпізнавати data drift, заново тренувати моделі на нових даних. Для цього й існують інструменти MLOps.

А якщо ви розгорнули рішення і побачили одразу, що модель поводить себе дивно — це поганий дзвінок. Можливо, ви допустили data leak (витік даних), не було тестового сету чи просто вибірка даних для тренування була нерепрезентативною. Збір та обробка даних у цьому pipeline (потік даних) дуже важливі.

Як робити правильно

На цій схемі добре зображено базовий алгоритм дій для впровадження ШІ, але варто деталізувати певні етапи.

  • Якщо ви успішно пройшли пункт 1, то починаєте проводити експерименти. На цьому етапі у вас має бути набір цільових метрик, які ви документуєте та озвучуєте команді чи підряднику. І потрібно зважати, скільки є даних. Якщо їх доволі багато і вони в хмарі, варто одразу працювати в сервісах типу AWS SageMaker і не переносити купу даних на ПК.
  • Якщо все ок, метрики досягнуті, немає витоку інформації й ви готові розгортати модель — не поспішайте. Перенесіть весь клубок коду з juputer-ноутбуків в репозиторій, розплутайте його, зробіть більш-менш нормальний дизайн коду для тренування/ оцінки/ інференсу (тобто використання розгорнутої моделі).
  • Зробіть код пре/постпроцесингу загальним, а не «copy-paste».
  • Зробіть ETL jobs для підготовки датасета та аугментацій або, іншими словами, перетворень.
  • Додайте версіювання даних, як-то Pachyderm, DVC чи просто s3 versioning.
  • Продумайте, як ви будете виявляти Data/Concept drift та інші моніторингові рутини;
  • Подумайте як збиратимете лейбли для нових даних (в межах supervised learning). Вам потрібні нові дані, щоб перетреновувати моделі та оцінювати їхню якість.

Іншими словами, не породжуйте величезний технічний борг, бо він має властивість самозбільшуватись.

А як розгорнете рішення, вам знадобляться «очі» та методи контролю цього величезного математичного графа.

Key takeaways

  1. Спочатку метрики, потім експерименти. Спочатку встановлюйте конкретні метрики якості, які можна порахувати грошима. Встановіть мінімальну межу якості роботи моделі, щоб розуміти, чи ціль загалом досяжна.
  2. Не розраховуйте на чіткі терміни під час proof of concept, але вимагайте прозорості. Це — найхаотичніший етап, на якому data analyst/ scientist має виконувати безпрецедентні задачі, а наступний крок часто залежить від результатів попереднього. Гіпотези або спростовуються, або підтверджуються.
  3. Максимально використовуйте бізнесові знання. Якщо зі своєї аналітики ви точно знаєте, що клієнти з дітьми частіше купують іграшки — використайте це на етапі моніторингу. І взагалі, якщо ви можете написати набір бізнес-правил для того, щоб класифікувати клієнта як потенційного, то оберіть цей метод, а не ШІ.
  4. Віддавайте перевагу досвідченим спеціалістам, якщо маєте обмежені ресурси. Індустрія досі вважається молодою, але певний досвід спеціалісти встигли накопичити. Це важливо, адже дозволяє їм обрати простіше/гнучкіше/ якісніше рішення. При цьому дорогу молодим талантам теж треба давати.
  5. Вкладайтесь в MLOps. Це важливо, але після того, як маєте чіткі метрики й експерименти доводять їхню досяжність.

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному1
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

вітання. дуже крута стаття, дякую! а чому не пишеш про AzureML? може комусь цікава буде така стаття?

дякую!
я б з радістю, але нажаль поки написати нічого

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