Во что мы верим: Scaling Hypothesis (часть 2)
Есть ли области, в которых масштабирование до сих пор не работало? Робототехника одна из них: от автономных машин до гуманойдных роботов. Главная проблема этой области - количество данных. Из всех статей про скейлинг мы видим, что 3 оси должны масштабироваться в линейной пропорции: размер модели, количество данных, количество вычислений. Однако и тут, как только с данными разобрались, всё заработало (GR00T N1: An Open Foundation Model for Generalist Humanoid Robots), куча компаний бросились в гонку роботов (Humanoid Robots at work: where are we ?).

Где-то в русскоязычном телеграм сообществе я видел мнение, что рекомендательные датасеты тоже малы. Может это и справедливо для открытых датасетов, а также для каких-то небольших доменов, однако в корне неверно для крупных систем. Yambda-5b содержит, как следует из названия, миллиарды событий. Наш реальный датасет, на котором обучался Argus - в десятки раз больше. Учитывая, что каждое событие несет в себе намного больше информации, чем один текстовый токен, такого количества данных уж точно должно хватить для обучения энкодера размером в десятки миллиардов параметров (Training Compute-Optimal Large Language Models). Если же вы используете типичную инженерную парадигму в виде feature store над залогированными признаками, ваш датасет скорее всего действительно мал.

В нашей области можно выделить следующие основные оси масштабирования:
1. Размер sparse части (размер матрицы эмбеддингов)
2. Размер энкодера
3. Размерность входа (количество признаков / контекстное окно)
4. Размер датасета
5. Архитектурные усложнения (например раннее связывание)

Про каждую из них мы ещё поговорим отдельно. В этом посте сфокусируемся на размере энкодера.

Почему энкодеры в рекомендациях до сих пор не удавалось масштабировать?
(Understanding Scaling Laws for Recommendation Models, Breaking the Curse of Quality Saturation with User-Centric Ranking)
Я выделяю несколько причин:
1. Большой inductive bias, присущий любым моделям, использующим ручное признаковое пространство
2. Сложно сформулировать простую, масштабируемую задачу обучения (такую как NTP)
3. Ограниченного размера датасеты (если вы используете залогированные ручные признаки)
4. Ограничения на latency и throughput реальных систем, любое улучшение должно себя окупать

Последний год (с момента выхода Actions Speak Louder than Words) учит нас тому, что рекомендации, по всей видимости, не какой-то особый домен, в котором большие модели не работают. Вслед за лидерами побежали все остальные и сейчас довольно много компаний показали scaling laws своих моделей, некоторые уже заявляют, что замасштабировали энкодеры до миллиарда параметров (LinkedIn, ByteDance, KuaiShou, Pinterest, Netflix). Мы тоже рассказали о своих результатах в этом направлении.

Итак вроде проблемы преодолели, модели начали масштабироваться, данных куча. Остаётся небольшой слон в комнате: где же 7b+ рекомендательные модели? Ответ на него мне самому очень интересен и мы активно исследуем эту область, будем делиться результатами. Пока же никто (из того, что я читал или слышал) не показал насыщения за границами 1b.

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

Хотел здесь разобрать свежую статью от Alibaba про скейлинг рекомендательных трансформеров: Scaling Transformers for Discriminative Recommendation via Generative Pretraining, но тут неожиданно Kuaishou дропнули крайне подробный тех. репорт про OneRec, который мы в команде подробно изучали всю неделю.

Kuaishou - очень популярная в Китае платформа коротких видео, главный конкурент Douyin от ByteDance. Помимо просто развлекательной платформы они делают Kling AI - стартап про генерацию видео, собственный E-commerce, а также local life services (в Китае так называют сервисы типа Яндекс Еды, Лавки, аренду самокатов и другой online-to-offline).

Немного цифр для понимания масштаба компании:
- >400 млн DAU
- >700 млн MAU
- 135 млн MAU платящих пользователей e-commerce направления
- 400k RPS в пике

