Огромная благодарность всем авторам (и особенно Саше) за их вклад 🙏
https://arxiv.org/abs/2505.22238v2
https://arxiv.org/abs/2505.22238v2
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥51🥰5
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. Расскажу об этом в следующих постах.
Токенизация - небходимый элемент моделей на основе трансформеров. Задача токенизации разбить вход на небольшие кусочки, которые трансформер будет учиться комбинировать. В 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. Расскажу об этом в следующих постах.
👍10🔥7
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. Приводят впечатляющие результаты АБ теста.
Авторы статьи уже представили аналогичную на 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 нас к этому будущему, к сожалению, не приближает.
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 нас к этому будущему, к сожалению, не приближает.
🔥19👍9❤1
Data Dojo
26 августа выступлю в Питере на Data Dojo с рассказом про актуальные технологии в рекомендательных системах. Для подписчиков этого канала информация будет скорее не новая, но может дать какую-то суммаризацию и новый взгляд на уже знакомые вещи.
Кроме меня выступит Лёша Колесов, руководитель команды LLM, с рассказом про последние достижения и ближайшие планы.
А ещё там будет большой блок под нетворкинг, на котором и меня и Лёшу можно будет поймать и допросить 🙂
Регистрация открыта до 20 августа, так что не пропустите!
26 августа выступлю в Питере на Data Dojo с рассказом про актуальные технологии в рекомендательных системах. Для подписчиков этого канала информация будет скорее не новая, но может дать какую-то суммаризацию и новый взгляд на уже знакомые вещи.
Кроме меня выступит Лёша Колесов, руководитель команды LLM, с рассказом про последние достижения и ближайшие планы.
А ещё там будет большой блок под нетворкинг, на котором и меня и Лёшу можно будет поймать и допросить 🙂
Регистрация открыта до 20 августа, так что не пропустите!
🔥22
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, вышла ещё одна статья от тех же авторов: 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, обучаясь с минутными задержками.
👍15🔥7❤1😁1
OneRec-V2 Technical Report
https://arxiv.org/pdf/2508.20900
Парни публикую техрепорты быстрее, чем я успеваю писать на них разборы 🗿
- Обновленная архитектура: 8b (!) dense decoder-only (но в прод снова выкатывают 1b)
- Обновленная процедура алайнмента
- Прирост поверх v1 сопоставим с приростом v1 относительно каскадной системы
- Профит от скейлинга на 4b -> 8b уже не особо уменьшает претрейновый лосс
https://arxiv.org/pdf/2508.20900
Парни публикую техрепорты быстрее, чем я успеваю писать на них разборы 🗿
- Обновленная архитектура: 8b (!) dense decoder-only (но в прод снова выкатывают 1b)
- Обновленная процедура алайнмента
- Прирост поверх v1 сопоставим с приростом v1 относительно каскадной системы
- Профит от скейлинга на 4b -> 8b уже не особо уменьшает претрейновый лосс
👍15🔥4❤3
Про нестабильности в обучении
(мемчик из внутреннего чата от Влада Тыцкого)
Недавно мы взялись написть архетип - библиотечный класс нашей генеративной модели. После лёгкого рефакторинга обучение начало "взрываться" (кто бы мог подумать).
Что мы обычно используем для стабилизации:
- Gradient clipping
- Лоссы и нелинейности - в fp32
- Learning rate warmup и аккуратный подбор пикового значения
- Pre-norm
- QK-нормализацию
До сих пор не используем, но в LLM применяют:
- AdamW
- Очистку датасета от "плохих" батчей
- Отключение bias
- RMSNorm вместо LayerNorm
Конкретно в этом случае не спасало вообще ничего. Локализовать проблему помогло только отслеживание std (!) активаций на разных слоях.
Дебаг занял недели, а фикс ровно 1 строку кода.
(мемчик из внутреннего чата от Влада Тыцкого)
Недавно мы взялись написть архетип - библиотечный класс нашей генеративной модели. После лёгкого рефакторинга обучение начало "взрываться" (кто бы мог подумать).
Что мы обычно используем для стабилизации:
- Gradient clipping
- Лоссы и нелинейности - в fp32
- Learning rate warmup и аккуратный подбор пикового значения
- Pre-norm
- QK-нормализацию
До сих пор не используем, но в LLM применяют:
- AdamW
- Очистку датасета от "плохих" батчей
- Отключение bias
- RMSNorm вместо LayerNorm
Конкретно в этом случае не спасало вообще ничего. Локализовать проблему помогло только отслеживание std (!) активаций на разных слоях.
Дебаг занял недели, а фикс ровно 1 строку кода.
👍11🔥5👨💻5
Написал разбор свежей статьи от Alibaba о фундаментальных моделях. Эта тема меня очень интересует, хотя подход, основанный на ручных признаках, не тот, который мы используем в своей работе.
Обязательно подпишитесь на Рекомендательную: там публикуются разборы актуальных статей, и очень часто их делают ребята из нашей команды.
Обязательно подпишитесь на Рекомендательную: там публикуются разборы актуальных статей, и очень часто их делают ребята из нашей команды.
👍10🔥9
Forwarded from Red RecSys
Генеративные рекомендации 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.
Меняя компанию, я успела походить по собесам в области 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.
arXiv.org
Realizing Scaling Laws in Recommender Systems: A Foundation-Expert...
While scaling laws promise significant performance gains for recommender systems, efficiently deploying hyperscale models remains a major unsolved challenge. In contrast to fields where FMs are...
🔥11
Подпишитесь на канал Даши Тихонович, если интересно читать про актуальные рекомендательные технологии.
А ещё прочитайте eSASRec, где Даша - первый автор. Достойная работа, которая принята на RecSys ’25!
А ещё прочитайте eSASRec, где Даша - первый автор. Достойная работа, которая принята на RecSys ’25!
🔥10❤5
PML
Выступаю завтра на PML с рассказом про опыт внедрения генеративных моделей в нашу экосистему. Постарался подготовить очень практический материал, который можно будет применить в вашей компании. Должно быть полезно, даже если у вас нет большого числа видеокарт и намерения строить end2end генеративные рекомендации.
Оффлайн билетов уже нет, но можно посмотреть трансляцию:
https://pmlconf.yandex.ru/2025/
Выступаю завтра на PML с рассказом про опыт внедрения генеративных моделей в нашу экосистему. Постарался подготовить очень практический материал, который можно будет применить в вашей компании. Должно быть полезно, даже если у вас нет большого числа видеокарт и намерения строить end2end генеративные рекомендации.
Оффлайн билетов уже нет, но можно посмотреть трансляцию:
https://pmlconf.yandex.ru/2025/
🔥27❤9
Генеративные_рекомендательные_технологии_что_работает_в_Яндексе.pdf
5.9 MB
Презентация с сегодняшнего выступления
Всем спасибо, кто дошел, было приятно видеть полный зал!
Всем спасибо, кто дошел, было приятно видеть полный зал!
🔥34❤9👏7
Yandex Cup
Пока я немного погряз в работе и запусках (надеюсь очень скоро будет, чем поделиться в канал), напишу здесь про Yandex Cup. В этом году пересобрали ML трек, задачи должны стать интереснее, а финал пройдет в Стамбуле.
Если интересно попробовать свои силы, еще остается несколько дней на регистрацию:
https://yandex.ru/cup
Пока я немного погряз в работе и запусках (надеюсь очень скоро будет, чем поделиться в канал), напишу здесь про Yandex Cup. В этом году пересобрали ML трек, задачи должны стать интереснее, а финал пройдет в Стамбуле.
Если интересно попробовать свои силы, еще остается несколько дней на регистрацию:
https://yandex.ru/cup
❤11🔥5👍2
CIKM'25
В этом году я решил не ехать на RecSys, зато лечу на CIKM в Сеул. Не все слышали про эту конференцию, хотя на ней публикуются очень многие хорошие работы.
В программе этого года самые интересные (на мой взгляд) работы от Pinterest (TransAct V2 и PinRec), несколько работ от команды OneRec из Kuaishou (например QARM про способ токенизации и Pantheon, который они используют в качестве reward модели), а также end2end генеративная рекламная система от Meituan (самой большой доставки еды в мире).
Постараюсь привезти какие-нибудь инсайты, которыми поделюсь в канале.
В этом году я решил не ехать на RecSys, зато лечу на CIKM в Сеул. Не все слышали про эту конференцию, хотя на ней публикуются очень многие хорошие работы.
В программе этого года самые интересные (на мой взгляд) работы от Pinterest (TransAct V2 и PinRec), несколько работ от команды OneRec из Kuaishou (например QARM про способ токенизации и Pantheon, который они используют в качестве reward модели), а также end2end генеративная рекламная система от Meituan (самой большой доставки еды в мире).
Постараюсь привезти какие-нибудь инсайты, которыми поделюсь в канале.
🔥29❤17
CIKM'25 recap
Для меня это первый опыт поездки на CIKM и надо сказать, что конференция показалась мне в разы более полезной, чем RecSys. У обеих нет статуса A*, но CIKM отличается более лайтовым ревью работ. Например там нет ограничений на публикацию статьи до самой конфы. Казалось бы, такой подход должен привести к негативному отбору, но по факту на конференцию привозят большое количество отличных индустриальных и прикладных работ, которые не прошли по критериям научности в другие места.
Несколько заметок на полях по результатам поездки:
1. Тренд на Target Aware архитектуры в ранжировании
Компании переходят от классических deep ranker архитектур, основанных на feature interaction, к моделям с использованием раннего связывания с историей пользователя (InterFormer, RankMixer, MTGR, TransAct V2).
Общая идея:
- Используем сырую историю событий как вход в модель
- В attention нужно подставить как историю, так и самого кандидата (в виде одного или нескольких токенов)
- Сохраняются классические ручные признаки
Тренд появился не вчера, но все ещё не стихает. Мы в Яндексе тоже внедряем такие модели. На PML'25 как раз был доклад об этом от Пети Зайделя из команды Музыки.
2. Конкуренция на китайском рынке рекомендательных систем
По статьям прослеживается, насколько китайский рынок конкурентен. Как минимум 3 популярные платформы коротких видео (Douyin, Kuaishou, Weixin Channels) и 2 крупных ecom сервиса (Meituan и Taobao) привезли свои работы.
Кроме того, на CIKM приехали ребята из NetEase Cloud Music - 2й по популярности платформы музыкального стриминга в Китае. Говорят, что читают наши статьи и активно пользуются датасетом, попросили сфотографироваться 🙂
Доклады у них кстати тоже были неплохие: Climber про target-aware transformer и работа про semantic ids.
Ещё один интересный инсайт про конкуренцию: компании скрывают настоящих авторов своих работ, чтобы тех не захантили конкуренты! Узнали мы это из приватного разговора в куллуарах 🙂
3. Тренд на end2end системы только набирает обороты
Я здесь много пишу про то, что мы верим в end2end генеративные рекомендтельные системы и строим такую у себя (поделюсь кстати в ближайшее время, как у нас с этим дела). Meituan привез на конференцию работу про свою реализацию - EGA v1. Несмотря на то, что работа выпущена весной этого года, из слайдов мы узнали, что АБ тест провели уже больше года назад! Надо догонять 🙂
На конференции были ребята из core команды OneRec. Удалось узнать у них много деталей, которых нет в статьях. Западные команды тоже вдохновились работой и пытаются нагнать. Говорят, основные сложности лежат в инфраструктуре. По нашему опыту это действительно непростая часть.
Ещё немного инсайдов:
- Pinterest не переобучают и не дообучают свой PinRec, хотя в модели используются item id. Очень неожиданно и даже странно
- PinnerFormer не используется как кандидат-генератор, только как фича в downstream моделях
- TransAct V2 переобучают раз в неделю, но со случайных весов
- Для построения semantic ids в OneRec использовали всего 200 GPU 🗿
Для меня это первый опыт поездки на CIKM и надо сказать, что конференция показалась мне в разы более полезной, чем RecSys. У обеих нет статуса A*, но CIKM отличается более лайтовым ревью работ. Например там нет ограничений на публикацию статьи до самой конфы. Казалось бы, такой подход должен привести к негативному отбору, но по факту на конференцию привозят большое количество отличных индустриальных и прикладных работ, которые не прошли по критериям научности в другие места.
Несколько заметок на полях по результатам поездки:
1. Тренд на Target Aware архитектуры в ранжировании
Компании переходят от классических deep ranker архитектур, основанных на feature interaction, к моделям с использованием раннего связывания с историей пользователя (InterFormer, RankMixer, MTGR, TransAct V2).
Общая идея:
- Используем сырую историю событий как вход в модель
- В attention нужно подставить как историю, так и самого кандидата (в виде одного или нескольких токенов)
- Сохраняются классические ручные признаки
Тренд появился не вчера, но все ещё не стихает. Мы в Яндексе тоже внедряем такие модели. На PML'25 как раз был доклад об этом от Пети Зайделя из команды Музыки.
2. Конкуренция на китайском рынке рекомендательных систем
По статьям прослеживается, насколько китайский рынок конкурентен. Как минимум 3 популярные платформы коротких видео (Douyin, Kuaishou, Weixin Channels) и 2 крупных ecom сервиса (Meituan и Taobao) привезли свои работы.
Кроме того, на CIKM приехали ребята из NetEase Cloud Music - 2й по популярности платформы музыкального стриминга в Китае. Говорят, что читают наши статьи и активно пользуются датасетом, попросили сфотографироваться 🙂
Доклады у них кстати тоже были неплохие: Climber про target-aware transformer и работа про semantic ids.
Ещё один интересный инсайт про конкуренцию: компании скрывают настоящих авторов своих работ, чтобы тех не захантили конкуренты! Узнали мы это из приватного разговора в куллуарах 🙂
3. Тренд на end2end системы только набирает обороты
Я здесь много пишу про то, что мы верим в end2end генеративные рекомендтельные системы и строим такую у себя (поделюсь кстати в ближайшее время, как у нас с этим дела). Meituan привез на конференцию работу про свою реализацию - EGA v1. Несмотря на то, что работа выпущена весной этого года, из слайдов мы узнали, что АБ тест провели уже больше года назад! Надо догонять 🙂
На конференции были ребята из core команды OneRec. Удалось узнать у них много деталей, которых нет в статьях. Западные команды тоже вдохновились работой и пытаются нагнать. Говорят, основные сложности лежат в инфраструктуре. По нашему опыту это действительно непростая часть.
Ещё немного инсайдов:
- Pinterest не переобучают и не дообучают свой PinRec, хотя в модели используются item id. Очень неожиданно и даже странно
- PinnerFormer не используется как кандидат-генератор, только как фича в downstream моделях
- TransAct V2 переобучают раз в неделю, но со случайных весов
- Для построения semantic ids в OneRec использовали всего 200 GPU 🗿
👍16🔥8🙏4❤3
ML Global Recap'25
Готовлю выступление на наш митап ML Global Recap. Расскажу там по-подробнее, как я вообще вижу текущие тренды в рекомендациях, куда идут разные компании и что рассказали на конференциях в этом году. По-подробнее расскажу, что было на RecSys (я на него не ездил, но от нашей команды была большая делегация) и на CIKM, добавлю каких-нибудь инсайдов.
Кроме меня выступит Лёша Гусаков, наш CTO, с рассказом про NeurlPS, а также лиды CV, NLP и Speech команд с рассказами про тренды в их областях. Должно быть интересно!
Презентацию скину в канал, но лучше приходите послушать лично. Пообщаемся после выступления в куллуарах 🙂
Ссылка на регистрацию
Готовлю выступление на наш митап ML Global Recap. Расскажу там по-подробнее, как я вообще вижу текущие тренды в рекомендациях, куда идут разные компании и что рассказали на конференциях в этом году. По-подробнее расскажу, что было на RecSys (я на него не ездил, но от нашей команды была большая делегация) и на CIKM, добавлю каких-нибудь инсайдов.
Кроме меня выступит Лёша Гусаков, наш CTO, с рассказом про NeurlPS, а также лиды CV, NLP и Speech команд с рассказами про тренды в их областях. Должно быть интересно!
Презентацию скину в канал, но лучше приходите послушать лично. Пообщаемся после выступления в куллуарах 🙂
Ссылка на регистрацию
🔥17