Законы масштабирования в больших моделях последовательных рекомендаций

Авторы из WeChat и Tencent разбирались, работают ли законы масштабирования нейросетей для рекомендательных систем. Главный вопрос — есть ли улучшение качества рекомендаций при увеличении количества обучаемых параметров? Короткий ответ — да.

Известно, что рост количества параметров моделей иногда коррелирует с улучшением качества решаемых задач. Больше всего работ посвящено законам масштабирования в языковых моделях. В них определяется эмпирическая зависимость функции потерь на отложенной выборке от характеристик обучения. Обычно рассматривают параметры энкодеров и/или декодеров. Для NLP зависимость в логарифмических координатах получается линейной.

В работе об SR авторы масштабировали декодер трансформера и вносили изменения в стратегии обучения, чтобы получить закон масштабирования для рекомендательных систем:
— Для слоёв в начале последовательности декодер-блоков применяли больший dropout-rate, а для слоёв на вершине — меньший, что позволило избежать оверфита.
— Сначала обучались с Adam до полной сходимости, а потом брали чекпоинты, с которых продолжали обучение при помощи SGD, потому что несмотря на лучшую сходимость, итоговый минимум у Adam получался хуже.

Историю взаимодействий форматировали как хронологическую последовательность ID айтемов. То есть задача решалась так же, как в случае с языковыми моделями. Исследователи не брали другую информацию (например, текст айтема), так как хотели изучить работу закона с т. з. поведения пользователя. Модели увеличивали до 0,8B параметров, сравнивая эффекты в разных диапазонах размеров.

Оказалось, закон масштабирования работает для SR-моделей даже в сценариях с ограниченным количеством данных. Авторы показали преимущество больших моделей и на сложных задачах рекомендаций: cold start, long tail, определяли траектории пользователей и смотрели, что происходит при мультидоменном трансфере — во всех случаях масштабирование улучшало результаты.

@RecSysChannel
Разбор подготовил ❣ Артем Матвеев

LiNR: Model Based Neural Retrieval on GPUs at LinkedIn

В свежей статье от LinkedIn рассказывается о LiNR, первом индустриальном алгоритме генерации кандидатов, работающем на GPU. LiNR может поддерживать индексы, включающие миллиарды потенциальных кандидатов. Авторы рассказали, как они разрабатывали свой обучаемый дифференцируемый индекс и с какими трудностями им пришлось столкнуться.

В LiNR построение индекса рассматривается как процесс обучения, из-за чего и представления объектов, и веса, с помощью которых происходит формирование выдачи, интегрируются в одну модель. Отличительным аспектом статьи является использование честного KNN для формирования выдачи вместо широко распространенного ANN (Approximate Nearest Neighbor). В работе также описывается способ интегрирования фильтраций, основанных на логических правилах, в стадию скоринга объектов индекса, что позволяет повысить качество финальной выдачи.

В статье авторы предлагают три версии алгоритма для генерации кандидатов:
— Скоринг всех объектов с последующей фильтрацией. Первое предложенное решение, которое может работать неоптимально, особенно в случаях с большим процентом отфильтрованных объектов (low-pass-rate сценарии).
— Предварительная фильтрация объектов с последующим скорингом. Улучшенная версия первого подхода, которая решает его проблемы и увеличивает метрики качества выдачи.
— Дополнительное улучшение второго подхода с использованием квантизации. Предлагается использовать две стадии выбора кандидатов после фильтрации: первичный выбор подмножества объектов на основе квантизованных представлений и более гранулярная фильтрация оставшихся объектов для получения финальной выдачи.

Внедрение LiNR позволило увеличить количество ежедневных уникальных пользователей на 3%. Об особенностях архитектуры модели, квантизации, инфраструктуре, экспериментах, результатах и других фишках можно подробнее прочитать в самой статье, а я хотел бы остановиться на главных тезисах, которые исследователи постулируют в работе:

— С оффлайн инференсом и обновлением модели вы теряете свежих кандидатов, а следовательно, и качество. Real-time обновление LiNR увеличило качество всего пайплайна на 6%.
— Предварительная фильтрация, в отличие от пост-фильтрации, которая может тратить слоты кандидатов на нерелевантные объекты, помогает повысить качество модели.
— По умолчанию TF или PyTorch не приспособлены для реализации retrieval-моделей, из-за чего такие решения будут довольно медленными без дополнительных оптимизаций.
— Имплементация собственного CUDA-ядра для второй и третьей версий модели позволила получить значительное преимущество в скорости (к сожалению, авторы не поделились кодом самого ядра).

@RecSysChannel
Разбор подготовил ❣ Владимир Байкалов

Multi-objective Learning to Rank by Model Distillation

