Diffusion-based Contrastive Learning for Sequential Recommendation

Сегодня разбираем статью о подходе Contrastive Learning в Sequential Recommendation (SR).

Авторы ставят под вопрос существующие методы аугментации цепочек последовательных заказов с целью генерации новых цепочек:

— Маскирование и переупорядочивание истории пользователя, представленной разреженными товарами, может исказить предпочтения.
— Подмена айтема похожим (CoSeRec) не учитывает контекст, так как использует лишь информацию о взаимной встречаемости товаров.
— Двойной forward pass c разными dropout-масками (DuoRec) тоже теряет смысловую последовательность.

Вместо перечисленного предлагается использовать guided-диффузию для оценки условного распределения айтема, обусловленного на контекст прошлых и будущих заказов. Чтобы сблизить латентное пространство диффузионки и SR-модели (в этом случае — SASRec), их обучают вместе, end-to-end, деля между ними эмбеддинги айтемов.

Кодирование последовательности и SR-модель: history += positional embeddings ➡️ transformer ➡️последний токен последовательности. Следующий айтем предсказывается через скалярное произведение векторного представления истории пользователя и эмбеддингов айтемов.

Цель обучения — минимизировать BCE со случайными негативами.

Аугментация

Из последовательности S извлекается подмножество S' с фиксированным соотношением |S'| / |S|. После чего элементы S' заменяются на семантически близкие айтемы, предложенные диффузионкой.

Контрастивное сближение аугментированных последовательностей

Берётся батч последовательностей, каждая из которых аугментируется дважды с помощью случайных подмножеств, после чего аугментации кодируются трансформером. Две аугментированные версии одной последовательности считаются позитивными и противопоставляются оставшимся 2*(batch_size — 1) аугментированным последовательностям, которые выступают как негативы. Лосс рассчитывается с помощью кросс-энтропии.

Диффузия для аугментации

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

Итоговый лосс рассчитывается в end-to-end сценарии, где суммируются три компоненты: BCE для SR-модели, контрастивное сближение и VLB для диффузионки.

@RecSysChannel
Разбор подготовил Сергей Макеев
2 005 просмотров · 16 реакций Открыть в Telegram · Открыть пост на сайте
Towards Understanding the Overfitting Phenomenon of Deep Click-Through Rate Prediction Models

Сегодня делимся статьёй о резком переобучении CTR-моделей в начале второй эпохи, a.k.a. one-epoch phenomenon.

Этой проблеме подвержены модели со структурой вида categorical features with large sparsity ➡️ Embedding ➡️ MLP.

Чтобы понять, можно ли справиться с феноменом, авторы всесторонне его анализируют. Так, на качество обучения CTR-моделей не влияют:

— число параметров модели;
— вид функций активации и батч сайз;
— weight decay и dropout (без dropout, кстати, лучше).

Из-за чего же тогда могут переобучаться модели? По результатам экспериментов, есть несколько причин:

— Оптимизаторы. Чем быстрее сходимость, тем сильнее отрицательное влияние на обучение. Наиболее подвержены эффекту Adam и RMSPROP.
— Высокие LR: эффект наблюдается только если они больше 10⁻⁷.
— Кардинальность фичей. Чем меньше уникальных эмбеддингов, тем слабее эффект. Авторы рассматривали FILTER (использовали m% эмбеддингов наиболее частых ID, остальные — в один эмбеддинг), Hash (создавали табличку с m% строк от общего числа ID, далее — хэшировали ID в эмбеддинги).

Обязательное условие one-epoch феномена — сдвиг между распределениями p(x_{trained}, y) и p(x_{untrained}, y), вызванный обучением на фичах высокой кардинальности, например, ID товаров. Если этот сдвиг есть, модель поверх эмбеддинг-слоёв моментально переобучается под p(x_{trained}, y).

На картинках показаны нормы изменений параметров слоёв. Легко заметить, что в начале второй эпохи резко меняются параметры слоёв поверх эмбеддингов. Это доказывает разницу в распределениях p(x_{trained}, y) и p(x_{untrained}, y).

Можно, конечно, просто не использовать эмбеддинги товаров, чтобы избежать переобучения, но это сильно просадит пиковое качество. Вывод авторов — обучать CTR-модели лучше в одну эпоху.

@RecSysChannel
Разбор подготовил Сергей Макеев
2 104 просмотров · 15 реакций Открыть в Telegram · Открыть пост на сайте
User-Creator Feature Polarization in Recommender Systems with Dual Influence

Сегодня разбираем необычную статью, содержащую много математики.

Авторы изучают две проблемы link prediction:

Filter bubbles — сегрегация в графах, когда модель обособляет кластеры друг от друга, вместо того чтобы предсказывать что-то принципиально новое. В терминах рекомендательных систем — insufficient recommendation diversity, проблема на стороне нейросети.

Polarization — пользователи разбиваются на кластеры и взаимодействуют только внутри них, не видя альтернативных мнений. В терминах рексистем — insufficient creation diversity, проблема на стороне поставщика контента.

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

Пользователю i рекомендуют создателя j, после чего эмбеддинг пользователя i обновляется в зависимости от влияния на него j-го создателя. Обновляется и эмбеддинг создателя: на основе эмбеддингов тех, кому его рекомендовали.

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

Доказывали так: эмбеддинги пользователей и создателей меняются довольно плавно. Вероятность того, что каждого создателя порекомендуют каждому пользователю, больше 0. Тогда система схлопнется либо в 1 кластер (consensus), либо в 2 (bi-polarization).

При этом, если рекомендовать только top-k создателей, зануляя для остальных вероятности или relevance-скоры (скалярные произведения user на creator), можно избежать поляризации и забустить diversity, так как появятся нулевые вероятности.

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

@RecSysChannel
Разбор подготовил Сергей Макеев
2 093 просмотров · 13 реакций Открыть в Telegram · Открыть пост на сайте
FedUD: Exploiting Unaligned Data for Cross-Platform Federated Click-Through Rate Prediction, Alibaba

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

Просто собрать данные с разных доменов в одном месте и централизованно обучить модель не получится — это не конфиденциально. Для того чтобы безопасно обрабатывать чувствительные данные, существует подход Vertical Federated Learning (VFL): обучение происходит на каждом домене по отдельности, а полученные верхнеуровневые представления собираются в общую модель.

Но есть нюанс: собрать таким образом можно только выровненные представления (aligned data). Авторы статьи предлагают, как утилизировать на основном домене unaligned data — данные, к которым почему-то не получилось присоединить полезную информацию с других доменов.

Для aligned data обучение будет состоять из двух фаз (как на схеме):

1. На каждом домене своя сетка получит эмбеддинг пользователя, после чего передаст его сетке главного домена (вместо сырых данных — высокоуровневые представления). Эмбеддинг главного домена копируется на две головы.
2. Первая голова пытается выучить эмбеддинг другого домена. Происходит дистилляция: эмбеддинг главного домена проходит через MLP и через MSE сближается с эмбеддингом второстепенного домена (или доменов). Во второй голове эмбеддинг из главного и второстепенного доменов конкатятся, прогоняются через MLP и идут в BCE loss.

Когда готова голова, которая предсказывает эмбеддинг с другого домена, можно обучаться и на unaligned data: только во второй голове вместо эмбеддинга с другого домена используется эмбеддинг, предсказанный дистилляционной головой.

Результаты подтверждаются офлайн-экспериментами на открытом и приватном датасетах. Ориентируясь на AUC и LogLoss, авторы сравнивают предложенный подход:

— с другими VFL-моделями (которые используют как aligned, так и aligned + unaligned данные);
— с Wide&Deep (без кросс-домена).

@RecSysChannel
Разбор подготовил Сергей Макеев
2 252 просмотров · 14 реакций Открыть в Telegram · Открыть пост на сайте
Разбор тренда: графовые нейросети в индустрии

Начинаем год с взгляда в будущее! Некоторое время назад Кирилл Хрыльченко написал на Хабре пост о главных трендах в рексис. Практически все эти тренды будут актуальны и в 2025-м — в науке и индустрии ещё много чего можно сделать в этих направлениях. Сегодня разберём подробнее один из трендов, который точно не потеряет актуальности в мире рекомендательных систем, — графовые нейросети. Посмотрим, какие подходы существуют и с какими интересными статьями стоит ознакомиться, чтобы лучше разобраться в теме.

Классификация подходов:

1. End-to-end — обучаем графовую нейросеть вместе с последующей моделью.
2. Frozen — переиспользуем уже выученные графовые представления в замороженном виде:
◦ трансдуктивные — не обобщаемся на новых юзеров или айтемы;
◦ индуктивные — можем получать представления для новых юзеров или айтемов;
◦ промежуточные подходы — для юзеров получить представления можем, а для айтемов — нет.

End-to-end

Etsy — (2023) Unified Embedding Based Personalized Retrieval in Etsy Search. Особенности статьи: retrieval для поиска, графовое представление как дополнительная фича документа. SearchQuery-Product граф, семплирование соседей и усреднение в качестве агрегации.

Taobao — (2023) Graph Contrastive Learning with Multi-Objective for Personalized Product Retrieval in Taobao Search. Аналогичное предыдущей статье применение подхода, item-item граф, attention в качестве агрегации.

Amazon — (2021) Graph-based Multilingual Product Retrieval in E-Commerce Search. Идея, похожая на работу от Etsy. Авторы делают multilingual модель.

Alibaba Group — (2022) Multi-level Contrastive Learning Framework for Sequential Recommendation. На обучении графовое представление пользователя сближается с тем, что получено из sequential модели. На инференсе графовая часть откидывается.

Трансдуктивные

X/Twitter — (2022) TwHIN. Embedding the Twitter Heterogeneous Information Network for Personalized Recommendation. Обучаемые ID для каждой сущности, TransE на BCE (link-prediction).

Промежуточные

Amazon — (2023) Multi-Task Knowledge Enhancement for Zero-Shot and Multi-Domain Recommendation in an AI Assistant Application. Авторы создают кросс-доменный граф: музыка, видео, книги. Юзеры кодируются индуктивно, а айтемы = обучаемые ID.

Индуктивные

Pinterest — (2022) MultiBiSage: A Web-Scale Recommendation System Using Multiple Bipartite Graphs at Pinterest. Исследователи получают графовые представления для пинов, которые потом переиспользуют везде. Используют контент.

Spotify — (2021) Multi-Task Learning Of Graph-Based Inductive Representations Of Music Content. Мультитаск, BCE — пара вершин принадлежит одному плейлисту (link-prediction), либо пара вершин имеет один и тот же жанр, регрессия основана на близости по контенту.

Spotify — (2020) Podcast Recommendations and Search Query using GNNs at Spotify. Graph Learning Workshop 2022. Рассказ о собственных графовых сетках Spotify.

KuaiShou — (2023) A Unified Model for Video Understanding and Knowledge Embedding with Heterogeneous Knowledge Graph Dataset. Авторы получают индуктивные представления для видео и тегов к ним.

Основные выводы

1. Используя графовые нейросети, многие авторы статей наблюдают улучшение метрик на long-tail айтемах.
2. Такие сетки удобно использовать для данных из разных доменов.
3. Также графовые нейросети используются как один из источников генерации кандидатов или фич в ранжировании.

@RecSysChannel
Обзор подготовил Артем Матвеев
2 470 просмотров · 27 реакций Открыть в Telegram · Открыть пост на сайте
🎄 Чтение на каникулы: бонусная подборка статей от экспертов «Рекомендательной»

Мы уже делились лучшими постами за год в канале, но интересных статей в мире рексис гораздо больше, чем мы успели разобрать в 2024-м. Планы на 2025-й — масштабные, замедляться не думаем и вам не советуем, поэтому ловите бонусную подборку интересных статей для чтения и профессионального развития на новогодних праздниках. Кстати, полные разборы этих материалов обязательно появятся здесь в будущем — не пропустите то, что заинтересует именно вас. И с наступающими!

Towards Understanding the Overfitting Phenomenon of Deep Click-Through Rate Prediction Models
В статье рассматривается проблема резкого переобучения CTR-моделей в начале второй эпохи, a.k.a. one-epoch phenomenon. Его можно преодолеть с помощью нескольких трюков: снизить количество уникальных эмбеддингов или вовсе отказаться от эмбеддингов товаров, поэкспериментировать с оптимизаторами (Adam и RMSPROP оказались более склонны к эффекту), снизить LR, — однако всё это приводит к снижению пикового качества.

Diffusion-based Contrastive Learning for Sequential Recommendation
Авторы поставили под вопрос существующие методы аугментации цепочек последовательных заказов с целью генерации новых цепочек. Вместо маскирования и переупорядочивания истории пользователя предлагают использовать guided-диффузию для оценки условного распределения айтема, обусловленного на контекст. Чтобы сблизить латентное пространство диффузионки и SR-модели (в статье это SASRec), их обучают вместе end-to-end, шаря эмбеддинги айтемов.

Beyond Item Dissimilarities: Diversifying by Intent in Recommender Systems
Авторы хотят разнообразить предлагаемый пользователю контент, так как человек может иметь разные намерения, например, в зависимости от дня недели или времени: это может быть спорт, учеба, отдых и т. д. Было бы здорово учитывать намерение (intent) пользователя при генерации выдачи, а не только user-item схожесть. Для решения проблемы авторы предлагают новый фреймворк, который используется поверх рексистемы, но описывают его на идейном уровне, не уточняя, чем моделируют распределения.

Learned Ranking Function: From Short-term Behavior Predictions to Long-term User Satisfaction
Авторы статьи формулируют ранжирование как multitask slate optimization на языке траекторий пользователя. При ранжировании на вход получают m Multitask Model Scoring предиктов для каждого кандидата. Раньше их комбинировали с весами-гиперпараметрами, которые оптимизировали через Байесовскую оптимизацию. Цель — ранжировать так, чтобы повысить long term user satisfaction, то есть каждый слейт оценивается в том числе и по тому, что происходит после того, как пользователь его покинул.

Autoregressive Generation Strategies for Top-K Sequential Recommendations
Авторегрессионные рекомендации от лабы Сбера. Хотят генерировать k следующих айтемов для пользователя. Решают эту задачу через генерацию S различных пользовательских траекторий, которые потом агрегируют вместе. Ссылаются на пиннерформер и используют у себя decoder-only архитектуру. В самой статье предлагают два решения для агрегации: Reciprocal Rank Aggregation и Relevance Aggregation. В качестве декодера используют GPT-2. В разделе о генерации траекторий упоминают разные алгоритмы (жадный, beam search и temperature sampling), но используют только последний.

