Scaling Recommender Transformers to One Billion Parameters

Инженеры из группы исследования перспективных рекомендательных технологий выложили на arXiv статью о подходе ARGUS, которому ранее посвятили рассказ на Датафесте и пост на Хабре. Сейчас статья находится на ревью на KDD’26, но текст уже доступен для всех желающих.

В статье команда авторов делится опытом по масштабированию рекомендательных трансформеров, вдохновлённым нашумевшей работой Actions Speak Louder than Words.

В моделях Sequential Recommendation можно выделить четыре оси масштабирования: число параметров в таблице эмбеддингов, длина истории пользователя, размер датасета и количество параметров в трансформере. В то время как матрицы эмбеддингов могут содержать миллиарды параметров, а датасеты достигать триллионов токенов, размеры индустриальных трансформеров всё ещё остаются чрезвычайно малы в сравнении с языковыми моделями — сотни миллионов параметров. Авторам удалось обучить трансформер с миллиардом параметров на датасете из Яндекс Музыки и добиться прироста метрик.

Команда верит, что для успешного масштабирования рекомендательный трансформер должен предобучаться на фундаментальную задачу. Оказывается, Next Item Prediction может быть недостаточно — нужно уметь не только имитировать поведение предыдущей рекомендательной модели, породившей взаимодействия, но и корректировать её навыки. Другими словами, помимо предсказания следующего взаимодействия полезно научиться оценивать его.

Естественный способ это сделать — представить историю в виде пар токенов (item, feedback), из айтема предсказывать фидбек, а из фидбека — следующий айтем. Поскольку каждое взаимодействие представляется парой токенов, длина истории вырастает в два раза, увеличивая вычислительные затраты. Поэтому на практике каждое взаимодействие представляли одним токеном, а предсказание фидбека обуславливали на следующий айтем.

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

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

ARGUS уже внедрили в Яндекс Музыку, увеличив вероятность лайка на 6,37% и TLT на 2,26%. Внедрение оказалось самым успешным среди всех нейросетей в Музыке. А ещё ARGUS внедрили в Алису, Маркет, Лавку, и другие сервисы Яндекса.

Подробнее о решении можно прочитать в статье.

Статью написали Кирилл Хрыльченко, Артём Матвеев, Сергей Макеев, Владимир Байкалов

@RecSysChannel
2 573 просмотров · 38 реакций Открыть в Telegram · Открыть пост на сайте
Как прошла ICLR 2025: впечатления инженеров Яндекса

Подводим итоги конференции — для этого собрали впечатления, тенденции и интересные статьи, отмеченные инженерами, посетившими её.

Работы, упоминаемые в карточках:

- Language Representations Can be What Recommenders Need: Findings and Potentials
- TabReD: Analyzing Pitfalls and Filling the Gaps in Tabular Deep Learning Benchmarks
- TabM: Advancing Tabular Deep Learning with Parameter-Efficient Ensembling
- SLMRec: Distilling Large Language Models into Small for Sequential Recommendation
- CoS: Enhancing Personalization and Mitigating Bias with Context Steering
- Amulet: ReAlignment During Test Time for Personalized Preference Adaptation of LLMs

@RecSysChannel

#YaICLR
2 047 просмотров · 20 реакций Открыть в Telegram · Открыть пост на сайте
TransAct V2: Lifelong User Action Sequence Modeling on Pinterest Recommendation

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

Pinterest остаётся верен классической трёхстадийной архитектуре: retrieval — scoring — blending. На первом этапе модель отбирает несколько тысяч кандидатов, которые затем проходят pointwise-ранжирование. Ранжирующая модель оптимизируется исключительно под фид. Особое внимание уделяется тому, как используется длинная история действий — ключевое отличие от предыдущих решений.

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

Модель представляет собой multitask-архитектуру в pointwise-постановке. На вход она получает эмбеддинги, включающие обучаемые параметры, категорию взаимодействия, позиционный эмбеддинг и эмбеддинг пина. Последний строится как объединение эмбеддинга кандидата и карточек из истории, к которым кандидат наиболее близок по контенту. Трансформер с минимальным числом параметров (два слоя, одна attention-глава, скрытое представление размерности 64) пропускает эту последовательность и генерирует выходные векторы, которые подаются в линейный слой для генерации прогнозов.

Loss-модель использует два компонента: взвешенную кросс-энтропию по каждому действию (лайк, добавление в избранное и прочее) и sampled softmax loss на задачу next action prediction. В качестве позитивов используются все позитивные взаимодействия в последовательности, а в качестве негативов — показы. Авторы отмечают, что подход показывает себя лучше, чем batch sampling. Среди архитектурных решений также интересно, что один и тот же пин, встретившийся с разными действиями, кодируется как multi-hot-вектор, а эмбеддинги пинов хранятся в квантизованном виде (int8) и деквантизируются в float16 перед подачей в трансформер.

Ключевые нововведения — в инфраструктуре. Стандартные решения на PyTorch оказались неприменимы из-за избыточной материализации данных. Разработчики переписали инференс на собственный сервер с кастомными трансформерными ядрами в Triton (речь не о сервере NVIDIA, а о языке для компиляции под GPU). Такой подход позволил избежать дополнительных обращений к памяти: квантизованные векторы декодируются, нормализуются и сразу же используются для поиска ближайших соседей.

Ещё в работе реализовали оптимизации вроде кэширования длинных пользовательских историй в сессии (чтобы избежать их загрузки при каждом реквесте), дедупликации запросов и эффективного распределения памяти между CPU и GPU. Всё вместе это дало серьезный прирост производительности: latency снизился в 2–3 раза по сравнению с PyTorch, использование памяти тоже оказалось эффективным. Переход на собственные ядра позволил сократить время инференса на 85% и расход памяти на 13% при длине последовательности 192. Решение выигрывает и у FlashAttention 2: ядра оказались на 66% быстрее и потребляли на 5% меньше памяти, при этом FlashAttention 2 не поддерживает пользовательское маскирование токенов.

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

@RecSysChannel
Разбор подготовил Руслан Кулиев
4 307 просмотров · 24 реакций Открыть в Telegram · Открыть пост на сайте
Scaling Transformers for Discriminative Recommendation via Generative Pretraining

Тема масштабирования моделей в рекомендательных системах продолжает набирать популярность. Недавно Alibaba представила работу о масштабировании ранжирующих моделей для персональных рекомендаций товаров на AliExpress. О ней и поговорим.

В ML выделяют два класса вероятностных моделей:

— Дискриминативные — моделируют условное распределение p(y|x) (предсказывают метку y по данным x). Примеры: логистическая регрессия, большинство моделей для ранжирования.
— Генеративные — моделируют совместное распределение p(x, y), что позволяет генерировать данные. Примеры: GPT, диффузионные модели.

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

Решение — добавить генеративное предобучание (метод назван GPSD — Generative Pretraining for Scalable Discriminative Recommendation), а затем — дискриминативное дообучение. Ключевое преимущество заключается в том, что генеративное предобучание не страдает от сильного разрыва в обобщающей способности между обучением и валидацией, что и открывает путь к масштабированию.

Технические детали

1. Генеративное предобучение

