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
Разбор подготовила ❣ Дарья Тихонович

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
Обзор подготовила ❣ Маргарита Мишустина

Что читает команда алайнмента рекомендательных моделей

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

Progressive Semantic Residual Quantization for Multimodal-Joint
Interest Modeling in Music Recommendation

В работе предлагают по-новому учитывать мультимодальные интересы пользователей.

Главная проблема предыдущих методов — при сжатии фичей трека в компактные семантические ID смысл музыки постепенно теряется. Её назвали intra-modal semantic degradation: чем больше кодбуков, тем больше семантические ID отражают мелкие технические детали вместо реального содержания трека.

Вторая проблема — inter-modal modeling gaps: старые модели либо «склеивали» все модальности (текст, аудио) в один вектор, теряя нюансы, либо, наоборот, обрабатывали их изолированно, не улавливая синергию между грустным текстом и мажорной мелодией.

Решение состоит из двух этапов:

1) Progressive Semantic Residual Quantization (PSRQ). В отличие от обычного RQ, который на каждом новом слое квантует лишь ошибку с предыдущего шага, PSRQ всегда «помнит» оригинал. Начиная со второго кодбука он смотрит не только на текущий остаток, но и на то, какая часть исходного эмбеддинга уже была закодирована, и конкатенирует такие векторы с остатками. Благодаря этому семантические ID на всех уровнях сохраняют связь с реальным смыслом трека.

2) Multi-Codebook Cross-Attention (MCCA). Авторы ввели отдельные кодбуки для аудио и текста, а также для совместного представления (modal-joint). Предпочтения пользователя моделируется через кросс-аттеншн, где в качестве query выступает modal-joint эмбеддинг таргета. Это позволяет одновременно улавливать и нюансы предпочтений по отдельным модальностям, и их корреляции («как текст трека работает в связке с битом»).

Фреймворк не только бьёт SOTA на офлайн-бенчмарках, но и в реальном A/B-тесте на крупной стриминговой платформе даёт значимый прирост в добавлении треков в избранное и количестве прослушиваний треков до конца.

SIGMA: A Semantic-Grounded Instruction-Driven Generative Multi-Task Recommender at AliExpress

AliExpress рассказывает о своей генеративной рекомендательной системе на базе LLM. Ключевое нововведение — многоуровневое семантическое выравнивание, при котором система объединяет текстовую семантику, визуальные признаки, общие знания и коллаборативные сигналы в едином латентном пространстве.

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

Подход показывает значительные приросты в A/B-тесте: +7,84% GMV, +3,84% конверсии.

Masked Diffusion for Generative Recommendation

Статья продолжает линию исследований генеративных рекомендаций, где предсказание следующего айтема формулируется как генерация последовательности дискретных семантических токенов. Авторы предлагают отказаться от схемы «остаточная квантизация + авторегрессивная генерация» в пользу независимой токенизации через параллельные кодбуки и генерации через masked diffusion.

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

По скорости инференса выигрыш достигается за счёт параллельного декодирования: после короткой фазы прогрева, где модель по одному закрепляет самые уверенные семантические якоря, она переключается в параллельный режим и заполняет несколько позиций SID за один шаг, сокращая число forward pass'ов.

@RecSysChannel
Статьями поделились ❣ Вероника Иванова, Иван Артемьев и Илья Мурзин

Masked Diffusion Generative Recommendation

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

Сначала в работе перечисляют ограничения авторегрессивного подхода:

1) Нужно укладывать информацию об айтеме в строгую иерархию семантических ID, и это навязывает модели дополнительный inductive bias.
2) Генерация всегда идёт в фиксированном порядке, независимо от истории пользователя.
3) Эффективность на инференсе низкая, так как модель нужно прогонять по каждому семантическому токену.

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

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

Но появляется вопрос, как использовать диффузионку в качестве кандидата-генератора. Она умеет расшумлять все токены сразу, но непонятно, как получить несколько объектов. Поэтому вводят гибридную схему с элементами beam search. Модель фиксирует самые уверенные токены и дальше — по следующим по уверенности семантикам — отбираются кандидаты.

Чтобы заалайнить диффузию под рекомендательный домен, вводят history-aware masking allocation strategy. В отличие от равномерного маскирования учитывается, что семантические токены разные по сложности. Поэтому чаще маскируются те, которые реже встречались в истории пользователя, — такие семантики для модели сложнее предсказать. То есть задачу обучения дополнительно усложняют и за счёт этого получают прирост качества по сравнению с равномерным маскированием.

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

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

