Как работают рекомендации контента в поисковой выдаче
Кажется, еще недавно форумы пестрели просьбами посоветовать фильм, «чтоб все было как в Терминаторе», или найти новую музыку, «чтоб качало как Limp Bizkit». Но с тех пор большинство цифровых поставщиков контента и сами поисковики обзавелись собственными сервисами рекомендаций. И теперь знают ваши вкусы гораздо лучше форумных советчиков. N + 1 и Яндекс рассказывают, как это работает и через какие трудности нужно пройти создателям, чтобы рекомендации вас заинтересовали.
Проблема подбора рекомендаций появилась гораздо раньше, чем стриминговые платформы или онлайн-сервисы с музыкой. Netflix, к примеру, до того, как проник во все SmartTV и стал производить собственный контент, занимался арендой фильмов на DVD по почте. Уже тогда им было важно предугадывать оценку пользователя, чтоб иметь возможность качественно советовать новые фильмы. Для этого в 2006 году был объявлен конкурс Netflix Prize, предоставивший участникам невиданный по тем временам датасет с сотней миллионов оценок. Невиданным был и приз в миллион долларов. Целью конкурса было предсказать оценки пользователей по метрике RMSE на 10 процентов лучше, чем Cinematch — тогдашняя рекомендательная система Netflix.
В 2009 году конкурс завершился. Лучшим оказался результат RMSE = 0.8567, который получили сразу две команды. Но ни один алгоритм-победитель, если верить сообщениям с профильных конференций, так и не оказался в продакшне.
В Яндексе над рекомендациями начали работать в 2013 году. Тогда они разрабатывались для Яндекс.Музыки и Яндекс.Маркета. Чуть позже наработки по рекомендациям для Музыки стали использовать для Дзена. В то время каждое направление Яндекса имело свой подход к рекомендациям и временами приходилось выполнять ощутимое количество работы, чтоб использовать данные одного сервиса для создания рекомендаций в другом.
Как работают рекомендации в поисковой выдаче и с каким сложностями сталкиваются при их разработке, хорошо видно на примере задачи подбора фильмов. Первая проблема, с которой можно столкнуться, — необходимость подружить балльную шкалу рейтинга и процентную шкалу персонального рейтинга, который является мнением алгоритмов Яндекса о том, насколько именно вам подойдет этот фильм.
На первый взгляд кажется, что 8/10 эквивалентно 80 процентам. Но, с точки зрения пользовательских ощущений, это не так. Помочь адекватно связать эти две оценки Яндексу помог труд толокеров — пользователей Яндекс.Толоки. Это позволило построить функцию, которая отображает зависимость между балльными и процентными оценками, сохраняя ожидания пользователей.
Возникает вопрос: «А как теперь научить модель подсказывать пользователю фильмы?» Метрика RMSE здесь уже не годится, поскольку штраф за предсказывание оценки 9 вместо 10 такой же, как за 1 вместо 2. А ведь модель ни в коем случае не должна показывать пользователю фильмы, которым он поставит кол. Чтоб справиться с этой задачей, необходимо использовать метрики на основе списка, например NDCG, которая широко используется в задачах ранжирования.
Итак, получена метрика, дающая оценку качеству ранжирования. Следующая задача приходит на ум не сразу. Зачастую пользователи ставят наивысшие оценки не тем фильмам, которые смотрят каждый день. Часто оценку 10 получают признанные шедевры из мировых топов. Если составить рекомендательную ленту исключительно из них, пользователь оценит ее качество, но вряд ли станет что-то из нее смотреть, если у него нет подходящего настроения.
Можно сместить задачу в сторону предсказывания просмотра пользователем предложенного фильма. В таком случае, если в предложенном списке не окажется выдающихся лент, зритель может перестать доверять вкусу цифрового советчика. В Яндексе эту проблему решили с помощью ранжирования под метрику доли успешных рекомендательных сессий. Рекомендательная сессия начинается с запроса, для которого был показан рекомендательный список. Она считается успешной, если по ее итогам пользователь посмотрел фильм из списка и остался им доволен.
Все объекты в системе представляются в виде профилей. Это относится и к контенту, например фильмам или статьям на Дзене, и к их тегам, и к пользователям. В профилях хранятся счетчики и эмбеддинги — векторы в некотором пространстве. Поскольку время отклика сервиса должно быть менее 100 миллисекунд, Яндекс часть тяжелых операций выполняет в оффлайне, на этапе подготовки данных. Профили фильмов, к примеру, каждый день готовятся на YT (читается «Ыть») — основной платформе Яндекса для хранения и обработки больших данных. И оттуда уже загружаются в оперативную память машин, отвечающих на запросы.
Сами профили состоят из двух частей:
Таким образом, в любой момент профиль состоит из статичной и двух динамических частей, которые склеиваются вместе в момент запроса на рекомендации. Рассмотрим на примере музыки, как в рекомендациях обновляется профиль пользователя при прослушивании нового трека.
Обновление пользовательского профиля:
Но мы так и не ответили на вопрос, как подбираются для пользователя рекомендации. Для этого используется Recommender DSSM — нейросеть из двух башен. Ее цель — определить близость объекта, будь то фильм, песня или статья, к пользователю. Башня строит эмбеддинг объекта на основе данных о нем. Для фильма это, среди прочего, год выхода, страна выпуска, жанр, актеры. Для построения эмбеддинга пользователя агрегируется история просмотренных им объектов с затухающим по времени влиянием. Но если брать всю историю сразу, это серьезно замедлит работу нейросети, поэтому обработка профиля пользователя идет в два этапа.
Сначала строится более простой InnerDSSM. Берется какое-то количество последних действий пользователя без разделения на типы: лайки, просмотры, оценки, etc. Затем полученный InnerDSSM переобучается на всей истории пользователя, но уже с разбиением действий на типы. Так получают OuterDSSM, с которыми работают дальше. Между полученными эмбеддингами считается косинусное расстояние, которое и определяет близость объекта юзеру. Тот же принцип работает, кстати, и в поиске. Только вместо эмбеддинга пользователя в нем участвует эмбеддинг запроса.
С помощью Recommender DSSM получают несколько сотен кандидатов. К ним с помощью других генераторов прибавляются несколько сотен самых популярных объектов в любимых жанрах пользователя, а также объекты, похожие на те, которые пользователь хорошо оценил. Но теперь их необходимо отранжировать.
При сортировке объектов учитывается множество различных факторов — это и время суток, и частота использования сервиса пользователем, и число взаимодействий юзера с разными категориями сервиса. Для того, чтоб отранжировать полученных кандидатов, в Яндексе применяют CatBoost — собственную библиотеку градиентного бустинга. С ее помощью каждому объекту присваивается определенное значение релевантности. Казалось бы, дальше можно просто отсортировать какое-то количество лучших объектов по этому показателю. Но список может получиться слишком однородным, как было написано выше на примере кино. Как и чем его разбавить, зависит уже от конкретного сервиса.
Градиентный бустинг — это техника машинного обучения для задач классификации и регрессии, которая строит модель предсказания в форме ансамбля слабых предсказывающих моделей.
Сейчас пользовательские профили внутри сервисов Яндекса строятся по единому принципу. Больше нет необходимости подстраивать всю систему к чужому набору профилей, если хочется использовать внешние пользовательские предпочтения в своем сервисе. Эта платформа была была запущена в 2018 году и получила название DJ.
В большей или меньшей степени DJ используется в следующих сервисах:
Может показаться, что это открывает новую эпоху в создании рекомендаций. Ведь можно подсказывать пользователю фильмы и статьи, опираясь на его предпочтения в музыке. Однако, как говорят специалисты Яндекса, первые действия пользователя в новом сервисе дают гораздо больше полезной информации, чем его предпочтения в других областях. Но в скором времени в Яндексе собираются ввести единый профиль пользователя, отражающий его историю во всей экосистеме.
В планах Яндекса использовать для подбора контента систему «трансформеров», которая себя зарекомендовала во многих сервисах: в поиске, переводчике и других. С ее помощью можно различать контекст во взаимодействиях пользователя внутри сервисов, а не использовать их в совокупности, что сейчас происходит в традиционных моделях. Условно говоря, рассматривая релевантность некоторого объекта, модель будет смотреть, насколько он соответствует не всему вектору пользователя, а отдельным контекстам его интересов.
Сейчас рекомендательные системы используют краткосрочные метрики и строятся на машинном обучении с учителем. Если пользователь принял предложенный объект: посмотрел, полайкал, поделился — это хороший пример. Если нет — плохой. В скором времени системы рекомендации будут уходить в сторону reinforcement learning — самостоятельного машинного обучения, в котором алгоритм будет отслеживать, как влияют его рекомендации на интерес пользователя к сервису: чаще ли он заходит и взаимодействует с ним.
В более далекой перспективе рекомендации в поиске и сопутствующих сервисах будут чаще общаться с нами в диалоговой форме, уточнять наши интересы. Возможно, это будет происходить при помощи Алисы. И хотя не все изменения в системе рекомендаций будут видны невооруженному глазу, в будущем обращаться к людям за советом, что посмотреть-послушать, вы будете гораздо реже.