Свежая статья от Airbnb о том, как совместить дистилляцию и мультитаск-обучение. Задача ранжирования заключается не только в предсказании конверсии, но и её исхода. Например, человек может вернуть заказ или оставить отзыв. Также он может обратиться в сервис, если возникнут проблемы. Это важно в контексте долгосрочного роста платформы.

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

Решение — end-to-end multi-objective, совмещенный с дистилляцией. Важно, чтобы при этом инференс и обучение не занимали слишком много времени. Модели объединяют через дистилляцию, после чего добавляют механизм самодистилляции — он даёт лучшую воспроизводимость и помогает побороть cold start при переобучении. Так у авторов получилось решать ad-hoc бизнес-задачи, связанные с недифференцированными функционалами.

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

Подбирать веса, с которыми суммируются лоссы, при таком подходе дорого, плюс есть риск переобучения. Если подбирать веса каждый раз, когда обновляется какая-то модель — затраты вырастут. Избавиться от онлайн-тюнинга весов и сбалансировать обучение на цели с разным количеством данных помогает дистилляция, а дальнейшая самодистилляция закрепляет и усиливает эффект. Исследователи получили рост метрики nDCG на 1,1% в офлайн-экспериментах и +0,37% бронирований (CVR) в A/B-тестах.

@RecSysChannel
Разбор подготовил ❣ Сергей Макеев

Diffusion Model for Slate Recommendation

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

Ранжирование объектов — важная подзадача в рамках рекомендации слейтов, и для её решения авторы статьи используют отдельные модели, но в данной работе концентрируются на retrieval-части, рассказывая, чем хороши диффузионки. В качестве примеров похожих работ они ссылаются на 2 статьи от Google, за 2015 и 2019 год, где для решения аналогичной задачи используется RL. Проблема в том, что айтемы в слейте являются в RL-подходе независимыми событиями. Это упрощает обучение, но такой подход не совсем корректен, так как зависимость между соседними айтемами в слейте все же есть, что приводит к проблемам с качеством генерации.

Исследователи из Spotify утверждают, что генеративный подход (а именно — диффузионные модели) могут работать лучше, чем RL-like подходы. Диффузионки могут сделать слейт разнообразнее благодаря неявному пониманию, что айтемы не должны быть слишком похожими. Также авторы замечают, что диффузионные модели помогают бороться с popularity bias’ом и включать в подборки менее очевидные треки даже без явного обучения под эту задачу. Также авторы делают conditioning на весь контекст — профиль и запрос пользователя. Опционально в контекст добавляют отдельные айтемы из слейта, которые уже были предсказаны.

По словам исследователей, такой метод даёт значимо лучшие результаты, чем RL и другие привычные решения в сфере рекомендаций слейтов.

@RecSysChannel
Разбор подготовил ❣ Владимир Байкалов

Efficient Retrieval with Learned Similarities

Сегодня обсуждаем статью от Microsoft и Meta* об эффективном retrieval с обучаемыми функциями близости. Исторически нишу функций близости в retrieval занимали косинусные близости — скалярные произведения над нормализованными векторами. Но в последнее время популярность стали набирать обучаемые функции близости. Например, они допускают сопоставление одному запросу нескольких эмбеддингов, чтобы лучше улавливать редкие и противоречивые интересы пользователей. Также можно использовать нейросети над векторами запроса и векторами айтема и делать многие другие интересные вещи. Однако с эффективностью этих решений есть проблемы.

Чтобы повысить эффективность обучаемых функций близости, в статье используют Mixture-of-Logits как универсальный аппроксиматор и предлагают методы его ускорения для получения достаточно точной аппроксимации топ-k соседей. В экспериментах подход авторов обгоняет бейслайны почти в 100 раз по времени работы и при этом достигает 99% полноты/рекола.

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

Если изначальная матрица имела высокий ранг, мы не получим точного разложения. Простым решением является увеличение размерности эмбеддингов, но оно может привести к проблемам с памятью и оверфиту. А MoL позволяет аппроксимировать матрицу релевантности, сохранив ее ранг.

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

@RecSysChannel
Разбор подготовил ❣ Сергей Макеев

—
Meta признана экстремистской организацией, а Facebook и Instagram запрещены на территории РФ

Density Weighting for Multi-Interest Personalized Recommendation

Сегодняшняя статья от Google посвящена репрезентации юзера в виде нескольких векторов, каждый из которых отображает некоторый интерес пользователя.

Авторы отмечают, что использование нескольких представлений пользователя (multiple user representations, MUR) вместо одного представления (single user representation, SUR) показало свою эффективность. Однако при таком подходе огромную роль играет неравномерное распределение интересов пользователя. MUR фокусируется на головных, самых популярных интересах, из-за чего возникает просадка на более редких, хвостовых.

