Избранные статьи о рекомендательных системах с конференции KDD 2022

A data scientist reading a scientific paper while riding a unicorn (Stable Diffusion 2)A data scientist reading a scientific paper while riding a unicorn (Stable Diffusion 2)

Предлагаем вашему вниманию разбор конференции KDD 2022 от ML команды Одноклассников. Такие разборы стали традицией, и в этот раз нам опять помогали коллеги из ВК, за что им большое спасибо. Мы подготовили краткое изложение восьми статей из области рекомендательных систем. Как нам кажется, эти статьи отражают текущие тенденции в науке о рекомендациях. Все меньше предлагается новых архитектур, и больше внимания уделяется корректной постановке задачи: как учесть долгосрочные эффекты рекомендера, скорректировать смещения и надежно завести это все в продакшен. Наши изложения не претендуют на полноту, но, прочитав их, вы поймете, о чем идет речь в статьях, и при желании изучите их подробнее. Надеемся, что вам понравится!

В этом выпуске:

  • Настраиваем рекомендательную систему на долгосрочную цель >>

  • Трансформерные рекомендеры в продакшене >>

  • Чиним positional bias рекомендера >>

  • На лету выбираем лучший источник рекомендаций >>

  • Чиним popularity bias рекомендера >>

  • Чиним duration bias рекомендера видео >>

  • Настраиваем рекомендательную систему с помощью reinforcement learning >>

  • Добавляем разнообразия в рекомендации видео >>

Surrogate for Long-Term User Experience in Recommender Systems 

Автор разбора @anokhinn

ссылка

Авторы решают задачу настройки рекомендательной системы на долгосрочную цель. Основная идея — приблизить долгосрочную метрику с помощью краткосрочных метрик и встроить полученное приближение в существующий рекомендательный сервис. Детали рекомендательного алгоритма играют второстепенную роль: предложенный подход работает для любого рекомендера. 

Детали

Исторически рекомендательные системы настраиваются на краткосрочные метрики, например клики или лайки. Несмотря на удобство краткосрочных метрик — их легко считать и оптимизировать — у них есть важный недостаток: они плохо отражают «счастье» пользователя. Долгосрочные метрики, такие как доля возвратов на платформу, наоборот позволяют измерить качество пользовательского опыта в целом. Но долгосрочные метрики сложно оптимизировать:

  • Долго ждать, пока накопятся данные для подсчета долгосрочной метрики (если мы хотим измерить возвраты пользователей в течение года, то данные нужно ждать целый год).

  • Изменение долгосрочной метрики невозможно ассоциировать с конкретной рекомендацией (как понять, в какой момент мы показали настолько неудачную рекомендацию, что пользователь решил уйти с платформы).

Чтобы справиться с этими проблемами, авторы используют понятный подход: найдем краткосрочные метрики, которые хорошо приближают долгосрочные и настроим на них рекомендер. Улучшение таких краткосрочных метрик приведет к улучшению долгосрочных.

Выбор краткосрочных метрик

Долгосрочная метрика построена на частоте заходов пользователей в видео-сервис. Поведение пользователей бывает двух типов: низкочастотное (L: заходит редко) и высокочастотное (H: заходит часто). Задача рекомендера — побудить низкочастотных пользователей стать высокочастотными на горизонте 20 недель. Нужно выбрать краткосрочные метрики, оптимизируя которые, рекомендер успешно справится со своей задачей.

Авторы сравнивают пользователей, которые начинали низкочастотными, но постепенно стали высокочастотными (L-H) с пользователями, кто начинал и остался низкочастотными (L-L). Утверждается, что краткосрочные метрики, по которым можно различить эти типы пользователей, будут хорошим приближением для долгосрочной цели рекомендера. В качестве краткосрочных метрик предлагаются метрики разнообразия, повторные просмотры видео, долгие просмотры видео, частотные тематики видео и интервалы времени между заходами на разные страницы сервиса. Отбор делается с помощью random forest, который предсказывает тип пользователя (L-L vs L-H) по краткосрочным метрикам, рассчитанным за первый месяц. Победили две метрики:

  • Dentropy — энтропия распределения по тематикам видео, которые посмотрел пользователь.

  • Trevisit — среднее время между заходами на главную страницу сервиса.

Следующий шаг — учесть эти метрики при обучении рекомендера и измерить, улучшит ли это долгосрочную частоту заходов пользователя.

Использование в рекомендере

В статье задача рекомендаций поставлена в терминах reinforcement learning. Рекомендер обучается с помощью алгоритма REINFORCE. Чтобы учесть выбранные метрики при обучении модели, нужно встроить их в reward. 

Энтропия встраивается так:

R_t(s_t, a_t) = R_0(s_t, a_t) \exp \left[ m(D_{entropy}(s_t) - D_{entropy}(s_{t-1})) \right]

Интуитивно, reward увеличивается, если просмотренное на шаге t видео увеличило разнообразие по тематикам в истории просмотров пользователя. И наоборот: если разнообразие уменьшилось, то на reward накладывается уменьшающий множитель. Если видео на шаге t не просмотрено, то reward нулевой, так как R0(st, at)=0.

Среднее время между заходами учитывается похожим образом:

R_t(s_t, a_t) = R_0(s_t, a_t) [1 + c I(T_{revisit} \leq T_0)]

Если на шаге t среднее время между заходами меньше заданного порога, reward увеличивается на c

Обе модификации reward показали долгосрочный рост метрик рекомендера в A/B экспериментах.

Анализ

Идея, изложенная в статье, не новая: приближение долгосрочных метрик краткосрочными для обучения моделей известно давно. Интересно, что авторы довели эту идею до реализации на боевом рекомендере и показали долгосрочный рост. Несмотря на то, что метод можно повторить почти для любого рекомендера, не совсем понятно, будет ли он эффективен для классической постановки, или применение reinforcement learning имеет ключевое значение для успеха.

NxtPost: User To Post Recommendations In Facebook Groups

Автор разбора @boloz

ссылка

В статье представлена архитектура системы рекомендаций групповых постов в фейсбуке. Эта архитектура работает на базе трансформеров и решает следующие проблемы: огромное количество постов, актуальность постов и различные виды фидбека с разных устройств. В качестве результатов авторы статьи говорят о 49% росте оффлайн метрики Batch Hits@K и о 0.6% росте количества групп, с которыми взаимодействуют пользователи. 

Детали

NxtPost — это two-tower трансформер, который использует XLM-R энкодер для получения эмбеддингов из текста, предобученные модели для извлечения эмбеддингов из картинок и видео. При этом эмбеддинги картинок комбинируются при помощи Deep Sets Fusion. К полученным эмбеддингам добавляются добавляется метаданные, например, страна пользователя, публикующего пост и язык поста. Также модель учитывает кратковременные и долговременные интересы пользователя.

b5ed3881901176546328aa510c377949.jpeg

Авторы приводят примерную архитектуру их рекомендательной системы. Кратко можно сказать следующее:

  1. Создание (изменение) поста запускает асинхронный расчёт (перерасчёт) его эмбеддинга. Эмбеддинг поста хранится в распределенной файловой системе и кэше​.

  2. Эмбеддинги пользователей пересчитываются ежедневно, для пользователей у которых есть новые взаимодействия с постами. Хранятся эмбеддинги пользователей в ​key-value distributed memory lookup store​.

Анализ

Статья сосредоточена на применении трансформерной архитектуры в рекомендациях. Как утверждают авторы, с помощью предложенной архитектуры им удалось побить предыдущий бейзлайн Wide & Deep Learning for Recommender Systems. Помимо оффлайн метрик авторы приводят результаты A/B экспериментов, в которых они зафиксировали прирост вовлеченности пользователей на 0.6%.

Scalar is not Enough: Vectorization-based unbiased Learning to Rank

Автор разбора @Anvar5710

ссылка

Авторы решают проблему несмещенного обучения ранжированию рекомендательной системы. Расширяется понятие examination hypothesis (EH гипотезы) и на основе нее строится несмещенная модель.

Детали

EH гипотеза — разложение вероятности клика на две скалярные функции: функция ранжирования (релевантность айтема r) и функция смещения (вероятность, что пользователь увидит айтем). Авторы предлагают рассмотреть векторный вариант этой гипотезы, так как на практике взаимодействия между функциями ранжирования и факторами смещения сложны, и скалярные функции не могут описать все возможные взаимодействия. 

Однако векторная EH гипотеза на выходе дает вектор, что неудобно для ранжирования документов. Авторы вводят понятие базового вектора, на который проецируется результат разложения, чтобы получить скаляр. По этому скаляру сортируются документы в списке релевантности. Авторы берут базовый вектор как самый вероятный фактор смещения среди n текущих векторов.

Несмещенная модель ранжирования основывается на векторной EH гипотезе. Признаки делятся на два типа: признаки ранжирования x, от которых зависит релевантность r, и признаки предвзятости t, от которых зависит вектор смещения o. Итоговая вероятность клика зависит как от признаков ранжирования x (через релевантность), так и от признаков предвзятости t (через смещение).

dfdf5292aab552e2e48e71a276c32aee.png

Обучение модели происходит в две стадии.