Кроме того, компания очень прокачана в области рекомендательных систем и регулярно рассказывает о своих исследованиях в статьях и на топовых конференциях:
- Reinforcing User Retention in a Billion Scale Short Video Recommender System
- TWIN: TWo-stage Interest Network for Lifelong User Behavior Modeling in CTR Prediction at Kuaishou
- TWIN V2: Scaling Ultra-Long User Behavior Sequence Modeling for Enhanced CTR Prediction at Kuaishou
- KuaiFormer: Transformer-Based Retrieval at Kuaishou

Например лид группы OneRec Guorui Zhou, крайне опытный специалист по рекомендательным системам, раньше работал в Alibaba (Kuaishou входит в их группу компаний) и из-под его пера вышли довольно важные работы, например DIN.

Первый тех. репорт про OneRec вышел ещё в феврале, но там было сильно меньше подробностей и больше вопросов к результатам. В новой же работе очень много деталей и большинство наших сомнений она развеяла. По объему, детализации и формату очень напоминает тех. репорты от DeepSeek (v1, v2, v3, R1).

Самый крутой и важный результат работы: стандартную каскадную рекомендательную систему заменют на одну генеративную нейросеть! Будущее наступает быстрее, чем мы этого ждали 🙂
Ещё один крайне важный результат - утверждается, что операционные расходы на новую систему в 10 раз меньше, чем на старую!

Говорят, что заменили на OneRec 25% трафика своего главного приложения и 100% трафика Local Life Service. В последнем получают какие-то невероятные +17.89% GMV, непонятно, насколько высоким был бейзлайн. В основной же поверхности получили +1.98% Watch Time, +2.43% лайков и +5.27% комментариев. Отличные цифры для настолько развитой платформы (значительно выше, например, чем от внедрения KauiFormer), хоть и внедрение на 25% трафика (и 100% пользователей) немного читерское.

Scaling laws тоже показывают, масштабируя свои модели до 2b (с MoE)! Вот и демонстрация, что на 1b наша область уже точно не остановится. В их случае модель насыщается на датасете, собранном за буквально несколько дней логов (18 млрд сэмплов в день)!

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

OneRec разбор (часть 1): общая архитектура

Общая архитектура модели: генеративный encoder-decoder трансформер. На входе описание пользователя, на выходе semantic ids - специальные рекомендательные токены. Вообще специализированная токенизация - важная часть мультмодальных LLM. В рекомендациях была впервые введена в TIGER. В OneRec реализуется собственная модификация токенизации, о которой поговорим в другой раз.

Encoder-decoder не очень частый выбор для рекомендательных трансформеров. Мы в команде последние несколько лет применяли encoder (bidirectional attention, все входы видят друг друга). Сейчас, с появлением Argus, стали использовать decoder (авторегрессивный, каждый токен видит только своё прошлое). Обычно в рекомендациях используется impression level обучение - количество обучающих сэмплов равно числу запросов за рекомендацией. Подход с каузальной маской позволяет "сжимать" большое число сэмплов в один, уменьшая сложность обучения с O(n^3) до O(n^2), где n - число событий на пользователя (эффект хорошо описан в Actions...).

Выбор архитектуры, похоже, продиктован 2 соображениями: облегчением инференса и несовпадением форматов входа и выхода.

В encoder используется ffw_hidden_dim = 2 * hidden_dim. Такой выбор параметров я встречаю первый раз. В оригинальном Attention Is All You Need использовали 4, сейчас чаще всего встречается 2/3 × 4 (LLaMA: Open and Efficient Foundation Language Models). В 0.9b версии добавляют MoE в decoder, а в 2.6b ещё и в encoder. Концепция MoE, которая уже довольно широко применяется в LLM, мне видится перспективной, будем обязательно пробовать. Наличие MoE у самых больших версий OneRec дополнительно объясняет некоторое затухание scaling law, которое прослеживается на их графиках.

