Привет, Хабр!

С момент публикации серии статей на тему анализа данных и машинного обучения прошло уже достаточно времени и люди начинают просить новых публикаций. За последний год мне удалось поработать с несколькими компаниями, планирующих внедрять у себя инструменты продвинутой аналитики на предмет подбора специалистов, а также обучения их сотрудников и решения проектных задач. Для меня это был довольно необычный и одновременно сложный опыт, поэтому этот пост хотелось бы адресовать руководителям компаний, планирующих внедрять инструменты 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, потому как cost per acquisition почти всегда высока — проще говоря, легче зарабатывать на тех пользователях, которые уже платят своим хоть и не большим LTV, чем привлекать новых. Так вот, возвращаясь к задаче: пользователей несколько миллионов, вся информация о них в данный момент находится в реляционных хранилищах. Перед руководителем подразделения, отвечающего за данный проект было поручено рассчитать бюджет. Деньги оказались не такие большие для компании, но совершенно фантастические для данного проекта. Предполагалось (почти дословно цитирую) «закупить несколько машин», «организовать на них Hadoop-кластер», «организовать перенос данных в кластер», «поставить коммерческое ПО для больших данных, чтобы оно могло работать с данными на кластере» и (не уточнено как) «построить прогнозную систему».

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

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

Компании все еще боятся «искусственного интеллекта»

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

Нет единого понятийного аппарата

Т.к. большинство задач современной аналитики подразумевает применение методов машинного обучения, то важно понимать метрики качества получающихся алгоритмов, потому что именно они зачастую влияют на бизнес-кейс, т.е. на то самое value, которое компания хочет извлечь. И тут руководителю проекта нужно будет потрудиться (опять же — далеко не во всех компаниях), чтобы объяснить финансистам, проектным менеджерам или вышестоящему руководству доступным языком такие вещи как «ошибка первого/второго рода», «полнота», «точность» и др., а также учесть, что люди из предметной области, в которой находится задача, оперируют другими понятиями при решении аналогичных задач. Поэтому важно также знать, что такое «лифт», «охват» и другие понятия, характерные для предметной области (см. пункт 2 выше)

Конечно, это относится не ко всем компаниям. Во многих, в особенности в интернет-компаниях, культура работы с данными хорошо развита, все друг друга понимают и внедрять решение гораздо проще.

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

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

Всем успехов!

P. S. К сожалению, т.к. времени на все совершенно не хватает, наверное, я больше не смогу достаточно писать на хабре о том, чем можно поделиться. Оставлю голосовалку