Data Science в реальной жизни: никакой абстракции, только практика

­­­Data Science в реальной жизни Мы много смотрели на разницу ожиданий работодателей, которым требуются Data Scientist'ы, и самих ученых по анализу данных — и решили написать на эту тему статью. Получается, что основная польза от ученых по анализу данных не в самом анализе данных. Компания, инвестируя в новые разработки, в первую очередь ждет возврат на инвестиции, а не очередную модель. Специалист же, окончивший всевозможные курсы, ждет на входе чистые и понятные данные, и на выходе хотел бы отдать модель, прикрепив к ней метрики качества. А дальше «пусть менеджеры разбираются», как полученную модель встроить в процесс и использовать. В результате возникает непонимание между бизнесом и учеными. В реальности оказывается, что модели сами по себе никому не нужны, и приходится заниматься очень большим количеством рутинных задач. В этой статье хотелось бы на обобщенных примерах (все совпадения с реальной жизнью — случайны!) показать, какие трудности Data Scientist'у на самом деле приходится преодолевать, чтобы принести работодателю деньги. Наверное, после этого в аналитику данных люди будут идти более осознанно, попутно получая нужные для работы навыки, а не изучая очередную статью про алгоритм. Нужно понимать, что хочет бизнес Начнем с самого распространенного примера. Представьте, что вы закончили вуз, хорошо разбираетесь в машинном обучении, знаете, что такое xgboost, деревья решений и прочие непонятные нормальному человеку алгоритмы. Вы приходите работать в b2c-компанию (допустим, даже с большим «c» — где средний чек с клиента берется регулярно и на протяжении долгого периода времени), основной целью которой является, по сути, максимизация LTV. Это может быть тот же телеком-оператор. Наслушавшись рассказов на конференциях про свойства таких бизнесов («проще удержать старого клиента, чем привлечь нового», «важно управлять оттоком», «надо балансировать между лояльностью и увеличением ARPU»), вы ничуть не удивляетесь, когда вам предлагают улучшить или построить модель оттока. Ведь это важно — в таких компаниях лояльность (обычно измеряемая с помощью NPS или LT) стоит на первом месте. Все понимают, что это важно (но каждый понимает по-своему). Что происходит дальше? У вас в голове, разумеется, рисуется бинарная классификация. Вы уже мысленно расчехляете свой xgboost и ждете, когда на выходе будет та самая заветная таблица с ярко-выраженным отдельным столбцом (называемой вами целевой переменной) и метрика качества, по которой будут судить об успешности алгоритма (хотя метрику вы и сами, наверное, придумаете — из списка roc-auc, precision, recall и так далее). Но этого не происходит. Потому что даже непонятно, что такое отток. Вы только что закончили вуз, никогда не работали в операторе, для вас отток — «это когда клиенты перестают пользоваться услугами компании». Да, алгоритмы машинного обучения универсальны и могут решить любую задачу, но вот правильно ее сформулировать (а это и есть большая часть работы) могут только те, кто хотя бы немного понимает, как компании управляют оттоком. Например, автору этой заметки известны как минимум пара десятков (и их вариаций) определений оттока, но не известно, какое из них самое правильное. И это не известно никому. Качество и доступность данных важнее алгоритмов Допустим, с оттоком определились. А что такое клиент сотового оператора? Нормальному человеку понятно, что клиент — это клиент, и добавить нечего — что за дурацкий вопрос? Надо взять client_id и по нему выгрузить признаки. Но факт в том, что в компании уже N-ый год идет какой-нибудь большой проект под названием Customer Golden Record (или, как его еще называют, MDM), в котором до сих пор так и не определелились, что же считать клиентом. А считать можно много что — начиная от номера телефона, заканчивая номером приложения обслуживания или лицевого счета (на котором может обслуживаться несколько номеров). Но допустим, что вам и в этом случае повезло: в компании нашелся скромный сотрудник, который подсказал, что можно взять в качестве абонента — и вы можете смело броситься выгружать долгожданные features. И тут вы думаете, какие данные есть у оператора связи, влияющие на отток — идете читать статьи великих ученых, не находя в них конкретики. Потом идете спрашивать старших товарищей, которые стабильно выгружают данные из витрины «какого-нибудь оракла», а конкретно — берут вот эти столбцы, названия которых известны, но вот что они означают и как считаются — «вроде бы была где-то документация», это «вот когда вендор нам внедрял это все — осталась от него»... Не получив исчерпывающее понимание по фичам (а иначе бы вас не нанимали!) вы начинаете креативить. И тут обнаруживаете, что сложности начинаются даже на самых простых вещах. Например, вам очевидно, что на отток влиет такой известный показатель как ARPU (примерно равно среднему чеку). Вы снова идете к старшим товарищам, чтобы разузнать, где его можно взять — а оказывается, что есть платежи (то, что заплатил клиент), а есть начисления (то, что начислил биллинг). В теории, конечно, же эти две величины должны быть очень похожи, но только в теории. Понятно, что платежи — более показательный параметр, но происходят они редко. А вот начисления генерятся практически «налету» после каждой транзакции. И, скорее всего, придется именно их и брать в качестве фичи и именно по ним считать оценку APRU. Понятно, что с фичами рано или поздно вы разберетесь (скорее, правда, коллеги подскажут). А еще поймете: для того, чтобы их сделать, нужно поработать лет 5-7 в CRM того же оператора — тогда открывается их реальный смысл и методика подсчета. Модель бизнес не улучшит! Так вот, с фичами разобрались. Выгрузили (скорее всего, не своими руками). А дальше можно (или нет?) вздохнуть, потому что теперь-то есть та самая заветная таблица. Тут вы, как обычно, строите (часто — нет) графики, смотрите на зависимости, тренируете модель, получаете огромные рок-ауки, реколлы, пресижны и прочие числа — и сообщаете руководству. «Качество получилось 100500%», «технологии машинлернинга работают», сейчас, мол, мы передадим джупайтер-тетрадку нашим разработчикам — пускай переписывают это все «в продакшн» и все. Но не так все просто. Потому что сделали мы вовсе не то, что просили. Нас просили повысить эффективность управления оттоком, а не сделать джупайтер-тетрадку. На что читатель возразит: ну так че — предсказываем людей, которые наиболее вероятно уйдут в отток, берем самых нелояльных — предлагаем им че-нибудь и все, вот и удержали. Так-то схема простая, но, как говорится, есть нюансы. И именно дальнейшие рассуждения и действия нужны компаниям, а не натренированная модель, которая еще (как потом наверняка окажется) задачу не решает. Внедрение модели может затянуться на годы Теперь работа только начинается. Например, в схеме, описанной выше («берем наиболее нелояльных, и их удерживаем», логика отличная для нормального человека, работающего в найме (то есть не теряющего свои деньги). Но любой, кто хоть раз вел бизнес с большим количеством потенциальных клиентов, из которых можно выбирать, скажет вам одно — «не все клиенты равны, и относиться к ним нужно соответственно». Да, есть клиенты, с которыми проще не работать. И тут к вам приходит понимание, что реально удерживать надо далеко не всех, а только самых ценных (на этом моменте обычно и говорят много слов про CLTV). А это означает, что целевой сегмент, для которого мы разрабатывали модель, вовсе ограниченный. И, возможно, вообще не стоило строить модель, а лучше просто оценить, какое количество людей в него попадает. Проще говоря, давайте для начала поймем, сколько людей нам НЕ надо удерживать. Тогда и окажется, что некоторым выгодно дать личного клиентского менеджера в помощь, а на кого-то и IVR в качестве поддержки жалко будет. А остальной сегмент настолько мал, что модель строить не надо — проще раз в месяц им звонить. Как мы видим, ответы на простые вопросы обычно куда важнее сложной математики и моделей, которые строят Data Scientist’ы. Наш опыт показывает, что даже участие и успешное выступление в соревнованиях Kaggle не помогают при решении индустриальных задач (к похожему заключению пришли и многие любители соревнований по спортивному программированию — участие в соревнованиях типа ACM имеет мало общего с индустриальной разработкой ПО). Более того, этот опыт приобретается лишь методом проб и ошибок и никогда не будет описан в книгах — даже мы на своих лекциях рассказываем не все тонкости, которые применили на практике. 15 сентября в Москве состоится конференция по большим данным Big Data Conference. В программе — бизнес-кейсы, технические решения и научные достижения лучших специалистов в этой области. Приглашаем всех, кто заинтересован в работе с большими данными и хочет их применять в реальном бизнесе. Следите за Big Data Conference в Telegram, на Facebook и «ВКонтакте». Материалы по теме: Большие данные управляют людьми? Колонка основателя «Школы Данных» Что такое Big data: собрали всё самое важное о больших данных Могут ли большие компании быть инновационными: объясняет Стив Бланк «Большие данные дают конкурентное преимущество, поэтому не все хотят о них рассказывать» Фото на обложке: DamienGeso/Depositphotos.