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
Разбор подготовил❣ Виктор Януш
Сегодня разберём очередной техрепорт от 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
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8❤5👍3
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
Разбор подготовил❣ Виктор Януш
Продолжаем разбор техрепорта от 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
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8❤5👍4
TBGRecall: A Generative Retrieval Model for E-commerce Recommendation Scenarios
Разбираем работу Alibaba, архитектурно напоминающую ARGUS, используемый в Рекламе Яндекса. Модель TBG Recall, описанная в статье, генерирует кандидатов для главной страницы Taobao, крупнейшего e-commerce-сервиса компании.
Во многих работах для рекомендаций применяются генеративные и последовательные модели, но они предполагают, что история пользователя — это строгая последовательность событий. В e-commerce всё иначе: пользователь делает запрос и получает «пачку» товаров, потом ещё одну — внутри таких пачек никакой упорядоченности нет, поэтому обычные sequence-based-подходы здесь работают не совсем корректно.
В качестве решения авторы вводят предсказание следующей сессии, где сессия понимается как один запрос пользователя. Модель учится предсказывать, какие товары пользователь увидит в следующей выдаче.Также в работе используют incremental training, чтобы регулярно обновлять модель на свежих данных без перерасхода GPU.
Архитектура
Как уже сказали, в основе TBGRecall — next session prediction: история пользователя кодируется в вектор и сравнивается с векторами кандидатов через ANN-индекс, как в классических двухбашенных моделях. Слово «генеративная» в названии относится не к инференсу, а к способу обучения — авторегрессионному.
В начале каждой сессии стоит контекстный токен — обобщённое описание запроса. При инференсе он формируется из текущего контекста пользователя и напрямую влияет на итоговый вектор, с которым рекомендательная система делает запрос в индекс. По нашим наблюдениям, контекстные токены дают почти двукратный прирост качества — особенно в сервисах вроде Поиска и Рекламы, где контекст крайне важен.
Кодирование и обучение
Каждое событие описывается набором признаков: Item ID, Action, SideInfo (ID продавца или категория), Context и Timestamp. Вход модели — сумма этих векторов. Сначала они проходят через tower-модули, а затем через HSTU-блоки. Для контекстных и айтемных токенов используются отдельные tower-модули — небольшие проекции, без которых качество падает (что совпадает с нашим опытом в ARGUS).
Основная схема обучения — session-wise autoregressive approach с маской внимания, которая не позволяет айтемам внутри одной сессии «видеть» друг друга. Также применяется session-wise ROPE (sw-ROPE) — позиционные эмбеддинги, нумерующие сессии. Мы пока не видели стабильного выигрыша от подобных схем, но идея любопытная.
Лосс состоит из трёх частей:
1. Lnce — воспроизводит логирующую политику, учит отличать реальные айтемы в сессии от случайных негативов.
2. Lclick — отличает кликнутые айтемы от показанных.
3. Lpay — отличает купленные от всех прочих.
Все три компоненты считаются по разным продуктовым сценариям и взвешиваются по числу сессий в них. Отдельного претрейна или fine-tune-фазы, как в ARGUS, нет — всё обучение проходит за один этап.
Инференс и результаты
В проде модель работает не в реальном времени: кандидаты пересчитываются асинхронно и обновляются с небольшой задержкой. Авторы считают, что контекст пользователя меняется нечасто, поэтому такая схема не вредит качеству.
На закрытом датасете (около 2 трлн записей) TBGRecall превзошёл собственный dual-tower baseline компании. В A/B-тестах модель показала +0,5% по числу транзакций и +2% по обороту. Новый кандидат-генератор теперь отвечает за 24% показов на поверхности Guess You Like — одной из ключевых страниц Taobao.
В целом, TBGRecall — это шаг от классической двухбашенной архитектуры к генеративному обучению. Контекстные токены дают сильный прирост, MoE и SW-ROPE работают стабильно, а near-line-инференс показывает себя лучше, чем ожидалось.
@RecSysChannel
Разбор подготовил❣ Николай Савушкин
Разбираем работу Alibaba, архитектурно напоминающую ARGUS, используемый в Рекламе Яндекса. Модель TBG Recall, описанная в статье, генерирует кандидатов для главной страницы Taobao, крупнейшего e-commerce-сервиса компании.
Во многих работах для рекомендаций применяются генеративные и последовательные модели, но они предполагают, что история пользователя — это строгая последовательность событий. В e-commerce всё иначе: пользователь делает запрос и получает «пачку» товаров, потом ещё одну — внутри таких пачек никакой упорядоченности нет, поэтому обычные sequence-based-подходы здесь работают не совсем корректно.
В качестве решения авторы вводят предсказание следующей сессии, где сессия понимается как один запрос пользователя. Модель учится предсказывать, какие товары пользователь увидит в следующей выдаче.Также в работе используют incremental training, чтобы регулярно обновлять модель на свежих данных без перерасхода GPU.
Архитектура
Как уже сказали, в основе TBGRecall — next session prediction: история пользователя кодируется в вектор и сравнивается с векторами кандидатов через ANN-индекс, как в классических двухбашенных моделях. Слово «генеративная» в названии относится не к инференсу, а к способу обучения — авторегрессионному.
В начале каждой сессии стоит контекстный токен — обобщённое описание запроса. При инференсе он формируется из текущего контекста пользователя и напрямую влияет на итоговый вектор, с которым рекомендательная система делает запрос в индекс. По нашим наблюдениям, контекстные токены дают почти двукратный прирост качества — особенно в сервисах вроде Поиска и Рекламы, где контекст крайне важен.
Кодирование и обучение
Каждое событие описывается набором признаков: Item ID, Action, SideInfo (ID продавца или категория), Context и Timestamp. Вход модели — сумма этих векторов. Сначала они проходят через tower-модули, а затем через HSTU-блоки. Для контекстных и айтемных токенов используются отдельные tower-модули — небольшие проекции, без которых качество падает (что совпадает с нашим опытом в ARGUS).
Основная схема обучения — session-wise autoregressive approach с маской внимания, которая не позволяет айтемам внутри одной сессии «видеть» друг друга. Также применяется session-wise ROPE (sw-ROPE) — позиционные эмбеддинги, нумерующие сессии. Мы пока не видели стабильного выигрыша от подобных схем, но идея любопытная.
Лосс состоит из трёх частей:
1. Lnce — воспроизводит логирующую политику, учит отличать реальные айтемы в сессии от случайных негативов.
2. Lclick — отличает кликнутые айтемы от показанных.
3. Lpay — отличает купленные от всех прочих.
Все три компоненты считаются по разным продуктовым сценариям и взвешиваются по числу сессий в них. Отдельного претрейна или fine-tune-фазы, как в ARGUS, нет — всё обучение проходит за один этап.
Инференс и результаты
В проде модель работает не в реальном времени: кандидаты пересчитываются асинхронно и обновляются с небольшой задержкой. Авторы считают, что контекст пользователя меняется нечасто, поэтому такая схема не вредит качеству.
На закрытом датасете (около 2 трлн записей) TBGRecall превзошёл собственный dual-tower baseline компании. В A/B-тестах модель показала +0,5% по числу транзакций и +2% по обороту. Новый кандидат-генератор теперь отвечает за 24% показов на поверхности Guess You Like — одной из ключевых страниц Taobao.
В целом, TBGRecall — это шаг от классической двухбашенной архитектуры к генеративному обучению. Контекстные токены дают сильный прирост, MoE и SW-ROPE работают стабильно, а near-line-инференс показывает себя лучше, чем ожидалось.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤🔥6❤5👍1