Чтобы решить эту проблему, авторы предлагают схему итеративного взвешивания плотности (iterative density weighting scheme, IDW). Она должна помочь справиться с дисбалансом данных и улучшить рекомендации для хвостовых элементов. IDW корректирует представление предметов в пространстве, уменьшая влияние дисбалансированных данных и улучшая кластеризацию элементов. Вот как устроена IDW:

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

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

3. IDW — это итеративный процесс. На каждом этапе веса пересчитываются с учётом изменённой структуры представлений предметов. Этот процесс повторяется до тех пор, пока модель не стабилизируется и не достигнет сбалансированного состояния.

4. После корректировки весов для предметов, модель дополнительно оптимизируется, чтобы улучшить рекомендации для хвостовых элементов, не снижая производительность для популярных предметов.

По результатам экспериментов на бенчмарках — MovieLens 1M, Kindle Store, а также Clothing, Shoes and Jewelry — схема IDW показала значительное улучшение рекомендаций. В метрике HR@20 для MovieLens 1M модель с IDW достигла 82,65% против 80,82% у обычной MUR, а в NDCG@20 — 49,67% против 47,72% у MUR.

На датасете Kindle Store HR@20 составил 65.24% с IDW против 64,66% у MUR, а NDCG@20 — 32.25%, тогда как у MUR было 31,16%.

На датасете Clothing, Shoes and Jewelry метрика HR@20 у IDW составила 37,34% (33.92% у MUR), а NDCG@20 — 16.33% (14.90% у MUR).

@RecSysChannel
Разбор подготовил ❣ Степан Макаренко

Интересное с ACM RecSys 2024, часть 1

14 октября в Бари стартовала конференция ACM Conference on Recommender Systems, которая собрала специалистов в области рекомендательных систем со всего мира — в том числе, и из Яндекса. Мы поговорили с ребятами, обсудили интересные доклады и постеры, которые они увидели, и спешим поделиться с вами. Впереди — ещё больше впечатлений и свежих идей в постах с полей ACM RecSys!

Encouraging Exploration in Spotify Search through Query Recommendations
Spotify рассказали о том, как внедрили саджесты запросов в поиск. Они собирают запросы из разных источников: каталог (треки, артисты, альбомы, плейлисты), запросы других пользователей, запросы вида артист + mix/covers и запросы, сгенерированные LLM по метаинформации. Всё это отправляется в ранкер, обученный на поисковых логах, из которого пользователю показывают топ-4. Результаты: +9% exploratory queries, они же — поиск нового контента, и +10% к средней длине запроса.

Do Not Wait: Learning Re-Ranking Model Without User Feedback At Serving Time in E-Commerce
Идея статьи: если у нас есть реранжирующая функция и функция, приближающая reward по пользователю и списку, в рантайме можно «скорректировать» параметры ранжирующей функции в сторону максимизации оценивающей функции. Такие корректировки можно применить несколько раз и получить ранжирующую модель, работающую лучше оригинальной.

Авторы утверждают, что вырастили число заказов на пользователя на 2%. Клики при этом выросли всего на 0.08%, что звучит очень странно на фоне роста числа заказов. Ранжирующая функция — представляет собой какой-то thompson sampling, а Argmax находят с помощью "reinforce like method". Интересно, но практическая польза под вопросом.

Better Generalization with Semantic IDs: A Case Study in Ranking for Recommendations
Нашумевшая статья от Google DeepMind. Авторы предлагают закодировать контент документа в виде нескольких токенов с использованием VAE и векторной квантизации — изначально подход предложили в другой статье. Каждый документ представляют как набор токенов фиксированной длины. Получают хитрый словарь, которым можно кодировать документы, где один документ = несколько токенов. Утверждают, что работает не сильно хуже, чем обучаемые ID (без коллизий), но матрица эмбеддингов при этом радикально меньше, а коллизии в ней имеют семантический смысл.

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

@RecSysChannel #YaACMRecSys
Находками делились ❣ Николай Савушкин и Пётр Зайдель

Интересное с ACM RecSys 2024, часть 2

А мы продолжаем делиться классными докладами с ACM RecSys — оставайтесь с нами и приглашайте друзей подписываться, чтобы не пропустить самое интересное 👀

Ranking Across Different Content Types: The Robust Beauty of Multinomial Blending
Простая, но разумная продуктовая идея от Amazon Music: дать возможность продактам задавать пропорции по типу контента. Для этого есть две модели: одна ранжирует карусели, а другая — контент внутри каруселей. Когда карусели отранжированы, их группируют по типам контента, сэмплируют тип пропорционально весам, заданным продактам, и выбирают самую релевантную карусель из типа, выпавшего в сэмплировании. В А/Б тесте этот подход сравнили с системой, которая работает на MMR-like алгоритме и получили отличный рост метрик.

