Рекомендательная библиотека RePlay: сравнение с конкурентами RecBole и Recommenders на примере SOTA-модели SASRec

Привет, Хабр! Мы — команда ML‑разработчиков Сбера и Sber AI Lab. Хотим рассказать о нашем open‑source инструменте RePlay, который позволяет создавать рекомендательные системы с нуля, начиная с самых ранних DS‑экспериментов и заканчивая промышленной эксплуатацией. Статья будет интересна ML‑инженерам, разрабатывающим промышленные рекомендательные системы.

Мотивацией для создания RePlay послужил тот факт, что все популярные на сегодняшний день RecSys‑фреймворки в основном нацелены на научные исследования и плохо оптимизированы для промышленной эксплуатации: не в состоянии обработать большой объём данных или требуют для этого значительных модификаций. Подробнее о создании библиотеки вы можете прочитать в соответствующей статье с RecSys 2024. По той же ссылке вы найдёте обзорное видео о RePlay.

Здесь же мы сравним RePlay с главными конкурентами — RecBole и Microsoft Recommenders. Разберём возможности, которые предоставляет каждая из библиотек, а затем, на примере SOTA‑модели, построим рекомендательную систему, начиная с ввода данных и заканчивая генерированием рекомендаций и подсчётом метрик. Сравним полученные модели по качеству и длительности обучения и инференса. В конце расскажем об уникальных возможностях RePlay, которые помогут ещё сильнее облегчить путь разработчика, по сравнению с использованием библиотек‑конкурентов

Сравнение функциональности библиотек

Краткие аннотации от авторов

Вот что пишут авторы библиотек в своих статьях.

RePlay — открытый инструментарий для создания и сравнения рекомендательных систем. Предоставляет готовый к промышленной эксплуатации pipeline, охватывающий весь процесс разработки. Позволяет выбирать подходящий стек для каждого этапа: Pandas, Polars или Spark, обеспечивая масштабируемость вычислений и возможность развёртывания в кластере.

RecBole — унифицированная, всеобъемлющая и эффективная библиотека для рекомендательных систем на PyTorch. Реализует 73 модели на 28 эталонных (встроенных) наборах данных. Отличается общими и расширяемыми структурами данных, эффективным исполнением с использованием GPU, и вспомогательными функциями, такими как автоматическая настройка параметров и возобновление с точки останова.

Recommenders — открытая библиотека для помощи в создании и внедрении классических и современных алгоритмов рекомендаций. Фокусируется на лучших практиках разработки и опыте использования в производственной среде. Облегчает использование, ускоряет реализацию и развёртывание, повышает производительность рекомендательных систем.

Сравнение встроенных возможностей

Мы погрузились в исходный код и документацию каждого из фреймворков, провели собственные мини‑эксперименты и собрали в общую таблицу все особенности, которые мы обнаружили:

Анализ качества и времени работы на SOTA

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

Модель

Самый популярный сейчас подход в рекомендациях — обучение трансформеров на последовательностях взаимодействий пользователей. Поэтому для экспериментов мы взяли модель SASRec (Self‑Attentive Sequential Recommendation) которая реализована во многих библиотеках и уже стала «классической» в области sequence‑to‑sequence рекомендаций. Подробнее почитать о ней можно в оригинальной статье. Авторские реализации: раз, два.

Наборы данных от партнёров Сбера

Помимо сравнения рекомендательных библиотек мы хотим также предложить исследователям новые, более релевантные наборы данных для сравнения рекомендательных моделей. Несмотря на популярность в научных статьях таких набров, как MovieLens и Netflix, они невелики и постепенно устаревают. Авторы добавляют более свежие данные, но их объём — это капля в море для промышленной рекомендательной системы с миллионами ежедневных пользователей.

Исследователи Сбера выложили в открытый доступ три набора данных от партнёров банка. В них вошли:

• Zvuk Dataset — набор прослушиваний музыкальных треков пользователями в одноимённом стриминговом HiFi‑сервисе. Больше всего по своей природе подходит для тестирования seq2seq‑подходов (рекомендации на основе последовательностей).

