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

Как проверять задачи

Чтобы проверить задачу, нужно вспомнить, какие артефакты мы можем получить:

• инсайт, ответ на вопрос почему;

• автоматизированный отчет (дашборд);

• ML-модели;

• код системы анализа данных.

Почти все эти задачи объединяет наличие программного кода. Исключением может быть разве что инсайт, для поиска которого порой достаточно обычного Excel, а программирование могло не потребоваться.

Для проверки программного кода проводится код-ревью (code review). На этом этапе какой-либо сотрудник (не исполнитель) изучает программный код, чтобы понять, насколько этот способ решения задачи корректен и соответствует стилистическому подходу, принятому в команде. Эта практика широко применяется в разработке ПО.

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

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

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

• в случае ухода разработчика/аналитика весь код останется у вас;

• если возникнут проблемы – легко откатить изменения, вернувшись к прошлой версии.

Инспекцию кода относительно легко сделать для всех артефактов аналитики, кроме инсайтов. C инсайтами не все так однозначно. Для их поиска и выкладок используются разные инструменты: Excel или его аналоги, графический интерфейс аналитической системы, SQL, блокноты Python или другого языка (например, Jupyter Notebooks). В таких задачах обычно присутствует несколько этапов:

• получение данных;

• их очистка;

• анализ;

• выводы.

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

Есть одна проблема с блокнотами (jupyter notebooks) – скрытые ошибки. В блокнотах выполняются разовые задачи (ad-hoc), и поэтому аналитики пренебрегают стандартами разработки – инспекциями кода и тестами. Как с этим бороться? Есть несколько способов проверить код и выводы.

Во-первых, проверяющий может очень внимательно просмотреть все решение на предмет ошибок. Это трудоемко, ведь по сути ему придется построить решение чуть ли не с нуля в своей голове. Во-вторых, можно воспользоваться другими источниками данных, которые хотя бы косвенно могли бы подтвердить вывод. В-третьих, можно последовать совету Кэсси Козырьков, директора по принятию решений в Google, из ее статьи «Самая мощная идея в анализе данных» [26]: сделать случайное разделение данных на два датасета (набора данных). По первому набору аналитик будет искать причину, а по второму проверяющий проверит выводы аналитика. Такой подход всегда используется в машинном обучении и называется валидацией (validation).

Хочу сделать важное замечание относительно решений, которые не используют код. В чем сложность их проверки? Представьте, что вы работаете в Excel и уже получили данные в виде файла. Вы должны загрузить его в Excel, проверить, почистить, написать формулы, построить таблицу или сводную таблицу (что удобнее для проверки). Теперь поставьте себя на место проверяющего. Часть операций в Excel делается мышью, данные можно копировать и вставлять блоками, протокола всех действий нигде нет. Чтобы посмотреть формулу – нужно кликнуть, а если таких формул много? И вы их «протягивали», а если ошиблись, исправили и не обновили все формулы? Чуть лучше с интерфейсами, где блоки выстраиваются графически и соединяются стрелками. Приходится щелкать по каждому блоку, проверять, все ли корректно. С кодом проверить все намного проще – все операции с данными написаны текстом! Не нужно никуда щелкать, все видно сразу. Еще один плюс кода – можно очень быстро пересчитать задачу – просто запустить код. В безкодовых решениях аналитику придется писать протокол – что и как он делал по шагам. Это облегчит проверку и даст возможность безболезненно повторить задачу в будущем. Конечно, Excel и другие визуальные инструменты очень ускоряют работу, я сам пользуюсь ими и не отговариваю вас. Моя задача обозначить плюсы и минусы этих подходов – что вам ближе, решать только вам.

Эти нюансы я понял, только когда стал работать в Retail Rocket, так как требования к качеству были значительно выше, чем на моих предыдущих местах работы. Раньше я проверял только результат, а теперь – все решение целиком.

Как тестировать и выкладывать изменения в рабочую систему

Если задача вносит изменения в рабочую систему, то следующий шаг проверки – выкладка (deploy) изменений. Здесь все выглядит стандартно для разработки, и вы можете использовать практики, принятые у ваших разработчиков. В аналитике Retail Rocket мы использовали CI/CD на основе GitLab, когда все изменения выкладываются нажатием одной кнопки. Мы думали, кто это должен делать, и после различных экспериментов сошлись на том, что это должен делать исполнитель задачи. Как таковых инженеров тестирования у нас нет, поэтому исполнитель переводит задачу в статус тестирования (Testing). Далее делает выкладку, следит за тем, чтобы тесты были выполнены и изменения отразились на работе системы. Например, проверяет, что нужные отчеты работают и предоставляют информацию в требуемом виде. Цели выкладки: отразить изменения в рабочей системе, проверить, что все работает так, как этого требует задача.