— Используется архитектура трансформера с каузальной маской над историей взаимодействий.
— Модель решает две задачи: предсказание следующего товара (Sampled Softmax Loss с равномерно семплированными негативами из каталога) и предсказание его категории.
— При кодировании товаров применяются обучаемые эмбеддинги для каждого айтема, а также дополнительные фичи, такие как категория.
— Агрегация делается путём суммирования.

2. Дискриминативное дообучение

— Добавляется CLS-токен в историю. Его выходной вектор используется как представление пользователя.
— Это представление конкатенируется с фичами кандидата (товара, для которого предсказывается CTR) и подается на вход MLP.

3. Стратегия переноса весов

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

Ключевые результаты

— Без генеративного предобучения: увеличение модели не даёт прироста качества (AUC) из-за переобучения, наблюдается даже деградация.
— С GPSD: устойчивое масштабирование — рост AUC при увеличении размера модели от 13 тысяч до 300 млн параметров. Выведен степенной закон зависимости AUC от числа параметров.
— A/B-тест на рекомендательной платформе AliExpress: в продакшен выведена модель с тремя слоями трансформера и скрытой размерностью 160 (очень компактная).
Результат: +7,97% GMV, +1,79% покупок.

Замечания

1. Использованные модели и датасеты — небольшие, что немного подрывает веру в результаты.

2. При масштабировании одновременно с dense-частью (трансформер) увеличивались и sparse-часть (матрицы эмбеддингов), что также могло быть фактором роста качества. Для более честного замера её размер нужно было зафиксировать.

@RecSysChannel
Разбор подготовил Артём Матвеев
1 915 просмотров · 19 реакций Открыть в Telegram · Открыть пост на сайте
Preference Diffusion и Decoupled Embeddings: две статьи о масштабируемых рекомендациях

Сегодня разбираем ещё две статьи с ICLR — о диффузионных моделях в рекомендациях и о борьбе с градиентными конфликтами в длинных пользовательских историях.

Preference Diffusion for Recommendation

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

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

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

Вместо того чтобы обрабатывать сотни негативов по отдельности (что тяжело вычислительно), авторы сэмплируют 256 негативов, усредняют, берут центроид — и используют как один «усреднённый негатив». Такая тактика резко снижает нагрузку, но сохраняет информативность. По словам одной из соавторов, Ан Чжан, идея эффективного добавления негативов и упрощение вычислений — главный вклад статьи в индустрию — без этого диффузионка в рекомендациях просто не взлетает.

Ещё одно улучшение касается больших размерностей эмбеддингов. Авторы показали, что такие модели начинают работать только на размерностях больше 2 тысяч. Привычные 64 или 128 не дают никакого результата — лосс почти не убывает.

Итог: модель обучается быстрее, чем в предыдущих подходах. Её удалось встроить в классический пайплайн даже без больших кандидатов (в отличие от AlphaRec).

Long-Sequence Recommendation Models Need Decoupled Embeddings

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

В стандартном подходе одни и те же эмбеддинги используются и для блока attention, и для блока representation.

Авторы показывают, что в таком случае возникает конфликт между градиентами: одна часть модели (например, attention) толкает эмбеддинги в одну сторону, другая (representation) — в другую. В статье подсчитали, как часто градиенты конфликтуют — оказалось, больше чем в половине случаев.

Ещё исследователи измеряют, сколько лосса проходит через каждую часть — и оказывается, что representation тянет на себя ощутимо больше, чем attention. Это приводит к перекосу: одна часть доминирует, другая «умирает».

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

Тогда исследователи делают жёсткое разнесение: делят эмбеддинг на две части — одна идёт в attention, другая — в representation. Причём первая в 3–4 раза меньше, потому что attention всё равно получает меньше градиентного сигнала, и для него достаточно компактного представления. Это решение устраняет конфликт, ускоряет инфернес и не ухудшает качество. Визуально это хорошо видно на графиках: чем больше разнесение и уменьшение attention-части, тем выше эффективность.

Интересный побочный эффект — за счёт того, что attention работает на меньших векторах, система становится до 50% быстрее.

Авторы утверждают, что решение уже внедрено в продакшн и работает там на больших масштабах.

@RecSysChannel
Обзор подготовил Василий Астахов

#YaICLR
1 446 просмотров · 13 реакций Открыть в Telegram · Открыть пост на сайте
Scaling law в рекомендательных системах

Законы масштабирования вышли за рамки NLP и успешно применяются в рекомендательных системах. В наших карточках исследователь Владимир Байкалов затронул последние работы на эту тему. С обзором прошлых статей можно ознакомиться в этом посте.

Работы, упомянутые в карточках:
- Language Models are Unsupervised Multitask Learners
- Scaling Laws for Neural Language Models
- Training Compute-Optimal Large Language Models
- Actions Speak Louder than Words: Trillion-Parameter Sequential Transducers for Generative Recommendations
- Scaling New Frontiers: Insights into Large Recommendation Models
- Unlocking Scaling Law in Industrial Recommendation Systems with a Three-step Paradigm based Large User Model
- Scalable Cross-Entropy Loss for Sequential Recommendations with Large Item Catalogs
- Разбор статьи HSTU в канале «Рекомендательная»

@RecSysChannel
Обзор подготовил Владимир Байкалов
1 961 просмотров · 40 реакций Открыть в Telegram · Открыть пост на сайте
Conservative RL и ContextGNN: два подхода к рекомендациям с ICLR 2025

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

Looking into User’s Long-term Interests through the Lens of Conservative Evidential Learning

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

Из более ранних работ мы знаем, что оффлайн-прогнозатор не всегда хорошо догадывается о полезных латентных признаках. RL, за счёт обучения с другой формулировкой, может «подсказать» модели, какие сигналы стоит запоминать — даже если они редкие.

Аналогичный эффект и в этой статье. Хотя RL-сценарий тут продвинутый — авторы предлагают подход ECQ-L (Evidential Conservative Q-Learning). В нём комбинируется несколько идей.

Evidential learning — вместо классического эксплорейшена, они учатся на уменьшение неопределённости. То есть выбирают айтемы, которые дают больше информации (не просто максимальный reward, а максимальное снижение неуверенности).

Conservative learning — модель не переоценивает редкие положительные примеры. Если какая-то рекомендация «сработала», но по данным это было маловероятно, её вес занижается. Это сделано, чтобы не переобучаться на случайные удачи. Например, пользователь смотрел романтические фильмы, а вы случайно порекомендовали хоррор, и он понравился. ECQ-L в этом случае не будет придавать слишком большого значения этому событию, потому что оно слабо объясняется историей.

Это и есть суть conservative-части подхода — модель целится не просто в reward, а в нижнюю границу его оценки, основанную на уверенности.

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

Также используются разные типы лосса — отдельно на состояние, на действие, на оценку и на неопределённость.

Авторы показывают хорошие метрики — как в классическом RL-сценарии, так и в оффлайн-постановке.

ContextGNN: Beyond Two-Tower Recommendation Systems

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

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

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

Что показывают эксперименты:

- Если в датасете пользователь в основном «ходит по кругу», то выигрывает первая ветка — графовая.
- Если он часто пробует новое — вторая модель начинает давать вклад.
- Их основная модель всегда оказывается лучше, чем каждая по отдельности.

В целом, это не радикально новая архитектура, но хорошее объединение знакомых подходов: модуль, который учится на известном (GNN); модуль, который работает с новым (two-tower); модуль-медиатор, который учится понимать, чего хочет пользователь сейчас.