Количество варм-ап-шагов и ширина beam search влияют на качество и скорость инференса. Если делать слишком мало шагов, качество падает, потому что семантики хуже обусловлены друг на друга. Если делать больше шагов, качество растёт, но при этом теряется выигрыш в скорости.

На офлайн-датасетах Amazon Books и Electronics модель показывает SOTA среди item- и semantic-based-подходов. При этом она достаточно небольшая модель: шестислойный трансформер с hidden size порядка 256. На онлайн-тестах репортят рост GMV и CTR.

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

A Unified Language Model for Large Scale Search, Recommendation, and Reasoning

В сегодняшней статье Spotify представляют NEO — унифицированную модель decoder-only, которая работает с гетерогенными данными (текст и рекомендательные объекты). При этом она должна удовлетворять жёстким требованиям к качеству выдачи и латентности.

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

В статье обращают внимание на то, что существующие подходы не умеют одновременно рассуждать над доменными объектами, пользовательским поведением и естественным языком. Вдохновляясь мультимодальными архитектурами, авторы NEO решают эту проблему, интерпретируя Semantic ID объектов как отдельную модальность наравне с текстовыми токенами. Обучение ведут на смешанных данных, где в текстовые последовательности подмешивают идентификаторы рекомендательных объектов.

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

1. Создание семантических представлений (Semantic ID creation). Формируется база соответствий «объект — Semantic ID», которая задаёт словарь доменных токенов. То есть в дальнейшем модель сможет ссылаться на конкретные объекты.

2. Формирование знаний о домене (Domain Grounding). Модель учится воспринимать Semantic ID наравне с текстовыми токенами, выстраивая единое представление для обоих типов данных. Цель — научить модель воспринимать доменные токены как полноценную часть языка: понимать контекст вокруг них, связывать их с текстовыми описаниями и выстраивать единое семантическое пространство для обеих модальностей.

3. Формирование навыков через инструкции (Capability Induction via Instruction Tuning). Модель дообучается на конкретных задачах: next item prediction, ретривал по текстовым запросам, описание интересов пользователя, обоснование рекомендаций.

Чтобы показать, что фреймворк не привязан к конкретной архитектуре, авторы провели адаптацию Llama 3.2 1B с использованием NEO. Стадия Domain Grounding дала прирост около 18% в текстовом ретривале, что подтверждает эффективность подхода.

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

Особенно это заметно на задачах, требующих строгого следования инструкциям, и при генерации последовательностей смешанной структуры (текст + рекомендательные объекты). В офлайн-экспериментах NEO демонстрирует небольшой, но стабильный прирост над базовыми моделями в монозадачах по метрикам HR@K и NDCG@K.

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

Kunlun: Establishing Scaling Laws for Massive‑Scale Recommendation Systems [1/2]

Сегодня приступаем к разбору статьи, в которой Meta* обращает внимание на вопросы масштабирования моделей и эффективного использования GPU для задач рекомендательных систем. Начнём с предпосылок и овервью.

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

При попытке масштабировать подобные модели возникают два главных боттлнека:

1) неэффективные блоки в моделях, которые утилизируют только 3-15% вычислительных возможностей GPU (Model FLOPs Utilization, MFU) в сравнении с 40-60% для LLM;

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

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

В основе архитектуры Kunlun лежат три основные работы (хотя авторы указывают в числе референсов больше статей):

- Wukong — предлагает способ взаимодействия высокого порядка между контекстными фичами, но не работает с последовательностями;
- HSTU — хорошо работает с последовательностями, но почти не умеет с контекстом;
- Interformer — предыдущая попытка объединить контекстные фичи и последовательности, которая оказалась не очень эффективной на GPU.

Дальше — подробнее об архитектуре и масштабировании.

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

Accelerating Generative Recommendation via Simple Categorical User Sequence Compression

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

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

- айтемы из longterm-истории бьются на бакеты по категориальному признаку, recent-история подаётся в модель полностью;
- берётся максимум V бакетов по последнему таймстемпу айтема внутри;
- внутри бакетов берётся максимум G айтемов, также отсортированных по таймстемпу;
- каждый эмбед айтема внутри бакета пропускают через MLP-проектор, затем их усредняют по размерности бакета и складывают с обучаемым эмбедом бакета;
- дополнительно в начало последовательности ставят аналог CLS-токена, причём все сегменты отделены друг от друга SEP-токенами.