Как защищать задачу перед инициатором

У задачи есть инициатор, который ее поставил, и только этот человек может дать разрешение перевести ее в статус выполненной. В статусе тестирования, после выполнения всех расчетов, исполнитель задачи обращается к инициатору с просьбой проверить результат. Это может быть инсайт, отчет или какое-то программное изменение системы. Тут инициатор должен либо согласиться с результатами задачи, либо нет. В случае отказа я рекомендую сравнить то, что требует инициатор по результатам проверки, с постановкой задачи. Разница между тем, чего хотят от вас сейчас, и тем, чего хотели на этапе планирования задачи, может быть большой. Встречается такая ситуация довольно часто. Как с этим бороться, особенно если инициатор находится выше исполнителя в иерархии? Во-первых, правила игры должны быть известны всем и быть явно обозначены. Во-вторых, как я уже писал, нужно вести аудиозапись на встречах планирования. В-третьих, если условия задачи изменились существенно, то нужно признать, что результаты ее оказались ненужными и время было потрачено зря. А затем завести новую задачу, трудоемкость которой будет оценена отдельно.

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

Нужно ли уметь программировать?

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

Я научился программировать самостоятельно в детстве. Отец купил компьютер «Партнер 01.01» в конце 80-х, когда мне было примерно одиннадцать лет, и я начал погружаться в программирование. Вначале освоил язык BASIC, потом уже добрался до ассемблера. Изучал все по книгам – спросить тогда было не у кого. Задел, который был сделан в детстве, мне очень пригодился в жизни. В то время моим главным инструментом был белый мигающий курсор на черном экране, программы приходилось записывать на магнитофон – все это не идет ни в какое сравнение с теми возможностями, которые есть сейчас. Азам программирования научиться не так сложно. Когда моей дочери было пять с половиной лет, я посадил ее за несложный курс по программированию на языке Scratch. С моими небольшими подсказками она прошла этот курс и даже получила сертификат MIT начального уровня.

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

В аналитике есть два пути. Первый – пользоваться готовыми инструментами (Excel, Tableau, SAS, SPSS и т. д.), где все действия совершаются мышкой, а максимум программирования – написать формулу. Второй – писать на Python, R или SQL. Это два фундаментально разных подхода, но хороший специалист должен владеть обоими. При работе с любой задачей нужно искать баланс между скоростью и качеством. Особенно это актуально для поиска инсайтов. Я встречал и ярых приверженцев программирования, и упрямцев, которые могли пользоваться только мышкой и от силы одной программой. Хороший специалист для каждой задачи подберет свой инструмент. В каком-то случае он напишет программу, в другом сделает все в Excel. А в третьем – совместит оба подхода: на SQL выгрузит данные, обработает датасет в Python, а анализ сделает в сводной (pivot) таблице Excel или Google Docs. Скорость работы такого продвинутого специалиста может быть на порядок больше, чем одностаночника. Знания дают свободу.

Еще будучи студентом, я владел несколькими языками программирования и даже успел поработать полтора года разработчиком ПО. Времена тогда были сложными – я поступил в МФТИ в июне 1998 года, а в августе случился дефолт. Жить на стипендию было невозможно, денег у родителей я брать не хотел. На втором курсе мне повезло, меня взяли разработчиком в одну из компаний при МФТИ – там я углубил знание ассемблера и Си. Через какое-то время я устроился в техническую поддержку компании StatSoft Russia – здесь я прокачал статистический анализ. В Ozon.ru прошел обучение и получил сертификат SAS, а еще очень много писал на SQL. Опыт программирования мне здорово помог – я не боялся чего-то нового, просто брал и делал. Если бы у меня не было такого опыта программирования, в моей жизни не было бы многих интересных вещей, в том числе компании Retail Rocket, которую мы основали с моими партнерами.

Датасет

Датасет – это набор данных, чаще всего в виде таблицы, который был выгружен из хранилища (например, через SQL) или получен иным способом. Таблица состоит из столбцов и строк, обычно именуемых как записи. В машинном обучении сами столбцы бывают независимыми переменными (independent variables), или предикторами (predictors), или чаще фичами (features), и зависимыми переменными (dependent variables, outcome). Такое разделение вы встретите в литературе. Задачей машинного обучения является обучение модели, которая, используя независимые переменные (фичи), сможет правильно предсказать значение зависимой переменной (как правило, в датасете она одна).

