Generative Recommendation for Large-Scale Advertising

Tue, 31 Mar 2026 10:35:23 +0000

Generative Recommendation for Large-Scale Advertising

Сегодня разбираем статью, где авторы из Kuaishou расширяют парадигму OneRec на рекламный домен. Они выделяют три проблемы, которые в рекламных рекомендациях проявляются особенно остро по сравнению с обычными LLM.

1. Рекламу сложно токенизировать: одно объявление — это сразу видео, текст, продукт, бренд, рекламодатель и бизнес-метаданные.
2. Важно не просто генерировать рекомендации — важен порядок объявлений в выдаче и eCPM.
3. Всё это должно работать в проде с жёсткими ограничениями по latency.

Ответом становится GR4AD (Generative Recommendation for ADdvertising) — генеративная рекламная система, в которой для каждой из этих проблем есть отдельное решение.

Нововведения такие:

- UA-SID (unified advertisement semantic ID) — единый семантический идентификатор объявления. Объявление прогоняют через мультимодальную модель с instruction tuning для получения эмбеда с учётом прикладной семантики (контент, продукт, рекламодатель и так далее). Потом с помощью co-occurrence learning дообучают эмбеддинги под рекламный домен. Это нужно, чтобы модель лучше улавливала совместимость между рекламными сущностями. Далее полученные эмбеды с помощью MGMR RQ-KMeans квантуют в многоуровневые SID. Первые уровни ловят грубую семантику, следующие — уточняют остаточную информацию. Последний токен — хэш бизнес-ID для борьбы с коллизиями.

- LazyAR ускоряет декодер. Самый важный первый токен генерируется честно авторегрессивно, а часть промежуточных слоёв переиспользуется и считается не авторегрессивно. Для сохранения качества на выходы этих слоев навешивается дополнительный MTP-loss.

- VSL+RSPO — VSL добавляет в обучение бизнес-сигнал: модель предсказывает не только последовательность SID-токенов, но и дискретизированный eCPM. Добавляют перевзвешивание: более ценные пользователи и более важные действия получают больший вес. RSPO — RL-style компонента для list-wise-оптимизации. Вместо point-wise-обучения модель учат ранжировать список объявлений так, чтобы улучшать NDCG.

Ещё можно отметить оптимизации, например Dynamic Beam Serving, который подстраивает beam search под стадию генерации и текущую нагрузку. На ранних шагах beam шире. При высоком QPS — уже. Добавляются TTL-кэши, beam-cache, KV-cache, FP8.

Система построена как замкнутый цикл, в котором новые объявления переводятся в UA-SID и попадают в realtime index. При запросе модель генерирует и ранжирует кандидатов, после чего их показывают пользователю. Дальше система собирает reward-сигналы и отправляет их в онлайн-обучение, где обновляются VSL и RSPO. Так, модель постоянно дообучается на живом трафике.

Результаты у статьи впечатляющие. UA-SID сам по себе даёт ограниченный прирост к базовому генеративному ранкеру, основной буст происходит от способа обучения: VSL + RSPO заметно поднимают revenue относительно OneRec-V2. Сервисные оптимизации тоже ощутимые: LazyAR почти удваивает QPS без заметной просадки по качеству, а DBS помогает поймать баланс между скоростью и доходом. В A/B-тестах репортят увеличение рекламной выручки до 4,2% по сравнению с сильным бейзлайном на основе DLRM. Модель здорово масштабируется по качеству в зависимости от beam search width и количества параметров.

В целом работа выглядит как практичная попытка «приземлить» генеративные рекомендации в рекламу. Главная мысль статьи в том, что для использования LLM в рекламе, нужно учитывать специфику домена — например, свои SID, business-aware-лоссы и serving-оптимизации.

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

QARM V2: Quantitative Alignment Multi-Modal Recommendation for Reasoning User Sequence Modeling

Wed, 25 Mar 2026 08:39:01 +0000

QARM V2: Quantitative Alignment Multi-Modal Recommendation for Reasoning User Sequence Modeling

Сегодня разбираем статью от Kuaishou о том, как использовать LLM для формирования семантических фичей в ранжирующих моделях.

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

Когда последовательности становятся длинными, используют двухэтапную схему:

1) General Search Unit (GSU) выбирает из истории пользователя айтемы, наиболее близкие к текущему кандидату;
2) Exact Search Unit (ESU) точно оценивает релевантность кандидата по этой сжатой истории.

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

- низкая информативность (эмбеддинг не раскрывает семантику);
- изолированность знаний;
- слабая генерализация без постоянного дообучения;
- проблемы long-tail и cold start.

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

Причина в рассинхроне с задачей рекомендаций:

- Representation Unmatch — LLM понимает айтем, но не его релевантность пользователю;
- Representation Unlearning — эмбеддинги нельзя обучать end-to-end вместе с моделью.

QARM V2 решает эту проблему, адаптируя LLM-эмбеддинги под задачу рекомендаций через механизм Reasoning Item Alignment. Идея подхода в том, чтобы затюнить LLM под генерацию эмбеддингов, одновременно отражающих хорошее понимание айтемов и способных предсказывать их со-встречаемость:

1) на основе коллаборативных моделей собираются item-item-пары в качестве таргета для контрастивного обучения;
2) пары фильтруются, убирается шум и bias на популярные айтемы;
3) для айтемов также генерируются QA-пары в качестве таргета для генерации ответов;
4) обучение идёт по схеме «входные данные -> EMB-токены –> генерация ответов + контрастивный лосс».

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

Вторая часть пайплайна — построение semantic IDs через квантизацию. Базовый Residual KMeans хорошо ловит грубую семантику, но даёт много коллизий (разные айтемы получают одинаковые коды).

Авторы предлагают гибрид, в котором верхние уровни (Residual KMeans) захватывают грубую семантику, а последний (FSQ) помогает различать близкие айтемы и снижает коллизии.

Дальше подход встраивается в обычную схему GSU/ESU. Сначала с помощью полученных LLM эмбеддингов из истории пользователя выбираются наиболее близкие кандидату айтемы, а затем уже в ESU используются semantic IDs как признаки для более точного ранжирования.

Важно, что эмбеддинги для semantic IDs обучаются end-to-end вместе с ранжирующей моделью, в отличие от зафриженных LLM-эмбеддингов.

По результатам всё выглядит ожидаемо «сильным»: стабильные улучшения в офлайн-метриках, заметный буст в cold-start-сценариях, снижение количества коллизий после новой квантизации. Основные бизнес-метрики (CTR, GMV) демонстрируют ощутимые приросты в онлайн-экспериментах.

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

@RecSysChannel
Разбор подготовила ❣ Дарья Тихонович

Efficient Sequential Recommendation for Long Term User Interest Via Personalization

Thu, 19 Mar 2026 10:47:01 +0000

Efficient Sequential Recommendation for Long Term User Interest Via Personalization

Сегодня разберём недавнюю статью от Meta* на тему сжатия историй в sequential рекомендательных моделях.

Авторы исследуют, как сжимать long-term-историю пользователя так, чтобы её можно было эффективно обрабатывать на инференсе и при этом не потерять в качестве. Это не новая архитектура, а скорее фреймворк или метод сжатия истории, который можно применять к разным моделям. Например, в статье рассматриваются HSTU и HLLM.

Проблема

Sequential recommender обычно строится на трансформерной архитектуре, которая страдает от квадратичной сложности механизма аттешнна. Из-за этого обрабатывать длинные последовательности вычислительно дорого, хоть они и приносят стабильный профит.

В релевантных работах эту проблему решают в два этапа: сначала long-term-историю сокращают (например, семплируют или кластеризуют события), а затем объединяют с последними событиями и прогоняют через модель. В статье приводят примеры подходов KuaiFormer, SIM, TWIN V2.

Идея

Авторы предлагают новый подход — сжимать историю с помощью выучиваемых токенов (personalized experts).

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

Обучение

Обучение авторегрессивное, используется специальная аттеншн-маска: каждый токен может смотреть на предыдущие токены своего сегмента и на «экспертов» из предыдущих сегментов, при этом сами токены этих сегментов скрыты маской.
Модель обучается стандартно на задачу next item prediction, при этом для «экспертов» лосс не считается.

На инференсе сегменты обрабатывают последовательно, а key- и value-эмбеддинги сжимающих токенов сохраняются. При предсказании следующего айтема используют только текущий сегмент и сохраненные key и value «экспертов» с предыдущих сегментов. Благодаря этому пропадает необходимость обрабатывать всю long-term-историю как одну длинную последовательность.

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

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

Они проводятся на двух датасетах:

- MerRec — e-commerce датасет из Mercari;
- EB-NeRD — новостной датасет из газеты Ekstra Bladet.

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

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

Как оказалось при анализе результатов, «эксперты» часто содержат информацию по небольшому набору айтемов из истории, релевантных таргетному. Например, для айтема “LEGO” среди наиболее важных элементов из истории оказываются другие LEGO-товары.

Исходный код доступен на GitHub.

@RecSysChannel
Разбор подготовил ❣ Никита Степанов
___
Компания Meta признана экстремистской; её деятельность в России запрещена.

Айсберг KV-кэшей, или Как эффективно считать трансформеры

Fri, 13 Mar 2026 08:03:12 +0000

Айсберг KV-кэшей, или Как эффективно считать трансформеры

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

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

Но дальше всплывает «айсберг». KV-кэш быстро становится гигантским, потому что растёт сразу по нескольким осям: число слоёв, длина контекста, число KV‑голов, head_dim и dtype. Например, если хранить KV в FP16/BF16 (2 байта), то для контекста 8K порядок цифр на одну последовательность получается примерно такой:

- 2 ГБ для моделей 30B с GQA (зависит от точной архитектуры);
- 4 ГБ для LLaMA‑2‑7B;
- 36 ГБ для GPT‑3‑175B.

И это ещё до того, как мы вспомним о большом количестве одновременных пользователей. Закономерный вопрос: как такое внедрять в прод?

Где обычно ужимают KV-кэш

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

- по головам — Multi‑Query или Grouped‑Query Attention (меньше K/V-голов при том же числе Q-голов);
- по слоям или доступному контексту — Sliding Window Attention (держим только окно последних W-токенов);
- по dtype — квантизации;
- по head_dim — подходы, вроде Multi Latent Attention;
- и отдельный класс — умное сокращение контекста, например KVZip и KVZap.

На последнем пункте остановимся подробнее.

KVZip/KVZap — это «умное выкидывание» токенов (а точнее, KV-пар) по важности для контекста. KVZip оценивает важность через аттеншн при реконструкции промпта (teacher‑forcing) — но для этого нужен дополнительный прогон. KVZap предсказывает важность по скрытому состоянию и режет по порогу, делая сжатие адаптивным. Главное ограничение подхода — пока нет хорошей реализации, совместимой с Paged Attention (неравномерная длина кэша для голов требует работы с блоками переменной длины), что критично для использования в высоконагруженной системе.

