Как устроена система персонализированных рекомендаций видеоконтента в Megogo

Когда начинаешь улучшать user experience пользователей, бывает тяжело остановиться. Так обстояли дела и с нашей системой рекомендаций. Уже в процессе реализации неперсонализированных элементов системы мы поняли, что это хороший старт, но недостаточно для удобного пользования сервисом. Так что через некоторое время у нас уже было видение двух подсистем персонализированных рекомендаций, основанных на активных действиях пользователя.

PAUL строилась на явных оценках каждого пользователя (лайках и добавлениях в избранное), в то время как ALS – на статистике обо всем просмотренном контенте. Сперва речь пойдет о PAUL.

Полуперсонализированная рекомендация

Сначала у нас были только подборки, основанные на мета-данных (подробнее мы писали о них в предыдущей статье), на основании которых мы решили проверить успешность рекомендаций по активности пользователей MEGOGO. Мы создали две специальных подборки – «Потому что вы добавили в Избранное» и «Потому что вам понравилось». В каждую из них попадали фильмы, которые, согласно системе мета-рекомендаций, были похожи на контент, попавший к пользователю в «Избранное», или которому был поставлен «лайк» соответственно.

Сейчас мы можем раскрыть данные о том, как работала такая полуперсонализированная система. Мы выбрали период и провели подробное исследование поведения пользователей нашего сервиса на смарт-телевизорах одного из крупнейших вендоров.

За этот период подборка «Потому что вы добавили в Избранное» собрала 3500 кликов, а «Потому что вам понравилось» — 1500 кликов.

Несмотря на то, что в целом пользователей на заявленной платформе у нас в тот момент было порядка 980 000, новые подборки рекомендаций смогли увидеть только те из них, кто ставил хотя бы один лайк фильмам (таких было всего 40 000 – около 4%) и добавил хотя бы один фильм в «Избранное» (таких пользователей собралось порядка 53 000, что составляет около 5,3%).

Согласно сравнению с предыдущими показателями подборок, составленных «вручную» и без применения нового алгоритма и показанных пользователям на тех же позициях в интерфейсе за две недели до старта тестов, мы получили следующие результаты:

• «Потому что вы добавили в Избранное» — получила примерно в 5,5 раз больше уникальных кликов (3500 против 600);
• «Потому что вам понравилось» — получила в 3,6 раз больше уникальных кликов (1500 против 400).

Первая персонализированная рекомендация

Получив такое, достаточно убедительное подтверждение эффективности новых подборок с рекомендациями для определенной группы пользователей, мы решили посмотреть как PAUL покажет себя в боевой эксплуатации (даже учитывая, что охват алгоритма мизерный, как было сказано ранее).

Система довольно простая с точки зрения алгоритма, который основан на коллаборативной фильтрации плюс некоторая бизнес-логика. Система анализирует оценки пользователей и на основе этого анализа уже составляет список рекомендаций. В упрощенном виде работу PAUL можно описать так: если предположить, что Пользователь 1 «лайкнул» фильмы «Интерстеллар», «Прибытие», «Чужой» и «Аннигиляция», а Пользователь 2 – фильмы «Интерстеллар», «Чужой», «Космическая Одиссея» и «Марсианин», то первому в подборке выпадут «Марсианин» и «Космическая Одиссея», а второму – «Прибытие» и «Аннигиляция».

Если вы предположите, что подобная аналитическая задача требует огромного количества машинных ресурсов – вы будете абсолютно правы. Для работы PAUL нам пришлось полностью выделить отдельный сервер с 64 ГБ оперативной памяти.

Оставшиеся проблемы и выводы

Самая большая проблема PAUL – вовсе не техническая. К сожалению, в настоящий момент, у этой подсистемы все ещё слишком маленький бизнес-импакт. Чтобы обеспечить релевантность результатов (и экономию ресурсов), в выборку алгоритма попадают только фильмы, получившие не менее 15 оценок, а также пользователи, имеющие не менее 10 лайков/фильмов в «Избранном». Таких пользователей у нас набирается всего-навсего 4-8% в зависимости от платформы. Излишним будет говорить, что эта цифра – мизерная.

Но это не повод отказываться от алгоритма, скорее повод задуматься о некоторых бизнес-процессах. В частности, сейчас мы рассматриваем два пути решения этой ситуации:

• Оптимизировать пользовательский UI для того, чтобы сделать процесс выставления оценок более удобным и насущным;
• Обеспечить каждому новому пользователю полноценный онбординг (нам этот вариант импонирует больше всего, несмотря на то, что он при этом самый сложный в реализации).

