newsmode
search
Меню
arrow_back Назад

Counterfactual Evaluation for Recommendation Systems

auto_awesomeКраткое саммари

Юджин Ян объясняет, почему стандартная оффлайн-оценка рекомендательных систем некорректна: мы используем наблюдательный подход, тогда как рекомендации — это интервенционная задача, ведь показанные товары меняют поведение пользователей. Альтернатива A/B-тестам — контрфактическая оценка, прежде всего Inverse Propensity Scoring (IPS), которая переоценивает залогированные награды через importance weight: отношение вероятностей рекомендации в новой и старой моделях. У IPS есть проблемы insufficient support и высокой дисперсии, которые решают Clipped IPS (CIPS) и Self-Normalized IPS (SNIPS). На туториале RecSys 2021 Юта Сайто показал на синтетических данных Open Bandit Pipeline, что SNIPS даёт наименьшую ошибку и не требует подбора параметров, хотя и увеличивает вычисления, ведь importance weight считается для всех наблюдений, а не только с ненулевой наградой. Автор не призывает отказываться от классической оффлайн-оценки, но рекомендует пробовать SNIPS при расхождении оффлайн-метрик с результатами A/B-тестов.

Контрфактическая оценка рекомендательных систем

[ recsys eval machinelearning ] · 8 мин чтения

Когда я только начинал работать над рекомендательными системами, мне казалось, что в том, как мы проводим оффлайн-оценку, есть что-то странное. Сначала мы делим данные о взаимодействиях пользователей на обучающую и валидационную выборки. Затем обучаем рекомендатели на обучающей выборке и оцениваем их на валидационной, обычно по таким метрикам, как recall, precision и NDCG. Это похоже на то, как мы оцениваем модели обучения с учителем, и на первый взгляд не вызывает вопросов.

Но разве наши рекомендации не меняют то, на что пользователи кликают или что покупают? Если пользователи могут взаимодействовать только с теми товарами, которые им показали, почему мы проводим оффлайн-оценку на статических исторических данных?

Наблюдательные и интервенционные задачи

Мне потребовалось время, чтобы сформулировать, в чём дело, но, кажется, именно поэтому это казалось странным: мы рассматриваем рекомендации как наблюдательную задачу, тогда как на самом деле это интервенционная задача.

Задачи, решаемые с помощью обучения с учителем, обычно являются наблюдательными. По наблюдению — например, названию товара, описанию и изображению — мы пытаемся предсказать категорию товара. Наша модель учит P(category=phone|title="…", description="…", image=image01.jpeg).

С другой стороны, рекомендации — это интервенционная задача. Мы хотим понять, как разные интервенции (т. е. рекомендации товаров) приводят к разным исходам (т. е. кликам, покупкам). Используя залогированные данные о взаимодействиях пользователей в качестве меток, наблюдательный подход к оффлайн-оценке игнорирует интервенционную природу рекомендаций.

В итоге мы оцениваем не то, будут ли пользователи кликать или покупать больше из-за наших новых рекомендаций; мы оцениваем, насколько хорошо новые рекомендации соответствуют залогированным данным. Таким образом, наша модель учит P(view3=iphone|view1=pixel, view2=galaxy), тогда как на самом деле нам нужно P(click=True|recommend=iphone, view1=pixel, view2=galaxy).

Оценка recsys как интервенционной задачи

Самый простой способ оценить рекомендации как интервенционную задачу — это A/B-тестирование. Наши интервенции (т. е. новые рекомендации) показываются пользователям, мы логируем их поведение, связанное с новыми рекомендациями, и затем измеряем, как меняются метрики вроде click-through rate и конверсии. Однако это требует больше усилий, чем оффлайн-оценка, циклы экспериментов могут быть долгими — нужно набрать достаточно данных, чтобы сделать вывод, — и существует риск выкатить заведомо плохой эксперимент. К тому же у нас может не быть простого доступа к A/B-тестированию, если мы работаем на исследовательской стороне.

Менее прямой подход — контрфактическая оценка. Контрфактическая оценка пытается ответить на вопрос: «Что бы произошло, если бы мы показали пользователям наши новые рекомендации вместо существующих?» Это позволяет нам оценивать исходы потенциальных A/B-тестов, не запуская их.