• MegaMarket — набор данных о покупках пользователей товаров на одноименном онлайн‑маркетплейсе. Больше всего подходит для коллаборативных моделей (вроде ALS), поскольку товары относятся к большому количеству категорий, а сам порядок действий менее важен.

• SBOL Dataset — набор данных о взаимодействиях клиентов с банковскими продуктами, содержащий более 1300 признаков. Больше всего подходит для различных статистических методов и деревьев решений, поскольку имеет высокую разреженность и много признаков.

Важной особенностью является пересечение всех трёх наборов по пользователям, что также делает их пригодными для тестирования кросс‑доменных моделей (когда взаимодействия пользователя в одной тематической области некоторым образом интерпретируются в других областях). Таким образом, эти наборы данных позволяют проверять весь спектр рекомендательных моделей, а вдобавок могут ещё и работать в связке! Все три набора данных собраны в первой половине 2023 года и являются одними из наиболее свежих открытых наборов в рекомендательных систем.

Данные

В качестве данных для эксперимента мы выбрали три набора:

• MovieLens (20M). MovieLens — это самый популярный набор dataset‑ов для рекомендательных систем. Содержит оценки фильмов пользователями. Мы взяли версию на 20 миллионов интеракций, как ещё не совсем старую (год сборки: 2015) и достаточно объёмную.

• Netflix, знаменитый, но устаревающий (собран в 2005) набор с соревнования Netflix Prize, давшего толчок развитию рекомендательных систем. Также состоит из оценок фильмов.

• Zvuk Dataset — свежий (первая половина 2023) и наиболее подходящий под наш эксперимент набор. Полезное отличие от двух других — наличие 1,5 миллионов item‑ов (треков), что является примером данных промышленного масштаба. Как показал эксперимент, эта особенность является настоящим испытанием для RecSys‑моделей.

Метрики

Мы выбрали три основные метрики качества: Recall, MAP, NDCG. Recall наиболее информативна, когда мы обучаем модель первого уровня (генератор кандидатов), которой обычно является трансформер. MAP и NDCG добавляют информации о качестве ранжирования. Выбраны следующие k: 1, 5, 10, 20, 100. Если используется двухуровневая схема, то важнее всего метрики с большим k (хотим, чтобы как можно больше верных кандидатов прошли на второй уровень). Если же наша модель выдаёт финальные предсказания, то важны небольшие k (в зависимости от требуемого количества рекомендаций)

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

Все метрики качества были подсчитаны одним и тем же внешним инструментом — через RePlay, в который подавались готовые рекомендации от разных моделей и общий ground truth. Аналогично метрики времени одинаково собраны через модуль time в Python.

Конфигурация

Техническая конфигурация среды для экспериментов:

• 1x GPU A100 (80 ГБ)

• 10x vCPU (Intel Xeon® Gold 6248R CPU @ 3.00GHz)

• 128 ГБ RAM

• 1 ТБ SSD

• Python v3.9

• replay‑rec v0.18.0

• recbole v1.2.0

• recommenders v1.2.0

Предобработка данных

В ходе экспериментов мы столкнулись с удивительной проблемой: RecBole во время предобработки входных данных использует RAM в объёме, в разы большем, чем доступная память GPU, вес модели и сам набор. Отчасти это связано с обязательной внутренней аугментацией (о ней расскажем дальше), а отчасти это просто особенность реализации. Таким образом, при нашей заданной конфигурации со 128 ГБ RAM (которую нет возможности отдельно увеличить), RecBole не может обработать более 35 млн строк данных. Подавать каждому фреймворку на обучение наборы данных разного размера бессмысленно для целей эксперимента. Поэтому все использованные наборы мы перед подачей ограничили последними 35 млн взаимодействиями.

Для каждого эксперимента мы выполнили следующие предобработки исходных наборов данных (в таком порядке):

• Из всех данных взяли только взаимодействия user‑item.

