Роман с Data Science. Как монетизировать большие данные - читать онлайн книгу. Автор: Роман Зыков cтр.№ 50

И третье, что нужно иметь в виду, – на выбранной метрике ваш статистический критерий должен показывать отсутствие статистической значимости, ведь мы показываем пользователю одно и то же. Из опыта скажу – любые бинарные (биномиальные) тесты сходятся намного лучше и быстрее, чем тесты с непрерывной шкалой. Конверсия сайта (процент посетителей, сделавших покупку) сойдется лучше, чем средняя стоимость покупки (средний чек). Причин, с моей точки зрения, две. Первая – низкая вариабельность конверсии (только два значения – купил или нет), вторая – «выбросы» в метриках с непрерывной шкалой. Выброс в тестах – это редкое событие, например, очень дорогая покупка. В какую группу она попадет, там и будет сразу «улучшение» метрики. Согласитесь, такой результат никого не устроит. Поэтому есть определенная практика – срезать небольшой процент данных «сверху» (удаляем самые дорогие заказы), пока А/А-тест не сойдется. Эту практику применяют в Retail Rocket. Теоретически вместо арифметического среднего можно использовать медиану – она более устойчива к выбросам.

Отдельно хочу рассказать про перекрывающиеся тесты (interleaving tests), множественные тесты и многоруких бандитов (multi-armed bandits). Перекрывающиеся тесты заключаются в смешивании выдачи двух групп в одну, при этом создатель теста знает, когда, кому, какие элементы из групп (тестовой или контрольной) были показаны. Такой способ применяют поисковые системы, когда дорабатывают алгоритмы. Пользователю показывается ответ на его поисковые запросы, где на части позиций (например, четных) показывается контрольный, а на остальных – тестируемый алгоритм. То есть здесь тестируют, разделяя не пользователей, а позиции в выдаче. И часто это делают случайно, сохраняя данные по каждому показу. Мы делали такие тесты для рекомендаций товаров. И как раз наши внутренние A/A-тесты нам помогли увидеть, что у нас была проблема с генератором случайных чисел, реализация которого отличалась от Retail Rocket Segmentator [85].

Множественные тесты мы тоже используем, но я согласен с авторами книги «Семь главных правил экспериментов на веб-сайтах» [84]: лучше делать тесты проще и сегменты «пожирнее», тогда на выходе получится выше надежность решений, да и приниматься они будут быстрее. Сравним хороший тест с двумя группами 50/50 и тест с четырьмя группами 25/25/25/25 (пропорции разбиения). Первый тест сойдется минимум в два раза быстрее, так как данных в каждом сегменте в два раза больше.

Многорукие бандиты (multi-armed bandits) – очень популярная тема в наши дни. Это направление вышло из обучения с подкреплением (reinforcement learning) [86]. Представьте себе казино: зал с игровыми автоматами, дергая за ручку которых можно получить выигрыш. На некоторых автоматах можно выиграть чаще. Алгоритм тестирования подразумевает использование стратегии «исследуй-эксплуатируй» (explore – exploit). Исследование заключается в том, что мы последовательно дергаем ручки всех автоматов. «Эксплуатация» заключается в том, чтобы дергать чаще ручки тех, которые дают больший выигрыш. Комбинируя эти две стратегии, мы можем найти лучшую комбинацию автоматов с индивидуальной частотой дерганья ручки – менее выгодные дергаются намного реже «счастливых». Например, первый автомат нужно дергать в 10 раз реже, чем второй. Это альтернатива А/Б-тестам, где мы находим только один выигрышный вариант. В этом есть свои плюсы – когда выводим новый алгоритм в бой, то просто добавляем его в список автоматов. Стратегия «исследуй» нужна потому, что среда меняется, и со временем «счастливые» автоматы могут стать «несчастливыми», и наоборот. В долгосрочном варианте многорукие бандиты работают лучше, чем А/Б-тесты. Но я считаю, что это менее надежная схема. Поэтому рекомендую обращаться к ней только тогда, когда вы научитесь хорошо проводить A/Б-тесты – их можно использовать для калибровки многоруких бандитов.

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

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

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

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

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