Изучил «Рекомендательные системы» из курса Hard ML
С сентября 2024 года я работаю в RUTUBE и первая же задача связана с микросервисом рекомендательной системы. С MLOps технологиями проекта у меня явных сложностей нет, но чтобы быть более эффективным в разработке и эксплуатации, я решил изучить теорию.
Эта тема мне всегда была интересна. Впервые о подходах к их реализации я услышал в 2017 году в курсе MITx: 15.071x The Analytics Edge на примере Netflix. Далее были видео от ШАД и команды Яндекс.Дзена с теорией и обширная практика работы в контентном портале, где я подробно изучал рекомендательные системы платформ дистрибуции контента.
Но время идёт, информация забывается, подходы меняются. Поэтому, я решил изучить блок «Рекомендательные системы» из более свежего курса Hard ML.
Это мой конспект данного блока. Содержание дополняется по мере изучения материалов.
А ещё вам могут быть полезны следующие материалы
- Как подготовиться и пройти System Design Interview — конспект и анализ выступления Александра Поломодова.
- Прочитал и разобрал на молекулы книгу Building Microservices, 2nd Edition - Sam Newman.
- Мой план обучения: ссылки на книги, курсы, каналы по темам дизайна масштабируемых и надежных ML систем, разработки программного обеспечения на Python, DevOps, MLOps и Data Engineering, SRE.
1. Применение и основные концепции
Problem statement
Дано:
- Пользователь u.
- Объект рекомендаций i.
- rui — релевантность объекта i для пользователя u.
Задача: среди всего множества объектов построить отсортированный список рекомендаций по релевантности для пользователя.
Данные
Когда есть данные о взаимодействии с пользователем → Коллаборативные признаки:
- Работают на предположении, что похожим пользователям нравятся похожие объекты и наоборот.
- Позволяют легко построить MVP, т.к. не зависят от домена продукта.
- Обычно это данные вида
user
,item
,rating
,timestamp
.
Когда нет данных о взаимодействии с пользователем → Content-based признаки:
- Статичные.
- Легко интерпретируемые.
- Подходят, когда ещё нет информации о взаимодействии пользователей с объектом.
- Например: эмбеддинги картинок/текста или другой мета-информации.
Виды реакции от пользователя:
Явная реакция | Неявная реакция | |
---|---|---|
Примеры | Конверсии: лайки, поставленные оценки | Микроконверсии: клики, покупка, пропуск рекомендаций |
Точность данных | Точные данные о пользователях → реакция менее предвзята | Есть неопределённость → данные искажены |
Сложность получения | Сложно собрать → меньше данных | Легко собирать → больше данных |
В качестве реакций RecSys системы чаще всего используют неявные реакции из-за большего числа событий.
Архитектура
Большинство компаний используют двухуровневую архитектуру для построения RecSys:
- Модели кандидатов оптимизируют recall, то есть повышают вероятность показа хороших объектов.
- При этом в финальных рекомендациях важна точность (precision), что и оптимизирует ранжирующая модель.
Video corpus (millions) → Candidate generation (hundreds) + Other candidate sources → Ranking (dozens) → User.
Данная схема удобно масштабируется и позволяет строить рекомендации для миллионов объектов.
Ранжирующая модель использует больше признаков и взвешивает только ~100 кандидатов.
- Решаемые проблемы: масштабируемость, свежесть видео, учёт шума в данных.
- Поиск кандидатов происходят с помощью логистической регрессии факта просмотра.
- Веса для регрессии = время просмотра.
Варианты реализации системы
Для разных продуктов может подходить разный тип системы, в зависимости от задержки построения рекомендаций.
Offline | Batch | Realtime |
---|---|---|
Легкие в настройке | Баланс между сложностью и скоростью рекомендаций | Усложняют дизайн системы |
Хорошо подходят для теплых пользователей | Хорошо подходят для продуктов, где возможна задержка между взаимодействиями | Хорошо подходят для «холодных» пользователей |
Можно использовать «тяжелые» алгоритмы | Ограниченные ресурсы для «тяжелых» моделей | Необходимы простые алгоритмы с задержкой до нескольких секунд |
Холодный старт
Холодный старт рекомендаций в E-Commerce:
- Рекомендации построены на основе покупок всех посетителей.
- Не являются персонализированными.
- Важно «зацепить» пользователя, если про него ничего не известно.
Реакция системы на действия пользователя
- После просмотра item у пользователя появляется история (контекст).
- Фидбэк учитывается через несколько секунд, что позволяет исследовать интересы.
- Исследование интересов важно провести на этом этапе, однако пользователю могут не понравиться рекомендации и он уйдет без конверсии.