Немного GPU-реальности

Даже с красивым прунингом остаётся системная проблема: если аллоцировать KV-кэш как один большой непрерывный блок, память со временем фрагментируется. В итоге могут оставаться «дырки», куда уже не помещаются новые большие кэши, хотя суммарно свободной памяти вроде бы достаточно. Из-за этого возникает серьёзная недоутилизация GPU-памяти.

Типовое решение — Paged Attention: KV-кэш режут на страницы фиксированного размера и управляют ими через таблицу блоков. Вместо одного большого куска появляются небольшие блоки, которыми проще управлять и переиспользовать между запросами.

Как это используют

Есть несколько популярных проектов, которые по-разному решают задачу KV-кэша. Разберём некоторые из них.

1) vLLM — цельный inference‑движок вокруг Paged Attention

Плюсы:
- зрелая реализация paged‑подхода;
- multi‑GPU (tensor parallel) и коммуникации через NCCL;
- опенсорс.

Минусы:
- сложнее «вклинивать» нестандартные политики работы с KV (не всегда удобно расширять под свои эксперименты);
- KV‑кэш в основном локален узлу/серверу (шаринг и распределённое хранение — отдельная задача).

2) LMCache — KV‑кэш как отдельный слой (многоуровневый)

Плюсы:
- явная работа со страницами или блоками и несколькими уровнями кэша (GPU, CPU, SSD, распределённый);
- поддержка распределённого хранения KV;
- фокус на расширяемости и интеграции;
- опенсорс.

Минус:
- сочетание с оптимизациями внутри узла (NVLink/NVSwitch, tensor parallel) зависит от конкретной интеграции с движком и не всегда «из коробки».

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

@RecSysChannel
Разбор подготовил ❣ Кирилл Маляев

RankMixer: Scaling Up Ranking Models in Industrial Recommenders

Wed, 04 Mar 2026 09:38:58 +0000

RankMixer: Scaling Up Ranking Models in Industrial Recommenders

Сегодня разберём статью от ByteDance. Авторы предлагают модель RankMixer, новую масштабируемую архитектуру ранжирования для индустриальных рекомендаций.

Современные ранжирующие модели часто плохо используют GPU. Многие подходы исторически оптимизировались под CPU, из-за чего GPU-утилизация остаётся низкой. Авторы хотят повысить MFU (Model FLOPs Utilization) — то, насколько эффективно модель использует вычисления.

RankMixer позиционируется как продолжение линейки работ по deep learning в рекомендациях: Wide&Deep, DeepFM, DCNv2 и других моделей, развивающих feature interactions.

Архитектура

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

Сначала все признаки переводятся в token-based-представление, то есть представляются токенами одинаковой размерности. На входе получается матрица T×D, где T — число токенов, а D — их размерность.

Дальше токены подаются в RankMixer block, который состоит из двух частей:
- Multi-head Token Mixing,
- Per-token FFN (PFFN).

В Multi-head Token Mixing каждый токен разбивается на H голов, чтобы смешивать разные семантические фрагменты и лучше учитывать гетерогенность признаков.

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

Дальше идёт Per-token FFN, где каждый токен обрабатывается индивидуально. По сути это feed-forward-слой, но применяется он отдельно для каждого токена.

В PFFN также используют Sparse Mixture-of-Experts (MoE). Это позволяет увеличивать capacity модели без такого же роста флопсов: вместо одного FFN берут набор экспертов, и для каждого токена активируют только часть из них.

В статье отдельно обсуждают проблему dying experts, когда работают только несколько доминирующих экспертов. Для борьбы с этим используют routing-стратегию: роутер выбирает несколько экспертов; а также добавляют load balancing losses, чтобы эксперты использовались равномернее.

После нескольких блоков выход агрегируется через pooling, и дальше модель предсказывает таргетные сигналы: например, skip, like, completion и другие.

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

В работе есть сравнения по эффективности и качеству. Также авторы провели долгий A/B-эксперимент онлайн в Douyin и Douyin Lite, по итогам которого заменили в проде 16M модель на RankMixer 1B без существенного увеличения времени на инференс.

Для офлайн-оценки взяты стандартные метрики AUC и UAUC. Эксперименты провели сначала на рекомендациях видео, а затем и на рекламе.

В качестве бейзлайнов сравнивают RankMixer с MLP + feature crossing, DCNv2, а также с более современными моделями (например, AutoInt и HiFormer).

Результаты

RankMixer выигрывает у бейзлайнов как в варианте около 100M параметров, так и в варианте около 1B параметров. Полученные улучшения статзначимы.

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

В аблейшнах видно, что главный вклад дают два компонента RankMixer block:

1) Удаление Multi-head Token Mixing сильно снижает качество.
2) Замена Per-token FFN на shared FFN тоже ухудшает метрики.

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

@RecSysChannel
Разбор подготовила ❣ Василиса Григорьева

SilverTorch: A Unified Model-based System to Democratize Large-Scale Recommendation on GPUs

Fri, 27 Feb 2026 10:40:02 +0000

SilverTorch: A Unified Model-based System to Democratize Large-Scale Recommendation on GPUs

Сегодня разбираем статью от Meta* на тему кандидатогенерации на основе GPU. Авторы рассказывают, как именно уносят кандидатогенераторы на GPU и какой профит получают.

Индустриальные рекомендательные системы скейлятся на десятки и сотни миллионов айтемов, поэтому приходится строить каскад, где на ранней стадии кандидатов достают из ANN-индекса и дополнительно фильтруют по разным бизнес-правилам.

В работе утверждают, что типичный пайплайн «ANN на CPU + фильтрующий сервис + сетевые вызовы между компонентами» дорогой и неэффективный. Сюда прибавляется проблема неконсистентности: юзерная часть двубашенной модели обновляется часто, а документная — редко, потому что перестроение индекса стоит дорого. Это приводит к миссматчу версий и создаёт целых 30% дропа перформанса.

В SilverTorch объединяют индексацию и фильтрацию на одной видеокарте и реализуют всё как один PyTorch-граф без пересылок между отдельными сервисами. Для фильтрации вместо обратного индекса используют Bloom-index: строят битовые маски по атрибутам (язык, регион и прочее), транспонируют представление так, чтобы обрабатывать куски по 64 документа за инструкцию и избегать рандомных обращений к памяти. Фильтрацию делают сразу во время ANN-поиска, чтобы топ на выходе ANN-индекса содержал строго айтемы, соответствующие всем бизнес-правилам. Bloom-маску строят только по айтемам из выбранных кластеров — это, по оценке авторов, в 30 раз сократило стоимость стадии фильтрации фичей.

Сам ANN-поиск реализован как KNN с кластеризацией (сначала топ центроидов, потом дот-продакты внутри кластеров). Эмбеддинги квантуют в Int8, что в два раза сокращает потребление памяти и сильно поднимает пропускную способность.

Высвободившийся бюджет тратят на OverArch scoring layer — нейросеть, которая усложняет функцию матчинга поверх дот-продакта и даёт более высокий recall. Отдельно говорят, что такой дизайн упрощает мультитаск-ретривал: не нужно строить несколько индексов, так как все таски считаются в одной копии индекса, а потом комбинируются value-моделью.

По результатам на двух industry-scale-датасетах (10 млн и 80 млн айтемов) авторы получили снижение latency более чем в 5 раз, рост пропускной способности в 23 раза и сокращение костов на сёрвинг в 13 раз. Систему уже внедрили в сотни моделей в продуктах Meta, и она сёрвит миллиарды пользователей.

@RecSysChannel
Разбор подготовил ❣ Николай Савушкин
___
Компания Meta признана экстремистской; её деятельность в России запрещена.

OpenOneRec Technical Report

Wed, 18 Feb 2026 08:39:01 +0000

OpenOneRec Technical Report

Сегодня кратко пересказываем техрепорт от Kuaishou о рекомендательной модели, которая должна быть способна не только рекомендовать, но ещё и понимать, что она рекомендует, и уметь это объяснять.

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

RecIF-Bench

В бенчмарке три домена: short video, ads и products. Всего около 200 тысяч пользователей, больше 15 миллионов айтемов и почти 120 миллионов взаимодействий. Домены при этом сильно отличаются.

В видео у пользователей очень длинные истории с сотнями взаимодействий. В рекламе айтемов и кликов меньше. Products — это отдельный e-commerce-домен со своими паттернами.

Для кодирования айтемов используется семантические id, которые добавляются в словарь базовой LLM. История пользователя в виде единой последовательности, а обучение просходит авторегрессивно. Это позволяет обучать архитектуру LLM без изменений по принципу next-token prediction, но в рекомендательном контексте.

Кроме логов взаимодействий, датасет содержит три источника информации: пользователь, айтем и само взаимодействие. Пользователь описывается через текстовый User Portrait: демография, история просмотров, поиски, подписки, покупки и т.д. У айтемов есть мультимодальные эмбеддинги и dense captions (для видео). Во взаимодействиях учитывают разные сигналы: лайки, комментарии, просмотры, дизлайки.

Какие задачи проверяют

Всего выделяют восемь типов задач и распределяют их по четырём уровням. Каждый следующий требует от модели более «общего» поведения. Сначала понимание айтемов и простые рекомендации. Потом условные рекомендации, вроде «предскажи видео, которое лайкнут». И в конце задачи на объяснение рекомендаций.

Как обучают модель

Обучение во многом похоже на OneRec Think. Сначала делают warm-up для айтемных токенов, потом претрейн на основном датасете с добавлением обычных текстов, чтобы предотвратить катастрофическое забывание языка. Полностью это всё равно не спасает, поэтому дальше идут стадии посттрейнинга.

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

Отдельно говорят о масштабировании, что для таких моделей данные нужно скейлить чуть агрессивнее, чем параметры. Это хорошо ложится на общий опыт обучения рекомендательных моделей: относительно небольшие модели учатся на больших датасетах.

Результаты

На своём бенчмарке модели ожидаемо обгоняют базлайны. Интересно, что есть трейд-офф между обычной 8B и 8B Pro: вторая лучше в рекомендациях, но обычная 8B часто сильнее в задачах, где нужно говорить и объяснять.

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

@RecSysChannel
Разбор подготовил ❣ Иван Артемьев

Massive Memorization with Hundreds of Trillions of Parameters for Sequential Transducer Generative Recommenders

Thu, 12 Feb 2026 09:49:40 +0000

Massive Memorization with Hundreds of Trillions of Parameters for Sequential Transducer Generative Recommenders