Для задачи next item prediction используют InfoNCE, а для action prediction — cross-entropy loss.

Авторы выбрали датасеты KuaiRand-27K (логи интеракций с короткими видео) и MovieLens-20M (классика рекомендательных датасетов).

Эксперименты проводят на модели HSTU (3 слоя, hidden size 64, 8 attention heads), в качестве метрик берут NDCG@k и MRR, а бейзлайны — стандартный HSTU и подход GenRank, который агрегирует item и action. В результате подход даёт наилучшие метрики даже в сравнении с сетапами с более длинными последовательностями юзеров с ускорением до 6x на инференсе и до 4x на обучении.

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

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

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

RecIS: Sparse to Dense, A Unified Training Framework for Recommendation Models

Сегодня разберём работу Alibaba под названием RecIS (Recommendation Intelligence System). Это фреймворк для обучения рекомендательных систем, который нужен, чтобы масштабировать «всё и вся» в разных контекстах, оставаясь при этом PyTorch-френдли и пригодными для продакшена.

В рексистемах есть два разных типа нагрузки. В sparse-части, связанной с эмбеддингами, мало вычислений, но много обращений к памяти. В dense-части, наоборот, много вычислений и меньше работы с памятью. В рексистемах по сравнению с другими областями (NLP, CV) ощутимо больше sparse-нагрузки, поэтому оптимизации касаются именно этой части.

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

Авторы вводят метрику MBU — максимальная утилизация пропускной способности. Опираются на идею roofline-модели, где оценивается баланс между вычислениями и доступом к памяти. В классическом варианте по горизонтали откладывают число операций на загруженный байт, а по вертикали — количество FLOPs, которые модель может утилизровать.

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

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

На форварде каждая GPU определяет, какие эмбеддинги ей нужны с других устройств, после происходит all-to-all-коммуникация, и карты обмениваются нужной информацией. Затем каждая GPU читает свои эмбеддинги и отправляет их туда, где они нужны.

На бэкварде происходит то же самое: каждая GPU знает, куда нужно записать градиенты, и они пересылаются напрямую в соответствующие шарды. В итоге всё укладывается в две all-to-all-коммуникации, а таблица занимает меньше памяти на каждой видеокарте.

Также делают оптимизации. Есть стандартные вещи, такие как mixed precision, FlashAttention, ZeRO, fused softmax и cross-entropy. Есть специфичные для рекомендаций. Например, если у нескольких embedding-таблиц одинаковая размерность, их объединяют в одну, чтобы оптимизировать доступ к памяти.

Данные хранят в колоночном формате, для sparse-структур используют CSR.

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

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

Эксперименты проводят на двух моделях: MSE (предсказание вероятности клика) и LMA (предсказание следующего баннера по истории). По времени обучения RecIS работает быстрее, чем TensorFlow и PyTorch. По метрике MBU тоже более высокая утилизация пропускной способности.

При этом упоминают и проблемы:
- загрузка данных из сети может занимать много времени (сэмплы до ~6GB);
- embedding-таблицы остаются очень большими, в том числе из-за старых объектов;
- в старых фреймворках вроде TensorFlow 1.x есть ограничения на размер тензоров.

В конце авторы делают вывод, что в современных multi-GPU-системах памяти обычно достаточно. И это позволяет сместить баланс: делать больше операций с памятью и меньше вычислений.

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

MTGR: Industrial-Scale Generative Recommendation Framework in Meituan

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

Авторы выделяют две проблемы:

1. В классических моделях Deep Learning Recommendation (DLRM) вычислительная сложность и инференс масштабируются линейно по числу кандидатов. Если хотим сделать модель тяжелее, втиснуть её в прод становится невозможно по latency.

2. Generative Recommendation Model (GRM) решает проблему масштабирования. Но чтобы это работало, приходится отказываться от кросс-фичей. Авторы показывают, что их удаление настолько просаживает качество, что никакое увеличение параметров это не компенсирует.

Чтобы обойти ограничения, пробуют токенизировать все входные признаки:

- Профиль пользователя (U) — набор токенов, где каждая фича — отдельный токен.
- Историю делят на долгосрочную (S) и краткосрочную (R). Её токенизируют на уровне событий: эмбеддинги фич одного события конкатенируются и прогоняются через MLP.
- Кандидатов (C) токенизируют аналогично, но в них замешивают важные кросс-признаки.

