DSSM в задаче рекомендаций

Быстрая генерация рекомендаций

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

Вопрос: чем плохо обучить xgboost по паре user-item предсказывать релевантность и, упорядочив все итемы по релевантности, взять топ-k?

Ответ: потому что в большинстве случаев мы не успеем сделать этого в онлайне. Представьте что у нас музыкальный стриминг и размер нашей базы музыки - 2 миллиона треков. Для генерации рекомендаций для пользователя нам придется сделать predict 2 миллиона раз - по предикту на каждый трек. Это займет слишком много времени и, скорее всего, пользователь просто не дождется загрузки рекомендаций. Если возникнет соблазн “закидать проблему железом” (распараллелить все на тысячи машин) - вспомните что в каждый момент времени за рекомендациями приходит не один пользователь, а тысячи, если не десятки, а то и сотни тысяч.

Из абзаца выше становится ясно, что нас не устраивает генерация рекомендаций за O(N), где N - общее количество item’ов. Можно ли генерировать рекомендации быстрее?

Быстрее генерировать можно, в большинстве случаев для этого используется метод приближенного поиска ближайших соседей (approximate KNN). Если пользователи и item’ы описываются векторами, а релевантность item’а пользователю описывается близостью их векторов, то поиск топ-k самых релевантных item’ов сводится к поиску k ближайших соседей. Стоит отметить, что современные реализации approximate KNN под близостью могут понимать как Евклидово расстояние, так и часто используемые в рекомендациях cosine similarity (1 минус косинус угла между векторами) и negative dot product. Работает approximate KNN за O(log(N)), что, в отличие от O(N), нас устраивает. Одна из крутых open-source реализаций approximate KNN живет здесь https://github.com/nmslib/nmslib.

Именно из-за необходимости генерировать рекомендации через approximate KNN мы вынуждены использовать модели, которые моделируют релевантность с помощью скалярного произведения эмбеддингов.

DSSM

Оригинальная статья: https://www.microsoft.com/en-us/research/publication/learning-deep-structured-semantic-models-for-web-search-using-clickthrough-data

В оригинальной статье речь идет о задаче информационного поиска. Идея следующая: есть запрос и документы. Запрос и каждый документ описываются 500к каких-то признаков, намайненных из текста. Давайте сделаем две “башни” с полносвязными слоями и нелинейностями: одна башня будет для запросов, вторая для документов. На выходе каждая из этих башен будет выдавать вектор размерности 128. Эти выходные вектора и будут эмбеддингами запроса и документа, а косинус угла между этими векторами будет моделировать релевантность документа запросу (здесь и далее Q - query, D - document).

Когда модель уже обучена, нам потребуется прогнать все документы через правую башню этой сети чтобы получить 128-ми мерные эмбеддинги документов. Когда мы будем получать запрос пользователя, мы будем прогонять этот запрос через левую башню, получать 128-ми мерный эмбеддинг и искать ближайшие эмбеддинги документов, что, как мы выяснили ранее, мы умеем делать за O(log(N)).

