Главная задача рекомендательной системы — предоставить пользователю контент, фильм, трек, книгу, товар или информацию, которые могут заинтересовать его в данный момент. Сложность в том, что у нас нет явного запроса пользователя, как в поиске, есть только история его взаимодействий с объектами и наша надежда на то, что мы верно распознали его скрытые желания.

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

Меня зовут Кирилл Хрыльченко, я руковожу командой R&D рекомендательных технологий в Яндексе. Наша команда исследует и разрабатывает новые технологии, а также активно следит за тем, что нового появляется в индустрии. Сегодня я поделюсь трендами развития рекомендательных систем и расскажу, как нейросети продолжают улучшать качество рекомендаций: какие есть нюансы в работе с LLM, чем полезно обучение с подкреплением, что изменилось в плане анализа истории пользователя, а также на что обратить внимание при масштабировании.

Тренд 1. Большие языковые модели

Сейчас у рекомендательных систем есть несколько минусов:

• у них нет знаний о внешнем мире;

• холодный старт: им нужен фидбэк, чтобы адаптироваться к новым пользователям и объектам (иначе их называют items или айтемы);

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

Кроме того, рекомендации всё больше превращаются в black box. Становится всё сложнее понимать, почему рекомендуется именно то, что рекомендуется, как‑то объяснять рекомендации.

Решение этих проблем — большие языковые модели (LLM). У них есть знание внешнего мира (world knowledge), они хорошо работают zero‑shot (при отсутствии фидбэка для заданных пользователей и айтемов), могут рассуждать (reasoning) и генерировать объяснения рекомендаций. А ещё языковые модели интерактивны: у пользователей есть возможность доуточнять свои потребности, вносить какую‑то дополнительную персонализацию в рекомендации.

Самая простая схема рекомендаций с помощью LLM может выглядеть вот так:

Следующий логический шаг — сделать персонализацию, добавив в запрос историю пользователя в виде текста: «Что бы ты порекомендовал пользователю с такой историей: фильм-1, фильм-2…?»

Так как мы хотим обрабатывать очень большую пользовательскую историю — до десятков тысяч событий, — то такой «текстовый» подход (когда мы представляем историю пользователя в виде сплошного текста) приводит к очень большому количеству токенов на входе в языковую модель. Чтобы убрать это узкое место, сейчас тестируется множество подходов, где LLM напрямую взаимодействует с обучаемыми эмбеддингами айтемов, а также принимает на вход эмбеддинг пользователя из какой‑нибудь другой, более классической рекомендательной модели.

Эмбеддинг — это представление объекта в виде числового вектора. С помощью векторов можно делать классификацию, генерацию и решать другие задачи. В случае LLM, трансформер принимает на вход множество эмбеддингов, но обычно они несут в себе информацию вроде «что это за кусочек слова на естественном языке и на какой позиции он находится». В случае рекомендаций нам нужно кодировать не только текст на естественном языке, но и пользователей с айтемами.

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

1. Извлечение признаков. Например, суммаризация интересов пользователя или короткое описание свойств айтема в виде текста.

2. Векторизация. LLM, как и любые трансформеры, производит векторы. С помощью них можно напрямую кодировать входные объекты в векторы, а затем переиспользовать их в других моделях.

3. Генерация кандидатов. Можно попросить LLM сразу сгенерировать какой‑то список кандидатов. Но здесь есть сложности, потому что LLM может придумать какие‑то несуществующие айтемы, которых в доступном нам каталоге нет. Тогда нужно научиться как‑то отображать сгенерированные сущности на те, которые нам доступны.

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

Несмотря на все плюсы и возможные сценарии использования, LLM всё ещё не стали основной технологией в рекомендательных системах. И вот список проблем, для которых всё ещё ищутся решения:

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

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

3. LLM галлюцинируют. Нет никакой гарантии, что LLM предлагает что‑то разумное. В том числе и объяснения для рекомендаций могут быть очень плохие и неправильные.

