Всем привет! Я Денис Красильников, работаю в отделе персонализации Т-Банка. Мы занимаемся всеми рекомендациями экосистемы. Это и ранжирование постов в пульсе, и построение лент кэшбэков, и даже подсказки для работников поддержки — всем занимается наш отдел, в том числе пишем научные статьи по рекомендательным системам и публикуем их на конференциях. 

Расскажу, как мы научились делать тематические подборки у себя в контентной ленте лучше профессиональных редакторов и на какие шишки наступили.

Устройство контентной ленты и подборок

Контентная лента находится в меню «Город»: 

Лента состоит из карточек, каждая карточка относится к одному из типов контента. В ленте можно забронировать ресторан, оплатить билет в кино, почитать статью в Т—Ж или купить что-то Долями. Все это примеры разного типа контента.

Мы хотим, чтобы пользователю было приятно находиться в приложении и нравилось то, что он видит в ленте, поэтому ранжируем ленту персонально под каждого клиента. Все карточки проходят модерацию. Разные карточки имеют разные наборы фич, их объединяет только, что у каждой карточки есть описание, заголовок и картинка.

Как такового user-generated-контента у нас нет, это немного упрощает задачу и не создает ситуацию, когда мы рекомендуем откровенно странные вещи.

Подборки — это набор карточек из ленты, которые сгруппированы по общим признакам и удовлетворяют трем правилам:

• имеют одинаковый тип контента;

• тематически едины;

• дополняют ленту, а не заменяют ее.

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

Новый пайплайн в Каруселях

Минусы стали ощутимо перевешивать плюсы, и в начале этого года мы решили поменять пайплайн в Каруселях. Вместо ранжирования готовых Каруселей, собранных редакторами, мы стали собирать их самостоятельно. 

Но требования к Каруселям все так же предъявляются:

• Карусель должна быть персональной — наполнение должно зависеть от действий пользователя в ленте.

• Мы не должны получать ленту в ленте, поэтому алгоритмы для наполнения ленты и для наполнения Каруселей должны отличаться. 

• Карусели должны быть тематическими — значит, это должно быть заложено в алгоритме.

• Мы должны получать uplift по бизнес-метрикам. 

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

Метрики и алгоритмы

Engagement rate — самая главная метрика для бизнеса, именно по ней принимаются все решения. Это число пользователей, которые пролистали или кликнули по Каруселям к числу пользователей, которые просто увидели Карусель.  

У нас есть побочные метрики, такие как:

• CTR — число кликов на число просмотров.

• Swipe rate — число свайпов на число просмотров.

• Глубина свайпов — как много свайпов в среднем по одной Карусельке делают пользователи. 

Вот какими алгоритмами мы можем собирать Карусели.

Попробовать эвристику — самые популярные карточки, статьи Т—Ж или истории, ближайшие концерты или самые бронированные рестораны. Можно придумать кучу таких подборок, ну и собственно ранжировать их. 

Но они все еще не будут ни персонализированными, ни самыми динамичными, и это не самое интересное решение. 

Попробовать коллаборативную фильтрацию — ALS, EASE, VAE и прочие модели. Коллаборативную фильтрацию легко обучать, pipeline решения тоже довольно простой. И в предположении, что одинаковые по темам карточки нравятся одинаковым пользователям, все должно в принципе работать. 

Ряд проблем, по которым не подходит коллаборативная фильтрация:

• Слишком динамичный контент умеет устаревать и пропадать. Поэтому проблема cold start стоит особенно остро. Вечно актуального контента у нас не так много, и данные очень разрежены. 

• Коллаборативные модели участвуют в основном пайплайне ленты, и это может привести к дублированию. 

• Нет никаких гарантий на однородность Карусели. Мы можем только верить, что это действительно так. Если одинаковые по теме карточки нравятся одинаковым по поведению пользователям.

Устройство основной ленты

Наша основная модель была устроена так:

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

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

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

Мы хотели получить примерно такой пайплайн:

Как получать вектор карточки. Процесс может выглядеть примерно так: кодируем текстовым энкодером заголовок и описание карточки, а картинку — некоторым картиночным энкодером. Получаем два вектора, которые как-нибудь потом можем склеить в один.

После небольшого числа экспериментов мы решили на первое время отказаться от картиночного энкодера и оставили только текстовый по ряду причин:

• картинки малоинформативны;

• картинки плохо кластеризуются;

• не накидывают офлайн-метрик;

• неудобно хранить;

• нужно придумать красивый способ склеить эмбединги.

Итоговый пайплайн: из карточки мы достаем ее название, описание, склеиваем их, прогоняем через BERT-like-модель, которую дообучили на наших карточках, и на выходе получаем эмбединг размерности 312.

Как получать вектор пользователя. Когда мы научились получать эмбединг карточки, нам нужно как-то научиться представлять пользователя в том же пространстве.

Самый простой вариант представить пользователя — усреднить все его клики, то есть все карточки, на которые он кликнул. Метод простой, немного шумный, но рабочий. При этом мы можем еще и добавить некоторые веса перед кликами и делать взвешенные усреднения. Например, отдавать больший вес тем карточкам, на которые пользователь дольше смотрел, или тем, на которые он недавно кликнул. Такой подход мы назвали MeanRec:

Другой подход интереснее, с использованием ML. Обучим SASRec, но с небольшими изменениями. SASRec идеально ложится на нашу задачу — угадать следующую карточку по предыдущей. Плюс это довольно стабильный и известный подход, который много раз проверен и хорошо себя зарекомендовал.

Если вдруг кто-то не знаком с архитектурой — это такой декодер блок трансформера, почти как gpt, но только в рекомендациях. Обучать будем на всех данных в ленте, чтобы получить максимально репрезентативную картину пользователя. 

Эмбеддинг карточек мы берем из текстового энкодера и фризим их, чтобы получить возможность рекомендовать прям новые карточки. Получается, что обучается у нас только сам SASRec, а эмбеддинги айтемов не меняются. 

Добавляем feedforward-слой перед тем, как добавить позиционные эмбеддинги, чтобы перегнать вектора из текстового пространства в латентное. И добавим еще один feedforward-слой на выходе для декодирования обратно.

Задача модели — по предыдущим кликам пользователя угадать следующий. Тут все стандартно: маскированный механизм внимания и кроссэнтропия как функция потерь. 

Инференс тоже довольно простой: берем последнее скрытое представление последовательности кликов пользователя в качестве юзер эмбеддинга.

Дело за малым — сравнить пользователя и карточку. Есть два распространенных подхода: 

В своем решении мы пока остановились на простом подходе и взяли косинус. 

Сборка карусели с помощью KISS

Рассмотрим игрушечный пример:

Пусть у нас есть пользователь в некотором двумерном пространстве эмбеддингов и есть кластер карточек. Самый простой вариант собрать Карусельку — жадно набрать ближайшие к пользователю карточки.

Например, соберем Карусельки размером 3: берем пользователя и ищем к нему ближайшую карточку — это какая-то карточка про кино. Затем ищем следующую ближайшую — это будет карточка про инвестиции. Ну и последняя — карточка про котика. Получилась Каруселька, но не очень тематическая — сборная солянка и, наверное, решение не самое хорошее, хоть и простое

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

Мы снова находим самую ближайшую карточку — это кино:

Но теперь мы находим ближайшие карточки не к пользователю, а к нашей опорной карточке, то есть другие киношки:

Получается такая однородная Карусель полностью из кино. Вроде все хорошо, но есть один неочевидный недостаток.

Допустим, у нас рядом с кино есть еще и билеты в театр. Согласитесь, что они немного похожи, поэтому довольно вероятно могут быть рядом. И представим, что вчера пользователь посмотрел почти все карточки про кино, а так как мы не хотим показывать их второй раз — должны выкинуть их из кандидатов. 

Если мы предыдущим алгоритмом начнем собирать Карусельку, скорее всего, первой карточкой у нас будет кино, а за ней — два театра, что немного неконсистентно.

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

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

Можно придумать много способов, но мы остановились на расстоянии до центра карусели.

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

Такой подход позволяет нам получить хорошую Карусельку — однородную и при этом в меру релевантную пользователю.

Первые результаты. Мы успели провести полностью два A/B-теста. В первом тестировали MeanRec и якорный подход против нашего старого подхода, когда ранжировали готовые Карусели.

По итогам теста мы стазначимо увеличили CTR карточек внутри каруселей на 13%, а глубину свайпов — на 10%, но engagement rate, нашу основную метрику, мы, к сожалению, не статзначимо просадили.

Мы нашли интересный инсайт в данных, из-за которого проиграли и набили все технические шишки, чтобы последующие тесты прошли гладко. 

Посмотрим на engagement rate нашей модели относительно контрольной: 

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

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

Поэтому мы запустили следующий тест — контентный SASRec. Все с тем же якорным методом, но добавили некоторое смещение по выходным в кино. И в этот раз мы опять же тестировали против ранжирования редакторских подборок. 

Самое важное изменение — это пользовательский энкодер. Теперь вместо MeanRec у нас SASRec. Второй тест тоже длился две недели, по итогам мы смогли статзначимо нарастить главную бизнесовую метрику engagement rate на 15%. 

Swipe-rate при этом вырос на 21%, а CTR — на 18%.

Выводы

Модель выиграла по всем фронтам. Но мы немного утянули внимание с основной ленты и на 4% стазначимо посадили engagement rate остальных элементов в ленте. То есть люди начали чаще кликать в Карусельку и выходить из ленты, а не просто оставаться в ней.

Но так как engagement rate остальных элементов — метрика побочная, при условии большого uplift в других метриках решили оставить модель на проде.

Теперь нам хочется научиться рекомендовать, что называется, вдолгую. И поэтому следующей моделькой мы решили попробовать offline RL модельку TD3+BC в качестве энкодера-пользователя в таком же степе обучения, как и SASRec со следующими деталями:

• Эмбеддинги айтемов у нас все также заморожены;

• State — это эмбеддинг пользователя из Content SASRec;

• Action — это рекомендация айтема; 

• Reward — это клик-не-клик по рекомендации. 

Почему T3+BC? У нас уже есть положительный опыт его применения в рекомендациях. Мы знаем, что это работает. Плюс по офлайн-метрикам мы наблюдаем прирост. Она довольно простая, поэтому решили начать с нее. 

Прямо сейчас идет третий A/B-тест, где T3+BC в тестовой группе и Content SASRec в контрольной. Пока результатов нет и борьба почти на равных. 

Даже если сейчас мы не победим статзначимо, это может говорить о том, что в будущем мы получим ту самую долгосрочную выгоду, если оставим T3+BC.