Описание задачи
Sber RecSys Benchmark Cross Domain (GPU)
Задача для алгоритмов персонализированных рекомендаций, обогащенных кросс-доменными данными.
Для каждого из датасетов участникам необходимо порекомендовать top-K товаров для тестовых пользователей.
Для каждого из датасетов последовательно будет развернут свой docker-контейнер. Данные для решения задачи доступны из docker-контейнера.
Модель должна реализовывать следующий функционал:
- обучение на имеющихся данных;
- сохранение модели;
- загрузка модели;
- генерация рекомендаций;
- сохранение рекомендаций по указанному пути.
Формат решения
Результат нужно сохранить в виде parquet файла submission_zvuk.parquet и submussion_smm.parquet с двумя столбцами user_id и item_id.
Столбец user_id должен содержать id пользователей из файла test.parquet, item_id – список длины k из id товаров, упорядоченных по убыванию релевантности для пользователя.
В проверяющую систему необходимо отправить код алгоритма, запакованный в ZIP-архив.
Решения запускаются в изолированном окружении при помощи Docker. Время и ресурсы во время тестирования ограничены.
Данные задачи
Как выглядят данные и где их взять
Датасеты будут выданы участникам и доступны для скачивания в веб-интерфейсе задачи. Всего будет 4 файла:
- train_zvuk.parquet
- train_smm.parquet
- test_zvuk.parquet
- test_smm.parquet
Во время исполнения кода эти файлы будут доступны из той же директории, из которой запускаются train_predict.py. Сохраненные файлы с рекомендациями система также ожидает увидеть в этой директории.
Их названия:
- submission_zvuk.parquet
- submussion_smm.parquet
Разрешается создавать любые промежуточные файлы и директории на время выполнения кода в рамках предоставленного дискового пространства, не поднимаясь выше исходной (переходы типа ../ не будут работать)
Формат входных данных
Гарантируется, что каждый из файлов можно прочитать с помощью pyarrow.
Все файлыимеют одинаковые колонки (порядок не гарантируется):
- user_id - Синтетический ID пользователя (int32). Если у пользователя в обоих датасетах одинаковый ID, то это один и тот же пользователь
- item_id - Синтетический ID товара (int32). Товары НЕ пересекаются между датасетами. Совпадения item_id не несут в себе полезной информации
- rating - Явный и неявный фидбек пользователей на товары (float32). Большее значение говорит о лучшем фидбеке
- timestamp - Оригинальная временная метка события (int64)
Файлы test_*.parquet являются подмножествами соответствующих файлов
train_*.parquet и не несут в себе новой информации.
Предназначение файлов test - показать, для каких user_id требуется сгенерировать предсказания.
Остальные user_id не будут учтены при подсчете метрик.
Формат выходных данных
Ожидаемый формат выходных данных: 2 бинарных файла в формате parquet: submission_zvuk.parquet и submussion_smm.parquet, содержащие предсказания для соответствующих доменов
В каждом файле ровно 3 колонки: индекс (номер строки, начиная с 0), user_id и item_ids
- user_id (int32) должен содержать ID пользователя в том же виде, как в тренировочном датасете
- item_ids (array[int32]) должен содержать список произвольной длины (или пустой) из item_id данного домена, представляющий собой рекомендации.
- item_id должны быть представлены в порядке убывания релевантности. Важно помнить, что, независимо от длин массивов, будут учтены не более 10 первых элементов. Остальные будут отброшены.
Размер каждого из файлов не должен превышать 50МБ.
Количество строк в файлах произвольное, но при подсчёте метрик учитываются только user_id перечисленные в файле test_*.parquet.
Критерии оценивания
Метрика для оценки качества на каждом из датасетов
Для оценки качества решения на каждом из датасетов используется метрика NDCG@k, где k=10.
Метрика рассчитывается по каждому пользователю отдельно, а затем усредняется. Метрика оценивает качество ранжирования рекомендательной выдачи.
Используется бинарный вариант метрики, в котором учитывается информация о факте наличия предсказанных товаров среди купленных товаров и их порядок в списке рекомендаций.
- i – идентификатор пользователя, целое число от 1 до N
- j – позиция товара в списке рекомендаций для пользователя i, целое число от 1 до K
- N – количество пользователей
- K – количество продуктов в списке рекомендаций, для которогоь ассчитывается метрика
- 1𝑖𝑗 - индикаторная функция, факт приобретения пользователем i продукта на позиции j в списке рекомендаций
- 𝑅𝑒𝑙𝑖 - количество продуктов, фактически приобретенным пользователем i в тестовом периоде
Ноутбук с реализацией подсчета метрик предоставлен в Metrics.ipynb.
Обратите внимание, что правильный ответ для каждого из пользователей (ground_truth) скрыт в тестирующей системе. Поэтому для локального подсчета метрик необходимо сформировать свой ground_truth из предоставленных датасетов.
Интегральная метрика
Интегральная метрика рассчитывается только для решений, успешно отработавших на каждом из датасетов.
Итоговая оценка решения Участника рассчитывается как геометрическое среднее метрик по каждому из датасетов.
- D – множество датасетов, входящих в Бенчмарк,
- |𝐷| - количество датасетов, входящих в Бенчмарк,
- 𝑆𝑖 = NDCG@10 на датасете с порядковым номером i, входящем в D
Итоговый балл = 0,7*(Метрика) + 0,3*(Защита проекта)
Ограничения
- В течение одного дня Участник может загрузить для оценки не более 5 решений.
- Лимит устанавливается на сутки, начиная с 00:00.
- Участник, чьи решения используют какие-либо данные, помимо данных, содержащихся в train и test, будет дисквалифицирован.
- Контейнер с решением запускается с GPU-конфигурацией.
Контейнер с решением запускается в следующих условиях:
- 243 RAM
- 16 vCPU * 1 GPU Tesla A100 80 ГБ
- время на выполнение решения: 90 минут на тренировку и инференс
- максимальный размер упакованного архива с решением: 10 Мб