4. Смещения (biases). LLM, как и все модели машинного обучения, учатся на данных. У более простых моделей довольно сильные ограничения (индуктивные смещения, inductive biases), которые не дают моделям делать что‑то плохое. А LLM — это очень сложные и большие модели, которые могут запомнить всё плохое, что есть в данных. При этом из них это очень сложно убрать.

5. Сложное дообучение. В рексистемах всё постоянно меняется: тренды эволюционируют, у пользователей появляются новые интересы. Важно, чтобы модели быстро адаптировались к новой информации. Для этого обычно применяется дообучение — процесс, когда приходит свежий фидбэк от пользователей и текущая работающая в сервисе модель дообучается на нём. А с LLM это сложно сделать: сейчас их, как правило, обучают единоразово, затем дообучают (alignment) и фиксируют.

6. LLM нестабильны. Даже перестановка слов в промте (вместо «порекомендуй айтемы» — «айтемы порекомендуй») может изменить рекомендации.

Уверен, что в обозримом будущем все эти проблемы решат. Сейчас появляются интересные наработки, например статья от Google Research Demystifying Embedding Spaces using Large Language Models, в которой описаны попытки интерпретировать векторные пространства айтемов и пользователей с помощью LLM. То есть буквально учат LLM выдавать текстовое описание айтемов и пользователей по их вектору. И это работает!

Тренд 2. Нейросетевое ранжирование

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

Обычно для ранжирования используются алгоритмы типа градиентного бустинга, но в последнее время существует чёткий тренд на использование нейросетей для ранжирования. На вход ранжирующие модели принимают информацию про пользователей, айтемы и их взаимодействие в виде категориальных и вещественных признаков. Сначала признаки кодируются в эмбеддинги (можно также взять эмбеддинги из каких‑то других моделей), а затем все эмбеддинги конкатенируются и подаются в нейросетевые блоки. Например, на схеме есть две группы слоёв: DCN и MLP.

В другом своём докладе я подробно рассказывал о преимуществах нейросетей над градиентным бустингом, а сейчас постараюсь кратко привести основные тезисы:

1. Явное и неявное моделирование взаимодействия признаков. В нейросетевых моделях есть специальные слои, которые хорошо справляются с моделированием как явных взаимодействий между признаками (например, DCN‑v2), так и неявных (через обычные MLP). Под явными взаимодействиями понимается моделирование кросс‑фич, полиномов и т. д.

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

3. Переиспользование эмбеддингов из других моделей. В нейросети можно вставлять напрямую эмбеддинги из других моделей, а также учить какие‑то нейросетевые модели end‑to‑end.

4. End‑to‑end‑анализ последовательностей. Например, трансформеры, которые работают над историей пользователя, обычно обучают отдельно на ранжирующие лоссы, а можно обучать их end‑to‑end с upstream‑ранжированием, чтобы это было максимально полезно для всего стека ранжирования.

5. Knowledge transfer и экономия ресурсов с помощью многозадачности. За счёт «многоголовой» архитектуры мы решаем сразу несколько задач, что экономит ресурсы.

6. Масштабирование по данным за счёт большой ёмкости модели. Аргумент немножко искусственный, но всё‑таки следующее слово в LLM мы предсказываем не градиентным бустингом.

Что ещё предстоит сделать в этом направлении:

• Перейти к трансформерам. Пока они не очень хорошо работают с ранжированием над признаками.

• Улучшить моделирование взаимодействия признаков и анализ последовательности.

• Масштабировать системы. Об этом мы поговорим прямо сейчас — в следующем тренде :)

Тренд 3. Масштабирование

Трансформеры хорошо масштабируются в NLP (Natural Language Processing) и CV (Computer Vision). Об этом можно почитать, например, в статьях Scaling Laws for Neural Language Models и Scaling Vision Transformers to 22 Billion Parameters.

Есть такой термин — compute. Это общее количество вычислений, которое нам нужно произвести, чтобы обучить (или применить) модель. Чтобы его рассчитать, нужно умножить количество флопсов, которые происходят в модели при обучении или инференсе, на количество данных обучения. Модели в NLP очень хорошо скейлятся по этому самому compute.

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

