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
Разбор подготовил❣ Артём Матвеев
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
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤7🔥4💩1
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
Разбор подготовил❣ Руслан Кулиев
Сегодня разбираем свежую статью от Pinterest, которую недавно приняли на RecSys 2025.
Авторы делятся опытом построения foundation-модели. Вместо создания множества маленьких моделей, специализирующихся на отдельных задачах, они обучают одну большую: скармливают ей как можно больше данных о пользовательской активности, чтобы она начала выявлять закономерности в последовательностях. В контексте рекомендаций такими данными могут быть взаимодействия пользователей со всеми поверхностями приложения за длительный период времени.
Foundation-модели и большие претрейны уже давно хорошо зарекомендовали себя и в NLP, и в CV. Если дообучить для своих задач готовую GPT-подобную модель, которая многое знает о мире, результат вас вряд ли разочарует. К тому же, дообучение сильно дешевле обучения с нуля и быстрее дистилляции.
Однако в рекомендательных системах долгое время игнорировали этот подход. Исследователи из Pinterest утверждают, что они первые в индустрии, кто сделал полноценную foundation-модель. В качестве датасета для претрейна авторы собрали двухлетнюю историю взаимодействия пользователей с пинами на разных поверхностях, а во время файнтюна дообучили модель на специфическую поверхность.
При этом в попытке обучить и внедрить такую крупную структуру неизменно возникают следующие проблемы:
1. Косты. Большая модель не зря большая: инферить её дорого и долго.
2. Оптимизация входной информации. Важно не перегружать модель и при этом сохранять приемлемые косты. Чтобы повысить качество ответов, недостаточно просто сообщить, что пользователь взаимодействовал с определённой последовательностью айтемов — нужно передавать и дополнительные знания, при этом оставаясь в рамках практических ограничений.
3. Постоянное пополнение набора айтемов. Пользователи регулярно загружают в Pinterest новый контент: нужно научить модель адекватно оперировать незнакомыми, только что добавленными объектами.
По каждой из этих проблем авторы добиваются удовлетворительного решения. Продолжим разбор во второй части.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥7👍5💩1
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
Разбор подготовил❣ Руслан Кулиев
Продолжаем разбирать статью от 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
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🔥7❤6
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
Разбор подготовил❣ Сергей Макеев
Сегодня разберём статью 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
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤4💯3
RecGPT Technical Report, 1/2
Сегодня начинаем разбор недавнего техрепорта от Alibaba о новом подходе к рекомендациям RecGPT. В нём авторы предлагают по максимуму задействовать большие языковые модели.
Классические рекомендательные системы учатся в основном на логах кликов. Такой подход приводит к ряду ограничений: формируются «пузыри», когда пользователю постоянно показывают одно и то же; сложно работать с длинным хвостом товаров; возникают разные bias'ы (например, популярности). Но главное — при таком обучении теряется семантическая информация, а люди выбирают товары не только на основе кликов, а исходя из более сложных мотивов и контекстов.
В качестве решения Alibaba предлагают использовать LLM с ризонингом, чтобы модель не просто фиксировала клики, а пыталась понять, почему пользователь может захотеть тот или иной товар.
Но и тут свои сложности:
— LLM нужно адаптировать к конкретному домену;
— важно укладываться в ограничения по времени отклика и вычислительным ресурсам;
— по-прежнему сложно интегрироваться в индустриальные системы.
Пайплайн RecGPT состоит из четырёх частей:
1. User Interest Mining — извлечение интересов пользователя из истории;
2. Tag Prediction — генерация тегов (описаний желаемых товаров);
3. Item Retrieval — сопоставление тегов с реальными товарами;
4. Personalized Explanation — генерация объяснений, почему система рекомендует этот товар.
Каждый этап можно интерпретировать — это полезно и для пользователей (доверие к системе), и для разработчиков (удобнее отлаживать).
RecGPT внедрили в сценарий Guess What You Like (беззапросные рекомендации на taobao.com). В результате получили рост CTR, просмотров страниц и доли активных пользователей, а ещё увеличили разнообразие по категориям. Улучшения заметили и мерчанты: товары стали лучше доходить до целевой аудитории.
Alibaba заявляют, что их решение — первый в мире успешный деплой reasoning-LLM в рекомендательную систему.
В следующей части — подробнее об архитектуре рексистемы.
@RecSysChannel
Разбор подготовил❣ Виктор Януш
Сегодня начинаем разбор недавнего техрепорта от Alibaba о новом подходе к рекомендациям RecGPT. В нём авторы предлагают по максимуму задействовать большие языковые модели.
Классические рекомендательные системы учатся в основном на логах кликов. Такой подход приводит к ряду ограничений: формируются «пузыри», когда пользователю постоянно показывают одно и то же; сложно работать с длинным хвостом товаров; возникают разные bias'ы (например, популярности). Но главное — при таком обучении теряется семантическая информация, а люди выбирают товары не только на основе кликов, а исходя из более сложных мотивов и контекстов.
В качестве решения Alibaba предлагают использовать LLM с ризонингом, чтобы модель не просто фиксировала клики, а пыталась понять, почему пользователь может захотеть тот или иной товар.
Но и тут свои сложности:
— LLM нужно адаптировать к конкретному домену;
— важно укладываться в ограничения по времени отклика и вычислительным ресурсам;
— по-прежнему сложно интегрироваться в индустриальные системы.
Пайплайн RecGPT состоит из четырёх частей:
1. User Interest Mining — извлечение интересов пользователя из истории;
2. Tag Prediction — генерация тегов (описаний желаемых товаров);
3. Item Retrieval — сопоставление тегов с реальными товарами;
4. Personalized Explanation — генерация объяснений, почему система рекомендует этот товар.
Каждый этап можно интерпретировать — это полезно и для пользователей (доверие к системе), и для разработчиков (удобнее отлаживать).
RecGPT внедрили в сценарий Guess What You Like (беззапросные рекомендации на taobao.com). В результате получили рост CTR, просмотров страниц и доли активных пользователей, а ещё увеличили разнообразие по категориям. Улучшения заметили и мерчанты: товары стали лучше доходить до целевой аудитории.
Alibaba заявляют, что их решение — первый в мире успешный деплой reasoning-LLM в рекомендательную систему.
В следующей части — подробнее об архитектуре рексистемы.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11🔥7👍2🫡2
RecGPT Technical Report, 2/2
В первой части разбора рассказали об идее и результатах RecGPT. Теперь — детали реализации. Как мы уже упомянули, система состоит из четырёх ключевых компонентов.
User Interest Mining
Главная трудность оказалась в том, что у пользователей слишком длинные истории — в среднем больше 37 тысяч событий, что не помещается в контекст LLM. Авторы придумали механизм сжатия истории: они оставляют только самые информативные события — покупки, добавления в корзину, избранное, поисковые запросы, просмотр отзывов и подробных описаний. Все эти данные дополнительно агрегируются по времени: ближайшие дни учитываются подробно, а более старые периоды объединяются сначала в месяцы, а затем и в годы. Так история превращается в понятный текстовый нарратив, который можно подать на вход модели.
Параллельно Alibaba разработали task alignment framework. Они сформулировали 16 задач — от простых (например, определить категорию товара по запросу) до более сложных (выделение ключевых характеристик, определение релевантности). LLM обучали постепенно, чтобы адаптировать её к специфике рекомендательного домена.
Вдобавок сделали self-training evolution: модели генерировали гипотезы, которые затем фильтровали, чтобы убрать галлюцинации или слишком общие интересы, и использовали отобранное для дообучения. В итоге система научилась извлекать из истории осмысленные интересы, а 98% пользователей теперь помещаются в лимит контекста и на каждого удаётся предсказать в среднем 16 интересов.
Tag Prediction
На основе предсказанных интересов следующая модель формирует так называемые теги — текстовые описания того, что пользователь, возможно, захочет купить. Это не конкретные товары, а их обобщённые характеристики: например, «outdoor waterproof hiking boots». К тегам есть требования: они должны опираться на историю и интересы пользователя, быть конкретными, свежими и релевантными сезону. В среднем нужно получить не меньше пятидесяти тегов.
Для обучения используют два шага. Сначала pre-alignment, когда из названий товаров в истории составляются кандидаты для тегов. Затем self-training: система дообучается на собственных же генерациях, но перед этим данные чистят и перебалансируюют. Это нужно, чтобы популярные категории не полностью доминировали и модель не теряла разнообразие. Такой подход оказался эффективным: вырос hit rate — совпадения между предсказанными тегами и реальными товарами, которые позже были куплены или просмотрены.
Item Retrieval
Следующий этап — сопоставление тегов с конкретными товарами. Здесь Alibaba разработали архитектуру с тремя башнями: пользовательской, товарной и теговой. Она учитывает как семантическую близость, так и коллаборативные сигналы. Для обучения используют выборку с положительными и отрицательными примерами: система учится различать товары из нужной категории и из посторонних. На этапе инференса представления из разных башен объединяются, что позволяет более точно матчить интересы и товары.
Personalized Explanation
Наконец, один из самых заметных элементов — генерация объяснений. Вместо того чтобы каждый раз формировать объяснение заново для пары «пользователь-товар», в Alibaba сделали ставку на связку «интерес-товар». Это экономит ресурсы и сохраняет персонализацию. Датасет для обучения объяснений собирали через другую LLM и фильтровали от галлюцинаций. Дополнительный self-training помог адаптировать модель к новым ситуациям. В итоге рекомендации сопровождаются короткими и понятными комментариями вроде «Мы показали вам этот товар, потому что вы недавно искали похожие вещи для путешествий».
В итоге, RecGPT — это не просто «LLM в рексистеме», а целый пайплайн: от сжатия пользовательской истории и извлечения интересов до генерации тегов, матчинга и интерпретируемых объяснений.
@RecSysChannel
Разбор подготовил❣ Виктор Януш
В первой части разбора рассказали об идее и результатах RecGPT. Теперь — детали реализации. Как мы уже упомянули, система состоит из четырёх ключевых компонентов.
User Interest Mining
Главная трудность оказалась в том, что у пользователей слишком длинные истории — в среднем больше 37 тысяч событий, что не помещается в контекст LLM. Авторы придумали механизм сжатия истории: они оставляют только самые информативные события — покупки, добавления в корзину, избранное, поисковые запросы, просмотр отзывов и подробных описаний. Все эти данные дополнительно агрегируются по времени: ближайшие дни учитываются подробно, а более старые периоды объединяются сначала в месяцы, а затем и в годы. Так история превращается в понятный текстовый нарратив, который можно подать на вход модели.
Параллельно Alibaba разработали task alignment framework. Они сформулировали 16 задач — от простых (например, определить категорию товара по запросу) до более сложных (выделение ключевых характеристик, определение релевантности). LLM обучали постепенно, чтобы адаптировать её к специфике рекомендательного домена.
Вдобавок сделали self-training evolution: модели генерировали гипотезы, которые затем фильтровали, чтобы убрать галлюцинации или слишком общие интересы, и использовали отобранное для дообучения. В итоге система научилась извлекать из истории осмысленные интересы, а 98% пользователей теперь помещаются в лимит контекста и на каждого удаётся предсказать в среднем 16 интересов.
Tag Prediction
На основе предсказанных интересов следующая модель формирует так называемые теги — текстовые описания того, что пользователь, возможно, захочет купить. Это не конкретные товары, а их обобщённые характеристики: например, «outdoor waterproof hiking boots». К тегам есть требования: они должны опираться на историю и интересы пользователя, быть конкретными, свежими и релевантными сезону. В среднем нужно получить не меньше пятидесяти тегов.
Для обучения используют два шага. Сначала pre-alignment, когда из названий товаров в истории составляются кандидаты для тегов. Затем self-training: система дообучается на собственных же генерациях, но перед этим данные чистят и перебалансируюют. Это нужно, чтобы популярные категории не полностью доминировали и модель не теряла разнообразие. Такой подход оказался эффективным: вырос hit rate — совпадения между предсказанными тегами и реальными товарами, которые позже были куплены или просмотрены.
Item Retrieval
Следующий этап — сопоставление тегов с конкретными товарами. Здесь Alibaba разработали архитектуру с тремя башнями: пользовательской, товарной и теговой. Она учитывает как семантическую близость, так и коллаборативные сигналы. Для обучения используют выборку с положительными и отрицательными примерами: система учится различать товары из нужной категории и из посторонних. На этапе инференса представления из разных башен объединяются, что позволяет более точно матчить интересы и товары.
Personalized Explanation
Наконец, один из самых заметных элементов — генерация объяснений. Вместо того чтобы каждый раз формировать объяснение заново для пары «пользователь-товар», в Alibaba сделали ставку на связку «интерес-товар». Это экономит ресурсы и сохраняет персонализацию. Датасет для обучения объяснений собирали через другую LLM и фильтровали от галлюцинаций. Дополнительный self-training помог адаптировать модель к новым ситуациям. В итоге рекомендации сопровождаются короткими и понятными комментариями вроде «Мы показали вам этот товар, потому что вы недавно искали похожие вещи для путешествий».
В итоге, RecGPT — это не просто «LLM в рексистеме», а целый пайплайн: от сжатия пользовательской истории и извлечения интересов до генерации тегов, матчинга и интерпретируемых объяснений.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15❤5👍4
Large Foundation Model for Ads Recommendation
Сегодня разбираем свежую статью Tencent с интригующим названием, содержащим слова large и foundation. Обращает на себя внимание и список авторов: он очень длинный, что обычно указывает на масштабный внутренний проект, важный для компании.
В работе предлагают инкорпорировать большую вычислительно дорогую foundation-модель в более компактные CTR-модели ранжирования. Но авторов не устраивает простое подключение выходов в качестве эмбеддингов или скалярных признаков. Инженеры хотят использовать знания большой модели более умным способом, сохраняя эффективность в проде.
Авторы пишут, что обычно большие foundation-модели используют только user-представления, игнорируя другие важные сигналы. Предлагается перенести в downstream-модель все три вида: user-, item- и user-item-представления.
Напрямую работать с сырыми кросс-представлениями невозможно: они жёстко привязаны к конкретным парам user–item, и для каждой такой пары пришлось бы вычислять большую модель в онлайне. Именно этого авторы стараются избежать, предлагая обновлять и хранить агрегированные user- и item-векторы асинхронно.
Интересная находка: лучшие результаты даёт не использование последнего слоя модели, а извлечение представлений из предпоследнего, хотя замеры противоречивые — на графиках виден шум.
Архитектура Triple Tower
Для обучения используется так называемый triple tower design:
— user-башня,
— item-башня,
— mix-tower для их взаимодействия.
При этом архитектура разделена на две ветви (dual-branch design): одна обучается на органическом контенте (просмотры, лайки, комментарии), другая — на рекламных сэмплах (клики, конверсии). User- и item-вектора остаются общими, а cross-вектор извлекается только из рекламной ветви, так как он ближе к целевым downstream-задачам.
Авторы описывают три способа интеграции foundation-модели в downstream CTR-модель: добавление представлений в качестве новых фичей, подключение блока обработки внутри архитектуры, использование всей большой модели для генерации кандидатов.
Простое добавление эмбеддингов в downstream-модель работает плохо: пробовали и линейные проекции, и alignment-лоссы, но улучшений не добились. Вместо этого применяют другой приём: каждую входную фичу комбинируют с представлением из foundation-модели с помощью покомпонентного умножения и нелинейности. Таким образом, user-item-вектор встраивается в модель уже на уровне входных признаков.
Эксперименты и результаты
Валидацию делали только на внутренних данных Tencent: больших датасетах с рекламными и органическими действиями, онлайн-A/B-тестах. Авторы пишут что систему внедрили уже в десяти с лишним продуктах экосистемы и получили рост GMV на 2,45% по всей платформе.
Больше о внедрении фундаментальных моделей применительно к экосистеме Яндекса можно узнать в канале руководителя службы рекомендательных технологий Николая Савушкина — @light_from_black_box.
@RecSysChannel
Разбор подготовил❣ Николай Савушкин
Сегодня разбираем свежую статью Tencent с интригующим названием, содержащим слова large и foundation. Обращает на себя внимание и список авторов: он очень длинный, что обычно указывает на масштабный внутренний проект, важный для компании.
В работе предлагают инкорпорировать большую вычислительно дорогую foundation-модель в более компактные CTR-модели ранжирования. Но авторов не устраивает простое подключение выходов в качестве эмбеддингов или скалярных признаков. Инженеры хотят использовать знания большой модели более умным способом, сохраняя эффективность в проде.
Авторы пишут, что обычно большие foundation-модели используют только user-представления, игнорируя другие важные сигналы. Предлагается перенести в downstream-модель все три вида: user-, item- и user-item-представления.
Напрямую работать с сырыми кросс-представлениями невозможно: они жёстко привязаны к конкретным парам user–item, и для каждой такой пары пришлось бы вычислять большую модель в онлайне. Именно этого авторы стараются избежать, предлагая обновлять и хранить агрегированные user- и item-векторы асинхронно.
Интересная находка: лучшие результаты даёт не использование последнего слоя модели, а извлечение представлений из предпоследнего, хотя замеры противоречивые — на графиках виден шум.
Архитектура Triple Tower
Для обучения используется так называемый triple tower design:
— user-башня,
— item-башня,
— mix-tower для их взаимодействия.
При этом архитектура разделена на две ветви (dual-branch design): одна обучается на органическом контенте (просмотры, лайки, комментарии), другая — на рекламных сэмплах (клики, конверсии). User- и item-вектора остаются общими, а cross-вектор извлекается только из рекламной ветви, так как он ближе к целевым downstream-задачам.
Авторы описывают три способа интеграции foundation-модели в downstream CTR-модель: добавление представлений в качестве новых фичей, подключение блока обработки внутри архитектуры, использование всей большой модели для генерации кандидатов.
Простое добавление эмбеддингов в downstream-модель работает плохо: пробовали и линейные проекции, и alignment-лоссы, но улучшений не добились. Вместо этого применяют другой приём: каждую входную фичу комбинируют с представлением из foundation-модели с помощью покомпонентного умножения и нелинейности. Таким образом, user-item-вектор встраивается в модель уже на уровне входных признаков.
Эксперименты и результаты
Валидацию делали только на внутренних данных Tencent: больших датасетах с рекламными и органическими действиями, онлайн-A/B-тестах. Авторы пишут что систему внедрили уже в десяти с лишним продуктах экосистемы и получили рост GMV на 2,45% по всей платформе.
Больше о внедрении фундаментальных моделей применительно к экосистеме Яндекса можно узнать в канале руководителя службы рекомендательных технологий Николая Савушкина — @light_from_black_box.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13❤6👍6💩1
RecSys 2025: интересные статьи первого дня
Вчера в Праге стартовала конференция RecSys 2025. Первый день был посвящён в основном воркшопам. В промежутках можно было посмотреть постеры и пообщаться с авторами. Именно этим занимались инженеры Яндекса, которые уже разобрали несколько интересных работ.
In-Context Learning for Addressing User Cold-Start in Sequential Movie Recommenders
Авторы из Amazon используют sequential models (модели, основанные на цепочке событий пользователя) для задачи рекомендации видео, так как такие модели дают лучшее качество. В своих подходах указывают Recformer, SASRec, GRU4Rec, Tiger, Liger. Однако подобные модели чувствительны к проблеме холодного старта. Когда у пользователя ещё нет никакой истории, что ему показать? По данным авторов, таких пользователей — большинство: 47%, а еще 46% — имеют длину истории до пяти событий.
В качестве решения исследователи предлагают добавить к реальной истории пользователя выдуманную LLM (imaginary interactions). Её получают с помощью специально подготовленного промпта. Причём утверждают, что не так страшно, если модель сгаллюцинирует и вернёт несуществующие фильмы, так как это не финальная последовательность. Затем происходит объединение выдуманной истории с реальной. В работе используют два подхода:
— early fusion — просто объединяют выдуманную историю с реальной (последняя — реальная), формируя одну длинную последовательность;
— late fusion — генерируют k последовательностей независимо, каждую продолжают реальной, а потом делают avg pooling над эмбедами.
В экспериментах авторы репортят два датасета: публичный the MovieLens 1M и проприетарный the Amazon Proprietary. Early fusion лучше себя показал на публичном датасете, причём бустит он именно «холодных» пользователей, тогда как на более «горячих» его влияние пропадает. А вот на проприетарном датасете лучше сработала late fusion. Это объясняют тем, что подход добавляет разнообразия выдаче.
Следующие шаги:
— из k произвольных фильмов заданного жанра предложить LLM выбрать подходящий;
— добавить RAG;
— собирать информацию для «холодных» пользователей путём опроса.
DenseRec: Revisiting Dense Content Embeddings for Sequential Transformer-based Recommendation
Основные идеи:
— SASRec хорошо работает, но плохо справляется с cold items. Надо поправить эту проблему (другие подходы, например, semantic IDs требуют сильного изменения всего пайплайна).
— Предлагается использовать контентные фичи. Но замена «в лоб» просаживает качество.
— Предлагается выучить модель, которая будет работать поверх всё той же embedding table по ID в части случаев, но также научиться переводить в это пространство контентные фичи.
— Формально при обучении подбрасывают монетку для каждой позиции в последовательности айтемов, с вероятностью p берут эмбед из таблицы эмбеддингов, с вероятностью (1-p) берут конктентные фичи и с помощью простой модели (в данном случае — линейной проекции) переводят контентные эмбеды в пространство обычных.
— При инференсе для знакомых ID всегда используют таблицу эмбедов, для новых — конкретные фичи и линейный слой проекции.
— В экспериментах на датасете Amazon авторы показывают значимое улучшение метрик, причём основной прирост — не на «холодных» документах. Авторы объясняют это тем, что подход обучения с использованием контентных фичей не только улучшает их представление (new items as target), но и улучшает качество самой последовательности (new items in the sequence).
@RecSysChannel
Статьи заметил❣ Артём Ваншулин
Вчера в Праге стартовала конференция RecSys 2025. Первый день был посвящён в основном воркшопам. В промежутках можно было посмотреть постеры и пообщаться с авторами. Именно этим занимались инженеры Яндекса, которые уже разобрали несколько интересных работ.
In-Context Learning for Addressing User Cold-Start in Sequential Movie Recommenders
Авторы из Amazon используют sequential models (модели, основанные на цепочке событий пользователя) для задачи рекомендации видео, так как такие модели дают лучшее качество. В своих подходах указывают Recformer, SASRec, GRU4Rec, Tiger, Liger. Однако подобные модели чувствительны к проблеме холодного старта. Когда у пользователя ещё нет никакой истории, что ему показать? По данным авторов, таких пользователей — большинство: 47%, а еще 46% — имеют длину истории до пяти событий.
В качестве решения исследователи предлагают добавить к реальной истории пользователя выдуманную LLM (imaginary interactions). Её получают с помощью специально подготовленного промпта. Причём утверждают, что не так страшно, если модель сгаллюцинирует и вернёт несуществующие фильмы, так как это не финальная последовательность. Затем происходит объединение выдуманной истории с реальной. В работе используют два подхода:
— early fusion — просто объединяют выдуманную историю с реальной (последняя — реальная), формируя одну длинную последовательность;
— late fusion — генерируют k последовательностей независимо, каждую продолжают реальной, а потом делают avg pooling над эмбедами.
В экспериментах авторы репортят два датасета: публичный the MovieLens 1M и проприетарный the Amazon Proprietary. Early fusion лучше себя показал на публичном датасете, причём бустит он именно «холодных» пользователей, тогда как на более «горячих» его влияние пропадает. А вот на проприетарном датасете лучше сработала late fusion. Это объясняют тем, что подход добавляет разнообразия выдаче.
Следующие шаги:
— из k произвольных фильмов заданного жанра предложить LLM выбрать подходящий;
— добавить RAG;
— собирать информацию для «холодных» пользователей путём опроса.
DenseRec: Revisiting Dense Content Embeddings for Sequential Transformer-based Recommendation
Основные идеи:
— SASRec хорошо работает, но плохо справляется с cold items. Надо поправить эту проблему (другие подходы, например, semantic IDs требуют сильного изменения всего пайплайна).
— Предлагается использовать контентные фичи. Но замена «в лоб» просаживает качество.
— Предлагается выучить модель, которая будет работать поверх всё той же embedding table по ID в части случаев, но также научиться переводить в это пространство контентные фичи.
— Формально при обучении подбрасывают монетку для каждой позиции в последовательности айтемов, с вероятностью p берут эмбед из таблицы эмбеддингов, с вероятностью (1-p) берут конктентные фичи и с помощью простой модели (в данном случае — линейной проекции) переводят контентные эмбеды в пространство обычных.
— При инференсе для знакомых ID всегда используют таблицу эмбедов, для новых — конкретные фичи и линейный слой проекции.
— В экспериментах на датасете Amazon авторы показывают значимое улучшение метрик, причём основной прирост — не на «холодных» документах. Авторы объясняют это тем, что подход обучения с использованием контентных фичей не только улучшает их представление (new items as target), но и улучшает качество самой последовательности (new items in the sequence).
@RecSysChannel
Статьи заметил
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15🔥8👍3😱1
Что обсуждают на RecSys 2025
Прямо сейчас в Праге проходит 19-я международная конференция о рекомендательных системах. По традиции, делимся с вами самым интересным. Вот как прошли воркшопы, на которых побывали наши коллеги.
Practical Bandits: An Industry Perspective
Этот доклад мы услышали на воркшопе CONSEQUENCES’25. Сначала спикеры разобрали различия между off-policy- и on-policy-стратегиями и подробно рассказали, что такое importance weighting, Inverse Propensity Scoring (IPS) и для чего они используются. А потом перешли к сбору данных:
— Показали методы сбора: ε-greedy, softmax и гибридный подход.
— Ввели effective sample size — оценку того, сколько данных нужно собрать.
— Уточнили, какие данные необходимо логировать: контекст, все возможные и выбранные действия, награду и распределение вероятностей.
После этого перешли к тому, что делать, если некоторые действия блокируются (например, из-за бизнес-логики) и как выявлять смещение с помощью control variates.
Отдельно отметили проблему symbiosis bias — явление, когда разные политики начинают зависеть друг от друга из-за обучения на всех данных что есть. А завершили всё обсуждением большой кардинальности множества действий и решениям проблем, которые из-за этого возникают.
Gen AI for E-commerce
Докладов было много. Несколько спикеров поделились опытом того, как используют LLM в E-com: генерируют фичи для классического ML, пишут заголовки для e-mail-рассылок, создают поисковые саджесты, размечают данные для active learning, собирают системы из нескольких агентов, чтобы генерировать тексты, привлекающие пользователей.
Доклады интересные, где-то перекликаются с тем, что мы пробуем делать в Яндекс Go. Но ни в одном из выступлений не услышал, как применение LLM бустит метрики, связанные с деньгами — в лучшем случае менялись прокси-метрики.
Как я понял (и уточнил на стендах), самое популярное решение — не хостить LLM самим, а ходить в API готовых ИИ и платить за токены. Было весело, когда у докладчика, который рассказывал про LLM для active learning, спросили, сколько они потратили на OpenAI API — в выступлении упоминалось 1+ млн запросов.
Немного удивило, что существенная часть докладчиков не тестировала свои решения в A/B, только планирует сделать это в будущем.
На конференции в этом году — не протолкнуться. Кому-то даже пришлось обедать на лестнице. Кто знает, может, именно эти воркшопы коллеги обсуждают за трапезой 👀
@RecSysChannel
Суммаризировали для вас воркшопы❣ Михаил Сёмин и Алексей Ельчанинов
Сгенерировал фото❣ Андрей Мищенко
Прямо сейчас в Праге проходит 19-я международная конференция о рекомендательных системах. По традиции, делимся с вами самым интересным. Вот как прошли воркшопы, на которых побывали наши коллеги.
Practical Bandits: An Industry Perspective
Этот доклад мы услышали на воркшопе CONSEQUENCES’25. Сначала спикеры разобрали различия между off-policy- и on-policy-стратегиями и подробно рассказали, что такое importance weighting, Inverse Propensity Scoring (IPS) и для чего они используются. А потом перешли к сбору данных:
— Показали методы сбора: ε-greedy, softmax и гибридный подход.
— Ввели effective sample size — оценку того, сколько данных нужно собрать.
— Уточнили, какие данные необходимо логировать: контекст, все возможные и выбранные действия, награду и распределение вероятностей.
После этого перешли к тому, что делать, если некоторые действия блокируются (например, из-за бизнес-логики) и как выявлять смещение с помощью control variates.
Отдельно отметили проблему symbiosis bias — явление, когда разные политики начинают зависеть друг от друга из-за обучения на всех данных что есть. А завершили всё обсуждением большой кардинальности множества действий и решениям проблем, которые из-за этого возникают.
Gen AI for E-commerce
Докладов было много. Несколько спикеров поделились опытом того, как используют LLM в E-com: генерируют фичи для классического ML, пишут заголовки для e-mail-рассылок, создают поисковые саджесты, размечают данные для active learning, собирают системы из нескольких агентов, чтобы генерировать тексты, привлекающие пользователей.
Доклады интересные, где-то перекликаются с тем, что мы пробуем делать в Яндекс Go. Но ни в одном из выступлений не услышал, как применение LLM бустит метрики, связанные с деньгами — в лучшем случае менялись прокси-метрики.
Как я понял (и уточнил на стендах), самое популярное решение — не хостить LLM самим, а ходить в API готовых ИИ и платить за токены. Было весело, когда у докладчика, который рассказывал про LLM для active learning, спросили, сколько они потратили на OpenAI API — в выступлении упоминалось 1+ млн запросов.
Немного удивило, что существенная часть докладчиков не тестировала свои решения в A/B, только планирует сделать это в будущем.
На конференции в этом году — не протолкнуться. Кому-то даже пришлось обедать на лестнице. Кто знает, может, именно эти воркшопы коллеги обсуждают за трапезой 👀
@RecSysChannel
Суммаризировали для вас воркшопы
Сгенерировал фото
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19🔥6❤5🤩2
Продолжаем делиться работами с RecSys 2025
Второй день конференции запомнился нам не только выступлением Александра Плошкина с oral'ом о датасете Yambda, но и интересными статьями. Некоторые из них собрали в этом посте.
LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders
Авторы из ByteDance обучают модель в неавторегрессивном режиме на 10 000 событий, используя 10 000 GPU. Поскольку исследователи не связаны авторегрессивной схемой обучения (HSTU, Argus), они используют глобальные токены с эмбеддингом пользователя, счётчиками и т. п. Также применяется target-aware-подход: эмбеддинг целевого товара подаётся как глобальный токен.
В первом слое задействован cross-attention: в запросах (query) — глобальные токены и последние события, в ключах (key) — вся последовательность. Таким образом, последовательность сжимается до числа query-токенов на выходе слоя cross-attention. Далее идут стандартные слои self-attention с каузальной маской. Каузальная маска нужна, чтобы на инференсе переиспользовать KV-кэш.
Enhancing Embedding Representation Stability in Recommendation Systems with Semantic ID
Исследователи рассказали, как применяют семантический ID для повышения стабильности рекламных моделей. В рекламе крайне неравномерное распределение айтемов в датасете, к тому же они быстро меняются (примерно половина корпуса обновляется за шесть дней). Поэтому модели с обычными или случайными ID со временем деградируют.
Как решение предложен семантический ID, который создаётся на основе контента объявления (текста и картинок). В продакшене он генерируется из шести уровней иерархии (codebooks), из которых составляется префикс разной длины. Это позволяет похожим по смыслу объявлениям «обмениваться знаниями» и улучшает офлайн-метрики для новых айтемов и для хвоста распределения. Наибольший выигрыш виден в моделях, анализирующих историю взаимодействий пользователя.
Чтобы оценить влияние на стабильность, замеряют изменение скора модели при замене ID на его точную копию. В онлайне показано, что использование семантического ID снижает изменение скора на 43%. Итог: рост целевой метрики на 0,15%.
Generalized User Representations for Large-Scale Recommendations and Downstream Tasks
Интересный постер от Spotify. Авторы дообучают модели с дневным и даже более коротким интервалом. Для аудио и коллаборативных эмбеддингов используются одинаковые по размерности векторы — всего 80. При этом исследователи отмечают, что без стабилизации выходных эмбедов (как для аудио, так и для коллаборативных) система вообще не работала.
Отдельно видно, что старых пользователей специально не обрабатывают: модель всё ещё пытается восстанавливать очень давний онбординг, хотя это иногда даёт негативный эффект. Вероятно, основной акцент сделан на работу с холодными пользователями.
Любопытно, что для обучения используется автоэнкодер, причём его тренируют ежедневно всего на одном дне данных. Для аудиоэмбедов применяется трансформер-энкодер с выборкой из истории, чтобы оставить только наиболее релевантные треки.
@RecSysChannel
Работами поделились❣ Александр Шуваев, Пётр Зайдель, Даниил Бурлаков
Второй день конференции запомнился нам не только выступлением Александра Плошкина с oral'ом о датасете Yambda, но и интересными статьями. Некоторые из них собрали в этом посте.
LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders
Авторы из ByteDance обучают модель в неавторегрессивном режиме на 10 000 событий, используя 10 000 GPU. Поскольку исследователи не связаны авторегрессивной схемой обучения (HSTU, Argus), они используют глобальные токены с эмбеддингом пользователя, счётчиками и т. п. Также применяется target-aware-подход: эмбеддинг целевого товара подаётся как глобальный токен.
В первом слое задействован cross-attention: в запросах (query) — глобальные токены и последние события, в ключах (key) — вся последовательность. Таким образом, последовательность сжимается до числа query-токенов на выходе слоя cross-attention. Далее идут стандартные слои self-attention с каузальной маской. Каузальная маска нужна, чтобы на инференсе переиспользовать KV-кэш.
Enhancing Embedding Representation Stability in Recommendation Systems with Semantic ID
Исследователи рассказали, как применяют семантический ID для повышения стабильности рекламных моделей. В рекламе крайне неравномерное распределение айтемов в датасете, к тому же они быстро меняются (примерно половина корпуса обновляется за шесть дней). Поэтому модели с обычными или случайными ID со временем деградируют.
Как решение предложен семантический ID, который создаётся на основе контента объявления (текста и картинок). В продакшене он генерируется из шести уровней иерархии (codebooks), из которых составляется префикс разной длины. Это позволяет похожим по смыслу объявлениям «обмениваться знаниями» и улучшает офлайн-метрики для новых айтемов и для хвоста распределения. Наибольший выигрыш виден в моделях, анализирующих историю взаимодействий пользователя.
Чтобы оценить влияние на стабильность, замеряют изменение скора модели при замене ID на его точную копию. В онлайне показано, что использование семантического ID снижает изменение скора на 43%. Итог: рост целевой метрики на 0,15%.
Generalized User Representations for Large-Scale Recommendations and Downstream Tasks
Интересный постер от Spotify. Авторы дообучают модели с дневным и даже более коротким интервалом. Для аудио и коллаборативных эмбеддингов используются одинаковые по размерности векторы — всего 80. При этом исследователи отмечают, что без стабилизации выходных эмбедов (как для аудио, так и для коллаборативных) система вообще не работала.
Отдельно видно, что старых пользователей специально не обрабатывают: модель всё ещё пытается восстанавливать очень давний онбординг, хотя это иногда даёт негативный эффект. Вероятно, основной акцент сделан на работу с холодными пользователями.
Любопытно, что для обучения используется автоэнкодер, причём его тренируют ежедневно всего на одном дне данных. Для аудиоэмбедов применяется трансформер-энкодер с выборкой из истории, чтобы оставить только наиболее релевантные треки.
@RecSysChannel
Работами поделились
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍6🔥6