Your Causal Self-Attentive Recommender Hosts a Lonely Neighborhood
Статья от Джулиана МакОли пытается ответить на вопрос: что все-таки лучше, авторегрессионные подходы или автоэнкодерные и почему. Исследователи ссылаются на множество работ и хотят разобраться, насколько результаты робастны по итогу. Сравнивают BERT4Rec и SASRec в основном с их различными модификациями. Все эксперименты проведены на открытых датасетах: Beauty, Sports, Video, Yelp, MovieLens.

@RecSysChannel
Подборку подготовили Сергей Макеев и Владимир Байкалов
2 489 просмотров · 28 реакций Открыть в Telegram · Открыть пост на сайте
🏆Лучшее за год в Рекомендательной

Год был щедрым на интересные recsys-статьи, а мы не ленились разбирать их. Предлагаем освежить в памяти посты, которые вы читали чаще всего. Если что-то прошло мимо, самое время наверстать!

ICML 2024 — как это было
Даниил Лещёв и Андрей Мищенко рассказали, что запомнилось на ICML 2024. Среди интересного — новая архитектура ML-моделей в рекомендациях и методы из мира LLM для улучшения LSTM-моделей. Пожалуй, самый необычный хайлайт от ребят (хотя и не из нашего домена, просто им очень понравилось) — статья об обучении роборуки осязанию и возможности различать текстуры поверхностей. Даёшь тактильные ощущения роботам!

Законы масштабирования в больших моделях последовательных рекомендаций
Scaling law добрался до рекомендаций. Артём Матвеев разобрал статью от WeChat и Tencent, где авторы проверили, как увеличение параметров моделей улучшает качество рекомендаций. (Спойлер: выяснили, что большие модели справляются лучше на сложных задачах). Детали эксперимента — в обзоре.

Actions Speak Louder than Words: Trillion-Parameter Sequential Transducers for Generative Recommendations
Кирилл Хрыльченко разобрал HSTU — новую архитектуру для рекомендаций, которая показывает отличные результаты в онлайн-эксперименте и обрабатывает бо́льшие истории в сравнении с прошлыми подходами. Авторы предложили отдельные модели для генерации кандидатов и ранжирования, сделали последовательности событий target-aware и отказались от софтмакса в трансформере, чтобы точнее работать с пользовательской историей.

Кластерная якорная регуляризация в рекомендательных системах
Сергей Макеев объяснил, как ресёрчеры из DeepMind решали проблему popularity bias в рекомендациях. Их метод Cluster Anchor Regularization делает так, чтобы популярные айтемы «тянули» за собой непопулярные и помогали справляться с перекосами. Новый подход протестировали на YouTube Shorts — похоже, рекомендации могут стать качественнее.

LiGNN: Graph Neural Networks at LinkedIn
Владимир Байкалов рассказал, как LinkedIn использует графы для своих рекомендаций. Эти графы связывают пользователей с вакансиями, группами и компаниями. Результат — обучение стало быстрее, а метрики рекомендаций заметно выросли.

Multi-objective Learning to Rank by Model Distillation
Airbnb придумали, как объединить дистилляцию и мультитаск-обучение, чтобы алгоритмы ранжирования стали умнее. Подход учитывает важные факторы, вроде возвратов или обращений в поддержку. Как всё устроено, разбирался Сергей Макеев.

Интересное с ACM RecSys 2024, часть 3
А ещё мы сделали серию постов о лучших статьях с конференции ACM RecSys. Самым популярным стал разбор модели Text2Tracks, которая умеет подбирать музыку по текстовому запросу. Пётр Зайдель описал, как эта модель выбирает треки, и сравнил разные способы кодирования. Первая и вторая части тоже заслуживают г̶л̶у̶б̶о̶к̶о̶г̶о лайка.

@RecSysChannel
___
Meta признана экстремистской организацией, а Facebook и Instagram запрещены на территории РФ
2 538 просмотров · 40 реакций Открыть в Telegram · Открыть пост на сайте
Break the ID-Language Barrier: An Adaption Framework for Sequential Recommendation

Один из главных трендов RecSys 2024 — внедрение LLM в рекомендательные системы. Большинство работ по теме объединяет излишняя академичность (слишком сложные для реализации подходы), поэтому в индустрии это направление широкого признания пока не получило. Однако сегодняшняя статья вполне практическая: о способе использовать предобученные эмбеддинги рекомендательной модели в LLM.

Идея применять большие языковые модели для генерации рекомендаций популярна, но не нова: обе технологии отлично компенсируют слабые стороны друг друга. Рекомендательные модели слабы в познании мира, а LLM лишены богатого коллаборативного сигнала, который хранится в эмбеддингах и весах рекомендательных нейросетей. Чтобы объединить лучшее, что есть в каждом из подходов, можно интегрировать в LLM предобученные эмбеддинги рекомендательной модели. Адаптер, предложенный в статье, — фреймворк, который встраивает представления пользователя в attention-слои LLM.

Как это устроено, показано на схеме. Эмбеддинги пользователей берутся из рекомендательной модели, предобученной на Next Item Prediction. Hard Prompt Construction сопоставляет пользователя с его текстовым описание (промптом) и формулирует явное указание, что должна сделать модель, чтобы получить предсказание. А адаптер выравнивает размерность эмбеддингов пользователя (линейными слоями повышает её до внутренней размерности LLM) и уточняет эмбеддинги пользователей, смешивая их с промпт-токенами.

Из статьи вы узнаете, как можно решить проблему distribution shift между рекомендательной моделью и LLM, с учётом того, что у каждого слоя языковой модели — свой уровень абстракции и он нуждается в собственной предобработке внешних данных (эмбеддингов пользователей из рекомендательной модели).

@RecSysChannel
Разбор подготовил Сергей Макеев
2 472 просмотров · 24 реакций Открыть в Telegram · Открыть пост на сайте
Bridging the Gap: Unpacking the Hidden Challenges in Knowledge Distillation for Online Ranking Systems
часть 2

Далее в статье описываются нюансы реализации. Авторы рассматривают:

1. Два возможных подхода к дистилляции:

🔹 Direct distillation — дистилляционный и основной лосс применяются к одному логиту в модели-ученике.
🔹 Auxiliary distillation — в модели-ученике есть два раздельных логита: для основного и для дистилляционного лосса. Схема показана на иллюстрации.

Второй вариант хорошо себя показал для задач предсказания LTV: в офлайн-замере RMSE он на 0,4% лучше direct-подхода. Это объясняется тем, что LTV — очень шумный и плохо откалиброванный таргет: большая модель выучивает биасы в данных и остаётся плохо откалиброванной. А потом передаёт свои биасы ученикам и приводит к зашумлению таргета. Поэтому лучше использовать два отдельных логита.

2. Какие таргеты стоит использовать для дистилляции. Все таргеты можно поделить на 3 группы: Engagement (например, клики), Satisfaction (лайки или досмотры) и остальные. Авторы отмечают, что лучше использовать только Engagement и Satisfaction — это даёт прирост +1,13% Satisfaction +0,39% Engagement относительно модели без дистилляции. Добавление дополнительных таргетов влияет на общие слои и ухудшает итоговые результаты.

3. Как комбинировать ученика и учителя. Архитектуры ученика и учителя похожи, главное отличие — глубина и ширина внутренних слоёв. Авторы провели онлайн-эксперименты для комбинаций, когда учитель больше ученика в 2 и в 4 раза: в 2 раза больший учитель позволил добиться прироста +0,42% Engagement и +0,34% Satisfaction относительно модели без дистилляции, в 4 раза больший учитель — +0,85% и +0,80% соответственно. Но эффект масштабирования не будет продолжаться бесконечно, а увеличивать учителя ещё сильнее сложно: во-первых, его нужно обучать на больших объёмах данных, за несколько месяцев. Во-вторых – поддерживать онлайн.

