Помочь пользователю открыть новое: как мы боролись с замкнутым кругом рекомендаций в Яндекс Лавке

Хорошая рекомендательная система быстро учится угадывать, что вы положите в корзину. И чем точнее она угадывает, тем реже показывает что‑то незнакомое: ведь выгоднее предлагать проверенное. Со временем система замыкается на привычках человека и перестаёт показывать ему хоть что‑то за их пределами.

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

Меня зовут Рамиль Боярченков, я занимаюсь машинным обучением ^[1] в команде Яндекс Лавки. Расскажу, как мы собрали механизм, который подмешивает незнакомые товары персонально — тем, кто к ним расположен, — и с какой вероятностью это делать для каждого пользователя. По пути разберу, как мы калибровали «агрессивность» exploration и что получилось в итоге.

---

Ловушка обратной связи

Пользователь приходит в Яндекс Лавку прежде всего, чтобы закрыть текущие потребности ^[2]. Его поведение ^[3] хорошо описывается историческими данными, из которых несложно выделить устойчивые паттерны покупок, любимые категории и любимые бренды. Поэтому рекомендательные системы достаточно эффективно оптимизируют краткосрочные метрики релевантности: CTR (долю кликов по выдаче), CVR (долю конверсий), GMV (суммарный оборот). ML‑модель учится предсказывать ближайшее действие пользователя и с этой узкой задачей справляется хорошо.

Основной вызов возникает из‑за того, что со временем потребности пользователя меняются. В какой‑то момент ему может понадобиться нечто принципиально новое: незнакомая категория товаров, бренд, который он раньше не смотрел. Нужные товары наверняка уже есть в каталоге, но система их не предложит, так как в исторических данных нет соответствующего сигнала. А было бы неплохо удовлетворить эту потребность, ведь если человек обнаруживает, что новый интерес ^[4] можно закрыть внутри привычного сервиса, то его отношение к продукту меняется. Это существенно повышает глубину взаимодействия и укрепляет пользовательскую лояльность.

Способность системы выводить пользователя за пределы уже известного отображается метрикой discovery. Она показывает, насколько активно пользователь открывает для себя новые типы товаров за определённый промежуток времени. Жаль только, что discovery почти никогда не достаётся бесплатно. Базовая ранжирующая модель отлично подгоняет выдачу под исторически наблюдаемое поведение ^[5], и любое вмешательство в итоговый список грозит снижением текущей релевантности. Поэтому, чтобы поднять discovery, приходится искать компромисс между краткосрочной эффективностью и долгосрочным качеством опыта ^[6].

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

Причина кроется в самом устройстве рекомендательных систем, в цикле обратной связи (feedback loop). Система сама формирует данные, на которых потом обучается следующая версия модели:

Модель → Выдача → Взаимодействие → Лог (смещённый) → Переобучение → Модель

Если модель показывает в основном узкий набор популярных и знакомых пользователю объектов, то именно по ним и накапливается новый обучающий сигнал. Следующая версия модели ещё сильнее закрепляет старые паттерны, и постепенно система сходится к локальному оптимуму. В результате она «слепнет» ко всему за пределами протоптанной дорожки и перестаёт исследовать новые области пользовательских интересов.

Эту проблему можно описать через дилемму exploration — exploitation. Exploitation выжимает максимум из уже известных предпочтений и эффективно работает в краткосрочной перспективе, но вдолгую ведёт к деградации. Exploration же — это механизм для контролируемого сбора нового обучающего сигнала там, где его сейчас нет. Exploration бьёт по мгновенным метрикам, зато улучшает качество системы в будущем.

В долгосрочной перспективе exploration решает целый ряд системных проблем:

• позволяет новые пользовательские интересы и расширяет охват каталога;

• ослабляет эффект информационного пузыря;

• повышает разнообразие выдачи (diversity);

• обогащает данные для будущего обучения;

• делает всю рекомендательную систему устойчивее.

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

Повышение discovery: основные подходы

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

Reweighting обучающих семплов

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

Новизна объекта для пользователя — это бинарный признак novelty. Он отражает, попадал объект в недавнюю историю пользователя или нет.

где  — множество объектов, с которыми пользователь взаимодействовал за последние дней.