• Из всех взаимодействий оставили только положительные (поскольку классический SASRec умеет работать только с положительной обратной связью). Фильтровали по следующим условиям:

  • Для MovieLens — rating >= 3 (5-балльная шкала);

  • Для Netflix — rating >= 3 (5-балльная шкала);

  • Для Zvuk — rating >= 30 (здесь рейтинг — это секунды прослушивания трека пользователем).

• Оставили в каждом наборе только user_id, item_id и timestamp.

• Обрезали слишком длинные наборы по timestamp (чтобы RecBole смог обработать):

  • Для MovieLens — всего 20 млн интеракций, обрезать не потребовалось;

  • Для Netflix — взяли последние (по timestamp) 40 % взаимодействий;

  • Для Zvuk — взяли последние (по timestamp) 25 % взаимодействий.

• Удалили пользователей, имеющих в итоговом наборе менее трёх взаимодействий.

Затем необходимо определить логику разделения наборов данных (split). На картинке ниже показаны два возможных способа разделения данных на обучающую, валидационную и тестовую выборки: Time split и Leave One Out split. Time split (TS) — более правильный с научной точки зрения способ (модель не заглядывает в будущее), однако мы использовали Leave One Out split (LOO), поскольку это единственный метод, реализованный в Recommenders, а также использованный авторами в статье SASRec.

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

Особенности генерации рекомендаций

Ещё один важный момент состоит в том, как рассматриваемые библиотеки поступают с уже просмотренными пользователем элементами при генерации рекомендаций. В Movielens и Netflix все пары user‑item — уникальные, поэтому в тестовой выборке для пользователя не может присутствовать item, с которым он уже взаимодействовал. При генерации рекомендаций на этих наборах мы будем удалять из выдачи уже просмотренные пользователем элементы — такая возможность у нас есть для всех трёх библиотек:

• В RePlay есть специальная функция постпроцессинга RemoveSeenItems(), которая может быть передана на валидацию и предсказание в виде callback‑а, чтобы убрать из выдачи модели уже просмотренные пользователем элементы.

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

• В Recommenders нет своей функции генерации рекомендаций, а есть только метод predict(). Поэтому удаления просмотренных элементов тоже нет (но мы самостоятельно реализовали его там, где оно требуется).

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

Результаты

Что мы узнали об отличиях реализаций

В ходе экспериментов и исследования кода удалось установить два принципиальных отличия RePlay, RecBole и Recommenders: это наличие или отсутствие аугментации данных и способ вычисления функции потерь. С помощью иллюстраций ниже объясним, что это значит, а затем разберёмся, как это влияет на обучение. Здесь и далее: U — количество уникальных пользователей, I — количество уникальных item-ов (фильмов, треков), L — длина последовательности, подаваемой в трансформер, B — размер батча.

В RecBole авторы добавили аугментацию данных, которая работает, как показано на иллюстрации выше. От исходной последовательности поочерёдно отрезается справа по одному элементу, который отправляется на валидацию (на обучение при этом поступает оставшаяся часть последовательности). Такая аугментация увеличивает изначальный набор данных в O(L) раз в оперативной памяти. В теории, механизм attention должен заменять функцию этой аугментации, поэтому преобразование само по себе не очевидно. К тому же в оригинальной статье и коде SASRec аугментации нет. Тем не менее, в RecBole это сделано не просто так и имеет смысл при используемом способе подсчёта функции потерь, о котором поговорим ниже.

На картинке выше показаны максимально упрощённые схемы прямого прохода SASRec во всех трёх библиотеках (тут считаем, что loss‑функция — это перекрёстная энтропия по всем item‑ам). Схемы демонстрируют тот факт, что в RecBole и Recommenders используется более простой способ расчёта функции потерь: лишь по последнему элементу в последовательности. Таким образом, итоговый тензор, на котором вычисляется loss‑функция, становится в L раз меньше, чем в RePlay.

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

Недостаток в том, что при такой схеме придётся хранить в памяти GPU логиты для каждой интеракции (тензор размера B x L x I). Если подставить приблизительные размеры для Zvuk (B = 256, L = 50, I = 750 000, fp32), то получим B x L x I x 4 = ~4e10 байтов (36 ГБ). Тензоров такого размера в видеопамяти хранится два, поэтому размер батча для RePlay в нашем эксперименте ограничивается числом B.

