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
Разбор подготовил ❣ Илья Мурзин

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

Завершаем разбор статьи MiniOneRec. В первой части обсуждали SFT и семантические ID, а теперь посмотрим, что происходит дальше: RL-дообучение, генерация траекторий и насколько авторы смогли воспроизвести индустриальные результаты на открытых данных.

RL-дообучение: GRPO и генерация траекторий

После SFT и алайнмента применяется reinforcement learning по аналогии с OneRec — используется GRPO. Модель уже умеет генерировать последовательности семантических токенов, каждая из которых соответствует айтему. Генерируются несколько траекторий (beam search или dynamic sampling), затем по каждой считается награда. Награда включает два компонента: корректность следующего айтема и ранжирование согласно frozen collaborative модели (SASRec в реализации авторов).

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

GRPO здесь в «ванильной» версии: есть ограничение на отклонение от начальной политики, чтобы избежать reward hacking — классического случая, когда модель накручивает награду, но начинает генерировать бесполезные последовательности.

Результаты и масштабирование

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

В целом, MiniOneRec повторяет ключевые идеи OneRec — но делает это на открытых данных, с полностью доступным кодом и понятными экспериментами. Авторы аккуратно воспроизводят семантическую токенизацию Tiger, SFT поверх LLM, алайнмент между NLP и рекомендациями и RL-дообучение через GRPO. Это первая попытка показать, что индустриальные результаты действительно можно повторить за пределами приватных данных.

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

LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders

Сегодня разбираем статью от ByteDance, представленную на RecSys'25. Работа посвящена эффективным end-to-end-рекомендациям на GPU с использованием длинных пользовательских последовательностей (до 10 тыс. событий). Авторы рассматривают кейсы Douyin (китайского TikTok) — как в рекламе, так и в e-commerce.

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

1) Token Merging. Рядом стоящие токены в истории группируются по K штук. Группировка выполняется либо простой конкатенацией, либо через лёгкий внутренний трансформер (InnerTrans). Это уменьшает эффективную длину последовательности с L до L/K. Для типичных настроек (L=2000, d=32) TokenMerge(K=4) снижает FLOPs аттеншна примерно на 40–50% при минимальной потере качества.

Авторы аккуратно разбирают TokenMerge и InnerTrans в ablation study:
— без Merge (L=2000): FLOPs ≈ 3,73e9;
— c Merge (K=8, concat, L=250): FLOPs ≈ 3,03e9, ΔAUC +1,58%, ΔLogLoss −3,48%;
— добавление InnerTrans даёт ещё небольшой, но устойчивый буст.

Таким образом, TokenMerge не только снижает вычислительные затраты, но и даёт буст по метрикам качества, в сравнении с ванильным вариантом.

2) Global Tokens. На вход подаётся конкатенация глобальных токенов и пользовательской истории. Глобальные токены играют роль «якорей» (User Profiles, Context & Cross Features).

3) Тонкости обучения. Dense- и sparse-параметры (огромные embedding-таблицы) находятся на GPU-кластере. Обучение в BF16/FP16, часть активаций не хранится, а пересчитывается на backward. На инференсе используется KV Cache Serving.

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

В офлайне LONGER решает задачу предсказания conversion rate (CVR) на 5,2 млрд примеров (130 дней данных Douyin Ads) на кластере 48 × A100. По сравнению с базовым Transformer даёт +0,21% AUC и −0,39% LogLoss.

Онлайн A/B-тесты в Douyin Ads:
— Live Streaming: ADSS +1,06%, ADVV +1,17%
— Short Video: ADSS +2,10%, ADVV +2,15%
— Mall: ADSS +1,82%, ADVV +1,41%

Онлайн A/B-тесты в Douyin E-commerce:
— Live Streaming: Order/U +7,92%, GMV/U +6654%
— Short Video: Order/U +4,61%, GMV/U +5,28%

@RecSysChannel
Разбор подготовил ❣ Михаил Сёмин

GenSAR: Unified Generative Search and Recommendation

Сегодня разбираем статью от исследователей из Renmin University of China и Kuaishou Technology, представленную на RecSys'25. Работа посвящена объединённому моделированию поиска и рекомендаций с использованием генеративного подхода на основе больших языковых моделей.

Современные коммерческие платформы (e-commerce, видео, музыка) предлагают одновременно и поиск, и рекомендации. Совместное моделирование этих задач выглядит перспективно, однако авторы выявили ключевой trade-off: улучшение одной задачи часто приводит к деградации другой.

Причина кроется в различных информационных требованиях:

— Поиск фокусируется на семантической релевантности между запросами и айтемами — традиционные варианты поиска часто основаны на предобученных языковых моделях (BGE, BERT);
— Рекомендации сильно зависят от коллаборативных сигналов между пользователями и айтемами — ID-based-рекомендации дают отличные результаты.

GenSAR — унифицированный генеративный фреймворк для сбалансированного поиска и рекомендаций.

Для каждого айтема берутся два эмбеддинга: семантический (из текста) и коллаборативный (из user-item-взаимодействий). Оба прогоняются через отдельные MLP-энкодеры и приводятся к одной размерности, затем конкатенируются в общий вектор.

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

Далее остаточный вектор делится пополам. Одна половина подаётся в семантические кодбуки, другая — в коллаборативные. В итоге:

— Semantic ID (SID) = shared codes + semantic-specific codes;
— Collaborative ID (CID) = shared codes + collaborative-specific codes.

Лосс состоит из суммы:
1) Reconstruction loss: декодеры должны восстановить исходные эмбеддинги по кодам.
2) Loss for residual quantization: считается для трёх наборов кодбуков (shared, semantic, collaborative) и включает codebook loss + commitment loss для каждого.

Выход модели зависит от задачи:
- Рекомендации → CID (коллаборативный сигнал важнее);
- Поиск → SID (семантика важнее);
Модель различает задачи через task-specific-промпты. Обучение — joint training на смешанных батчах с балансировкой лоссов между задачами.

Оффлайн-эксперименты проводились на публичном датасете Amazon и коммерческом датасете Kuaishou. Сравнение с бейзлайнами: SASRec, TIGER (рекомендации), DPR, DSI (поиск), JSR и UniSAR (совместные модели).

На Amazon GenSAR показывает +12,9% по Recall@10 для рекомендаций и +12,8% для поиска относительно лучшего бейзлайна UniSAR. На коммерческом датасете Kuaishou прирост составляет +10,4% и +11,7% соответственно.

Ablation study подтверждает важность обоих компонентов:
— Без CID качество рекомендаций падает на 8,9%;
— Без SID качество поиска падает на 14,7%;
— Dual-ID подход даёт +12,7% к рекомендациям по сравнению с single-ID.

@RecSysChannel
Разбор подготовили ❣ Михаил Сёмин и Никита Мирошниченко