Як пояснити результати моделі?

Однією з частих вимог бізнесу до моделей машинного навчання є пояснюваність.
Чому це важливо? Якщо ви запитаєте у лікаря чому діагноз саме такий, він розповість, який симптом “призвів” до цього діагнозу (наприклад специфічний висип та висока температура), однак моделі машинного навчання це здебільшого чорна скринька, яка просто видає діагноз (або його ймовірність). При розмові з представниками бізнесу результат такої чорної скриньки може викликати певну недовіру. Тому під час останнього проекту для великого європейського сайту оголошень довелося розбиратись з різними варіантами пояснюваності моделей.

Отже, розрізняють “глобальну” та “локальну” пояснюваність. “Глобальна” пояснюваність — ви можете пояснити, правила за якими модель “приймає рішення”. Ці правила однакові для всіх випадків (наприклад, ваги у лінійних моделях). Раніше доводилося обирати між точністю моделей та їх глобальною пояснюваністю.

Розрізняють "глобальну" та "локальну" пояснюваність. "Глобальна" пояснюваність - ви можете пояснити, правила за якими модель "приймає рішення". Ці правила однакові для всіх випадків (наприклад, ваги у лінійних моделях). "Локальна пояснюваність" - пояснює вагу ознак для окремих точок і зазвичай передбачає побудову додаткової моделі в цих точках. Ось приклад з з статті: "Why Should I Trust You?": Explaining the Predictions of Any Classifier (Ribeiro, Singh, and Guestrin 2016) де було запропоновано LIME(Locally Interpretable Model-Agnostic Explanations).

Наприклад, якщо ви застосували алгоритм для визначення об'єктів на фото і отримали результати: "електрогітара", "акустична гітара" та "лабрадор", то візуалізовані "ознаки, які відповідають за результат" виглядають так:

Або якщо ви натренуєте класифікатор "позитивний - негативний" відгук та візуалізуєте слова, які приводять до такого результату:

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

Full stack data science і GCP

Сьогоднішній пост буде про специфіку роботи  data scientist в  бізнес (не research) проектах.

 Часто бізнесу потрібно мати просто хороше рішення сьогодні, а не ідеальне післязавтра. Але при цьому це “сьогоднішнє рішення” має бути достатньо якісним (щоб отримати шанс бути покращеним в майбутньому).

Згідно стандарту CRISP-DM виділяють такі етапи data science процесу:

• Business Understanding - розуміння бізенс проблеми та можливих шляхів її вирішення
• Data Understanding - розуміння які дані допоможуть вирішити цю проблему і де їх взяти
• Data Preparation - підготовка даних (налаштування ETL, очищення, збагачення)
• Modeling - підбір моделей та алгоритмів, які найкраще підходят для вирішення задачі
• Evaluation - перевірка моделі, основне питання - "Чи вирішує наша модель бізнес задачу?"
• Results communication - представлення результатів дослідження в зрозумілій всім учасникам формі.
• Deployment - розгортання моделі для подальшого використання.

В ідеалі цим займається команда, яка включає:
Data Scientist (або Data Analyst + Machine Learning Engineer)- моделювання, підготовка даних, підготовка звітів/комунікація результатів.
Data Engineer - підготовка даних, підготовка до розгортання;
Business Analyst - комунікація з бізнесом,
DevOps - розгортання.

Часто кожен з цих спеціалістів має вузьку спеціалізацію із специфічним набором скілів. Часом у спеціаліста нема бажання виходити за межі власної зони відповідальності. Часом у бізнесу нема ресурсів/бажання платити за таку кількість (часто дорогих) спеціалістів, оплачувати  оверхед по неохідному комунікуванню між ними, налогоджування/контролю процесу взаємодії в команді. Та й побудова команди, де всі будуть доповнювати один одного задача не з легких. Подібні проблеми не нові і у споріднених  галузях. Наприклад, у software development одним із способів вирішити проблеми такого типу є спеціалізація full stack developer (а також практики DevOps). По аналогії,  такого "спеціаліста на всі руки" можна назвати full stack datas cientist.

