Подготовка датасета для офлайн-оценки рекомендательных моделей: что проверить перед запуском экспериментов
<img src="https://habrastorage.org/getpro/habr/upload_files/02b/cf9/6dc/02bcf96dc6c2ab95c3870859125f798f.jpg" /><p>Привет, Хабр! Меня зовут Алексей Васильев, я тимлид команды «Рекомендательные системы и персонализация» Sber AI Lab — Центра практического искусственного интеллекта Сбера. Мы занимаемся исследованиями в области рекомендаций, разрабатываем новые модели и, конечно, сравниваем свои результаты с результатами коллег и других исследователей. И <em>регулярно сталкиваемся с ситуацией, когда результаты, заявленные в научной статье или полученные от другой команды, не удаётся воспроизвести, хотя ключевые параметры пайплайна полностью совпадают</em>. В этой статье мы с Анной Володкевич, исследователем из нашей команды, расскажем про свой опыт анализа таких расхождений, на основе которого разработали фреймоворк SplitLight.</p><p>Когда результаты научной статьи или успех другой команды не удаётся воспроизвести, обычно начинают с поиска багов в реализации модели: смотрят архитектуру, функцию потерь, способ сэмплирования негативных примеров. Хотя часть несоответствий обусловлена именно этим, наш практический опыт показывает, что <em>процедура подготовки данных зачастую сильнее влияет на итоговый результат</em> сравнения рекомендательных моделей. Например, формулировка из статьи «датасет Zvuk, global temporal split с квантилем 0,9» не сообщает, какие фильтры и агрегации применяли, как обрабатывали события с одинаковыми временными метками и повторные взаимодействия, удаляли ли холодные объекты, какие данные передавали модели на вход и по каким событиям рассчитывали метрики. Поэтому два пайплайна с одним датасетом и одинаковым названием разбиения могут оценивать разные постановки задачи. Это затрудняет воспроизведение экспериментов и сравнение результатов между работами.</p> <a href="https://habr.com/ru/articles/1076666/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1076666#habracut">Читать далее</a>