Основные два вида переменных – категориальные и количественные. Категориальная (categorical) переменная содержит текст или цифровое кодирование «категории». В свою очередь, она может быть:

• Бинарной (binary) – может принимать только два значения (примеры: да/нет, 0/1).

• Номинальной (nominal) – может принимать больше двух значений (пример: да/нет/не знаю).

• Порядковой (ordinal) – когда порядок имеет значение (пример, ранг спортсмена, номер строки в поисковой выдаче).

Количественная (quantitative) переменная может быть:

• Дискретной (discrete) – значение подсчитано счетом, например, число человек в комнате.

• Непрерывной (continuous) – любое значение из интервала, например, вес коробки, цена товара.

Рассмотрим пример. Есть таблица с ценами на квартиры (зависимая переменная), одна строка (запись) на квартиру, у каждой квартиры есть набор атрибутов (независимы) со следующими столбцами:

• Цена квартиры – непрерывная, зависимая.

• Площадь квартиры – непрерывная.

• Число комнат – дискретная (1, 2, 3…).

• Санузел совмещен (да/нет) – бинарная.

• Номер этажа – порядковая или номинальная (зависит от задачи).

• Расстояние до центра – непрерывная.

Описательная статистика

Самое первое действие после выгрузки данных из хранилища – сделать разведочный анализ (exploratory data analysis), куда входит описательная статистика (descriptive statistics) и визуализация данных, возможно, очистка данных через удаление выбросов (outliers).

В описательную статистику обычно входят различные статистики по каждой из переменных во входном датасете:

• Количество непустых значений (non missing values).

• Количество уникальных значений.

• Минимум/максимум.

• Среднее значение.

• Медиана.

• Стандартное отклонение.

• Перцентили (percentiles) – 25 %, 50 % (медиана), 75 %, 95 %.

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

s = pd.Series([4–1, 2, 3])

s.describe()

count 3.0

mean 2.0

std 1.0

min 1.0

25 % 1.5

50 % 2.0

75 % 2.5

max 3.0

Хотя эта книга не является учебником по статистике, дам вам несколько полезных советов. Часто в теории подразумевается, что мы работаем с нормально распределенными данными, гистограмма которых выглядит как колокол (рис. 4.1).

Очень рекомендую проверять это предположение хотя бы на глаз. Медиана – значение, которое делит выборку пополам. Например, если 25-й и 75-й перцентиль находятся на разном расстоянии от медианы, это уже говорит о смещенном распределении. Еще один фактор – сильное различие между средним и медианой; в нормальном распределении они практически совпадают. Вы будете часто иметь дело с экспоненциальным распределением, если анализируете поведение клиентов, – например, в Ozon.ru время между последовательными заказами клиента будет иметь экспоненциальное распределение.

Рис. 4.1. Нормальное распределение и Шесть Сигм

Среднее и медиана для него отличаются в разы. Поэтому правильная цифра – медиана, значение, которое делит выборку пополам. В примере с Ozon.ru это время, в течение которого 50 % пользователей делают следующий заказ после первого. Медиана также более устойчива к выбросам в данных. Если же вы хотите работать со средними, например, из-за ограничений статистического пакета, да и технически среднее считается быстрее, чем медиана, то в случае экспоненциального распределения можно его обработать натуральным логарифмом. Чтобы вернуться в исходную шкалу данных, нужно полученное среднее обработать обычной экспонентой.

Перцентиль – значение, которое заданная случайная величина не превышает с фиксированной вероятностью. Например, фраза «25-й перцентиль цены товаров равен 150 рублям» означает, что 25 % товаров имеют цену меньше или равную 150 рублям, остальные 75 % товаров дороже 150 рублей.

Для нормального распределения, если известно среднее и стандартное отклонение, есть полезные теоретически выведенные закономерности – 95 % всех значений попадает в интервал на расстоянии двух стандартных отклонений от среднего в обе стороны, то есть ширина интервала составляет четыре сигмы. Возможно, вы слышали такой термин, как Шесть сигм (six sigma, рис. 4.1), – эта цифра характеризует производство без брака. Так вот, этот эмпирический закон следует из нормального распределения: в интервал шести стандартных отклонений вокруг среднего (по три в каждую сторону) укладывается 99.99966 % значений – идеальное качество. Перцентили очень полезны для поиска и удаления выбросов из данных. Например, при анализе экспериментальных данных вы можете принять то, что все данные вне 99-го перцентиля – выбросы, и удалять их.

Графики

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

• гистограммы;

• диаграмма рассеяния (scatter chart);

• график временного ряда (time series) с линией тренда;

• график «ящики с усами» (box plot, box and whiskers plot).

