ACM RecSys — 2024: тренды и доклады с крупнейшей конференции по ML в рекомендательных системах

Привет! Меня зовут Пётр Зайдель и я старший разработчик в Музыке. Вместе с другими ребятами из Яндекса, которые развивают рекомендательные системы в разных сервисах, я в октябре побывал на международной конференции ACM RecSys — 2024 в итальянском городе Бари. Сегодня хочу поделиться с Хабром впечатлениями, трендами и, конечно, обзорами самых интересных научных статей с конференции. Думаю, мой рассказ будет полезен всем специалистам в сфере рекомендательных систем, которые следят за трендами и готовы пробовать в своей работе что‑то новое и интересное. Поехали:)

Как и где проходила конференция

Бари — небольшой уютный город на побережье Адриатического моря. Основными местами проведения конференции стали местный технический вуз (Politecnico di Bari) и театр Пиччини — старейший в городе. В университете проходили воркшопы в первый и последние дни ACM RecSys и часть постерной сессии, а в театре — основные доклады и концерт классической музыки в финале.

Конечно, жизнь участников конференции состоит не только из перемещения между постерами в попытке успеть поговорить со всеми интересными авторами: в последний день организаторы устроили вечеринку на вилле, где все мы проводили время в гораздо более расслабленной атмосфере.

Яркими моментами для меня также стали выступление ресёрч‑директора DeepMind о будущем генеративных рекомендаций и keynote на главной сцене от Spotify: рассказывали об истории и развитии рекомендательных систем в компании.

О чём говорили и что показывали на RecSys — 2024

Тренды

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

LLM в рекомендациях

Пожалуй, главный тренд — много работ, много хайпа. Практически все компании пытаются так или иначе использовать LLM для рекомендаций. Большие языковые модели помогают в генерации контента, предобработке данных и как часть пайплайна. Компания Google рассказывала о том, как с помощью LLM можно предсказывать верхнеуровневые интересы пользователя. Примеры статей:

Генеративные модели

Тренд, близкий к LLM, но больше о том, как модели могут выдавать сразу айтемы для рекомендаций. Было несколько статей от Spotify и Google, в которых авторы развивают подходы к генерации ID айтемов напрямую.

Статьи по теме:

Пока что публикации в основном академические, индустриальное применение есть только со слов сотрудников.

Новые способы представления айтемов для моделей

Это важный тренд, так как в идеале мы всегда стремимся найти баланс между генерализацией и меморизацией, чтобы иметь возможность легко обобщаться на новые айтемы. Ещё альтернативные способы представления необходимы для развития применения LLM, поскольку стандартные способы, такие как айтем ID, контент или контентные эмбеддинги, не подходит.

Статьи по теме:

Скейлинг моделей

Этот тренд продолжает активно развиваться — большие компании хотят большие модели. Пока что размер рекомендательных систем значительно уступает актуальным LLM, но догнать их — вопрос времени. Основная задача — найти мощности и оправдать использование огромных моделей экономически. Мне кажется, что это вполне реально: в Google верят в синтез LLM и рекомендаций, а в Meta* развивают большие генеративные модели для рекомендательных систем. Примеры статей:

Антитренды

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

А теперь — к статьям!

В создании этого раздела очень помогли коллеги: Николай Савушкин, Владимир Цепулин и Кирилл Хрыльченко. Их разборы здесь представлены вместе с моими.

Мой личный топ-3

Keynote от Эда Чи, ресёрч‑директора DeepMind

Выступление было посвящено обзору развития рексистем за последние 10 лет и тому, куда мы движемся, начиная с матричной факторизации и заканчивая генеративными моделями. Основная идея доклада: нужно объединять языковые модели с рекомендательными, строить агентов и т. д. Эд Чи рассказал, как в Google связывают LLM с рекомендациями при помощи semantic IDs и что с их помощью получается дообучать модели на задачу рекомендаций на совсем небольших объёмах данных.

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‑тесте. Тем не менее итоговая архитектура, которую авторы измеряют и внедряют, с точки зрения количества параметров не очень большая — где‑то сотни миллионов. А вот по размеру датасета и длине истории скейлинг получился очень хороший.

А ещё на ACM RecSys были представлены постеры статей Toward 100TB Recommendation Models with Embedding Offloading и Enhancing Performance and Scalability of Large‑Scale Recommendation Systems with Jagged Flash Attenti, посвящённых техническим деталям реализации больших моделей для рекомендаций.

LLMs for User Interest Exploration in Large‑scale Recommendation Systems

