Big Data: поточна реальність

Привіт, хабр!

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

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

Важливо розуміти можливості і обмеженість застосування Big Data аналітики
Дуже часто розмова починається приблизно так: «Хочемо прогнозувати X за нашими даними Y з точністю не менше Z», де X і Y майже ніяк не корелюють, а Z така, що можна сказати «зуб даю».

Наприклад, нещодавно до мене звернувся один з керівників IT досить великої ритейлової мережі. Завдання звучала приблизно так: "Є показники ефективності (порядку декількох сотень) регіональних магазинів (кілька десятків) за 2 роки (тобто 2 таблиці). Потрібно передбачити ці ж показники за третій рік (тобто знову таблицю)". Будь-який фахівець знає — що це типова задача прогнозування часових рядів і що з такими основними умовами і таким набором даних вона не вирішується.

Знову ж таки, люди, які знайомі з методами обробки природної мови (Natural Language Processing) скажуть, що на сьогоднішніх день, наприклад завдання класифікації текстів вирішуються в більшості випадків добре (просто кажучи, з малою часткою помилки), в той час як завдання типу «генерування умовиводів з набору пов'язаних між собою текстів» (приклад такої «Decision Support System» мені пропонували розробити для одного з фондів) на сьогоднішній момент практично не вирішуються в тому сенсі, що існуючі рішення абсолютно не продуктивні.

Тут хочеться відзначити, що Big Data — це не чарівна паличка, яка приймає на вхід «простирадло» (ще один термін, який часто доводиться чути в багатьох компаніях), що робить всередині і видає на виході що душі завгодно. У прогнозних завдання цільова змінна (target) передбачається, як правило, на основі набору ознак (features), який повинен бути вичерпним в плані впливу на цільову змінну. До речі, звідси ж постає і друге важливе спостереження:

У нішевих завдання простіше навчити існуючих фахівців, ніж знайти нових з ринку
У завданнях предиктивної аналітики одним з найважливіших етапів (фактично закладають перше обмеження на якість отриманих моделей) є підготовка і відбір ознак (feature engineering, feature selection, etc.). Простіше кажучи — набору оптимальних параметрів, які впливають на ту чи іншу цільову змінну. Цей набір ознак визначається саме предметною областю завдання, тому її знання є критичним для багатьох завдань.

Наприклад, нехай вирішується задача прогнозування відтоку клієнтів (для будь-якого сервісного бізнесу). Data Scientist, який почне вирішувати цю задачу, швидше за все, в якості ознак відтоку буде розглядати показники виду «кількість звернень на підтримку». Але будь-який фахівець, який розуміє предметну область, скаже Вам, що на відтік впливає не кількість звернень, а «наявність звернень X-го рівня за тематикою Y за останні Z днів». Додавання такого ознаки збільшує якість моделей «в рази», і не складно помітити, що придумати такий ознака може тільки людина, глибоко знайомий з предметної областю. Не кажучи вже про те, що саме поняття «відтік» визначити правильно може тільки людина, що знає це поняття не з чуток.

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

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

Часто не потрібен великий CAPEX
3 місяці тому один не дуже великий інтернет-сервіс вирішила будувати, знову ж таки, модель відтоку для своїх користувачів. Так, це, напевно, одна з перших завдань, яке починає вирішувати будь-сервісний бізнес, почувши назву Big Data. Воно й зрозуміло, бо майже всі сервіси працюють на retention, бо як acquisition cost per майже завжди висока — простіше кажучи, легше заробляти на тих користувачів, які вже платять своїм хоч і не великим LTV, ніж залучати нових. Так от, повертаючись до задачі: користувачів кілька мільйонів, вся інформація про них в даний момент знаходиться в реляційних сховищах. Перед керівником підрозділу, відповідального за даний проект було доручено розрахувати бюджет. Гроші виявилися не такі великі компанії, але абсолютно фантастичні для даного проекту. Передбачалося (майже дослівно цитую) «закупити кілька машин», «організувати на них Hadoop-кластер», «організувати перенесення даних в кластер», «поставити комерційне для великих даних, щоб воно могло працювати з даними на кластері» і (не уточнено) «побудувати прогнозну систему».

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

В цьому прикладі в результаті, виявилося, що модель відтоку, що задовольняє бізнес, можна було успішно побудувати на вже існуючих даних, що зберігаються в реляційних базах (практично не роблячи feature engineering — що знають мене зрозуміють). З інструментів знадобився Python з його бібліотеками, код якого запускається тепер кожен місяць, працює кілька годин, після чого вихідні дані «вивантажуються в excel» (це теж важливо, тому що цей інструмент бере участь у більшості бізнес-процесів компанії) і передаються в службу, планують кампанії по утриманню клієнтів. Рішення далеко не найкраще на сьогоднішній день, але воно повністю задовольняє замовників. До речі, треба розповісти, чому задовольняє:

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

Немає єдиного понятійного апарату
Оскільки більшість завдань сучасної аналітики передбачає застосування методів машинного навчання, то важливо розуміти метрики якості виходять алгоритмів, тому що саме вони найчастіше впливають на бізнес-кейс, тобто на те саме значення, яке компанія хоче отримати. І тут керівнику проекту потрібно буде попрацювати (знову ж — далеко не у всіх компаніях), щоб пояснити фінансистам, проектним менеджерам або вищестоящому керівництву доступним язиком такі речі як «помилка першого/другого роду», «повнота», «точність» і ін, а також врахувати, що люди з предметної області, в якій знаходиться завдання, оперують іншими поняттями при вирішенні аналогічних завдань. Тому важливо також знати, що таке «ліфт», «охоплення» і інші поняття, характерні для предметної області (див. пункт 2 вище)

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

Це одні з найпоширеніших речей, з якими доводиться зустрічатися людині, яка займається розробкою прогнозних аналітичних інструментів (що часто також називається модним словом Big Data). Цією статтею я хотів показати, що окрім відомого твердження «90% роботи Data Scientist'а складається з підготовки та очищення даних», на практиці частіше виявляється набагато важче пройти весь шлях від ідеї до кінцевого продуктивного рішення, а найскладніша ділянка починається і закінчується далеко не на очищення даних.

Саме тому часто важливіше знаходити спільну мову з людьми, маючи побудоване за спиною дерево рішень (Decision Tree), ніж градієнтний бустинг або RandomForest, який на пальцях не пояснити.

Всім успіхів!

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

/>
/>


<input type=«radio» id=«vv66973»
class=«radio js-field-data»
name=«variant[]»
value=«66973» />
Серія постів про аналіз соціальних мереж (багато складної математики)
<input type=«radio» id=«vv66975»
class=«radio js-field-data»
name=«variant[]»
value=«66975» />
Про практичні навички, які можуть бути корисні на роботі
<input type=«radio» id=«vv66977»
class=«radio js-field-data»
name=«variant[]»
value=«66977» />
Пости про машинне навчання
<input type=«radio» id=«vv66979»
class=«radio js-field-data»
name=«variant[]»
value=«66979» />
Про підготовку фахівців
<input type=«radio» id=«vv66981»
class=«radio js-field-data»
name=«variant[]»
value=«66981» />
Тільки найважливіше

Проголосувало 70 осіб. Утрималося 11 осіб.


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


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.