@RecSysChannel
Разбор подготовил Петр Зайдель
2 271 просмотров · 28 реакций Открыть в Telegram · Открыть пост на сайте
Bridging the Gap: Unpacking the Hidden Challenges in Knowledge Distillation for Online Ranking Systems
часть 1

Сегодняшнюю статью подготовила для RecSys 2024 команда Google. В ней они рассказали, как используют дистилляцию для ранжирования видео на главной YouTube: не шортсов, а именно роликов на главной странице.

Говоря о дистилляции в CV или NLP, обычно подразумевают классический пайплайн:

🔹 обучение большой модели на некотором объёме данных;
🔹 подготовка датасета из предсказаний большой модели;
🔹 обучение маленьких моделей с использованием предсказаний большой нейросети.

Применять такой подход напрямую для рекомендаций не получится: поведение пользователей, набор рекомендуемых айтемов меняются со временем, иногда даже в течение дня. Это значит, что один раз обучить большую модель на длинном промежутке времени и использовать её как учителя не получится, она быстро устареет. Для точных рекомендаций YouTube учитывает в дистилляции distribution shift: постоянно дообучает модели нейросетевого ранжирования на свежих данных.

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

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

@RecSysChannel
Разбор подготовил Петр Зайдель
2 066 просмотров · 24 реакций Открыть в Telegram · Открыть пост на сайте
KuaiFormer: Transformer-Based Retrieval at Kuaishou

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

Kuaishou — суперпопулярный в Китае аналог TikTok: 400 млн активных пользователей, 600+ тыс RPS. В среднем один пользователь просматривает сотни видео в день.

Это первое внедрение в Kuaishou трансформера для кандидатогенерации. По их словам, — самое успешное внедрение за последние полгода.

Новая модель получила название KuaiFormer. Опираясь на историю взаимодействия пользователя с продуктом, она помогает предсказывать следующие положительные взаимодействия (в случае Kuaishou — это, например, лайк, полный просмотр видео и т. д.).

PinnerFormer, SASRec, Bert4Rec и другие похожие работы плохо улавливают разнообразные интересы пользователей, поскольку представляют их в виде одного вектора. Подходы MIND и ComiRec решают эту проблему: они умеют выделять целые кластеры интересов — так рекомендации получаются более разнообразными. KuaiFormer объединяет в себе оба подхода — она умеет справляться с главными проблемами реальных рекомендательных систем:

1. За счёт применения logQ-коррекции эффективно работает с большим каталогом айтемов при обучении.

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

3. Работает в реалтайме, но не требует большого объёма вычислительных ресурсов, несмотря на огромные RPS. Добиться этого помогает сворачивание последовательных кусков истории пользователя в один вектор с помощью bidirectional-трансформера: самые старые айтемы, которые были актуальны достаточно давно, сворачиваются в один вектор, а самые свежие — остаются нетронутыми. Схема того, как 256 токенов превращаются в 64, показана на рисунке.

@RecSysChannel
Разбор подготовил Артем Матвеев
2 887 просмотров · 36 реакций Открыть в Telegram · Открыть пост на сайте
Recommender Systems with Generative Retrieval

Современные модели для генерации кандидатов обычно строят так: обучают энкодеры (матричные разложения, трансформеры, модели dssm-like) для получения ембеддингов запроса (пользователя) и кандидата в одном пространстве. Далее по кандидатам строится ANN-индекс, в котором по ембеддингу запроса ищутся ближайшие по выбранной метрике кандидаты. Авторы предлагают отойти от такой схемы и научиться генерировать ID айтемов напрямую моделью, которую они обучают. Для этого предлагают использовать энкодер-декодер трансформенную модель на основе фреймворка T5X.

Остается вопрос, как закодировать айтемы для использования в трансформерной модели и как научиться напрямую предсказывать ID в декодере? Для этого предлагается использовать наработки из прошлой работы — Semantic IDs. Такие ID для описания айтемов обладают следующими свойствами:

— иерархичность — ID в начале отвечают за общие характеристики, а в конце — за более детальные;
— они позволяют описывать новые айтемы, решая проблему cold-start;
— при генерации можно использовать сэмплинг с температурой, что позволяет контролировать разнообразие.

В статье проводят эксперимент на датасете Amazon Product Reviews, состоящий из отзывов пользователей и описания товаров. Авторы используют три категории: Beauty, Sports and Outdoors и Toys and Games. Для валидации и тестирования используют схему leave-one-out, когда последний товар в истории каждого пользователя используется для тестирования, а предпоследний — для валидации. Такой подход много критиковали за возможные лики, но авторы используют его для сравнения с уже существующими результатами бейзлайнов.

Semantic IDs строили следующим образом: каждый товар описывался строкой из названия, цены, бренда и категории. Полученное предложение кодировали предобученной моделью Sentence-T5, получая эмбеддинг размерности 768. На этих ембеддингах обучали RQ-VAE с размерностями слоев 512, 256, 128, активацией ReLU и внутренним ембеддингом 32. Использовали три кодовые книги (codebooks) размером 256 ембеддингов. Для стабильности обучения их инициализировали центроидами кластеров k-means на первом батче. В результате каждый айтем описывает три ID, каждый из словаря размера 256. Для предотвращения коллизий добавляли еще один ID с порядковым номером.

Энкодер и декодер — трансформеры из четырёх слоев каждый с шестиголовым аттеншеном размерности 64, ReLU активацией, MLP на 1024 и размерностью входа 128. В словарь токенов добавили 1024 (256 × 4) токенов для кодбуков и 2000 токенов для пользователей. В итоге получилась модель на 13 миллионов параметров. Каждый пример в датасете выглядит так: hash(user_id) % 2000, <semantic_ids_1>, … <semantic_ids_n> -> <semantic_ids_n+1>. Во время инференса метод показывает значительный прирост качества (Recall@5, NDCG) по сравнению с бейзлайнами (SASRec, S3-Rec etc). При этом нужно учитывать, что у предложенной модели намного больше параметров, чем у остальных.

Авторы проводят ablation study для семантических ID — рассматривают варианты их замены на LSH и случайные ID. В обоих случаях semantic ID дает большой прирост и является важным компонентом подхода. Также проводится анализ возможности модели обобщаться на новые айтемы. Для этого из датасета выкидываются 5% товаров, а на инференсе задают отдельным гиперпараметром долю новых кандидатов в top-k (с совпадающими первыми тремя ID) и сравнивают свою модель с KNN.

Статья получилась во многом академичной, но она обращает внимание на важное направление, которое сейчас активно развивается. Похожий подход можно использовать для кодирования айтемов для LLM, чем, судя по разговорам на конференции, уже активно занимаются. Также можно отметить, что в статье не раскрывается часть важных вопросов: как добавлять новые айтемы и как переобучать RQ-VAE (в реальных сервисах часто меняется распределение контента), а также хотелось бы увидеть сравнение на более приближенных к реальным датасетах.

@RecSysChannel
Разбор подготовил Петр Зайдель
2 723 просмотров · 37 реакций Открыть в Telegram · Открыть пост на сайте
Joint Modeling of Search and Recommendations Via an Unified Contextual Recommender (UniCoRn)

В ещё одном интересном докладе с ACM RecSys разработчики из Netflix делятся опытом объединения моделей для персонализированного поиска и рекомендаций. В статье есть несколько предпосылок. Во-первых, обслуживать одну модель в продакшене проще, чем несколько. Во-вторых, качество объединённых моделей может быть выше.