Аналогично и в случае анализа последовательностей исторических событий пользователей: трансформеры, которые там применяют, зачастую состоят из одного‑двух слоёв, и длина контекста (истории пользователя) небольшая.

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

Например, у Meta* есть удачные эксперименты. Они убрали из модели вещественные признаки и представили пользователя в виде последовательности, а ещё модифицировали трансформер, выкинув из него софтмакс и FFN. Оказалось, что софтмакс в Attention мешает выучивать интенсивность чего‑либо с точки зрения истории: как часто пользователь слушал определённый жанр или артиста и т. д. Ещё их новая архитектура гораздо быстрее, чем трансформер, и видеопамяти требует меньше. По результатам экспериментов получился хороший скейлинг для compute относительно количества данных для обучения.

Тренд 4. Анализ последовательности

Анализ истории пользователя в виде последовательности событий — это важная область моделирования для рексистем. Вот как это работало раньше:

• Next Item Prediction для предсказания следующего события. Здесь явно вдохновлялись обработкой естественного языка: представили пользователя в виде последовательности токенов, где каждый токен кодирует информацию про айтем. А затем научили модель предсказывать следующий токен, то есть айтем. Используются при этом всё те же популярные в NLP трансформеры. Яркие примеры — это модели SASRec и BERT4Rec. Вторая вместо предсказания следующего токена использует задачу MLM аналогично исходной модели BERT.

• Методы крупных компаний. Ещё до бума трансформеров в NLP в рексистемах обрабатывали историю пользователя в виде последовательности. В далёком 2016 году в культовой статье YouTubeDNN историю пользователя сворачивали в единый вектор простым усреднением векторов исторических событий. Чуть позже у Alibaba в ранжирующей модели появился модуль, который применял Attention над историей и кандидатом‑айтемом. Позже они тоже перешли к трансформерам для обработки истории.

Давайте посмотрим, что происходит в индустрии сейчас:

• Переход от Next Item Prediction к более сложным постановкам обучения. Например, PinnerFormer, когда вместо предсказания следующего события предсказывают что‑то из более далёкого будущего, так как хотят учитывать долгосрочные сигналы из истории пользователя.

• Более индуктивные и мультимодальные модели, в которых используют не только уникальный идентификатор айтема, но и его контент: например, текстовый и визуальный сигнал.

• Более длинные истории пользователей, lifelong‑рекомендации. Раньше в истории пользователей было 20–50 событий, сейчас может быть и 8000.

• Time awareness — учёт сигнала, связанного со временем, с помощью таймстемпов (поскольку между событиями в истории пользователя разные временные промежутки).

• Разделение на real‑time‑модели с минимальной задержкой для небольших, но свежих историй пользователя и на офлайн‑модели. Бывает, что отдельно выделяют near‑real‑time‑модели.

Тренд 5. Графовые нейросети

Если взять все данные, которые порождает какой‑нибудь большой сервис, то получится граф. Например, посмотрим на Яндекс Маркет. В таком графе будут вершины для пользователей, айтемов, поисковых запросов. Что‑то похожее есть и у других сервисов: примерно везде есть поиск, главная страница, рекомендации похожих товаров. И все эти рекомендательные «поверхности» порождают данные в графе.

В больших экосистемах типа Яндекса есть ещё и кросс‑доменная информация из других сервисов. А ещё в графе могут быть гиперрёбра, на которых больше двух вершин, например корзины пользователей, состоящие из более чем двух товаров. Также в граф можно внести семантическую информацию: таксономию из дерева категорий, любую дополнительную информацию про товары или другие айтемы.

В результате получаем очень большой всеобъемлющий граф:

Цель рекомендательной системы — что‑то показать пользователю, порекомендовать. Обычно для этого используется совсем небольшой кусочек нашего графа — двудольный граф между пользователями и айтемами (user‑item‑граф). Поверх него обучается что‑нибудь типа матричной факторизации или какой‑нибудь другой коллаборативный алгоритм. Трансформерная персонализация тоже в основном использует только информацию из этого двудольного графа.

