Подобные сервисы работают следующим образом. Заказчик загружает задание и датасет к нему, пишет инструкцию, назначает цену. В датасет можно добавить контрольные примеры. Они пригодятся, чтобы отсеять халявщиков, которые могут выполнять задания быстрее, случайно щелкая по ответам. Поэтому рекомендую обязательно использовать контрольные примеры. После выполнения всех формальностей исполнители получают возможность выполнять задания и получать за это деньги. По моему мнению, заработать там сложно, но как подработка это вполне себе вариант (вот оно, рабство XXI века люди на службе AI). От цены за задание зависит количество откликнувшихся исполнителей.
Для каждой задачи требуется свой инструмент. Если делать собственными силами долго, не хватает данных, то сервисы наподобие «Толоки» могут стать хорошим решением. Они позволяют очень хорошо масштабировать задачу и получать результат с приемлемым качеством. Да, за это придется заплатить, но сэкономленное время может с лихвой окупиться.
ML и большие данные
В 2016 году на конференции ACM Recsys я обратил внимание, что компании Netflix и Quora не рекомендуют пользоваться распределенными системами машинного обучения [68]. Причина проста они работают намного медленнее, чем параллельные вычисления на одной машине. Я сам столкнулся с этим, когда мы считали GBRT (Gradient Boosting Regression Tree) модель, используя наш вычислительный кластер и библиотеку MLLib в Spark. В тот момент мы пробовали это делать на одной машине, в память данные не поместились, поэтому воспользовались распределенным алгоритмом. Все бы хорошо, но он считал модель два часа. Это слишком долго, учитывая, что модель была совсем несложная. Тогда мы оптимизировали данные и попробовали посчитать на локальной библиотеке Smile на Java. Все посчиталось за пять минут.
Проблемы с распределенными алгоритмами происходят из-за медленной сетевой скорости. Различным нодам кластера приходится постоянно координироваться между собой, передавать данные и параметры по обычной локальной сети. Скорость работы с памятью примерно в 50 раз быстрее гигабитной сети, поэтому локальные вычисления на одной машине работают значительно быстрее. Да и одна машина стоит гораздо дешевле, чем использование дорогого кластера.
Recency, Frequency и Monetary
Впервые с закономерностями поведения клиентов я познакомился в книге Джима Ново [71]. Джим рассказывал в книге о не знакомом мне тогда способе сегментации RFM: Recency (давность), Frequency (частота) и Monetary (деньги).
Recency давность какого-либо действия клиента. Для сегментации очень важно эмпирическое свойство Recency чем меньше времени прошло с момента последней активности клиента, тем вероятней, что он повторит действие. Например, пусть Recency это давность последнего заказа клиента. Нужно сравнить двух клиентов: у первого давность последнего заказа 30 дней (30 дней назад он сделал свой последний заказ), у второго 70 дней. Как вы думаете, какой клиент с большей вероятностью повторит заказ? Правильно, первый (давность 30 дней).
Frequency количество действий, которые совершил клиент. Для нас важно свойство Frequency чем больше каких-либо действий совершит клиент, тем больше вероятность того, что он повторит их в будущем. В литературе и на сайтах основателей этого метода не ограничивается временной интервал, в течение которого измеряется Frequency. По своему опыту скажу, что ограничивать этот интервал нужно. Например, считать Frequency только в течение 360 дней, предшествовавших дате анализа. Пусть Frequency количество заказов, сделанных в течение 360 дней: у первого клиента 10 заказов, у второго клиента 5 заказов. Понятно, что у первого клиента вероятность сделать в будущем заказ выше, чем у второго.
Monetary сумма денег, которую потратил клиент. Здесь все, как у Frequency, нужно постараться ограничить время, в течение которого измеряется величина; и чем больше денег было потрачено, тем больше вероятность того, что клиент вновь сделает заказ. На практике Monetary обычно не используют, так как этот показатель сильно коррелирует с Frequency. Поэтому RFM-сегментация в большинстве случаев называется RF-сегментацией.
Итак, у нас есть два параметра для сегментации Recency (далее R) и Frequency (далее F), оба эти параметра могут прогнозировать дальнейшее поведение клиента c определенной точностью. И если объединить их в один параметр RF то точность прогноза повышается в разы. Далее я приведу последовательность шагов (по методике Джима Ново):
Итак, у нас есть два параметра для сегментации Recency (далее R) и Frequency (далее F), оба эти параметра могут прогнозировать дальнейшее поведение клиента c определенной точностью. И если объединить их в один параметр RF то точность прогноза повышается в разы. Далее я приведу последовательность шагов (по методике Джима Ново):
Параметр R бьется на пять частей, и появляются пять значений от 1 до 5. 5 это когда заказ был сделан совсем недавно.
Параметр F бьется на пять частей, и появляются пять значений от 1 до 5. 5 это когда клиент в течение определенного периода времени (этот период тоже нужно рассчитать) сделал очень много заказов.
Строится RF-сетка (grid): в виде двузначной комбинации R и F. 55 сегмент лучших клиентов, 11 самых худших клиентов.
Вычисляются вероятность совершения следующего действия для каждого сегмента.
25 RF сегментов объединяются по вероятностям (из прошлого шага) в большие сегменты.
С точки зрения RFM, самый лучший клиент это тот (рис. 9.3), который совершил покупку совсем недавно, до этого сделал их много на хорошую сумму денег. Этот фундаментальный принцип помог создавать фичи, которые предсказывают вероятность совершения действий в дальнейшем. Его можно распространить на любые действия людей, кроме покупок: вероятность заболеть, вероятность вернуться на сайт, вероятность попасть в тюрьму, вероятность кликнуть на баннер. Всего лишь с помощью этих переменных и простой линейной модели на одном из конкурсов Kaggle я смог получить очень неплохой результат. Для лучших результатов, кроме действительных цифр, я использовал бинарное кодирование. За базу можно взять сегментацию, о которой я написал выше. Можно брать отдельно переменные R и F или целиком RF.
Рис. 9.3. RF-сегментация
Последний совет
Кроме каких-либо теоретических книг в качестве дополнительных источников знаний рекомендую два бесплатных ресурса: книгу Эндрю Ына [60] про практику машинного обучения и правила Google для инженерии ML-проектов [72]. Они помогут в дальнейшем совершенствовании.
Глава 10
Внедрение ML в жизнь: гипотезы и эксперименты
Все эксперименты проводятся для того, чтобы дать фактам возможность опровергнуть нулевую гипотезу.
Сэр Рональд Фишер, «Планирование экспериментов» (1935)Модели ML рождаются, живут и умирают. Жизнь меняется, это закон природы: если что-то долго не меняется, то оно умирает. Улучшая и оптимизируя модель, мы даем ей новую жизнь и надежду. Помочь нам в этом могут гипотезы (или идеи) и эксперименты, подтверждающие или отвергающие гипотезы. В 2016 году на сцене концертного зала MIT я рассказывал про то, как убивать гипотезы как можно раньше. Доклад зашел на ура, поэтому я решил изложить те идеи и выводы в этой главе.
Гипотезы
Гипотеза это идея по улучшению продукта. Неважно, что это сайт, товар или магазин. Существует даже должность менеджера по продукту, одной из задач которого является создание и поддержание списка таких гипотез, расстановка приоритетов их исполнения. Список гипотез еще называют бэклогом (backlog). Он является важным стратегическим элементом развития компании. Как придумывать гипотезы и расставлять их в порядке приоритетов тема отдельной большой книги. Если кратко, идеальная ситуация выглядит так продуктологи взаимодействуют с рынком, с существующими и потенциальными клиентами, изучают конкурентные решения, проводят фокус-группы, чтобы понять, сколько то или иное изменение (гипотеза) принесет компании денег. На основе этих исследований гипотезы попадают в список и приоретизируются. Бизнес требует денежных метрик для приоритезации гипотез, чем точнее они подсчитаны, тем лучше. Но в реальности с большинством гипотез сделать это очень сложно, и оценка происходит по принципу «пальцем в небо». Самые громкие коммерческие успехи в истории были революционными, а не эволюционными вспомните хотя бы появление первого iPhone.
Приоритизация гипотез служит главной цели как можно быстрее достичь успеха. Если следовать этой логике, идеи, которые с большей вероятностью могут дать результат, должны быть первыми в списке на реализацию. Но у каждой гипотезы есть такая характеристика, как сложность ее реализации, вот почему, приоритизируя гипотезы, важно оценивать их трудоемкость и стоимость инфраструктуры (сервера, наем дополнительного персонала). Допустим, первая гипотеза обещает принести примерно 10 млн рублей за год, при этом затраты на ее реализацию это месяц работы двух разработчиков и одного аналитика данных. Вторая обещает 2 млн рублей за год, при этом реализовать ее смогут два человека за пять дней работы. Какую гипотезу выбрать первой? Это решение я оставляю за менеджментом, однозначного совета дать здесь не могу.