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 квантизованных флотов на пользователя.

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