Текст книги "Роман с Data Science. Как монетизировать большие данные"

Артефакты машинного обучения

Раньше компьютером можно было управлять только с помощью прямых команд или инструкций: поверни сюда, дай назад, сложи и т. д. Это обычное, так называемое детерминированное программирование – для нас понятен алгоритм в виде инструкций, мы его описали, и компьютер подчиняется ему. Машинное обучение предполагает совершенно другой подход к программированию – обучение на примерах. Здесь мы показываем системе что-то с помощью примеров, тем самым избавляем себя от самостоятельного написания инструкций, что бывает совсем не просто. Это становится работой по обучению алгоритма ML.

Для меня машинное обучение отличается от программирования так же, как квантовая физика отличается от классической. Там мы точно можем определить, где находятся планеты Солнечной системы, а в квантовой механике все есть вероятность – мы получим только вероятность нахождения электрона. Так и в машинном обучении вы будете работать с вероятностями – например, модель будет предсказывать вероятность того, что на фотографии кошка. Под моделью я подразумеваю компьютерную программу (далее программный код), который обладает рядом признаков.

• Функция обучения (train), в которую можно отправить данные для обучения признаки (они же фичи, независимые предикторы, независимые переменные) и правильный ответ (output). Сам результат обучения сохраняется внутри модели.

• Функция предсказания (predict), которая предсказывает результат для новых примеров.

Поясню на примере одной задачи. У нас есть много фотографий собак и кошек, и нам нужно их разделить: в одну папку сложить файлы с фотографиями кошек, в другую – фото собак. Фотографий очень много – миллионы, вручную не сделать. У вас есть размеченный набор данных для обучения – тысяча фотографий, для каждой указано, кошка там или собака. Вы берете нужную модель, «скармливаете» ей в функцию train набор с размеченными данными, и она учится на них. Сама модель выглядит для нас как черный ящик. Конечно, в него можно заглянуть, что мы и сделаем в главе про машинное обучение. Как только модель обучится, мы уже начинаем одна за другой скармливать ей фотографии, которые нужно разделить. Для каждой фотографии модель вернет нам вероятность того, кошка там или собака. Используя эти цифры, уже несложно разделить фотографии.

Этот пример я видел вживую, когда глубокое обучение нейронных сетей (Deep Learning) только набирало оборот. На одном из конкурсов Kaggle.com была точно такая же задача [14]. Чтобы поиграть с этой задачей, я нашел код в интернете, который не использовал нейронные сети. Естественно, ничего не получилось, мой алгоритм был настолько плох, что проще было бросить монетку и получить такой же результат. Первые места заняли исследователи, у которых результат был близок в 99 % (точность угадывания). Их модель была основана на сверточных нейронных сетях. Меня тогда поразил результат. Глубокое обучение нейронных сетей еще не было популярным, а ведь это было всего лишь в 2013 году. Вот так быстро меняются технологии!

Следующий постулат: данные, на которых обучена модель, – это часть кода. Это еще одно серьезное отличие от классического программирования. Чтобы сделать «тиражирование» программного кода, его текст можно опубликовать в Сети. Эта программа будет работать везде одинаково. Если вы захотите «поделиться» своей обученный моделью, то вам придется отправить не только код, но и весь получившийся черный ящик. Именно так исследователи и делятся своими обученными моделями. Например, модель нейронной сети Resnet 50 [15] была обучена на миллионах изображений. Она уже полностью готова к работе; просто показывая ей разные фотографии, вы получите названия предметов, которые там изображены.

Артефакты инженерии

Ничего нельзя сделать без инженерии аналитической системы. Даже для самых простых вещей «на коленке» нужно продумывать следующие вопросы:

• Откуда и с какой периодичностью брать данные и как туда получить доступ?

• Какова нагрузочная способность источников данных, чтобы и бизнес работал без сбоев, и данные как можно быстрее были доступны для анализа?

• Какую архитектуру хранилища сделать? Или, может, не делать его вовсе?

• Какую аналитическую систему выбрать?

• Как использовать в процессах обученную модель машинного обучения (далее ML-модель)?

Таких вопросов может быть очень много. Эти вопросы должны решаться и автоматизироваться. Артефактами инженерии будут:

• Архитектура аналитической системы.

• Программный код, который обеспечивает работу системы.

Если все сделано идеально, то этих двух артефактов достаточно, чтобы развернуть (подготовить) аналитическую систему за минимальное время. В крутых реализациях это можно сделать автоматически, нажатием одной кнопки. Это очень важно для устойчивой работоспособности аналитической системы. К сожалению, работа людей, которые этим занимаются (администраторы, инженеры), почти незаметна, особенно когда все хорошо работает. Их почти не замечают, не понимают, чем они занимаются, и поэтому часто не ценят.