@RecSysChannel
Обзор подготовил Василий Астахов

#YaICLR
1 889 просмотров · 18 реакций Открыть в Telegram · Открыть пост на сайте
Language Representations Can be What Recommenders Need: Findings and Potentials

Разбираем одну из самых интересных статей на тему рекомендательных систем с ICLR 2025. Её авторы задаются вопросом: действительно ли LLM неявно кодируют информацию о предпочтениях пользователей. В работе предлагается использовать эмбеддинги айтемов из LLM для улучшения качества рекомендаций.

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

Таким образом можно извлечь и представление пользователя, усреднив эмбеддинги айтемов из его истории взаимодействий. Представления пользователей и айтемов затем используются для получения скора ранжирования (например, с помощью dot-product).

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

В статье рассуждают о нескольких вариантах кодирования айтемов: с использованием ID и матриц эмбеддов, с использованием LLM. У первого подхода есть недостатки: например, плохая переносимость эмбеддингов между доменами и отсутствие явной возможности распознавать намерения пользователей. Их и призван нивелировать второй подход.

Главные вопросы, на которые хотят ответить в статье: кодируют ли LLM коллаборативный сигнал и насколько наличие сигнала зависит от размеров модели. Сравниваясь с существующими методами на модельных датасетах, авторы приходят к выводам о превосходстве представлений, полученных с помощью LLM, над ID-based подходом. Также утверждают, что с увеличением размера модели увеличивается репрезентативность пользовательских интересов.

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

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

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

#YaICLR
1 965 просмотров · 13 реакций Открыть в Telegram · Открыть пост на сайте
Исследователи Яндекса выложили в опенсорс Yambda — датасет на 5 млрд событий

В открытом доступе появился Yandex Music Billion-Interactions Dataset (Yambda) — один из крупнейших в мире датасетов в области рекомендательных систем. В этом посте рассказываем, зачем он нужен и какие у него ключевые особенности.

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

Существующие доступные датасеты, такие как MovieLens, Netflix Prize dataset, Amazon Reviews, Music4All-Onion, Steam и несколько других имеют ряд недостатков. Например, сравнительно небольшой размер делает их нерепрезентативным для коммерческих масштабов, а фокус на явных сигналах ограничивает полезность для моделирования реальных последовательных взаимодействий.

Чтобы решить эти проблемы и дать исследователям больше возможностей для разработки и тестирования новых гипотез в рекомендациях, исследователи Яндекса выложили в опенсорс свой датасет Yambda.

Ключевые особенности Yambda:

— Содержит 4,79 млрд обезличенных взаимодействий пользователей с музыкальными треками в Яндекс Музыке.
— Есть три версии: полная (5 млрд событий) и уменьшенные (500 млн и 50 млн
событий).
— Включает два основных типа взаимодействий: неявную обратную связь (прослушивания) и явную обратную связь (лайки, дизлайки, анлайки и андизлайки).
— Для большинства треков есть нейросетевые вектора, сгенерированные с помощью свёрточной нейронной сети (CNN), что позволяет учитывать некоторые характеристики музыкальных треков.
— Включены анонимизированные признаки метаданных треков, такие как длительность, содержание вложений, исполнитель и альбом.
— Каждое событие помечено флагом is_organic, который позволяет различать органические действия пользователей и действия, вызванные рекомендациями алгоритма.
— Все события имеют временные метки, что позволяет проводить анализ временных последовательностей и оценивать алгоритмы в условиях, приближённых к реальным.
— Данные распределены в формате Apache Parquet, что обеспечивает совместимость с распределёнными системами обработки данных (например, Hadoop, Spark) и современными аналитическими инструментами (например, Polars, Pandas).

Методы оценки

В отличие от метода Leave-One-Out (LOO), который исключает последнее положительное взаимодействие пользователя из обучающей выборки для предсказания, Yambda-5B использует глобальный временной сплит (Global Temporal Split, GTS). Преимущество GTS в том, что он сохраняет временную последовательность событий, предотвращая нарушение временных зависимостей между тренировочным и тестовым наборами данных. Это позволяет более точно оценить, как модель будет работать в реальных условиях, когда доступ к будущим данным ограничен или невозможен.

Вместе с датасетом представлены baseline-алгоритмы (MostPop, DecayPop, ItemKNN, iALS, BPR, SANSA, SASRec). Они служат отправной точкой для сравнения эффективности новых подходов в области рекомендательных систем.

Используются следующие метрики:

— NDCG@k (Normalized Discounted Cumulative Gain) — оценивает качество ранжирования рекомендаций.
— Recall@k — измеряет способность алгоритма генерировать релевантные рекомендации из общего набора возможных рекомендаций.
— Coverage@k — показывает, насколько широко представлен каталог элементов в рекомендации.

Датасет и код для оценочных бейзлайнов уже доступны на Hugging Face, а статья — на arXiv.

UPD: Появилось видео выступления Саши Плошкина на ACM RecSys — оставим его здесь для истории 💫

Статью подготовили Александр Плошкин, Владислав Тыцкий, Алексей Письменный, Владимир Байкалов, Евгений Тайчинов, Артём Пермяков, Даниил Бурлаков, Евгений Крофто, Николай Савушкин

@RecSysChannel
4 206 просмотров · 52 реакций Открыть в Telegram · Открыть пост на сайте
Что делают в мире: LLM & RecSys. Часть 2/2

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

Real-time Ad retrieval via LLM-generative Commercial Intention for Sponsored Search Advertisin

Статья от Tencent, в которой LLM используются для кандидатогенерации в рекламе. Исследования последних лет показывали эффективность LLM в этом направлении, но подходы сводились к следующему: в офлайне строятся индексы документов, а в онлайне на основе запроса LLM генерирует подходящий индекс. Такой подход концептуально неплох, но имеет ряд недостатков с точки зрения как качества, так и эффективности инференса. Tencenet же делают следующее: в офлайне с помощью LLM генерируют «коммерческие предложения» (CI) для рекламного корпуса, строят динамический индекс формата {CI: Рекламные объявления} так, что одному CI ставится в соответствие сразу пачка объявлений. В онлайне же — отдельной затюненной LLM генерирует CI для запроса и по соответствующему CI достаёт объявления-кандидаты из офлайн-хранилища. Такой формат хранения ключей позволяет значительно лучше утилизировать способности LLM к обработке, внезапно, естественного языка и отлично себя показывает на онлайн-метриках: на различных поверхностях прирост GMV составил от 5,02% до 6,37%.

The Blessing of Reasoning: LLM-Based Contrastive Explanations in Black-Box Recommender Systems

Гигантская статья с участием небезызвестной Minmin Chen. Представим, что нам удалось построить хорошую рекомендательную модель, которая прекрасно работает в продакшене. Но как для самих исследователей, так и для внешнего мира (и внутренних заказчиков) может быть интересно и важно, почему система приняла именно такое решение. Это банально интересно, позволяет лучше понять аудиторию, да и просто это отличные вводные для улучшений в будущем. К сожалению, ответить на вопрос почему крайне сложно, особенно если модель нейросетевая — сложность архитектуры просто не позволяет связать входы и выходы модели и составить понятную интерпретацию. Но буквально по соседству продолжается бурное развитие LLM — с глубоким знанием о мире и потрясающей способностью к рассуждению. Мы можем делегировать reasoning-моделям задачу «понимания» пользователя и поиск наиболее важных точек соприкосновения между ним и товаром-кандидатом, чтобы получить обоснование релевантности. Авторы показывают, что помимо хорошей объясняющей способности, добавление в рекомендательную систему знания LLM о мире также позволяет добиться лучшего качества на публичных датасетах.

