Да кто такие эти ваши producer-side A/B-тесты?
В своей яндексовской эре работы над рекомендациями я точечно работал над качеством ранжирующей модели и не выглядывал за пределы этой области. Та же история была и в рекомендательном периоде работы в X. Но тут один добрый человек рассказал мне, что я оказывается жизни-то вообще и не знаю. Качество системы с точки зрения пользователя это ещё половина проблемы.
Дело в том, что для долгосрочного качества платформы и процветания бизнеса необходимо смотреть на то, как изменение системы влияет на производителей контента (что в соцсети, что в маркетплейсе). В самом экстремальном случае система может показывать пользователям очень маленькую прослойку разнообразных авторов и игнорировать остальных. Те могут расстроиться и перестать постить, тем самым ухудшить долгосрочную ситуацию.
Влияние на авторов и замеряется с помощью этого самого
producer-side A/B теста. Посмотрим на то, как выглядит наивная её реализация в контексте рекомендаций.
Среди всех авторов выделяем 2 группы - контрольную и тестовую - к примеру, по 1%. Скор для (98+1)% документов считается дефолтной моделью, тогда как для тестового набора из 1% будем предсказывать новой моделькой. Допустим, что она отдаёт большее предпочтения мелким авторам.
Такой тест покажет прекрасный результат - все мелкие авторы счастливы и стали генерировать больше контента. Классический user-side тест, допустим, показал нейтральные метрики. Вроде бы всё в шоколаде, и вы шипаете изменение в прод, но вот беда - эффект испарился.
Задроты вам укажут - на лицо нарушение Stable Unit Treatment Value Assumption. Перевожу на русский - изменение ведёт себя по-разному в зависимости от доли, на которую его раскатили. Тот кусочек мелких авторов среди 1%-ной выборки получил преимущество перед 99% таких же вне её. Раскатив изменение, весь рост показов, которые они получили в AB-тесте, размажется на остальные 99%.
Чтобы побороть этот эффект, нужен фреймворк посложнее. Одно из решений предлагается в статье от Меты - "
A Counterfactual Framework for Seller-Side A/B Testing on Marketplaces". Не знаю, насколько в ней это впервые предложили - может и нет, мне не важно.
Иллюстрация на картинке. Итак, теперь мы будем оценивать 100% постов обеими системами - старой и новой (синей и зелёной). Для документов из контрольной выборки мы получаем их финальные позиции, как если бы мы ранжировали все 100% документов так, как обычно - они обозначены как C_1 и C_2. В то же время, документы из тестовой выборки получают свои финальные позиции так, как если бы все 100% документов ранжировала новая система - это T_1 и T_2.
Финальную выдачу для пользователя мы создаём, расставляя эти документы на их соответствующие позиции, закрывая глаза на коллизии и помещая случайно друг под другом, если позиции точно совпали. Самый прикол этой схемы в том, что на ранжирование остальных 98% документов в принципе всё равно - до выкатки это будет старая система, после выкатки это будет новая система, но размер эффекта на документы в обоих случаях ожидается одинаковый.
Именно это в том числе и проверяют авторы данной работы. В нижней части слева расположена выдача до выкатки - pre-test, а справа после выкатки - back-test. Авторы приводят результаты своих тестов, в которых демонстрируют одинаковость эффекта на измеряемые документы. Такая схема тестирования гораздо ближе к SUTVA.
Надо понимать, что эта грёбаная SUTVA никогда не выполняется полностью. Любая выкатка изменяет распределение данных для обучения и последующее ранжирование. В обычных пользовательских A/B-тестах на это закрывают глаза и надеются, что эффект сохранится, что часто подтверждается holdback-экспом. А вот с авторскими A/B-тестами приходится проделывать такую гимнастику, чтобы хоть как-то подобраться к честному замеру.
@knowledge_accumulator