Альтернатива этому подходу, реализованная в RecBole и Recommenders, позволяет хранить на этом этапе лишь тензор размерности B x I и увеличить размер батча в L раз, что влечёт ускорение обучения, но качество снижается.

Проблему с большим тензором в памяти GPU в Replay можно решить при помощи сэмплирования item‑ов при подсчёте loss‑функции. За это отвечает параметр loss_sample_count, задаваемый при создании SASRec модели: количество item‑ов, которые будут случайным образом сэмплироваться без повторений при каждом подсчёте loss.

Подытожим теоретические отличия реализаций:

• В Replay модель обучается на предсказаниях для всех элементов последовательности, аугментаций нет.

• В Recommenders обучение происходит только на предсказаниях для последних взаимодействий, без аугментаций. Модель получает значительно меньше сигнала для обучения, но и видеопамяти при одном B потребляется в ~L раз меньше, чем в RePlay.

• В RecBole также обучение происходит только на предсказаниях для последних взаимодействий, но есть описанная выше аугментация данных. В сумме за одну эпоху в функцию потерь попадает столько же логитов, как и в RePlay, но вычислений при этом делается в L раз больше (а видеопамяти при том же B потребляется в ~L раз меньше), чем в RePlay.

Описание таблиц с результатами

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

Остальные три графика на каждой иллюстрации отвечают за метрики качества: Recall, MAP и NDCG соответственно. Построены графики для каждого k из 1, 5, 10, 20, 100. Шкала у всех метрик качества линейная. Чем выше метрика, тем лучше.

Выводы

Длительность работы

Длительность работы отображена на тёмно‑синих графиках.

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

• По длительности обучения, подготовки к ней и суммарному времени RecBole всегда проигрывает с большим отрывом. По длительности тренировки проигрыш в 6 раз и более! Причиной этого является наличие встроенной аугментации, которую мы обсудили выше.

• Длительности подготовки к тренировке у RePlay значительно выше, чем у Recommenders, но абсолютные значения невелики по сравнению с временем самой тренировки.

• По времени тренировки с небольшим отрывом побеждает Recommenders. На Movielens и Netflix победитель не ясен, но с более крупным набором данных Zvuk Recommenders справляется на 6% быстрее RePlay. Это объясняется бóльшим размером батча и меньшим учётом сигнала обучения.

• Длительность предсказания во всех экспериментах очень наглядна: RecBole на порядок медленнее RePlay, а Recommenders на порядок медленнее RecBole. Отсюда наблюдения:

  • RePlay ориентирован на промышленное использование, поэтому скорость предсказания в нём максимально оптимизирована.

  • В RecBole скорость предсказания средняя.

  • В Recommenders же предсказание в двух замерах из трёх медленнее, чем его собственное обучение! Это объясняется неудачными требованиями к формату данных на предсказании, которое, к тому же, поштучное для каждой пары user‑item.

• По последнему столбцу Total time видно, что RePlay всегда работает быстрее ближайшего конкурента Recommenders (на 24% на Zvuk и в несколько раз на других наборах данных). RecBole отстаёт от обоих конкурентов в разы сильнее за счёт очень длинного обучения.

Метрики качества

Перейдём к метрикам (графики со светло‑голубым фоном). На наборе MovieLens (20m):

• Все три метрики RePlay и RecBole практически совпадают, с незначительным отрывом RePlay на больших k.

• Recommenders на этом наборе отстаёт от конкурентов. По Recall не так значительно, а по MAP и NDCG — на 30–50%. Это объясняется меньшим количеством поступившего сигнала.

На наборе Netflix картина немного другая:

• RecBole и Recommenders показывают похожий результат. RecBole опережает по MAP, но отстаёт по Recall при больших k.

• RePlay по всем метрикам является абсолютным фаворитом. Учёт всех элементов последовательности при обучении приносит тут свои плоды.