Вход и выход модели значительно отличаются. Если на выходе semantic ids, то на входе события описываются целым набором фич. Мы формируем входы в трансформер похожим способом (Personalized Transformer-based Ranking for e-Commerce at
Yandex). В OneRec сжимают историю через несколько маршрутов: 20 самых свежих соыбтий, 256 позитивных, а также 100000 longterm, которые предварительно кластеризуются в 2000, а затем сжимаются в 128 с помощью QFormer (идея вдохновлена TWIN V2 от тех же Kuaishou).

Оба подхода вносят inductive bias и не очень сильно мне нравятся, в долгосрочной перспективе хочется от них уйти.

Представление событий в виде набора фич делает наш "токен" очень "богатым", а хотелось бы просто разделить задачу на максимально примитивные кусочки и позволить модели "правильно" их скомбинировать: item-action схема из Actions..., context-item-action из Argus и Semantic ids двигают модель именно в таком направлении.

Набор событий в историю позволяет использовать техники сжатия (в авторегрессивном формате применить их не получится), однако возвращает обучение в impression level, значительно замедляя тренировку. Побороть несовпадение входа и выхода можно с помощью каких-нибудь interleaved схем (Sparse Meets Dense: Unified Generative Recommendations with Cascaded Sparse-Dense Representations). Поддержать же длинный контекст в проде тяжело. Не только из-за долгого инференса, но и из-за значительных проблем на уровне хранилища и процессинга.

Интересный факт, который расходится с моей интуицией: авторы утверждают, что события на входе в трансформер можно описывать только с помощью semantic ids, отказавшись от стандартных sparse ids и больших матриц эмбеддингов для документов. У трансформера "память" находится в feed-forward слоях (Transformer Feed-Forward Layers Are Key-Value Memories), которых, как мне казалось, не должно хватать с учётом пока ещё скромных размеров модели. На наших внутренних замерах результат предварительно подтверждается, но будем перепроверять.

OneRec разбор (часть 2): токенизация

Токенизация - небходимый элемент моделей на основе трансформеров. Задача токенизации разбить вход на небольшие кусочки, которые трансформер будет учиться комбинировать. В NLP рецепт уже более-менее общий: разновидности BPE, O(100k) токенов, небольшие отличия в инженерных трюках (как обрабатывать пробелы и пунктуацию, разбивать ли числа на отдельные цифры, какие спец. токены добавить), после обучаемый словарь эмбеддингов ([1], [2], [3]). В vision language models рецепт токенизации пока не устоялся. Изображение обычно разбивается на патчи, которые пропускают через предобученную визуальную модель (An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale). Далее визуальные токены либо квантизуют в дискретное представление, либо подают на вход LLM, пропустив через небольшой адаптер. Основные design choices: какой выбрать визуальный энкодер (архитектура, задача обучения, датасет), как сжать визуальные токены перед входом в LLM (Q-Former, Perciever, Windowed Attention), как (и надо ли) превратить их в дискретные представления. В audio моделях ситуация очень похожая: аудио дорожка нарезается на отрезки, кодируется, выход подаётся как есть, либо дискретизуется (Audio Flamingo 3).

Рекомендательные трансформеры устроены похожим образом. История пользователя естественным способом разбивается на "кусочки" - отдельные события, перед входом в модель они пропускаются через специальны адаптер, обучаемый вместе с трансформером. Энкодеры бывают как предобученные, так обучающиеся совместно с основной моделью. Проблема такого способа токенизации - он не подходит для генерации. В других областях также часто используют токены разных видов для входа и выхода модели. Первыми решение проблемы предложили в Deepmind в статье TIGER. Идея заключается в том, чтобы построить машинно обученное дерево категорий документов. Таким образом каждое событие распадается на несколько токенов, каждый из которых уточняет предыдущий. Идею подглядели в CV.

