TBGRecall: A Generative Retrieval Model for E-commerce Recommendation Scenarios

Разбираем работу Alibaba, архитектурно напоминающую ARGUS, используемый в Рекламе Яндекса. Модель TBG Recall, описанная в статье, генерирует кандидатов для главной страницы Taobao, крупнейшего e-commerce-сервиса компании.

Во многих работах для рекомендаций применяются генеративные и последовательные модели, но они предполагают, что история пользователя — это строгая последовательность событий. В e-commerce всё иначе: пользователь делает запрос и получает «пачку» товаров, потом ещё одну — внутри таких пачек никакой упорядоченности нет, поэтому обычные sequence-based-подходы здесь работают не совсем корректно.

В качестве решения авторы вводят предсказание следующей сессии, где сессия понимается как один запрос пользователя. Модель учится предсказывать, какие товары пользователь увидит в следующей выдаче.Также в работе используют incremental training, чтобы регулярно обновлять модель на свежих данных без перерасхода GPU.

Архитектура

Как уже сказали, в основе TBGRecall — next session prediction: история пользователя кодируется в вектор и сравнивается с векторами кандидатов через ANN-индекс, как в классических двухбашенных моделях. Слово «генеративная» в названии относится не к инференсу, а к способу обучения — авторегрессионному.

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

Кодирование и обучение

Каждое событие описывается набором признаков: Item ID, Action, SideInfo (ID продавца или категория), Context и Timestamp. Вход модели — сумма этих векторов. Сначала они проходят через tower-модули, а затем через HSTU-блоки. Для контекстных и айтемных токенов используются отдельные tower-модули — небольшие проекции, без которых качество падает (что совпадает с нашим опытом в ARGUS).

Основная схема обучения — session-wise autoregressive approach с маской внимания, которая не позволяет айтемам внутри одной сессии «видеть» друг друга. Также применяется session-wise ROPE (sw-ROPE) — позиционные эмбеддинги, нумерующие сессии. Мы пока не видели стабильного выигрыша от подобных схем, но идея любопытная.

Лосс состоит из трёх частей:
1. Lnce — воспроизводит логирующую политику, учит отличать реальные айтемы в сессии от случайных негативов.
2. Lclick — отличает кликнутые айтемы от показанных.
3. Lpay — отличает купленные от всех прочих.

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

Инференс и результаты

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

На закрытом датасете (около 2 трлн записей) TBGRecall превзошёл собственный dual-tower baseline компании. В A/B-тестах модель показала +0,5% по числу транзакций и +2% по обороту. Новый кандидат-генератор теперь отвечает за 24% показов на поверхности Guess You Like — одной из ключевых страниц Taobao.

В целом, TBGRecall — это шаг от классической двухбашенной архитектуры к генеративному обучению. Контекстные токены дают сильный прирост, MoE и SW-ROPE работают стабильно, а near-line-инференс показывает себя лучше, чем ожидалось.

@RecSysChannel
Разбор подготовил ❣ Николай Савушкин

PLUM: Adapting Pre-trained Language Models for Industrial-scale Generative Recommendations

Сегодня разбираем совместную статью Google DeepMind и YouTube. Об этой работе было известно заранее — на конференции RecSys авторы проекта, включая Ed Chi и Lichan Hong, упоминали, что готовится статья о генеративных рекомендациях. Через пару недель после конференции она действительно вышла.

Исследование продолжает трек генеративных рекомендаций, заданный предыдущей работой авторов TIGER. На этот раз основная идея — использование предобученных больших языковых моделей в рекомендательных пайплайнах (в случае Google — это Gemini). Простая LLM из коробки не подходит: модель не знает ни о корпусе айтемов, ни о пользовательских поведенческих сценариях, что приводит к плохим результатам. Чтобы исправить это, команда предлагает фреймворк PLUM, включающий три стадии: item tokenization, continued pre-training и task-specific fine-tuning. Кратко разберём каждую из них.

1) Item tokenization. За основу взята работа TIGER. В ней семантические идентификаторы (SIDs) формировались через RQ-VAE поверх текстового описания товара (эксперименты были на открытых датасетах Amazon). В PLUM к этому подходу добавляют коллаборативный сигнал и мультимодальные контентные представления. Используются уже готовые аудио-, видео- и текстовые эмбеддинги YouTube, которые конкатенируются и проходят через энкодер RQ-VAE.

Новые предложенные компоненты:

— Multi-Resolution Codebooks: число идентификаторов в кодбуках уменьшается от слоя к слою, чтобы верхние уровни разделяли крупные семантические категории, а нижние — более гранулярные признаки.
— Progressive Masking: модель обучается восстанавливать не полный набор SIDs, а его префикс.

