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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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