Привет! Это канал, посвященный рекомендательным системам. Здесь мы, RecSys-специалисты из Яндекса, будем делиться опытом, рассказывать об интересных случаях из практики, искать ответы на острые вопросы и комментировать свежие статьи. Подписывайтесь, если вам близка тема RecSys и вы не прочь обсудить её в уютной компании единомышленников.
Персонализация рекламы в Meta*
Meta — корпорация с огромным трафиком и сотнями сервисов. Учить user-эмбеддинги под каждую задачу непрактично. Для решения проблемы создан фреймворк SUM (Scaling User Modeling), а для адаптации к изменениям user-фич и поддержки актуальности эмбеддингов — асинхронная онлайн-платформа SUM (SOAP). Они работают в проде и, по словам авторов статьи, дают хороший прирост конверсий и экономят 15,3% затрат на инфраструктуру.
Две башни
В модели 2 главные сущности: башни user и mix. В user-башне собирают фичи — в сумме 1600. Они делятся на dense и sparse — во вторую категорию попадают, например, UserID и PageID. В interaction-модулях применяют DCN-модель и MLP-миксер.
На mix подают результаты в виде двух эмбеддингов размерностью в 96. Они джойнятся с фичами баннера. Обучают mix с помощью multi-task cross-entropy loss. Сюда осознанно не передают user-фичи, «мотивируя» user-башню узнавать о пользователе как можно больше.
SOAP
SOAP получает запрос, по которому из Feature Store достаются и усредняются 2 предыдущих user-эмбеддинга. Их отправляют в downstream-модель — она показывает рекламу. В то же время асинхронно вычисляют и записывают текущие эмбеддинги. Благодаря этому модель получает данные за 30 мс.
Возможная проблема — Embedding Distribution Shift. Появляются новые ID, с которыми юзеры не взаимодействовали, а существующие — устаревают. Поэтому при выкатке новой версии эмбеддингов их логируют. Мы спрашивали авторов, нет ли у них Feature Store с тайм-машиной для расчёта эмбеддингов. Ответ — нет.
Дообучение
Команда попробовала 4 разных подхода к дообучению модели:
— Frozen User Model — дообучение раз в месяц;
— Offline Batch — обновление раз в день;
— Online Real-Time Serving — обновление текущих эмбеддингов;
— Async Online Serving — тот самый SOAP.
В статье есть результаты экспериментов со всеми подходами. Обсудим в комментариях?
Разбор подготовил ❣ Константин Ширшов
@RecSysChannel
___
Meta признана экстремистской организацией, а Facebook и Instagram запрещены на территории РФ
Meta — корпорация с огромным трафиком и сотнями сервисов. Учить user-эмбеддинги под каждую задачу непрактично. Для решения проблемы создан фреймворк SUM (Scaling User Modeling), а для адаптации к изменениям user-фич и поддержки актуальности эмбеддингов — асинхронная онлайн-платформа SUM (SOAP). Они работают в проде и, по словам авторов статьи, дают хороший прирост конверсий и экономят 15,3% затрат на инфраструктуру.
Две башни
В модели 2 главные сущности: башни user и mix. В user-башне собирают фичи — в сумме 1600. Они делятся на dense и sparse — во вторую категорию попадают, например, UserID и PageID. В interaction-модулях применяют DCN-модель и MLP-миксер.
На mix подают результаты в виде двух эмбеддингов размерностью в 96. Они джойнятся с фичами баннера. Обучают mix с помощью multi-task cross-entropy loss. Сюда осознанно не передают user-фичи, «мотивируя» user-башню узнавать о пользователе как можно больше.
SOAP
SOAP получает запрос, по которому из Feature Store достаются и усредняются 2 предыдущих user-эмбеддинга. Их отправляют в downstream-модель — она показывает рекламу. В то же время асинхронно вычисляют и записывают текущие эмбеддинги. Благодаря этому модель получает данные за 30 мс.
Возможная проблема — Embedding Distribution Shift. Появляются новые ID, с которыми юзеры не взаимодействовали, а существующие — устаревают. Поэтому при выкатке новой версии эмбеддингов их логируют. Мы спрашивали авторов, нет ли у них Feature Store с тайм-машиной для расчёта эмбеддингов. Ответ — нет.
Дообучение
Команда попробовала 4 разных подхода к дообучению модели:
— Frozen User Model — дообучение раз в месяц;
— Offline Batch — обновление раз в день;
— Online Real-Time Serving — обновление текущих эмбеддингов;
— Async Online Serving — тот самый SOAP.
В статье есть результаты экспериментов со всеми подходами. Обсудим в комментариях?
Разбор подготовил ❣ Константин Ширшов
@RecSysChannel
___
Meta признана экстремистской организацией, а Facebook и Instagram запрещены на территории РФ
❤5👍2
EBR в рекомендательных системах: перспективы мультизадачности
Статья о любопытном подходе к EBR (Embedding-based retrieval) для учёта нескольких интересов пользователя. Авторы не просто растят diversity и fairness, но и утверждают, что увеличивают общее качество. В статье это показано на примере SASRec, но в теории подход сработает для любых трансформеров над историей пользователя.
Суть — в кластеризации исходного множества айтемов на подмножества, в которые на этапе retrieval ходят отдельными kNN. При этом в каждом кластере обучают отдельный таск и рассматривают задачу в целом как multi-tasking learning (MTL).
Это решает проблему классического обучения на всем множестве айтемов с семплированием негативов, где одновременно происходит дискриминация простых и сложных негативов, что отрицательно влияет на качество, поскольку модель имеет дело с конфликтующими задачами.
В экспериментах авторы проводили кластеризацию через K-means на Word2Vec, но также можно использовать уже имеющееся in-house разбиение документов на категории.
Три подхода к MTL
В статье описано три варианта реализации multi-tasking learning. Первый подход — наивный, где на вход добавляется ещё один обучаемый вектор. Работает это не очень хорошо — у модели не получается выучить взаимодействия между фичами.
Вторая реализация оказалась удачной — покомпонентное умножение обучаемого вектора на каждый из эмбеддингов истории пользователя. Это немного похоже на attention, хотя есть и различия — умножение, вероятно, даёт более общую модель.
Третий подход — MoE (Mixture of Experts), где используется несколько специализированных сетей — экспертов — для решения одной задачи. Он работает лучше, чем наивный multi-tasking, но хуже, чем покомпонентное умножение, и получается дороже по времени обучения.
По нашему мнению, подход с разбиением на кластеры будет полезен не только в сценариях с рекомендациями на всём множестве айтемов, но и для конкретных срезов — то есть рекомендаций или поиска внутри категорий.
@RecSysChannel
Разбор подготовил❣ Артём Мышкин
Статья о любопытном подходе к EBR (Embedding-based retrieval) для учёта нескольких интересов пользователя. Авторы не просто растят diversity и fairness, но и утверждают, что увеличивают общее качество. В статье это показано на примере SASRec, но в теории подход сработает для любых трансформеров над историей пользователя.
Суть — в кластеризации исходного множества айтемов на подмножества, в которые на этапе retrieval ходят отдельными kNN. При этом в каждом кластере обучают отдельный таск и рассматривают задачу в целом как multi-tasking learning (MTL).
Это решает проблему классического обучения на всем множестве айтемов с семплированием негативов, где одновременно происходит дискриминация простых и сложных негативов, что отрицательно влияет на качество, поскольку модель имеет дело с конфликтующими задачами.
В экспериментах авторы проводили кластеризацию через K-means на Word2Vec, но также можно использовать уже имеющееся in-house разбиение документов на категории.
Три подхода к MTL
В статье описано три варианта реализации multi-tasking learning. Первый подход — наивный, где на вход добавляется ещё один обучаемый вектор. Работает это не очень хорошо — у модели не получается выучить взаимодействия между фичами.
Вторая реализация оказалась удачной — покомпонентное умножение обучаемого вектора на каждый из эмбеддингов истории пользователя. Это немного похоже на attention, хотя есть и различия — умножение, вероятно, даёт более общую модель.
Третий подход — MoE (Mixture of Experts), где используется несколько специализированных сетей — экспертов — для решения одной задачи. Он работает лучше, чем наивный multi-tasking, но хуже, чем покомпонентное умножение, и получается дороже по времени обучения.
По нашему мнению, подход с разбиением на кластеры будет полезен не только в сценариях с рекомендациями на всём множестве айтемов, но и для конкретных срезов — то есть рекомендаций или поиска внутри категорий.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
Трансформеры в рекомендательных системах
Высокая гетерогенность фичей мешает использовать трансформеры в рекомендательных системах. Ресёрчеры из Google поделились статьёй, где предложили решение: модифицированный attention-слой позволил уловить связи, важные для предсказания итогового таргета. В тестах подход показал рост ключевых метрик (клики, покупки) — например, +0,4% по сравнению с DCN.
Подготовка фичей
На вход модели подаются cat- и dense-фичи. Cat-фичи обрабатываются стандартно (для них строятся обучаемые эмбеддинги), а с dense-фичами поступают чуть сложнее: их нормализуют, конкатенируют, применяют линейное преобразование, а потом сплитуют по D — внутренней размерности трансформера. Так фичей становится меньше.
Heterogeneous Attention Layer
Здесь матрицы query, key и value (QKV) считают отдельно для каждой фичи. Чтобы вычислить итоговый вектор для токена, вектора со всех голов, отвечающих фичам, конкатенируются и умножаются на матрицы.
Затем данные идут на Feed Forward-слой (FFN) с активацией GELU. Полученный вектор и будет выходом attention-слоя. Количество операций по сравнению с обычным трансформером не растёт, увеличивается лишь число параметров.
Hiformer
Чтобы уловить сложные взаимодействия, систему снова модифицируют — создают одну большую матрицу фичей. Затем конкатенируют все фичи каждой головы, умножают их на матрицу и получают модифицированные вектора. Благодаря этому получается выявить новые закономерности и связи, в т. ч. между composite-фичами и task-эмбеддингами.
Оптимизация
С большой матрицей трансформер становится тяжёлым с точки зрения latency — его нужно оптимизировать. Авторы используют низкоранговое разложение и прунинг последнего слоя. В первом случаем мы уменьшаем сложность за счёт разложения большой матрицы на две матрицы меньшего ранга.
Прунинг выполняется на последнем слое, где можно обучать таргет по task-эмбеддингам. Обычно итоговых задач намного меньше, чем фичей, что снижает сложность матричных умножений.
@RecSysChannel
Разбор подготовила❣ Маргарита Мишустина
Высокая гетерогенность фичей мешает использовать трансформеры в рекомендательных системах. Ресёрчеры из Google поделились статьёй, где предложили решение: модифицированный attention-слой позволил уловить связи, важные для предсказания итогового таргета. В тестах подход показал рост ключевых метрик (клики, покупки) — например, +0,4% по сравнению с DCN.
Подготовка фичей
На вход модели подаются cat- и dense-фичи. Cat-фичи обрабатываются стандартно (для них строятся обучаемые эмбеддинги), а с dense-фичами поступают чуть сложнее: их нормализуют, конкатенируют, применяют линейное преобразование, а потом сплитуют по D — внутренней размерности трансформера. Так фичей становится меньше.
Heterogeneous Attention Layer
Здесь матрицы query, key и value (QKV) считают отдельно для каждой фичи. Чтобы вычислить итоговый вектор для токена, вектора со всех голов, отвечающих фичам, конкатенируются и умножаются на матрицы.
Затем данные идут на Feed Forward-слой (FFN) с активацией GELU. Полученный вектор и будет выходом attention-слоя. Количество операций по сравнению с обычным трансформером не растёт, увеличивается лишь число параметров.
Hiformer
Чтобы уловить сложные взаимодействия, систему снова модифицируют — создают одну большую матрицу фичей. Затем конкатенируют все фичи каждой головы, умножают их на матрицу и получают модифицированные вектора. Благодаря этому получается выявить новые закономерности и связи, в т. ч. между composite-фичами и task-эмбеддингами.
Оптимизация
С большой матрицей трансформер становится тяжёлым с точки зрения latency — его нужно оптимизировать. Авторы используют низкоранговое разложение и прунинг последнего слоя. В первом случаем мы уменьшаем сложность за счёт разложения большой матрицы на две матрицы меньшего ранга.
Прунинг выполняется на последнем слое, где можно обучать таргет по task-эмбеддингам. Обычно итоговых задач намного меньше, чем фичей, что снижает сложность матричных умножений.
@RecSysChannel
Разбор подготовила
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Улучшаем Sequential Recommendation с помощью Guided Diffusion, часть 1
Поговорим о моделях, генерирующих следующий айтем на основе предыдущих взаимодействий пользователя — это может быть трек в плейлисте, видео, товар и т. д. По словам авторов статьи, SR обычно работает в парадигме learning-to-classify — получает позитивы, выполняет сэмплинг негативов, дополняет ими выборку и обучается. При этом неизвестно, видел ли юзер полученные айтемы и считает ли их нерелевантными. Альтернатива — использовать диффузию и перейти к learning-to-generate.
Пользователь примерно понимает, что хочет найти. Этот гипотетический айтем авторы называют oracle. Не факт, что он существует — тогда человек выберет что-то близкое из предложенных вариантов. Но именно «оракула» должна сгенерировать Guided Diffusion-модель.
Как это сделать
В прямом процессе на обучение берётся известный таргет и постепенно зашумляется. Незначительный гауссовский шум добавляется на каждом шаге (их тысячи), в итоге приходя к стандартному нормальному шуму. В обратном процессе мы избавляемся от шума, обуславливаясь на исторический контекст пользователя, закодированный трансформером в обобщающий вектор. Это позволяет выйти за рамки конкретных айтемов и сэмплировать абстрактное предложение.
Авторы описывают три подхода к диффузии:
— DDPM — оптимизация нижней вариационной оценки логарифмов правдоподобия наблюдаемых таргетов, которая сводится к оптимизации дивергенции Кульбака — Лейблера. Основной метод, использующийся в статье.
— Непосредственное рассмотрение двух марковских цепочек — если расписать score-функцию, этот подход эквивалентен певрому.
— Проведение аналогии между СДУ и диффузионной моделью актуально для генеративных моделей, т. к. позволяет получить логарифм нулевого распределения на таргетах и замерять им качество на этапе инфиренса.
Эффективность подхода проверяли экспериментами и сравнениями с другими моделями. Код и данные лежат тут. Во второй части мы подробнее расскажем о генерации и обучении.
@RecSysChannel
Разбор подготовил❣ Сергей Макеев
Поговорим о моделях, генерирующих следующий айтем на основе предыдущих взаимодействий пользователя — это может быть трек в плейлисте, видео, товар и т. д. По словам авторов статьи, SR обычно работает в парадигме learning-to-classify — получает позитивы, выполняет сэмплинг негативов, дополняет ими выборку и обучается. При этом неизвестно, видел ли юзер полученные айтемы и считает ли их нерелевантными. Альтернатива — использовать диффузию и перейти к learning-to-generate.
Пользователь примерно понимает, что хочет найти. Этот гипотетический айтем авторы называют oracle. Не факт, что он существует — тогда человек выберет что-то близкое из предложенных вариантов. Но именно «оракула» должна сгенерировать Guided Diffusion-модель.
Как это сделать
В прямом процессе на обучение берётся известный таргет и постепенно зашумляется. Незначительный гауссовский шум добавляется на каждом шаге (их тысячи), в итоге приходя к стандартному нормальному шуму. В обратном процессе мы избавляемся от шума, обуславливаясь на исторический контекст пользователя, закодированный трансформером в обобщающий вектор. Это позволяет выйти за рамки конкретных айтемов и сэмплировать абстрактное предложение.
Авторы описывают три подхода к диффузии:
— DDPM — оптимизация нижней вариационной оценки логарифмов правдоподобия наблюдаемых таргетов, которая сводится к оптимизации дивергенции Кульбака — Лейблера. Основной метод, использующийся в статье.
— Непосредственное рассмотрение двух марковских цепочек — если расписать score-функцию, этот подход эквивалентен певрому.
— Проведение аналогии между СДУ и диффузионной моделью актуально для генеративных моделей, т. к. позволяет получить логарифм нулевого распределения на таргетах и замерять им качество на этапе инфиренса.
Эффективность подхода проверяли экспериментами и сравнениями с другими моделями. Код и данные лежат тут. Во второй части мы подробнее расскажем о генерации и обучении.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2