А ведь на самом деле остаётся ещё очень много полезной информации про пользователей и айтемы. Например, для трансформера над историей пользователя можно также взять поисковые запросы и какие‑то кросс‑доменные события. И остальную часть графа точно можно использовать для других целей. Для этого применяют специальные нейросети, которые обычно называют графовыми нейросетями.

Есть два основных подхода к построению графовых нейросетей для рексистем:

• Индуктивный. Методы типа GraphSAGE, PinSage. Чтобы получить хорошее векторное представление вершины, используем её контент (текстовое и визуальное описание), а также её соседей в графе. Тот же трансформер над пользователем можно считать примером индуктивной графовой нейросети.

• Трансдуктивный, или Representation Learning. Цель та же самая — получить хорошее векторное представление. Но здесь мы не пытаемся закодировать вершину через контент или соседей напрямую, а заводим для каждой вершины свой обучаемый эмбеддинг. Затем учим всю структуру на какую‑то графовую задачу обучения, например link prediction — предсказание рёбер в графе. Примером такой архитектуры является модель TwHIN от Twitter.

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

Тренд 6. Обучение с подкреплением, или RL

Можно выделить три довольно разные области, которые имеют отношение к обучению с подкреплением.

Feedback Loop. Любая рекомендательная система несовершенна, и данные, которые она порождает, только усиливают эти несовершенства. Получается, что при дообучении рексистемы очень высок риск деградации. Например, popularity bias: рекомендательные системы обычно любят рекомендовать популярные айтемы, а затем при дообучении они снова видят очень много фидбэка для этих айтемов и начинают их рекомендовать ещё чаще (Matthew effect, или «Богатый становится богаче»). От этого страдают более нишевые айтемы, а также свежий контент.

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

Долгосрочные цели. Обычно рекомендательные системы не заглядывают слишком далеко и пытаются показать что‑то, что вызовет положительную реакцию уже сейчас: клик пользователя, лайк, просмотр. Но чего мы на самом деле хотим, так это того, чтобы пользователь оставался в сервисе на долгой дистанции, продолжал подписываться, пользоваться сервисом. Чтобы был высокий ретеншн. И до сих пор есть большая надежда, что как раз здесь должно помогать RL, что оно сможет как‑то балансировать между собой краткосрочный эффект с долгосрочным и, возможно, добавлять в рекомендации больше разнообразия, делать их менее «эхо‑камерными».

Но пока что это не очень хорошо работает. Прежде всего, от других областей, использующих RL, нас отделяют масштабы: у нас очень большое дискретное пространство действий. Для нас действие — это рекомендация конкретного айтема. Айтемов очень много (вплоть до миллиардов), а ещё мы обычно показываем не один айтем, а сразу несколько, то есть сложность растёт комбинаторно.

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

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

Уникальные задачи. Есть и третья подобласть применения RL в рексистемах — это всё, что в первые две области не входит:)

Например, если у нас есть многостадийная рекомендательная система, то в ней обязательно возникает Selection Bias: те данные, на которых мы учим ранжирующую модель, уже куда‑то смещены. Если наш кандидатогенератор обладает какими‑то недостатками, то он будет терять часть хороших айтемов из исходного каталога, они не будут доходить до ранжирования. В идеале мы бы хотели учить модель на всех объектах, а не только на тех, которые хороши по мнению кандидатогенератора. С точки зрения RL это мультиагентная система, в которой два агента — кандидатогенерация и ранжирование — работают над общей целью. На эту тему есть интересные статьи.

Ещё с помощью RL можно делать рекомендательные алгоритмы более парето‑оптимальными, решать задачу переранжирования, тюнить гиперпараметры, даже шардировать матрицы эмбеддингов.

На самом деле, это далеко не все тренды, которые существуют в рексистемах на данный момент. Но конкретно эти — одни из самых активно развиваемых. На эти темы выходит много статей, идёт много работы в индустрии.

Надеюсь, после этого обзора и вам захочется попробовать что‑то из этих трендов в своих проектах!

*Компания Meta признана экстремистской организацией, а её продукты, Facebook и Instagram, запрещены на территории РФ.