Ключевая вещь в архитектуре — дополнительный contrastive learning на RQ-VAE, который вводит коллаборативный сигнал прямо в процесс токенизации. Берутся пары айтемов, встречавшихся рядом в пользовательской истории как позитивные пары, обучается с помощью InfoNCE по батчу. Так коллаборативный сигнал тоже участвует в формировании кодбуков без отдельной стадии дообучения как, например, в OneRec. В итоге SIDs начинают отражать не только контентную информацию об айтемах, но и коллаборативные пользовательские связи между ними.

2) Continued Pre-Training (CPT). Здесь языковая модель дообучается с увеличенным словарём, в который, помимо изначальных токенов, встроены токены айтемов. Модель обучается на смешанной задаче (supervised + self-supervised). Цель этой стадии — заставить LLM встроить в общее семантическое пространство представления токенов и SIDs.

3) Task-Specific Fine-Tuning. Это полноценное обучение на задачу генеративного ретривала: модель предсказывает релевантные айтемы в пользовательских историях (обучение на next token prediction).

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

Эксперименты и результаты

Основная модель — Mixture-of-Experts с ~900 млн активных параметров (всего 4,2 млрд).

В онлайн-A/B-тестах PLUM показывает рост ключевых метрик: CTR и вовлечённости пользователей, особенно в коротких видео (YouTube Shorts). Аблейшены подтверждают, что важны все предложенные компоненты.

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

Финальная PLUM-модель дообучается ежедневно на ~0,25 млрд примеров, тогда как предыдущие LEM (Large Embedding Models) подходы требовали многомиллиардных датасетов.

@RecSysChannel
Разбор подготовил ❣ Владимир Байкалов

Balancing Fine-tuning and RAG: A Hybrid Strategy for Dynamic LLM Recommendation Updates

Сегодня разберём статью от компании Google DeepMind, главный фокус которой в последнее время — LLM в рекомендациях. У рекомендательных моделей есть ряд преимуществ относительно более традиционных рексистем: богатое понимание мира, ризонинг, способность объяснять, почему был порекомендован тот или иной объект, и многое другое. Но это не отменяет слабые места, например, проблему динамики в интересах пользователей и корпусе айтемов. Именно этот аспект авторы разбирают в статье.

Эксперименты проводятся в YouTube Shorts. Авторы выясняют: нужно ли вообще обновлять рекомендательную LLM в таком домене, или со своим знанием мира она и так справится. Отвечают интересным экспериментом: кластеризуют тематики шортсов и по логам пользователей собирают тройки (c1, c2, c_next) кластеров, с которыми кто-то последовательно провзаимодействовал. Делают так отдельно для нескольких месяцев, после чего для всех пар (c1, c2) собирают топ-5 переходов в c_next для каждого месяца i: {c_next_1, …, c_next_5}_i. Далее для пар (c1, c2) считают IoU множеств переходов за соседние месяцы (i vs. i+1) и получают низкое значение 0,17, что подчеркивает высокую изменчивость паттернов пользователей во времени. Отсюда возникает необходимость постоянного обновления рекомендательной LLM.

В статье сравниваются два метода: fine-tuning и RAG. Первый обновляет веса модели через дообучение на новом трафике. Второй, грубо говоря, усиливает промпт недостающей информацией о пользователе и домене, при этом никак не влияет на саму модель.

Fine-tuning. Модель дообучается предсказывать следующий кластер, с которым провзаимодействовало большинство пользователей: (c_1, c_2, …, c_n) → c_{n+1}. Описания кластеров поступают в LLM в словесной форме. Из минусов метода — сложность, возможность переобучения и высокие вычислительные затраты. Из-за последнего дообучение происходит лишь ежемесячно.

RAG. Точно так же представляет историю в виде последних взаимодействий с кластерами (обновленные интересы пользователя), но ещё и добавляет в промпт наиболее популярное продолжение для этой последовательности взаимодействий (обновленные реалии домена). Поскольку множество всевозможных историй вида (c_1, c_2, …, c_k) невелико и конечно, инференс производится несколько раз в неделю, а предпосчитанные кандидаты для каждой истории достаются в реальном времени лукапом.

В офлайн-эксперименте проверяют, нужен ли RAG и стоит ли пересчитывать кандидатов раз в несколько дней. Оказывается, что на оба вопроса ответ положительный. В A/B-тесте отчитываются о приростах Satisfied User Outcomes, Satisfaction Rate и об уменьшении Dissatisfaction Rate и Negative Interaction.

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

OneTrans: Unified Feature Interaction and Sequence Modeling with One Transformer in Industrial Recommender

Сегодня разберём статью о OneTrans — нейросетевом ранкере от TikTok. Его можно было бы назвать аналогом HSTU от Meta* или TransAct от Pinterest, но ни на одну из этих работ авторы не ссылаются, упоминают только Wukong и RankMixer.

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

