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
Сегодня разбираем ещё две статьи с 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
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤3🔥3
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
Разбор подготовил❣ Артём Матвеев
Тема масштабирования моделей в рекомендательных системах продолжает набирать популярность. Недавно 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
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9❤5👍4
This media is not supported in your browser
VIEW IN TELEGRAM
🔥22👍1👎1😱1
Мы с отличными новостями! Статью о датасете Yambda приняли на Oral конференции RecSys 2025. Поздравляем команду рекомендательных технологий Яндекса!
🔥53❤12🥰4
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
Разбор подготовил❣ Руслан Кулиев
Разбираем статью от 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
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥7❤6🥰1🤩1
Как прошла 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
Подводим итоги конференции — для этого собрали впечатления, тенденции и интересные статьи, отмеченные инженерами, посетившими её.
Работы, упоминаемые в карточках:
- 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
❤11👍5🔥3
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
Инженеры из группы исследования перспективных рекомендательных технологий выложили на 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
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18🔥12👍3
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
Разбор подготовил❣ Сергей Макеев
Сегодня рассказываем о статье, в которой описано решение от команды исследователей из Яндекса, получившее в этом году четвёртое место на конкурсе RecSys Challenge. Статью также приняли на конференцию RecSys 2025.
Челлендж был посвящён области e-commerce. В этом направлении рекомендательные модели обучают предсказывать разные виды сигналов: конверсии, релевантные товары и их категории, сумму, которую потратит клиент, и многое другое. Целью челленджа было обучить эмбеддинг пользователя, который объединил бы разнородные сигналы. Затем организаторы использовали этот эмбеддинг, чтобы обучить независимые модели под шесть разных задач, вроде тех, что описаны выше.
Как видно на картинке, для построения такого эмбеддинга предлагается сконкатенировать векторы от четырёх моделей: трансформера, выбор которого мотивирован подходом ARGUS, графовой нейросети TwHIN, DCN-v2-эмбеддингов и стандартизованных счётчиков.
Взаимодействия пользователей, предоставленные участникам, носят упорядоченный последовательный характер, поэтому важная часть решения — модель, кодирующая последовательности, — трансформер. В качестве истории пользователя брались все типы событий: добавления и удаления из корзины, покупки, посещённые страницы и запросы.
Трансформер в генеративной постановке учился предсказывать тип следующего взаимодействия, время до него, следующую посещённую страницу, а также следующий товар. DCN-v2-модель училась поверх эмбеддинга из трансформера и множества счётчиков, прошедших через кусочно-линейное кодирование, предсказывать отток клиентов, а также актуальные товары и категории, с которыми провзаимодействует пользователь. Графовая модель TwHIN обучалась предсказывать связи (добавления в корзину и покупки) между пользователем и товаром. Счётчики считались по разным временным промежуткам, тематическим кластерам и ценовым сегментам, а для учёта временных зависимостей использовалось экспоненциальное взвешивание. Подробный разбор всех счётчиков доступен в приложении к статье.
Получившийся ансамбль показал качество, сопоставимое с более сложными решениями (из десятков моделей), и занял четвёртое место в финальном лидерборде.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🔥9👍5