Некоторые плюсы и минусы semantic ids:
➕Не нужно использовать гигантские эмбеддинг таблицы для item id
➕Токены меньше переобучаются, отсутствует one epoch phenomenon
➕ Используется полный softmax loss, вместо сэмплированной версии
➖ Кодируется только сам документ, контекст игнорируется
➖ Практически вся мемоизация уносится в веса трансформера
➖ Не гарантируется попадание похожих документов в один кластер
➖ Процесс обучения RQ-VAE нестабилен, есть эффект "схлопывания" кластеров

Направление рекомендательной токенизации сейчас активно развивается ([1], [2], [3], [4]). В Kuaishou предлагают свой способ. Его основные идеи:
1. Использовать в качестве семантического энкодера предобученную VLM
2. Сжать выход с помощью QFormer, чтобы уменьшить размерность
3. Дообучить модель на коллаборативно близких парах документов, чтобы уменьшить проблему мемоизации в весах словаря
4. Дополнительно подать выход QFormer в LLaMA 3 и навесить loss на captioning задачу, чтобы модель не разучилась понимать семантический смысл документов
5. На выходах QFormer запусть RQ-Kmeans, вместо изначального RQ-VAE

Большинство идей уже были описаны в их предыдущей статье, однко в OneRec Technical Report рецепт значительно изменили. Что нам нравится и не нравится в их подходе:

➕ Добавлять коллаборативный сигнал в токенизацию точно нужно, причём делать это на уровне контентной модели кажется проще, чем в качестве дополнительного лосса кластеризации (как в LETTER).
➕ RQ-Kmeans выглядит интересно. Кластера в RQ-VAE не сбалансированы (как по количеству, так и по популярности документов), часто становятся пустыми. Kmeans позволяет избежать этих проблем.
➖В целом конструкция получилась довольно громоздкой, с большим количетсвом моделей, хочется попробовать её упростить. Начнём точно с того, что дообучим какую-то модель на коллаборативный сигнал, без использования QFormer и дополнительной LLM после.

Мы сейчас активно экспериментируем с токенизацией. Первые результаты (RQ-VAE над GME-Qwen2VL) получились неплохими, удалось обогнать хэшированные sparse ids. Расскажу об этом в следующих постах.

RecGPT Technical Report
https://arxiv.org/pdf/2507.22879

Ушел в отпуск, не успев закончить разбор OneRec, а тут уже вышел новый большой тех. репорт от Alibaba. Объемные публикации бигтеха меня всегда привлекают - если коммерческая компания, которой надо шипить прод, нашла время написать "большой красивый документ" с длинным списком авторов, значит как минимум гордится своим результатом.

В статье предлагается метод к построению рекомендательной системы на основе LLM.
1. Представить пользователя в виде текстового описания (базовые фичи типа пол / возраст + история действий).
2. С помощью LLM выделить "интересы" пользователя (например "Parenting & Baby Care"), обновлять их с задержкой в сутки.
3. С помощью LLM из "интересов" выделить "тэги" (например "Baby Bath Temperature Sensor").
4. С помощью очень лёгкой 3-tower DNN посчитать релеантность "тэга" товару и товара пользователю. Это единственное место всего пайплайна, в котором используются логи сервиса!
5. С помощью LLM сгенерить объяснение к каждой рекомендации.

LLM здесь не выступает ни как рекомендательный индекс, ни как генератор итоговой выдчи, она лишь суммаризует предпочтения и генерирует объяснения. Дообучение языковых моделей происходит регулярно, но только на LLM as a judge разметку.

Утверждают, что заменили таким подходом старую рекомендательную систему на главной странице Taobao. Приводят впечатляющие результаты АБ теста.

To the best of our knowledge, we are the first to deploy a reasoning-enhanced hundred-billion-scale recommendation foundation model in industrial applications serving over a billion consumers and items

Авторы статьи уже представили аналогичную на KDD'25. В ней репортят выкатку на ту же поверхность, но в качестве дополнительного генератора кандидатов, без отказа от старого стека. Методы в обеих статьях идейно похожи, но детали отличаются значительно.
Один из core contributors RecGPT кстати также является соавтором BERT4Rec.