LLM-Alignment Live-Streaming Recommendation

Статья от Kuaishou, где авторы пытаются объединить RecSys, LLM, мультимодальность — и всё это упаковать в реалтаймовый сценарий. Сначала происходит подготовка языковой модели для стриминга: используют 100B модель для разметки 30-секундных видеофрагметов, на основе которых тюнят 7B-модель для быстрого инференса, чтобы в реалтайме строить высокоинформативные эмбеддинги, которые далее передаются рекомендательной модели. LLM-эмбеддинги выравнивают с рекомендательными id-based-эмбеддингами с помощью отдельного гейтинг-механизма, чтобы получить итоговое представление, связывающее рекомендательный сигнал автора, пользователя и LLM-знание о происходящем на стриме. Полученный единый эмбеддинг переводят в Semantic ID и используют в итоговой модели ранжирования. A/B-эксперимент показал рост времени просмотра на двух стриминговых платформах на 0,07% и 0,17%, число лайков на 2,5% и 2,8% соответственно на стадии ранжирования. При этом особенно сильный рост числа показов наблюдается для контент-мейкеров с хвоста распределения, с числом подписчиков до порядка 100~1000.

@RecSysChannel
Обзор подготовил Руслан Кулиев
2 276 просмотров · 17 реакций Открыть в Telegram · Открыть пост на сайте
Unified Embedding: Battle-Tested Feature Representations for Web-Scale ML Systems

Сейчас в RecSys много говорят о семантических ID для кодирования айтемов. У нас в «Рекомендательной» уже были материалы о разных алгоритмах с этой техникой:

Recommender Systems with Generative Retrieval
From Features to Transformers: Redefining Ranking for Scalable Impact
OneRec: Unifying Retrieve and Rank with Generative Recommender and Iterative Preference Alignment
Learnable Item Tokenization for Generative Recommendation

Но также вспомним классические методы кодирования айтемов. Один из популярных и очень мощных на практике — Multisize Unified Embeddings. Он предоставляет способ кодирования набора категориальных признаков произвольной кардинальности в единый вектор.

Как это работает.

Пусть дан набор айтемов D={x₁,…,x_N}. Каждый из них описан T категориальными признаками x = [v₁,…,v_T], где vₜ∈Vₜ.

Классические подходы к кодированию

1. Collisionless (без коллизий)
– Для каждого признака t и каждого его значения vₜ хранится отдельный вектор-эмбеддинг.
– Плюс: нет коллизий.
– Минус: память растёт пропорционально сумме кардинальностей всех Vₜ.

2. Hash Table (feature hashing)
– Каждое значение одного признака хешируется в таблицу размера M.
– Плюс: фиксированный объём памяти, независимо от числа значений.
– Минус: внутрипризнаковые коллизии искажают градиенты и ухудшают качество.

Подход Unified Table

Авторы предлагают объединить всё в одну общую хеш-таблицу размера M, но использовать для каждого признака свою хеш-функцию hₜ:
– Плюс: только одна таблица, всего два гиперпараметра (M и параметры хеша).
– Минус: появляются межпризнаковые коллизии, когда значения разных признаков попадают в один и тот же бакет.

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

Теоретический анализ из статьи показывает:
– Межпризнаковые коллизии (случай t≠s, когда hₜ(v) и hₛ(u) уходят в один бакет) нейтрализуются последующей нейросетью: для каждой группы модель учит почти ортогональные проекции. Такие коллизии не влияют на качество.
– Внутрипризнаковые коллизии (разные v₁,v₂∈Vₜ хешируются в один бакет) создают устойчивое смещение градиента и ухудшают качество решаемой задачи.

Улучшение: Multisize Unified Table

Для каждого признака t вместо одного хеша используют сразу k независимых хеш-функций hₜ¹…hₜᵏ→[1…M].
– «Плохие» внутрипризнаковые коллизии почти исчезают;
– Объём памяти остаётся таким же, как в Unified Table.

Итог

Multisize Unified Embeddings дают качество, сопоставимое с отдельными таблицами эмбеддингов, но требуют в разы меньше памяти и отлично масштабируются на web-scale.

@RecSysChannel
Разбор подготовил Артём Матвеев
2 197 просмотров · 26 реакций Открыть в Telegram · Открыть пост на сайте
Learnable Item Tokenization for Generative Recommendation

Тренд на семантические ID развивается уже более полугода. Начало положила статья TIGER, в которой для генеративного ретривала контентные эмбеддинги айтемов квантовали с помощью RQ-VAE. Статья вышла ещё в 2023 году, но популярность к подходу начала приходить только после конференции RecSys в 2024-м.

В сегодняшней статье авторы предлагают модификацию алгоритма квантизации — Learnable Item Tokenization for Generative Recommendation (LETTER). Новый подход основан на трёх идеях:

1. сохранение иерархичности семантической квантизации;
2. контрастивное сближение квантизаций и коллаборативных эмбеддингов (полученных через предобученный SASRec или LightGCN);
3. сглаживание распределений айтемов по центроидам кодбуков.

Еще одно отличие от TIGER — для того чтобы генерировать валидные коды, используются префиксные деревья по аналогии со статьей How to Index Item IDs for Recommendation Foundation Models.

Отдельное спасибо авторам хочется выразить за подробный ablation study числа кодов в иерархии квантизации: они отмечают, что увеличение числа кодов не всегда улучшает работу модели из-за накопления ошибки при авторегрессивном инференсе без teacher forcing. Очень полезны и данные о числах эмбеддингов в кодбуках.

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

1. предобученная контентная модель (в их случае это LLaMA-7B);
2. предобученная коллаборативная модель (например, SASRec или LightGCN);
3. другой подход к экспериментам — сейчас они, как правило, проводятся на открытых датасетах без time-split, из-за этого применимость метода в индустрии пока под вопросом.

@RecSysChannel
Разбор подготовил Сергей Макеев
2 192 просмотров · 17 реакций Открыть в Telegram · Открыть пост на сайте
SLMREC: Distilling Large Language Models Into Small For Sequential Recommendation

Сегодня разбираем статью от исследователей Rutgers University и Ant Group, представленную на ICLR 2025. Авторы предлагают альтернативу тяжёлым LLM в рекомендательных системах. Они доказывают, что для sequential recommendation достаточно компактных моделей, если правильно «дистиллировать» знания из больших LLM.

В статье рассматриваются два подхода интеграции LLM в рекомендательные системы:

Генеративные методы (G-LLMRec): Модель предсказывает следующий товар как «следующий токен» в последовательности (аналогично генерации текста). Примеры: P5, LLaRa.

Методы на основе эмбеддингов (E-LLMRec): LLM используется как экстрактор признаков. Последний скрытый слой модели преобразуется в вектор пользователя, который сравнивается с векторами товаров через скалярное произведение. SLMRec относится ко второму типу.

