Forwarded from эйай ньюз
🔥Курс по Deep Learning (Fall 2024) от MIT доступен онлайн!
Один из лекторов - Phillip Isola, чень крутой ресерчер в Computer Vision. Олды помнят его легендарный CycleGAN (2017).
Выложили и слайды, и доп материалы, и видео лекций, и домашки (можете по-честному их выполнить и отправить на проверку в Claude Code :))
Очень качественный базовый курс. Если хотите разобраться в Deep Learning немного глубже промптов, то очень рекомендую к просмотру!
Курс целиком можно скачать тут:
https://ocw.mit.edu/courses/6-7960-deep-learning-fall-2024/video_galleries/lecture-videos/
P.S. Еще один хрестоматийный курс по DL - это Стенфордский CS231 от Карпатого.
#ликбез
@ai_newz
Один из лекторов - Phillip Isola, чень крутой ресерчер в Computer Vision. Олды помнят его легендарный CycleGAN (2017).
Выложили и слайды, и доп материалы, и видео лекций, и домашки (можете по-честному их выполнить и отправить на проверку в Claude Code :))
Очень качественный базовый курс. Если хотите разобраться в Deep Learning немного глубже промптов, то очень рекомендую к просмотру!
Курс целиком можно скачать тут:
https://ocw.mit.edu/courses/6-7960-deep-learning-fall-2024/video_galleries/lecture-videos/
P.S. Еще один хрестоматийный курс по DL - это Стенфордский CS231 от Карпатого.
#ликбез
@ai_newz
Forwarded from Дратути Антон
Вечерние размышления про руководство [2/x]
Над следующим топиком я рефлексировал достаточно продолжительное время, но так и не смог точно для себя определить, насколько аналогии, приведенные ниже — уместны. Но хотелось бы считать, что я смог хоть как-то донести свою мысль.
Руководитель — организатор
Организовывать всё и вся — это моя любовь☺️ , мой драйв с самого детства. Что в школе я организовывал взаимодействия классов, что в университете общие конспекты, написание билетов и т.д., что на работе страюсь сделать что-то эдакое. Я невероятно люблю приходить к самоорганизующимся самостоятельным системам, где, для того, чтобы они стали "само-" ты приложил руку 😀 . Но до этого, зачастую, бесконечный дебаг человеческих взаимоотношений.
Хоть это, вероятно, и глупо, но я часто думаю про организации как о ПО👨🦳 . Да-да, те самые программы, только очень сложные. Есть куча компонентов, они как-то связаны с друг другом. И, конечно, же, они обладают большим набором свойств. Вот часть из них:
— К некоторым нет доступа. Прям как в C++ инкапсуляция🤓 . Правда можно через указатели пробраться к приватным членам/методам (людям) класса (команды) и даже как-то на них повлиять (дать задачи), но с большой вероятностью прилетит по голове, ну или прокатит 🏥 . А можно стать дружественным классом (договориться о взаимодействии) и быть может некоторые интерфейсы и поля тебе будут открыты;
— Иногда компоненты прям дублируют друг друга. Обычно в разработке нам некогда думать о переиспользуемости🧠 , а в руководстве — не хотим/не можем договориться 😊 ;
— Компоненты — это сущности составные. Но минимально базовым является человек;
— В компонентах бывают возникают баги. В случае команд зачастую это проблема в процессах, а в случае людей — мотивация, усталость и много много другого. И для всяких случаев нужно понимать, как дебажить: минимально возможный инструмент — это принт, т.е. поговорить🔼 .
Я помню случай, когда мне нужно было дебажить TensorRT на предмет нестабильности. Ну вот сама по себе библиотека — проприетарная, а потому, как внешнему разработчику, мне не доступны исходники. Приходится буквально дебажить Black-Box в надежде отловить проблему. Но, я же инженер, поэтому исследовал кишки бинарников и в хвост и в гриву, в итоге поборол проблемки🤯 .
В случае людей всё сильно сложнее. Ты не можешь тыкать рандомно и бесконечное число раз, попытки исчисляются единицами, иначе можно подсадить ещё багов (например, демотивация). Но если вдруг всё получается, то ты получаешь новые свойства компонент, за чем наблюдать — одно удовольствие.
Продолжение следует...
Над следующим топиком я рефлексировал достаточно продолжительное время, но так и не смог точно для себя определить, насколько аналогии, приведенные ниже — уместны. Но хотелось бы считать, что я смог хоть как-то донести свою мысль.
Руководитель — организатор
Организовывать всё и вся — это моя любовь
Хоть это, вероятно, и глупо, но я часто думаю про организации как о ПО
— К некоторым нет доступа. Прям как в C++ инкапсуляция
— Иногда компоненты прям дублируют друг друга. Обычно в разработке нам некогда думать о переиспользуемости
— Компоненты — это сущности составные. Но минимально базовым является человек;
— В компонентах бывают возникают баги. В случае команд зачастую это проблема в процессах, а в случае людей — мотивация, усталость и много много другого. И для всяких случаев нужно понимать, как дебажить: минимально возможный инструмент — это принт, т.е. поговорить
Я помню случай, когда мне нужно было дебажить TensorRT на предмет нестабильности. Ну вот сама по себе библиотека — проприетарная, а потому, как внешнему разработчику, мне не доступны исходники. Приходится буквально дебажить Black-Box в надежде отловить проблему. Но, я же инженер, поэтому исследовал кишки бинарников и в хвост и в гриву, в итоге поборол проблемки
В случае людей всё сильно сложнее. Ты не можешь тыкать рандомно и бесконечное число раз, попытки исчисляются единицами, иначе можно подсадить ещё багов (например, демотивация). Но если вдруг всё получается, то ты получаешь новые свойства компонент, за чем наблюдать — одно удовольствие.
Продолжение следует...
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Дата канальи — про «специалистов» в данных / ML / AI
#ML
Про анализ важности фичей
В очередной модели, которую попросили «посмотреть», обнаружил сразу три графика по важности фичей в бустинге:
— По числу сплитов по фиче (дефолтный feature_importances_)
— По gain
— По tree shap
Пропустим пока вопрос о дрифте фич (а они бывают разные с разными эффектами) — про них отдельно стоит написать.
Дальше я наивно ждал интерпретации — но увы.
Когда я об этом спросил услышал две версии от двух тимлидов:
Астерикс— «где gain выше та фича и сильнее»,
Обеликс — «где shap выше та фича и сильнее».
Поскольку галлы строят модели под влиянием волшебного друидского зелья и не знакомы с латинским, немного навайбкодил примеров чтобы показать что для анализа фичей нужны все три важности (это еще не считая анализа стабильности этой важности во времени / по фолдам).
Ключевое в них — кросс-плоты feature_importance по cплитам vs по gain и по shap vs по gain.
Это два графика, которые нужно обязательно смотреть в бустингах.
Если вкратце:
1. Важность по gain сильно завышает редкие бинарные фичи с резким эффектом (в тетрадке это x_strong_rare). Модель редко использует их (малый SHAP), но когда использует — один сплит даёт огромный выигрыш.
Что с такими фичами делать?
Если они сами по себе интерпретируемы и срабатывают редко —
Иначе будут проблемы и с обучением (понадобится больше деревьев и стабильность пострадает) и с интерпретируемостью — такая фича забьет рабочие лошадки по важности + начнет ломать интерпретируемость shap (либо придется считать отдельно для x_strong_rare = 1 или x_strong_rare = 0).
Смотрят либо фичи вылетевшие вверх на графике shap vs gain либо проверяют фичи которые в топе по gain но не в топе по shap.
Бонусом к отдельному сигналу — частота у такой фичи может сильно скакать во времени что еще больше нарушит стабильность модели.
Так что вынос такой фичи в отдельный сигнал — это еще и интерпретабельность PSI модели.
Как это повлияет на калибровку?
Ухудшит “глобальную” калибровку, но улучшает там, где модель реально работает (при x_strong_rare = 0).
2. Есть фичи вроде x_weak_often — с высоким сплитом, но низким shap и gain.
Здесь может быть несколько вариантов:
— +/- симметрично распределенный непрерывный шум
— фича костыль: есть небольшая коррекции с таргетом, но в модель ничего не добавляет
— фича по построения состоит из нескольких бакетов
В любом случае если зажали max_depth / n_estimators чтобы «регуляризоваться» то модель потратит кучу деревьев и сплитов на такие шумные и удобные для сплита фичи вместо того чтобы поймать реальный сигнал.
Еще она может массировать другие проблемы вроде мультиколлинеарности или ликов.
Как еще их можно отловить?
Строить feature_importance по месяцам/фолдам и проверять стабильность важности фичи.
Следить за дисперсией метрики (ex: Gini) на CV.
3. Есть фичи с низким split и не самым высоким gain, но с высоким SHAP.
То есть модель редко по ним сплитится, но почти в каждом объекте они двигают prediction.
Итого:
1. Строим:
- split vs gain
- shap vs gain
2. Если фича:
- top gain, но не top shap → кандидат в сигнал
- top split, но низко по shap и gain → кандидат на выброс
- low split, not high gain, high shap → не трогать, это рабочая фича (пока мы не исследовали ее стабильность по времени)
3. Проверяем:
- стабильность importance по фолдам / времени
- Дисперсию метрики по фолдам кросс-валидации
- PSI условно (x_strong_rare=0)
4. Только после этого:
- feature selection
- регуляризация
Те кто внезапно дочитал до этого момента могут заключить что второй тимлид был прав и надо смотреть только на shap.
Но
.
Особенно, если:
⁃ Он высокий только на трейне
⁃ Нестабилен по фолдам / или времени
⁃ Фича сама по себе нестабильна
⁃ Модель деградирует на OOT
PS.
низкий SHAP не значит что фича плохая.
Например:
— фича-разделитель (регион),
— стабилизирует модель,
— работает только в хвостах,
часто имеют низкий SHAP, но без них качество и стабильность падают.
Про анализ важности фичей
В очередной модели, которую попросили «посмотреть», обнаружил сразу три графика по важности фичей в бустинге:
— По числу сплитов по фиче (дефолтный feature_importances_)
— По gain
— По tree shap
Пропустим пока вопрос о дрифте фич (а они бывают разные с разными эффектами) — про них отдельно стоит написать.
Дальше я наивно ждал интерпретации — но увы.
Когда я об этом спросил услышал две версии от двух тимлидов:
Астерикс— «где gain выше та фича и сильнее»,
Обеликс — «где shap выше та фича и сильнее».
Поскольку галлы строят модели под влиянием волшебного друидского зелья и не знакомы с латинским, немного навайбкодил примеров чтобы показать что для анализа фичей нужны все три важности (это еще не считая анализа стабильности этой важности во времени / по фолдам).
Ключевое в них — кросс-плоты feature_importance по cплитам vs по gain и по shap vs по gain.
Это два графика, которые нужно обязательно смотреть в бустингах.
Если вкратце:
1. Важность по gain сильно завышает редкие бинарные фичи с резким эффектом (в тетрадке это x_strong_rare). Модель редко использует их (малый SHAP), но когда использует — один сплит даёт огромный выигрыш.
Что с такими фичами делать?
Если они сами по себе интерпретируемы и срабатывают редко —
их нужно выносить в сигналы до модели!
Иначе будут проблемы и с обучением (понадобится больше деревьев и стабильность пострадает) и с интерпретируемостью — такая фича забьет рабочие лошадки по важности + начнет ломать интерпретируемость shap (либо придется считать отдельно для x_strong_rare = 1 или x_strong_rare = 0).
Смотрят либо фичи вылетевшие вверх на графике shap vs gain либо проверяют фичи которые в топе по gain но не в топе по shap.
Бонусом к отдельному сигналу — частота у такой фичи может сильно скакать во времени что еще больше нарушит стабильность модели.
Так что вынос такой фичи в отдельный сигнал — это еще и интерпретабельность PSI модели.
Как это повлияет на калибровку?
Ухудшит “глобальную” калибровку, но улучшает там, где модель реально работает (при x_strong_rare = 0).
2. Есть фичи вроде x_weak_often — с высоким сплитом, но низким shap и gain.
Здесь может быть несколько вариантов:
— +/- симметрично распределенный непрерывный шум
— фича костыль: есть небольшая коррекции с таргетом, но в модель ничего не добавляет
— фича по построения состоит из нескольких бакетов
В любом случае если зажали max_depth / n_estimators чтобы «регуляризоваться» то модель потратит кучу деревьев и сплитов на такие шумные и удобные для сплита фичи вместо того чтобы поймать реальный сигнал.
Еще она может массировать другие проблемы вроде мультиколлинеарности или ликов.
Не выбросить такую фичу — ошибка!
Как еще их можно отловить?
Строить feature_importance по месяцам/фолдам и проверять стабильность важности фичи.
Следить за дисперсией метрики (ex: Gini) на CV.
3. Есть фичи с низким split и не самым высоким gain, но с высоким SHAP.
То есть модель редко по ним сплитится, но почти в каждом объекте они двигают prediction.
Выбрасывать такие фичи — тоже ошибка!
Итого:
1. Строим:
- split vs gain
- shap vs gain
2. Если фича:
- top gain, но не top shap → кандидат в сигнал
- top split, но низко по shap и gain → кандидат на выброс
- low split, not high gain, high shap → не трогать, это рабочая фича (пока мы не исследовали ее стабильность по времени)
3. Проверяем:
- стабильность importance по фолдам / времени
- Дисперсию метрики по фолдам кросс-валидации
- PSI условно (x_strong_rare=0)
4. Только после этого:
- feature selection
- регуляризация
Те кто внезапно дочитал до этого момента могут заключить что второй тимлид был прав и надо смотреть только на shap.
Но
высокий shap ничего не гарантирует!
.
Особенно, если:
⁃ Он высокий только на трейне
⁃ Нестабилен по фолдам / или времени
⁃ Фича сама по себе нестабильна
⁃ Модель деградирует на OOT
PS.
низкий SHAP не значит что фича плохая.
Например:
— фича-разделитель (регион),
— стабилизирует модель,
— работает только в хвостах,
часто имеют низкий SHAP, но без них качество и стабильность падают.
Forwarded from Information Retriever
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к статей про рекомендательные системы.
А сегодня, во второй день школы, были лекции по психологии, графовым нейронным сетям, а также про оффлайн оценку качества рексистем. Но про это расскажу чуть позже :)
На этой неделе перед основной конференцией 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к статей про рекомендательные системы.
А сегодня, во второй день школы, были лекции по психологии, графовым нейронным сетям, а также про оффлайн оценку качества рексистем. Но про это расскажу чуть позже :)
Forwarded from Information Retriever
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 квантизованных флотов на пользователя.
И прикладываю пару фотографий с этого дня школы :)
Под оффлайн-оценкой качества рекомендаций подразумевается типичный для ресерча процесс (присутствует в 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 квантизованных флотов на пользователя.
И прикладываю пару фотографий с этого дня школы :)