Рекомендательная [RecSys Channel] – Telegram
Рекомендательная [RecSys Channel]
2.79K subscribers
188 photos
3 videos
100 links
Канал про рекомендательные системы от ml-специалистов Яндекса. Делимся опытом, обсуждаем новые подходы и интересные статьи.

Вопросы и предложения > @yandex_ml_brand
Download Telegram
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
Разбор подготовили Михаил Сёмин и Никита Мирошниченко
Please open Telegram to view this post
VIEW IN TELEGRAM
26🔥10👍7🗿2
🎉Подводим итоги: лучшее за год в Рекомендательной

У нас в 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23🎄96👍1👎1👏1🍾1🦄1
Какие статьи 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 запрещены на территории РФ
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥135👍4🙊1
Какие статьи 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
Статьи отобрали Сергей Макеев, Руслан Кулиев, Артём Матвеев
Please open Telegram to view this post
VIEW IN TELEGRAM
11🔥9👍6
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
Разбор подготовил Артём Ваншулин
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
14🔥9👍7
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
Разбор подготовил Сергей Макеев
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥86
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
Разбор подготовил Артём Матвеев
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍87
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 признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
11🔥9👍8
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
Разбор подготовил Иван Артемьев
Please open Telegram to view this post
VIEW IN TELEGRAM
7👍6🔥3🤔1🤩1
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 признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
12🔥10👍8
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
Разбор подготовила Василиса Григорьева
Please open Telegram to view this post
VIEW IN TELEGRAM
👍105🔥3❤‍🔥11🥰1😍1