RecSys + DSSM + FPSLoss is all you need

Упрощать и искать похожие детали, очень полезный навык! Предлагаю быстро пробежаться и попробовать найти ту самую серебряную пулю в RecSys !

Введение

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

В современных системах чаще используются модели с поздним связыванием (late interaction): есть две независимые башни для query и doc, которые преобразуют их в вектора. Далее релевантность аппроксимируется через скалярное произведение: . Это может быть клик/не клик или ручная разметка.

Важно: скалярное произведение не нормировано, так как качество выше, если модель сама учит регулизацию. Если грамотной регулизации нет — лучше использовать нормированые вектора(aka косинусная мера).

Почему это удобно?

• Можно независимо в оффлайне пересчитывать документы, не зависеть от рантайма.

• Не нужно каждый раз пересчитывать декартово произведение (doc, query) векторов.

• Можно построить KNN и искать быстро!

• Универсальный интерфейс, подходящий для многих задач.

• Можно эффективно считать FPS (Full Product Softmax) — ранее связывание + претраин FPS + SFT эффективнее, чем позднее связывание без FPS претраина.

Что такое DSSM? Звучит мощно, не так ли?

В 2008 году Microsoft выпустили статью Learning Deep Structured Semantic Models for Web Search using Clickthrough Data ^[1], где показали DSSM (Deep Semantic Similarity Model): две башни (query, doc) и в таргете клик! С тех пор это название закрепилось за таким дизайном моделей.

Теперь ты знаешь, что значит это сокращение захватившее все продакшены бигтехов там где есть DL :D

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

Классический пример башен — трансформеры над последовательностями + MLP (для категориальных/вещественных признаков и результата трансформера).

Ранжирующие лоссы

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

В течении написания наткнулся на офигетельный хендбук Яндекса по рексису. Многое буду брать от туда ^[2]

Важное наблюдение:

Некоторые авторы пытались вместо косинусной меры использовать обучаемый MLP, но это оказалось неэффективно.

Обозначения

• , — эмбеддинги объектов

• — релевантность (помним, при нормализации векторов)

Основной трюк в обучении ^[3] рекомендательных систем — сбор сэмплов из клика (обычно одного) и множества негативов (практически любой другой документ). Но использовать слишком много негативов неразумно! Здесь помогает negative sampling (ещё из Word2Vec ^[4]). Обычно берём 1 позитив () и –20 негативов ().

PointWise | Softmax Loss

Классический способ — предсказывать абсолютную вероятность:

Pairwise loss | PairCE + TripletLoss

Теперь важно лишь, что релевантнее .

Pair Cross-Entropy loss (PairCE):

Triplet loss:

Все эти лоссы учат отталкивать разнорелевантные пары. Softmax Loss дополнительно учит предсказывать вероятность, что усложняет задачу для сетки, ведь для ранжирования это избыточно.

ListWise | FPSLoss

Часто используют PairCE/TripletLoss с одним кликом и кучей негативов — это похоже на ListWise, но можно ли придумать что-то новое? Да! В игру мощно врывается — CLIP ^[5] (2021), решает задачу — определение семантической близости картинки и текста, где найден эффективный способ получения негативов.

Full Product Softmax loss (FPSLoss):

Собираем батч размера : , где — запрос, — документ, — релевантность (обычно положительная, часто клик и равен 1).

Составляем матрицу эмбеддингов запросов , документов и вектор таргетов .

Тогда перемножение матриц — это эффективный подсчёт dotproduct, а далее и вероятностей:

Остаётся, как и в Softmax, взять элементы только с диагонали:

Интуитивно понятно, что учится относительная вероятность при условии query . Обращу внимание ^[6], что легко можно добиться смену местами query и doc.

Также заметим, как хитро и качественно теперь негативы собираются!

А что с этим делать?

Предлагается следующее:

• Определить архитектуры башен: наверняка это должна быть комбинации BERT ^[7] + MLP

• Собрать очень много данных для FPS лосса (обычно яркий положительный фидбек пользователя)

• Сделать долгий претраин на FPS

• Дофайнтюниться на свою задачу, если нужно

Заключение

Этим хотел показать, общий вид DL RecSys и на самом деле все кроется в маленьких деталях. Абсолютно точно, для каждой задачи нужно относиться критически и замерять профит от каждого действия, что в рексисе является очень не простой задачей!

Если статья была полезна — ставьте лайк, подписывайтесь и делитесь своим опытом ^[8] в комментариях!