Життєвий цикл Data Science проєкту. Розбираємось на прикладах

Я — Data Scientist уже більше 10 років, працювала над розробкою, впровадженням і моніторингом сотень моделей, різноманітними Data Science-проєктами у різних доменах. Нині я Staff Data Scientist у компанії thredUP, до цього займалася Data Science Consulting.

Ця стаття буде корисна тим, хто хоче краще розуміти особливості Data Science-проєктів, зокрема Data Science-менеджерам, Project Managers та Product Managers.

Типовий життєвий цикл

У цьому розділі ми розглянемо один із найбільш поширених варіантів життєвого циклу проєкту. Я проілюструю кожен етап життєвого циклу прикладами етапів розробки моделі Conversion Rate prediction у нашій компанії.

Бізнес-задача

Більшість проєктів починається з бізнес-задачі, формулювання якої далеке від Data Science задачі. Головне завдання на цьому етапі — зрозуміти потреби бізнесу і транслювати їх у задачу Data Science. На цьому етапі варто поставити декілька питань:

  • Чи дійсно задачу найефективніше вирішувати засобами Data Science/ Machine Learning? У деяких випадках відповідь буде «ні», і вчасно поставлене питання збереже час і ресурси бізнес-стейкхолдерів і Data Science-команди.
  • Як ми будемо використовувати Machine Learning модель, коли отримаємо її на практиці? Чим чіткішою буде відповідь на це питання на початку проєкту, тим кращим буде ML-рішення. Відповідь на це питання часто впливає на вибір DS/ML-рішення.
  • Чи є у нас дані для побудови ML/DS рішення? Якщо даних дуже мало, можливо, спочатку потрібно налаштувати збір даних.
  • Чи готові ми технічно до використання ML-моделі? Бувають випадки, коли ML-модель принесла вигоду бізнесу, для запуску моделі достатньо даних, але технічна інфраструктура потребує змін, щоб інтегрувати результати моделі у процес прийняття рішень.

Якщо відповідь на усі питання позитивна — можна переходити до наступних етапів.

Приклад з історії thredUP

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

Після обговорення задачі командами, ми вирішили, що:

  • Для вирішення бізнес-задачі оптимальним буде прогноз конверсії користувача одразу після реєстрації. Це дасть змогу порівняти кампанії між собою через декілька днів.
  • Якщо у нас буде ймовірність конверсії кожного користувача одразу після реєстрації, маркетингова команда порахує середню ймовірність конверсії користувачів через тиждень після запуску кампанії і використає цю інформацію для кращого розподілу маркетингового бюджету.
  • thredUP збирає багато різноманітних даних, що пов’язані з конверсією: звідки прийшов користувач, чи підписався він на емейл-розсилку, як часто він заходить на сайт, які сторінки на сайті дивився після реєстрації і т. п.
  • Ми можемо розраховувати ймовірність конверсії для користувачів декілька разів на день у butch-режимі, завантажувати дані у DataWarehouse і завантажувати у BI tool, яким користуються менеджери маркетингових каналів

Prototype

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

Data extraction

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

  1. Оцінити, які є дані. Зокрема, зрозуміти, чи достатньо історичних даних для побудови цільової змінної.
  2. Розбити дані на декілька груп залежно від доступності і необхідності попередньої обробки перед використанням. Наприклад, в першу чергу варто подивитися на дані, які не потребують попередньої обробки перед використанням в моделі і можуть бути отримані швидко. Із таких даних можна побудувати першу версію датасету. Далі потрібно виділити групу даних, що потребує посередніх зусиль і часу для обробки. Залежно від корисності та об’єму даних з початкової групи, працювати з ними одразу або відкласти на наступну ітерацію. Дані, які складно дістати, або потрібно довго чистити чи агрегувати, варто відкласти до наступних ітерацій.
  3. Побудувати першу версії датасету, на основі якої можна будувати модель.

Приклад з історії thredUP

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

MVP

Найцікавіший момент для кожного Data Scientist — створення першої версії моделі. Проте, перш ніж переходити до найбільш інтригуючого моменту, варто не пропустити кілька критично важливих кроків.

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

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

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

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

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

Приклад з історії thredUP

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

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

Також стратифікували дані, оскільки об’єм даних був великий. Для побудови моделі обрали Random Forest, бо він дає гарні результати для структурованих даних з середньою кількістю фіч (100-150).

Перші результати моделювання показали непогану точність і ми взяли цю модель як MVP для подальшої роботи

Валідація моделі

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

Для додаткової перевірки моделі колегами, можна поширити прототип моделі через git або у ноутбуці через Databricks або Google Colab.

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

Приклад з історії thredUP

На момент створення моделі ми працювали переважно в Jupyter, тому попросили колег переглянути ноутбуки з прототипом у git.

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

На прохання Facebook channel-менеджерки ми порахували скори моделі для підгрупи клієнтів, що зареєструвалися кілька місяців тому. Вона оцінила, які рішення можна було прийняти на основі даних моделі, і наскільки правильними були би ці рішення

Деплоймент нової моделі

Якщо етап валідації пройдено вдало, час вирішувати питання деплойменту. Тут є декілька важливих питань.

  • Наскільки часто потрібно оновлювати прогноз моделі? Від відповіді на це питання залежить вибір механізму деплою.
    • Якщо дані потрібні в реальному часі, потрібно буде створювати мікросервіс.
    • Якщо дані достатньо оновлювати декілька разів на день або рідше, можна зробити батчеву імплементацію, коли модель буде запускатися, збирати необхідні дані, рахувати прогноз і складати отримані дані у заздалегідь узгоджене місце (Data Lake, Database etc).
  • Чи потрібно автоматично перетреновувати модель? Якщо так, тоді потрібно одразу створити окремий процес для тренування моделі.

