InterFormer: Effective Heterogeneous Interaction Learning for CTR Prediction
Сегодня разбираем статью InterFormer об архитектуре под задачу CTR-prediction на гетерогенных данных: статичных признаках пользователя/айтема и поведенческих последовательностях.
Авторы выделяют две проблемы существующих подходов:
1. слабое взаимодействие между sequence- и non-sequence-фичами;
2. агрессивное раннее сжатие последовательностей через pooling/summary, из-за чего теряется много информации.
Ключевой вклад — модуль InterFormer, который обрабатывает разные типы признаков отдельно, но на каждом слое обменивает между ними сжатые представления:
🔴 Interaction Arch — работает с non-sequence-фичами: user profile, item features, context. Ко входу добавляется summary последовательности, а в качестве бекбона можно использовать разные interaction-модули, например DCNv2 или DHEN.
🔴 Sequence Arch — моделирует историю пользователя. Здесь sequence-эмбеддинги обновляются с учётом summary от non-sequence-фичей: сначала через personalized FFN, затем через multi-head attention.
🔴 Cross Arch — слой обмена между двумя ветками. Non-sequence-признаки сжимаются через gated selection, а sequence-информация суммаризуется через комбинацию CLS-, PMA- и recent-tokens. Эти summary передаются в соседнюю ветку на следующем слое.
Идея в том, чтобы не «схлопывать» все признаки в один вектор слишком рано, а делать «двунаправленный обмен»: sequence помогает non-sequence-части, а non-sequence-контекст помогает sequence-моделированию.
Для задачи CTR используется стандартная бинарная кросс-энтропия.
Из публичных: AmazonElectronics (3M), TaobaoAds (25M), KuaiVideo (137M). Также авторы используют крупный внутренний датасет Meta* на 70B семплов.
На публичных датасетах InterFormer даёт лучшие результаты среди бейзлайнов. На внутреннем датасете Meta авторы показывают +0,15% NE, +24% QPS, а в pilot launch +0,6% uplift по по основным продуктовым метрикам.
Ablation studies подтверждают, что:
🔴 bidirectional interaction лучше однонаправленного обмена;
🔴 selective aggregation лучше раннего pooling/MLP/MHA-сжатия;
🔴 удаление PMA, recent tokens, gating, PFFN или MHA ухудшает качество.
Главное достоинство InterFormer — имплементация идеи с двунаправленным взаимодействием между статичными признаками и последовательностями без агрессивного раннего сжатия. Однако архитектура получилась довольно сложной и тяжелой для распараллеливания, приросты на публичных датасетах небольшие, а самые интересные production-результаты получены на закрытых данных Meta.
@RecSysChannel
Разбор подготовил❣ Никита Степанов
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Сегодня разбираем статью InterFormer об архитектуре под задачу CTR-prediction на гетерогенных данных: статичных признаках пользователя/айтема и поведенческих последовательностях.
Авторы выделяют две проблемы существующих подходов:
1. слабое взаимодействие между sequence- и non-sequence-фичами;
2. агрессивное раннее сжатие последовательностей через pooling/summary, из-за чего теряется много информации.
Ключевой вклад — модуль InterFormer, который обрабатывает разные типы признаков отдельно, но на каждом слое обменивает между ними сжатые представления:
Идея в том, чтобы не «схлопывать» все признаки в один вектор слишком рано, а делать «двунаправленный обмен»: sequence помогает non-sequence-части, а non-sequence-контекст помогает sequence-моделированию.
Для задачи CTR используется стандартная бинарная кросс-энтропия.
Из публичных: AmazonElectronics (3M), TaobaoAds (25M), KuaiVideo (137M). Также авторы используют крупный внутренний датасет Meta* на 70B семплов.
На публичных датасетах InterFormer даёт лучшие результаты среди бейзлайнов. На внутреннем датасете Meta авторы показывают +0,15% NE, +24% QPS, а в pilot launch +0,6% uplift по по основным продуктовым метрикам.
Ablation studies подтверждают, что:
Главное достоинство InterFormer — имплементация идеи с двунаправленным взаимодействием между статичными признаками и последовательностями без агрессивного раннего сжатия. Однако архитектура получилась довольно сложной и тяжелой для распараллеливания, приросты на публичных датасетах небольшие, а самые интересные production-результаты получены на закрытых данных Meta.
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤6🔥6❤🔥2👨💻1🫡1
OneReason Technical Report [1/2]
Сегодня разбираем хайповый техрепорт от Kuaishou на 108 страниц, в котором авторы научились получать существенный профит от ризонинг-моделей в рекомендациях.
В предыдущих статьях — OneRec-Think и OpenOneRec — модели уже могли генерировать человекочитаемые рассуждения на естественном языке, но thinking-режим не давал стабильного прироста и иногда даже ухудшал рекомендации. В OneReason авторы предлагают полный рецепт, объединяющий улучшенное восприятие itemic-токенов, структурированный CoT и доменный RL. В результате reasoning trace наконец начинает помогать предсказанию, а общие способности модели в основном сохраняются.
В этом разборе сосредоточимся преимущественно на первой части рецепта: устройстве бенчмарков, токенизации и многоуровневом претрейне, который создаёт семантический фундамент для последующего ризонинга.
Авторы предлагают не предсказывать следующий айтем напрямую по шумной истории пользователя. Сначала модель строит структурированный reasoning trace в три этапа. На этапе Persona Abstraction она сжимает историю в компактный профиль устойчивых предпочтений. Затем Interest Expansion выделяет несколько возможных направлений интереса, подтверждённых поведением пользователя. Наконец, Transition Inference сравнивает эти гипотезы с учётом силы и свежести сигналов, их временной связности и соответствия целевому домену. После этого модель генерирует itemic-токены следующего айтема.
Способности модели авторы оценивают на четырёх последовательных уровнях:
R0 — связывать itemic-токены с их текстовой семантикой и отвечать на вопросы о свойствах айтемов;
R1 — выводить отношения и возможные переходы между айтемами на основе их семантики;
R2 — рассматривать историю пользователя как временную последовательность и восстанавливать эволюцию его интересов;
R3 — объединять предыдущие способности для next-item prediction.
Для каждого уровня в едином OneReason-Bench предусмотрен свой набор диагностических задач. Финальное качество рекомендаций измеряют в двух сетапах:
🔴 single-domain, где модель видит историю только из целевого домена,
🔴 cross-domain, где получает взаимодействия пользователя из всех четырёх доменов, но предсказывает айтем из конкретного. Кросс-доменная история обычно даёт небольшой прирост, но для холодных пользователей помогает больше.
Чтобы модель вообще смогла строить такие рассуждения, сначала её пришлось научить понимать сами itemic-токены и пользовательские истории. Об этом поговорим во второй части.
@RecSysChannel
Разбор подготовил❣ Илья Мурзин
Сегодня разбираем хайповый техрепорт от Kuaishou на 108 страниц, в котором авторы научились получать существенный профит от ризонинг-моделей в рекомендациях.
В предыдущих статьях — OneRec-Think и OpenOneRec — модели уже могли генерировать человекочитаемые рассуждения на естественном языке, но thinking-режим не давал стабильного прироста и иногда даже ухудшал рекомендации. В OneReason авторы предлагают полный рецепт, объединяющий улучшенное восприятие itemic-токенов, структурированный CoT и доменный RL. В результате reasoning trace наконец начинает помогать предсказанию, а общие способности модели в основном сохраняются.
В этом разборе сосредоточимся преимущественно на первой части рецепта: устройстве бенчмарков, токенизации и многоуровневом претрейне, который создаёт семантический фундамент для последующего ризонинга.
Авторы предлагают не предсказывать следующий айтем напрямую по шумной истории пользователя. Сначала модель строит структурированный reasoning trace в три этапа. На этапе Persona Abstraction она сжимает историю в компактный профиль устойчивых предпочтений. Затем Interest Expansion выделяет несколько возможных направлений интереса, подтверждённых поведением пользователя. Наконец, Transition Inference сравнивает эти гипотезы с учётом силы и свежести сигналов, их временной связности и соответствия целевому домену. После этого модель генерирует itemic-токены следующего айтема.
Способности модели авторы оценивают на четырёх последовательных уровнях:
R0 — связывать itemic-токены с их текстовой семантикой и отвечать на вопросы о свойствах айтемов;
R1 — выводить отношения и возможные переходы между айтемами на основе их семантики;
R2 — рассматривать историю пользователя как временную последовательность и восстанавливать эволюцию его интересов;
R3 — объединять предыдущие способности для next-item prediction.
Для каждого уровня в едином OneReason-Bench предусмотрен свой набор диагностических задач. Финальное качество рекомендаций измеряют в двух сетапах:
Чтобы модель вообще смогла строить такие рассуждения, сначала её пришлось научить понимать сами itemic-токены и пользовательские истории. Об этом поговорим во второй части.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13👍5🐳5🔥2
OneReason Technical Report [2/2]
В первой части разобрали, как устроен OneReason-Bench и почему авторы вообще вводят многоступенчатый ризонинг вместо next-item prediction. Теперь посмотрим, как модель учат работать с itemic-токенами и почему претрейн оказался здесь так важен.
На претрейне модель прежде всего учат воспринимать историю пользователя и связывать семантические ID с текстом. Каждый айтем представляют четырьмя токенами: токеном домена и тремя семантическими ID. От завершающего токена из OpenOneRec отказались, чтобы сократить представление айтема и оставить больше контекста.
Данные для претрейна делят на четыре уровня гранулярности:
🔴 на уровне токенов модель учат связывать с текстом отдельные itemic-токены, их префиксы и полные токеновые последовательности;
🔴 на уровне айтемов — генерировать описания, восстанавливать itemic-токены по тексту и отвечать на вопросы о свойствах контента;
🔴 на уровне отношений — понимать связи и переходы между айтемами через естественно-языковые объяснения;
🔴 на уровне пользователя — работать с доменно сгруппированными и хронологически перемешанными историями, моделируя кросс-доменные связи и эволюцию интересов.
То есть претрейн не сводят к одному next-item objective. Обучающая смесь одновременно охватывает задачи от семантики отдельных токенов до моделирования полной пользовательской истории.
Около 28,4% токенов претрейна приходится на данные общего назначения: 26,85% составляют текстовые корпуса, а ещё 1,59% — мультимодальные. Они нужны, чтобы во время специализации на рекомендациях модель сохраняла общие reasoning- и instruction-following-способности. С такой смесью итоговая модель остаётся близка к исходному Qwen3-8B на общих LLM-бенчмарках.
Сам претрейн проходит в три этапа.
1) Сначала при замороженном бэкбоне обучают только новые эмбеддинги и соответствующие веса LM-головы для itemic-токенов.
2) Затем размораживают все параметры и продолжают обучение с меньшим learning rate.
3) На последнем этапе максимальную длину отдельных примеров увеличивают с 4K до 32K токенов, чтобы модель научилась обрабатывать полные пользовательские истории.
OneReason обгоняет рекомендательные бейзлайны и почти не просаживается на LLM-бенчмарках — в отличие от Open OneRec, которая заметно теряла в языковых способностях. При этом модель, обученная получать качество за счёт рассуждений, становится лучше и в режиме без ризонинга.
Аблейшны показывают, что добавление каждого следующего уровня гранулярности улучшает качество, а лучший результат даёт весь претрейн-рецепт целиком.
@RecSysChannel
Разбор подготовил❣ Илья Мурзин
В первой части разобрали, как устроен OneReason-Bench и почему авторы вообще вводят многоступенчатый ризонинг вместо next-item prediction. Теперь посмотрим, как модель учат работать с itemic-токенами и почему претрейн оказался здесь так важен.
На претрейне модель прежде всего учат воспринимать историю пользователя и связывать семантические ID с текстом. Каждый айтем представляют четырьмя токенами: токеном домена и тремя семантическими ID. От завершающего токена из OpenOneRec отказались, чтобы сократить представление айтема и оставить больше контекста.
Данные для претрейна делят на четыре уровня гранулярности:
То есть претрейн не сводят к одному next-item objective. Обучающая смесь одновременно охватывает задачи от семантики отдельных токенов до моделирования полной пользовательской истории.
Около 28,4% токенов претрейна приходится на данные общего назначения: 26,85% составляют текстовые корпуса, а ещё 1,59% — мультимодальные. Они нужны, чтобы во время специализации на рекомендациях модель сохраняла общие reasoning- и instruction-following-способности. С такой смесью итоговая модель остаётся близка к исходному Qwen3-8B на общих LLM-бенчмарках.
Сам претрейн проходит в три этапа.
1) Сначала при замороженном бэкбоне обучают только новые эмбеддинги и соответствующие веса LM-головы для itemic-токенов.
2) Затем размораживают все параметры и продолжают обучение с меньшим learning rate.
3) На последнем этапе максимальную длину отдельных примеров увеличивают с 4K до 32K токенов, чтобы модель научилась обрабатывать полные пользовательские истории.
OneReason обгоняет рекомендательные бейзлайны и почти не просаживается на LLM-бенчмарках — в отличие от Open OneRec, которая заметно теряла в языковых способностях. При этом модель, обученная получать качество за счёт рассуждений, становится лучше и в режиме без ризонинга.
Аблейшны показывают, что добавление каждого следующего уровня гранулярности улучшает качество, а лучший результат даёт весь претрейн-рецепт целиком.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10🔥7💅5👍2👎1🐳1🤝1
GRank: Towards Target-Aware and Streamlined Industrial Retrieval with a Generate-Rank Framework
Сегодня разбираем статью о том, как построить ретривал для миллиардов айтемов, сохранить target-aware-ность, уложиться в жесткий latency budget и при этом обойтись без сложных индексов.
В классическом ретривале из миллиардов кандидатов нужно быстро вернуть тысячи или десятки тысяч айтемов, которые дальше пойдут в ранжирование. Поэтому часто используются двубашенные подходы: отдельно получаем юзерный эмбеддинг, отдельно — эмбеддинги айтемов, а дальше считаем какую-то простую функцию вроде dot product и ищем «ближайшие» к юзеру айтемы.
У такого подхода сильно ограничена выразительная способность, ведь эмбеддинги юзеров и айтемов взаимодействуют только через выбранную простую функцию, но никак иначе.
При этом хочется добавить target-aware-ность в архитектуру через более плотное взаимодействие конкретного кандидата с юзером. Например, если хотим понять, насколько юзеру релевантна компьютерная мышь, то можно посмотреть на историю его действий, увидеть что-то о ноутбуках и обратить внимание именно на это. То есть, хочется «перевзвешивать» историю юзера относительно конкретного таргета.
На ретривал-стадии так сделать не получится из-за того, что кандидатов слишком много и обработать их надо быстро. Можно строить сложные индексы на основе деревьев или графов, но их тяжело поддерживать, они замедляют инференс и становится труднее контролировать latency.
В работе предлагается от всего этого уйти и разбить ретривал на две стадии:
1) Генератор, который должен очень быстро вернуть чуть больше кандидатов, чем в итоге нужно. В продовом сетапе авторов он достаёт 2000 айтемов, количество которые потом сужаются до 500. При этом сам генератор на инференсе остается обычной двубашенной моделью.
2) Преранкер, который представляет собой target-aware-подход уже на маленьком наборе кандидатов через cross-attention, после чего выдает более выразительные скоры релевантности.
Самая интересная часть статьи — о том, как учится генератор.
Обычно мы берём юзерный эмбед после трансформера, считаем dot product с айтемом и учим модель отличать позитив от негативов. В GRank к этому добавляют вспомогательную target-aware-задачу.
Берут те же таргет и негативы, подставляют их в историю, прогоняют через трансформер с ранним связыванием и считают лосс по полученным скорам — генератор одновременно учится на обеих задачах.
На инференсе эта target-aware-компонента никак не используется, и мы получаем классический быстрый двухбашенный подход.
По аблейшенам эта компонента выглядит самой важной частью системы — если взять просто генератор, то жертвуем качеством; если добавить только ранкер, метрики лучше, но всё равно проседают относительно полного GRank. А когда к генератору добавляют target-aware-компоненту в лоссе, получается самый большой прирост.
По экспериментам авторы докладывают о двузначных приростах в Recall и NDCG, причём не только на своём датасете. При этом по пропускной способности GRank остаётся примерно на уровне предыдущего двубашенного решения, а подходы со сложными индексами проседают.
@RecSysChannel
Разбор подготовил❣ Никита Степанов
Сегодня разбираем статью о том, как построить ретривал для миллиардов айтемов, сохранить target-aware-ность, уложиться в жесткий latency budget и при этом обойтись без сложных индексов.
В классическом ретривале из миллиардов кандидатов нужно быстро вернуть тысячи или десятки тысяч айтемов, которые дальше пойдут в ранжирование. Поэтому часто используются двубашенные подходы: отдельно получаем юзерный эмбеддинг, отдельно — эмбеддинги айтемов, а дальше считаем какую-то простую функцию вроде dot product и ищем «ближайшие» к юзеру айтемы.
У такого подхода сильно ограничена выразительная способность, ведь эмбеддинги юзеров и айтемов взаимодействуют только через выбранную простую функцию, но никак иначе.
При этом хочется добавить target-aware-ность в архитектуру через более плотное взаимодействие конкретного кандидата с юзером. Например, если хотим понять, насколько юзеру релевантна компьютерная мышь, то можно посмотреть на историю его действий, увидеть что-то о ноутбуках и обратить внимание именно на это. То есть, хочется «перевзвешивать» историю юзера относительно конкретного таргета.
На ретривал-стадии так сделать не получится из-за того, что кандидатов слишком много и обработать их надо быстро. Можно строить сложные индексы на основе деревьев или графов, но их тяжело поддерживать, они замедляют инференс и становится труднее контролировать latency.
В работе предлагается от всего этого уйти и разбить ретривал на две стадии:
1) Генератор, который должен очень быстро вернуть чуть больше кандидатов, чем в итоге нужно. В продовом сетапе авторов он достаёт 2000 айтемов, количество которые потом сужаются до 500. При этом сам генератор на инференсе остается обычной двубашенной моделью.
2) Преранкер, который представляет собой target-aware-подход уже на маленьком наборе кандидатов через cross-attention, после чего выдает более выразительные скоры релевантности.
Самая интересная часть статьи — о том, как учится генератор.
Обычно мы берём юзерный эмбед после трансформера, считаем dot product с айтемом и учим модель отличать позитив от негативов. В GRank к этому добавляют вспомогательную target-aware-задачу.
Берут те же таргет и негативы, подставляют их в историю, прогоняют через трансформер с ранним связыванием и считают лосс по полученным скорам — генератор одновременно учится на обеих задачах.
На инференсе эта target-aware-компонента никак не используется, и мы получаем классический быстрый двухбашенный подход.
По аблейшенам эта компонента выглядит самой важной частью системы — если взять просто генератор, то жертвуем качеством; если добавить только ранкер, метрики лучше, но всё равно проседают относительно полного GRank. А когда к генератору добавляют target-aware-компоненту в лоссе, получается самый большой прирост.
По экспериментам авторы докладывают о двузначных приростах в Recall и NDCG, причём не только на своём датасете. При этом по пропускной способности GRank остаётся примерно на уровне предыдущего двубашенного решения, а подходы со сложными индексами проседают.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7❤🔥3👍3🔥2🤝1💘1
Три статьи на стыке LLM и Recsys
Сегодня делимся сразу тремя работами о том, как LLM встраивают в разные части рекомендательных и шопинговых систем.
Building a Production Shopping Agent at Scale
Amazon делятся опытом внедрения их шопингового агента Rufus. Здесь LLM — оркестратор: она принимает запрос пользователя, контекст диалога и релевантные пользовательские фичи и по ним понимает, в какие тулы нужно сходить, чтобы удовлетворить интент. По результатам работы тулов модель формирует окончательный ответ пользователю.
Агент работает в нескольких сценариях: 1) помогает с Product Discovery, когда пользователь ещё не знает конкретный товар; 2) отвечает на вопросы о конкретных товарах; 3) обращается к профилю пользователя, например смотрит прошлые покупки и текущие заказы, и может сам добавлять товары в корзину.
Авторы показывают несколько приёмов для ускорения цепочки.
• Отбирают только релевантные события из истории пользователя и сокращают историю диалога, чтобы не засорять контекст и уменьшать время до первого токена.
• Оптимизируют промпты, делая более стабильные и переиспользуемые префиксы, чтобы не пересчитывать одинаковое состояние агента.
• Делают вызовы тулов строже и по возможности параллелят, чтобы быстрее выдавать результат пользователю.
Можно улучшать каждый компонент по отдельности, но просадить общий пользовательский опыт. Чтобы такого не было, авторы предлагают смотреть на систему end-to-end: насколько удачной была работа агента, устроил ли результат пользователя и насколько дорогим и долгим оказался весь пайплайн.
Probe-Then-Plan: Environment-Aware Planning
Авторы из JD решают задачу сложных пользовательских запросов. Здесь «сложные» — не те, что требуют сложного ризонинга, а те, которые понятны человеку, но плохо переводятся на язык каталога. Например, пользователь хочет подобрать что-то «к зелёной рубашке»: человеку понятно, что речь скорее о брюках, джинсах или обуви, а простой поиск может выдать ещё больше рубашек.
Авторы замечают, что часто достаточно один раз посмотреть на выдачу, чтобы понять, как исправить запрос. Поэтому сначала смотрят, что по исходному запросу выдаёт продакшен-стек. Небольшой Qwen определяет, всё ли с выдачей хорошо, слишком ли она маленькая или товаров много, но они не соответствуют запросу, и при необходимости предлагает план исправления. Модель дистиллируют из большой LLM, а затем дообучают с RL на бизнес-цели.
Даже маленькая модель даёт заметное замедление, поэтому 80% простых запросов оставляют текущему продуктовому стеку, а 20% сложных отправляют через новый пайплайн.
В офлайне подход заметно лучше слепого переписывания запроса. По качеству он уступает ReAct, зато сильно выигрывает по времени. В онлайне всё конвертируется в GMV.
RecGPT-Mobile
Здесь on-device LLM используют, чтобы быстро понять изменения интента в рекомендательной ленте.
Допустим, пользователь внезапно начинает чаще кликать по компактным рюкзакам и добавлять их в избранное. Специальный модуль замечает изменение поведения и триггерит систему. Из залогированных на устройстве релевантных событий формируется промпт для on-device LLM, которая генерирует query под новый интент. Он отправляется в облако, где большая продовая система возвращает релевантные товары и обновляет ленту.
Чтобы всё это работало на устройстве, используют Qwen3-0.6B с квантизацией, берут не всю историю, а только полезный контекст и запускают систему не на каждый случайный клик, а только когда поведение действительно меняется.
В экспериментах LoRA обходит полный тюнинг модели, а квантизация теряет не так много качества. В месячном A/B-тесте получили +2,5% GMV на четырёх поверхностях.
@RecSysChannel
Разбор подготовила❣ Екатерина Дмитриева
Сегодня делимся сразу тремя работами о том, как LLM встраивают в разные части рекомендательных и шопинговых систем.
Building a Production Shopping Agent at Scale
Amazon делятся опытом внедрения их шопингового агента Rufus. Здесь LLM — оркестратор: она принимает запрос пользователя, контекст диалога и релевантные пользовательские фичи и по ним понимает, в какие тулы нужно сходить, чтобы удовлетворить интент. По результатам работы тулов модель формирует окончательный ответ пользователю.
Агент работает в нескольких сценариях: 1) помогает с Product Discovery, когда пользователь ещё не знает конкретный товар; 2) отвечает на вопросы о конкретных товарах; 3) обращается к профилю пользователя, например смотрит прошлые покупки и текущие заказы, и может сам добавлять товары в корзину.
Авторы показывают несколько приёмов для ускорения цепочки.
• Отбирают только релевантные события из истории пользователя и сокращают историю диалога, чтобы не засорять контекст и уменьшать время до первого токена.
• Оптимизируют промпты, делая более стабильные и переиспользуемые префиксы, чтобы не пересчитывать одинаковое состояние агента.
• Делают вызовы тулов строже и по возможности параллелят, чтобы быстрее выдавать результат пользователю.
Можно улучшать каждый компонент по отдельности, но просадить общий пользовательский опыт. Чтобы такого не было, авторы предлагают смотреть на систему end-to-end: насколько удачной была работа агента, устроил ли результат пользователя и насколько дорогим и долгим оказался весь пайплайн.
Probe-Then-Plan: Environment-Aware Planning
Авторы из JD решают задачу сложных пользовательских запросов. Здесь «сложные» — не те, что требуют сложного ризонинга, а те, которые понятны человеку, но плохо переводятся на язык каталога. Например, пользователь хочет подобрать что-то «к зелёной рубашке»: человеку понятно, что речь скорее о брюках, джинсах или обуви, а простой поиск может выдать ещё больше рубашек.
Авторы замечают, что часто достаточно один раз посмотреть на выдачу, чтобы понять, как исправить запрос. Поэтому сначала смотрят, что по исходному запросу выдаёт продакшен-стек. Небольшой Qwen определяет, всё ли с выдачей хорошо, слишком ли она маленькая или товаров много, но они не соответствуют запросу, и при необходимости предлагает план исправления. Модель дистиллируют из большой LLM, а затем дообучают с RL на бизнес-цели.
Даже маленькая модель даёт заметное замедление, поэтому 80% простых запросов оставляют текущему продуктовому стеку, а 20% сложных отправляют через новый пайплайн.
В офлайне подход заметно лучше слепого переписывания запроса. По качеству он уступает ReAct, зато сильно выигрывает по времени. В онлайне всё конвертируется в GMV.
RecGPT-Mobile
Здесь on-device LLM используют, чтобы быстро понять изменения интента в рекомендательной ленте.
Допустим, пользователь внезапно начинает чаще кликать по компактным рюкзакам и добавлять их в избранное. Специальный модуль замечает изменение поведения и триггерит систему. Из залогированных на устройстве релевантных событий формируется промпт для on-device LLM, которая генерирует query под новый интент. Он отправляется в облако, где большая продовая система возвращает релевантные товары и обновляет ленту.
Чтобы всё это работало на устройстве, используют Qwen3-0.6B с квантизацией, берут не всю историю, а только полезный контекст и запускают систему не на каждый случайный клик, а только когда поведение действительно меняется.
В экспериментах LoRA обходит полный тюнинг модели, а квантизация теряет не так много качества. В месячном A/B-тесте получили +2,5% GMV на четырёх поверхностях.
@RecSysChannel
Разбор подготовила
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13🔥11✍3👌1🤝1
Generating Long Semantic IDs in Parallel for Recommendation
Генеративные модели с Semantic ID обычно используют короткие ID, например из четырёх токенов. Делают так, потому что авторегрессионная генерация длинных даёт высокую задержку и большой расход памяти. Но с короткими тоже есть проблема — они ощутимо ограничивают выразительность представления объектов.
В статье RPG предложили отказаться от авторегрессионной генерации и предсказывать все токены Semantic ID параллельно. Благодаря этому можно использовать длинные Semantic ID — до 64 токенов, и это ключевой вклад работы.
Но для параллельной генерации не очень подходят обычные Semantic ID на основе RQ. В RQ каждый следующий токен кодирует остаток после предыдущего, поэтому токены последовательно зависят друг от друга, а первые оказываются важнее последних. Вместо RQ авторы используют OPQ, который сначала преобразует item-вектор, а затем делит его на отдельно квантуемые подпространства. Поэтому токены получаются более независимыми и сбалансированными.
На обучении используется multi-token prediction loss. Модель параллельно предсказывает токены, а не сами товары, и для каждой позиции Semantic ID задан конкретный таргетный токен. Хотя генерация параллельная, позиции ID фиксированы — эквивалентность между разными комбинациями токенов на обучении не учитывается.
На инференсе возникает другая проблема. Независимо предсказанные токены могут сложиться в комбинацию, которой нет ни у одного реального айтема. Чтобы решить это, авторы используют graph-constrained decoding. Вершины графа соответствуют валидным Semantic ID реальных айтемов, а рёбра связывают похожие ID. Поиск проходит по этому графу и не требует полного перебора каталога.
Согласно приведённым результатам, RPG занимает первое место в 15 из 16 сравнений среди бейзлайнов. А по метрике NDCG@10 показывает в среднем относительный прирост 12,6% по сравнению с сильнейшим бейзлайном.
При этом в эксперименте на датасете Sports runtime GPU memory примерно в 25 раз ниже, а инференс почти в 15 раз быстрее относительно TIGER. При фиксированных параметрах декодирования время инференса и используемая GPU-память не зависят напрямую от числа айтемов. Однако полное хранилище, включая decoding graph и отображение айтемов в токены, растёт вместе с каталогом.
Отдельно авторы анализируют выразительность Semantic ID на энкодерах sentence-t5-base и text-embedding-3-large. Получается интересное: сильный энкодер сам по себе не гарантирует прирост. TIGER с коротким ID может потерять часть информации из хорошего эмбеддинга, тогда как RPG с длинным OPQ-ID лучше её сохраняет.
Абляции, которые в работе довольно подробные и убедительные, подтверждают, что отдельные части подхода работают именно вместе. При этом в целом статья пока выглядит скорее как исследование, чем как готовое продакшн-решение, потому что эксперименты проведены только на публичных Amazon-датасетах, production latency benchmark отсутствует, а обновление графа при изменении каталога не исследовано.
@RecSysChannel
Разбор подготовила❣ Варвара Родионова
Генеративные модели с Semantic ID обычно используют короткие ID, например из четырёх токенов. Делают так, потому что авторегрессионная генерация длинных даёт высокую задержку и большой расход памяти. Но с короткими тоже есть проблема — они ощутимо ограничивают выразительность представления объектов.
В статье RPG предложили отказаться от авторегрессионной генерации и предсказывать все токены Semantic ID параллельно. Благодаря этому можно использовать длинные Semantic ID — до 64 токенов, и это ключевой вклад работы.
Но для параллельной генерации не очень подходят обычные Semantic ID на основе RQ. В RQ каждый следующий токен кодирует остаток после предыдущего, поэтому токены последовательно зависят друг от друга, а первые оказываются важнее последних. Вместо RQ авторы используют OPQ, который сначала преобразует item-вектор, а затем делит его на отдельно квантуемые подпространства. Поэтому токены получаются более независимыми и сбалансированными.
На обучении используется multi-token prediction loss. Модель параллельно предсказывает токены, а не сами товары, и для каждой позиции Semantic ID задан конкретный таргетный токен. Хотя генерация параллельная, позиции ID фиксированы — эквивалентность между разными комбинациями токенов на обучении не учитывается.
На инференсе возникает другая проблема. Независимо предсказанные токены могут сложиться в комбинацию, которой нет ни у одного реального айтема. Чтобы решить это, авторы используют graph-constrained decoding. Вершины графа соответствуют валидным Semantic ID реальных айтемов, а рёбра связывают похожие ID. Поиск проходит по этому графу и не требует полного перебора каталога.
Согласно приведённым результатам, RPG занимает первое место в 15 из 16 сравнений среди бейзлайнов. А по метрике NDCG@10 показывает в среднем относительный прирост 12,6% по сравнению с сильнейшим бейзлайном.
При этом в эксперименте на датасете Sports runtime GPU memory примерно в 25 раз ниже, а инференс почти в 15 раз быстрее относительно TIGER. При фиксированных параметрах декодирования время инференса и используемая GPU-память не зависят напрямую от числа айтемов. Однако полное хранилище, включая decoding graph и отображение айтемов в токены, растёт вместе с каталогом.
Отдельно авторы анализируют выразительность Semantic ID на энкодерах sentence-t5-base и text-embedding-3-large. Получается интересное: сильный энкодер сам по себе не гарантирует прирост. TIGER с коротким ID может потерять часть информации из хорошего эмбеддинга, тогда как RPG с длинным OPQ-ID лучше её сохраняет.
Абляции, которые в работе довольно подробные и убедительные, подтверждают, что отдельные части подхода работают именно вместе. При этом в целом статья пока выглядит скорее как исследование, чем как готовое продакшн-решение, потому что эксперименты проведены только на публичных Amazon-датасетах, production latency benchmark отсутствует, а обновление графа при изменении каталога не исследовано.
@RecSysChannel
Разбор подготовила
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍5🔥5💯3❤🔥2🤝2🤩1
WHALE: A Scalable Unified Model for Recommendation with Wukong-HSTU Architecture
Сегодня разбираем статью от Meta*. Это практическая работа о том, как в большом сервисе коротких видео повысить качество модели на этапе финального ранжирования. О жёстких ограничениях латенси тоже не забываем.
Главный вопрос — куда направить дополнительный вычислительный бюджет в рантайме. Варианты такие:
- на моделирование взаимодействий признаков,
- на моделирование последовательности действий пользователя,
- на то и другое.
Авторы выбрали третий вариант и предложили WHALE — архитектуру из двух параллельных веток с модулем фьюзинга:
1) Wukong-модуль работает со стандартными числовыми фичами: счётчиками и предиктами нижестоящих моделей.
2) HSTU-модуль обрабатывает исходную пользовательскую историю до 15 тысяч событий.
На каждом слое Wukong через cross-attention обращается к состояниям HSTU и вытаскивает информацию, релевантную конкретному кандидату. Получившееся представление передаётся на вход следующего слоя, там всё повторяется.
Информация идёт только из истории в Wukong, но не обратно, поэтому ветвь вычисления HSTU не зависит от кандидата. Таким образом длинную историю пользователя можно посчитать один раз и переиспользовать KV-cache для всех кандидатов.
В экспериментах авторы проверили, что вообще выгоднее масштабировать (вопрос, заданный в начале). Их основная оффлайн-метрика — Normalized Entropy (NE) — показывает улучшение logloss-модели относительно оптимальной константы. При сопоставимом бюджете на вычисления увеличение только Wukong дало всего до +0,06% NE, что близко к уровню шума. Масштабирование HSTU даёт +0,73%, а масштабирование сразу обеих ветвей в WHALE — уже +1,39%.
Отдельно проаблейтили раннее связывание через attention-механизм. Если cross-attention заменить обычным mean-пулингом, результат получается хуже на 0,23% NE. Почти весь выигрыш — именно от выборочного извлечения информации из несжатой истории.
Также WHALE проверили в двухнедельном A/B-тесте на срезе рекомендаций некоторой неназванной соцсети. По основной онлайн-метрике авторов получили +0,113% при снижении inference QPS на 5%.
Главный вывод, который тут подтвердили — дополнительный компьют в финальном ранжировании выгоднее тратить на длинную пользовательскую историю и её взаимодействие с кандидатом по глубине сети. Принципиально новой идеи здесь, кажется, нет. Но зато авторы взяли сильные бейзлайны, собрали из них нафаршированную модель и довели её до успеха в онлайне.
@RecSysChannel
Разбор подготовил❣ Александр Плошкин
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Сегодня разбираем статью от Meta*. Это практическая работа о том, как в большом сервисе коротких видео повысить качество модели на этапе финального ранжирования. О жёстких ограничениях латенси тоже не забываем.
Главный вопрос — куда направить дополнительный вычислительный бюджет в рантайме. Варианты такие:
- на моделирование взаимодействий признаков,
- на моделирование последовательности действий пользователя,
- на то и другое.
Авторы выбрали третий вариант и предложили WHALE — архитектуру из двух параллельных веток с модулем фьюзинга:
1) Wukong-модуль работает со стандартными числовыми фичами: счётчиками и предиктами нижестоящих моделей.
2) HSTU-модуль обрабатывает исходную пользовательскую историю до 15 тысяч событий.
На каждом слое Wukong через cross-attention обращается к состояниям HSTU и вытаскивает информацию, релевантную конкретному кандидату. Получившееся представление передаётся на вход следующего слоя, там всё повторяется.
Информация идёт только из истории в Wukong, но не обратно, поэтому ветвь вычисления HSTU не зависит от кандидата. Таким образом длинную историю пользователя можно посчитать один раз и переиспользовать KV-cache для всех кандидатов.
В экспериментах авторы проверили, что вообще выгоднее масштабировать (вопрос, заданный в начале). Их основная оффлайн-метрика — Normalized Entropy (NE) — показывает улучшение logloss-модели относительно оптимальной константы. При сопоставимом бюджете на вычисления увеличение только Wukong дало всего до +0,06% NE, что близко к уровню шума. Масштабирование HSTU даёт +0,73%, а масштабирование сразу обеих ветвей в WHALE — уже +1,39%.
Отдельно проаблейтили раннее связывание через attention-механизм. Если cross-attention заменить обычным mean-пулингом, результат получается хуже на 0,23% NE. Почти весь выигрыш — именно от выборочного извлечения информации из несжатой истории.
Также WHALE проверили в двухнедельном A/B-тесте на срезе рекомендаций некоторой неназванной соцсети. По основной онлайн-метрике авторов получили +0,113% при снижении inference QPS на 5%.
Главный вывод, который тут подтвердили — дополнительный компьют в финальном ранжировании выгоднее тратить на длинную пользовательскую историю и её взаимодействие с кандидатом по глубине сети. Принципиально новой идеи здесь, кажется, нет. Но зато авторы взяли сильные бейзлайны, собрали из них нафаршированную модель и довели её до успеха в онлайне.
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍7🎉5💯1🏆1
OneRanker: Unified Generation and Ranking with One Model in Industrial Advertising Recommendation [1/3]
Сегодня приступаем к разбору статьи о том, как объединить генерацию кандидатов и ранжирование в одной модели. Начнём с проблематики и первого шага фреймворка OneRanker.
У современных рекомендательных подходов есть несколько минусов:
• Конфликт интереса пользователя и ценности для бизнеса. Генерация кандидатов опирается на клики и конверсии в истории пользователя, но системе важно учитывать и ценность объектов для бизнеса (например, для рекламы это eCPM). Если напрямую обучать генератор на обеих целях, они тянут общее представление в разные стороны: ухудшается и охват интересов, и отбор ценных объектов. Если же учитывать ценность только при ранжировании, лучшие по этому критерию кандидаты могут отсеяться раньше, чем начнётся ранжирование.
• Нечувствительность к кандидату (target-agnostic). При генерации представление пользователя одинаково для разных кандидатов. Поэтому модель не может выделить в истории именно те события, которые важны для оценки конкретного объекта.
• Разрыв между этапами. Отдельные генератор и ранжировщик могут повторно обрабатывать одну историю и учить разные представления.
Чтобы решить эти проблемы, авторы предлагают интегрировать генерацию в ранжирование на архитектурном уровне. Так появился фреймворк OneRanker. Он состоит из трёх шагов.
Шаг 1. Основа генерации
OneRanker опирается на предыдущую работу Tencent — GPR. История пользователя представлена последовательностью разнородных токенов: пользователя (U), контента (C), контекста (X) и объектов (I). Декодер на основе HSTU обрабатывает эту последовательность, а авторегрессионный механизм multi-token prediction (MTP) позволяет за один проход модели параллельно строить несколько полных цепочек семантических ID.
Что происходит на втором шаге фреймворка, подробно разберём в следующем посте.
@RecSysChannel
Разбор подготовил❣ Артём Ваншулин
Сегодня приступаем к разбору статьи о том, как объединить генерацию кандидатов и ранжирование в одной модели. Начнём с проблематики и первого шага фреймворка OneRanker.
У современных рекомендательных подходов есть несколько минусов:
• Конфликт интереса пользователя и ценности для бизнеса. Генерация кандидатов опирается на клики и конверсии в истории пользователя, но системе важно учитывать и ценность объектов для бизнеса (например, для рекламы это eCPM). Если напрямую обучать генератор на обеих целях, они тянут общее представление в разные стороны: ухудшается и охват интересов, и отбор ценных объектов. Если же учитывать ценность только при ранжировании, лучшие по этому критерию кандидаты могут отсеяться раньше, чем начнётся ранжирование.
• Нечувствительность к кандидату (target-agnostic). При генерации представление пользователя одинаково для разных кандидатов. Поэтому модель не может выделить в истории именно те события, которые важны для оценки конкретного объекта.
• Разрыв между этапами. Отдельные генератор и ранжировщик могут повторно обрабатывать одну историю и учить разные представления.
Чтобы решить эти проблемы, авторы предлагают интегрировать генерацию в ранжирование на архитектурном уровне. Так появился фреймворк OneRanker. Он состоит из трёх шагов.
Шаг 1. Основа генерации
OneRanker опирается на предыдущую работу Tencent — GPR. История пользователя представлена последовательностью разнородных токенов: пользователя (U), контента (C), контекста (X) и объектов (I). Декодер на основе HSTU обрабатывает эту последовательность, а авторегрессионный механизм multi-token prediction (MTP) позволяет за один проход модели параллельно строить несколько полных цепочек семантических ID.
Что происходит на втором шаге фреймворка, подробно разберём в следующем посте.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍6🔥3👏2🤩1