Интересное с 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
Обзор подготовил ❣ Пётр Зайдель

Actions Speak Louder than Words: Trillion-Parameter Sequential Transducers for Generative Recommendations

У нейросетевых рекомендательных систем есть одна большая проблема — они плохо масштабируются, в то время как в NLP и CV скейлинг по размеру нейросетевых энкодеров очень хороший. Выделяют несколько причин этого явления: гигантский нестационарный словарь айтемов, гетерогенная природа признаков, а также очень большой объем данных.

В сегодняшней статье авторы предлагают переформулировать задачу рекомендации в генеративной постановке. Для начала, они представляют данные в виде последовательности событий. Вещественные фичи (счетчики и проч.) выкидываются, из взаимодействий с айтемами формируется единая последовательность, и затем в нее добавляются события изменения статической информации, такие как смена локации или изменение любого другого контекста.

Архитектура для генерации кандидатов выглядит довольно стандартно и похожа на SASRec или Pinnerformer: представляем пользователя в виде последовательности событий (item, action), и в тех местах, где следующим событием идет положительное взаимодействие с айтемом, предсказываем, что это за айтем.

А вот для ранжирования новизна достаточно серьезная: чтобы сделать модель target-aware (см. Deep Interest Network от Alibaba), понадобилось сделать более хитрую последовательность, в которой чередуются токены айтемов и действий: item_1, action_1, item_2, action_2, …. Из айтем-токенов предсказывается, какое с ними произойдет действие. Еще говорят, что на практике можно решать в этом месте любую многоголовую мультизадачу. Важно отметить, что авторы не учат единую модель сразу на генерацию кандидатов и ранжирование, а обучают две отдельные модели.

Другое нововведение — отказ от софтмакса и FFN в трансформере. Утверждается, что софтмакс плох для выучивания «интенсивности» чего-либо в истории пользователя. Те вещественные признаки, которые были выкинуты авторами, в основном её и касались. Например, сколько раз пользователь лайкал автора видеоролика, сколько раз скипал и т. д. Такие признаки очень важны для качества ранжирования. То, что отказ от софтмакса эту проблему решает, видно по результатам экспериментов — действительно есть значительное улучшение результатов ранжирования при такой модификации.

В итоге HSTU (Hierarchical Sequential Transduction Unit, так авторы окрестили свою архитектуру) показывает отличные результаты как на публичных, так и на внутренних датасетах. Еще и работает гораздо быстрее, чем прошлый DLRM подход за счет авторегрессивности и нового энкодера. Результаты в онлайне тоже очень хорошие — на billion-scale платформе short-form video (предполагаем, что это рилсы) получили +12.4% относительного прироста целевой метрики в A/B-тесте. Тем не менее, итоговая архитектура, которую авторы измеряют и внедряют, с точки зрения количества параметров не очень большая, где-то сотни миллионов. А вот по размеру датасета и длине истории скейлинг получился очень хороший.

@RecSysChannel
Разбор подготовил ❣ Кирилл Хрыльченко

Joint Modeling of Search and Recommendations Via an Unified Contextual Recommender (UniCoRn)

В ещё одном интересном докладе с ACM RecSys разработчики из Netflix делятся опытом объединения моделей для персонализированного поиска и рекомендаций. В статье есть несколько предпосылок. Во-первых, обслуживать одну модель в продакшене проще, чем несколько. Во-вторых, качество объединённых моделей может быть выше.

Представленная архитектура обучается на трёх задачах: персональные рекомендации, персонализированный поиск и рекомендации к текущему видео. Для этого в нейросетевой ранкер подаётся поисковой запрос, ID текущей сущности (видео), ID пользователя, страна и ID задачи, которая решается (поиск или одно из ранжирований). Также в ранкер подаётся эмбеддинг истории действий пользователя, полученный так называемой "User Foundation Model", детали которой не раскрываются ни в тезисах с конференции, ни в ответе на прямой вопрос после устного доклада.

Чтобы заполнить эмбеддинги сущностей, которые отсутствуют (например, поисковые запросы в задаче рекомендаций), авторы провели серию экспериментов, по итогам которых решили, что в задаче поиска лучше вместо контекста подставлять отдельное нулевое значение, а в задаче рекомендаций — использовать название текущего видео вместо строки запроса.

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

Результаты — рост на 7% в офлайн-качестве в поиске и на 10% — в рекомендациях. Это, по всей видимости, достигается за счёт регуляризации, возникающей при обучении на несколько задач и за счёт перехода к полной персонализации в поиске.

@RecSysChannel
Разбор подготовил ❣ Владимир Цепулин

Recommender Systems with Generative Retrieval

Современные модели для генерации кандидатов обычно строят так: обучают энкодеры (матричные разложения, трансформеры, модели dssm-like) для получения ембеддингов запроса (пользователя) и кандидата в одном пространстве. Далее по кандидатам строится ANN-индекс, в котором по ембеддингу запроса ищутся ближайшие по выбранной метрике кандидаты. Авторы предлагают отойти от такой схемы и научиться генерировать ID айтемов напрямую моделью, которую они обучают. Для этого предлагают использовать энкодер-декодер трансформенную модель на основе фреймворка T5X.

