Как стать автором
Обновить

Дропаем ранжирующие метрики в рекомендательной системе, часть 1: визуальный анализ и popularity bias

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров6.6K
Всего голосов 18: ↑18 и ↓0+18
Комментарии2

Комментарии 2

Привет! Есть пару комментов

1) Если я правильно понял, ты показываешь, как нелогично к одному фильму (запросу) рекомендуются другие, и строишь гипотезы на них. На мой взгляд, модель рекомендует к одному фильму другие нелогичные, просто потому, что пользователи так себя ведут. Ты фактически показываешь, что фильмы к запросу непохожи на фильм-запрос. Однако, кажется, модель не решает задачу нахождения похожих фильмов к твоему. Вероятно, пользователи смотревшие "фильм-запрос" также смотрели и другие фильмы из рекомендаций (твоих примеров справа), поэтому не очень понял, как связана непохожесть и оценка popular bias?

2) в этом датсете, насколько я его помню, действительно большой pop bias. Но предположу, что это не "результат работы прошлой рекомендательной модели". Если там был чисто датасет из интеракций людей, то много разных причин влияли на то, смотрит человек что-то или нет. Например, если на главной всем показывали огромным банером "Девятаева", то он и вышел популярным в итоге. И люди сначала смотрели что-то интересное, а потом смотрели этот фильм. И все модели обязаны оптимизироваться под этот факт, поэтому и получаются такие рекомендации

3) вообще было бы интересно, можно ли решить эту проблему на уровне алгоритма. Есть ведь подходы, которые отдельно моделируют популярность фильма и отдельно интерес к нему. Потому что как показывают некоторые статьи, можно даже на сильно смещенном датасете генерировать хорошие recall/map, но с меньше bias'ом

1) Примеры тут для того, чтобы хоть немного показать, насколько обманчивыми бывают высокие результаты по конкретной метрике (например MAP), и что за ними по факту может скрываться в рекомендациях. Повторяющаяся типичная ошибка на множестве запросов, найденная на визуальном анализе - повод для того, чтобы добавить в валидацию метрику, которая сможет отражать эту ошибку количественно. Так, я начинала с классических MAP и Recall. Построенная модель часто рекомендовала непохожие на запрос фильмы, причём одни и те же (тот же "Девятаев", да). Я начала искать причину - увидела, что это фильмы из топа просмотров в датасете. Сделала гипотезу, что у модели popularity bias. Ввела на валидации метрики, которые отражали бы popularity bias количественно. В статье привожу пересечение с популярным алгоритмом. Для модели из соревнования на этой метрике получила 62%, сравнила с другими моделями, подтвердила гипотезу о popularity bias. Продолжила ресёрчить модели, на этот раз снижая popularity bias. Непохожесть рекомендаций на множестве запросов - сигнал о том, что у модели есть проблемы, и что возможно, с этим что-то стоит сделать (зависит от бизнес кейса). Безусловно, во всех моих примерах у фильмов-запросов и фильмов в рекомендациях была общая аудитория, тем более что я здесь показываю почти целиком коллаборативную фильтрацию, то есть - модель в любом случае рекомендует на основе со-встречаемости. Но даже простой bm25 уже можно чётко настраивать под то, стоит ли отдавать предпочтение популярным айтемам, или наоборот.

2) Да, топ просмотров явно идёт от внешних факторов, я тоже думаю, что мощно влияют баннеры на главной, и вполне вероятно - внешняя реклама. Модели на этот bias в исторических данных реагируют сильно, но на мой взгляд в кейсе онлайн-кинотеатра это важно лечить, потому что такие рекомендации не имеют особой ценности. Я для себя в этом проекте пыталась решить задачу именно персонализированных рекомендаций.

3) Ну тут сразу вспоминается lightfm, например. Вопрос в том, как потом считать финальные рекомендации. Мы всё равно должны прийти к какой-то формуле: например, сгладить рассчитанный bias и снизить его вес в финальном скоре, отдавая больший вес скалярному произведению эмбеддингов юзера и айтемов-кандидатов. Но такую формулу тоже нужно как-то валидировать, подбирая аргументы. Да и в любой модели мы должны тюнить гипер-параметры. Мой основной посыл в этой статье - внимательно выбирать, на какую метрику мы их тюним, решая задачу строго персонализированных рекомов. Я тут предлагаю одним из вариантов Recall без популярного. Саша Петров (@asash), который меня ревьюил, предлагал смотреть в сторону popularity-sampled метрик, как в статье Амазона "Don't recommend the obvious..." (https://dl.acm.org/doi/abs/10.1145/3523227.3546753). Ещё я встречала классическиe Recall и NDCG, но в тестовых интеракциях делалался down-sampling для популярных айтемов (https://arxiv.org/abs/2204.12176).

У меня сейчас самый большой интерес именно в том, чтобы найти метрики, максимизация которых приводила бы к желаемому результату или хотя бы была сильно ближе, чем Recall, MAP или Serendipity. Буду благодарная за ссылки)

В плане моделей очень перспективным кажется опять же подход Амазона - не менять модели, но менять лосс с тем, чтобы нивелировать popularity bias, если есть такая задача.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий