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

Погрешности – правило штангенциркуля

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

В бизнесе и науке так делать нельзя, особенно если вы хотите быть хорошим аналитиком и не пользоваться вышеупомянутыми «сравнительно честными способами» повернуть цифры туда, куда нужно. Сейчас погрешность измерений веб-аналитики (системы измеряют посещаемость веб-сайтов) составляет около 5 %. Когда я еще работал в Ozon.ru, погрешность всей аналитической системы тоже была около 5 % (расхождение с данными бухгалтерии). У меня был серьезный случай – я обнаружил ошибку в коммерческой системе веб-аналитики Omniture Sitecatalyst (ныне Adobe Analytics): она не считала пользователей с браузером Opera. В результате погрешность измерений была очень большой – около 10 % всех совершенных заказов система, за которую мы платили более 100 тысяч долларов в год, безнадежно потеряла. С такой погрешностью ей тяжело было доверять – но, к счастью, когда я обнаружил ошибку системы и сообщил о ней в Omniture, их разработчики ее устранили.

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

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

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

Принцип Парето

Итальянский экономист и социолог Вильфредо Парето в 1897 году, исследуя структуру доходов итальянских домохозяйств, выяснил, что 80 % процентов всех их доходов приходится на 20 % из них.

Универсальный принцип, названный в его честь, был предложен в 1951 году, и сейчас принцип Парето звучит так: «20 % усилий дают 80 % результата».

Опираясь на свой опыт, я бы так сформулировал его на языке данных:

• 20 % данных дают 80 % информации (data science);

• 20 % фич или переменных дают 80 % точности модели (machine learning);

• 20 % из числа успешных гипотез дают 80 % совокупного положительного эффекта (тестирование гипотез).

Я почти 20 лет работаю с данными и каждый день убеждаюсь в том, что эта закономерность работает. Это правило лентяя? Только на первый взгляд. Ведь чтобы понять, какие именно 20 % позволят добиться результата, нужно потратить 100 % усилий. Стив Джобс в интервью Business Week в 98-м году сказал: «Простое сделать труднее, чем сложное: вам придется усердно поработать, чтобы внести ясность в ваши мысли, и тогда станет понятно, как сделать проще. Но это стоит того: как только вы достигнете этого, вы сможете свернуть горы».

Приведу пример того, как применяется правило Парето в машинном обучении. Для проекта обычно готовится ряд фич (входных параметров модели), на которых будет тренироваться модель. Фич может получиться очень много. Если выводить такую модель в бой, она будет тяжелой, требовать для своего поддержания много строк программного кода. Для такой ситуации есть лайфхак – посчитать вклад каждой фичи (feature importance) в результирующую модель и выбросить из модели фичи с минимальным вкладом. Это прямое использование правила Парето – 20 % фич дают 80 % результата модели. В большинстве случаев лучше модель упростить, пожертвовав небольшой долей ее точности, при этом проект будет в разы меньше исходного. На практике можно экономить время, подсмотрев фичи в решениях какой-нибудь схожей задачи на kaggle.com. Взять оттуда самые сильные из них и реализовать в первой версии собственного проекта.

Можно ли принимать решения только на основе данных?

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

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

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

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

В анализе данных ошибка выжившего – это учет известного и пренебрежение неизвестным, но существующим. С этой ошибкой очень легко столкнуться, когда у нас есть какие-то данные, на основе которых нужно сделать вывод. Любые данные – это выборка, ограниченное число. Сама выборка сделана из генеральной совокупности. Если выборка сделана случайно и она достаточно большая, то все хорошо – большая часть закономерностей будет зафиксирована в выборке, и выводы будут объективными. Если же выборка была не случайной, как в нашем случае с самолетами, где в ней отсутствовали сбитые машины, – то, скорее всего, выводы будут ошибочными.

Например, в среднем только 1 из 100 посетителей сайта интернет-магазина совершает покупку. Если мы захотим улучшить свой сайт, чтобы больше покупателей покупали, то с какими посетителями нужно работать? Обычно дизайнеры и продуктологи обращают внимание на существующих покупателей из-за того, что с ними можно пообщаться, есть контактная информация из заказов, по ним есть хорошая статистика. Но эта выборка составляет всего лишь 1 % от всей генеральной совокупности посетителей; с остальными почти невозможно связаться – это «сбитые самолеты». В итоге будет смещение выводов в сторону «выживших», а значит, выводы анализа не будут работать для всех посетителей.

