https://arxiv.org/pdf/2002.02126.pdf
https://github.com/gusye1234/LightGCN-PyTorch
Графовые конволюционные сети (далее GCN) стали SOTA для коллаборативной фильтрации. Однако почему так произошло до конца не было изучено. Существующие работы в этой области предназначены больше для задач классификации на графах. Однако авторы отмечают, что два наиболее распространенных "трюков" из GCN - преобразование признаков и нелинейные активации - не особо полезны для рекомендаций. Более того, эти действия приводят к ухудшению качества.
В этой работе авторы хотят упростить дизайн GCN, чтобы оно стало более подходящим для составления рекомендаций. Для этого они описывают новую модель - LightGCN. Она включает в себя только самую необходимую компоненту GCN - агрегацию информации о соседстве. Это происходит путем выучивания векторов пользователей и объектов через линейное распространение по графу с интеракциями. Финальные вектора получаются через взвешенную сумму всех векторов. Такая моделька получается простой, линейной и аккуратной, поэтому ее легко реализовать и натренировать. Также LightGCN демонстрирует улучшение в качестве на 16% по сравнению с Neural Graph Collaborative Filtering - SOTA на графах для рекомендации в тех же самых условиях эксперимента. Авторы показывают рациональность и простоту своей модели через аналитический и эмпирический анализы. Доступна имплементация на TF и PyTorch
В начале упоминается, что GCN хороши для графа с большим числом типов узлов. Если есть только матрица интеракций, то тогда у нас есть только юзеры и пользователи. Так как обычно дополнительная информация не рассматривается, то нет смысла добавлять много слоев с нелинейными преобразованиями, так как это все усложняет, но не дает прироста в качестве. Чтобы убедиться в этом, авторы изучили работу NGCF в том же экспериментальном сеттинге. Из их анализа следует, что в NGCF операции преобразования признаков и нелинейные активации отрицательно влияют на качество рекомендаций. (А используются они потому, что используются в GCN). Авторы этой статьи учитывают это, поэтому эти операции не включены в LightGCN. Включена только основная составляющая GCN - агрегация "соседства".
В GCN есть несколько уровней. На 0-ом уровне есть изначальные вектора, которые получаются по айдишникам. На первом уровне вектор пользователя или объекта - результат агрегации векторов сущностей, с которыми было взаимодействие. В качестве агрегирующей функции может быть использована взвешенная сумма, LSTM и другие. (Вообще, как я понимаю, смысл в том, что на первом уровне вектор пользователя получается из векторов объектов, с которыми были взаимодействия. На втором уровне, чтобы получить вектор пользователя, нужно опять же взять те же самые "положительные" объекты. Однако, вектора объектов теперь учитывают свое соседство - то есть других пользователей, которые с ними взаимодействовали. Получается, что вектор пользователя второго уровня учитывает пользователей, которые потребили те же айтемы, что и сам изначальный пользователь. Таким образом, получается агрегация по графу). Вектора в LightGCN получаются путем взвешенной суммы (которая не дает векторам возрастать с ростом количества уровня). Вектора получаются без учета самих себя с предыдущего уровня (что обычно делается наоборот). Это сделано, потому что финальные вектора получаются путем взвешенной суммы всех предыдущих векторов (с других уровней). Последняя сумма взвешивается через гиперпараметр (например, 1/(k+1), где k - номер уровня). Комбинация векторов с разных уровней происходит по трем причинам: 1) эмбеддинги становятся сглаженными с ростом уровня, 2) вектора с разных уровней имеют разный смысл (0 уровень - интеракции, 1 уровень - пересечение по интеракциям и тд), 3) благодаря комбинации учитываются самосоединения (self-connections) - фишка из GCN. На выходе считается inner product между пользователями-объектами.
Сам граф составляется через матрицу смежности (блочная матрица из 2 нулевых, матрицы интеракций и транспонированной матрицы интеракций). Матрицу эмбеддингов E(l) на каждом уровне можно выразить в явном виде. Поэтому и финальные вектора юзеров-айтемов выражаются в явном виде через изначальную матрицу, в которой хранятся вектора по айдишникам.
Нетрудно заключить, что тренируется только матрица эмбеддингов. Происходит это через BPR loss c L2 регуляризацией. Также авторы отмечают, что dropout они не используют, так как он является элементов регуляризации, которая осуществляется через L2. Утверждается дополнительно, что выучивать коэффициент важности уровней (через который происходит суммирование), не приводит к улучшению.
В статье приводятся многообещающие результаты. Предложенная модель бьет Mult-VAE достаточно неплохо. Причем у нее немного гиперпараметров
У этой статьи много цитирований за относительно небольшое время. Выглядит так, что авторы провели эксперименты честно. Поэтому превосходство над Mult-VAE возможно действительно имеет место быть. (Mult-VAE - единственная модель, которая победила бейзлайны в статье "Are We Really Making Much Progress? ..."). Однако если сравнивать между собой эти модели, то в Mult-VAE вектора юзеров составляются по их интеракциям. Следовательно, можно обучать модель и делать инференс по батчам (лениво считывая данные). А для LightGCN этого сделать невозможно. Поэтому на больших датасетах применить эту модель может быть сложно. Также для обновления рекомендаций из-за новых интеракций нужно переучивать модельку, что тоже может оказаться проблематично. В общем, в практическом применении для оффлайн-рекомендаций Mult-VAE выглядит лучше. Однако Light-GCN, возможно, позволяет давать объяснения рекомендациям через коэффициенты с первого/второго уровней.