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

Второе, на что важно обратить внимание, – пользователи должны попадать в группы равномерно, не должно быть смещений по разным срезам пользователей. Например, в тесте участвуют две группы пользователей: юридические и физические лица, первых всего 10 %, а вторых 90 %. После разбиения на группы это соотношение изменилось – в контрольной группе 7 и 93 % соответственно, в тестовой – 12 и 88 %. У этого явления могут быть две причины. Первая – есть закономерность в назначении идентификаторов клиентов, и эти данные используются в назначении групп. Вторая – юридических лиц слишком мало в абсолютных цифрах, и выборка нужна больше. Последнюю причину проще отсечь – нужно попытаться собрать больше данных, если наблюдаемая разница исчезнет, то все в порядке. Если нет – нужно разбираться с процедурой назначения. Обратите внимание на то, что «срезы» лучше сходятся, когда используется разбиение 50/50, а не какое-нибудь экзотическое 90/10. В меньшую группу попадает всего 10 % пользователей.

И третье, что нужно иметь в виду, – на выбранной метрике ваш статистический критерий должен показывать отсутствие статистической значимости, ведь мы показываем пользователю одно и то же. Из опыта скажу – любые бинарные (биномиальные) тесты сходятся намного лучше и быстрее, чем тесты с непрерывной шкалой. Конверсия сайта (процент посетителей, сделавших покупку) сойдется лучше, чем средняя стоимость покупки (средний чек). Причин, с моей точки зрения, две. Первая – низкая вариабельность конверсии (только два значения – купил или нет), вторая – «выбросы» в метриках с непрерывной шкалой. Выброс в тестах – это редкое событие, например, очень дорогая покупка. В какую группу она попадет, там и будет сразу «улучшение» метрики. Согласитесь, такой результат никого не устроит. Поэтому есть определенная практика – срезать небольшой процент данных «сверху» (удаляем самые дорогие заказы), пока А/А-тест не сойдется. Эту практику применяют в 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/Б-тестом. Но почему в нашем случае рекомендаций товаров он расходится? С моей точки зрения, это происходит по двум причинам. Во-первых, товарные рекомендации изменяют действия пользователя, поэтому расчет метрик рекомендаций на старых данных обладает слабой предсказательной способностью. Во-вторых, нашей основной метрикой являются «угаданные» товары в покупках. Цикл принятия решений может растянуться на дни. Если бы мы предсказывали клик на товар – все было бы намного проще.

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