https://arxiv.org/pdf/1901.07555.pdf
Многие рекомендательные модели страдают от смещения рекомендаций на популярные объекта (которые попадают в рекомендации чаще, чем менее популярные). Однако персональные предложения объектов, которые оказываются в хвосте распределения по популярности, может быть критически важным с точки зрения бизнеса. В статье авторы предлагают способ, как можно разнообразить персонализированные подборки путем повторного ранжирования. Этот метод позволяет увеличить количество непопулярных объектов в рекомендациях, поддерживая при этом допустимую релевантность. Их метод является методом постобработки, который является универсальным для любых типов алгоритмов. Продемонстрировано также, что предлагаемый способ может эффективно бороться со смещением на популярные объекты, если сравнивать с существующими методами. В статье приводятся существующие и новые метрики, чтобы оценить покрытие объектов из хвоста распределения популярности.
Не смотря на то, что популярные объекты могут быть хорошими рекомендациями, они могут также быть хорошо известными для пользователей. В таком случае рекомендательная модель не ведет к знакомству с новыми объектами, которые были бы на самом деле интересны. Все объекты авторы подразделяют на три вида: очень популярные, средние по популярности (long tail), непопулярные (distant tail). Те объекты, которые можно отнести к средним по популярности, могут попадать в списки рекомендаций, хотя далеко не все алгоритмы будут их включать в свои итоговые ответы. То, что относится к distant tail, должно обрабатываться контентными либо гибридными моделями. Для коллаборативной фильтрации интеракций по этим айтемам недостаточно. Поэтому в данной статье фокус только на long tail.
Задача ставится примерно такая. Есть готовый отранжированный список R, его нужно превратить в другой список S, который будет учитывать смещение на популярные объекты. Такой список S будем строить итеративно. На некоторой итерации скоры будут определяться формулой:
, где
- лямбда отвечает за силу разреживания.
- P(u|v) - вероятность того, что пользователю u будет интересен объект v.
- P(c|u) - показатель того, насколько пользователь заинтересован в популярных/средних по популярности объектов.
- D - множество очень популярных объектов.
- D' - множество long tail объектов.
- P(c|u) считаем как долю объектов из соответствующей категории в интеракциях юзера.
- P(v|c) - бинарная величина (1 или 0), которая показывает, к какой категории популярности принадлежит v.
- P(i| c, S) - либо тоже бинарная величина, которая символизирует, что объект i из списка S принадлежит категории c. Либо же это просто доля объектов, которая в списке S принадлежит категории c. В первом случае, такая моделька может прокинуть вперед только один айтем из long-tail, поэтому это не способствует сильному разнообразию.
Таким образом, все величины легко посчитать. Добавление каждого айтема производится из R. Дополнительное слагаемое увеличивает шансы попасть в рекомендации для long-tail айтемов, так как оно больше 0 в том случае, если ни один объект, уже попавший в итоговый список, не принадлежит к long-tail. В качестве метрик предоставлены:
- Average Recommendation Popularity (APR) - среднее количество рейтингов в трейне
- Average Percentage of Long Tail Items (APLT) - процент long tail объектов в рекомендациях
- Average Coverage of Long Tail items (ACLT) - покрытие по айтемам из long tail.
В качестве модельки для рекомендаций был использован RankALS. Binary - вариант, где P(i| c, S) - была бинарной величиной, Smooth - пропорциональна количеству айтемов в текущем S из каждой категории.
На графиках видим, что по метрикам, которые отражают смещение на популярные объекты, предложенный метод работает неплохо. Интересно, что у RankALS почти нулевые показатели по рекомендациям непопулярных объектов. Тогда же как, теряя в качестве не сильно много (по NDCG), предложенный метод добавляет что-то несильно популярное.
Интересно, что binary и smooth способы отличаются несильно. Кажется, что причиной этому может быть невысокая глубина оценивания рекомендаций, всего 10.
Интересный подход, который, самое главное, не зависит от используемой модели. Что касается просадки в качестве на оффлайн тестировании, то возможно это не является сильным недостатком. Так как в самом тест-сете популярные айтемы будут преобладать. Поэтому, когда мы стараемся избавляться от них, то безусловно это должно влиять на метрики точности рекомендаций. Другими словами, оценивая RankALS и Smooth re-ranking метод, описанный здесь с помощью онлайн тестирования, возможно мы бы нашли больший интерес пользователей к рекомендациям от второго алгоритма.
Также количество переранжированных элементов для каждого пользователя равняется 100. Думаю, что это серьезный гиперпараметр, который влияет на результате. Однако его авторы не исследовали.