Первая стадия: обучение relevance и observation model. Relevance model — модель ранжирования документов, учит предсказывать релевантность item-a, обучается на ранжирующих признаках x. Observation model — модель смещения, учится предсказывать вероятность, что пользователь увидит item. Она учится на признаках предвзятости t. Итого, первая стадия — это выполнение EH гипотезы.

Вторая стадия: векторная EH гипотеза дает вектор, а нам нужен скаляр на выходе для сортировки документов по релевантности. Для решения этой проблемы нужно обучить base model, которая будет выдавать базовый вектор. Обучение base model происходит на основе векторов из observation model o, так как базовый вектор берут как самый вероятный фактор смещения среди предложенных observation векторов.

Inference. Основная цель — отранжировать документы. У нас есть модель, которая дает вектора релеватности (relevance model). Однако это вектора, а нам нужны скаляры для сортировки, поэтому мы проецируем полученные вектора релевантности на базовый вектор, полученный из base model для данных векторов. В итоге, у нас скаляры ri, по которым мы сортируем документы и выдаем пользователю.

Анализ

Статья показалась интересной, хотя идея не новая — это развитие EH гипотезы. Реализовать такой подход вполне возможно. Однако предложенная модель не имеет такого большого прироста по метрикам, даже проигрывает некоторым рассмотренным в статье бейзлайнам.

Device-cloud Collaborative Recommendation via Meta Controller

Автор разбора @rds29

ссылка

46df75ef21c45f406983aac85ee8dc1b.png

При взаимодействии с рекомендательной системой через мобильное приложение пользователь может получать рекомендации тремя основными способами:

  1. заранее подготовленные оффлайн рекомендации,

  2. рекомендации, которые были дополнительно переранжированы на мобильном устройстве с учетом последних действий пользователя,

  3. рекомендации, которые постоянно переранжируются удаленным сервисом.

Авторы статьи предлагают реализацию «мета контроллера», призванного автоматизировать переключение между этими 3 подходами с помощью машинного обучения для поиска компромисса между качеством рекомендаций и стоимостью их получения. Основная проблема, возникающая при решении данной задачи — это подготовка датасета для обучения. Авторы предлагают использовать методы причинно-следственного анализа (causal inference): создание counterfactual датасета. Такой метод генерации предполагает, что один из трех подходов, например, оффлайн генерация, берется за базовый, а для остальных двух при помощи CATE и T-Learners рассчитывается размер эффекта относительно базового подхода.

Предлагаемый алгоритм:

  1. подготовить датасеты отдельно для каждого из трех подходов;

  2. обучить модели на этих датасетах предсказывать вероятность того, что пользователю понравятся рекомендации;

  3. рассчитать CATE для каждого сэмпла из всех трех датасетов;

  4. на основании CATE выбрать для каждого сэмпла подход, дающий наибольший положительный эффект;

  5. получаем объединенный датасет, в котором каждой записи соответствует подход, которым стоит воспользоваться для получения наилучшей рекомендации;

  6. обучаем классификатор и дополнительно штрафуем модель за выбор третьего подхода, т.к. считаем его самым вычислительно дорогим;

  7. получаем модель, которая выполняет роль мета контроллера.

Авторы проверили свой подход на трех датасетах: Amazon, MovieLens и Alipay. В каждом случае им удалось превзойти качество рекомендаций моделей без мета контроллера, но улучшение NDCG@5, AUC и HitRate@1 во всех случаях было всего около 1%.

Анализ

Авторы статьи  решили интересную инженерную задачу, но улучшение полученных офлайн метрик выглядит совсем незначительным. Поэтому применимость данного подхода на практике остается под вопросом.

Model-Agnostic Counterfactual Reasoning for Eliminating Popularity Bias in Recommender System

Автор разбора @AlexeyShik

ссылка

Многие модели в целях минимизации loss«а отдают предпочтение популярным item«ам, а не тем, которые лучше всего подходят конкретному пользователю. Такой вид смещений в данных называется «Popularity bias». Авторы статьи разработали фреймворк, позволяющий снизить частоту популярных item«ов за счет большего влияния user-item фичей на итоговый score.

Детали

Авторы предлагают рассмотреть два мира. В мире (a) user-item признаки K зависят от признаков пользователя U и признаков item«а I, а итоговое предсказание Y зависит от всех трех категорий признаков. Таким образом учитывается и персонализация, и bias«ы пользователя и item«а. 

В мире (b) связь между признаками пользователя U, признаками item«а I и user-item признаками K разрывается: на предсказание влияют только признаки пользователя U и item«а I. В этом мире нет персонализации, потому что для обучения user-item признаков вместо признаков пользователя и item-а используются их средние значения u* и i*.

9d55f68f88a413d97122529ab9ed0f3f.png

Используя соображения causal inference, авторы определяют итоговый score модели как разность предсказаний в мире (a) и в мире (b) с гипер-параметром »c».

