Интересное с 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
Находками делились❣ Николай Савушкин и Пётр Зайдель
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
Находками делились
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤5🔥5
А тут — непередаваемая атмосфера конференции и подборка постеров из сегодняшнего поста.
#YaACMRecSys
@RecSysChannel
#YaACMRecSys
@RecSysChannel
🔥13❤6👍4
Интересное с 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 — оставайтесь с нами и приглашайте друзей подписываться, чтобы не пропустить самое интересное 👀
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
Находками делился
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤4🔥4
👍6❤5🔥5
Интересное с 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
Обзор подготовил❣ Пётр Зайдель
Конференция завершилась, ребята вернулись домой, но продолжают делиться с нами обзорами интересных и актуальных статей, а мы и рады их опубликовать! Сегодня в эфире — довольно подробный разбор статьи 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
Обзор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤5👍4
👍6❤4🤝3🔥1