Затем идёт агрегация: вместо обработки пар «пользователь-кандидат» по отдельности, все кандидаты юзера объединяются в один пример. Полученные токены образуют последовательность U → S → R → C. За один forward-pass модель оценивает сразу всех кандидатов, давая сублинейное масштабирование.

Токены подают в модифицированный трансформер HSTU со следующими внедрениями:

- Group-Layer Normalization (GLN). Так как токены имеют разную семантику, нормализация делается независимо для каждой группы (U, S, R, C).
- Dynamic Masking. Кастомная маска защищает от утечки данных. Пользователь и долгая история (U+S) видны всем. Краткосрочная (R) — подчиняется каузальности. Кандидаты (C) видят только предшествующую часть R и не видят других кандидатов.

Над токенами кандидатов на выходе строится MLP для предсказания CTR и CVR.

Авторы применили оптимизации, которые увеличили пропускную способность в 1,6–2,4 раза в сравнении с TorchRec. Также им удалось получить x65 FLOPs на один пример без увеличения затрат на обучение в сравнении с DLRM.

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

Размер батчей сделали динамическим. Семплы с длинной историей объединяются в батчи с меньшим числом семплов. Семплы с короткой историей — в батчи с большим числом семплов. Это даёт примерно одинаковую вычислительную нагрузку на все GPU.

Обучение проводили в bf16 mixed precision с префетчингом. Его разбивали на три потока: copy (загрузка данных), dispatch (lookup эмбеддингов), compute (forward/backward), что позволило перекрывать I/O-операции с вычислениями.

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

Для обучения использовали внутренние логи Meituan, так как открытые датасеты слишком маленькие и в них нет нужных кросс-фичей. В качестве бейзлайнов взяли передовые DLRM-архитектуры: Wukong, UserTower, DNN, MoE, MultiEmbed. Качество оценивали по AUC и GAUC.

По сравнению с лучшим бейзлайном (UserTower-SIM) офлайн-метрики (CTR/CTCVR, AUC/GAUC) улучшились на 0,5–1,5%.

Проверка показала, что все компоненты архитектуры критичны. Отсутствие кросс-фичей просаживает качество сильнее всего — без них MTGR сразу проигрывает старым бейзлайнам. GroupLN и Dynamic Masking также дают значимый прирост в качестве.

Авторы продемонстрировали линейный прирост качества (CTCVR GAUC) от log(flops). Отдельно показали, что модель масштабируется по всем осям: можно наращивать как число слоёв, так и скрытую размерность или длину истории.

В онлайн-эксперименте MTGR даёт +1,9% CTR и +1,02% CTCVR в сравнении с лучшим DLRM-бейзлайном.

@RecSysChannel
Разбор подготовил ❣ Влад Аверков

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

В рекомендациях для разных поверхностей, доменов и таргетов часто обучают отдельные модели. Но такой подход плохо масштабируется и усложняет поддержку системы. Чтобы решить проблему, авторы Meta Lattice построили фундаментальную модель, сочетающую разные органические и рекламные поверхности Meta*.

Основной вклад статьи в том, что в ней собран большой набор инженерных «рецептов» для такого объединения. Разбирают, как совмещать конверсии с разными окнами атрибуции, отбирать фичи, стабилизировать мультидоменное обучение, делать дистилляцию, включая inference-time-дистилляцию.

Ещё в работе предлагают несколько неочевидных и при этом работающих идей:

- correlation-based loss для смешивания таргетов из разных доменов — решение простое и, судя по статье, эффективное. Это элемент, который позволяет обучать модель для разных поверхностей и одновременно бустить качество на них;

- inference-time distillation — подстановка эмбеддингов учителя в ученика в момент запроса. Технологически это означает, что нужно поддерживать near-realtime-контур с инференсом модели-учителя и кеш эмбеддингов на недавних запросах (не путать с KV-cache);

- совместная модель для pCTR и pCVR — очевидное сокращение компьюта.

В Meta Lattice вводят понятие портфеля — пары поверхности и таргета. Портфели объединяются между доменами с достаточным перекрытием пользователей и одинаковым типом таргетов (моментальные или отложенные). Для каждого объединённого портфеля обучается и деплоится одна модель на общем датасете со всеми таргетами.

Как всё работет в общих чертах:

- Lattice Partitioner — объединяет портфели по перекрытию user_id и схожему типу таргетов.