Основная идея статьи — применение LLM Gemini Pro для предсказания нового интереса пользователя. Схема, которую предлагают авторы, позволяет без существенных затрат на инфраструктуру использовать знания языковой модели для рекомендаций.

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

Запрос в LLM устроен так: по списку кластеров интересов пользователя (используют два) просят предсказать следующий. Чтобы модель лучше понимала задачу и умела выдавать реально существующий кластер, её файнтюнят на залогированных (C1, C2) → CL, где CL — новый интерес пользователя, с которым он успешно взаимодействовал. При этом используют не все данные, а для каждого целевого кластера CL выбирают только топ-10 пар кластеров слева, т. е. всего 7610 примеров. Это нужно для увеличения разнообразия данных и позволяет убрать перекос генерации в сторону более частотных кластеров. В целом файнтюнинг увеличивает понимание моделью задачи (увеличивается рекол) и уменьшает процент ошибок — предсказаний несуществующего кластера.

Для инференса LLM используют так: в офлайне за несколько часов получают предсказание для всех пар кластеров (761 × 761) и получившуюся таблицу хранят в памяти. В онлайне семплируют два кластера из истории пользователя за 30 дней и находят соответствующий следующий кластер в таблице. Далее ранжируют кандидатов из кластера стандартными моделями для персонализации.

Систему внедрили в YouTube Shorts и получили прирост относительно бейзлайна — tree‑based LinUCB. Увеличилось количество пользователей с N (от 20 до 200) различными кластерами интересов за семь дней. Также эксперимент показал увеличение overall watch time и количества пользователей с временем просмотра видео более 10 минут.

Больше статей, хороших и разных

Генеративные рекомендации

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. Используется три кодовые книги (codebook) размером 256 эмбеддингов. Для стабильности обучения их инициализируют центроидами кластеров k‑means на первом батче. В результате каждый айтем описывает 3 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 (в реальных сервисах часто меняется распределение контента), а также хотелось бы увидеть сравнение на более приближенных к реальным датасетах.

Better Generalization with Semantic IDs: A Case Study in Ranking for Recommendations

Нашумевшая статья от Google DeepMind. Авторы предлагают закодировать контент документа в виде нескольких токенов с использованием VAE и векторной квантизации — изначально подход предложили в другой статье. Каждый документ представляют как набор токенов фиксированной длины. Получают хитрый словарь, которым можно кодировать документы, где один документ = несколько токенов. Утверждают, что работает не сильно хуже, чем обучаемые ID (без коллизий), но матрица эмбеддингов при этом радикально меньше, а коллизии в ней имеют семантический смысл.

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

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 и использование пользовательской истории для персонализации рекомендаций.

Индустриальные статьи

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

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

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

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

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

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

Encouraging Exploration in Spotify Search through Query Recommendations

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

Ranking Across Different Content Types: The Robust Beauty of Multinomial Blending

Простая, но разумная продуктовая идея от Amazon Music: дать возможность продактам задавать пропорции по типу контента. Для этого есть две модели: одна ранжирует карусели, а другая — контент внутри каруселей. Когда карусели отранжированы, их группируют по типам контента, семплируют тип пропорционально весам, заданным продактам, и выбирают самую релевантную карусель из типа, выпавшего в семплировании. В AB‑тесте этот подход сравнили с системой, которая работает на MMR‑like‑алгоритме, и получили отличный рост метрик.

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

Large scale

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 по всей базе.

Другое

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. Интересно, но практическая польза под вопросом.

AIE: Auction Information Enhanced Framework for CTR Prediction in Online Advertising

Довольно интересный фреймворк. Авторы добавили отшкалированный CPC как вес позитива в log loss и получили рост метрик (выразившийся в деньгах) в AB‑тесте. К сожалению, автор не подсказал, какими были теоретические предпосылки — судя по всему, сработала какая‑то очень общая интуиция. В офлайне используют в основном AUC и csAUC, которые обычно нормально конвертируются в онлайн‑метрики.

Делаем выводы

Модели для рекомендаций с каждым днём всё больше становятся похожи на языковые. В больших компаниях либо увеличивают модели до размеров LLM, либо приближаются к тому, чтобы напрямую использовать их для рекомендаций. Кажется, что это основной тренд на ближайшие годы, и мы скоро увидим в проде модели размеров (именно в dence‑части), сопоставимых с актуальными LLM. Также в применение больших языковых моделей для ретривала и ранжирования верят крупнейшие компании, а значит, будет больше статей, больше ресурсов и больше результатов.

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

* Компания Meta признана экстремистской организацией, а её продукты, Facebook и Instagram, запрещены на территории РФ.

ссылка на оригинал статьи https://habr.com/ru/articles/862148/