Представленная архитектура обучается на трёх задачах: персональные рекомендации, персонализированный поиск и рекомендации к текущему видео. Для этого в нейросетевой ранкер подаётся поисковой запрос, ID текущей сущности (видео), ID пользователя, страна и ID задачи, которая решается (поиск или одно из ранжирований). Также в ранкер подаётся эмбеддинг истории действий пользователя, полученный так называемой "User Foundation Model", детали которой не раскрываются ни в тезисах с конференции, ни в ответе на прямой вопрос после устного доклада.

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

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

Результаты — рост на 7% в офлайн-качестве в поиске и на 10% — в рекомендациях. Это, по всей видимости, достигается за счёт регуляризации, возникающей при обучении на несколько задач и за счёт перехода к полной персонализации в поиске.

@RecSysChannel
Разбор подготовил Владимир Цепулин
2 538 просмотров · 30 реакций Открыть в Telegram · Открыть пост на сайте
LiGNN: Graph Neural Networks at LinkedIn

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

В теории, использование графовой структуры вводит некий inductive bias и может помочь ML-модели в выучивании закономерностей, однако на практике очень сложно внедрить графы в продакшен из-за ряда проблем: distribution shift, cold start, dynamic vocabulary. В сегодняшней статье ребята из LinkedIn рассказывают, как внедряли графы в свою инфраструктуру, с какими сложностями столкнулись и что усвоили.

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

Архитектура ML-модели представлена на втором рисунке и состоит из трёх частей:

- Graph Engine — алгоритм для семплирования подграфов на базе открытой библиотеки DeepGNN от Microsoft. Для семплирования используют Personalized Page Rank (PPR).
- Encoder — помогает получить агрегированные представления вершин графа, опирается на GraphSage;
- Decoder — обычный MLP, вычисляет финальную релевантность между двумя вершинами (source и target).

За время работы над LiGNN команда смогла в 7 раз ускорить обучение графовых нейросетей, частично побороть cold start и запуститься в near-realtime сеттинге. Внедрение такой архитектуры как в ранжирование, так и в кандидатогенерацию повысило продуктовые метрики: +1% откликов на вакансии, +2% CTR объявлений, +0,5% еженедельно активных пользователей, +0,2% продолжительности взаимодействия с платформой и +0,1% еженедельно активных пользователей благодаря рекомендациям.

Посмотреть, как работает LiGNN, можно в приложениях LinkedIn: сейчас он развёрнут в доменах Feed, Jobs, People Recommendation и Ads.

@RecSysChannel
Разбор подготовил Владимир Байкалов
3 701 просмотров · 33 реакций Открыть в Telegram · Открыть пост на сайте
Actions Speak Louder than Words: Trillion-Parameter Sequential Transducers for Generative Recommendations

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

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

Архитектура для генерации кандидатов выглядит довольно стандартно и похожа на SASRec или Pinnerformer: представляем пользователя в виде последовательности событий (item, action), и в тех местах, где следующим событием идет положительное взаимодействие с айтемом, предсказываем, что это за айтем.

А вот для ранжирования новизна достаточно серьезная: чтобы сделать модель target-aware (см. Deep Interest Network от Alibaba), понадобилось сделать более хитрую последовательность, в которой чередуются токены айтемов и действий: item_1, action_1, item_2, action_2, …. Из айтем-токенов предсказывается, какое с ними произойдет действие. Еще говорят, что на практике можно решать в этом месте любую многоголовую мультизадачу. Важно отметить, что авторы не учат единую модель сразу на генерацию кандидатов и ранжирование, а обучают две отдельные модели.

Другое нововведение — отказ от софтмакса и FFN в трансформере. Утверждается, что софтмакс плох для выучивания «интенсивности» чего-либо в истории пользователя. Те вещественные признаки, которые были выкинуты авторами, в основном её и касались. Например, сколько раз пользователь лайкал автора видеоролика, сколько раз скипал и т. д. Такие признаки очень важны для качества ранжирования. То, что отказ от софтмакса эту проблему решает, видно по результатам экспериментов — действительно есть значительное улучшение результатов ранжирования при такой модификации.

В итоге HSTU (Hierarchical Sequential Transduction Unit, так авторы окрестили свою архитектуру) показывает отличные результаты как на публичных, так и на внутренних датасетах. Еще и работает гораздо быстрее, чем прошлый DLRM подход за счет авторегрессивности и нового энкодера. Результаты в онлайне тоже очень хорошие — на billion-scale платформе short-form video (предполагаем, что это рилсы) получили +12.4% относительного прироста целевой метрики в A/B-тесте. Тем не менее, итоговая архитектура, которую авторы измеряют и внедряют, с точки зрения количества параметров не очень большая, где-то сотни миллионов. А вот по размеру датасета и длине истории скейлинг получился очень хороший.

@RecSysChannel
Разбор подготовил Кирилл Хрыльченко
11 308 просмотров · 34 реакций Открыть в Telegram · Открыть пост на сайте
Интересное с ACM RecSys 2024, часть 3

Конференция завершилась, ребята вернулись домой, но продолжают делиться с нами обзорами интересных и актуальных статей, а мы и рады их опубликовать! Сегодня в эфире — довольно подробный разбор статьи Text2Tracks: Generative Track Retrieval for Prompt-based Music Recommendation.

Авторы рассматривают задачу рекомендации музыки на основе текстовых запросов, например, “old school rock ballads to relax”, “songs to sing in the shower” и т. д. Исследуется эффективность модели на широких запросах, не подразумевающих конкретного артиста или трека. Рекомендовать трек по текстовому запросу можно разными путями. Например, задать вопрос языковой модели, распарсить ответ и найти треки через поиск. Это может привести к галлюцинациям или неоднозначности поиска — иногда совершенно разные треки могут иметь одно название. Кроме того, предсказание может занимать много времени и требовать больших вычислительных ресурсов.

Авторы предлагают дообучить модель типа encoder-decoder (flan-t5-base), которая по текстовому входу смогла бы генерировать идентификатор трека напрямую, вдохновившись подходом differentiable search index. Основной вопрос, на который дают ответ в статье — как лучше кодировать трек? Для этого сравнивают несколько подходов:
— Трек кодируется случайным натуральным числом, которое подаётся на вход в виде текста. Например “1001”, “111”
— Трек котируется как два числа: ID артиста и ID трека внутри артиста. То есть треки артиста 1 будут представляться как “1_1”, “1_2” … Для топ 50к артистов добавляют отдельные токены с словарь.
— Каждый трек описывается списком ID на основе иерархической кластеризации контентного (названия плейлистов с треком) или коллаборативных ембеддингов (word2vec). Для каждого кластера добавляется отдельный токен.

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

В качестве основных бейзлайнов авторы используют popularity, bm25 и двухбашенный энкодер (all-mpnet-base-v2), который файнтюнят c multiple negatives ranking loss. Сравнивают модели на трёх датасетах: MPD 100k, CPCD и редакционные плейлисты Spotify. Исследователи показывают, что их модель значительно лучше бейзлайнов на всех датасетах. В будущем они планируют изучить возможности моделей с архитектурой decoder-only и использование пользовательской истории для персонализации рекомендаций.

@RecSysChannel #YaACMRecSys
Обзор подготовил Пётр Зайдель
2 553 просмотров · 16 реакций Открыть в Telegram · Открыть пост на сайте
Интересное с ACM RecSys 2024, часть 2