Свежесть объекта (freshness) поддерживает новинки и затухает по мере старения товара:

где  — время с момента появления объекта в каталоге,  — гиперпараметр затухания (обе величины можно измерять, например в днях).

Неожиданность (serendipity) характеризует степень неожиданности рекомендации при сохранении её полезности. Её можно считать разными способами, мы пользуемся таким вариантом:

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

Итоговый вес семпла — взвешенная сумма компонент:

Гиперпараметры , , задают вклад каждой составляющей и подбираются под конкретный продукт и целевые метрики; при желании сюда же можно добавить другие компоненты, коррелирующие с вашими бизнес‑целями.

Reweighting позволяет корректировать выдачу в пользу более редких примеров, однако модель по‑прежнему обучается на логах, сформированных предыдущей системой. Если объект практически никогда не попадал в выдачу, достаточного обучающего сигнала по нему просто не существует, reweighting здесь не поможет.

Контрфактические методы

Проблема feedback loop тесно связана с popularity bias и exposure bias, то есть с перекосом в пользу того, что система и так часто показывает. Контрфактические методы решают эту проблему напрямую, пытаясь оценить, как повёл бы себя пользователь, покажи мы ему другие объекты.

Inverse Propensity Scoring (IPS) перевзвешивает каждое взаимодействие обратно пропорционально вероятности его наблюдения:

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

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

Семантическое расширение через LLM

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

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

Многорукие бандиты

Наконец, поговорим про подход, который работает с уже готовым ранжированным списком на этапе post‑ranking. Многорукие бандиты (Multi‑Armed Bandits) — класс алгоритмов онлайн‑обучения, придуманных специально для решения дилеммы exploration vs exploitation в условиях неопределённости.

Название происходит от аналогии с игровыми автоматами: система должна выбирать одно из нескольких действий («рук»), максимизируя суммарную награду, при этом вероятность успеха заранее неизвестна и оценивается по мере накопления данных. В рекомендательных системах «рукой» может быть группа товаров, тип exploration‑стратегии или набор холодных айтемов.

Существуют следующие основные виды таких алгоритмов:

ε‑Greedy — самый простой вариант: с вероятностью система выбирает лучший известный вариант, с вероятностью  — исследует случайный.

где  — действие, выбранное на текущем шаге ,  — параметр исследования в интервале [0, 1],  — текущая оценка ценности действия .

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

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

UCB (Upper Confidence Bound) учитывает не только ожидаемую награду, но и степень неопределённости оценки:

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

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

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

Thompson Sampling — один из самых популярных подходов в проде. Его идея в том, что вероятность успеха каждого действия моделируется случайной величиной и семплируется из апостериорного распределения. Для бинарной награды используют Beta‑распределение:

где  — число успешных взаимодействий,  — неуспешных.

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

В качестве примера действием обозначим выбор товара из органической выдачи, а действием  — выбор товара из группы холодных айтемов. Для каждого действия поддерживается оценка вероятности успеха (например, клика или покупки) в виде Beta‑распределения. Для органической выдачи это может быть , для холодных товаров — , где соответствует числу успешных взаимодействий, а — числу неуспешных. На каждом шаге случайным образом семплируются значения и из соответствующих распределений, после чего выбирается действие с максимальным значением. Если пользователь совершил целевое действие после показа товара (например, кликнул или купил), параметр α для выбранного действия увеличивается на единицу, в противном случае увеличивается .

Thompson Sampling автоматически снижает exploration по мере роста уверенности, корректно обрабатывает малое число наблюдений и хорошо масштабируется. Эмпирически он часто превосходит UCB на реальных задачах.

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

где  — вектор контекста,  — оценка параметров действия,  — матрица ковариации. Второй член играет роль UCB‑бонуса, адаптированного под конкретный контекст. По сути, контекстный бандит учится отвечать на вопрос: «Кому и в какой ситуации exploration сейчас полезнее всего и для кого он наименее рискован?» Этот вопрос и оказался для нас ключевым.

Бандит для прогрева холодных айтемов в Лавке

В Яндекс Лавке регулярно появляются новые товары без накопленного сигнала. Базовая модель, обученная на исторических логах, показывает их редко, и с каждой итерацией обучения эффект только копится: нет показов → нет сигнала → нет показов. Здесь и возникает описанный ранее цикл обратной связи.