- Lattice Zipper — объединяет разные окна атрибуции; все они смешиваются в один датасет, для каждого клика случайно выбирается одно окно, а в модели обучают отдельные головы под каждое окно атрибуции. На инференсе используют oracle-head с самым длинным окном.

- Lattice Filter — фильтрует фичи через permutation feature importance и отбор по Парето-фронтам.

- Lattice Models — архитектура на базе DenseNet-like блоков, DHEN/Wukong для feature interaction и трансформера для последовательностей. Используются domain-specific FFN, QK-norm и дополнительный correlation-based loss для multi-domain multi-target обучения.

- Lattice Sketch — подбирает гиперпараметры модели и стратегию FSDP-шардирования с ограничениями по latency и quality.

- Lattice KTAP — inference-time-дистилляция + обычная knowledge-дистилляция: teacher embeddings, soft targets, label smoothing и feature clipping.

Используют два датасета: KuaiVideo (13 млн событий для like/follow/click prediction) и production-scale-датасет Meta на 100 млрд событий для CTR/CVR prediction с ~2 тысячами рекламных фичей.

Обучение идёт на общем датасете со всеми таргетами и доменами внутри объединённого портфеля. У каждого семпла при этом только один таргет.

Фичи берутся из объединения всех фичей портфеля. Если фича отсутствует для конкретного домена или задачи, используют zero-fill. Для каждого семпла считают соответствующий task-specific loss, после чего лоссы суммируются по батчу. Дополнительно добавлен correlation-based loss между предиктами и таргетами.

Дистилляция делается через soft-targets и teacher embeddings на входе модели.

В работе есть аблейшны всех частей пайплайна, а также разбивка по вкладу: Lattice Partitioner (36%), Lattice Zipper (11%), Lattice Filter (13%), Lattice Networks (23%), and Lattice KTAP (17%).

Архитектурные улучшения сравнивают с индустриальными SOTA-подходами, вроде Wukong, — на открытом датасете и на приватном.

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

@RecSysChannel
Разбор подготовил ❣ Александр Плошкин

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

GenRec: A Preference-Oriented Generative Framework for Large-Scale Recommendation

Разбираем статью от команды JD App — крупного китайского маркетплейса. Работа небольшая, но в ней есть несколько интересных идей на тему генеративных рекомендаций.

Обычный Next Item Prediction плохо соответствует тому, как пользователь в действительности взаимодействует со страницей. Юзер видит набор товаров, кликает, покупает, скроллит — и порядок этих действий не всегда отражает реальные намерения. Также есть проблемы логирования: события могут записываться не в том порядке, в котором пользователь их совершал.

Авторы предлагают перейти от Next Item Prediction к Page-Wise Next Token Prediction. Вместо того чтобы обучаться на отдельных действиях, модель рассматривает сразу всю страницу и все действия пользователя на ней. Действия сортируются по важности: покупки, клики, показы. Дальше модель делает один forward pass и суммирует лог-пробы всех действий. За счёт этого сигнал становится плотнее, а проблема неконсистентности между действиями и их логированием уменьшается.

Вторая часть работы посвящена сжатию длинных последовательностей. Каждый айтем представляют тремя семантическими id, поэтому без сжатия вычислительные затраты значительны. Чтобы сократить длину последовательности, используют Token Merger: конкатенируют три семантических токена и пропускают через линейную проекцию, получая один токен вместо трёх. Между семантиками одного айтема остаются разделительные токены, поэтому последовательность уменьшается не в три, а в два раза без сильной просадки качества.

Сами семантики получают через мультимодальный Qwen2.5-VL, добавляют коллаборативный сигнал и затем применяют residual quantization с K-means, получая три кодбука семантических токенов.

Третья часть — алайнмент через модификацию GRPO. Авторы используют preference model, которая оценивает айтемы из роллаутов и выдаёт реворд. Это нужно потому, что реальные пользовательские сигналы вроде кликов слишком спарсовые. Но при этом preference model может давать высокие скоры нерелевантным айтемам, поэтому добавляют gating-механизм, который зануляет реворд для нерелевантных пользователю рекомендаций.

Если пользователь действительно кликал или покупал айтемы из роллаута, его реворд дополнительно повышается — таким объектам назначают максимальный скор внутри группы. Дальше эти реворды используют в обычной формуле GRPO для подсчёта advantage. Вместо KL-регуляризации используют NLL-регуляризацию.

