RecSys Summer School, день первый.

На этой неделе перед основной конференцией ACM RecSys проходит летняя RecSys школа в Вене, большую часть которой составляют лекции различных профессоров / ресерчеров.

Для меня это возможность научиться чему-то новому, набрать побольше материала для собственного курса по рексису, понетворкаться, а также потусить целую неделю в Вене :)

Что интересного было в первый день:

1. Dietmar Jannach, один из самых цитируемых ученых в RecSys, выступил с вводной лекцией про рекомендательные системы: про их ценность, алгоритмы, оценку качества. С такой лекцией он выступает уже не первый раз, презентации прошлых лет есть в открытом доступе.

Приводил много разных фактов про пользу рексистем. Например, (1) 35% выручки Амазона атрибуцируется рексистемам, (2) а в Нетфликсе говорят, что с помощью персонализации и рексистем “экономят” больше миллиарда долларов в год.

Интересно было послушать и про историческое развитие области:
* в 1992 году в статье Using collaborative filtering to weave an information tapestry впервые был упомянут термин “Collaborative Filtering”
* в 1994 появился первый кейс индустриальной рексистемы (GroupLens, рекомендация новостей), статья GroupLens: an open architecture for collaborative filtering of netnews
* в 2003 Амазон опубликовал статью про Item-to-Item Collaborative Filtering
* потом состоялся небезызвестный Netflix prize (2006 — 2009), в рамках которого Нетфликс выложил самый большой на тот момент рекомендательный датасет с пользовательскими рейтингами фильмов. Про это есть хороший рассказ от CPO Нетфликса на рексисе в 2014 году (тык)
* позже от задачи предсказания рейтингов перешли к learning-to-rank парадигме, стали использовать implicit feedback (время просмотра, клики и тд). Активно использовали матричную факторизацию
* сейчас царит deep learning, про использование которого в рексистемах ваш покорный слуга аж четыре лекции в ШАДе в прошлом учебном году читал, и в этом планирует прочитать еще больше :)

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

Упоминал beyond accuracy метрики (статья Beyond accuracy: evaluating recommender systems by coverage and serendipity).

Fun fact: в какой-то момент Dietmar занимался рексистемой для премиальных кубинских сигар =)

2. Barry Smyth (h-index 85!) выступил с рассказом по мотивам статьи People Who Liked This Also Liked ... A Publication Analysis of Three Decades of Recommender Systems Research, в которой приводится аналитика по всем RecSys публикациям за ближайшие 30 лет. Также он немного дополнил рассказ про историю рексистем, показал статью аж 1990 года от Jussi Karlgren под названием An Algebra for Recommendations, в которой уже говорится про моделирование пользовательского поведения и предсказание будущего пользователей. Еще показал очень красивое издание Communications of the ACM 1997-го года, special issue on recommender systems (картинку прикладываю).

Получилось, что за последние 30 лет появилось порядка 50к статей про рекомендательные системы.

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

Best Practices for Offline Evaluation.

Под оффлайн-оценкой качества рекомендаций подразумевается типичный для ресерча процесс (присутствует в 87% RecSys’23 статей), когда мы берем датасет с пользовательским фидбеком, сплитим на train/valid/test, замеряем метрики на тесте.

Ниже идет моя вольная интерпретация лекции от Lien Michiels на RecSys Summer School:

1. Большая часть ресерч статей — это “мы увеличили ndcg / recall на датасете X на 0.0Y% и побили SOTA”. Этим улучшениям нет доверия. По ходу школы неоднократно шутили, что если бы можно было просуммировать зарепорченные приросты из всех статей, побивших соту, то мы бы давно вышли за верхние границы метрик. Есть непаханое поле для более осознанного ресерча — задайте stakeholder’ов (например, кроме пользователей это могут быть content creator’ы, сама платформа), сформулируйте реалистичный objective (e.g., хотим не только поднять точность для пользователей, но и поднять exposure по content creator’ам).

2. Запускайте эксперименты несколько раз (с зафиксированными сидами), выкладывайте весь код — не только код метода, но и код запуска экспериментов, включая бейзлайны; и даже код тюнинга гиперпараметров.

3. Используйте публичные датасеты, при этом выбирайте наиболее большие и свежие.

4. Очень популярна n-core фильтрация, когда из датасета фильтруются все пользователи и айтемы с менее чем n взаимодействиями. Не нужно делать ее просто так; повторение за другими статьями — не обоснование.

5. Не используйте совсем рандомные дата сплиты (это лик).

6. Всегда перезапускайте бейзлайны (на своих машинках), не копируйте результаты из других статей.

7. Используйте сильные бейзлайны. Например, в статьях часто используют BPRMF (матричная факторизация с BPR-лоссом), а EASE — редко . А метрики у него выше :)

8. Используйте beyond accuracy метрики — например, coverage (насколько ваш алгоритм своими рекомендациями покрывает весь каталог; для кандгена актуально); время работы алгоритма.

9. Нужно тюнить все модели (и все гиперпараметры), а не только свои. Включая бейзлайны!

10. Считайте метрики без сэмплирования негативов.

11. Зачастую, если пофильтровать из рекомендаций то, что у пользователя в истории уже встречалось, можно поднять метрики. Это нормально, но если так делаете — нужно явно писать (сейчас часто не пишут).

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

1. На лекции говорилось, что в некоторых ситуациях отсутствие таймсплита для эвала — это нормально. Что это зависит от домена (например, в музыке таймсплит менее необходим чем в новостях), и что иногда для таймсплита недостаточно данных. Я считаю что тайм сплит нужен абсолютно всегда, даже в доменах типа музыки. Еще был кусочек про user split, что если в тест и трейн класть непересекающихся пользователей, то будем проверять strong generalization. Это совсем не соответствует сценарию реального применения.

2. Также было сказано, что если все-таки сэмплируете негативы для метрик, то надо сэмплировать их пропорционально популярности (а не равномерно). Это тоже не соотвествует сценарию применения.

3. В качестве примера хорошей метрики приводился ndcg (на сэмплированных айтемах / индексе). Но он ничего информативного не измеряет. Если вы обучаете модель для стадии отбора кандидатов, то нужно смотреть на полноту (Recall@K), причем с большими значениями K. Если для ранжирования — надо замеряться не против случайных айтемов, а против других показанных в той же выдаче объектов (impression’ов). По крайней мере, так делают все в индустрии, и это хорошо работает.

4. С тюнингом размерности эмбеддингов тоже не совсем согласен — в зависимости от сценария применения это может быть не целесообразно. Например, если вы пересчитываете векторы пользователей в оффлайне и загружаете в key-value storage, то у вас есть ограничения по памяти. На практике для одной модели редко когда можно хранить больше 100-1000 квантизованных флотов на пользователя.

И прикладываю пару фотографий с этого дня школы :)