Архитектура аналитической системы состоит из нескольких уровней:

• Физический – серверы и каналы связи между ними.

• Данные – хранилища данных.

• Приложения – программы, с помощью которых пользователи получают доступ к данным, а также публикуют модели ML.

За физический уровень отвечают системные администраторы. Они занимаются «железом», чтобы система была отказоустойчивой. Также администраторы постоянно мониторят здоровье системы. Знаете, как определить, что у вас хорошая система и администраторы? Вы о работе администраторов ничего не слышите, а система работает без серьезных сбоев.

За уровень данных отвечают инженеры данных (Data Engineers или ETL Engineers): их основная задача – сделать так, чтобы данные доставлялись от источников данных и сохранялись в хранилищах данных. Часто они же отвечают за предобработку данных и развертывание BI-систем (OLAP-кубы и отчетные системы).

За уровень приложений отвечают инженеры машинного обучения (ML engineers) и аналитики данных (data scientists). ML-инженеры занимаются созданием ML-моделей и иногда – их развертыванием, чтобы они работали на благо вашего бизнеса (хотя в больших компаниях развертыванием моделей «в бою» часто занимаются другие инженеры). Аналитики данных занимаются тестированием моделей и их оценкой. В небольших компаниях эти две роли часто совмещаются. Однажды я проходил собеседование в офисе компании Quora.com (социальная сеть) в Пало-Альто (Калифорния, США) и там выяснил, что местные ML-инженеры как раз и занимаются разработкой ML-моделей, а аналитики данных занимаются метриками, анализом данных и прочим, но не ML-моделями.

Кто анализирует данные

Чем ближе анализ данных к точке принятия решений – тем лучше. Если вопрос возник у руководителя и у него есть полное понимание бизнес-контекста (какие события были и т. д.), а аналитическая система обладает хорошей интерактивностью, то большинство вопросов решаются на раз-два-три. До 80 % вопросов (вспомните правило Парето), если быть точным. В чем плюсы такого решения? Нет посредников – выше скорость! Пользователь даже может не иметь четко сформулированного вопроса, который точно понадобится, если ставить задачу аналитикам. Для этого очень важно внутри компании «продавать» аналитический подход и регулярно обучать пользователей.

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

Третий уровень – передаем задачу условному центральному отделу аналитиков данных, если:

• задача требует изменения ядра системы;

• задача технически сложна для аналитика какого-то отдела;

• требуется большая коллаборация между отделами для ее решения.

В Ozon.ru я не полностью ее реализовал, но уже в Wikimart.ru была сделана такая система: интерактивный анализ данных в OLAP-кубах дал возможность пользователям быстро решать свои вопросы, аналитики отделов решали проблемы анализа данных отделов, а центральный отдел создавал ядро всей аналитической системы. Кстати, многие бывшие пользователи OLAP-кубов в Ozon.ru потом писали мне, что им очень не хватает этих аналитических решений в других компаниях. К хорошему быстро привыкаешь.

Идеальная кнопка

До Физтеха я вообще не знал английского – в школе у меня был немецкий, о чем я очень жалел. На Физтехе принято учить английский язык, поэтому сразу на первом курсе была сформирована группа начинающих, в которую попали всего 4 человека. На протяжении трех курсов у нас проходило 2 занятия в неделю. Это был один из самых моих любимых предметов, и он здорово мне пригодился. На четвертом курсе я устроился подрабатывать переводчиком книги с английского языка на русский. Это была книга о программе анализа данных STATISTICA компании StatSoft. Я устроился туда стажером, переводил книгу, помню норматив – 15 000 знаков в день, от которого к вечеру пухла голова. Постепенно я втянулся и стал заниматься более интересными вещами: преподавал клиентам компании, проводил презентации для продаж, ездил в командировки и т. д. Тогда я постоянно консультировал клиентов и понял одну важную вещь: многие клиенты хотят получить кнопку и желательно на стуле – садишься на нее, а она делает всю твою работу.

Кроме того, заказчику чаще всего лень вдаваться в детали, и он готов платить огромные деньги просто за яркую обертку. Этот феномен очень хорошо эксплуатируется продавцами IT-решений, консультантами всех мастей. Я наблюдал его, когда Ozon.ru выбирал решение для веб-аналитики между Omniture SiteCatalyst и Webtrends. Обе команды продавцов активно рассказывали о «светлом» будущем. Так как никто из принимающих решения не был особенно в теме (я, кстати, тоже), то выбрали тех, кто «поет» лучше. Презентация Omniture выглядела эффектней, они нам подарили радиоуправляемые машинки и всякие подарки. Поэтому выбор был сделан в их пользу, хотя я нахожу системы равнозначными, и стоили они почти одинаково. В продолжение истории – когда я пришел в Wikimart.ru, мне уже было понятно, что нужно пользователям от веб-аналитики. Я быстро накатал техническое задание, его реализовали разработчики, и через два месяца после моего прихода в компании была своя система веб-аналитики, ничуть не хуже Omniture. И экономия составляла порядка 100 тысяч долларов в год.