Скейлинг рекомендательных моделей — один из ключевых трендов рексистем последних лет. Исследователи Яндекса в рамках подхода Argus показывали, что качество моделей сильнее всего растёт при увеличении длины последовательности, которую обрабатывает трансформер. Однако рост до десятков и сотен тысяч событий сопряжен уже с инфраструктурными сложностями, и применение таких моделей в реалтайме за разумное время не представляется возможным.

Сегодня рассказываем о статье, в которой авторы из Meta* предлагают элегантный двухстадийный фреймворк. Вместо того, чтобы тяжелым трансформером держать в контексте 1 млн событий, можно в офлайне сжать всю lifelong-историю, а в рантайме использовать это сжатое представление.

Идея сама по себе не нова, но в близких по духу работах SIM, TWIN V2 или Transact V2 утилизация lifelong-контекста была сопряжена либо с тривиальным и неэффективным сжатием последовательности, либо с обработкой ограниченного подмножества событий, что в итоге ведёт к сильной просадке качества.

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

Эмбеддинги складываются в кэш, который обновляется асинхронно. Во время инференса их берут и строят target attention между сжатыми представлениями и айтемами-кандидатами.

Результаты офлайн-экспериментов оказались примерно сопоставимы с HSTU, вместе с этим скорость инференса при увеличении длины последовательности остаётся практически константной.

A/B-тест проводился, скорее всего, на базе Reels, в качестве бейзлайна выступала HSTU-модель. Ключевая внутренняя метрика вовлеченности C-task выросла на 0,5%, а дополнительные метрики удержания — O1 и O2 tasks — на 0,2% и 0,04%. Утверждается, что рост O2 даже на 0,01% — это существенный успех.

@RecSysChannel
Разбор подготовил ❣ Руслан Кулиев
___
Компания Meta признана экстремистской; её деятельность в России запрещена.

OneRec-Think: In-Text Reasoning for Generative Recommendation

Wed, 04 Feb 2026 11:02:16 +0000

OneRec-Think: In-Text Reasoning for Generative Recommendation

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

OneRec хорошо предсказывает следующий айтем по истории пользователя, но остаётся узкодоменной моделью: у неё нет широкого world knowledge, как у LLM, и нет развитых механизмов следования инструкциям и рассуждения. Поэтому авторы добавляют в OneRec-Think ризонинг, рассчитывая улучшить точность рекомендаций. Причём он используется непосредственно в процессе предсказания следующего айтема.

Тут возникают две сложности. Во-первых, LLM изначально не знает, что такое рекомендательные айтемы (видео, треки и прочее). Во-вторых, даже если заставить её «думать», она не умеет думать именно в рекомендательном домене: длинные и шумные истории пользователей ломают красивый ризонинг.

Авторы решают эти проблемы в три этапа.

Сначала делают Itemic Alignment. В словарь добавляют айтем-токены (3×8К = 24К новых токенов) и учат модель понимать айтем-токены в одном контексте с текстовыми. Делают это аккуратно: сначала замораживают бэкбон и обучают только эмбеддинги новых токенов, чтобы сохранить языковые способности модели, а затем размораживают все параметры и обучают модель совместно. Используют несколько задач, включая интерпретацию пользовательской истории, sequential next-item prediction и декодирование айтемов в текстовые описания.

Дальше — Reasoning Activation. Просто взять полную историю и попросить «подумай» не работает: слишком много шума и длинный контекст. Поэтому ризонинг-траектории извлекают хитрее. Берут таргет-айтем и с помощью внешней модели близости айтемов g(·,·) достают top-k (k=10) самых релевантных айтемов из истории пользователя. На этом подмножестве модель способна сгенерировать осмысленное объяснение того, почему пользователь взаимодействовал с таргетным айтемом. Эти объяснения затем используют как SFT-данные: уже на полной истории учат сначала генерировать ризонинг-трейс, а потом — следующий айтем.

И финальный этап — Reasoning Enhancement. Модель сэмплит несколько объяснений, а дальше под каждое считают reward — не в бинарной форме «угадал / не угадал», а на основе степени совпадения семантических токенов предсказанных кандидатов с таргетным айтемом. Для этого используется beam search по продолжениям. В результате ризонинг-траектории, ведущие к более точным предсказаниям, получают больший вес и становятся более вероятными.

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

В онлайне обычный OneRec ограничивается этим множеством и быстро достраивает финальный айтем. За счёт этого снижается стоимость инференса и одновременно в продакшн-систему переносятся знания LLM, зашитые в ризонинг-префиксы.

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

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

KVzap: Fast, Adaptive, and Faithful KV Cache Pruning

Thu, 29 Jan 2026 09:14:01 +0000

KVzap: Fast, Adaptive, and Faithful KV Cache Pruning

Сегодня посмотрим на совсем свежую статью от NVIDIA о сжатии KV-кэша. KV-кэш — это сохраненные K- и V-стейты трансформера для последующей авторегрессивной генерации токенов в декодере. В первую очередь проблема сжатия возникает на стадии генерации в LLM, однако она актуальна и для ускорения инференса рекомендательных моделей, например, имеющих encoder-decoder-архитектуру.

Размер KV-кэша линейно зависит от числа слоёв трансформера L, от числа аттеншн-голов H, от длины входной последовательности T и от размерности векторов D. Таким образом, он имеет размерность (2, L, H, T, D), где 2 соответствует хранению K- и V-кэшей в одном тензоре. Сжатие по L-размерности достигается чередованием обычных MHA-слоёв и слоёв со Sliding Window Attention (SWA): GPT-OSS-120B, Gemma3, Kimi-Linear, и др. Для сжатия по размерности H применяют Grouped Query Attention (GQA), в котором одни и те же KV-головы используются в нескольких Q-головах: Llama3, GLM 4.5, Qwen3-235B-A22B. Вдоль размерности D сжатия добиваются с использованием хранения латентных представлений KV-векторов значительно меньшей размерности — Multi-head Latent Attention (MLA): DeepSeek V2.

Текущая SOTA для сжатия вдоль размерности T — KVzip, который:

1. получает входной промпт пользователя;
2. просит модель его повторить, аугментируя промпт следующим образом: «user: <input prompt>. Repeat the previous context exactly. assistant: »;
3. для каждой KV-головы для каждого вектора k_i из input prompt запоминают наибольший по длине повторённого промпта вес аттеншна (а в случае GQA максимум берётся и по группе Q-голов);
4. фиксированный процент K_i и v_i, соответствующих наименьшим запомненным весам, удаляются;
5. сжатый промпт подаётся модели.

Во-первых, такая схема скоринга очень дорога. Во-вторых, она применима только к стадии cache prefilling — стадия cache decoding сохраняется целиком. Последняя проблема особенно актуальна в контексте рассуждающих моделей, которые на стадии декодинга генерируют тысячи токенов.

В работе предлагают дистиллировать слегка модифицированные скоры KVzip в легковесный MLP. Для каждого слоя трансформера и каждого входного скрытого состояния MLP предсказывает вектор скоров из H (число KV-голов) компонент, после чего откидываются KV-пары, скоры которых не превосходят некоторый порог. Таким образом, степень сжатия зависит от информативности промпта. Локальный контекст из ближайших 128 токенов, однако, сохраняется полностью. MLP обучается поверх обученной модели на специальном датасете, содержащем целевые скоры KV-пар.

Поскольку MLP не добавляет значительной вычислительной сложности и применяется к входным токенам поточечно, KVzap можно использовать как во время prefilling’a, так и во время декодинга. Сжатие prefilling-стадии также становится дешевле.

Эвалятся авторы на Qwen3-8B, Llama-3.1-8B-Instruct, и Qwen3-32B, KV-кэш удаётся сжать в 2–4 раза при незначительных потерях качества.

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

Orthogonal Low Rank Embedding Stabilization

Thu, 22 Jan 2026 08:04:13 +0000

Orthogonal Low Rank Embedding Stabilization

Сегодня разбираем статью от авторов из Netflix о стабилизации обучаемых эмбедов пользователя/документа. В двухбашенной архитектуре с поздним связыванием классическая проблема при дообучении — «разворот» пространств эмбеддингов пользователя/документа при сохранении результирующего dot product. Это происходит из-за того, что отдельные координаты эмбедов (например 1-я или i-ная координата вектора документа) не имеют никакого специального смысла, важно лишь их суммарное взаимодействие с соответствующим вектором пользователя.

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

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

Обозначим таблицу эмбеддингов документов как T (размерностью n * e, где n — количество документов, а e — размерность эмбеддингов), а таблицу эмбеддингов пользователей — как W (размерностью m * e, где m — количество пользователей). Тогда их произведение будет иметь смысл матрицы взаимодействий (X=TWᵀ). Сами документные и пользовательские эмбеддинги могут быть нестабильны при обучении: даже небольшие пертурбации в начальных условиях приводят к существенно разным результатам. При этом сингулярное разложение матрицы взаимодействий остаётся единственным с точностью до знаков сингулярных векторов.

Однако получить напрямую SVD-разложение матрицы X вычислительно сложно: O(mn²). В статье предлагают воспользоваться тем, что матрица X — это произведение двух низкоранговых матриц TWᵀ, и сделать QR-разложение каждой из них, что линейно по сложности относительно n и m. А затем сделать SVD-разложение уже низкоранговой (e * e) матрицы RₜRwᵀ, SVD(RₜRwᵀ)=UᵣSVᵣᵀ.

Кроме самого сингулярного разложения X потребуются ещё и матрицы перехода в новое пространство для T и W (Mₜ и Mw соответственно), такие чтоб TMₜ = US¹ᐟ², а WMw = VS¹ᐟ², что сохранит матрицу взаимодействий X: TMₜ(WMw)ᵀ = USV = TWᵀ. Однако, имея сингулярное разложение RₜRwᵀ, их вычислить несложно: Mₜ = Rwᵀ Vᵣ S⁻¹ᐟ²; Mw = Rₜᵀ Uᵣ S⁻¹ᐟ².

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

Дальше задача сводится к поиску матрицы, отображающей получившееся на очередном шаге дообучения представление в референсное пространство. Хотя такое отображение можно искать среди произвольных матриц, удобно ограничить поиск только среди ортогональных. Формально, имея матрицы Tₖ (текущее пространство) и T₀ (референсное пространство) требуется найти такую ортогональную матрицу R, что RTₖ ~= T₀. Эта задача называется ортогональной задачей Прокруста.

Финально, получив матрицы отображения на первом (Mₜ и Mw) и втором (R) шагах, мы имеем преобразование, которое стабилизует пространства эмбеддингов документов (MₜR) и пользователей (MwR). Так как преобразование ортогональное, то значения матрицы взаимодействий не меняются. При этом размерность матрицы — e * e, что делает её хранение и применение очень лёгкой операцией, которую можно добавить последним слоем нейросети.

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

