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

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

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

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

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

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

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

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

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

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

REINFORCE

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

Off-policy correction

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

Top-K correction

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

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

Online A/B-тест

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Training Compute-Optimal Large Language Models

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

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

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

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

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

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

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

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