\hat y_k \cdot  \sigma(\hat y_i) \cdot \sigma(\hat y_u) - c \cdot \sigma(\hat y_i) \cdot \sigma(\hat y_u)

В формуле нижний индекс соответствует вершине графа, а домик означает, что score получается за счет обучения модели. Например, yk — это предсказание рекоммендера (на рисунке ниже, Conventional Recsys), отражающее, на сколько пользователю u подходит item i.

Реализация

Предложенный авторами подход использует многозадачное обучение. Обучаются три компонента:

  • В User module используется модель, обозначенная User model, для обучения score yu на основании только признаков пользователя. Оптимизируется лосс LU.

  • В Item module используется модель, обозначенная Item model, для обучения scorer yi на основании только признаков item«а. Оптимизируется лосс LI.

  • В Recommender части используется модель, обозначенная Conventional Recsys, для обучения score yk на основании признаков и пользователя, и item«a. Полученный yk в схеме называется Matching и обозначает user-item соответствие. После чего на основании score«ов yu, yi, yk по формуле выше определяется score yu, i (на схеме модели соответствующий компонент называется Fusion). Оптимизируется лосс LO.

Если проводить аналогию с мирами из прошлого абзаца, то в мире (a) обучаются yu, yi, yk, а в мире (b) обучаются только yu, yi. Затем по формуле вычисляется причинно-следственный эффект. Причем в левую часть формулы подставляются score из мира (a), а в правую часть — из мира (b).

da8673582c31f1af5d44b2e7b957258f.png

В качестве лоссов LO, LI, LU используется binary cross-entropy loss. Итоговый лосс L определяется как

L_O + \alpha L_I + \beta L_U.

Эксперимент

Важная особенность проведенного авторами эксперимента заключается в том, что user-item взаимодействия в тестовой и валидационной выборке распределены равномерно по item«ам. Таким образом, в тестовой и валидационной выборках нет явно популярных item«ов и эксперимент проверяет именно устойчивость построенной модели к popularity bias. 

В общем случае в качестве модели user-item признаков (Conventional Recsys на схеме) может быть использована произвольная user-item модель. В эксперименте авторы используют Matrix Factorization и LightGCN для сравнения данного метода избавления от popularity bias с аналогами. В обоих случаях данный подход оказался лучше предыдущих по представленным в статье метрикам, в частности, лучше текущего SOTA (DICE_MF, DICE_LightGCN).

14dc49a70a9549e2e7dae5a59a7295fc.png

Отмечу, что в статье не приводится результатов эксперимента, если тренировочная и валидационная выборка не распределены равномерно по item«ам. Интересно, как изменятся результаты в таком случае.

Анализ

Подход очень простой, красивый, эффективный и не зависит от архитектуры user-item модели. Однако для его применения в продакшене придется аккуратно выбирать гиперпараметр c, чтобы и получить снижение popularity bias, и не просадить продуктовые метрики.

Deconfounding Duration Bias in Watch-time Prediction for Video

ссылка 

Автор разбора @submaps

Предсказание времени просмотра видео — ключевая задача для вовлечения пользователей в видеосервис. Однако предсказанное время просмотра не всегда зависит только от степени релевантности видео для пользователя. Иногда оно может быть ложно скоррелировано с длительностью видео. Такой эффект возникает, потому что часто рекомендательная система видеосервиса стремится увеличить как таргет проведенное пользователем время (time spend) и предлагает видео с большей длительностью, а не только большей релевантности пользователю. На рисунке показано чем больше длительность видео, тем больший разброс в значениях watch-time.

ecfda04079f5b59e75b55133510e54d0.png

Из-за этой ложной корреляции модели ранжирования склонны отдавать предпочтения более длительным видео. Для решения этой проблемы авторы предлагают свой подход Duration-Deconfounded Quantile-based (D2Q). Идея — создать модель, и управлять её инференсом через causual графовую модель. Благодаря этому, в графе причинно-следственных связей явным образом убирается ложное влияние. Также в работе используется эмпирическая оценка квантиля, в который попадает видео по длительности.

Авторы перечисляют существующие методы борьбы со смещением модели:

Данная работа относится к третьей категории casual intervention. С помощью каузального вмешательства авторы устраняют нежелательное влияние продолжительности на видео, при этом сохраняя желаемое влияние продолжительности на время просмотра.

В статье предлагается представить зависимость параметров видео сервиса в виде causal графа и далее исключить влияние нежелательного смещения, убрав дугу между вершинами D и V. Это меняет формулу условной вероятности зависимости других узлов и соответственно убирает влияние на распределения таргета — времени просмотра. Такой подход называется backdoor adjustment.


    
            <p class=© Habrahabr.ru