EBR в рекомендательных системах: перспективы мультизадачности
Статья о любопытном подходе к EBR (Embedding-based retrieval) для учёта нескольких интересов пользователя. Авторы не просто растят diversity и fairness, но и утверждают, что увеличивают общее качество. В статье это показано на примере SASRec, но в теории подход сработает для любых трансформеров над историей пользователя.

Суть — в кластеризации исходного множества айтемов на подмножества, в которые на этапе retrieval ходят отдельными kNN. При этом в каждом кластере обучают отдельный таск и рассматривают задачу в целом как multi-tasking learning (MTL).

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

В экспериментах авторы проводили кластеризацию через K-means на Word2Vec, но также можно использовать уже имеющееся in-house разбиение документов на категории.

Три подхода к MTL
В статье описано три варианта реализации multi-tasking learning. Первый подход — наивный, где на вход добавляется ещё один обучаемый вектор. Работает это не очень хорошо — у модели не получается выучить взаимодействия между фичами.

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

Третий подход — MoE (Mixture of Experts), где используется несколько специализированных сетей — экспертов — для решения одной задачи. Он работает лучше, чем наивный multi-tasking, но хуже, чем покомпонентное умножение, и получается дороже по времени обучения.

По нашему мнению, подход с разбиением на кластеры будет полезен не только в сценариях с рекомендациями на всём множестве айтемов, но и для конкретных срезов — то есть рекомендаций или поиска внутри категорий.

@RecSysChannel

Разбор подготовил ❣ Артём Мышкин

Трансформеры в рекомендательных системах
Высокая гетерогенность фичей мешает использовать трансформеры в рекомендательных системах. Ресёрчеры из Google поделились статьёй, где предложили решение: модифицированный attention-слой позволил уловить связи, важные для предсказания итогового таргета. В тестах подход показал рост ключевых метрик (клики, покупки) — например, +0,4% по сравнению с DCN.

Подготовка фичей
На вход модели подаются cat- и dense-фичи. Cat-фичи обрабатываются стандартно (для них строятся обучаемые эмбеддинги), а с dense-фичами поступают чуть сложнее: их нормализуют, конкатенируют, применяют линейное преобразование, а потом сплитуют по D — внутренней размерности трансформера. Так фичей становится меньше.

Heterogeneous Attention Layer
Здесь матрицы query, key и value (QKV) считают отдельно для каждой фичи. Чтобы вычислить итоговый вектор для токена, вектора со всех голов, отвечающих фичам, конкатенируются и умножаются на матрицы.

Затем данные идут на Feed Forward-слой (FFN) с активацией GELU. Полученный вектор и будет выходом attention-слоя. Количество операций по сравнению с обычным трансформером не растёт, увеличивается лишь число параметров.

Hiformer
Чтобы уловить сложные взаимодействия, систему снова модифицируют — создают одну большую матрицу фичей. Затем конкатенируют все фичи каждой головы, умножают их на матрицу и получают модифицированные вектора. Благодаря этому получается выявить новые закономерности и связи, в т. ч. между composite-фичами и task-эмбеддингами.

Оптимизация
С большой матрицей трансформер становится тяжёлым с точки зрения latency — его нужно оптимизировать. Авторы используют низкоранговое разложение и прунинг последнего слоя. В первом случаем мы уменьшаем сложность за счёт разложения большой матрицы на две матрицы меньшего ранга.

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

@RecSysChannel
Разбор подготовила ❣ Маргарита Мишустина

Улучшаем Sequential Recommendation с помощью Guided Diffusion, часть 1
Поговорим о моделях, генерирующих следующий айтем на основе предыдущих взаимодействий пользователя — это может быть трек в плейлисте, видео, товар и т. д. По словам авторов статьи, SR обычно работает в парадигме learning-to-classify — получает позитивы, выполняет сэмплинг негативов, дополняет ими выборку и обучается. При этом неизвестно, видел ли юзер полученные айтемы и считает ли их нерелевантными. Альтернатива — использовать диффузию и перейти к learning-to-generate.

Пользователь примерно понимает, что хочет найти. Этот гипотетический айтем авторы называют oracle. Не факт, что он существует — тогда человек выберет что-то близкое из предложенных вариантов. Но именно «оракула» должна сгенерировать Guided Diffusion-модель.

Как это сделать
В прямом процессе на обучение берётся известный таргет и постепенно зашумляется. Незначительный гауссовский шум добавляется на каждом шаге (их тысячи), в итоге приходя к стандартному нормальному шуму. В обратном процессе мы избавляемся от шума, обуславливаясь на исторический контекст пользователя, закодированный трансформером в обобщающий вектор. Это позволяет выйти за рамки конкретных айтемов и сэмплировать абстрактное предложение.