• Видим деградацию RecBole по отношению к предыдущему набору данных. Разница в данных в том, что в Netflix больше item‑ов, чем в MovieLens. Возможно, RecBole хуже с этим справляется.

На наборе Zvuk картина ещё более явная:

• RePlay уже очень сильно (на 30–50%) опережает конкурентов по всем метрикам. В основе этого по‑прежнему лежит учёт всех последовательностей целиком.

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

• RecBole на этом наборе данных отстаёт ещё более выраженно. Здесь причина уже кроется в принудительной фильтрации просмотренных item‑ов: в ground truth на этом наборе достаточно часто попадаются элементы, с которыми пользователь уже взаимодействовал.

Общий вывод

• Во всех проведённых нами экспериментах SASRec в RePlay показывает такое же или лучшее качество по сравнению с двумя его конкурентами. На крупных наборах данных разница очень заметная.

• По времени обучения (и подготовки к нему) RePlay незначительно отстаёт от Recommenders, а вместе они на порядок опережают RecBole

• По времени предсказания RePlay является лидером с большим отрывом. Второе место у RecBole. А в Recommenders разработчики, скорее всего, вообще не уделяли внимание выдаче рекомендаций

Исходный код экспериментов

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

Дополнительные возможности RePlay

Теперь рассмотрим дополнительные возможности RePlay, которые отсутствуют у конкурентов.

Предобработка входных данных (ETL)

В RePlay есть отдельный модуль (replay.preprocessing) для предобработки данных. Там содержатся различные фильтры, инструменты для кодирования признаков, разбиения данных на сессии, дискретизации, преобразования типов и многого другого. Самым важным во всём этом является то, что абсолютно вся работа с RePlay, включая предобработку, может одинаково осуществляться через Pandas, Polars или Spark. При этом система гарантирует, что результат работы всегда будет одинаковым с точностью до нескольких знаков.

Эта особенность даёт разработчикам возможность использовать один и тот же код как для небольших экспериментов, так и для крупных продуктовых проектов. Можно сделать концепт рекомендательной системы на Pandas, а затем лёгким преобразованием перевести всё на Spark, получив при этом возможность делать вычисления на больших объёмах и распределённо. Для тех, кто ещё не знаком с Polars, — это высокопроизводительная библиотека на Rust для работы с табличными данными, поддерживающая многопоточность и ленивые вычисления.

Примеры работы ETL можно найти в репозитории RePlay. Например, в этом ноутбуке начиная с ячейки 21 предсказание делается на Pandas и Spark — результат идентичный. А в другом ноутбуке можно посмотреть примеры работы наиболее популярных методов фильтрации данных.

Обучение на нескольких GPU

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

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

• DDP (Distributed Data Parallel): распределяет данные между GPU, синхронизируя градиенты.

• FSDP (Fully Sharded Data Parallel): распределяет модель, оптимизатор и данные между GPU для экономии памяти.

Пример перехода на две GPU в рамках одной физической машины:

import lightning as L trainer = L.Trainer(...,     accelerator="gpu",     devices=2,     strategy="ddp")  trainer.fit(model, ...)

Вот такое ускорение можно получить:

Заключение

Мы рассмотрели две наиболее популярных на сегодняшний день библиотеки для рекомендательных систем RecBole и Microsoft Recommenders и сравнили их с RePlay, предложенным Сбером. RePlay — это единственное решение из трёх, стабильно работающее с практически любыми вводными и готовое для промышленного использования.

По результатам проведённых экспериментов, SOTA‑модель SASRec в RePlay с отрывом опережает аналогичные в RecBole и Recommenders. К тому же только в RePlay разработчикам будут доступны многочисленные модификации и возможности конфигурации.

Благодарим за прочтение и приглашаем к участию в разработке нашей библиотеки. Будем рады любым обсуждениям, запросам новых функций, а также звёздочкам в нашем GitHub. В репозитории есть подробные примеры использования всех функций и моделей RePlay. Библиотека активно развивается, поэтому по любым вопросам вы можете смело оставлять issue, и мы вам ответим.