Раньше для ранжирования авторы использовали linear thompson sampling, теперь — нейронка, которая обучается в онлайн-режиме на сабсэмпле логов с задержкой в десятки секунд. Сейчас они активно пробуют sequential-модели, но пока не в проде.

AIE: Auction Information Enhanced Framework for CTR Prediction in Online Advertising
Довольно интересный фреймворк. Авторы добавили отшкалированный CPC как вес позитива в log loss, и получили рост метрик (выразившийся в деньгах) в А/Б тесте. К сожалению, автор не подсказал, какими были теоретические предпосылки — судя по всему сработала какая-то очень общая интуиция.

В оффлайне используют в основном AUC и csAUC, которые обычно нормально конвертируются в онлайн-метрики.

Enhancing Performance and Scalability of Large-Scale Recommendation Systems with Jagged Flash Attention
Постер о jagged flash attention — это когда вы не используете пэдлинг в историях пользователей, а вместо этого упаковываете её в два тензора: непрерывную историю и размеры историй.

Авторы обещают код в опенсорсе в ближайшее время. Сообщают об ускорении на инференсе, но не рассказали, на каких размерах батчей и длинах истории получены цифры. На графиках с ускорением обучения всегда пэдят до максимальной длины, а не до максимальной длины в батче, а значит, цифры завышены. Но в целом история очень полезная.

Sliding Window Training: Utilizing Historical Recommender Systems Data for Foundation Models
Исследователи в Netflix учат базовую модель для downstream-тасков. По сути это sasrec — предсказывают next item. На разных эпохах используют разные длины истории (фиксированные на всю эпоху). Для каждого пользователя выбирают одно рандомное окно указанной длины в эпоху. На вход подают просто ID, action type используют только в loss, где смешивают loss’ы на разный action type с разными весами. Истрия пользователя состоит из разных позитивов: клики, просмотры и т. п.

Авторы никак не дообучают модель в downstream-тасках, а просто подают на вход верхней модели полученные эмбеддинги. Lookahead и action type во входе модели не пробовали. Размерность эмбеда — 64. Loss представляет собой честный softmax по всей базе.

@RecSysChannel #YaACMRecSys
Находками делился ❣ Николай Савушкин

Интересное с ACM RecSys 2024, часть 3

Конференция завершилась, ребята вернулись домой, но продолжают делиться с нами обзорами интересных и актуальных статей, а мы и рады их опубликовать! Сегодня в эфире — довольно подробный разбор статьи Text2Tracks: Generative Track Retrieval for Prompt-based Music Recommendation.

Авторы рассматривают задачу рекомендации музыки на основе текстовых запросов, например, “old school rock ballads to relax”, “songs to sing in the shower” и т. д. Исследуется эффективность модели на широких запросах, не подразумевающих конкретного артиста или трека. Рекомендовать трек по текстовому запросу можно разными путями. Например, задать вопрос языковой модели, распарсить ответ и найти треки через поиск. Это может привести к галлюцинациям или неоднозначности поиска — иногда совершенно разные треки могут иметь одно название. Кроме того, предсказание может занимать много времени и требовать больших вычислительных ресурсов.

Авторы предлагают дообучить модель типа encoder-decoder (flan-t5-base), которая по текстовому входу смогла бы генерировать идентификатор трека напрямую, вдохновившись подходом differentiable search index. Основной вопрос, на который дают ответ в статье — как лучше кодировать трек? Для этого сравнивают несколько подходов:
— Трек кодируется случайным натуральным числом, которое подаётся на вход в виде текста. Например “1001”, “111”
— Трек котируется как два числа: ID артиста и ID трека внутри артиста. То есть треки артиста 1 будут представляться как “1_1”, “1_2” … Для топ 50к артистов добавляют отдельные токены с словарь.
— Каждый трек описывается списком ID на основе иерархической кластеризации контентного (названия плейлистов с треком) или коллаборативных ембеддингов (word2vec). Для каждого кластера добавляется отдельный токен.

Эти стратегии значительно сокращают количество токенов, необходимых для представления трека по сравнению с текстовым описанием. Результат получился следующий: лучше всего себя показал второй подход (ID артиста + ID трека в нём). При этом хуже всего себя показали подходы с кластеризацией коллаборативных ембеддингов и ID трека в виде натурального числа.

В качестве основных бейзлайнов авторы используют popularity, bm25 и двухбашенный энкодер (all-mpnet-base-v2), который файнтюнят c multiple negatives ranking loss. Сравнивают модели на трёх датасетах: MPD 100k, CPCD и редакционные плейлисты Spotify. Исследователи показывают, что их модель значительно лучше бейзлайнов на всех датасетах. В будущем они планируют изучить возможности моделей с архитектурой decoder-only и использование пользовательской истории для персонализации рекомендаций.

@RecSysChannel #YaACMRecSys
Обзор подготовил ❣ Пётр Зайдель