- PVSM.RU - https://www.pvsm.ru -
В онлайн-кинотеатре ivi десятки тысяч единиц контента и задача «выбрать, что посмотреть» становится нетривиальной.
О рекомендательной системе в ivi, которая занимается подбором контента на основе пользовательских интересов (внутреннее название — Hydra [1]) мы писали тут [2] и тут [3]. Прошло уже много времени и код проекта значительно изменился: оффлайн часть переехала на Spark, онлайн часть адаптировалась к высоким нагрузкам, Hydra начала использовать другую рекомендательную модель — все эти изменения будут освещены в статье.
В далёком 2014 Hydra была создана в виде Python приложения: данные для рекомендательной модели подгружались отдельным скриптом — «оффлайн-частью» — из внешних источников (Vertica, Mongo, Postgres). Скрипт готовил user-item матрицу размерностью , где m — число пользователей в обучающей выборке, а n — размер каталога (количество уникальных единиц контента), подробнее про item-based персональные рекомендации можно почитать в статьях Сергея Николенко [4].
История смотрения юзера — это вектор размерности , в котором для каждого контента, с которым взаимодействовал пользователь (посмотрел, оценил), стоят единицы, остальные элементы нулевые. Так как каждый юзер взаимодействует с деcятками единиц контента, а размер каталога составляет тысячи единиц, мы получаем разреженный вектор-строку, в котором очень много нулей и матрица user-item состоит из таких векторов. Онлайн-кинотеатр ivi собирает богатый фидбэк от пользователей — просмотры контента, оценки (по десятибальной шкале), результаты онбординга (бинарные предпочтения «нравится — не нравится», вот презентация с примером от Netflix [5]) — на этих данных и обучается модель.
Для выдачи рекомендаций использовался классический memory-based алгоритм — Hydra «запоминала» обучающую выборку и хранила матрицу пользовательских просмотров (и оценок) в памяти. С ростом аудитории сервиcа пропорционально рос и размер матрицы user-item. Архитектура рекомендательного сервиса на тот момент выглядела следующим образом:
Как видно на схеме, фидбэк от пользователей (просмотры, оценки контента, отметки онбординга) сохраняется в быстрые key-value хранилища (MongoDB и Redis) и в Vertica — колоночное хранилище данных. В вертику данные льются инкрементально с помощью специальных ETL процедур.
Оффлайн-часть запускается ежедневно по крону: выкачивает данные, обучает модель, сохраняет её в виде текcтовых и бинарных файлов (разреженные матрицы, python-объекты в формате .pkl). Онлайн-часть формирует выдачу рекомендаций на основе модели и истории целевых действий пользователя — просмотров, оценок, покупок контента (пользовательский фидбэк читаем из Redis/Mongo). Рекомендации выдаются с помощью нескольких десятков процессов python, запущенных на каждом сервере (всего в кластере Hydra 8 серверов).
Такая архитектура порождала несколько проблем:
Система в таком виде (с постоянными доработками и улучшениями) дожила до февраля 2017 года. Время на загрузку данных в оффлайн-части росло алгоритм модели оставался неизменным. В начале 2017 мы решили переехать с memory-based рекомендательной модели на более свежий алгоритм ALS (на Coursera есть видео об этой модели [6]).
Если коротко — алгоритм пытается представить нашу огромную разреженную user-item матрицу в виде произведения двух «плотных» матриц: матрицы пользователей и матрицы контента:
ALS позволяет обучить для каждого пользователя вектор размерности — т.н. «скрытые факторы» пользователя. Каждой единице контента соответствует вектор такой же размерности, «скрытые факторы» контента. При этом , размерность пространства скрытых факторов сильно меньше чем размер каталога, каждого пользователя описывает плотный вектор низкой размерности (обычно ).
Произведение вектора пользователя на вектор контента — это релевантность контента пользователю: чем она выше, тем больше шансов у фильма попасть в выдачу. Выхлоп ALS перемалывается в мясорубке бизнес-правил, потому что кроме задачи «показать контент, который понравится пользователю» у рекомендательной системы есть ряд задач, связанных с монетизацией контента, позиционированием сервиса и т.д. Бизнес-правила немного искажают вектор рекомендаций — этот факт нужно учитывать, например, при проведении оффлайн-оценки модели.
Была проведена большая работа по перепроектированию сервиса, результаты которой выглядят следующим образом:
Hydra за год сильно изменилась как в архитектурном плане, так и в алгоритмической части. Более подробно об этих изменениях будет рассказано в цикле статей.
Автор: Dju
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/big-data/278677
Ссылки в тексте:
[1] Hydra: https://ru.wikipedia.org/wiki/%D0%93%D0%B8%D0%B4%D1%80%D0%B0_(Marvel_Comics)
[2] тут: https://habrahabr.ru/company/ivi/blog/232843/
[3] тут: https://habrahabr.ru/company/ivi/blog/247813/
[4] Сергея Николенко: https://habrahabr.ru/company/surfingbird/blog/139518/
[5] примером от Netflix: https://www.useronboard.com/how-netflix-onboards-new-users/?slide=64
[6] этой модели: https://ru.coursera.org/learn/unsupervised-learning/lecture/xYpnf/sgd-i-als
[7] numpy.linalg.solve: https://docs.scipy.org/doc/numpy/reference/generated/numpy.linalg.solve.html
[8] событийной аналитики groot: https://habrahabr.ru/company/ivi/blog/236253/
[9] Источник: https://habr.com/post/351176/?utm_campaign=351176
Нажмите здесь для печати.