А мы продолжаем делиться классными докладами с ACM RecSys — оставайтесь с нами и приглашайте друзей подписываться, чтобы не пропустить самое интересное 👀

Ranking Across Different Content Types: The Robust Beauty of Multinomial Blending
Простая, но разумная продуктовая идея от Amazon Music: дать возможность продактам задавать пропорции по типу контента. Для этого есть две модели: одна ранжирует карусели, а другая — контент внутри каруселей. Когда карусели отранжированы, их группируют по типам контента, сэмплируют тип пропорционально весам, заданным продактам, и выбирают самую релевантную карусель из типа, выпавшего в сэмплировании. В А/Б тесте этот подход сравнили с системой, которая работает на MMR-like алгоритме и получили отличный рост метрик.

Раньше для ранжирования авторы использовали linear thompson sampling, теперь — нейронка, которая обучается в онлайн-режиме на сабсэмпле логов с задержкой в десятки секунд. Сейчас они активно пробуют sequential-модели, но пока не в проде.

AIE: Auction Information Enhanced Framework for CTR Prediction in Online Advertising
Довольно интересный фреймворк. Авторы добавили отшкалированный CPC как вес позитива в log loss, и получили рост метрик (выразившийся в деньгах) в А/Б тесте. К сожалению, автор не подсказал, какими были теоретические предпосылки — судя по всему сработала какая-то очень общая интуиция.

В оффлайне используют в основном AUC и csAUC, которые обычно нормально конвертируются в онлайн-метрики.

Enhancing Performance and Scalability of Large-Scale Recommendation Systems with Jagged Flash Attention
Постер о jagged flash attention — это когда вы не используете пэдлинг в историях пользователей, а вместо этого упаковываете её в два тензора: непрерывную историю и размеры историй.

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

Sliding Window Training: Utilizing Historical Recommender Systems Data for Foundation Models
Исследователи в Netflix учат базовую модель для downstream-тасков. По сути это sasrec — предсказывают next item. На разных эпохах используют разные длины истории (фиксированные на всю эпоху). Для каждого пользователя выбирают одно рандомное окно указанной длины в эпоху. На вход подают просто ID, action type используют только в loss, где смешивают loss’ы на разный action type с разными весами. Истрия пользователя состоит из разных позитивов: клики, просмотры и т. п.

Авторы никак не дообучают модель в downstream-тасках, а просто подают на вход верхней модели полученные эмбеддинги. Lookahead и action type во входе модели не пробовали. Размерность эмбеда — 64. Loss представляет собой честный softmax по всей базе.

@RecSysChannel #YaACMRecSys
Находками делился Николай Савушкин
1 989 просмотров · 14 реакций Открыть в Telegram · Открыть пост на сайте
Интересное с ACM RecSys 2024, часть 1

14 октября в Бари стартовала конференция ACM Conference on Recommender Systems, которая собрала специалистов в области рекомендательных систем со всего мира — в том числе, и из Яндекса. Мы поговорили с ребятами, обсудили интересные доклады и постеры, которые они увидели, и спешим поделиться с вами. Впереди — ещё больше впечатлений и свежих идей в постах с полей ACM RecSys!

Encouraging Exploration in Spotify Search through Query Recommendations
Spotify рассказали о том, как внедрили саджесты запросов в поиск. Они собирают запросы из разных источников: каталог (треки, артисты, альбомы, плейлисты), запросы других пользователей, запросы вида артист + mix/covers и запросы, сгенерированные LLM по метаинформации. Всё это отправляется в ранкер, обученный на поисковых логах, из которого пользователю показывают топ-4. Результаты: +9% exploratory queries, они же — поиск нового контента, и +10% к средней длине запроса.

Do Not Wait: Learning Re-Ranking Model Without User Feedback At Serving Time in E-Commerce
Идея статьи: если у нас есть реранжирующая функция и функция, приближающая reward по пользователю и списку, в рантайме можно «скорректировать» параметры ранжирующей функции в сторону максимизации оценивающей функции. Такие корректировки можно применить несколько раз и получить ранжирующую модель, работающую лучше оригинальной.

Авторы утверждают, что вырастили число заказов на пользователя на 2%. Клики при этом выросли всего на 0.08%, что звучит очень странно на фоне роста числа заказов. Ранжирующая функция — представляет собой какой-то thompson sampling, а Argmax находят с помощью "reinforce like method". Интересно, но практическая польза под вопросом.

Better Generalization with Semantic IDs: A Case Study in Ranking for Recommendations
Нашумевшая статья от Google DeepMind. Авторы предлагают закодировать контент документа в виде нескольких токенов с использованием VAE и векторной квантизации — изначально подход предложили в другой статье. Каждый документ представляют как набор токенов фиксированной длины. Получают хитрый словарь, которым можно кодировать документы, где один документ = несколько токенов. Утверждают, что работает не сильно хуже, чем обучаемые ID (без коллизий), но матрица эмбеддингов при этом радикально меньше, а коллизии в ней имеют семантический смысл.

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

@RecSysChannel #YaACMRecSys
Находками делились Николай Савушкин и Пётр Зайдель
1 762 просмотров · 16 реакций Открыть в Telegram · Открыть пост на сайте
Density Weighting for Multi-Interest Personalized Recommendation

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

Авторы отмечают, что использование нескольких представлений пользователя (multiple user representations, MUR) вместо одного представления (single user representation, SUR) показало свою эффективность. Однако при таком подходе огромную роль играет неравномерное распределение интересов пользователя. MUR фокусируется на головных, самых популярных интересах, из-за чего возникает просадка на более редких, хвостовых.

Чтобы решить эту проблему, авторы предлагают схему итеративного взвешивания плотности (iterative density weighting scheme, IDW). Она должна помочь справиться с дисбалансом данных и улучшить рекомендации для хвостовых элементов. IDW корректирует представление предметов в пространстве, уменьшая влияние дисбалансированных данных и улучшая кластеризацию элементов. Вот как устроена IDW:

1. Модель анализирует плотность предметов в пространстве представлений — то есть то, насколько близко друг к другу они находятся. Плотность рассчитывается для каждого предмета, чтобы понять, каких элементов слишком много (высокая плотность) и каких мало (низкая плотность).

2. На основе плотности модель корректирует веса предметов — элементы с высокой плотностью получают меньшие веса, а с низкой плотностью — большие. Это позволяет модели меньше фокусироваться на популярных предметах и больше — на редких.

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

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

По результатам экспериментов на бенчмарках — MovieLens 1M, Kindle Store, а также Clothing, Shoes and Jewelry — схема IDW показала значительное улучшение рекомендаций. В метрике HR@20 для MovieLens 1M модель с IDW достигла 82,65% против 80,82% у обычной MUR, а в NDCG@20 — 49,67% против 47,72% у MUR.

На датасете Kindle Store HR@20 составил 65.24% с IDW против 64,66% у MUR, а NDCG@20 — 32.25%, тогда как у MUR было 31,16%.

На датасете Clothing, Shoes and Jewelry метрика HR@20 у IDW составила 37,34% (33.92% у MUR), а NDCG@20 — 16.33% (14.90% у MUR).

@RecSysChannel
Разбор подготовил Степан Макаренко
2 166 просмотров · 21 реакций Открыть в Telegram · Открыть пост на сайте
Efficient Retrieval with Learned Similarities