Авторы применяют LLM (говорят о LLaMa-7B) для получения «учителя», а затем дистиллируют его знания в компактную модель через выравнивание промежуточных представлений.

Архитектура и подход

— Используют технику knowledge distillation: большая модель (LLaMa-7B) выступает «учителем», а компактная (в 8 раз меньше) — «учеником».

— Обнаружили, что 75% слоёв в LLM избыточны для рекомендательных задач. Удаление лишних слоёв почти не влияет на качество.

— Вводят тройной механизм переноса знаний между учеником и учителем: выравнивание направлений эмбеддингов (через cosine similarity), регуляризация норм векторов и многоуровневый надзор за скрытыми состояниями. Надзор вкратце такой: слои группируются в блоки, а на выходах каждого блока добавляются «адаптеры», которые проецируют скрытые состояния ученика в пространство учителя. Ученик учится предсказывать выходы всех блоков одновременно, а не только финальный слой.

— Объединяют слои модели в блоки (по 4–8 слоев) для групповой дистилляции — так ученик учится воспроизводить иерархическое представление данных.

— Модель обучается только на позитивных взаимодействиях.

Ключевые фишки

— Эффективность: SLMREC требует всего 13% параметров оригинальной LLM, ускоряя обучение в 6,6 раза, а инференс — в 8 раз.

— Универсальность: метод совместим с другими техниками оптимизации — квантизацией и прунингом.

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

Эксперименты на данных Amazon (одежда, фильмы, музыка, спорт) показали, что SLMREC не только догоняет LLM по метрикам (HR@10, NDCG), но иногда даже превосходит — вероятно, за счёт снижения шума в глубоких слоях.

Спорные моменты

— Неясно, как модель адаптируется к cold start — авторы используют предобученные эмбеддинги, но не проверяют сценарий с новыми пользователями или товарами.

— Как именно выбирались слои для удаления? В статье сказано: «экспериментально обнаружена избыточность», но нет чётких критериев. Например, могла быть использована простая эвристика вроде «среднее значение активаций», что не гарантирует оптимальности.

— Метод тестировался только на Amazon-датасетах (одежда, фильмы), где плотность взаимодействий выше, чем в реальных соцсетях. В системах с миллиардами пользователей и «длинными хвостами» нишевого контента (например, TikTok) эффективность SLMREC под вопросом.

— Хотя инференс быстрее в 8 раз, сама дистилляция требует обучения как учителя (LLaMA-7B), так и ученика.

Выводы

Работа предлагает практичный компромисс для продакшена. Однако остаётся вопрос: можно ли масштабировать подход до экосистем с миллиардами айтемов, где даже 1B параметров — уже много? Авторы обещают исследовать few-shot-обучение в будущем.

@RecSysChannel
Обзор подготовил Елисей Смирнов

#YaICLR
2 128 просмотров · 19 реакций Открыть в Telegram · Открыть пост на сайте
Завтра — последний день ICLR 2025 в Сингапуре

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

- Подборка статей двух первых дней конференции
- Фоторепортаж для тех, кто хочет проникнуться вайбом ICLR
- Ещё немного фантастических видов Сингапура
- Интересные статьи третьего дня ICLR

Желаем участникам отличного окончания конференции, а всем остальным — полезного чтения!

Больше разборов, интересных постеров, фото и видео с ICLR вы найдёте в наших других каналах: @timeforcv, @MLunderhood, @stuffyNLP, @speechinfo.

@RecSysChannel

#YaICLR
1 700 просмотров · 7 реакций Открыть в Telegram · Открыть пост на сайте
Интересные статьи третьего дня ICLR 2025

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

Language Representations Can be What Recommenders Need: Findings and Potentials

Авторы берут граф взаимодействий пользователей и айтемов, с помощью LLM получают вектора для айтемов и пользователей (усредняя эмбеддинги положительных взаимодействий с айтемами). Затем идут «вглубь» до какого-то момента по графу — и получают итоговые вектора.

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

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

При этом скоры получились подозрительно высокие — возможно, результат слегка завышен.

Ещё автор сказал, что некоторые компании уже видят профит от подхода, но деталей он не раскрыл.

Bridging Jensen Gap for Max-Min Group Fairness Optimization in Recommendation

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

CoS: Enhancing Personalization and Mitigating Bias with Context Steering

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

PersonalLLM: Tailoring LLMs to Individual Preferences

Авторы симулировали пользователей, создавая их предпочтения путём усреднения различных reward-моделей, а затем обучили LLM на этих синтетических данных. Деталей обучения не приводят, но на их бенчмарке модель показывает хорошие результаты. Для новых пользователей ищут похожих на основе language space и строят ответы, опираясь на поведение тех, чьи данные были в обучении.

Beyond Content Relevance: Evaluating Instruction Following in Retrieval Models

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

Рассматривали следующие параметры: пользователь (Audience), поисковые запросы или темы (Keyword), формат отображения (Format), длина ответа (Length), язык (Language), источник информации (Source).

Качество работы моделей оценивали с помощью двух метрик:

- Strict Instruction Compliance Ratio (SICR): бинарная метрика, которая проверяет, что при явном указании условия (например, «документ только на казахском») скор растёт относительно безусловного режима, а при обратном условии («всё кроме казахского») — падает.

- Weighted Instruction Sensitivity Evaluation (WISE): версия метрики, учитывающая изменения позиций в ранжировании.

Лучше всех с задачей справился GPT-4o.

@RecSysChannel

Интересные работы заметили Маргарита Мишустина, Эльдар Ганбаров, Алёна Фомина, Алексей Степанов

#YaICLR
1 418 просмотров · 11 реакций Открыть в Telegram · Открыть пост на сайте
Кадры из самой гущи событий. Можно оценить масштабы главного холла, где выступают с докладами, своими глазами увидеть очередь к хайповому стенду и убедиться: Сингапур хорош как при свете дня, так и под покровом ночи.

@RecSysChannel

#YaICLR
1 395 просмотров · 10 реакций Открыть в Telegram · Открыть пост на сайте
Интересные статьи двух первых дней ICLR 2025

Конференция в разгаре — статей по рекомендательным системам становится всё больше! Делимся избранным и ждём комментариев: какие идеи показались интересными вам.

ContextGNN: Beyond Two-Tower Recommendation Systems
В статье описано, как объединить попарный скор и двухбашенный подход в одной модели, избежав недостатков каждого решения и не делая двухстадийное ранжирование. Для этого используют разные модели для объектов, с которыми пользователь взаимодействовал, и остальных, прогнозируя пожелания пользователя в данный момент.

Preference Diffusion for Recommendation
Авторы из TikTok-ток развивают идеи диффузионных моделей для рекомендаций. Базово решают задачу предсказания следующей покупки или взаимодействия пользователя, пытаясь диффузионками сгенерировать (!) эмбеддинг товара. Недостаток — решение обучается и применяется только на пользователях, сделавших хотя бы 10 покупок, и автор признала, что в проде такое не взлетит.

In Prospect and Retrospect: Reflective Memory Management for Long-term Personalized Dialogue Agents
Статья о персонализации в контексте LLM. Первая идея: точность модели существенно растёт, если использовать весь предыдущий контекст пользователя (диалога). Вторая — в целом, пользовательские фичи можно собирать поумнее: сначала суммиризировать, потом дополнять суммаризацию релевантными топиками из базы, дальше использовать RL-подход для отчистки базы. Это, кстати, применимо не только к ассистенту, но и в целом к другим проектам персонализации или рекомендаций.