@RecSysChannel
Разбор подготовил ❣ Артём Ваншулин

Какие статьи 2025 года перечитывают эксперты Рекомендательной. Часть 2

Wed, 14 Jan 2026 08:16:20 +0000

Какие статьи 2025 года перечитывают эксперты Рекомендательной. Часть 2

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

ActionPiece: Contextually Tokenizing Action Sequences for Generative Recommendation

Совместная работа DeepMind и авторов SasRec о токенизации в генеративном ретривале. Каждое взаимодействие пользователя представляется в виде множества контентных фичей айтема, которые потом токенизируются на основе частоты их совстречаемостей — подобно тому, как делается в BPE. Что интересно, мерджиться в один токен могут как фичи одного айтема, так и фичи смежных айтемов. Из приятного — есть открытый репозиторий с кодом.

Correcting the LogQ Correction: Revisiting Sampled Softmax for Large-Scale Retrieval

Статья от исследователей из Яндекса о LogQ-коррекции отличается своей математичностью и обобщаемостью: её результат можно использовать в любой задаче с любой моделью, лишь бы она обучалась на softmax-лосс над большим каталогом. Предложенная корректировка точнее аппроксимирует знаменатель softmax, при этом получается заменой буквально пары строк относительно классической LogQ-коррекции. Рост метрик наблюдается как на закрытых данных, так и на публичных, в чём можно удостовериться, прогнав код из открытого репозитория.

Scaling Recommender Transformers to One Billion Parameters

Ещё одна статья от Яндекса с рецептом масштабирования рекомендательных трансформеров до 1 миллиарда параметров. Именно в ней представлен подход ARGUS. Его внедрение в Яндекс Музыку привело к самому большому одномоментному улучшению платформы от нейросетевых подходов: +2,26% к суммарному времени прослушивания и +6,37% к вероятности лайка.

PinFM: Foundation Model for User Activity Sequences at a Billion-scale Visual Discovery Platform

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

В статье много практических трюков: комбинация InfoNCE-лоссов под близкие задачи, серьёзные инженерные оптимизации (cross-attention с дедупликацией, int4-квантизация эмбеддингов), добавление компактных контентных эмбеддингов на этапе файнтюна. Для cold start предлагают на файнтюне заменять часть айтемов в последовательности на рандомные, а для свежих айтемов использовать агрессивный дропаут. В продакшне это дало рост метрик: сохранения сниппетов +1,2% на главной и +0,72% на странице сниппета, а сохранения свежих айтемов на главной — +5,7%.

@RecSysChannel
Статьи отобрали ❣ Сергей Макеев, Руслан Кулиев, Артём Матвеев

Какие статьи 2025 года перечитывают эксперты Рекомендательной. Часть 1

Mon, 12 Jan 2026 09:09:45 +0000

Какие статьи 2025 года перечитывают эксперты Рекомендательной. Часть 1

Прошедший год заметно изменил то, как мы представляли себе рекомендательные системы: границы между кандидатогенерацией, ранжированием и генеративностью начали стираться, а LLM всё чаще становятся частью рекомендательных алгоритмов. Мы собрали важные статьи, к которым эксперты Рекомендательной возвращаются снова и снова. Если вам есть что добавить или с чем поспорить — приходите обсуждать в комментарии!

OneRec Technical Report и OneRec-V2 Technical Report

Самая хайповая серия статей этого года. Авторы первыми в мире объединили все стадии рекомендательной системы в единую генеративную нейросеть. Адаптировали техники, которые давно и активно применяются в других областях: претрейне, GRPO RL. Модель выкатили на 25% трафика одной из самых больших рекомендательных систем в мире с 400 млн DAU. В OneRec-V2 авторы уже реализуют описанные в первой части идеи ухода от схемы encoder-decoder и улучшения RL-обучения.

OneRec-Think: In-Text Reasoning for Generative Recommendation

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

Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations

Авторы построили фундаментальную модель, сочетающую различные органические и рекламные поверхности Meta*. Она объединяет ручное признаковое пространство и обработку сырых историй пользователей. Архитектура состоит из последовательных блоков трансформерных и interaction-слоёв. В статье — очень подробное описание и впечатляющие результаты внедрения.

RecGPT Technical Report и RecGPT-V2 Technical Report

В техрепорте от Taobao рассказывается о создании их рекомендательной системы — на базе множества LLM. RecGPT позволяет хорошо учитывать не только коллаборативный сигнал, но и намерения, которыми руководствуются пользователи при выборе товаров, а также объяснять свои рекомендации на основе контекста и пользовательской истории. Подход получил развитие в техрепорте RecGPT-V2.

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

В этой работе авторы из Youtube и Google DeepMind рассматривают возможность переиспользовать предобученные LLM для задачи генеративного ретривала. Предложили два ключевых улучшения: инициализацию трансформера предобученной текстовой моделью, а также продолженный претрейн с использованием доменных данных (метаданных видео и пользовательских историй просмотров). В результатах показывают, что оба изменения независимо улучшают модель по метрикам генерации кандидатов. Статья выделяется тем, что в ней соединяется много современных трендов: RecSys+LLM, SemanticID и генеративная постановка задачи рекомендаций.

@RecSysChannel

Лучшие статьи отобрали ❣ Николай Савушкин, Виктор Януш, Маргарита Мишустина
___
Meta признана экстремистской организацией, а Facebook и Instagram запрещены на территории РФ

🎉Подводим итоги: лучшее за год в Рекомендательной

Tue, 30 Dec 2025 08:16:32 +0000

🎉Подводим итоги: лучшее за год в Рекомендательной

У нас в RecSys Channel есть традиция: каждый год мы вспоминаем популярные посты, которые пользователи читали и лайкали больше всего. Так что прямо сейчас предлагаем немного замедлиться и оглянуться назад. Будет интересно узнать, совпадает ли наш топ-5 с публикациями, которые запомнились вам.

Какие рексис-тренды будут развивать в Яндексе в 2025 году

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

Исследователи Яндекса выложили в опенсорс Yambda — датасет на 5 млрд событий

Пост о Yambda — крупнейшем в мире датасете в области рекомендательных систем. Рассказали, зачем он нужен, какие у него ключевые особенности и какие методы оценки использовали наши исследователи. А ещё Александр Плошкин, один из авторов, представил работу на ACM RecSys ✨Такие моменты точно хочется вспомнить в завершение года.

TransAct V2: Lifelong User Action Sequence Modeling on Pinterest Recommendation

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

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

Одна из недавних публикаций Владимира Байкалова также вошла в число популярных. Это разбор совместной работы от Google DeepMind и YouTube, которая продолжает тему генеративных рекомендаций, начатую в предыдущей статье авторов — TIGER. На этот раз основная идея — использование предобученных больших языковых моделей в рекомендательных пайплайнах (в случае Google — это Gemini). За подробностями приглашаем в разбор.

Scaling Recommender Transformers to One Billion Parameters

В завершение подборки — ещё одна важная для нас работа. Инженеры из группы исследования перспективных рекомендательных технологий выложили на arXiv статью о подходе ARGUS, а в дальнейшем представят работу на конференции KDD’26. В статье описан опыт масштабирования рекомендательных трансформеров, вдохновлённый нашумевшей работой Actions Speak Louder than Words.

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

@RecSysChannel

GenSAR: Unified Generative Search and Recommendation

Fri, 26 Dec 2025 13:43:47 +0000

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
Разбор подготовили ❣ Михаил Сёмин и Никита Мирошниченко

LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders

Thu, 18 Dec 2025 08:26:32 +0000

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
Разбор подготовил ❣ Михаил Сёмин

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

Fri, 12 Dec 2025 08:46:14 +0000

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

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

Fri, 05 Dec 2025 07:34:01 +0000

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

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

Wed, 26 Nov 2025 09:12:01 +0000

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
Разбор подготовил ❣ Артём Матвеев

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

Thu, 20 Nov 2025 08:23:01 +0000

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
Разбор подготовил ❣ Сергей Макеев

CIKM’25 в разгаре: интересные статьи с третьего дня конференции

Thu, 13 Nov 2025 10:25:03 +0000

CIKM’25 в разгаре: интересные статьи с третьего дня конференции

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

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

В первой половине была одна запоминающаяся статья — DAS: Dual-Aligned Semantic IDs Empowered Industrial Recommender System. Авторы прямо во время обучения семантических ID замешивают коллаборативный сигнал. В дополнении раскладывали на семантики не только айтемы, но и пользователей — и применяли пользовательские ID в рекомендательной системе.

Во второй половине дня было три классных работы.

⚫️MPFormer: Adaptive Framework for Industrial Multi-Task Personalized Sequential Retriever

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

⚫️TBGRecall: A Generative Retrieval Model for E-commerce Recommendation Scenarios Taming Ultra-Long Behavior Sequence in Session-wise Generative Recommendation

⚫️Taming Ultra-Long Behavior Sequence in Session-wise Generative Recommendation

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

@RecSysChannel

CIKM’25: начинаем репортаж с конференции в Сеуле

Mon, 10 Nov 2025 13:30:39 +0000

CIKM’25: начинаем репортаж с конференции в Сеуле

В эти дни в Южной Корее проходит международная конференция CIKM 2025, на которую отправилась часть команды рекомендательных технологий Яндекса.

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

Так, в программе этого года заявлены доклады от Pinterest (TransAct V2, PinRec), Kuaishou (QARM, Pantheon) и Meituan (EGA-V1). С нетерпением ждём подробностей от наших инженеров.

Кроме туториалов и воркшопов, будет AnalytiCup 2025 — конкурсный трек с задачами по анализу данных. В этом году его проводят Alibaba International и FinVolution.

Впечатлениями от первого дня конференции поделился Николай Савушкин, руководитель службы рекомендательных технологий:

Отличное начало — сильные доклады от Pinterest и живое общение с участниками. В конце дня были интересные выступления от eBay и Google. От eBay докладывала русскоязычная исследовательница, пообщались после её презентации о ресёрче в компании. Основная программа стартует завтра.

Продолжим держать вас в курсе! А пока несём немного атмосферных фото из Сеула.

@RecSysChannel

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

Fri, 07 Nov 2025 11:51:48 +0000

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
Разбор подготовил ❣ Владимир Байкалов

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

Thu, 30 Oct 2025 09:17:01 +0000

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
Разбор подготовил ❣ Николай Савушкин

OnePiece: Bringing Context Engineering and Reasoning to Industrial Cascade Ranking System [2/2]

Thu, 23 Oct 2025 08:05:54 +0000

OnePiece: Bringing Context Engineering and Reasoning to Industrial Cascade Ranking System [2/2]

Продолжаем разбор техрепорта от Shopee. Так чем же интересен reasoning?