Під full stack data scientist будемо далі розуміти людину, яка:

• спілкується з замовником, визначає вимоги до проекту, критерії успішності
• будує pipeline збору та підготовки даних до моделювання
• підбирає найкращий алгоритм
• робить валідацію результатів (з точки зору бізнесу)
• готує/презентує результати дослідження
• розгортає модель (як мінімум на етапах POC та MVP)

Тепер про інструменти.

Раніше, як і більшість моїх колег, використовувала такий стек:

Препроцесінг/підготовка даних - R/Python/Spark або спеціалізоване рішення типу Trifacta.

При цьому дані зберігаються локально або в базі даних (в 90% це SQL бази).

Побудова моделі - R /Python/Spark/TensorFlow

Тут швидкість обробки та кількість даних, які можна обробити залежать від локальної машини/сервера. Швидкість тренування моделей теж. 

Комунікація результатів:

Може бути статичною або інтерактивною.
Набір інструментів:

• PowerPoint/Google Slides
• R(Shiny), Python (matplotlib/seaborn)
• Tableau
• JavaScript (d3.js)

Deployment:

• веб додаток з використанням R Shiny (якщо потрібне візуальне представлення результатів роботи моделі)
• веб додаток з використанням Python/Flask (якщо в результаті маємо сервіс, який видає результати через API)

Виглядає непогано, однак треба вирішувати багато питань, які мало відносяться до data science:

• вимоги до заліза
• розробка/тестування веб додатку (frontend, backend, tests)
• налаштування середовища (VM, Docker container, локально, в хмарі? )
• розгортання додатку (Vagrant, Ansible?)
• моніторінг
• підтримка 
• scaling (коли, як, хто?)

Тобто, впроваджуючи ваше рішення ви frontend розробник, backend розробник, тестувальник, devops інженер. Це забирає дуже багато часу та зусиль, оскільки всі інструменти змінюються.

Крім того,  світ data science теж змінюється (Вжух, і всюди XGBoost).

Чи є інший шлях?

Для себе використовую Google Cloud Platform інфраструктуру.

Як це працює:

Поточні дані збираються з допомогою GoogleAnalytics (оскільки це веб-сайт + мобільні додатки це природній та найбільш простий спосіб отримати дані) та кількох ETL і потрапляють в BigQuery. Це DWH, який дозволяє супер швидке виконання SQL запитів на великих об'ємах даних. Там  роблю і первинне дослідження даних. Середовище налаштовувати не потрібно. При цьому запит, який обробляє 67 GB виконується за 40 секунд.
Додатковий плюс:  не маємо звичної проблеми, коли аналітичні квері сповільнюють роботу SQL продакшен бази.

Вивчення даних та тестування гіпотез роблю з допомогою в Datalab. Це побудований на основі Jupyter notebook,  дозволяє звертатись до BigQuery/Google Storage/ML Engine, а також використовувати python та  його бібліотеки (pandas, scikit-learn, seaboarn).

Будувати візуалізації можна як з використанням python бібліотек, так і з використанням Google Charts API.  Для запуску достатньо команди
datalab create datalab-vm -- machine-type "machine type"
яка автоматично стартує машину вказаного типу та встановить з'єднання з цією машиною з вашого локального комп'ютера.

Для тренування та збереження моделей  використовую Google ML Engine. ML Engine використовує Tensor Flow.  Весною 2017 з'явилась можливість тренування на GPU.

Основна переваги GCP для мене:
Big Query:

• швидка обробка великого об'єму даних
• зручна мова запитів

ML Engine:

• API для використання моделі готовий відразу після розгортання моделі. 
• Це serverless рішення, тобто ресурси для нього виділяються лише на час виклику. 
• Автоматично масштабується - ресурси виділяються пропорційно до викликів
• Можна викликати prediction у online (near real time) та batch форматах.
• Можна одночасно розгорнути кілька версій API

Datalab досить зручний, однак в принципі, може бути замінений Jupiter notebook з налаштуванням доступу то GCP сервісів через API.  Найбільше подобається можливість легкої зміни типу машини під задачу.