Самая известная техника контрфактической оценки — Inverse Propensity Scoring (IPS). Иногда её также называют inverse probability weighting/sampling. Интуиция в том, что мы можем оценить, как изменятся взаимодействия пользователей, — путём переvзвешивания того, как часто будет происходить каждое взаимодействие, — на основе того, насколько чаще (или реже) каждый товар показывается нашей новой рекомендательной моделью. Вот формула IPS.

Разбор оценщика Inverse Propensity Score

Попробуем разобрать её, начиная справа. В разделе 1 r обозначает награду за наблюдение. Это количество кликов, покупок или любая другая метрика, важная для вас, в залогированных данных.

Далее идёт importance weight. Знаменатель (раздел 2a) — это вероятность того, что наш текущий продакшен-рекомендатель (π0) сделает рекомендацию (она же action a) при контексте x; числитель (раздел 2b) — та же вероятность, но для нашего нового рекомендателя (πe). (π обозначает рекомендательную policy.) Для user-to-item рекомендателя x — это пользователь; для item-to-item рекомендателя x — это товар.

С помощью importance weight мы можем вычислить, насколько часто рекомендация делается новой моделью относительно существующей. Затем мы можем использовать это отношение, чтобы обновить наши залогированные награды. Например, у нас есть старая модель (π0) и новая модель (πe), которые рекомендуют iPhone на странице товара Pixel, но с разными вероятностями:

π0(recommend=iPhone|view=Pixel) = 0.4 πe(recommend=iPhone|view=Pixel) = 0.6

В этом сценарии новая модель будет рекомендовать iPhone в 0.6/0.4 = 1.5 раза чаще, чем старая. Поэтому при ненулевой награде (т. е. пользователь кликнул или купил) мы можем переvзвесить залогированную награду, считая её в 1.5 раза ценнее.

Наконец, мы усредняем по нашим данным (раздел 3) и получаем IPS-оценку (раздел 4) для нашего нового рекомендателя. Эта IPS-оценка показывает, сколько награды (т. е. кликов, покупок) получит новый рекомендатель относительно продакшен-рекомендателя, если новый рекомендатель будет показан пользователям.

Но как получить вероятность того, что будет сделана рекомендация (a) при контексте (x)? Можно нормализовать сырые скоры каждой рекомендации (через Plackett-Luce) и получить вероятность для каждой рекомендации. Альтернативно, если наши рекомендации предвычислены, можно посчитать частоту каждой рекомендации в нашем хранилище рекомендаций. Мой предпочтительный подход — использовать количество показов (impression count) для каждой рекомендации: я считаю, что это самая прямая мера вероятности сделать рекомендацию, и она лучше всего учитывает presentation bias.

Эта зависимость от вероятностей рекомендаций или количества показов, вероятно, объясняет, почему контрфактическая оценка не получила более широкого распространения в академических работах: большинство публичных датасетов их не включают. Исключение — Open Bandit Dataset, в котором есть вероятность рекомендации (action_prob) для каждого наблюдения рекомендации.

Примеры строк в Open Bandit Pipeline с вероятностями действий

Однако у IPS есть свои подводные камни. Один из них — insufficient support. Это происходит, когда наш оцениваемый новый рекомендатель (πe) делает рекомендацию (a), которую существующий продакшен-рекомендатель (π0) не делал. Тогда вероятность a у π0 равна нулю, и мы не можем посчитать importance weight. Это можно смягчить, сознательно показывая случайные выборки не рекомендованных товаров на небольшой части трафика, чтобы залогировать взаимодействия для потенциальных рекомендаций. (Спойлер: продактам это может не понравиться.) Более приемлемый подход — обеспечить, чтобы у всех подходящих товаров была ненулевая вероятность рекомендации, и затем сэмплировать по этой вероятности. Это даёт всем товарам шанс быть рекомендованными.