Я не утверждаю, что продавцы и консультанты плохи, я призываю вас самих не лениться. Прочитайте книгу, а лучше две по теме, дочитайте их до конца. Ищите независимых экспертов, которым сможете доверять. Главное – это погружаться в детали, именно там кроются и все проблемы, и их решения. Будьте скептичны по отношению к своим эмоциям. Будьте скептичны к докладам на конференциях, они часто однобоки и слишком позитивны, чтобы быть правдой. Там есть интересные вещи, но мало кто рассказывает, чего стоило то или иное решение.

Продать аналитику внутри компании

Для меня это очень непростой вопрос. В разделе «Кто анализирует данные» я упоминал, что аналитическую систему мне удалось поднять за два месяца (причем я работал тогда два дня в неделю). «Продажа» ее пользователям заняла гораздо больше времени, и только спустя 4 месяца системой начали более-менее пользоваться. Причем kick-off-презентацию я делал сразу после запуска: пригласил туда всех значимых сотрудников компании, включая основателей.

Мне легче работать на индивидуальном уровне: поговорить за обедом, обменяться парой фраз у кулера с водой, поинтересоваться чужими задачами, копнуть глубже. Затем представить в уме схему решения – что есть и чего не хватает. Прислать решение человеку, показать его лично. Приучать людей к новой системе лучше не навязывая, а обучая – так пользователи постепенно поймут, как она может ускорить решение их задач.

В Retail Rocket мы так внедряли аналитику на базе ClickHouse. Ранее данные были доступны только в SQL-интерфейсе к вычислительному кластеру на базе Spark/Hadoop (эти технологии мы обсудим в главе о хранилищах), Hive. Подобная схема используется в компании Facebook, они так дают доступ к данным внутри своей компании. Проблема этой технологии заключается в том, что она медленно считает, запросы выполнялись до 30 минут, а данные доступны только до вчерашних суток. Пользовались этой системой только сотрудники технической поддержки. В одном из проектов мы попробовали аналитическую базу данных ClickHouse от Яндекса. Нам она понравилась: быстро считала, большая часть запросов – это секунды, можно было сделать систему, близкую к реальному времени. Вначале пересадили на нее техническую поддержку, а в Retail Rocket это одно из самых сильных подразделений. Они очень быстро полюбили эту технологию за скорость и отказались от использования медленного Hive. Далее мы начали предлагать новую систему пользователям внутри компании. После обучающих презентаций многие сотрудники зарегистрировались в системе, но не стали ею пользоваться. Тогда мы пошли другим путем: все входящие задачи от сотрудников, которые можно было решить с помощью этой системы, начали раз за разом «отфутболивать» – возвращать под соусом «сделай сам», демонстрируя возможности системы. И часть пользователей стала работать с системой самостоятельно! Там многое еще можно сделать, но то, что уже сделано, я считаю успехом.

Вообще, если абстрагироваться от продаж аналитики внутри компании, в структуре бизнеса часто не хватает такой роли, как руководитель внутреннего продукта. Задачей которого было бы помогать сотрудникам работать эффективнее, лучше автоматизировать внутреннюю деятельность, избавляться от неэффективного «мартышкиного» труда. В компаниях часто любят внедрять процессы, чтобы забюрократизировать работу, но мало кто думает о внутреннем продукте, чтобы целенаправленно облегчить работу своим сотрудникам. Я думаю, причина в том, что сложно посчитать, сколько заработает на этом компания. Но на самом деле это очень важная роль. И если она есть – продажа аналитики внутри компании происходит естественным образом.

Конфликт исследователя и бизнеса

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

Я много раз проводил собеседования и с новичками, и с опытными людьми, и знаю, что поиск интересной работы – главный тренд на рынке труда. Действующие специалисты говорят: «Надоело заниматься рутиной и всякой ерундой, хочу заниматься моделями машинного обучения». Новички: «Хочу заниматься компьютерным зрением и NLP (машинное обучение в лингвистике)». В целом людей объединяет любовь к машинному обучению, но для меня это звучит как любовь строителя к молотку, который пытается построить дом лишь с его помощью.

Эндрю Ын (Andrew Ng), которого я считаю одним из главных исследователей и популяризаторов машинного обучения, автор моего любимого курса на Coursera, в своей рассылке deeplearning.ai писал:

«Существует огромная разница между построением модели в блокноте Python (Jupyter Notebook) на компьютере в лаборатории и созданием реально работающих систем, которые создают ценность. Кажется, что сфера AI переполнена людьми, но по факту она широко открыта для профессионалов, которые знают, что делают».

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

Ноа Лоранг, аналитик данных из компании Basecamp, в своем блоге [16] пишет:

«Маленькая грязная тайна продолжающегося бума data science в том, что то, что обычно подразумевается под этим на самом деле, не нужно бизнесу. Бизнесу нужна точная и полезная информация для принятия решений: как тратить время и ресурсы компании. Очень небольшое подмножество задач в бизнесе может быть лучшим образом решено машинным обучением; большинство же из них нуждается в хороших данных и понимании их смысла, что может быть достигнуто простыми методами».

Я готов подписаться под каждым словом. К сожалению, проблема в хайпе вокруг нашей профессии. Курсы по анализу данных рекламируют видеоблогеры, президенты говорят об искусственном интеллекте, акции Tesla растут каждый день. Но, с одной стороны, есть молодые специалисты-романтики, которые хотят строить космические корабли, а с другой – компании, которые хотят зарабатывать деньги. О том, как примирить их интересы, пойдет речь в следующих главах.

Недостатки статистического подхода в аналитике

Аналитика данных «усредняет» человека. На вопрос «Би-би-си» про индивидуальность человека Карл Юнг, основатель аналитической психологии, сказал [17]:

«Что тут скажешь: это – одно из следствий современной науки, которая основывается на статистическом усреднении. А для статистического усреднения человек как таковой совершенно не важен. Это – абстракция, а не конкретная личность.

Наше мировоззрение, тоже основанное на статистическом усреднении, является абстракцией, которая не имеет никакого отношения к тому, что происходит в реальном мире. В таком мировоззрении индивидуум есть не что иное, как случайный феномен. Но в действительности индивидуум – это единственная реальность.

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

Статистический подход, данные для которого по сути представляют «агрегаты» (суммы, количества, средние), убирает «слабые» сигналы индивидуальности. Для алгоритма человек – всего лишь строчка с несколькими цифрами и ID. Все остальное не нужно, эти «фичи» не важны, потому что конкретная модель не смогла извлечь из них выгоду. Я размышлял над моделями машинного обучения, они все слишком обобщают и упрощают, часто видят лишь черное и белое, не различая оттенков. В итоге все сводится к банальности, к скору (score), к баллам на выходе модели, на основании которых принимают решение – дать кредит или не дать и т. д. Это касается моделей машинного обучения.

Еще один недостаток статистического подхода – измерение, которое лежит в его основе. Об этом пишет в своей книге «Тирания показателей» [18] Джерри Миллер, ученый, автор многочисленных статей для New York Times и Wall Street Journal:

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

Бездумное внедрение количественных показателей везде, где только можно, – зло. Я помню, как в школе на уроках физкультуры нас гоняли по нормативам. Вы тоже бегали на скорость стометровку и прыгали в длину? Но при этом никто не прививал культуру тренировок и привычку к ежедневной физической активности. Соответствие абстрактным нормативам оказалось важнее не только твоего личного прогресса (все мы разные – усреднять нельзя!), но и любви к спорту – а это в корне неправильно. Помню, читал пост выпускника Физтеха в соцсети: «1987 год. Мы уже поступили… А потом была какая-то контрольная по физкультуре. Надо было на время переплыть физтеховский 25-метровый бассейн. Заставили всех, а потом вывесили результаты. Помню, как я их изучал: 30 сек, 35 сек, 1 мин, 2 мин, 5 мин… Последней строкой значилось: “сошел с дистанции”. Куда сошел?»

Все мы знаем про «палочную» систему в силовых органах, которая доводит до абсурда. Саша Сулим, автор книги «Безлюдное место. Как ловят маньяков в России» [8], посвященной знаменитому делу ангарского маньяка, пишет в ней о том, как их на самом деле не ловят – милиция много лет не связывала убийства женщин в серию, игнорируя очевидные факты, чтобы избежать в отчетах «висяка» и непойманный маньяк не портил статистику раскрываемости.

Но хотя количественные оценки – это плохо, никто пока не придумал ничего лучше. И надо признать, что методы этих оценок эволюционируют, усложняясь. Десять лет назад я (как, вероятно, и большинство моих коллег), оценивая эффективность сайта, фокусировался на конверсии и лишь потом начал обращать внимание на другие метрики: средняя выручка на посетителя сайта, средняя стоимость заказа, среднее число товаров в заказе и даже маржа. Одновременно эти показатели нужно делить по верхним категориям товаров и группам пользователей (если достаточно данных). Одной количественной метрики – конверсии – оказалось недостаточно: экономика интернет-магазина сложнее.