Сегодня обсуждаем статью от Microsoft и Meta* об эффективном retrieval с обучаемыми функциями близости. Исторически нишу функций близости в retrieval занимали косинусные близости — скалярные произведения над нормализованными векторами. Но в последнее время популярность стали набирать обучаемые функции близости. Например, они допускают сопоставление одному запросу нескольких эмбеддингов, чтобы лучше улавливать редкие и противоречивые интересы пользователей. Также можно использовать нейросети над векторами запроса и векторами айтема и делать многие другие интересные вещи. Однако с эффективностью этих решений есть проблемы.

Чтобы повысить эффективность обучаемых функций близости, в статье используют Mixture-of-Logits как универсальный аппроксиматор и предлагают методы его ускорения для получения достаточно точной аппроксимации топ-k соседей. В экспериментах подход авторов обгоняет бейслайны почти в 100 раз по времени работы и при этом достигает 99% полноты/рекола.

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

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

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

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


Meta признана экстремистской организацией, а Facebook и Instagram запрещены на территории РФ
2 198 просмотров · 22 реакций Открыть в Telegram · Открыть пост на сайте
Diffusion Model for Slate Recommendation

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

Ранжирование объектов — важная подзадача в рамках рекомендации слейтов, и для её решения авторы статьи используют отдельные модели, но в данной работе концентрируются на retrieval-части, рассказывая, чем хороши диффузионки. В качестве примеров похожих работ они ссылаются на 2 статьи от Google, за 2015 и 2019 год, где для решения аналогичной задачи используется RL. Проблема в том, что айтемы в слейте являются в RL-подходе независимыми событиями. Это упрощает обучение, но такой подход не совсем корректен, так как зависимость между соседними айтемами в слейте все же есть, что приводит к проблемам с качеством генерации.

Исследователи из Spotify утверждают, что генеративный подход (а именно — диффузионные модели) могут работать лучше, чем RL-like подходы. Диффузионки могут сделать слейт разнообразнее благодаря неявному пониманию, что айтемы не должны быть слишком похожими. Также авторы замечают, что диффузионные модели помогают бороться с popularity bias’ом и включать в подборки менее очевидные треки даже без явного обучения под эту задачу. Также авторы делают conditioning на весь контекст — профиль и запрос пользователя. Опционально в контекст добавляют отдельные айтемы из слейта, которые уже были предсказаны.

По словам исследователей, такой метод даёт значимо лучшие результаты, чем RL и другие привычные решения в сфере рекомендаций слейтов.

@RecSysChannel
Разбор подготовил Владимир Байкалов
2 062 просмотров · 27 реакций Открыть в Telegram · Открыть пост на сайте
Multi-objective Learning to Rank by Model Distillation

Свежая статья от Airbnb о том, как совместить дистилляцию и мультитаск-обучение. Задача ранжирования заключается не только в предсказании конверсии, но и её исхода. Например, человек может вернуть заказ или оставить отзыв. Также он может обратиться в сервис, если возникнут проблемы. Это важно в контексте долгосрочного роста платформы.

По словам авторов, традиционные подходы к ранжированию страдают из-за дисбаланса данных, которых для разных задач может быть разное количество — много для CTR и конверсий, но мало для возвратов, обращений в сервис и т. д. Учесть эти факторы сложно.

Решение — end-to-end multi-objective, совмещенный с дистилляцией. Важно, чтобы при этом инференс и обучение не занимали слишком много времени. Модели объединяют через дистилляцию, после чего добавляют механизм самодистилляции — он даёт лучшую воспроизводимость и помогает побороть cold start при переобучении. Так у авторов получилось решать ad-hoc бизнес-задачи, связанные с недифференцированными функционалами.

Лоссы с разных подзадач объединяют с помощью скаляризации. Отдельные лейблы, возникающие из-за того, что задач несколько, агрегируются в один, т. н. софт-лейбл. При такой постановке происходит шеринг нижних слоев (возможно, не только их). Это оказывает положительное влияние на задачи с разреженными данными, но может работать плохо, если между задачами слабая корреляция — так часто бывает в маркетплейсах. Даже несмотря на это, по словам авторов, выгода от шеринга есть.

Подбирать веса, с которыми суммируются лоссы, при таком подходе дорого, плюс есть риск переобучения. Если подбирать веса каждый раз, когда обновляется какая-то модель — затраты вырастут. Избавиться от онлайн-тюнинга весов и сбалансировать обучение на цели с разным количеством данных помогает дистилляция, а дальнейшая самодистилляция закрепляет и усиливает эффект. Исследователи получили рост метрики nDCG на 1,1% в офлайн-экспериментах и +0,37% бронирований (CVR) в A/B-тестах.

@RecSysChannel
Разбор подготовил Сергей Макеев
2 587 просмотров · 17 реакций Открыть в Telegram · Открыть пост на сайте
LiNR: Model Based Neural Retrieval on GPUs at LinkedIn

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

В LiNR построение индекса рассматривается как процесс обучения, из-за чего и представления объектов, и веса, с помощью которых происходит формирование выдачи, интегрируются в одну модель. Отличительным аспектом статьи является использование честного KNN для формирования выдачи вместо широко распространенного ANN (Approximate Nearest Neighbor). В работе также описывается способ интегрирования фильтраций, основанных на логических правилах, в стадию скоринга объектов индекса, что позволяет повысить качество финальной выдачи.

В статье авторы предлагают три версии алгоритма для генерации кандидатов:
Скоринг всех объектов с последующей фильтрацией. Первое предложенное решение, которое может работать неоптимально, особенно в случаях с большим процентом отфильтрованных объектов (low-pass-rate сценарии).
Предварительная фильтрация объектов с последующим скорингом. Улучшенная версия первого подхода, которая решает его проблемы и увеличивает метрики качества выдачи.
Дополнительное улучшение второго подхода с использованием квантизации. Предлагается использовать две стадии выбора кандидатов после фильтрации: первичный выбор подмножества объектов на основе квантизованных представлений и более гранулярная фильтрация оставшихся объектов для получения финальной выдачи.

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

— С оффлайн инференсом и обновлением модели вы теряете свежих кандидатов, а следовательно, и качество. Real-time обновление LiNR увеличило качество всего пайплайна на 6%.
— Предварительная фильтрация, в отличие от пост-фильтрации, которая может тратить слоты кандидатов на нерелевантные объекты, помогает повысить качество модели.
— По умолчанию TF или PyTorch не приспособлены для реализации retrieval-моделей, из-за чего такие решения будут довольно медленными без дополнительных оптимизаций.
— Имплементация собственного CUDA-ядра для второй и третьей версий модели позволила получить значительное преимущество в скорости (к сожалению, авторы не поделились кодом самого ядра).

@RecSysChannel
Разбор подготовил Владимир Байкалов
2 196 просмотров · 23 реакций Открыть в Telegram · Открыть пост на сайте
Законы масштабирования в больших моделях последовательных рекомендаций

Авторы из WeChat и Tencent разбирались, работают ли законы масштабирования нейросетей для рекомендательных систем. Главный вопрос — есть ли улучшение качества рекомендаций при увеличении количества обучаемых параметров? Короткий ответ — да.

Известно, что рост количества параметров моделей иногда коррелирует с улучшением качества решаемых задач. Больше всего работ посвящено законам масштабирования в языковых моделях. В них определяется эмпирическая зависимость функции потерь на отложенной выборке от характеристик обучения. Обычно рассматривают параметры энкодеров и/или декодеров. Для NLP зависимость в логарифмических координатах получается линейной.

