Моё решение — 5/216 место на VK RecSys Challenge LSVD

Мне было интересно снова поучаствовать в соревновании, чтобы проверить некоторые идеи, поучить Polars и поразвивать интуицию вокруг RecSys. Ниже кратко напишу про результаты.

Задача: нужно было предсказать 100 пользователей, которые лайкнут клип VK Видео, причём с самим клипом в истории нет взаимодействий.

Бейзлайн: будем «рекомендовать» тех юзеров, которые уже лайкали автора в прошлом. Сортируем по сумме лайков. Это уже ~30/216 место.

Решение: возьмём всех юзеров, которые видели автора клипа, и отсортируем их с помощью LGBMRanker. Подробнее — в презентации.

Чего было у тех, кто выше, но не было у меня: трансформер, DCN, SANSA, CatBoost. Я не смог это качественно заиспользовать.

Чем хочется поделиться:

1) Я использовал идею из поста 2023 года канала Wazowski Recommends с экспоненциальными счётчиками, чтобы «переварить» все данные. Для расчёта фичей я использовал словари в словарях в Python с помощью кода на ~500 строк, который мне полностью написала ChatGPT. Грубо говоря, я пробежался for-циклом по всему датасету и с экспоненциальным затуханием насчитал все фичи без даталиков.

2) Всех юзеров я разбил по user_id % M == k и работал только с выбранной пачкой (простое шардирование), что позволило гибко настраивать trade-off «скорость vs RAM». Это был ключевой шаг, чтобы обработать все данные.

3) Я пытался искусственно побить клипы на кластеры по контенту и насчитать фичи, но это оказалось бесполезным занятием. У меня есть теория, что когда ты создаёшь группировку user/item на основе контента, но такой группировки не существует в самом сервисе, — это бесполезно для качества.
Например, если мы рекомендуем продукты питания, у нас есть категоризация сервиса и фичи вида user–category. Категории существуют в каталоге → фичи значимые. Если же мы создадим semantic id и посчитаем фичи вида user–semantic-id, эти фичи дадут меньший эффект, чем user–category.

4) Задача подбора аудитории в целом — это во многом история про борьбу за активных людей. Если у вас есть приложение, в котором вы показываете баннер, и вы спросите: кто кликнет на него завтра? Я бы собрал аудиторию из самых активных пользователей приложения. Если отправлять email и собирать аудиторию, кто его прочитает, — это те, кто чаще всего читает email. Тут никакой RecSys / ML не нужен.

И здесь есть тонкая грань между персонализацией и простой эксплуатацией самого активного ядра юзеров под любые нужды. Недаром авторы RecSys Challenge поставили ограничение, что нельзя выбирать одного юзера 101+ раз.

5) Соревнование для меня — во многом про аккуратность, правильную приоритизацию гипотез и доведение их проверки до конца. Также важны тайм-менеджмент, готовность полностью погружаться в эксперименты и терпимость к тому, что очередная идея не улучшает результат.

В общем, участие оказалось очень полезным, всем советую попробовать себя в соревнованиях по Recsys)