Еще одно когнитивное искажение – предвзятость результата (outcome bias). Представьте себе – вам предлагают два варианта на выбор:

• Сыграть в «Орла или решку» – если выпадет орел, получите 10 000 рублей.

• Сыграть игральной костью с шестью гранями – если выпадет 6, получите 10 000 рублей.

Какой вариант выберете? Естественно первый, в котором шанс выиграть 1 к 2, во втором варианте значительно хуже – 1 к 6. Монету подбросили – выпала решка, вы ничего не получили. Тут же бросили кость, выпала шестерка. Будет ли обидно? Да, будет. Но было ли наше решение правильным?

Этот пример я взял из поста «Фокусируйтесь на решениях, а не на результате» [5] Кэсси Козырьков (Cassie Kozyrkov), которая работает директором по принятию решений [4] (Decision Intelligence) в Google. Она советует всегда оценивать верность решения, учитывая, какой именно информацией вы обладали в момент его принятия. Многие люди жалеют, что они не уволились с работы раньше и только потеряли время, откладывая это решение, – я и сам в свое время так думал. И это отличный пример предвзятости результата – мы понимаем, что нужно было уволиться раньше, только обладая той информацией, которая у нас есть на данный момент. Например, что с тех пор зарплата так и не выросла, а интересный проект, который мы предвкушали, так и не был запущен. Оценивая последствия своего решения (особенно неудачного), в приступе самокопания мы не должны забывать, что принимали решение в условиях неопределенности.

Глава 2
Делаем анализ данных

Когда я работал в компании Wikimart.ru, основатели этого проекта познакомили меня с Ди Джеем Патилом (DJ Patil). Ди Джей был тогда одним из ангелов-инвесторов проекта, он руководил аналитикой в LinkedIn, затем был ведущим аналитиком данных (Chief data scientist) Белого дома в Вашингтоне при администрации Барака Обамы, тогдашнего президента США. Встречался я с Ди Джеем несколько раз в Москве и в Кремниевой долине в Калифорнии. В Москву он приезжал для презентации своей мини-книги «Building Data Science Teams» («Построение команд аналитиков данных») [9], выпущенной издательством O’Reilly. В книге он обобщил опыт ведущих компаний Кремниевой долины. Очень рекомендую вам эту книгу, так как ее мысли мне близки, и их я проверил на практике. Вот как автор определяет организацию, управляемую данными:

«A data-driven organization acquires, processes, and leverages data in a timely fashion to create efficiencies, iterate on and develop new products, and navigate the competitive landscape».

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

Далее Ди Джей указывает на принцип «Если ты не можешь измерить, ты не можешь это исправить» («if you can’t measure it, you can’t fix it»), который объединяет самые сильные организации, эффективно использующие свои данные. Вот рекомендации Патила, которые следуют из этого принципа:

• Собирайте все данные, какие только возможно. Вне зависимости от того, строите ли вы просто отчетную систему или продукт.

• Продумывайте заранее и делайте вовремя измерение метрик проектов.

• Позвольте как можно большему количеству сотрудников знакомиться с данными. Множество глаз поможет быстрее выявить очевидную проблему.

• Стимулируйте интерес сотрудников задавать вопросы относительно данных и искать на них ответы.

Эти мысли я еще озвучу в главе про данные. А теперь самое время поговорить о том, что мы получаем на выходе анализа данных.

Артефакты анализа данных

Здесь и далее под артефактами я буду понимать осязаемый результат, физический или виртуальный объект.

Рис. 2.1. Артефакты аналитики

Их можно разделить на три вида (рис. 2.1):

• артефакты бизнес-анализа данных (business intelligence);

• артефакты машинного обучения (machine learning);

• артефакты инженерии данных (data engineering).

Поговорим о них подробнее.

Бизнес-анализ данных

Бизнес-анализ данных (Business Intelligence, BI) – термин уже устоявшийся. Вот какое определение дает Википедия:

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

Под бизнес-анализом я подразумеваю объединение контекста бизнеса и данных, когда становится возможным бизнесу задавать вопросы к данным и искать ответы Первыми артефактами являются так называемые инсайты и гипотезы, вторыми – отчеты или дашборды, метрики и ключевые показатели (Key Performance Indicator). Поговорим подробнее об инсайтах и гипотезах.