Авторы берут hidden state из последнего блока backbone, подают на вход в декодер с блочно-каузальным attention. По словам авторов, блоки позволяют учитывать больше информации о каждом токене.

Блоки в итоге учатся на разные таски:
— Retrieval: binary-cross-entropy loss (будет клик или не будет, добавят товар в корзину или нет, купят ли) и bidirectional contrastive learning (симметричный User to Item и Item to User).
— Ranking: вместо BCL используют set contrastive learning на успешных случаях, чтобы расширить границы положительных и отрицательных исходов.

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

Сделав вход модели более информативным, а также добавив многошаговый reasoning, авторы улучшили результаты работы модели. Внедрение нового фреймворка в основной сценарий персонализированного поиска помогло добиться +2% GMV/UU и +2,90% дохода от рекламы.

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

OnePiece: Bringing Context Engineering and Reasoning to Industrial Cascade Ranking System [1/2]

Tue, 21 Oct 2025 08:33:07 +0000

OnePiece: Bringing Context Engineering and Reasoning to Industrial Cascade Ranking System [1/2]

Сегодня разберём очередной техрепорт от Shopee — маркетплейса, популярного в Южной Америке и Азии. Авторы представляют новый фреймворк OnePiece, где адаптируют LLM и к retrieval, и к ранжированию.

Идеи, на которых основан подход, простые, но интересные:

— Structured context engineering: обогатить историю взаимодействия с пользователями.
— Block-wise latent reasoning. Авторы в некотором роде придумали, как прикрутить к рекомендательным системам reasoning от LLM.
— Progressive multi-task training: прогрессивно усложнять обучающие задачи для учёта фидбека.

По названию материала можно было бы подумать, что речь пойдёт про одностадийную модель, но нет. Как заведено в современных рекомендательных системах, стадии две: retrieval и ranking.

В основе модели — энкодер с трансформером. Размеры в статье не приводят, но по косвенным признакам, модель не очень большая.

Подробности можно рассмотреть на схеме. Начнём с retrieval. Вход стандартный: история взаимодействий, описание контекста через пользовательские фичи. Из интересного — preference anchors, которые помогают собрать топы товаров по количеству покупок, добавлению в корзину или кликов. Можно сказать, что это аналог RAG (от LLM) для рекомендашек.

Для стадии ранжирования — то же самое, плюс множество кандидатов, как в подходе с target-aware-трансформером.

Представление входов довольно стандартное. Товары описываются набором ID: название, магазин, категория. Запросы представлены мешком слов. Токены получаются с помощью MLP над конкатенацией эмбеддингов.

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

Backbone тоже стандартный и не стоит отдельного внимания. А вот reasoning интересный. Почему? Расскажем в следующем посте!

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

Kuaishou: обзор ключевых статей и техрепортов

Tue, 14 Oct 2025 09:31:56 +0000

Kuaishou: обзор ключевых статей и техрепортов

Собрали в карточках краткие описания семи больших работ Kuaishou, включая те, на основе которых вырос OneRec и его продолжения.

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

Ссылки на работы, упомянутые в посте:

— OneRec: Unifying Retrieve and Rank with Generative Recommender and Iterative Preference Alignment
— OneRec Technical Report
— OneRec-V2 Technical Report
— QARM: Quantitative Alignment Multi-Modal Recommendation at Kuaishou
— TWIN V2: Scaling Ultra-Long User Behavior Sequence Modeling for Enhanced CTR Prediction at Kuaishou
— Pantheon: Personalized Multi-objective Ensemble Sort via Iterative Pareto Policy Optimization
— OneLoc: Geo-Aware Generative Recommender Systems for Local Life Service

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

PinRec: Outcome-Conditioned, Multi-Token Generative Retrieval for Industry-Scale Recommendation Systems

Thu, 09 Oct 2025 08:33:00 +0000

PinRec: Outcome-Conditioned, Multi-Token Generative Retrieval for Industry-Scale Recommendation Systems

Сегодня разбираем статью от Pinterest о модели PinRec. В индустрии существуют два основных подхода к transformer-based retrieval. Первый — классическая двухбашенная схема: трансформер анализирует пользовательскую историю и сжимает её в эмбеддинг, с которым затем обращаемся к HNSW-индексу, построенному на айтемных эмбеддингах. Второй подход — появившиеся относительно недавно генеративные модели, в которых трансформер порождает непосредственно список айтемов, релевантных для данного юзера, например генерируя их в виде последовательностей семантических айдишников.

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

В базовой версии модель представляет собой трансформер с каузальной маской, авторегрессивно предсказывающий каждый следующий айтем, с которым провзаимодействовал пользователь, при условии его предыдущей истории. Учится модель на sampled softmax loss с logQ-коррекцией и mixed-negative sampling (используются in-batch и random-негативы). На инференсе предсказываем по истории пользователя эмбеддинг следующего айтема, дописываем его в сыром виде в конец истории и повторяем такой процесс несколько раз — в результате генерируем последовательность эмбеддингов и от каждого из них набираем ближайшие айтемы в HNSW-индексе.

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

Во-первых, авторы предлагают способ, при помощи которого можно обуславливать генерацию на желаемые действия пользователя — не прибегая к SFT и RL. При предсказании следующего айтема будем давать модели информацию о действии, совершенном юзером с этим айтемом. А именно, будем конкатить выход из трансформера, сжимающий предыдущую историю, с эмбеддингом действия и уже из этого конката предсказывать следующий айтем. Такая схема позволяет на инференсе подставить эмбеддинг нужного нам действия и предсказать наиболее вероятные айтемы при условии этого действия.

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

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

Авторы репортят, что описываемая ими модель внедрена как один из кандидатогенераторов в Pinterest на весь их внушительный industrial scale. При этом получены значимые приросты онлайн-метрик: на поверхности homefeed +0,28% fulfilled sessions, +0,55% timespent и +3,33% кликов.

Помимо архитектурных идей статья содержит интересные детали сервинга модели в продакшене (используется Triton Inference Server с Python-бэкендом). Также авторы сравнивают в своём сетапе трансформер с архитектурой HSTU (не в пользу последней), проводят эксперименты со скейлингом трансформера вплоть до миллиарда параметров и репортят, что добавление в модель таблицы id-based-эмбеддингов с 10 миллиардами параметров докидывает +14% к recall@10 поверх только контентных эмбеддингов.

@RecSysChannel
Разбор подготовил ❣ Сергей Лямаев

Подборка статей с RecSys 2025

Thu, 02 Oct 2025 09:04:46 +0000

Подборка статей с RecSys 2025

Делимся ещё несколькими работами, которые показались любопытными инженерам Яндекса. В сегодняшней подборке: диффузионки, которые генерируют целые плейлисты, борьба с cold start, обучение семантических ID на все задачи сразу и презентация с иллюстрациями из мультика «Холодное сердце».

Prompt-to-Slate: Diffusion Models for Prompt-Conditioned Slate Generation

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

Каждый объект каталога кодируется вектором-эмбеддингом. Слейт фиксированной длины представляют как конкатенацию этих векторов. Текстовый промпт кодируется трансформером и подаётся в Diffusion Transformer через cross-attention. Диффузионная часть пошагово «разшумляет» случайный вектор в латент слейта. Готовые латенты проецируются в ближайшие объекты каталога с фильтрацией дублей.

Такой подход даёт согласованность набора, стохастичность и разнообразие (несколько валидных слейтов для одного промпта). В экспериментах на музыкальных плейлистах и e-commerce-бандлах модель показала до +17% по NDCG и +6,8% взаимодействий в онлайне.

Not All Impressions Are Created Equal: Psychology-Informed Retention Optimization for Short-Form Video Recommendation

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

Semantic IDs for Joint Generative Search and Recommendation

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

Let it Go? Not Quite: Addressing Item Cold Start in Sequential Recommendations with Content-Based Initialization

Авторы сначала учат эмбеддинги документов только на контенте, а затем доучивают на ID, контролируя, чтобы норма изменения эмбеддинга оставалась малой. Говорят, это хорошо работает на «холодных» документах, и при этом на «горячих» качество почти не проседает. А ещё в презентации статьи были шикарные иллюстрации с героями из мультика «Холодное сердце».

@RecSysChannel
Статьи выбрали ❣ Александр Шуваев и Андрей Мищенко

Новые впечатления с RecSys 2025

Fri, 26 Sep 2025 12:05:33 +0000

Новые впечатления с RecSys 2025

Продолжаем смотреть на конференцию RecSys глазами инженеров Яндекса. Сегодня подсветим три интересные работы и вдохновляющий keynote от Xavier Amatriain.

Scaling Generative Recommendations with Context Parallelism
on Hierarchical Sequential Transducers

Авторы рассказали, как наращивают длину пользовательской истории при обучении HSTU-моделей. Оказалось, что использование истории длиной более 10 К событий всё ещё даёт прирост продуктовых метрик. Работа исключительно инженерная, но полезная для масштабирования используемых длин в истории.

Исследователи используют подход context parallelism: шардинг q/k/v по длине последовательностей в батче на P частей. При вычислении аттеншна ключи и значения нужно агрегировать со всех частей. Вместо стандартной схемы all-gather предлагают использовать all-to-all, чтобы пересылать только нужные блоки. Как итог, память под активации и KV-кэш на каждом GPU снизилась в ~1/P, а поддерживаемая длина истории выросла с 3 K до 16 K токенов.

RankGraph: Unified Heterogeneous Graph Learning for
Cross-Domain Recommendation

На конференции прозвучало несколько докладов о графовых нейросетях (GNN), но особенно выделился этот. В онлайновых A/B-тестах решение показало рост продуктовых метрик: +0,92% к кликам и +2,82% к конверсиям.

Для построения графа используются все доступные поверхности — лента, видео, рекламные объявления. Формируется единый гетерогенный граф, включающий пользователей и айтемы из разных доменов. Модель основана на RGCN (Relational Graph Convolutional Network) и обучается на contrastive-лоссы (triplet loss и InfoNCE). Для каждого отношения (типа ребра) агрегируются сообщения от соседей этого типа; затем результаты объединяются через «mixer» и обновляют представление узла.

Ключевой момент — сохранение самопетель (self-loop), чтобы прежнее представление узла также учитывалось при обновлении. Модель используется как для кандидат-генерации (user-to-item и item-to-item), так и как источник эмбеддингов пользователей и объектов, которые затем передаются в другие доменные модели в качестве фичей.

Scaling Retrieval for Web-Scale Recommenders: Lessons from Inverted Indexes to Embedding Search

LinkedIn поделились историей эволюции своей retrieval-системы. Начинали, как многие, с инвертированных индексов: решение быстрое и объяснимое, но требует ручного тюнинга (query expansion, переписывание запросов). Сверху добавили ML — learning to retrieve, графовые методы, атрибутные связи. Это помогало, но ограничения оставались: много ручной работы, оффлайн-билд индекса раз в неделю, больно интегрировать эмбеддинги.

