10 причин, за якими ваш дата-проект провалиться

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

Повна версія зі слайдами і поясняющим текстом є тут. Слайди є також окремо в ПДФ-файл.

Є також деяке обговорення на Hacker News.

Спочатку декілька слів про мене:
Керував групами спеціалістів з теорії і методів аналізу даних в двох стартапів у Лондоні.
Розроблені продукти використовуються компаніями Time Inc, Staples, John Lewis, Top Shop, Conde Nast, New York Times, Buzzfeed і т. д.


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

Давайте розглянемо причини.

1. Ваші дані не готові
Якщо дані знаходяться в базі даних, то їх можна використовувати, правильно?
Але можна припустити, що це просто сміття, якщо їх не використовували раніше.
Перевіряйте дані.
Вельми мудрий консультант по обробці даних сказав мені, що він завжди запитує, чи використовувалися раніше дані в якому-небудь проекті. Якщо ні, то він додає 6-12 місяців на роботи з очищення даних.

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

2. Нерідко чути: «Обробка даних — це нова нафта»
Але це не так. Дані не є товаром; вони повинні бути перетворені в деякий продукт, перш ніж придбають якусь цінність. Багато співрозмовників розповідали мені про проекти, які запускалися без якого-небудь уявлення, хто буде їх користувачем або як використовувати їх «цінні дані». Відповідь приходив, як правило, занадто пізно: «ніхто» і «ніяк».

3. Ваші фахівці по роботі з даними подумують про відхід
image
Могли б ви надіслати мені робоче завдання?
Що ви розробляєте в даний час?
Взагалі-то, я тільки що отримав доступ до R і Python! Буквально 5 хвилин тому.


Не створюйте проблем вашим фахівцям, не надаючи їм доступу до даних і інструментів, необхідним для нормальної роботи. Старшому науковому співробітникові з листування вище знадобилося шість тижнів на отримання дозволу встановити Python і R. Він був щасливий!

На жаль, щастя було недовгим:
image
Ви, мабуть, жартуєте…
Ось воно.

Ця програма заблокована вимогам групової політики. За додатковою інформацією зверніться до вашого системного адміністратора.


Тепер дозвольте представити цього хлопця:
image

Він був менеджером по продукту на сайті інтернет-аукціону, про який ви, можливо, чули. Його розповідь була про A/B-тесті нового алгоритму прототипу для головної пошукової машини продуктів. Тест був успішним, і новий алгоритм пішов у справу.

На жаль, після того як пройшло багато часу і було витрачено багато грошей, з'ясувалося, що в коді A/B-тесту була помилка: прототип не був використаний. Вони випадково перевірили старий алгоритм на власних даних. Результати виявилися безглуздими.

Це була проблема:
Ви не будете знати, що результати являють собою сміття.
Помилка вибірки, зміщення вимірювання, парадокс Сімпсона, статистична значимість і т. д.
НДДКР — непроста справа
4. У вас немає фахівця-лідера по обробці даних
Вам потрібні люди, які живуть і дихають помилкою вибірки, зміщенням вимірювання і подібними речами — або ви ніколи не дізнаєтеся, що ваші результати не мають сенсу. Таких людей називають «вченими».

Так, до речі.

Ця людина не є ні «вченим», ні фахівцем по обробці даних:

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

А цього фахівця по обробці даних можна вважати «вченим»:

«Спеціалізація: ймовірнісне програмування, аналіз даних, байесовское моделювання, приховані Марківські моделі, методи Монте-Карло з ланцюгами Маркова (MCMC), рекурентні нейронні мережі (LSTM), багатозадачне навчання, доменна адаптація.»

Також протилежне твердження дуже часто є вірним:

5. Ви не повинні були наймати вчених*
*Див. пункт 3.
Для технології ETL (витягання, перетворення і завантаження даних) наймайте фахівців з інженерії даних.
Для створення звітів наймайте фахівців з засобів бізнес-аналітики (BI).
Кінець.
6. Ваш бос читає публікації в блозі по машинному навчання
Галас навколо машинного навчання означає, що там є багато легкодоступного контенту. Це може привести до явища, яке можна було б назвати «скоростиглий експерт»: тепер кожен має великі ідеї по машинного навчання. Симптомом є використання таких словосполучень як, наприклад, «усунення расходимости» або «ансамблевий метод» у невідповідному контексті. Повірте мені, подібне добре не кінчається.

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

Розроблена нейронна мережа мала дуже високу точність, але вона, як не дивно, завжди відправляла астматиків додому. Це було незрозуміло, так як у астматиків насправді ризик ускладнень від пневмонії досить високий.

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

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

8. Ваші результати не відтворюються
Git;
Аналіз коду;
Автоматичне тестування;
Забезпечення взаємодії при конвеєрній обробці даних.
Основою будь-якої науки є відтворюваність результатів. Робіть все з зазначеного. І не кажіть потім, що я не попереджав вас.

9. Лабораторія, що займається НИОКРом, чужа корпоративній культурі вашої компанії.
Люди воліють інтуїцію.
НДДКР є областю діяльності з високим ризиком.
Зустрічі в лабораторії, переговори, публікації статей і т. д.
Лабораторія, що займається прикладною наукою, накладає серйозні зобов'язання на компанію. Точні дані часто можуть бути дуже небезпечними для людей, які воліють довіряти своїй інтуїції. НДДКР несе в собі високий ризик невдачі і вимагає — необхідне, але все ж недостатня умова для успіху — незвично високого рівня завзятості. Чесно запитайте себе — ваша компанія, дійсно, приймає таку культуру?

10. Розробка інформаційних продуктів без опори на реальні дані рівносильна заняття таксидермией без спостереження за живими тваринами.
При підготовці будь-якого інформаційного продукту (навіть деякого макета) категорично не допускається розроблення взаємодії з користувачем і робота менеджерів по продуктах з використанням неподлинных даних. Як тільки на макеті будуть використані реальні дані, може виявитися, що він є повною фантазією.

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

0 коментарів

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