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

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