В работе об SR авторы масштабировали декодер трансформера и вносили изменения в стратегии обучения, чтобы получить закон масштабирования для рекомендательных систем:
— Для слоёв в начале последовательности декодер-блоков применяли больший dropout-rate, а для слоёв на вершине — меньший, что позволило избежать оверфита.
— Сначала обучались с Adam до полной сходимости, а потом брали чекпоинты, с которых продолжали обучение при помощи SGD, потому что несмотря на лучшую сходимость, итоговый минимум у Adam получался хуже.

Историю взаимодействий форматировали как хронологическую последовательность ID айтемов. То есть задача решалась так же, как в случае с языковыми моделями. Исследователи не брали другую информацию (например, текст айтема), так как хотели изучить работу закона с т. з. поведения пользователя. Модели увеличивали до 0,8B параметров, сравнивая эффекты в разных диапазонах размеров.

Оказалось, закон масштабирования работает для SR-моделей даже в сценариях с ограниченным количеством данных. Авторы показали преимущество больших моделей и на сложных задачах рекомендаций: cold start, long tail, определяли траектории пользователей и смотрели, что происходит при мультидоменном трансфере — во всех случаях масштабирование улучшало результаты.

@RecSysChannel
Разбор подготовил Артем Матвеев
11 391 просмотров · 18 реакций Открыть в Telegram · Открыть пост на сайте
ICML 2024 — как это было
В этом году на одну из крупнейших конференций по машинному обучению, ICML, ездила большая делегация от Яндекса — там были и наши специалисты в сфере рекомендательных систем. Мы поговорили с Даниилом Лещёвым и Андреем Мищенко и узнали, какие доклады запомнились коллегам больше всего.

Рекомендательные системы
Actions Speak Louder than Words: Trillion-Parameter Sequential Transducers for Generative Recommendations
Статья на актуальную тему — о новой архитектуре ML-моделей в рекомендациях, позволяющей использовать все преимущества скейлинга. Результаты впечатляют — нам и самим захотелось попробовать!

Wukong: Towards a Scaling Law for Large-Scale Recommendations
Ещё один интересный пейпер, тоже от Meta*, на тему масштабирования моделей в рекомендательных системах.

xLSTM: Extended Long Short-Term Memory
Авторы применяют методы и техники из мира новейших LLM, чтобы улучшить архитектуру, увеличить масштаб и повысить производительность LSTM-моделей.

Inferring the Long-Term Causal Effects of Long-Term Treatments from Short-Term Experiments
Статья от Netflix — авторы замеряют долгосрочные эффекты от внедрений через краткосрочные эксперименты. Рассматривая задачу в RL-постановке, получают теоретические оценки на результат и проверяют подход в симуляционных средах.

Интересное и забавное
Discovering environments with XRM
Статья об обучении в целом. Авторы предлагают метод перекрестной минимизации рисков (XRM) — учат 2 сети, каждая из которых использует случайную половину обучающих данных, тем самым повышая внимание к примерам, на которых ошибается текущая версия модели.

Enforced Amnesia as a Way to Mitigate the Potential Risk of Silent Suffering in Conscious AI
Не обошлось без забавного — здесь название говорит само за себя 😉

A Touch, Vision, and Language Dataset for Multimodal Alignment
Оригинальная тема — авторы обучали роборуку осязанию — трогать разные поверхности и описывать их: «мягкое, с пупырышками», «гладкое и твёрдое» и т. д.

А вам захотелось изучить статьи и опробовать подходы на практике?

@RecSysChannel

Meta признана экстремистской организацией, а Facebook и Instagram запрещены на территории РФ
14 331 просмотров · 16 реакций Открыть в Telegram · Открыть пост на сайте
Кластерная якорная регуляризация в рекомендательных системах
Обучение на логах юзеров может приводить к popularity bias. Мы рекомендуем айтемы, человек их смотрит, это попадает в логи и оттуда — в дальнейшее обучение. В итоге «богатый становится богаче». Известные способы борьбы с этим ухудшают перфоманс популярных айтемов, что тоже плохо. Ресёрчеры из DeepMind предлагают свой метод, Cluster Anchor Regularization, и применяют его для YouTube Shorts.

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

Кластеры генерируют энкодером с учётом метаданных и контента. 2-миллиардный индекс мапится в 256-размерные эмбеддинги. Они фиксированы, считаются один раз и нужны лишь для построения графа, который и будет кластеризоваться. Об архитектуре энкодера авторы не пишут.

Ноды графа — айтемы, а рёбра отражают косинусную близость между ними. Граф разбивается на кластеры так, что рёбра, выходящие из одного кластера и приходящие в другой, получают меньший вес. Каждой ноде сопоставляют вес, равный √ числа взаимодействий с айтемом. После 4 уровней кластеризации получается 48 000 кластеров. В каждом из них внутри одного уровня примерно одинаковое число взаимодействий.

Якорная регуляризация
Внутри кластеров есть source- и target-айтемы. В нашем случае source — популярные айтемы, а target — непопулярные. Каждому айтему сопоставляем его обучаемый эмбеддинг, а каждому кластеру — эмбеддинг такой же размерности. На первом этапе source-айтемы мапятся в свои кластеры, а представления кластеров обучают так, что градиент просачивается в них, не изменяя source-векторы.

На втором этапе то же самое происходит с target-айтемами, но обновляется уже не представление кластера, а векторы target’ов. Результаты обоих этапов добавляем в основной loss. Благодаря этому получается «эффект якоря»: популярные айтемы «тянут» за собой непопулярные.

@RecSysChannel
Разбор подготовил Сергей Макеев
4 072 просмотров · 21 реакций Открыть в Telegram · Открыть пост на сайте
🤖 HyperFormer от DeepMind: выучить выразительные представления для sparse-фичей
Авторы статьи рассказывают, как улавливать высокоуровневые взаимосвязи между категориальными фичами (они же — sparse-фичи) и благодаря этому выучивать информативные эмбеддинги в том числе и для редких значений.

Например, в выборке много москвичей, но всего несколько жителей Нью-Йорка. Таких редких значений категориальных признаков в датасетах может быть много — возникает т. н. тяжёлый хвост признаков. Современные нейросети справляются с ним плохо — для решения этой проблемы и придуман HyperFormer.

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

Для каждого батча данных рассматривается гиперграф, в котором вершинами являются сэмплы, а рёбрами — значения категориальных фичей. Ребро гиперграфа может, к примеру, связать всех жителей Нью-Йорка или все айтемы одной ценовой категории.

Гиперформер
Модель, которая выучивает информативные эмбеддинги sparse-фичей. Dense-фичи гиперформер не обрабатывает — этим, как и финальными предсказаниями, занимаются upstream-модели.

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

Гиперформер состоит из двух трансформерных декодеров, один — над эмбеддингами значений категориальных фичей, другой — над эмбеддингами сэмплов текущего батча. В обоих декодерах используются только кросс-аттеншены: в первом query вычисляется по фичам, key и value вычисляются по сэмплам, а во втором — наоборот.

То, что модель оперирует над структурой гиперграфа, построенного по текущему батчу, обеспечивается масками в кросс-аттеншенах — сэмплы «смотрят» только на те значения категориальных фичей, которые к ним относятся, и vice versa. Получается, декодеры на каждом слое обмениваются информацией — в гиперграфе она перетекает от вершин к инцидентным им рёбрам и от рёбер — к инцидентным им вершинам.

@RecSysChannel
Разбор подготовил Сергей Лямаев
1 239 просмотров · 12 реакций Открыть в Telegram · Открыть пост на сайте