Следующий шаг — embedding-based retrieval на ANN внутри старой системы. Но с такой архитектурой тяжело экспериментировать: квантование портило качество, CPU не тянуло, итерации шли медленно.

Решение — построить с нуля GPU retrieval-систему. Теперь это огромные sparse/dense матрицы в GPU-памяти без «костыльного» ANN. KNN считается честно и быстро, а терм-поиск и эмбеддинги можно гибко комбинировать. Внедрили множество оптимизаций: кастомные CUDA-кернелы, bfloat16, батчинг, шардирование по регионам.

Результаты: –75% инфраструктурных затрат и +30% к скорости экспериментов. В продакшене на кейсе job-matching это дало +4,6% к числу поданных заявок и +5,8% к budget utilization в промовакансиях.

Главный инсайт: inverted index хороши для классического поиска, но в современных ML-рексис они быстро достигают потолка. GPU-based EBR (Embedding-Based Retrieval) даёт гибкость и multi-objective-оптимизацию уже на этапе retrieval, а значит — приносит больше пользы для бизнеса.

Напоследок — впечатление от выступления Xavier Amatriain, посвящённого комплексному подходу к развитию рекомендательных систем:

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

@RecSysChannel
Заметки собрали ❣ Александр Шуваев, Влад Тыцкий, Артём Ваншулин

Продолжаем делиться работами с RecSys 2025

Thu, 25 Sep 2025 16:47:57 +0000

Продолжаем делиться работами с RecSys 2025

Второй день конференции запомнился нам не только выступлением Александра Плошкина с oral'ом о датасете Yambda, но и интересными статьями. Некоторые из них собрали в этом посте.

LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders

Авторы из ByteDance обучают модель в неавторегрессивном режиме на 10 000 событий, используя 10 000 GPU. Поскольку исследователи не связаны авторегрессивной схемой обучения (HSTU, Argus), они используют глобальные токены с эмбеддингом пользователя, счётчиками и т. п. Также применяется target-aware-подход: эмбеддинг целевого товара подаётся как глобальный токен.

В первом слое задействован cross-attention: в запросах (query) — глобальные токены и последние события, в ключах (key) — вся последовательность. Таким образом, последовательность сжимается до числа query-токенов на выходе слоя cross-attention. Далее идут стандартные слои self-attention с каузальной маской. Каузальная маска нужна, чтобы на инференсе переиспользовать KV-кэш.

Enhancing Embedding Representation Stability in Recommendation Systems with Semantic ID

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

Как решение предложен семантический ID, который создаётся на основе контента объявления (текста и картинок). В продакшене он генерируется из шести уровней иерархии (codebooks), из которых составляется префикс разной длины. Это позволяет похожим по смыслу объявлениям «обмениваться знаниями» и улучшает офлайн-метрики для новых айтемов и для хвоста распределения. Наибольший выигрыш виден в моделях, анализирующих историю взаимодействий пользователя.

Чтобы оценить влияние на стабильность, замеряют изменение скора модели при замене ID на его точную копию. В онлайне показано, что использование семантического ID снижает изменение скора на 43%. Итог: рост целевой метрики на 0,15%.

Generalized User Representations for Large-Scale Recommendations and Downstream Tasks

Интересный постер от Spotify. Авторы дообучают модели с дневным и даже более коротким интервалом. Для аудио и коллаборативных эмбеддингов используются одинаковые по размерности векторы — всего 80. При этом исследователи отмечают, что без стабилизации выходных эмбедов (как для аудио, так и для коллаборативных) система вообще не работала.

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

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

@RecSysChannel
Работами поделились ❣ Александр Шуваев, Пётр Зайдель, Даниил Бурлаков

Что обсуждают на RecSys 2025

Wed, 24 Sep 2025 15:15:01 +0000

Что обсуждают на RecSys 2025

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

Practical Bandits: An Industry Perspective
Этот доклад мы услышали на воркшопе CONSEQUENCES’25. Сначала спикеры разобрали различия между off-policy- и on-policy-стратегиями и подробно рассказали, что такое importance weighting, Inverse Propensity Scoring (IPS) и для чего они используются. А потом перешли к сбору данных:

— Показали методы сбора: ε-greedy, softmax и гибридный подход.
— Ввели effective sample size — оценку того, сколько данных нужно собрать.
— Уточнили, какие данные необходимо логировать: контекст, все возможные и выбранные действия, награду и распределение вероятностей.

После этого перешли к тому, что делать, если некоторые действия блокируются (например, из-за бизнес-логики) и как выявлять смещение с помощью control variates.

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

Gen AI for E-commerce
Докладов было много. Несколько спикеров поделились опытом того, как используют LLM в E-com: генерируют фичи для классического ML, пишут заголовки для e-mail-рассылок, создают поисковые саджесты, размечают данные для active learning, собирают системы из нескольких агентов, чтобы генерировать тексты, привлекающие пользователей.

Доклады интересные, где-то перекликаются с тем, что мы пробуем делать в Яндекс Go. Но ни в одном из выступлений не услышал, как применение LLM бустит метрики, связанные с деньгами — в лучшем случае менялись прокси-метрики.

Как я понял (и уточнил на стендах), самое популярное решение — не хостить LLM самим, а ходить в API готовых ИИ и платить за токены. Было весело, когда у докладчика, который рассказывал про LLM для active learning, спросили, сколько они потратили на OpenAI API — в выступлении упоминалось 1+ млн запросов.

Немного удивило, что существенная часть докладчиков не тестировала свои решения в A/B, только планирует сделать это в будущем.

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

@RecSysChannel
Суммаризировали для вас воркшопы ❣ Михаил Сёмин и Алексей Ельчанинов
Сгенерировал фото ❣ Андрей Мищенко

RecSys 2025: интересные статьи первого дня

Tue, 23 Sep 2025 09:01:01 +0000

RecSys 2025: интересные статьи первого дня

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

In-Context Learning for Addressing User Cold-Start in Sequential Movie Recommenders

Авторы из Amazon используют sequential models (модели, основанные на цепочке событий пользователя) для задачи рекомендации видео, так как такие модели дают лучшее качество. В своих подходах указывают Recformer, SASRec, GRU4Rec, Tiger, Liger. Однако подобные модели чувствительны к проблеме холодного старта. Когда у пользователя ещё нет никакой истории, что ему показать? По данным авторов, таких пользователей — большинство: 47%, а еще 46% — имеют длину истории до пяти событий.

В качестве решения исследователи предлагают добавить к реальной истории пользователя выдуманную LLM (imaginary interactions). Её получают с помощью специально подготовленного промпта. Причём утверждают, что не так страшно, если модель сгаллюцинирует и вернёт несуществующие фильмы, так как это не финальная последовательность. Затем происходит объединение выдуманной истории с реальной. В работе используют два подхода:

— early fusion — просто объединяют выдуманную историю с реальной (последняя — реальная), формируя одну длинную последовательность;
— late fusion — генерируют k последовательностей независимо, каждую продолжают реальной, а потом делают avg pooling над эмбедами.

В экспериментах авторы репортят два датасета: публичный the MovieLens 1M и проприетарный the Amazon Proprietary. Early fusion лучше себя показал на публичном датасете, причём бустит он именно «холодных» пользователей, тогда как на более «горячих» его влияние пропадает. А вот на проприетарном датасете лучше сработала late fusion. Это объясняют тем, что подход добавляет разнообразия выдаче.

Следующие шаги:
— из k произвольных фильмов заданного жанра предложить LLM выбрать подходящий;
— добавить RAG;
— собирать информацию для «холодных» пользователей путём опроса.

DenseRec: Revisiting Dense Content Embeddings for Sequential Transformer-based Recommendation

Основные идеи:
— SASRec хорошо работает, но плохо справляется с cold items. Надо поправить эту проблему (другие подходы, например, semantic IDs требуют сильного изменения всего пайплайна).
— Предлагается использовать контентные фичи. Но замена «в лоб» просаживает качество.
— Предлагается выучить модель, которая будет работать поверх всё той же embedding table по ID в части случаев, но также научиться переводить в это пространство контентные фичи.
— Формально при обучении подбрасывают монетку для каждой позиции в последовательности айтемов, с вероятностью p берут эмбед из таблицы эмбеддингов, с вероятностью (1-p) берут конктентные фичи и с помощью простой модели (в данном случае — линейной проекции) переводят контентные эмбеды в пространство обычных.
— При инференсе для знакомых ID всегда используют таблицу эмбедов, для новых — конкретные фичи и линейный слой проекции.
— В экспериментах на датасете Amazon авторы показывают значимое улучшение метрик, причём основной прирост — не на «холодных» документах. Авторы объясняют это тем, что подход обучения с использованием контентных фичей не только улучшает их представление (new items as target), но и улучшает качество самой последовательности (new items in the sequence).

@RecSysChannel
Статьи заметил ❣ Артём Ваншулин

Large Foundation Model for Ads Recommendation

Wed, 17 Sep 2025 12:12:20 +0000

Large Foundation Model for Ads Recommendation

Сегодня разбираем свежую статью Tencent с интригующим названием, содержащим слова large и foundation. Обращает на себя внимание и список авторов: он очень длинный, что обычно указывает на масштабный внутренний проект, важный для компании.

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

Авторы пишут, что обычно большие foundation-модели используют только user-представления, игнорируя другие важные сигналы. Предлагается перенести в downstream-модель все три вида: user-, item- и user-item-представления.

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

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

Архитектура Triple Tower

Для обучения используется так называемый triple tower design:
— user-башня,
— item-башня,
— mix-tower для их взаимодействия.

При этом архитектура разделена на две ветви (dual-branch design): одна обучается на органическом контенте (просмотры, лайки, комментарии), другая — на рекламных сэмплах (клики, конверсии). User- и item-вектора остаются общими, а cross-вектор извлекается только из рекламной ветви, так как он ближе к целевым downstream-задачам.

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

Простое добавление эмбеддингов в downstream-модель работает плохо: пробовали и линейные проекции, и alignment-лоссы, но улучшений не добились. Вместо этого применяют другой приём: каждую входную фичу комбинируют с представлением из foundation-модели с помощью покомпонентного умножения и нелинейности. Таким образом, user-item-вектор встраивается в модель уже на уровне входных признаков.

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

Валидацию делали только на внутренних данных Tencent: больших датасетах с рекламными и органическими действиями, онлайн-A/B-тестах. Авторы пишут что систему внедрили уже в десяти с лишним продуктах экосистемы и получили рост GMV на 2,45% по всей платформе.

