Это пет-проект на открытом датасете. Именно поэтому я делюсь деталями так свободно, включая код.
Про аб-тесты общеизвестно, что модель, выигрывающая на оффлайне по ранжирующим метрикам, может легко проигрывать в проде на бизнесовых. Отсюда и встаёт вопрос - что ещё стоит учитывать при отборе моделей для аб-теста. Сейчас это активно обсуждается в статьях
1) Примеры тут для того, чтобы хоть немного показать, насколько обманчивыми бывают высокие результаты по конкретной метрике (например MAP), и что за ними по факту может скрываться в рекомендациях. Повторяющаяся типичная ошибка на множестве запросов, найденная на визуальном анализе - повод для того, чтобы добавить в валидацию метрику, которая сможет отражать эту ошибку количественно. Так, я начинала с классических MAP и Recall. Построенная модель часто рекомендовала непохожие на запрос фильмы, причём одни и те же (тот же "Девятаев", да). Я начала искать причину - увидела, что это фильмы из топа просмотров в датасете. Сделала гипотезу, что у модели popularity bias. Ввела на валидации метрики, которые отражали бы popularity bias количественно. В статье привожу пересечение с популярным алгоритмом. Для модели из соревнования на этой метрике получила 62%, сравнила с другими моделями, подтвердила гипотезу о popularity bias. Продолжила ресёрчить модели, на этот раз снижая popularity bias. Непохожесть рекомендаций на множестве запросов - сигнал о том, что у модели есть проблемы, и что возможно, с этим что-то стоит сделать (зависит от бизнес кейса). Безусловно, во всех моих примерах у фильмов-запросов и фильмов в рекомендациях была общая аудитория, тем более что я здесь показываю почти целиком коллаборативную фильтрацию, то есть - модель в любом случае рекомендует на основе со-встречаемости. Но даже простой bm25 уже можно чётко настраивать под то, стоит ли отдавать предпочтение популярным айтемам, или наоборот.
2) Да, топ просмотров явно идёт от внешних факторов, я тоже думаю, что мощно влияют баннеры на главной, и вполне вероятно - внешняя реклама. Модели на этот bias в исторических данных реагируют сильно, но на мой взгляд в кейсе онлайн-кинотеатра это важно лечить, потому что такие рекомендации не имеют особой ценности. Я для себя в этом проекте пыталась решить задачу именно персонализированных рекомендаций.
3) Ну тут сразу вспоминается lightfm, например. Вопрос в том, как потом считать финальные рекомендации. Мы всё равно должны прийти к какой-то формуле: например, сгладить рассчитанный bias и снизить его вес в финальном скоре, отдавая больший вес скалярному произведению эмбеддингов юзера и айтемов-кандидатов. Но такую формулу тоже нужно как-то валидировать, подбирая аргументы. Да и в любой модели мы должны тюнить гипер-параметры. Мой основной посыл в этой статье - внимательно выбирать, на какую метрику мы их тюним, решая задачу строго персонализированных рекомов. Я тут предлагаю одним из вариантов Recall без популярного. Саша Петров (@asash), который меня ревьюил, предлагал смотреть в сторону popularity-sampled метрик, как в статье Амазона "Don't recommend the obvious..." (https://dl.acm.org/doi/abs/10.1145/3523227.3546753). Ещё я встречала классическиe Recall и NDCG, но в тестовых интеракциях делалался down-sampling для популярных айтемов (https://arxiv.org/abs/2204.12176).
У меня сейчас самый большой интерес именно в том, чтобы найти метрики, максимизация которых приводила бы к желаемому результату или хотя бы была сильно ближе, чем Recall, MAP или Serendipity. Буду благодарная за ссылки)
В плане моделей очень перспективным кажется опять же подход Амазона - не менять модели, но менять лосс с тем, чтобы нивелировать popularity bias, если есть такая задача.
Для инференса двухэтапной архитектуры модель первого этапа обучается на всех данных, которые мы знаем на текущий момент. Именно так, как мы будем потом это делать в проде. Обученный бустинг этот результат будет реранжировать.
Чтобы бустинг умел делать реранжирование, мы должны его обучить. Поэтому мы выделяем ему период для обучения (фиолетовый отрезок) и на время представляем, что это пока что не случившееся будущее. Генерируем кандидатов первого этапа на голубом отрезке, собираем таргеты на фиолетовом (заглянули в будущее, чтобы научиться реранжировать), обучаем бустинг. Теперь у нас есть бустинг, готовый к инференсу.
И инференс мы делаем, имея все данные на текущий момент, то есть - на жёлтом отрезке (фиолетовый и голубой вместе). Потому что у нас больше нет смысла "лишать" себя данных с фиолетового отрезка, они нужны нам для качественных рекомендаций.
Это пет-проект на открытом датасете. Именно поэтому я делюсь деталями так свободно, включая код.
Про аб-тесты общеизвестно, что модель, выигрывающая на оффлайне по ранжирующим метрикам, может легко проигрывать в проде на бизнесовых. Отсюда и встаёт вопрос - что ещё стоит учитывать при отборе моделей для аб-теста. Сейчас это активно обсуждается в статьях
1) Примеры тут для того, чтобы хоть немного показать, насколько обманчивыми бывают высокие результаты по конкретной метрике (например MAP), и что за ними по факту может скрываться в рекомендациях. Повторяющаяся типичная ошибка на множестве запросов, найденная на визуальном анализе - повод для того, чтобы добавить в валидацию метрику, которая сможет отражать эту ошибку количественно. Так, я начинала с классических MAP и Recall. Построенная модель часто рекомендовала непохожие на запрос фильмы, причём одни и те же (тот же "Девятаев", да). Я начала искать причину - увидела, что это фильмы из топа просмотров в датасете. Сделала гипотезу, что у модели popularity bias. Ввела на валидации метрики, которые отражали бы popularity bias количественно. В статье привожу пересечение с популярным алгоритмом. Для модели из соревнования на этой метрике получила 62%, сравнила с другими моделями, подтвердила гипотезу о popularity bias. Продолжила ресёрчить модели, на этот раз снижая popularity bias. Непохожесть рекомендаций на множестве запросов - сигнал о том, что у модели есть проблемы, и что возможно, с этим что-то стоит сделать (зависит от бизнес кейса). Безусловно, во всех моих примерах у фильмов-запросов и фильмов в рекомендациях была общая аудитория, тем более что я здесь показываю почти целиком коллаборативную фильтрацию, то есть - модель в любом случае рекомендует на основе со-встречаемости. Но даже простой bm25 уже можно чётко настраивать под то, стоит ли отдавать предпочтение популярным айтемам, или наоборот.
2) Да, топ просмотров явно идёт от внешних факторов, я тоже думаю, что мощно влияют баннеры на главной, и вполне вероятно - внешняя реклама. Модели на этот bias в исторических данных реагируют сильно, но на мой взгляд в кейсе онлайн-кинотеатра это важно лечить, потому что такие рекомендации не имеют особой ценности. Я для себя в этом проекте пыталась решить задачу именно персонализированных рекомендаций.
3) Ну тут сразу вспоминается lightfm, например. Вопрос в том, как потом считать финальные рекомендации. Мы всё равно должны прийти к какой-то формуле: например, сгладить рассчитанный bias и снизить его вес в финальном скоре, отдавая больший вес скалярному произведению эмбеддингов юзера и айтемов-кандидатов. Но такую формулу тоже нужно как-то валидировать, подбирая аргументы. Да и в любой модели мы должны тюнить гипер-параметры. Мой основной посыл в этой статье - внимательно выбирать, на какую метрику мы их тюним, решая задачу строго персонализированных рекомов. Я тут предлагаю одним из вариантов Recall без популярного. Саша Петров (@asash), который меня ревьюил, предлагал смотреть в сторону popularity-sampled метрик, как в статье Амазона "Don't recommend the obvious..." (https://dl.acm.org/doi/abs/10.1145/3523227.3546753). Ещё я встречала классическиe Recall и NDCG, но в тестовых интеракциях делалался down-sampling для популярных айтемов (https://arxiv.org/abs/2204.12176).
У меня сейчас самый большой интерес именно в том, чтобы найти метрики, максимизация которых приводила бы к желаемому результату или хотя бы была сильно ближе, чем Recall, MAP или Serendipity. Буду благодарная за ссылки)
В плане моделей очень перспективным кажется опять же подход Амазона - не менять модели, но менять лосс с тем, чтобы нивелировать popularity bias, если есть такая задача.
Там логика в другом.
Для инференса двухэтапной архитектуры модель первого этапа обучается на всех данных, которые мы знаем на текущий момент. Именно так, как мы будем потом это делать в проде. Обученный бустинг этот результат будет реранжировать.
Чтобы бустинг умел делать реранжирование, мы должны его обучить. Поэтому мы выделяем ему период для обучения (фиолетовый отрезок) и на время представляем, что это пока что не случившееся будущее. Генерируем кандидатов первого этапа на голубом отрезке, собираем таргеты на фиолетовом (заглянули в будущее, чтобы научиться реранжировать), обучаем бустинг. Теперь у нас есть бустинг, готовый к инференсу.
И инференс мы делаем, имея все данные на текущий момент, то есть - на жёлтом отрезке (фиолетовый и голубой вместе). Потому что у нас больше нет смысла "лишать" себя данных с фиолетового отрезка, они нужны нам для качественных рекомендаций.