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

Как-то со мной произошла интересная история. Мы в Retail Rocket искали инвестиции, и на встречу нас пригласил Яндекс. Маркет. Один парень из Яндекс спросил, используем ли мы офлайн-тесты, принятые в машинном обучении? Я ответил, что нет. Мои партнеры тогда взялись за голову. Сотрудничества с Яндексом так и не случилось. Почему они нам отказали – не знаю, но могу предположить, что они посчитали меня профаном. Офлайн-тесты у кабинетных исследователей рекомендаций – единственный способ оценить их эффективность. После этого случая я проштудировал всю литературу по теме. Мы вывели все формулы метрик, принятые научным сообществом. В итоге оказалось, что офлайн-тесты слабо коррелировали с нормальными A/Б-тестами, которые я проводил. Поэтому моя изначальная стратегия разработки алгоритмов, основанная только на A/Б-тестах, оказалась верной. Но зачем тогда вообще нужны офлайн-тесты?

Напомню, что такое офлайн-тест: это моделирование A/Б-теста на старых данных. Если у меня есть датасет (лог) действий старых пользователей, то я могу на одной его части обучить алгоритм, а на другой – проверить его эффективность. В идеале он должен хорошо сходиться с настоящим A/Б-тестом. Но почему в нашем случае рекомендаций товаров он расходится? С моей точки зрения, это происходит по двум причинам. Во-первых, товарные рекомендации изменяют действия пользователя, поэтому расчет метрик рекомендаций на старых данных обладает слабой предсказательной способностью. Во-вторых, нашей основной метрикой являются «угаданные» товары в покупках. Цикл принятия решений может растянуться на дни. Если бы мы предсказывали клик на товар – все было бы намного проще.

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

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

Конвейер экспериментов

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

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

В этот момент вы поймете, что время прохождения гипотезы от начала до конца конвейера – очень большое. Особенно время на А/Б-тесты. И скорее всего, сделаете вывод, что было бы неплохо «убивать» неудачные гипотезы до того, как они пройдут хотя бы половину пути [23]. Это очень здравая идея – как можно раньше отвергнуть неудачную гипотезу, чтобы не тратить время и силы на обреченный проект. Именно таким способом мне в Retail Rocket удалось уменьшить среднее время прохождения гипотез через наш конвейер экспериментов с 90 дней до 45.

Глава 11 Этика данных