Авторы описывают три подхода к диффузии:
— DDPM — оптимизация нижней вариационной оценки логарифмов правдоподобия наблюдаемых таргетов, которая сводится к оптимизации дивергенции Кульбака — Лейблера. Основной метод, использующийся в статье.
— Непосредственное рассмотрение двух марковских цепочек — если расписать score-функцию, этот подход эквивалентен певрому.
— Проведение аналогии между СДУ и диффузионной моделью актуально для генеративных моделей, т. к. позволяет получить логарифм нулевого распределения на таргетах и замерять им качество на этапе инфиренса.

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

@RecSysChannel
Разбор подготовил ❣ Сергей Макеев

Улучшаем раннюю стадию ранжирования рекламы
Сегодня — статья о ранжировании рекламы. Как и в других рекомендательных системах, в нём 3 стадии:

• Retrieval — отбор объявлений из баз, необязательно с помощью ML (~миллионы объявлений).
• Ранняя стадия ранжирования (~тысячи объявлений).
• Финальное ранжирование (~сотни объявлений).

Value считают на обоих этапах ранжирования, а итоговую оценку получают в финале. Учитывают:
• ставку рекламодателя;
• кликовые/конверсионные прогнозы;
• качество рекламы, оно же фидбек. Например, клик по крестику говорит, что объявление нерелевантно.

Проблемы ранней стадии ранжирования

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

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

Решение

Фреймворк с мультитаргет-архитектурой. В нём есть shared-часть — она выдаёт эмбеддинги, которые идут в 3 головы:
• Первая предсказывает CTR.
• Во второй происходит дистилляция — главная фишка статьи. Модель с нижних стадий обучают на разметке моделей с финальной стадии ранжирования
• Третья — Consolidated Quality Score — учится на целевые действия кроме кликов: результаты опросов, долгие конверсии и др. Для каждого баннера считается их вероятность, а таргет берётся из финальной стадии.

Финальная модель обучается на сумму loss’ов — важно аккуратно подбирать веса, чтобы ничего не просело.

Мультитаргетная архитектура позволяет экномить ресурсы и не сильно терять в качестве. Проблему selection bias решают, добавляя в датасет негативы.

Оценивают симулятором — он считает вероятный топ в оффлайне. Так получают golden-сет, с которым сравнивают результаты прода.

@RecSysChannel
Разбор подготовила ❣ Маргарита Мишустина

⏰ Добавляем таймстэмпы в модели Sequential Recommendation
Статья от Amazon о том, как передать время события в трансформер — в основном на примере BERT4Rec. Для этого есть сложившиеся подходы, и авторы предлагают 2 метода: близкий к «классике» и оригинальный.

Основная идея — мультиразмерный таймстэмп: время события делят на 5 представлений: год, месяц, неделя, день недели и час дня, прибавляя их комбинацию к эмбеддингам событий на входе трансформера. Получаются категории, отвечающие за периодичность. Значения нормализуют до ≤ 1. Кроме исторических событий берут таймстэмп текущего запроса (query time) — в BERT4Rec его просто добавляют к маске.

Projection-based подход
В таймстэмпе два вида полезной информации: время и его отличие от других событий в истории. Модель должна «видеть» временные паттерны, учитывая разницу между таймстэмпами. Чтобы достичь этого, вычисляют векторы, используя ядро — функцию от разности таймстэмпов. Оно хорошо подходит для трансформера, т. к. в attention эмбеддинги сравниваются через скалярное произведение, смоделированное ядром.

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

Embedding-based подход
Компоненты мультиразмерного таймстэмпа рассматривают как категориальные фичи, ограниченные по количеству значений. Для каждой фичи ведут таблицу эмбеддингов — 24 эмбеддинга для часа дня, 7 для дней недели и т. д. Их конкатенируют и получают финальный эмбеддинг таймстэмпа.

По словам авторов, embedding-based метод работает лучше, когда данных много, т. к. модель может выучить нужную структуру эмбеддингов сама, без ограничения конкретным методом вроде ядра. Но в экспериментах много спорного: в 2 датасетах из 4 нет информации о часовых поясах; для больших и маленьких датасетов используют разные размерности эмбеддингов, а также странным образом делят данные на трейн, валидацию и тест — без полного таймсплита, отчего результаты могут быть некорректными.

Однако сама идея разбиения таймстэмпа интересная — хочется провести свой эксперимент 🤓

@RecSysChannel
Разбор подготовил ❣ Денис Бурштеин