До сих пор ко всем статьям про LLM как рекомендер я относился с большим скепсисом:
➖ Результаты часто приводятся на открытых данных, без проверки в реальном проде. К академическим датасетам у меня и так мало доверия, а в случае с LLM они ещё и могут протекать в обучение.
➖ Описание пользователей и документов в виде текста выглядит избыточным. Представление пользователя в такой постановке доходит до сотен тысяч токенов.
➖ Языковые модели обладают inductive bias в сторону того, как люди интерпретируют процесс построения рекомендаций, что не обязательно совпадает с настоящими предпочтениями пользователей.
➖ Любые достаточно мощные LLM всё ещё слишком вычислительно тяжелы, чтобы удовлетворять требованиям по задержке, пропускной способности и экномической целесообразности в web-scale продуктах, если речь идёт о применении в реальном времени.

Есть у LLM-based подхода и существенные плюсы:
➕ Интерпретируемый процесс построения рекомендаций позволяет уменьшить feedback loop.
➕ Возможность построить объяснимые рекомендации с персонализированным reason to believe.
➕ Обширные знания о мире усиливают способность модели к генерализации, особенно на холодных документах и тяжёлом хвосте.

Для меня достаточно удивительно, что настолько ручной подход, ещё и с суточными задержками, может побить бейзлайн важной поверхности бигтех компании. В целом Alibaba делает шаг в сторону от end2end системы, к которой мы стремимся. Верю, что рекомендации рано или поздно должны стать ещё одной модальностью универсальной модели (ради чего, вроде как, semantic ids и затевались), но до сих пор не видно примеров успешной реализации этой идеи, а RecGPT нас к этому будущему, к сожалению, не приближает.

Data Dojo

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

Кроме меня выступит Лёша Колесов, руководитель команды LLM, с рассказом про последние достижения и ближайшие планы.

А ещё там будет большой блок под нетворкинг, на котором и меня и Лёшу можно будет поймать и допросить 🙂

Регистрация открыта до 20 августа, так что не пропустите!

OneRec разбор (часть 3): алайнмент

Прямо как по заказу к моменту, когда руки дошли написать пост про алайнмент в OneRec, вышла ещё одна статья от тех же авторов: OneLoc. В ней описывается в целом всё тот же OneRec (хотя в деталях различий немало), но применённый к поверхности Local Life Service. В OneRec Technical Report упоминалась выкатка на эту поверхность с точно такими же результатами AB-теста, так что это на самом деле один и тот же релиз. Разберём сегодня на примере всех 3 работ (OneLoc, OneRec и OneRec Technical Report) моё видение алайнмента генеративных рекомендательных моделей.

Я выделю следующие возможные подходы:
- Next token / item prediction (то есть отсутствие алайнмента)
- Supervised Fine-Tuning (SFT)
- Conditioning (например Prompt-based или P-tuning)
- Псевдо RL (например DPO)
- RL (например PPO и GRPO)

NTP
LLM обучается предсказывать следующий токен в последовательностях текстов (NTP), в результате чего выучивают "модель мира" (а точнее модель того, как люди пишут тексты). Мы в рекомендациях адаптируем эту идею, реализуя next item prediction. При этом практически все рекомендательные модели либо получают на вход только позитивные взаимодейтсвия (как SASRec или TIGER), либо на вход получают всё, а предсказывают только позитивы (как PinnerFormer или Actions...). Такие модели не выучивают логгирующую политику, их модель мира упрощённая. В Technical Report модель предобучают на exposed items, их базовая модель предобучена именно на NTP.

SFT
Часть цепочек можно назвать "хорошими" и научить модель такие цепочки генерировать. В LLM такие цепочки можно составлять с помощью разметчиков. В рекомендациях обычно используют логи прошлой системы и фидбэк пользователей. Pretrain первой версии OneRec это именно SFT - NTP loss там повесили только на high-quality sessions. Также в обеих версиях статьи используют SFT как дополнительный лосс на этапе алайнмента.

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