Гистограмма (рис. 4.2) – наиболее полезный инструмент анализа. Она позволяет визуализировать распределение по частотам появления какого-то значения (для категориальной переменной) или разбить непрерывную переменную на диапазоны (bins). Второе используется чаще, и если к такому графику дополнительно предоставить описательные статистики, то у вас будет полная картина, описывающая интересующую вас переменную. Гистограмма – это простой и интуитивно понятный инструмент.

График диаграммы рассеяния (scatterplot, рис. 4.3) позволяет увидеть зависимость двух переменных друг от друга. Строится он просто: на горизонтальной оси – шкала независимой переменной, на вертикальной оси – шкала зависимой. Значения (записи) отмечаются в виде точек. Также может добавляться линия тренда. В продвинутых статистических пакетах можно интерактивно пометить выбросы.

Рис. 4.2. Гистограмма

Рис. 4.3. Диаграмма рассеяния

Графики временных рядов (time series, рис. 4.4) – это почти то же самое, что и диаграмма рассеяния, в которой независимая переменная (на горизонтальной оси) – это время. Обычно из временного ряда можно выделить две компоненты – циклическую и трендовую. Тренд можно построить, зная длину цикла, например, семидневный – это стандартный цикл продаж в продуктовых магазинах, на графике можно увидеть повторяющуюся картинку каждые 7 дней. Далее на график накладывается скользящее среднее с длиной окна, равной циклу, – и вы получаете линию тренда. Практически все статистические пакеты, Excel, Google Sheets умеют это делать. Если нужно получить циклическую компоненту, это делается вычитанием из временного ряда линии тренда. На основе таких простых вычислений строятся простейшие алгоритмы прогнозирования временных рядов.

Рис. 4.4. Временные ряды

График «Ящик с усами» (box plot, рис. 4.5) очень интересен; в некоторой степени он дублирует гистограммы, так как тоже показывает оценку распределения.

Рис. 4.5. Ящик с усами

Рис. 4.6. Ящики с усами для разных экспериментов

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

Общий подход к визуализации данных

Визуализация данных нужна для двух вещей: для исследования данных и для того, чтобы объяснить выводы заказчику. Часто для представления результатов используется несколько способов: простой комментарий с парой цифр, Excel или другой формат электронных таблиц, презентация со слайдами. Все эти три способа объединяют вывод и доказательство – то есть объяснение, как к этому выводу пришли. Доказательство бывает удобно выражать в графиках. В 90 % случаев для этого достаточно тех графиков, типы которых были описаны выше. Исследовательские графики и презентационные отличаются друг от друга. Цель исследовательских – найти закономерность или причину, их, как правило, много, и бывает, что они строятся наугад. Целью презентационных графиков является подведение ЛПР (лица, принимающего решения) к выводам в задаче. Тут важно все – и заголовок слайда, и их простая последовательность, которая ведет к нужному выводу. Важный критерий схемы доказательства вывода – как быстро заказчик поймет и согласится с вами. Необязательно это должна быть презентация. Лично я предпочитаю простой текст – пара предложений с выводами, пара графиков и несколько цифр, доказывающих эти выводы, ничего лишнего.

Джин Желязны, который работает директором по визуальным коммуникациям в McKinsey & Company, в своей книге «Говори на языке диаграмм» утверждает [28]:

«Тип диаграммы определяют вовсе не данные (доллары или проценты) и не те или иные параметры (прибыль, рентабельность или зарплата), а ваша идея – то, что вы хотите в диаграмму вложить».

Рекомендую вам обращать внимание на графики в презентациях и статьях – доказывают ли они выводы автора? Все ли вам нравится в них? Могли бы они быть более убедительными?

А вот что пишет Джин Желязны про слайды в презентациях [28]:

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

Я делал довольно много докладов: со слайдами и без, короткие, на 5–10 минут, и длинные – на час. Смею вас заверить, что мне намного сложнее сделать убедительный текст для короткого доклада без слайдов, чем презентацию в PowerPoint. Посмотрите на политиков, которые выступают: их задача убеждать, много ли из них показывают слайды на выступлениях? Слово убеждает сильнее, слайды – это всего лишь наглядный материал. И чтобы ваше слово было понятно и убедительно, требуется больше труда, чем для накидывания слайдов. Я себя поймал на том, что при составлении слайдов я думаю о том, как презентация выглядит. А при составлении устного доклада – насколько убедительны мои аргументы, как работать с интонацией, насколько понятна моя мысль. Пожалуйста, подумайте, действительно ли вам нужна презентация? Хотите ли вы превратить совещание в просмотр скучных слайдов вместо принятия решений?

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