Приклад з історії thredUP

Нам достатньо було оновлювати прогнози моделі раз на день, оскільки рішення приймалися декілька разів на тиждень. Ми створили Python-джобу в Airflow, що кожен день рахувала ймовірність конверсії для всіх клієнтів, що зареєструвалися менше 60 днів тому. Результати роботи джоби записувались у Redshift, а звідти були доступні у Looker для усіх бізнес користувачів

Впровадження зворотного зв’язку

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

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

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

Приклад з історії thredUP

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

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

Типи Data Science-проєктів із різними життєвими циклами

Загальний або типовий проєкт

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

Інші приклади загальних (типових) проєктів — прогноз churn користувача, прогноз дефолту за споживацьким кредитом.

Діагностика даних

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

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

Діагностика даних, пов’язаних з використанням текстового пошуку:

  • Перевірити:
    • чи збирається інформація про те, як користувачі застосовують текстовий пошук на сайті;
    • чи можемо ми реконструювати, який текст писав клієнт;
    • на які пропозиції пошуку клієнт клікав;
    • яким був перелік можливих пропозицій;
    • яких даних не вистачає;
  • Організувати співпрацю з front-end командою, щоб зібрати потрібні дані. Перевірити, чи нові дані збираються коректно.

Діагностика даних, пов’язаних з виплатами за кредитом:

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

Exploratory Data Analysis (EDA)

Дуже поширений тип проєкту, який також може існувати як частина типового Data Science-проєкту. Зазвичай EDA-проєкт виконується на прохання бізнес-стейкхолдерів і його головною мета — отримання інсайтів про певну частину бізнесу. Результати проєкту використовуються для прийняття бізнес-рішень, зокрема про тактику розвитку продукту. EDA-проєкти часто мають декілька ітерацій.

Наприклад, проаналізувати, на якому кроці реєстрації у системі найчастіше виникають проблеми. В ідеалі — зрозуміти, яку дію виконують користувачі (який крок анкети викликає найбільше затримок і т. д.). На основі результатів аналізу Product Manager може вирішити прибрати проблемні пункти анкети або повністю змінити процес реєстрації.

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

Reporting (Data Visualization)

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

Часто задача Data Scientist полягає не тільки у побудові звіту, а й у його «дизайні», коли потрібно зрозуміти, які метрики найкраще описують процес. Проєкти з побудови звітів тривалі і зазвичай мають багато ітерацій.

Приклади:

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

A/B test analysis

Last but not least. Цей тип проєкту надзвичайно потрібний при запуску нових фіч. Він може бути частиною типового проєкту, коли перед використанням нової моделі спочатку запускають тестування, щоб підтвердити ефективність моделі. Data Scientists можуть бути задіяні на різних етапах, починаючи від дизайну самого тесту і закінчуючи, власне, аналізом. Ключова роль Data Scientist — визначити, був тест успішними чи ні. При цьому участь у тестуванні може мати різні напрямки:

  • суто формальний аналіз, коли збір ключових KPIs для оцінки тесту автоматизовано і потрібно просто переглянути результати і підтвердити/порахувати статистичну значущість тесту;
  • збір і обробка даних, коли потрібно повністю розібратися з даними, перевірити коректність розбиття на підвибірки, побудувати важливі метрики;
  • дизайн тесту, коли Data Scientist пропонує тест на основі результатів EDA;
  • всебічний аналіз результатів тесту, коли потрібно не просто формально переглянути результати, а зрозуміти нюанси роботи тесту для різних сегментів клієнта. Залежно від того, наскільки досконала продуктова аналітика в компанії, може будуватися як у спеціальних інструментах аналізу, так і «з нуля».

Досить часто A/B тести мають декілька ітерацій, коли за результатами першого тесту планується наступний. Зазвичай циклом подібних проєктів займаєтсья один і той же Data Scientist.

Приклади:

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

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

Висновки

Усі Data Science-проєкти мають спільні риси, що відрізняють їх від інших software-проєктів:

  • Дані як фундамент. Кожен тип Data Science-проєкту включає декілька ітерацій інтенсивної роботи з даними. Чим краще Data Scientist знайомий з даними, тим швидше і легше проходять ітерації проєкту.
  • Інтеграція у реальні системи. У більшості комерційних компаній результати роботи Data Science-команди потрібно інтергувати у системи компанії і знадобиться тісна співпраця з software engineers.
  • Експерименти та ітерації. Більшість Data Science-проєктів потребують декількох ітерацій, що пов’язано з заглибленням у задачу і дані, а також з отриманням зворотного зв’язку про роботу моделі.

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

Корисні посилання

  1. Effective Data Science Infrastructure. MEAP began May 2021.
  2. What is a Data Science Life Cycle?
  3. Introduction to Life Cycle of Data Science projects (Beginner Friendly)
👍ПодобаєтьсяСподобалось14
До обраногоВ обраному3
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

Цікавий огляд.
Як ви вчите команду (новачків) що долучаються до таких проектів?

Дякую за Вашу увагу і відгук!

Цікава стаття та актуальна.
Особливо тішить, шо стаття написана державною мовою.
Добра робота. Пишіть ще!

Та йди звідси зі своїм мовнюковим срачем. Інгліш мазафака — ду ю спік іт? Хоча б статтю прочитав

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