Оффтоп: в 2020 исследователи из того же Microsoft предложили аналогичный подход, в котором в каждой из башен MLP поверх текстовых фичей заменяется на BERT (конспект здесь: https://vk.com/wall-154085965_402), но сегодня мы будем обсуждать классические DSSM с фичами и полносвязными слоями.

Loss function

Обучать модель предлагается при помощи negative sampling’а. Релевантность мы моделируем косинусом:

Для каждого положительного примера (пары запрос-документ, где был клик пользователя), мы возьмем 4 случайных документа и будем считать что этому запросу они не релевантны. Обозначим полученное множество документов D, получим предсказания для 5 пар (текущий запрос + каждый из 5 документов) и применим softmax:

где gamma - гиперпараметр модели (smoothing factor или softmax temperature). Итоговый лосс будет выглядеть так:

где D+ - документ, по которому был клик с запросом Q.

Интересно что в большинстве работ по DSSM в рекомендациях и во всех работах, о которых сегодня пойдет речь, лосс выглядит именно так.

Multi-View DSSM

https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/frp1159-songA.pdf

Переходим от поиска к рекомендациям: запрос теперь - это пользователь, а документы - item’ы.

Авторы статьи немного расширили подход. Рассматривается задача кросс-рекомендаций, в которой нужно рекомендовать пользователю item’ы из разных доменов (новости, игры, музыку, …) Предлагается для каждого такого домена обучать свою башню, но один объект из обучающей выборки (пара user-item) при обучении будет затрагивать только ту башню, к которой относится item из этой пары.

Размерность исходного признакового представления в этой работе порядка миллионов признаков (5М для пользователя и 3М для item’а). Речь идет скорее всего в основном о категориальных признаках высокой кардинальности (в том числе потенциально user_id и item_id).

Deep Neural Architecture for News Recommendation

http://ceur-ws.org/Vol-1866/paper_85.pdf

В следующих статьях все активнее используется тот факт что мы можем сколь угодно усложнять модель без ущерба времени генерации рекомендаций.

В этой работе авторы предлагают для генерации эмбеддинга пользователя использовать LSTM с attention поверх последовательности item’ов, с которыми взаимодействовал пользователь.

r_1, …, r_R - 300 мерные эмбеддинги item’ов, с которыми взаимодействовал user, item+ - эмбеддинг item’а, с которым у user’а было взаимодействие (кроме тех, которые фигурируют в LSTM), item- - эммбеддинг item’а, с которым у user’а не было взаимодействия.

Шарятся ли эмбеддинги r и item+/item- из статьи я не понял, а код, к сожалению, авторы выкладывать не стали (в 2017 выкладывать код еще не стало мейнстримом).

Фичи пользователя в этом подходе не используются, фичи item’а потенциально могут использоваться при генерации 300 мерного эмбеддинга item’а (опять-таки не понятно из статьи, речь об обучаемых эмбеддингах или о предобученных).

Multi-Rate Deep Learning for Temporal Recommendation

http://sonyis.me/paperpdf/spr209-song_sigir16.pdf

Авторы пытаются учесть изменение интересов пользователя при помощи LSTM, но в отличие от предыдущей работы используют не attention, а несколько LSTM с разной гранулярностью по времени. Fast-Rate-RNN призвана отслеживать самые последние изменения интересов пользователя и может опираться, скажем, на дневные агрегаты активности пользователя, а Slow-Rate-RNN призвана отслеживать сезонные изменения интересов и может опираться на недельные агрегаты. Как именно агрегируется активность в клики из статьи я не понял, код, к сожалению, авторы не выложили.

В целом архитектура выглядит так:

Есть две башни для user’ов и item’ов (как в классической DSSM) плюс башня из нескольких LSTM для моделирования изменения интересов пользователя во времени. Функция F(W1, W2) занимается объединением static и temporal user features, авторы пробовали в качестве f брать конкатенацию и (взвешенное) поэлементное произведение.

Еще одна интересная идея, которая предложена в статье - pretrain. Предлагается сначала обучать без temporal части, а затем обучать только temporal часть. Авторы утверждают pretrain значительно ускоряет обучение, но сравнения результатов с pretrain и без него в статье нет.

Мое мнение

• Очень не хватает кода. Ответы на какие-то простые вопросы по архитектуре модели (шарятся ли параметры в каком-то месте, какие активации используются) намного проще найти в коде, чем листая статью. Как хорошо, что в 2021 доля статей с кодом значительно выше, чем в 2016
• В статье и в Multi-View DSSM (а возможно и в двух оставшихся статьях) используют tanh активацию между всеми скрытыми слоями (не говорю про LSTM, говорю про полносвязные куски). Есть ощущение что эту функцию выбрали в 2013 году и в последующих статьях просто не пытались пересмотреть этот выбор. Учитывая известную проблему с затуханием градиентов в tanh, кажется имеет смысл попробовать здесь более привычный ReLU
• Negative sampling. В статье 2013 года про DSSM в поиске утверждается, что разницы в том как именно генерить отрицательные пары нет. В последующих работах этот вопрос не затрагивается. Мне кажется, в рекомендациях это может быть важно хотя бы потому что меньшая часть item’ов как правило составляет большую часть взаимодействий и, выбирая случайный item, мы скорее всего возьмем достаточно редкий item, который окажется слишком легким примером для модели. То есть, сэмплировать стоит как минимум пропорционально популярности. Как максимум, возможно стоит попробовать прикрутить сюда hard negative mining
• Релевантность == косинус. Во всех статьях, которые мне попадались, релевантность item’а user’у моделируется косинусом. Интуитивно кажется, что dot для этого подходит лучше - тогда норма вектора item’а будет отвечать за его популярность, а собственно косинус - за релевантность. Обоснования почему используется именно косинус я не нашел

Источник: m.vk.com

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