SLMRec: Distilling Large Language Models into Small for Sequential Recommendation
Авторы хотят прикрутить LLM к рекомендациям — посмотрели на существующие алгоритмы и задались разумным вопросом: «откуда зафриженные LLM могут узнать об айдшниках в промпте?» и «точно ли все параметры LLM так уж нужны?». В итоге взяли часть слоёв LLM (13% параметров осталось), предложили дистилляцию — то есть дообучают кусок LLM под задачу ранжирования и делают так, чтобы эмбеды совпадали у дистиллируемой части и учителя. Автор говорит, что решение применяется в 6–8 раз быстрее, чем LLM до выкидывания слоёв.

@RecSysChannel

Интересные постеры заметили Василий Астахов, Александр Воронцов, Алёна Фомина и Маргарита Мишустина

#YaICLR
1 792 просмотров · 19 реакций Открыть в Telegram · Открыть пост на сайте
Эти фото сделаны в городе Ессентуки Сингапуре, где завтра начнётся ICLR 2025 — одна из крупнейших конференций в области машинного обучения. ML-инженеры Яндекса уже отправились в центр событий, и скоро канал наполнится новостями с мероприятия!
1 578 просмотров · 36 реакций Открыть в Telegram · Открыть пост на сайте
InterFormer: Towards Effective Heterogeneous Interaction Learning for CTR Prediction

Сегодня разбираем статью InterFormer — новую архитектуру для CTR prediction, в которой особое внимание уделено взаимодействию между разными типами признаков.

Модель создавалась при участии соавторов Wukong, и является её идейным продолжением. В новой статье особое внимание уделяется работе с различными последовательностями, которые можно извлечь из пользовательских логов. Авторы пытаются исправить два недостатка существующих моделей:

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

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

В первую ветку попадают всевозможные категориальные и dense-признаки. Эта ветка отвечает за построение взаимодействий признаков, что можно делать несколькими способами: используя факторизационные машины, DCNv2 или, например, DHEN.

Вторая ветка предназначена для работы с последовательностями. Сначала данные очищаются с помощью MaskNet’а, а затем подаются в классический attention-слой.

Ключевая особенность модели — механизм взаимодействия между этими ветками. Из первой ветки во вторую перед attention-слоем приходит обучаемая проекция на элементы последовательности. В свою очередь, из второй ветки в первую передаётся агрегация последовательности, в которую входят CLS-токен, PMA (Pooling by Multihead Attention), а также фиксированное число последних элементов последовательности. Важно, что взаимодействия между признаками в первой ветке считаются уже с учётом этой агрегации, а для сохранения размерностей используются обычные MLP. С помощью такой организации перекрёстного обмена авторы решают сразу обе указанные ими проблемы.

InterFormer тестируется на трёх публичных датасетах и одном крупном внутреннем. На всех задачах он показывает SOTA-результаты, обгоняя как non-sequential-, так и известные sequential-решения.

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

Также исследуется масштабируемость InterFormer’а по числу и размерам последовательностей и самой модели — авторы утверждают, что модель хорошо скейлится по всем направлениям.

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

@RecSysChannel
Обзор подготовил Олег Сорокин
2 188 просмотров · 19 реакций Открыть в Telegram · Открыть пост на сайте
Что делают в мире: LLM & RecSys. Часть 1/2

Этой весной мы запланировали чаще делиться подборками последних статей в области Information Retrieval. Решили начать с темы влияния LLM на RecSys. В первой части — общий обзор тренда, а во второй — разбор статей по этой теме.

Постановка задач, решаемых LLM и рекомендательными моделями, очень похожа: есть исторический контекст в виде упорядоченной последовательности, по которой мы хотим подобрать наиболее подходящий следующий объект в этой последовательности — семантический токен или айтем-товар. Неудивительно, что если мы посмотрим на SOTA-подходы последних лет, то увидим концептуально схожие мотивы и методы: авторегрессии, господство трансформеров, GPT- и BERT-like архитектуры, RL-методы по типу DPO — всё это и показывает отличные результаты в задачах обработки естественного языка, и с успехом адаптируется в рекомендательных моделях. Передний край исследований «RecSys as is» как раз состоит в том, чтобы повторить успех LLM в скейлинге и качестве.

Однако сами LLM не особо хорошо справляются с рекомендациями «из коробки»: плохо учитывают исторический контекст, могут галлюцинировать. Но в силу обширного знания о мире и прокаченных способностей к рассуждениям внедрение LLM в RecSys-пайплайн кажется заманчивой перспективой. Несколько ярких направлений (но далеко не единственных), в рамках которых можно использовать сильные стороны языковых моделей:

End-to-end LLM-based рекомендации. Концептуально всё просто — конструируем промпт, получаем рекомендацию на выходе. Самое наивное решение — запрос «Посоветуй фантастический фильм». Решение чуть более персонализированное — «Я только что посмотрел всю сагу „Звездные войны“, посоветуй мне фантастический фильм» (и прочие zero-shot- и few-shot-решения). Но если добавить контекста, внести большую историю взаимодействий, затюнить модель на нужный таргет, то уже можно получать хорошие результаты.

LLM для извлечения знания. Большие языковые модели — носители гигантского объёма информации во всём многообразии тем и идей. Из LLM можно брать информативные латентные представления, специфически уточняя их для того или иного таргета.

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

В следующей части — разбираем последние статьи на тему LLM & RecSys.

@RecSysChannel
Обзор подготовил Руслан Кулиев
2 027 просмотров · 22 реакций Открыть в Telegram · Открыть пост на сайте
Wukong: Towards a Scaling Law for Large-Scale Recommendation

Сегодня разбираем не новую, но важную статью на тему scaling law в RecSys. В домене NLP он сводится к идее: чем больше модель, тем выше её качество. Но в современных рекомендательных системах нет такой явной зависимости. Мотивация авторов в том, чтобы создать архитектуру, которая, прежде всего, хорошо масштабируется по параметрам.

Исследователи утверждают, что достигли своих целей:

1) создали архитектуру, которая позволяет улавливать сложные взаимодействия признаков высокого порядка;

2) добились плавного масштабирования качества в зависимости от размера датасета, объёма вычислений (GFLOP) и ограничений по параметрам.

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

Ключевая инновация статьи — использование серии последовательно расположенных факторизационных машин (Factorization Machines, FMB). Это как раз и позволяет учитывать нетривиальные взаимодействия высоких порядков.

Общую схему архитектуры можно описать так: сначала берутся Dense embeddings — это преобразование всех признаков в эмбеддинги. Затем следует блок Interaction Stack, состоящий из нескольких Wukong-слоёв, каждый из которых разделён на два простых блока: Factorization Machine Block и Linear Compress Block.

Interaction Modules Stack состоит из l одинаковых слоёв (interaction layers), причём каждый слой постепенно захватывает всё более высокие порядки взаимодействия признаков. Для слоя i cтека его результаты могут содержать взаимодействия признаков произвольного порядка от 1 до 2i.