Больше о внедрении фундаментальных моделей применительно к экосистеме Яндекса можно узнать в канале руководителя службы рекомендательных технологий Николая Савушкина — @light_from_black_box.

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

RecGPT Technical Report, 2/2

Mon, 08 Sep 2025 09:01:49 +0000

RecGPT Technical Report, 2/2

В первой части разбора рассказали об идее и результатах RecGPT. Теперь — детали реализации. Как мы уже упомянули, система состоит из четырёх ключевых компонентов.

User Interest Mining

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

Параллельно Alibaba разработали task alignment framework. Они сформулировали 16 задач — от простых (например, определить категорию товара по запросу) до более сложных (выделение ключевых характеристик, определение релевантности). LLM обучали постепенно, чтобы адаптировать её к специфике рекомендательного домена.

Вдобавок сделали self-training evolution: модели генерировали гипотезы, которые затем фильтровали, чтобы убрать галлюцинации или слишком общие интересы, и использовали отобранное для дообучения. В итоге система научилась извлекать из истории осмысленные интересы, а 98% пользователей теперь помещаются в лимит контекста и на каждого удаётся предсказать в среднем 16 интересов.

Tag Prediction

На основе предсказанных интересов следующая модель формирует так называемые теги — текстовые описания того, что пользователь, возможно, захочет купить. Это не конкретные товары, а их обобщённые характеристики: например, «outdoor waterproof hiking boots». К тегам есть требования: они должны опираться на историю и интересы пользователя, быть конкретными, свежими и релевантными сезону. В среднем нужно получить не меньше пятидесяти тегов.

Для обучения используют два шага. Сначала pre-alignment, когда из названий товаров в истории составляются кандидаты для тегов. Затем self-training: система дообучается на собственных же генерациях, но перед этим данные чистят и перебалансируюют. Это нужно, чтобы популярные категории не полностью доминировали и модель не теряла разнообразие. Такой подход оказался эффективным: вырос hit rate — совпадения между предсказанными тегами и реальными товарами, которые позже были куплены или просмотрены.

Item Retrieval

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

Personalized Explanation

Наконец, один из самых заметных элементов — генерация объяснений. Вместо того чтобы каждый раз формировать объяснение заново для пары «пользователь-товар», в Alibaba сделали ставку на связку «интерес-товар». Это экономит ресурсы и сохраняет персонализацию. Датасет для обучения объяснений собирали через другую LLM и фильтровали от галлюцинаций. Дополнительный self-training помог адаптировать модель к новым ситуациям. В итоге рекомендации сопровождаются короткими и понятными комментариями вроде «Мы показали вам этот товар, потому что вы недавно искали похожие вещи для путешествий».

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

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

RecGPT Technical Report, 1/2

Fri, 05 Sep 2025 09:06:11 +0000

RecGPT Technical Report, 1/2

Сегодня начинаем разбор недавнего техрепорта от Alibaba о новом подходе к рекомендациям RecGPT. В нём авторы предлагают по максимуму задействовать большие языковые модели.

Классические рекомендательные системы учатся в основном на логах кликов. Такой подход приводит к ряду ограничений: формируются «пузыри», когда пользователю постоянно показывают одно и то же; сложно работать с длинным хвостом товаров; возникают разные bias'ы (например, популярности). Но главное — при таком обучении теряется семантическая информация, а люди выбирают товары не только на основе кликов, а исходя из более сложных мотивов и контекстов.

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

Но и тут свои сложности:

— LLM нужно адаптировать к конкретному домену;
— важно укладываться в ограничения по времени отклика и вычислительным ресурсам;
— по-прежнему сложно интегрироваться в индустриальные системы.

Пайплайн RecGPT состоит из четырёх частей:

1. User Interest Mining — извлечение интересов пользователя из истории;
2. Tag Prediction — генерация тегов (описаний желаемых товаров);
3. Item Retrieval — сопоставление тегов с реальными товарами;
4. Personalized Explanation — генерация объяснений, почему система рекомендует этот товар.

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

RecGPT внедрили в сценарий Guess What You Like (беззапросные рекомендации на taobao.com). В результате получили рост CTR, просмотров страниц и доли активных пользователей, а ещё увеличили разнообразие по категориям. Улучшения заметили и мерчанты: товары стали лучше доходить до целевой аудитории.

Alibaba заявляют, что их решение — первый в мире успешный деплой reasoning-LLM в рекомендательную систему.

В следующей части — подробнее об архитектуре рексистемы.

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

Training Compute-Optimal Large Language Models

Thu, 28 Aug 2025 08:05:16 +0000

Training Compute-Optimal Large Language Models

Сегодня разберём статью 2022 года от DeepMind, известную также по названию модели Chinchilla. Работа посвящена проблеме правильного распределения фиксированного компьюта между увеличением размера модели и числа токенов, на которых она учится, в домене языковых моделей. Для связи этих трёх величин существует аппроксимация C = 6ND, где C — компьют, N — число параметров, D — число токенов в датасете. Оптимальные N и D масштабируются как C^a и C^b соответственно, где a + b = 1. Задача — найти a и b.

Работа мотивирована статьей 2020 года от OpenAI — Scaling Laws for Neural Language Models, в которой авторы заключили, что большая часть компьюта должна быть аллоцирована под масштабирование самой модели (a > b). Исследователи из DeepMind приходят к другому выводу. Они выводят законы масштабирования тремя разными способами, и все три приводят к схожим результатам (a ≈ b ≈ 0,5).

Подход первый: строят график в осях FLOPs — лосс для нескольких моделей с числом параметров от 75M до 10B. Каждому числу флопсов ставится в соответствие точка с минимальным лоссом, для которой известно, какому размеру модели и числу пройденных токенов она относится. Полученные точки переносят на графики в осях FLOPs — N и FLOPs — D, регрессируют их прямой (в прологарифмированных осях), угол наклона которой задаёт a и b. В итоге: a = b = 0,5.

Подход второй: фиксируют компьют и варьируют число параметров, что автоматически задаёт число токенов для обучения. Для каждого фиксированного компьюта находят такую точку, для которой уменьшение или увеличение числа параметров приводит к ухудшению финального лосса. Снова регрессируют эти точки в осях FLOPs — N и FLOPs — D, получая a = 0,49 и b = 0,51.

Подход тертий: здесь авторы моделируют зависимость L(N, D) финального лосса от размера модели и числа пройденных токенов, используя при этом все результаты (L_final, N, D) из первых двух подходов. Благодаря этому выражению, зная компьют, можно найти оптимальное число параметров, которое будет ординатой точки касания вертикальной прямой к линии уровня L(N, D) в осях FLOPs — N (левый график). a и b оказываются равными 0,46 и 0,54 соответственно.

Главный вывод статьи, — число параметров в модели и число токенов в датасете должны масштабироваться равномерно (то есть как квадратный корень из компьюта). Например, при увеличении компьюта в четыре раза обе величины должны вырасти в два раза.

Ещё один интересный вывод авторов — модель Gopher (280B) обучили на недостаточно большом датасете. В качестве доказательства обучают в четыре раза меньшую модель Chinchilla (70B) на в четыре раза большем числе токенов, и эта модель оказывается значительно лучше Gopher.

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

PinFM: Foundation Model for User Activity Sequences at a Billion-scale Visual Discovery Platform [2/2]

Mon, 25 Aug 2025 08:01:58 +0000

PinFM: Foundation Model for User Activity Sequences at a Billion-scale Visual Discovery Platform [2/2]

Продолжаем разбирать статью от Pinterest. Авторы не делятся внутренними параметрами модели, не уточняют, какого размера декодер и как всё обучалось. Однако они приводят масштабы всей системы — 20 миллиардов параметров. Судя по всему, большая часть этих параметров — матрица эмбеддингов. То есть модель в итоге получилась небольшой.

Отмечают, что в качестве энкодера выбрали архитектуру GPT2 и не увидели улучшений от применения HSTU-энкодера. Обучающую последовательность сформировали из 16 тысяч пользовательских взаимодействий, нарезав их на подпоследовательности длиной несколько сотен событий. Каждое событие кодируют обучаемыми эмбеддингами пина, поверхности и типа взаимодействия, итоговый токен события — сумма этих трёх эмбеддингов. Напоминает то, как формируются токены в Argus: де-факто есть те же context, item и action, но в весьма ограниченном варианте.

В остальном архитектура вышла стандартной. Но вот решаемую задачу авторы определяют весьма интересно. В качестве таргетов берут только позитивные события (при этом последовательность формируется с включением негативов), делают это с помощью Sampled Softmax (почему-то без LogQ-коррекции). В этом сетапе на стадии претрейна предсказывают:

– следующий позитивный токен;
– следующие позитивные токены в некотором временном окне;
– позитивные события, но во временном окне downstream-ранжирующей модели.

Получившийся лосс суммируют.

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

Команда Pinterest в очередной раз демонстрирует крутые инфраструктурные решения для жизнеспособность всей системы. В частности, эффективная дедупликация последовательности увеличила на 600% пропускную способность модели по сравнению с FlashAttention-2. Для оптимизации гигантской таблицы эмбеддингов применили агрессивную int4-квантизацию практически без потери качества.

В результате получилась сильная модель, хорошо агрегирующая знание о пользователях. Это отражается в результатах A/B-тестирования: на рекомендательной ленте на главной удалось добиться роста числа сохранений пинов на 2,6%, а для свежих пинов — на 5,7%.

@RecSysChannel
Разбор подготовил ❣ Руслан Кулиев

PinFM: Foundation Model for User Activity Sequences at a Billion-scale Visual Discovery Platform [1/2]

Fri, 22 Aug 2025 08:03:35 +0000

PinFM: Foundation Model for User Activity Sequences at a Billion-scale Visual Discovery Platform [1/2]

Сегодня разбираем свежую статью от Pinterest, которую недавно приняли на RecSys 2025.

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

Foundation-модели и большие претрейны уже давно хорошо зарекомендовали себя и в NLP, и в CV. Если дообучить для своих задач готовую GPT-подобную модель, которая многое знает о мире, результат вас вряд ли разочарует. К тому же, дообучение сильно дешевле обучения с нуля и быстрее дистилляции.

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

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

1. Косты. Большая модель не зря большая: инферить её дорого и долго.

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

3. Постоянное пополнение набора айтемов. Пользователи регулярно загружают в Pinterest новый контент: нужно научить модель адекватно оперировать незнакомыми, только что добавленными объектами.

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

@RecSysChannel
Разбор подготовил ❣ Руслан Кулиев

Top-K Off-Policy Correction for a REINFORCE Recommender System

Mon, 18 Aug 2025 07:02:44 +0000

Top-K Off-Policy Correction for a REINFORCE Recommender System