Показывать такие товары нужно аккуратно, именно тем пользователям, которые к этому расположены. Reweighting и контрфактические методы правят обучение, но не спасают, когда сигнала нет вовсе. LLM‑аугментация несёт с собой все вышеописанные риски. Так что для нас решением стал бандит, который с некоторой индивидуально рассчитанной вероятностью подмешивает в персональную выдачу пользователя недоисследованные объекты.

Эту вероятность мы считаем через математическое ожидание Beta‑распределения с добавлением гиперпараметров:

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

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

Помимо самого алгоритма мы ввели нижнюю и верхнюю границы для вычисляемой вероятности и определили критерии, по которым товар считается недостаточно исследованным. Конкретные значения параметров мы оценили заранее, ещё до экспериментов.

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

Дальнейшее внедрение прошло в три этапа.

Эксперимент 1: подбор гиперпараметров

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

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

Эксперимент 2: накопление exploration‑сигнала

Со стабильной конфигурацией мы запустили долгий эксперимент: месяц 50% пользователей получали рекомендации с включённым exploration, остальные 50% оставались на baseline‑модели без бандита.

Мы хотели накопить качественно новый обучающий сигнал, описывающий взаимодействия с холодными товарами, реакции ^[7] на новые категории, поведенческие паттерны, которых в исторических данных не было вовсе.

За месяц пул данных в exploration‑группе заметно отличался по разнообразию в сравнении с контрольной группой. Просмотры холодных товаров выросли в 8 раз, добавления в корзину холодных товаров — в 4 раза. То есть было собрано в разы больше нового сигнала для обучения модели, чем есть в контрольной группе. Заодно ещё раз подтвердилось, что выбранные настройки бандита не дают значимой деградации бизнес‑метрик.

Эксперимент 3: переобучение и финальная проверка

На третьем шаге мы переобучили ранжирующую модель на данных из exploration‑пула.

Важный момент: новая модель училась на том же разделении пользователей (50/50), что и во втором эксперименте. Так мы исключили смешение обучающего и тестового сигналов.

Финальный A/B‑тест сравнивал старую baseline‑модель и новую, переобученную на exploration‑обогащённых данных. В итоге мы получили следующие статистически значимые результаты:

• Discovery: +0,65% — расширился каталожный охват пользователей;

• GMV: +0,6% — статистически значимый рост в финальном A/B‑тесте;

• выросло и diversity — разнообразие рекомендаций.

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

Как повторить этот опыт

Оговорюсь: сам по себе этот результат не гарантирован. Попытка сходу включить агрессивный exploration без калибровки с большой вероятностью окончилась бы деградацией метрик. Рост стал возможен благодаря аккуратной и чёткой последовательности действий: подбор гиперпараметров → сбор сигнала → переобучение.

1. Мы рекомендуем сначала проводить офлайн‑валидацию: проверять гиперпараметры на исторических данных (exploration rate, ограничения по позициям и числу холодных объектов в выдаче) и отсекать заведомо нежизнеспособные конфигурации ещё до прода.

2. Затем необходим пристрелочный онлайн‑эксперимент на 5–10% трафика: он проверяет стабильность системы, влияние на деньги и качество опыта в бою.

3. Следующий шаг — накопление exploration‑сигнала. Стоит собрать побольше данных о взаимодействиях с холодными объектами и новыми категориями, на которых в дальнейшем можно будет обучить качественную ранжирующую модель.

4. Переобучение ранжирующей модели на обогащённых данных: именно оно позволяет вывести систему за пределы старых ограничений.

5. В конце финальный A/B: сравниваем baseline и новую модель по discovery, разнообразию, GMV и удержанию.

Что в итоге

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

Мы научились платить за exploration аккуратно: подмешивать незнакомые товары тем, кто к ним расположен, и тем активнее, чем удачнее у человека складывались прошлые встречи с новинками. Накопленный сигнал мы пустили на переобучение ранжирующей модели, и вложение окупилось. Однако стоит понимать, что Multi‑Armed Bandit — это лишь инструмент. Рост метрик обеспечило его дисциплинированное применение.

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