Гипотезы и инсайты

Инсайт (insight) в переводе с английского – понимание причин. Именно за этим обращаются к аналитикам. В поиске инсайтов помогают аналитика и статистика:

• Цель аналитики заключается [10] в помощи формулирования гипотезы.

• Цель статистики [10] в том, чтобы эту гипотезу проверить и подтвердить.

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

• Не происходило ли что-нибудь подобное раньше? Если да, то какие тому были причины? Тогда у нас будет самая первая и самая вероятная гипотеза.

• Обращаемся к бизнес-контексту: не происходило ли каких-либо неординарных событий? Часто как раз параллельные события влияют на возникновение проблемы. Еще плюс пара гипотез.

• Описательный анализ данных (exploratory data analysis): смотрим данные в аналитической системе (например, кубах OLAP), не видно ли каких-либо аномалий на глаз? Например, какие-либо распределения изменились во времени (типы клиентов, структура продаж и т. д.). Если что-то показалось подозрительным – дополняем список гипотез.

• Использование более сложных методов поиска аномалий или изменений, например, как описано здесь [11].

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

Когда я был директором по аналитике Retail Rocket (сервис рекомендаций для интернет-магазинов), мне и аналитикам часто приходилось заниматься расследованиями, ведь бизнес довольно большой – больше 1000 клиентов, и странности, с которыми приходится разбираться, случаются часто. Много приходится работать с так называемыми А/Б-тестами: это тесты, где аудитория сайта делится на две части случайным образом – первой части пользователей показывается одна версия сайта, второй – другая. Такие тесты обычно используют, чтобы оценить влияние изменений на бизнес-метрики сайта, когда первая версия – это старая версия или контрольная группа, а вторая – новая версия. Если это интернет-магазин – это, скорее всего, будут продажи. Далее к результатам теста применяются статистические критерии, которые подскажут достоверность изменений.

Такие тесты хорошо выявляют проблемы: например, версия сайта с обновленными рекомендациями Retail Rocket проиграла старой версии рекомендаций. Как только это становится известным, начинается расследование. Проверка начинается с интеграции, и это первая гипотеза: правильно ли передаются нам данные от интернет-магазина. Обычно на этом этапе решается 60–70 % проблем. Далее мы пытаемся найти отличие этого магазина от остальных в такой же тематике, например магазины одежды. Это вторая гипотеза. Третья гипотеза – возможно, мы изменили дизайн сайта таким образом, что полезная информация опустилась ниже на странице сайта. Четвертая гипотеза – тест мог отрицательно повлиять на определенные категории товаров. Собрав набор таких гипотез, мы начинаем их проверять примерно в такой последовательности, как я описал. Довольно часто мы находим причину проблем, но иногда это не удается, его величество случай играет с нами в кошки-мышки, и эту мышку очень сложно найти.

Однажды клиент – магазин «Дочки-Cыночки» – тестировал наш сервис и сервис одного из наших российских конкурентов, чтобы выбрать лучший, и это превратилось в настоящий детектив [12]. Чтобы точно не проиграть в тесте, конкурент перемещал некоторое число пользователей, которые были близки к покупке, (например, добавили товар в корзину) из конкурентных (наших) сегментов в свой – причем делалось это не на постоянной основе, а в отдельные дни и часы. Основной метрикой сравнения была конверсия: процент пользователей, совершивших покупку. Ясно, что в той «мошеннической схеме» такой процент будет выше там, куда перетянули пользователей. Здесь компания Retail Rocket пошла на принцип! Мы стали копать. Через два месяца были обнаружены и опубликованы [12] факты подтасовки результатов. В итоге прошел ряд судебных процессов, и справедливость восторжествовала.

Отчеты, дашборды и метрики

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

• Просто таблица с «сырыми» данными или так называемые «выгрузки», например, таблица с заказами клиентов.

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

• Дашборды (dashboards) содержат ключевые показатели и метрики.