Классический подход к финальному ранжированию, ставший стандартом индустрии, обычно предполагает, что историю пользователя обрабатывают отдельно от обработки ручных счётчиков. Сначала входную последовательность событий пропускают через Sequence Modeling Block, где вытаскивают и сжимают информацию о пользователе, необходимую для построения рекомендаций. Потом сжатое представление попадает в Interaction-блок. Параллельно набор Non-Seq-фичей (например, ручные счëтчики) конкатенируют или каким-то другим способом подают в тот же Interaction-блок.

OneTrans одновременно моделирует и последовательные, и Non-Seq-входы внутри единой модели OneTrans. Архитектура ранкера — на схеме: последовательности (голубые блоки S на схеме) и non-seq (NS, оранжевые) айтемы токенизируют по отдельности. Блоки поведения пользователей разделяют специальными блоками [SEP], после чего единую последовательность подают на вход OneTrans Pyramid Stack. Внутри этой пирамиды последовательность S итеративно сжимают до тех пор, пока её длина не совпадёт с NS.

OneTrans Block — казуальный трансформер с RMSNorm, Mixed Causal Attention и Mixed FFN. Под Mixed авторы понимают смешанную параметризацию: у S-токенов общие QKV/FFN-матрицы, а каждый NS получает свои токен-специфичные веса.

По результатам экспериментов на индустриальных датасетах, OneTrans эффективно масштабируется с ростом параметров: систематиически обгоняет сильные бейзлайны и показывает рост на 5,68% per-user GMV в онлайн-A/B-тестах.

*Компания Meta, владеющая Instagram, признана экстремистской; её деятельность в России запрещена.

@RecSysChannel
Разбор подготовил ❣ Артём Матвеев

MiniOneRec: An Open-Source Framework for Scaling Generative Recommendation [1/2]

Сегодня начинаем разбирать неожиданно вышедшую статью MiniOneRec. В ней использованы подходы из нашумевшей серии техрепортов OneRec от Kuaishou. Авторы MiniOneRec — исследователи из университетов Китая и Сингапура — фактически берут ключевые идеи OneRec, переносят их в минимально жизнеспособный фреймворк и подтверждают, что они действительно работают на открытых данных. Это выглядит как попытка «повторить OneRec», но в академии и без доступа к приватным датасетам. И действительно, LLM-подходы в NLP работают слишком хорошо, чтобы не пытаться перенести их в другие домены — в том числе в рекомендации.

Семантические ID и подготовка данных

Первое препятствие, которое сразу появляется в рекомендациях, — огромный каталог документов. Нельзя просто взять LLM и обучить её поверх ID в десятки или сотни миллионов: embedding/de-embedding-слои и softmax станут непригодными. Поэтому MiniOneRec, как и OneRec, используют семантические ID из работы TIGER.

Суть простая: каждый документ кодируется короткой последовательностью токенов. Из исходного текста (название + описание) получают эмбеддинг: текст прогоняется через замороженную Qwen3-Embedding-4B, затем hidden states последнего слоя усредняются (mean pooling) в один вектор, который и подаётся в трёхуровневую RQ-VAE-кластеризацию. На каждом уровне отнимается ближайший из 256 центроид (получается semantic_id_0), формируется остаток, который проходит ту же процедуру кластеризации следующего уровня — в итоге документ получает трёхтокенную семантическую подпись. Это резко уменьшает словарь: вместо миллионов ID становится 3x256 дополнительных к словарю токенов. У Tiger и OneRec эта идея ключевая, и MiniOneRec полностью повторяет её.

Авторы также отмечают проблему коллапса кластеров (слишком много документов в одном кластере), поэтому в коде используют не случайную инициализацию, а RQ k-means из оригинального OneRec. Это увеличивает энтропию кластеров и улучшает токенизацию.

SFT и перенос NLP в рекомендации

После токенизации авторы делают SFT поверх предобученной LLM (берут Qwen). В случае с академией это более чем оправдано: экономятся ресурсы, не нужно тренировать архитектуру с нуля и сразу есть сильный старт. Истории пользователя подаются в виде последовательностей семантических токенов, а модель учится предсказывать следующий айтем.

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

Получается несколько типов задач:

- история на естественном языке — нужно предсказать следующий айтем в виде семантических токенов;

- история в виде семантических токенов — нужно предсказать текстовое описание следующего айтема;

- просто перевод айтема между двумя представлениями — из текста в семантические токены и наоборот.

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

В следующей части обзора расскажем о RL-дообучении, масштабировании и результатах.

@RecSysChannel
Разбор подготовил ❣ Илья Мурзин