Крім того, Google Cloud Platform має ще кілька цікавих рішень:

• Cloud Dataprep - препроцесінг даних. На основі сервісу Trifacta. Мала невеликий досвід використання Trifacta - тоді були проблеми якраз з Ops частиною.
• Dataproc - дозволяє підняти кластер з Hadoop, Spark, Hive, Pig, etc
• Dataflow - можна використовувати для побудови ETL.
• Pub/Sub - message flow
• Google Data Studio - для побудови дешбордів.
• Cloud Functions - serverless середовище для виконання функцій

Отже, що ми отримали в результаті:

• frontend/backend development, DevOps та Ops зкоротилися до мінімуму - нарешті data scientist може займатися своєю роботою (юххху!)
• платимо лише за використані ресурси (запити до апі, час тренування, місце) і не оплачуємо неефективний час роботи віртуальної машини або докер контейнера
• ми можемо вибрати (і оплатити) для реалізації проекту лише реально необхідну кількість ресурсів
• маємо розумний варіант для масштабування (по часу і вартості)
• продакшен рішення представлені у вигляді добре задокументованих і відомих у галузі API.

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

В серпні на DataFest в Києві планую розповісти детальніше та показати на прикладах, як це працює.

Перша спеціалізація, яка мала бізнес спрямування, а не технічне.
Особливо було морально тяжко, коли demand на наступний рік вираховували з допомогою одного евристичного правила, а не оці ваші time-series :)

Не такі страшні перших 80% створення онлайн курсу, як останніх 80%

Станом на сьогодні на курс "Аналіз даних та статистичне виведення на мові R"  на Prometheus записалося вже 10032 слухачі (~ 2000 після закінчення активної фази курсу) і нарешті є час описати процес створення курсу.

Наприкінці 2015 зі мною сконтактував Олексій Молчановський і запропонував зробити курс з статистики. Ми домовились про наступні кроки: в січні базовий перелік тем, в лютому детальний, весна - розробка лекцій і запис лекцій. Літо - лабораторні роботи та тести. Виглядало цілком поєднуваним з сім"єю та роботою.

Що хотілося досягнути?

• Показати практичне застосування статистики
• Дати початкові знання та показати, де можна вивчати статистику крім українських вузів
• Зробити внесок в українську освіту :)

Початковий план виглядав так:

План та матеріали третього тижня допомагала робити Олена Медвєдєва.  Однак, з кінця квітня в гру вступила реальність. Практично подальша підготовка курсу тривала до релізу.
На початок травня були презентації по трьох лекціях. Які дуже відрізнялись від теперішніх :) Далі ми почали узгоджувати та планувати запис. Фактично розробка презентацій останніх тижнів + різні варіанти запису (в студії, скрінкасти)  + покращення існуючих тривали майже все літо.

Лише запис скрінкастів прийнятної (не ідеальної) якості тривав більше місяця (запис щодня по дві години).
Як ви могли помітити, Prometheus ставить на меті робити курси кращої якості ніж edX та Coursera, що вимагає від автора більше зусиль. В останній тиждень перед запуском я зрозуміла, що треба робити детальні конспекти (початковий план включав лише основні формули). Конспект + завдання лабораторної роботи – це 20-30 сторінок тексту щотижня. Не дивлячись на те, що це вимагало значно більше часу, вважаю що дуже покращило курс.
Після запуску курсу та першого тижня, стало зрозуміло, що серед слухачів є люди з зовсім іншим способом мислення, які розуміють завдання інакше. Тому завдання наступних тижнів допомагали тестувати Олена Мєдведєва, Таня Кодлюк, Олег Суховірський та Саша Руппельт. Саша ще допомагав з підтримкою форуму. Відповіді на форумі, навіть з моїм кількарічним досвідом роботи в саппорті, були найбільш тяжким випробуванням :) Тут морально допомагала моя сім'я.

Трохи статистики:

• станом на сьогодні 10032 зареєстровані слухачі
• більше 80% мають ступінь бакалавра або вище
• відсоток тих, хто отримав сертифікат 7.42% (середній відсоток закінчення для Coursera, EdX, Udacity ~ 2%)
• середній вік слухачів 29 років
• загалом від моменту домовленості про створення курсу до завершення активної фази пройшло 11 місяців
• протягом цього року було змінено три роботи :)

Висновки та поради тим,  хто думає над створенням свого курсу:

Цільова аудиторія: при створенні курсу вважала, що цільова аудиторія це студенти ВУЗів. Насправді 80% слухачів вже мало вищу освітою (також серед слухачів були й викладачі ВУЗів, які хотіли закрити для себе питання застосування статистики).
Різниця між "живим" виступом і онлайн-курсом: при "живому" виступу є фідбек від аудиторії і є можливість на це зреагувати та щось на ходу змінити, в онлайн-відео все зразу має бути ідеально.
Оцінка часу: час підготовки однієї хорошої презентації на кількість тижнів курсу. Запис відео - як мінімум, стільки ж (реалістичніше 2x)

Деталі: конспекти, лабораторні, тести. Приблизно половина часу підготовки презентацій. Вимагають тестування.
Тестування: - хороший варіант прочитати курс кілька разів для невеликих груп перед запуском.
Команда: можливо кращий варіант розділити курс на окремі частини між кількома особами. Це можуть бути модулі або підготовка однотипного матеріалу(презентації, озвучення презентацій, конспекти, завдання і т. д.). Однак, тут треба зводити все до спільного знаменника та координувати роботу всіх залучених.

Data Science в Нідерландах

Під час відпустки сходили на зустріч PyData Amsterdam. Зустріч відбувалася в офісі GoDataDriven(який є частиною компанії Xebia). Сама локація знаходиться в іншому для мене Амстердамі - з широкими магістралями та великими технологічними будівлями.

В офісі - скельний тренажер:

А тепер про сам мітап. Говорили про Deep Learning для NLP.

Maarten Versteegh з команії Textkernel займається нормалізацією резюме з використанням deep learning.  Його доповідь містила загальний короткий огляд deep learning. Наприкінці був набір практичних порад з імплементації: як проводити початкову ініціалізацію ваги, робити нормалізацію і т д. Загалом, нічого нового: convolutional networks з використанням keras (на прикладі Newsgroup Dataset)

Друга доповідь Privacy laws and machine learning @ ING від Kees van der Fliert з банку ING була про практичну проблему підготовки даних для аналізу. Суть проблеми: вибірка транзакцій для аналізу може містити дані приватних осіб. Якщо фізичну особу можна з мінімальними зусиллями ідентифікувати, то це може призвести до судових позовів. Тому дані фізосіб мають вилучатись на етапі формування вибірки. Якщо ці особи не є клієнтами банку, то не вистачає інформації, щоб розрізнити фізичних та юридичних осіб. Класифікатор будується на основі тексту транзакції, який містить назву юридичної/фізичної особи.

 Доповідачі в Україні відпрацьовують всі деталі дуже ретельніше і стараються зробити вау-доповідь. За рахунок цього data science зустрічі у Львові відбуваються досить рідко, бо на підготовку вау-доповіді треба витрати багато часу та зусиль. В Амстердамі це виглядало більше як зустріч data science комюніті з піцою та пивом + доповіді для обговорення. Це трохи відбивається на доповідях - на базовому рівні до аудиторії доноситься суть проблеми та пропоновані шляхи вирішення. Можливо, деякі деталі можна було б допрацювати, але сама ідея цілком зрозуміла.

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

Morning@Lohika: Introduction to Data Science

В суботу, 16 січня говорили про data science і як з цим жити. Слайди:

Introduction to Data Science from Anastasiia Kornilova

А також досліджували злочинність у Сан-Франциско і визначали найбільш небезпечні місця. Код тут.

Аналізуємо статті з NIPS 2015

На kaggle запустили змагання для аналізу статтей з конференції NIPS 2015 (Neural Infromation Processing Systems). NIPS це одна з найбільших конференцій з machine learning.