Первые два относительно просты и делаются через специальные системы, которые могут генерировать отчеты по запросу. Я стараюсь максимально оставить эту задачу на откуп пользователям. Почему? Потому, что тратить на это время высококвалифицированных сотрудников – значит стрелять из пушки по воробьям. Кстати, этим могут заняться стажеры-аналитики – отличный способ наработать опыт и понять бизнес-контекст. Как мотивировать пользователей стараться самостоятельно? Во-первых, они сэкономят время, которое обычно тратят на постановку задачи и ожидание результата. Во-вторых, получат возможность самим вносить правки и изменения – а значит творить. По моему опыту, обычно этим занимаются очень перспективные сотрудники, которые не бояться освоить новый инструмент, чтобы делать свою работу лучше. Остальным придется пройти через стандартный цикл планирования задач: а это время (дни, а иногда недели) и очень четкая формулировка технического задания. И кстати, все генеральные директора (Ozon.ru, Wikimart.ru, Ostrovok), с которыми я работал, пользовались OLAP-кубами со своих компьютеров. С их помощью они всегда могли ответить на простые вопросы, а если не получалось – обращались к аналитикам.

Теперь взглянем на дашборды и начнем с определения из Википедии:

«Дашборд – это тип графического интерфейса, который делает возможным быструю оценку ключевых показателей для конкретной цели или бизнес-процесса. Часто подразумевается, что это просто другое название отчета о прогрессе или просто отчета».

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

• Ключевой показатель (key performance indicator, KPI) – это индикатор, который показывает, насколько далеко мы находимся от цели, например отставание/опережение плана.

• Метрика – это цифра, которая характеризует процесс, обычно используется как справочная информация.

Главное различие между метрикой и ключевым показателем – наличие цели. В ключевых показателях она есть, в метриках обычно нет. Как правило, ключевые показатели используются в дашбордах компаний, где уже и продукт, и бизнес-процесс «устоялись». Уже накоплено некоторое множество данных, что делает возможным прогнозирование целей. Метрики я обычно вношу туда, где нет достаточно устойчивых процессов. Их обычно ставят, когда цель пока не прогнозируема. Зрелость дашборда можно определить по соотношению количества ключевых показателей и метрик: чем метрик больше, тем более незрелый дашборд мы получаем на выходе.

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

• не является «простыней цифр»;

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

Часто велико искушение сделать огромную простыню цифр, закрывающую все аспекты бизнеса. И я понимаю владельцев/менеджеров компаний – на старте проекта по построению внутренней аналитической системы всегда хочется большего. Я наблюдал это и в Ozon.ru, и в Ostrovok.ru. К слову, эти строки написаны по мотивам письма, которое я писал восемь лет назад операционному директору Ostrovok.ru, – он хотел получить от аналитиков ту самую «простыню». А я считаю такое цифровым «микроменеджментом», в нем легко запутаться, самые важные показатели похоронены среди второстепенных. С первого взгляда будет сложно понять, где возникла проблема, а это основная функция дашбордов. Бороться с этим можно, например, через внедрение OKR – цели и ключевые результаты (Objectives and Key Results) [13] – или системы сбалансированных показателей (Balanced Scorecard). В этой книге я не буду подробно останавливаться на этих методиках, но рекомендую вам с ними ознакомиться. Также можно чаще пользоваться графическими элементами, например, добавив на график линию тренда (с помощью семиточечного скользящего среднего, чтобы убрать недельную сезонность), будет легче заметить восходящий или нисходящий тренд.

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

Никакой дашборд не заменит интерактивный анализ, для которого нужны соответствующая аналитическая система (SQL, OLAP, Google Data Studio, Tableau) и знание контекста. Мы никогда не сможем придумать ограниченный набор отчетов, которые будут отвечать на вопрос «почему». Максимум, что мы можем сделать, – наращивать (но не слишком) объем правильных метрик, исходя из инцидентов, за которыми будем следить.

Поэтому я всегда за лаконичные автоматические отчеты, которые будут отвечать на два вопроса: есть ли проблема и где она возникла. Если проблема есть, нужно лезть в интерактивные системы анализа данных.

Разработка дашбордов – это одна из самых нелюбимых работ у тех, кто занимается анализом данных. Когда я обсуждал этот вопрос с Ди Джеем Патилом, отметив, что 50 % времени аналитического отдела занимает работа над отчетностью, он сказал, что у них в LinkedIn тоже периодически накапливался пул таких задач и приходилось их закрывать. И взгрустнул. Но дашборды очень нужны – они помогают контролировать общее здоровье вашей системы – вверенных вам серверов и сетей, если вы системный администратор, или всей компании, если вы генеральный директор.