Конечно можно было бы снизить пороговые значения параметров для выборки, но это будет экстенсивным путем решения проблемы. Так как, это понизит релевантность, а расход ресурсов наоборот экспоненциально повысится. Такое решение подходит для тестирования функционала системы, но не годится для полноценной работы.

Но по-большому счету система PAUL тоже не более чем часть R&D. В данный момент настоящий венец системы рекомендаций – алгоритм основанный на информации о просмотрах. Именно подобным этому алгоритмом пользуется и Netflix.

Реализация системы рекомендаций на основе данных о смотрении контента. Продукт

Основная причина запуска системы рекомендаций основанной на просмотрах – это увеличение доли пользователей, которые могут воспользоваться ею. Кроме того, эффект от работы системы PAUL был, скажем прямо, незначительным в сравнении с масштабами всей пользовательской базы Megogo.

Так, если при использовании PAUL мы смогли охватить всего от 4% до 8% зрителей, при использовании новой системы мы прогнозировали рост этого показателя практически до 80%. Наши пользователи всегда были хороши в одном деле — смотрении контента, а статистических данных по просмотрам у нас было более чем достаточно, чтобы начать разработку системы практически «с колес».

Проблемы и гипотезы

Нельзя сказать, что обилие статистики по просмотрам решало все наши проблемы. Перед нами стоял ряд задач, решение которых было ничуть не очевидно. Так, например данные о просмотрах нельзя трактовать явно — длительность просмотренного фрагмента не эквивалентна напрямую оценке. Да и даже если фильм досмотрен до конца — это еще не значит, что он понравился пользователю. Кроме того, непонятно что в принципе можно считать единицей измерения «оценки» при просмотре. И вдобавок ко всему, нам нужно было каким-то образом разделять просмотры по времени суток — часто с одного аккаунта контент потребляют все члены семьи, а значит, если не делать такого разделения, рекомендации могут быть нерелевантны для пользователей.

Вопрос трактовки смотрения как оценки мы решили подбором специальных коэффициентов. Процесс занял довольно много времени, и полученные результаты устроили нас только относительно. К сожалению (для статистического аппарата), все пользователи разные, и как следствие у них выработаны разные привычки смотрения — а значит универсальной «палочки-выручалочки» не существует. Но пока подобранные коэффициенты нас более-менее устраивают. Дальнейшая их оптимизация возможна только в случае подбора в режиме реального времени, и имея понимание того, что происходит у конкретного пользователя.

Результаты реализации

Внедрение новой системы позволило нам вдвое увеличить показатель кликабельности подборки “рекомендованное” для пользователей – с 14% до 28%. А значит пользователи считают ее гораздо более информативной, чем другие системы рекомендаций, использованные нами до этого. Конечно, реальную эффективность рекомендаций, созданных на основе этого алгоритма, мы сможем определить только после того, как узнаем, действительно ли пользователь просмотрел контент, после того, как узнал о нем благодаря системе рекомендации. Сейчас, мы как раз занимаемся сбором данных о рекомендациях для каждого пользователя, чтобы потом сравнить их с реальными просмотрами.

Отдельного внимания заслуживает тот факт, что для пользователей, которые уже давно пользуются нашим сервисом, набор рекомендаций практически не меняется. Например у одного из наших пользователей топ-20 объектов не меняются уже более двух недель. Мы предполагаем, что это происходит потому, что пользователь не смотрит конкретно рекомендуемые объекты, так как у него большая история просмотра, потому что он редко смотрит новый контент, который бы менял его предпочтения с точки зрения алгоритма и т.д. Когда мы целиком осознали всю эту ситуацию, мы поняли, что нам необходимо собирать не только положительный, но и негативный фидбэк (который заключается в отсутствии внимания на рекомендованный объект), а также создать систему пересортировки рекомендованного контента практически в реальном времени.

Сейчас мы приняли решение проводить дополнительную сортировку рекомендованных фильмов по тому, насколько много пользователей досмотрело их до конца. По сути, мы будем «штрафовать» контент, искусственно занижать его в выдаче рекомендаций, если статистика покажет, что большинство зрителей не досмотрело его до конца. Но насколько это окажется эффективно – пока не ясно.

Мы не останавливаемся на достигнутом и продолжаем и дальше совершенствовать наши методики рекомендаций контента, фиксируя такие вещи, как регион пользователя, факты покупки того или иного контента и даже то, со страницы какого фильма он перешел на оформление подписки. Но пока все эти фичи еще на стадии разработки.

Автор: Дмитрий Мелков, .IO видеосервиса Megogo