Псевдо RL и RL
Эта группа методов позволяет напрямую оптимизировать выдачи, которые понравятся пользователям, а не иммитировать подмножество хороших выдач прошлой системы. Большая проблема рекомендаций - вы не можете показать 2 разные выдачи одному и тому же пользователю в один момент времени и узнать его реакцию на обе. Это приводит к необходимости обучения reward model. По аналогии с LLM такая модель оценивает, насколько хорошо ответ подойдёт на запрос. Имея reward model, можно сэмплировать различные выдачи для пользователя и либо составлять из них пары для DPO, либо оценивать value для RL алгоритмов.

Логичный вопрос: раз уж у нас есть reward model, зачем нам DPO? Я вижу 2 главных причины: он стабильнее и менее требовательный к "онлайновости" обучения. Основные RL алгоритмы, применяющиеся в генеративных моделях, учатся on-policy (то есть на своём собственном фидбэке). При обучении на логах другой системы приходтся вносить корректировки, которые всё равно работают плохо. В идеале модель должна обновлять веса сразу после получения фидбэка. На практике это недостижимо, поэтому чем "онлайновее" обучение, тем лучше.

Похоже, что 3 внедрения появлялись именно в таком порядке по мере усложнения инфраструктуры:
- OneLoc использует обычный DPO, обучаясь offline.
- OneRec использует Iterative DPO - модель чаще обновляет веса во время дообучения.
- OneRec Technical Report использует свою модификацию GRPO, обучаясь с минутными задержками.

OneRec-V2 Technical Report
https://arxiv.org/pdf/2508.20900

Парни публикую техрепорты быстрее, чем я успеваю писать на них разборы 🗿

- Обновленная архитектура: 8b (!) dense decoder-only (но в прод снова выкатывают 1b)
- Обновленная процедура алайнмента
- Прирост поверх v1 сопоставим с приростом v1 относительно каскадной системы
- Профит от скейлинга на 4b -> 8b уже не особо уменьшает претрейновый лосс

Про нестабильности в обучении
(мемчик из внутреннего чата от Влада Тыцкого)

Недавно мы взялись написть архетип - библиотечный класс нашей генеративной модели. После лёгкого рефакторинга обучение начало "взрываться" (кто бы мог подумать).

Что мы обычно используем для стабилизации:
- Gradient clipping
- Лоссы и нелинейности - в fp32
- Learning rate warmup и аккуратный подбор пикового значения
- Pre-norm
- QK-нормализацию

До сих пор не используем, но в LLM применяют:
- AdamW
- Очистку датасета от "плохих" батчей
- Отключение bias
- RMSNorm вместо LayerNorm

Конкретно в этом случае не спасало вообще ничего. Локализовать проблему помогло только отслеживание std (!) активаций на разных слоях.

Дебаг занял недели, а фикс ровно 1 строку кода.

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

Обязательно подпишитесь на Рекомендательную: там публикуются разборы актуальных статей, и очень часто их делают ребята из нашей команды.

Генеративные рекомендации III. Хайп и хаос

Меняя компанию, я успела походить по собесам в области RecSys DL, и в одной из секций всегда всплывали генеративные рекомендации. Тема сейчас настолько хайповая, что в терминологии полный хаос, который идёт к нам ещё из научных статей. Пара примеров понимания "генеративных рекомендаций" из статей 23-25 годов:

“The first generative recommendation system in the literature” – хочет назвать известная компания свою же прошлую архитектуру из “Actions…” (ICML'24). Сподвигает их к этому предложение "Generative Recommender", но их парадигма по сути только заменяет концепцию обучения с impression-based на авторегрессивную, не меняя ни задачи модели, ни способ инференса.

"In the paradigm of generative recommendation, the primary objective is to predict the next item a user is likely to interact with" - хочет написать Huawei в препринте этого года. И приписывает таким образом пальму первенства генеративных рекомендаций ванильному SASRec из 2019 года (а то и BERT4Rec из 2018). Мотивация Huawei понятна: они обновляют архитектуру трансформера для простой Shifted Sequence модели (как это делают FuX-α, HSTU, eSASRec и пр.), не меняя концепцию обучения или задачи инференса. Но подчеркнуть актуальность статьи нужно, “Generative” в название статьи добавить хочется, и потому возникает такой вот финт, причём применяется он сейчас в статьях часто. Под "Generative" в заголовке статьи 2024-25 года часто будет скрываться именно авторегрессивная постановка обучения, без концептуальных нововведений на уровне моделирования. Разве что каузальная маска внимания может быть чуть видоизменена под конкретную задачу, как в "Generative Rankers" из моего прошлого поста.

“We propose a generative Next-K strategy, where recommendations are generated item-by-item” – пишет Саша Петров с соавтором в "Generative Sequential Recommendation..." (SIGIR’23). Тут реализуется простая идея: айтем, сгенерированный авторегрессивной моделью, можно подставить в последовательность и продолжить генерировать рекомендации дальше. Помимо жадной генерации есть и другие стратегии. Интуитивно очень понятный подход, и тут он «генеративный» уже в прямом смысле слова, без оговорок. Но хайпует сейчас другое.

“We propose a new paradigm ... Instead of traditional query-candidate matching approaches, our method uses an end-to-end generative model that predicts the candidate IDs directly.” – пишет Google в статье про TIGER (NeurIPS’23). TIGER использует полноценную энкодер-декодер архитектуру и обучается генерировать один следующий айтем (состоящий из набора иерархических semantic ids) для пользователя с заданной историей (в которой также каждый айтем представлен как набор semantic ids). Результаты на публичных датасетах у этой модели легко бьются простым SASRec с gBCE или SS лоссом, но важно далеко не это. Открывается целое направление в RecSys ресёрче:

“We propose OneRec, which replaces the cascaded learning framework with a unified generative model. This is the first end-to-end generative model” - пишут KuaiShou в препринте OneRec (2025). В данном случае одна модель заменяет собой все стадии индустриальных рекомендательных пайплайнов от кандидато-генерации до ранжирования. Прямая генерация айтемов по семантическим айди повторяет идею TIGER, так что в первом приближении модель относится к кандидато-генерации ("Generative Retrieval"). Но использование RL подходов в серии статей “One…” от KuaiShou
позволяет моделям дообучаться на максимизацию приносимого ими профита. По сути, это инкорпорация сразу и ранжирующего сигнала (конверсии в целевые действия - на которые учатся ранжирующие модели), и даже более общего экономического сигнала сразу в единую модель. Что в идеальном мире позволяет ей быть end-to-end генеративным рекомендательным движком, затюненным на полезность в сервисе. Так что законно задаёмся вопросом – не это ли RecSys будущего?

Про серию “One…” можно почитать хардовые разборы у Коли Савушкина из Яндекса и поучаствовать в ближайших ридинг группах VK.

Подпишитесь на канал Даши Тихонович, если интересно читать про актуальные рекомендательные технологии.

А ещё прочитайте eSASRec, где Даша - первый автор. Достойная работа, которая принята на RecSys ’25!

Oral от Саши на RecSys 🔥

PML

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

Оффлайн билетов уже нет, но можно посмотреть трансляцию:
https://pmlconf.yandex.ru/2025/

Презентация с сегодняшнего выступления

Всем спасибо, кто дошел, было приятно видеть полный зал!

Yandex Cup

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

Если интересно попробовать свои силы, еще остается несколько дней на регистрацию:
https://yandex.ru/cup

CIKM'25

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

В программе этого года самые интересные (на мой взгляд) работы от Pinterest (TransAct V2 и PinRec), несколько работ от команды OneRec из Kuaishou (например QARM про способ токенизации и Pantheon, который они используют в качестве reward модели), а также end2end генеративная рекламная система от Meituan (самой большой доставки еды в мире).

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