Efficient Retrieval with Learned Similarities
Сегодня обсуждаем статью от Microsoft и Meta* об эффективном retrieval с обучаемыми функциями близости. Исторически нишу функций близости в retrieval занимали косинусные близости — скалярные произведения над нормализованными векторами. Но в последнее время популярность стали набирать обучаемые функции близости. Например, они допускают сопоставление одному запросу нескольких эмбеддингов, чтобы лучше улавливать редкие и противоречивые интересы пользователей. Также можно использовать нейросети над векторами запроса и векторами айтема и делать многие другие интересные вещи. Однако с эффективностью этих решений есть проблемы.
Чтобы повысить эффективность обучаемых функций близости, в статье используют Mixture-of-Logits как универсальный аппроксиматор и предлагают методы его ускорения для получения достаточно точной аппроксимации топ-k соседей. В экспериментах подход авторов обгоняет бейслайны почти в 100 раз по времени работы и при этом достигает 99% полноты/рекола.
По сути обучаемые функции близости — это попытка повысить экспрессивность функции, моделирующей релевантность. В идеале у нас есть большая матрица релевантностей, где каждому запросу сопоставлена вероятность. При переходе к обучаемым эмбеддингам мы оцениваем релевантность как dot product и пытаемся оценить логарифм матрицы низкоранговым разложением.
Если изначальная матрица имела высокий ранг, мы не получим точного разложения. Простым решением является увеличение размерности эмбеддингов, но оно может привести к проблемам с памятью и оверфиту. А MoL позволяет аппроксимировать матрицу релевантности, сохранив ее ранг.
Также авторы предлагают методы ускорения этой конструкции: несколько вариаций алгоритмов, о которых можно узнать больше из полного текста статьи, и оптимизацию GPU-кернелов вкупе с использованием более масштабных датасетов, что сделает разницу между традиционными подходами и обучаемыми функциями близости ещё более выраженной.
@RecSysChannel
Разбор подготовил❣ Сергей Макеев
—
Meta признана экстремистской организацией, а Facebook и Instagram запрещены на территории РФ
Сегодня обсуждаем статью от Microsoft и Meta* об эффективном retrieval с обучаемыми функциями близости. Исторически нишу функций близости в retrieval занимали косинусные близости — скалярные произведения над нормализованными векторами. Но в последнее время популярность стали набирать обучаемые функции близости. Например, они допускают сопоставление одному запросу нескольких эмбеддингов, чтобы лучше улавливать редкие и противоречивые интересы пользователей. Также можно использовать нейросети над векторами запроса и векторами айтема и делать многие другие интересные вещи. Однако с эффективностью этих решений есть проблемы.
Чтобы повысить эффективность обучаемых функций близости, в статье используют Mixture-of-Logits как универсальный аппроксиматор и предлагают методы его ускорения для получения достаточно точной аппроксимации топ-k соседей. В экспериментах подход авторов обгоняет бейслайны почти в 100 раз по времени работы и при этом достигает 99% полноты/рекола.
По сути обучаемые функции близости — это попытка повысить экспрессивность функции, моделирующей релевантность. В идеале у нас есть большая матрица релевантностей, где каждому запросу сопоставлена вероятность. При переходе к обучаемым эмбеддингам мы оцениваем релевантность как dot product и пытаемся оценить логарифм матрицы низкоранговым разложением.
Если изначальная матрица имела высокий ранг, мы не получим точного разложения. Простым решением является увеличение размерности эмбеддингов, но оно может привести к проблемам с памятью и оверфиту. А MoL позволяет аппроксимировать матрицу релевантности, сохранив ее ранг.
Также авторы предлагают методы ускорения этой конструкции: несколько вариаций алгоритмов, о которых можно узнать больше из полного текста статьи, и оптимизацию GPU-кернелов вкупе с использованием более масштабных датасетов, что сделает разницу между традиционными подходами и обучаемыми функциями близости ещё более выраженной.
@RecSysChannel
Разбор подготовил
—
Meta признана экстремистской организацией, а Facebook и Instagram запрещены на территории РФ
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12👍6❤4
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
Разбор подготовил❣ Степан Макаренко
Сегодняшняя статья от 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
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥6❤2
Интересное с 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