Reinforcement Learning — подход, который логично применять для рекомендаций. При этом работ об использовании RL-алгоритмов в этой области не так много. Сегодня разберём статью 2019 года с конференции WSDM’19, которая посвящена этой теме. В работе описано одно из первых успешных применений RL в рекомендательных системах, внедренное в YouTube на миллионы пользователей и многомиллионные каталоги видео.

Как RecSys сформулировать в терминах RL

Взаимодействие пользователя можно смоделировать как марковский процесс принятия решений:
— состояние — контекст взаимодействия и история пользователя;
— действие — рекомендуемый кандидат (видео и т. п.);
— награда — полезность показа (клик, лайк, время просмотра).
Политика π(a|s) выбирает кандидатов так, чтобы максимизировать долгосрочную полезность.

Дизайн награды

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

r = α·1_click + β·log(1 + watch_sec)

REINFORCE

Политику π(a|s) моделируют в виде параметрической функции от состояния (истории пользователя), которая выдаёт распределение на действиях. В качестве модели берут рекуррентную нейронную сеть. Политику обучают с помощью алгоритма REINFORCE. Это on-policy-алгоритм, поэтому обновление весов корректно только на данных, собранных текущей политикой. Поскольку это требует сложной инфраструктуры, обучение проводят на залогированных данных.

Off-policy correction

Залогированные данные получены от предыдущей версии рекомендательной системы β(a|s), которую авторы называют поведенческой политикой. Это приводит к смещению в оценке градиента. Чтобы компенсировать смещение, используют Importance Sampling. Для моделирования β(a|s) применяют ту же архитектуру, что и для π(a|s), но обучают только на логах и не пропускают градиенты этой «головы» в общий backbone модели. Для обеих политик при обучении используется Sampled Softmax.

Top-K correction

На YouTube показывают сразу K элементов на одной странице, то есть политика подбирает не одного кандидата, а набор. Делается предположение, что каждый из K элементов сэмплируется независимо из π(a|s), поэтому от вероятности π(a|s) переходят к вероятности попадания на страницу:

α(a|s) = 1 − (1 − π(a|s))^K

Online A/B-тест

Полученную политику π(a|s) использовали как один из кандидатогенераторов основного алгоритма рекомендаций YouTube. Применение off-policy correction увеличило число просмотренных видео примерно на +0,5%. Добавление Top-K correction увеличило общее время просмотра видео на +0,8–0,9%.

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

Что интересного показали на конференции KDD 2025

Thu, 14 Aug 2025 11:56:40 +0000

Что интересного показали на конференции KDD 2025

В Торонто прошла конференция KDD 2025, посвященная поиску знаний и анализу данных. На мероприятии, как водится, представили немало интересных публикаций. А мы, как водится, выбрали самые любопытные из них.

TAT: Temporal-Aligned Transformer for Multi-Horizon Peak Demand Forecasting

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

Automated Query-Product Relevance Labeling using Large Language Models for E-commerce Search

Статья Walmart о том, как инженеры сделали фреймворк для авторазметки соответствия товара запросу. Утверждают, что работает лучше ручной разметки (асессорам пора искать работу).

DV365: Extremely Long User History Modeling at Instagram*

Крутая статья Meta* — возможно, самая революционная в прикладном плане. Инженеры компании сделали офлайн-профиль пользователя размером в среднем 40к, так как масштабировать HSTU дальше сложно и дорого. Жертвуют свежестью данных и делают ставку на стабильные интересы пользователей. Получили +0,7% таймспента от внедрения эмбедда в использующих его моделях.

Mini-Game Lifetime Value Prediction in WeChat

Статья WeChat о предсказании LTV в играх. В основе graph representation learning, а также используют интересный подход к zero-inflated lognormal distribution modeling.

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

Интересное увидел ❣ Сергей Мить

@RecSysChannel

Blending Sequential Embeddings, Graphs, and Engineered Features: 4th Place Solution in RecSys Challenge 2025

Tue, 12 Aug 2025 09:10:01 +0000

Blending Sequential Embeddings, Graphs, and Engineered Features: 4th Place Solution in RecSys Challenge 2025

Сегодня рассказываем о статье, в которой описано решение от команды исследователей из Яндекса, получившее в этом году четвёртое место на конкурсе RecSys Challenge. Статью также приняли на конференцию RecSys 2025.

Челлендж был посвящён области e-commerce. В этом направлении рекомендательные модели обучают предсказывать разные виды сигналов: конверсии, релевантные товары и их категории, сумму, которую потратит клиент, и многое другое. Целью челленджа было обучить эмбеддинг пользователя, который объединил бы разнородные сигналы. Затем организаторы использовали этот эмбеддинг, чтобы обучить независимые модели под шесть разных задач, вроде тех, что описаны выше.

Как видно на картинке, для построения такого эмбеддинга предлагается сконкатенировать векторы от четырёх моделей: трансформера, выбор которого мотивирован подходом ARGUS, графовой нейросети TwHIN, DCN-v2-эмбеддингов и стандартизованных счётчиков.

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

Трансформер в генеративной постановке учился предсказывать тип следующего взаимодействия, время до него, следующую посещённую страницу, а также следующий товар. DCN-v2-модель училась поверх эмбеддинга из трансформера и множества счётчиков, прошедших через кусочно-линейное кодирование, предсказывать отток клиентов, а также актуальные товары и категории, с которыми провзаимодействует пользователь. Графовая модель TwHIN обучалась предсказывать связи (добавления в корзину и покупки) между пользователем и товаром. Счётчики считались по разным временным промежуткам, тематическим кластерам и ценовым сегментам, а для учёта временных зависимостей использовалось экспоненциальное взвешивание. Подробный разбор всех счётчиков доступен в приложении к статье.

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

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

Scaling Recommender Transformers to One Billion Parameters

Fri, 25 Jul 2025 10:15:13 +0000

Scaling Recommender Transformers to One Billion Parameters

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

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

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

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

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

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

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

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

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

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

@RecSysChannel

Как прошла ICLR 2025: впечатления инженеров Яндекса

Tue, 15 Jul 2025 09:23:49 +0000

Как прошла ICLR 2025: впечатления инженеров Яндекса

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

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

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

@RecSysChannel

#YaICLR

TransAct V2: Lifelong User Action Sequence Modeling on Pinterest Recommendation

Fri, 11 Jul 2025 08:01:54 +0000

TransAct V2: Lifelong User Action Sequence Modeling on Pinterest Recommendation

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

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

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

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

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

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

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

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

@RecSysChannel
Разбор подготовил ❣ Руслан Кулиев

Post #120

Fri, 04 Jul 2025 16:45:06 +0000

Мы с отличными новостями! Статью о датасете Yambda приняли на Oral конференции RecSys 2025. Поздравляем команду рекоменд

Fri, 04 Jul 2025 16:45:06 +0000

Мы с отличными новостями! Статью о датасете Yambda приняли на Oral конференции RecSys 2025. Поздравляем команду рекомендательных технологий Яндекса!

Scaling Transformers for Discriminative Recommendation via Generative Pretraining

Thu, 03 Jul 2025 08:04:03 +0000

Scaling Transformers for Discriminative Recommendation via Generative Pretraining

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замечания

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

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

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

Preference Diffusion и Decoupled Embeddings: две статьи о масштабируемых рекомендациях

Mon, 30 Jun 2025 08:04:13 +0000

Preference Diffusion и Decoupled Embeddings: две статьи о масштабируемых рекомендациях

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

Preference Diffusion for Recommendation

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

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

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

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

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

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

Long-Sequence Recommendation Models Need Decoupled Embeddings

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

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

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

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

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

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

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

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

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

#YaICLR

Scaling law в рекомендательных системах

Thu, 26 Jun 2025 12:20:16 +0000

Scaling law в рекомендательных системах

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

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

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

Рекомендательная [RecSys Channel]

Generative Recommendation for Large-Scale Advertising

QARM V2: Quantitative Alignment Multi-Modal Recommendation for Reasoning User Sequence Modeling

Efficient Sequential Recommendation for Long Term User Interest Via Personalization

Айсберг KV-кэшей, или Как эффективно считать трансформеры

RankMixer: Scaling Up Ranking Models in Industrial Recommenders

SilverTorch: A Unified Model-based System to Democratize Large-Scale Recommendation on GPUs

OpenOneRec Technical Report

Massive Memorization with Hundreds of Trillions of Parameters for Sequential Transducer Generative Recommenders

OneRec-Think: In-Text Reasoning for Generative Recommendation

KVzap: Fast, Adaptive, and Faithful KV Cache Pruning

Orthogonal Low Rank Embedding Stabilization

Какие статьи 2025 года перечитывают эксперты Рекомендательной. Часть 2

Какие статьи 2025 года перечитывают эксперты Рекомендательной. Часть 1

🎉Подводим итоги: лучшее за год в Рекомендательной

GenSAR: Unified Generative Search and Recommendation

LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders

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

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

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

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

CIKM’25 в разгаре: интересные статьи с третьего дня конференции

CIKM’25: начинаем репортаж с конференции в Сеуле

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

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

OnePiece: Bringing Context Engineering and Reasoning to Industrial Cascade Ranking System [2/2]

OnePiece: Bringing Context Engineering and Reasoning to Industrial Cascade Ranking System [1/2]

Kuaishou: обзор ключевых статей и техрепортов

PinRec: Outcome-Conditioned, Multi-Token Generative Retrieval for Industry-Scale Recommendation Systems

Подборка статей с RecSys 2025

Новые впечатления с RecSys 2025

Продолжаем делиться работами с RecSys 2025

Что обсуждают на RecSys 2025

RecSys 2025: интересные статьи первого дня

Large Foundation Model for Ads Recommendation

RecGPT Technical Report, 2/2

RecGPT Technical Report, 1/2

Training Compute-Optimal Large Language Models

PinFM: Foundation Model for User Activity Sequences at a Billion-scale Visual Discovery Platform [2/2]

PinFM: Foundation Model for User Activity Sequences at a Billion-scale Visual Discovery Platform [1/2]

Top-K Off-Policy Correction for a REINFORCE Recommender System

Что интересного показали на конференции KDD 2025

Blending Sequential Embeddings, Graphs, and Engineered Features: 4th Place Solution in RecSys Challenge 2025

Scaling Recommender Transformers to One Billion Parameters

Как прошла ICLR 2025: впечатления инженеров Яндекса

TransAct V2: Lifelong User Action Sequence Modeling on Pinterest Recommendation

Post #120

Мы с отличными новостями! Статью о датасете Yambda приняли на Oral конференции RecSys 2025. Поздравляем команду рекоменд

Scaling Transformers for Discriminative Recommendation via Generative Pretraining

Preference Diffusion и Decoupled Embeddings: две статьи о масштабируемых рекомендациях

Scaling law в рекомендательных системах