Основной прирост качества даёт именно Page-Wise-NTP. Когда сравнивают с LC-Rec на одинаковом backbone (Qwen2.5-3B) метрики выше. Token merger немного ухудшает качество, что логично — часть информации теряется при сжатии семантик.

Интересный момент при скейлинге. При переходе от 1,5B к 3B качество сильно выросло, а дальше — почти нет. Авторы связывают это с тем, что для генеративных рекомендаций важнее глубина модели, чем увеличение hidden size.

В онлайне получились большие приросты: около +9,5% по кликам и +8,7% по транзакциям. В аблейшнах видно, что основной вклад в RL-части даёт gating-механизм: без него reward alignment работает заметно хуже и больше галлюцинаций с невалидными айтемами.

@RecSysChannel
Разбор подготовила ❣ Вероника Иванова

Gryphon: A Unified Architecture for Semantic-ID Generation and Item-Level Scoring in Industrial Recommendations

Разбираем статью о гибридной генеративно-ранжирующей модели в рекомендациях Яндекс Музыки. О ней на Data Fest рассказала Дарья Тихонович, руководитель Яндекс RND-команды, которая разрабатывает новые рекомендательные технологии.

Генеративные рекомендации на базе Semantic IDs позволяют применять подход next token prediction к огромным каталогам, где невозможно напрямую выбирать следующий объект из миллионов вариантов. Вместо того чтобы предсказывать конкретный трек сразу, модель генерирует его поэтапно через последовательность семантических токенов. Например, сначала определяет жанр (русский рок), затем исполнителя («Сплин»), а потом конкретную композицию («Летучий Голландец»).

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

Но у генеративных рекомендательных моделей есть ряд проблем:

🔴Коллизии Semantic IDs — разные айтемы могут получать одинаковые семантические идентификаторы, из-за чего модель не различает их.
🔴Слой разрешения коллизий не масштабируется — работает офлайн, но не подходит для динамического каталога, который постоянно пополняется.
🔴Без разрешения коллизий падает качество — при удалении этого слоя качество может снижаться в разы.
🔴Нужно расширять пространство токенов — для лучшей уникализации нужны более крупные кодбуки и больше семантических токенов.
🔴Копятся ошибки генерации — ошибка в раннем токене ведёт к неверной оценке всей траектории.
🔴Потолок качества при длинных Semantic ID — увеличение числа токенов увеличивает уникализацию, но перестаёт улучшать качество рекомендаций.

Gryphon: генерация + ранжирование в одной модели

Gryphon — гибридная архитектура, которая объединяет генерацию кандидатов и их ранжирование. В основе encoder-decoder: по истории пользователя модель через beam search генерирует набор Semantic IDs. Чтобы избежать накопления ошибок при генерации (Semantic Drift), в beam search используется PRM (Process Reward Model), которая оценивает траектории генерации и помогает выбирать только релевантные пути для продолжения.

После генерации все Semantic IDs отображаются в общем пуле айтемов-кандидатов, релевантность которых оценивается через ORM (Output Reward Model). В результате, генеративная часть отвечает за кандидатогенерацию на уровне Semantic ID, а ORM — за финальное ранжирование айтемов. PRM и ORM — это легковесные модули на основе cross-attention, которые переиспользуют выходы энкодера генеративной модели, и поэтому лишь незначительно растят общее количество параметров и стоимость инференса.

При обучении ORM на задачу next-item-prediction в офлайне Gryphon показал +20% прироста Recal@1000 относительно Argus. Более того, модель опередила по качеству полный softmax по каталогу Яндекс Музыки.

В A/B-тестах Gryphon полностью заменил стек кандидатогенерации и преранжирования Яндекс.Музыки (15+ моделей), сократив число кандидатов для финального ранкера с 3000 до 1000 без потери качества. В сравнении с генеративным бейзлайном модель дала +3,6% команд Like, сохранила продуктовые метрики и увеличила разнообразие рекомендаций.

Модель работает в рантайме и регулярно дообучается. Семантический индекс строится на мультимодальных эмбеддингах (аудио, текст, метаданные), полученных с помощью Qwen 2.5 Omni и дополнительно обученных на коллаборативном InfoNCE-лоссе.

Теперь у нас есть архитектура, которая объединяет генерацию и ранжирование и уже показывает качество значительно выше классических кандидатогенераторов и полного softmax. Сейчас Gryphon активно развивается в экспериментах с end-to-end-рекомендациями и кросс-доменными генеративными моделями Яндекса.

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