IPS также может страдать от высокой дисперсии, когда новая модель (πe) рекомендует сильно иначе, чем старая (π0). Предположим, π0 делает рекомендацию (a) с вероятностью 0.001, и мы залогировали один клик. Если πe делает ту же рекомендацию (a) с вероятностью 0.1, мы переvзвесим этот единственный клик в 100 раз — это, скорее всего, серьёзное завышение. Одно из решений — следить, чтобы оцениваемые новые рекомендатели не слишком отличались от продакшен-рекомендателя и importance weight не взрывался.

Другое решение — Clipped IPS (CIPS). CIPS позволяет задать максимальный порог для importance weight. Например, если наш порог 10, то importance weight больше 10 обрезается до этого значения. Однако настройка параметра обрезки может быть непростой.

Clipped Inverse Propensity Score

Ещё один подход — Self-Normalized IPS (SNIPS). SNIPS делит IPS-оценку на importance weight. Это перемасштабирование предотвращает завышение IPS-оценок. По сравнению с CIPS, SNIPS проще и не требует настройки параметра.

Self-normalized Inverse Propensity Score

Что работает лучше? На недавнем туториале RecSys 2021 Юта Сайто сравнил различные методы на экспериментах с синтетическими данными, сгенерированными через Open Bandit Pipeline, с 10 возможными действиями. Он также оценил direct method (DM), который мы не обсуждали. Если кратко, DM обучает модель импутировать пропущенные награды. Считайте, что это похоже на построение модели среды для обучения с подкреплением — такой как OpenAI gym или Criteo reco-gym, — которую мы затем можем использовать для обучения и оценки наших RL-моделей.

Сравнение различных IPS-оценщиков и Direct Method

Он обнаружил, что IPS обгоняет DM по мере роста объёма залогированных данных, а CIPS работает не сильно лучше IPS. В целом, SNIPS показал лучший результат (т. е. наименьшую ошибку) и без необходимости настраивать какие-либо параметры. В туториале также обсуждаются другие оценщики — например, Doubly Robust (комбинация DM и SNIPS), — а также контрфактическое обучение; настоятельно рекомендую ознакомиться.

Тем не менее, недостаток SNIPS в том, что он требует вычисления importance weight для всех наблюдений; в IPS importance weight нужен только для наблюдений с ненулевой наградой. Если учесть, что у большинства рекомендаций нулевая награда (<10% CTR или конверсии), SNIPS увеличивает требования к хранению вероятностей рекомендаций и вычислению importance weight в 10 и более раз. Тем не менее авторы SNIPS обнаружили, что рост вычислений компенсируется более быстрой сходимостью.

Ещё один инструмент в арсенале оценки recsys

В заключение поясню: я не предлагаю прекращать обучать и оценивать recsys-модели в наблюдательной парадигме. Несмотря на свои ограничения, у неё есть несколько достоинств. Во-первых, это устоявшаяся фреймворк оценки с множеством публичных датасетов и стандартных метрик. Это упрощает сравнение различных техник. Во-вторых, мы можем собирать данные для обучения и оценки ещё до развёртывания нашего первого рекомендателя. Данные о взаимодействиях пользователей генерируются органически, когда пользователи пользуются нашими платформами. Поэтому традиционный подход к оффлайн-оценке — хорошая отправная точка.

Тем не менее, если вам хочется попробовать новый подход к оценке или ваши оффлайн-метрики расходятся с результатами онлайн A/B-тестов, рассмотрите контрфактическую оценку через SNIPS. Кроме того, хотя я обсуждал контрфактическую оценку в контексте recsys, она применима и к другим задачам, где нужно симулировать A/B-тесты оффлайн.

Спасибо Arnab Bhadury, Vicki Boykis и Yuta Saito за чтение черновиков.

Ссылки

Если это оказалось полезным, пожалуйста, цитируйте эту заметку как:

Yan, Ziyou. (Apr 2022). Counterfactual Evaluation for Recommendation Systems. eugeneyan.com. https://eugeneyan.com/writing/counterfactual-evaluation/.

или

@article{yan2022counterfactual, title = {Counterfactual Evaluation for Recommendation Systems}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2022}, month = {Apr}, url = {https://eugeneyan.com/writing/counterfactual-evaluation/} }



Присоединяйтесь к 11 800+ читателей, получающих обновления о машинном обучении, RecSys, LLM и инженерии.