Авторы указывают, что чем важнее фича, тем большая размерность эмбеддинга ей выделяется. Затем все эти эмбеддинги объединяют, конкатенируют и через MLP преобразуют в d-dimensional векторы.

На внутреннем датасете исследователей насчитывается около семисот фич, среди которых есть не только категориальные, но и Dense-фичи. Их тоже пропускают через MLP, чтобы привести к одинаковым представлениям. Получив эти эмбеддинги, авторы переходят к следующему слою.

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

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

В финале авторы показывают результаты на шести общедоступных датасетах: по метрике AUC модель почти везде превосходит другие решения. При этом по LogLoss на ряде датасетов (особенно там, где высокая вариативность) Wukong не всегда занимает первое место.

В целом, полученное решение действительно показывает поведение, близкое к scaling law: при увеличении числа параметров и размера датасета качество предсказаний закономерно возрастает.

@RecSysChannel
Разбор подготовил Константин Ширшов
2 004 просмотров · 11 реакций Открыть в Telegram · Открыть пост на сайте
OneRec: Unifying Retrieve and Rank with Generative Recommender and Iterative Preference Alignment

Сегодня разбираем хайповую статью от Kuaishou — второго по популярности сервиса коротких видео в Китае. Авторы утверждают, что создали одностадийную рекомендательную систему OneRec, где генерация кандидатов и их ранжирование объединены в одной модели.

Архитектура модели

— Используют архитектуру «энкодер-декодер»: энкодер обрабатывает историю действий (на вход принимает только позитивные поведения: лайки, подписки, шеры, просмотры), а декодер генерирует всю сессию целиком.
— Вместо предсказания следующего айтема строит всю траекторию пользователя.
— Использует технику Direct Preference Optimization (DPO), причём итеративно — модель оценивает реворд каждой сессии и постепенно его увеличивает.

Энкодер — это обычный трансформер с N слоями. Между сессиями используют специальный токен-сепаратор.

Декодер устроен сложнее: в нём есть каузальный self-attention внутри сессии и cross-attention на энкодер (стандартная схема для декодеров). FFN-слой заменили на смесь экспертов. Это важно, чтобы избежать «узкого горлышка» и дать модели запомнить больше деталей о хороших сессиях. Такой подход увеличивает число параметров, но не требует лишних вычислений: в каждом проходе активируются только 4 эксперта из 24. За счёт этого растёт ёмкость модели без большого увеличения FLOPs. Ещё в декодере есть токены начала и конца сессии, последний предсказывается моделью.

Подробнее об устройстве

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

Подход с прямой генерацией ID уже использовали ранее, например, в работе TIGER. Но там не удалось сделать его end-to-end: модель работала как ретривал, но не заменяла ранжирование — эту стадию пришлось оставить. Авторы Kuaishou утверждают, что решили эту проблему.

Для видео они используют собственный мультимодальный эмбеддинг QARM. Берётся мультимодальная LLM, которая обрабатывает текст, изображения и аудио, её элайнят на рекомендательный сигнал и в конце применяют квантизацию.

С квантизацией есть нюанс. Обычно, как в той же TIGER, применяют RQ-VAE для получения семантических ID и построения семантических токенов. Но авторы пишут, что этот метод работает плохо из-за эффекта «песочных часов»: большинство айтемов мапятся в одни и те же ID, а остальные остаются невостребованными. В результате код-бук используется неэффективно.

Авторы предлагают заменить RQ-VAE на residual K-Means. Сначала вектор кластеризуется на K групп, затем для каждого объекта вычисляют разницу с центроидом его кластера и повторяют кластеризацию для этих разностей. Этот процесс выполняется несколько раз, а в итоге получается код из нескольких ID. Чтобы коды использовались равномерно, делают балансировку — стараются распределять видео по кластерам примерно поровну.

Генерировать хотят не просто сессии, а сессии с высокой ценностью. По критериям Kuaishou, сессия — это последовательность из 5–10 видео. Она считается удачной, если пользователь посмотрел хотя бы 5 роликов, провёл за просмотром больше определённого времени или проявил активность: лайкнул, добавил в коллекцию, поделился. Эти правила позволяют отобрать качественные сессии и использовать их в обучении. В самих сессиях каждый айтем представлен набором семантических ID.

Что в итоге

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

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


@RecSysChannel
Разбор подготовил Виктор Януш
2 466 просмотров · 31 реакций Открыть в Telegram · Открыть пост на сайте
Beyond Item Dissimilarities: Diversifying by Intent in Recommender Systems

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

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

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

Идея в том, чтобы перейти от p(item | user) к p(item | user, intent) = p(item | user) * p(intent | user, item) / p(intent | user). От неё берут матожидание по априорной p(intent | user), получают вероятность того, что айтем подходит юзеру с учётом всех возможных интентов.

Это значение возводится в степень γ (гиперпараметр) и умножается на скор ранжирующей мод ели. Таким образом учитывается как user-item-релевантность, так и intent-aware-релевантность, формируя итоговый скор рекомендации.

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

k+1) Переходя от позиции “k” к “k+1”, считаем, что k-ый айтем не подошёл пользователю. С учётом этого обновляем распределение интентов по теореме Байеса, находя апостериорное распределение. После этого пересчитываем скоры, но теперь матожидаем не по априорному, а по апостериорному распределению.

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

@RecSysChannel
Разбор подготовил Сергей Макеев
2 358 просмотров · 18 реакций Открыть в Telegram · Открыть пост на сайте
FuXi-𝛼: Scaling Recommendation Model with Feature Interaction Enhanced Transformer

Сегодня разбираем статью от Huawei Noah’s Ark Lab об их новой рекомендательной модели FuXi-𝛼.

HSTU — одно из главных достижений индустрии за прошлый год. Среди важных архитектурных решений, которые вошли в эту модель, можно выделить отказ от Feed-Forward Network (FFN) блока и модификацию attention, куда, помимо прочего, добавили дополнительную компоненту для более явного учёта позиционной информации.

Авторы FuXi-𝛼 утверждают, что без FFN-блока очень сложно качественно учитывать неявное (implicit) взаимодействие между признаками. Более того, временную и позиционную информацию они считают настолько важной, что для корректной работы с ними недостаточно простой правки attention.

Основных изменений в модели FuXi-𝛼 два:

1. Модификация HSTU-attention. Его заменили на FuXi-блоки с Adaptive Multi-channel Self-attention (AMS). Они кодируют семантическую информацию о последовательностях стандартным образом, беря за основу HSTU-модификацию attention. А вот позиционная и темпоральная информация в новом блоке обрабатываются отдельно, в специальных обучаемых матрицах. Подробнее о том, как это работает, — на центральной схеме.

2. Возвращение FFN, от которого отказались в HSTU. При этом, добавили гейтинг и residual connections почти в каждый слой архитектуры, чтобы градиенты могли течь по любому маршруту (правая схема).

Для проверки получившейся модели авторы выбрали публичные датасеты MovieLens (1M и 20M), KuaiRand и собственный индустриальный датасет. FuXi-𝛼 показывала лучшие результаты по всем метрикам и хороший скейлинг как на small, так и на large моделях. Например, на KuaiRand NDCG@50 FuXi-𝛼-Large выше HSTU-large на 9%, а HitRate@50 — на 7%. А согласно онлайн-экспериментам в Huawei Music, внедрение FuXi-𝛼 позволило вырастить среднее время прослушивания на 5,1%.