Остается вопрос, как закодировать айтемы для использования в трансформерной модели и как научиться напрямую предсказывать ID в декодере? Для этого предлагается использовать наработки из прошлой работы — Semantic IDs. Такие ID для описания айтемов обладают следующими свойствами:

— иерархичность — ID в начале отвечают за общие характеристики, а в конце — за более детальные;
— они позволяют описывать новые айтемы, решая проблему cold-start;
— при генерации можно использовать сэмплинг с температурой, что позволяет контролировать разнообразие.

В статье проводят эксперимент на датасете Amazon Product Reviews, состоящий из отзывов пользователей и описания товаров. Авторы используют три категории: Beauty, Sports and Outdoors и Toys and Games. Для валидации и тестирования используют схему leave-one-out, когда последний товар в истории каждого пользователя используется для тестирования, а предпоследний — для валидации. Такой подход много критиковали за возможные лики, но авторы используют его для сравнения с уже существующими результатами бейзлайнов.

Semantic IDs строили следующим образом: каждый товар описывался строкой из названия, цены, бренда и категории. Полученное предложение кодировали предобученной моделью Sentence-T5, получая эмбеддинг размерности 768. На этих ембеддингах обучали RQ-VAE с размерностями слоев 512, 256, 128, активацией ReLU и внутренним ембеддингом 32. Использовали три кодовые книги (codebooks) размером 256 ембеддингов. Для стабильности обучения их инициализировали центроидами кластеров k-means на первом батче. В результате каждый айтем описывает три ID, каждый из словаря размера 256. Для предотвращения коллизий добавляли еще один ID с порядковым номером.

Энкодер и декодер — трансформеры из четырёх слоев каждый с шестиголовым аттеншеном размерности 64, ReLU активацией, MLP на 1024 и размерностью входа 128. В словарь токенов добавили 1024 (256 × 4) токенов для кодбуков и 2000 токенов для пользователей. В итоге получилась модель на 13 миллионов параметров. Каждый пример в датасете выглядит так: hash(user_id) % 2000, <semantic_ids_1>, … <semantic_ids_n> -> <semantic_ids_n+1>. Во время инференса метод показывает значительный прирост качества (Recall@5, NDCG) по сравнению с бейзлайнами (SASRec, S3-Rec etc). При этом нужно учитывать, что у предложенной модели намного больше параметров, чем у остальных.

Авторы проводят ablation study для семантических ID — рассматривают варианты их замены на LSH и случайные ID. В обоих случаях semantic ID дает большой прирост и является важным компонентом подхода. Также проводится анализ возможности модели обобщаться на новые айтемы. Для этого из датасета выкидываются 5% товаров, а на инференсе задают отдельным гиперпараметром долю новых кандидатов в top-k (с совпадающими первыми тремя ID) и сравнивают свою модель с KNN.

Статья получилась во многом академичной, но она обращает внимание на важное направление, которое сейчас активно развивается. Похожий подход можно использовать для кодирования айтемов для LLM, чем, судя по разговорам на конференции, уже активно занимаются. Также можно отметить, что в статье не раскрывается часть важных вопросов: как добавлять новые айтемы и как переобучать RQ-VAE (в реальных сервисах часто меняется распределение контента), а также хотелось бы увидеть сравнение на более приближенных к реальным датасетах.

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

KuaiFormer: Transformer-Based Retrieval at Kuaishou

Сегодня разбираем свежую работу от Kuaishou о том, как они используют в реалтайме трансформеры для кандидатогенерации.

Kuaishou — суперпопулярный в Китае аналог TikTok: 400 млн активных пользователей, 600+ тыс RPS. В среднем один пользователь просматривает сотни видео в день.

Это первое внедрение в Kuaishou трансформера для кандидатогенерации. По их словам, — самое успешное внедрение за последние полгода.

Новая модель получила название KuaiFormer. Опираясь на историю взаимодействия пользователя с продуктом, она помогает предсказывать следующие положительные взаимодействия (в случае Kuaishou — это, например, лайк, полный просмотр видео и т. д.).

PinnerFormer, SASRec, Bert4Rec и другие похожие работы плохо улавливают разнообразные интересы пользователей, поскольку представляют их в виде одного вектора. Подходы MIND и ComiRec решают эту проблему: они умеют выделять целые кластеры интересов — так рекомендации получаются более разнообразными. KuaiFormer объединяет в себе оба подхода — она умеет справляться с главными проблемами реальных рекомендательных систем:

1. За счёт применения logQ-коррекции эффективно работает с большим каталогом айтемов при обучении.

2. Порождает разнообразные рекомендации, поскольку выделяет не один вектор интересов, а несколько. Во время обучения вероятность целевого айтема моделируется через вектор интересов, наиболее близкий к нему.

3. Работает в реалтайме, но не требует большого объёма вычислительных ресурсов, несмотря на огромные RPS. Добиться этого помогает сворачивание последовательных кусков истории пользователя в один вектор с помощью bidirectional-трансформера: самые старые айтемы, которые были актуальны достаточно давно, сворачиваются в один вектор, а самые свежие — остаются нетронутыми. Схема того, как 256 токенов превращаются в 64, показана на рисунке.

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