@RecSysChannel
Разбор подготовил Руслан Кулиев
2 716 просмотров · 12 реакций Открыть в Telegram · Открыть пост на сайте
From Features to Transformers: Redefining Ranking for Scalable Impact

Сегодня разбираем статью от Linkedin, в которой Фёдор Борисюк и команда делятся результатами внедрения HSTU-подобной модели. Публикация интересна тем, что объединяет ключевые тренды 2024 года: идею target-aware из HSTU и использование semantic IDs из TIGER.

В работе обозначено несколько целей:

1) Избавиться от большого количества hand-crafted фичей
Авторы хотят показать, что их небольшая модель с базовыми фичами может переиграть сложные подходы и дать высокие результаты в ранжировании.

2) Использовать list-wise подходы вместо point-wise
Исторически ранжирующие модели Linkedin использовали point-wise подход, то есть оценивали каждый айтем независимо от прочих. В статье утверждается, что вероятность клика на конкретный айтем зависит не только от него самого, но и от других совместно показанных айтемов. Из-за этого авторы отказываются от point-wise и переходят на list-wise ранжирование. Ещё эта мера помогла им избавиться от rule-based бизнес-логики в обработке выходов моделей.

3) Scaling law в рекомендациях
Если в NLP и CV scaling law продемонстрирован многократно, то в RecSys — лишь в единицах исследований. Авторы ссылаются на работы, которые показывают, что при правильном увеличении модели можно увидеть scaling law (HSTU, Wukong, HLLM). Им самим удалось добиться этого, используя всего семь ключевых фичей, основанных на разных ID.

Решение, предложенное в статье, — модель под названием LinkedIn Generative Recommender (LiGR), которая собирает воедино перечисленные доработки.

До LiGR LinkedIn использовали в проде для ранжирования две отдельные point-wise модели, которые предсказывали несколько типов взаимодействия: Click Tower — вероятность клика и длительного просмотра поста; Contributions Tower — лайки, комментарии и репосты. Все фичи проходили через fully-connected слои, выдавая на выходе вероятности событий.

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

Вдохновляясь HSTU, авторы используют target-aware постановку (в истории пользователя явно представлены не только айтемы, но соответствующие им действия совершенные пользователем) и gated attention — измененный механизм внимания с использованием гейтинга.

Также авторы предлагают использовать дополнительные attention блоки, работающие только в рамках сессий. Идея, заимствованная из SNG (Session-based Neural Graphs), заключается в том, что внутри одной сессии все айтемы могут учитывать друг друга для уточнения финальных скоров.

Эксперименты и эффекты

Один из главных результатов — исследователям удалось показать, что scaling law действительно работает. Они попробовали масштабировать практически все аспекты: флопсы, размеры эмбеддингов, размеры трансформера. В сравнении с HSTU их подход показал лучшее качество.

Ещё одно наблюдение — простое увеличение длины sequence length при фиксировании других параметров дало ощутимый рост метрик.

Один из самых заметных эффектов от внедрения модели — рост Daily Active Users (DAU) на 0,27%.

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

@RecSysChannel
Разбор подготовил Владимир Байкалов
2 764 просмотров · 30 реакций Открыть в Telegram · Открыть пост на сайте
Какие рексис-тренды будут развивать в Яндексе в 2025 году

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

@RecSysChannel
6 074 просмотров · 25 реакций Открыть в Telegram · Открыть пост на сайте
TWIN V2: Scaling Ultra-Long User Behavior Sequence Modeling for Enhanced CTR Prediction at Kuaishou

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

За последние 3 года у 2% пользователей платформы накопилось от 100 тысяч до миллиона событий в истории. Несмотря на небольшую долю таких пользователей, они генерируют 60% трафика. В целом 95% трафика исходит от пользователей с более чем 10 тысячами событий, поэтому масштабирование моделей под длинные последовательности в Kuaishou критично.

Система обработки пользовательской истории в Kuaishou состоит из двух этапов. General Search Unit (GSU) отбирает наиболее релевантные события из всей истории. Затем Exact Search Unit (ESU) обрабатывает этот отфильтрованный список.

Первая версия TWIN могла работать только с 10 тысячами событий в истории — примерно 3–4 месяца активности пользователей. Этого оказалось недостаточно, и новая версия расширяет этот лимит.

Как происходит обработка истории

При офлайн-обработке размер истории пользователя уменьшают примерно в 10 раз. К каждому событию из истории привязан его Completion Ratio (=playing time / video duration) — на их основе события разбиваются на 5 групп, чтобы в каждой группе у видео были примерно одинаковые значения. Затем группы иерархически кластеризуются методом k-means, пока мощность кластеров не достигнет определенного значения. Кластеризацию делают на основе эмбеддингов от внутренней рексистемы Kuaishou.

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

Между кандидатом и каждым кластером считают нечто похожее на attention, но без софтмакса: просто скалярные произведения, к которым добавляют логарифм размера кластера, чтобы усилить значимость кластеров, более интересных пользователю. Дальше отбирают топ-100 кластеров по полученным скорам, после чего в ESU они проходят через трансформер с обычным attention’ом.

Исследователи проводили эксперименты на собственных логах, сравнивая разные методы отбора наиболее релевантных событий из истории. A/B-тесты показали значимый прирост метрик Watch Time и Diversity.

@RecSysChannel
Разбор подготовил Сергей Макеев
2 088 просмотров · 16 реакций Открыть в Telegram · Открыть пост на сайте
Real-time Indexing for Large-scale Recommendation by Streaming Vector Quantization Retriever

Сегодня разберём статью об обучаемом в реалтайме индексе кандидатов от ByteDance (TikTok).

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

Один из самых популярных подходов — HNSW в связке с Two-Tower-моделью. Однако у него хватает минусов:

— Индекс нужно регулярно перестраивать, что занимает много времени.
— При построении индекса не учитывается таргет.
— Two-Tower хуже моделирует user-item взаимодействия.

Авторы статьи предлагают новый подход к построению индекса — streaming vector quantization, который обеспечивает:

Index Immediacy — быструю адаптацию к действиям пользователей, так как индекс дообучается в реальном времени. Это особенно важно для TikTok.
Index Reparability — устойчивость к деградации. В отличие от HNSW Two-Tower, steaming VQ не перестраивается, поэтому нужно убедиться, что качество индекса не начнёт деградировать со временем.
Index Balancing: отсутствие bias в пользу популярного контента.
Multi-task Learning: при обучении индекса можно одновременно учитывать разные рекомендательные таргеты.

На картинке — схема двух хронологических этапов, из которых состоит streaming VQ:

Retrieval Indexing. С помощью VQ-VAE из всего корпуса документов отбираются несколько тысяч кандидатов, близких к эмбеддингу пользователя.
Retrieval Ranking. Более сложная модель с кросс-аттеншном сортирует результаты предыдущего этапа, отправляя лучшие на финальное ранжирование.

По словам авторов, внедрение streaming VQ в TikTok значительно улучшило ключевые продуктовые метрики, полностью заменив другие подходы к генерации кандидатов.

@RecSysChannel
Разбор подготовил Владислав Тыцкий
2 232 просмотров · 22 реакций Открыть в Telegram · Открыть пост на сайте