Добрый день, не хотите ли узнать больше о рекомендательных системах?

Меня зовут Владимир Байкалов (@noname_untitled). Я занимаюсь научными исследованиями в области рекомендательных систем в VK.

Ранее я работал в YouTube как MLE, над задачами теггирования видео и рекомендаций совместно с командой из DeepMind. Затем в Яндексе я углубился в сторону нейросетевой персонализации (Музыка, Маркет, Реклама и другие проекты). Там же, до перехода в VK, я успел стать тимлидом R&D команды и поучаствовать в написании ряда научных работ:

- Yambda-5B -- A Large-Scale Multi-modal Dataset for Ranking And Retrieval (RecSys'25)
- Correcting the LogQ Correction: Revisiting Sampled Softmax for Large-Scale Retrieval (RecSys’25)
- Scaling Recommender Transformers to One Billion Parameters (KDD’26)

Помимо индустриальной деятельности, я консультирую студентов по их научным работам, второй год участвую в разработке курса по рекомендательным системам в ШАД и также являюсь PC member на одной из А* конференций. В академическом треке у меня также есть работа:
- End-to-end graph-sequential representation learning for accurate recommendations (WWW'24, за первым авторством)

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

Selecting User Histories to Generate LLM Users for Cold-Start Item Recommendation (Google, DeepMind, UC Davis)

В сентябре я посетил RecSys 2025, одну из главных конференций по рекомендательным системам. Помимо участия в презентации работ от Яндекса, где я тогда работал, было интересно пообщаться с исследователями из топовых лабораторий. В частности, мне запомнился симпозиум Google/YouTube/DeepMind о перспективах и рисках направления LLM × RecSys.

На днях как раз вышла работа от части этих исследователей. Приятно видеть знакомые имена в новых статьях!)

Основная идея: решить проблему холодного старта на стадии кандидатогенерации с использованием RL и LLM.

Сама проблема довольно известная: когда новый товар появляется в системе, у него нет истории взаимодействий. Большинство CF-based моделей не могут обучить для него качественное представление из-за отсутствия данных. В итоге новые товары почти не попадают в список кандидатов, пока не накопят достаточно фидбека.

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

Вот как это работает:

Модель политики видит признаки пользователя и решает, брать ли его для аугментации или нет. Для выбранных пользователей LLM получает пользовательскую историю взаимодействий и два случайных холодных айтема. Её задача - ответить, какой из этих айтемов пользователь бы предпочёл.

После аугментации полученные пары (пользователь-айтем) объединяются с оригинальными данными и на низ обучается двухбашенная модель на задачу предсказания вероятности взаимодействия пользователя с айтемом. С помощью этой модели вычисляется recall@k по холодным айтемам, который используется как ревард для обучении ранее упомянутой политики. Для её обучения авторы используют REINFORCE алгоритм.

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

Эксперименты проводят на серии датасетов от Amazon. Что можно выделить, так это использование темпорального сплита!

По основным результатам получили прирост в ~2.5 раз (1.05% vs 2.65%) для recall@50 на холодных айтемах, но при этом общий recall@50 упал (5.55% vs 4.69%).

Из ablation:
- добавление пользовательского представления из двухбашенной модели в признаки политики значимо бустит качество (2.49% vs 3.08%)
- авторы ускоряют обучение через proxy rewards. Вместо полного переобучения двухбашенных моделей модели на каждой итерации обучения REINFORCE, они берут уже предобученную модель и только дообучают её на 3 эпохи. Этот подход даёт более стабильный сигнал для обучения политики, чем обучение модели с нуля с ранней остановкой (2.49% vs 1.65%), но все еще хуже чем с полным обучением модели с нуля (2.49% vs 2.65%)

Чего мне лично не хватило:
- сравнения по требованиям по вычислительным ресурсам с обучением на обычных данных без аугментации, насколько дороже обучение с LLM + REINFORCE?
- A/B эксперимента, интересно, как это показало бы себя в YouTube
- более детального обоснования ряда архитектурных решений: например, модель политики выглядит очень маленькой, всего один слой (!) поверх статистик

При Generative Retrieval (часть 1)

Предыстория

Весной 2024 года мне посчастливилось представлять свою научную работу на конференции TheWebConf в Сингапуре. Это была моя первая конференция, эмоции от посещения были невероятные. Помню, как возвращаясь вечером в отель после одного из дней, звонил другу и убеждал его начать заниматься исследованиями в RecSys (увы, убедить не удалось).

Из множества событий конференции сейчас хотел бы выделить туториал от Martin de Rijke и его студентов, посвященный последним достижениям в области Generative Retrieval (GR). Тогда этот туториал был не особо популярным, в аудитории набиралось 5-6 человек. Я сам тогда скептически отнесся к идее генерировать ID объектов из каталога как текст, но за прошедшее время подход заметно эволюционировал, и, если посмотреть на последние работы на arXiv, RecSys-сообщество сейчас активно работает с GR.

Этот обзор я решил разделить на две части. В этой части я хочу разобрать, зачем нужен GR и в чём он выигрывает у двухбашенного подхода.

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

Немного про двухбашенные модели (дискриминативный подход)

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

Базово такая модель устроена следующим образом: есть две независимые башни (пользовательская и айтемная). На вход первой башне идут различные признаки пользователя (часто берут N его последних взаимодействий). Айтемная башня получает на вход только признаки определенного объекта из каталога. Обе башни выдают на выход векторные представления в едином пространстве.

В проде этот подход работает по схеме "encode + retrieve". С помощью башен вы кодируете всю доступную информацию о пользователях и айтемах в вектора (шаг encode), а затем по вектору пользователя с помощью ANN находите те вектора айтемов, которые находятся к нему ближе всего (шаг retrieve). Эти объекты становятся кандидатами и проходят на следующую стадию рекомендательного пайплайна. В этом смысле двухбашенный подход является дискриминативным, так как модель не генерирует выдачу, а считает для каждого из айтемов его релевантность для данного пользователя.

Как работает генеративный подход?

В качестве альтернативы дискриминативной идее "encode + retrieve" появилась генеративная парадигма "encode + decode".

Основная идея GR в том, чтобы отказаться от подсчета релевантностей для всего каталога и обучать модель напрямую генерировать топ-k релевантных айтемов. Пользовательская башня (в этой схеме уже энкодер) остаётся без изменений, а айтемную башню заменяют на декодер, который принимает выход энкодера и генерирует последовательности кодов, соответствующие топ-k айтемам.

Осталось рассказать, как айтем переводится в последовательность для генерации. В статьях выделяют разные подходы (о них я напишу во второй части), а пока можно думать, что каждому айтему ставится в соответствие последовательность кодов (c1, c2, c3, c4), где каждый код принимает значение из фиксированного небольшого набора.

В такой схеме генерация топ-k кандидатов происходит с помощью beam search: декодер шаг за шагом предсказывает следующий код, сохраняя наиболее вероятные траектории.

(Из-за ограничение места телеграм порезал пост на две части)

(Продолжение поста выше)

Какие проблемы дискриминативного подхода старается решить генеративный?

1. Проблема полного софтмакса

Двухбашенные модели в идеале должны обучаться на задачу экстремальной классификации по всему каталогу. Однако при размере каталога больше сотен тысяч (в проде это могут быть миллиарды) вычисление softmax по нему становится слишком затратным как по памяти, так и по времени. Эту проблему решают с использованием sampled softmax подхода, который аппроксимирует градиент полного softmax'а, но требует аккуратного подхода в реализации.

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

2. Проблема холодного старта

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

GR подходит к этой проблеме иначе. Модель генерирует и выдаёт последовательность кодов, а маппинг code -> item хранится в обычном KV-хранилище. При появлении нового айтема, ему можно сразу назначить код и добавить соответствующую запись. Теперь у модели есть возможность выдавать новый айтем сразу после появления (при некоторых уточнениях).

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

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

Сейчас много занимаюсь подготовкой статьи на SIGIR'26. Если всё пройдёт гладко и статью примут, то обязательно расскажу про неё :)

А пока новость: в эту субботу (24го января) буду выступать на Data Ёлке: расскажу про итоги 2025 года в RecSys, какие направления оказались перспективными и какие знаковые статьи вышли в этом году.

Само мероприятие будет проходить как в Москве (буду выступать тут), так и в Питере. Помимо меня на мероприятии также будут и другие интересные доклады про итоги года, так что приходите послушать и пообщаться!

P.S. Регистрация будет открыта до 22 января.

Сегодня выступал с докладом про итоги года в рекомендательных системах за предыдущий год. Очень рад, что с моими 40+ слайдами получилось уложиться в тайминг и рассказать все, что планировал. На самом деле даже оказалось, что надо было подготовить дополнительные слайды еще на 2-3 минуты :)

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

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

Из того, что было уже в кулуарах, после выступления: поговорили детальнее про масштабирование моделей в условиях ограниченных данных, важность спорта в жизни и то, что надо все-таки его всеми силами встраивать в жизнь, правильное и неправильное построение семантических айдишников и про то, что "векторочек" это довольно точный и милый перевод слова "embedding" :)

Ещё раз всем спасибо за мероприятие и фидбек по докладу, было очень приятно!

P.S слайды презентации в комментариях и ссылка на запись доклада прилагаются :)

Недавно прошел дедлайн по подаче статьи на short paper track на SIGIR'26.

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

Пока я был занят этим и не только, на arXiv вышло много интересных работ из индустрии. Я еще не успел ознакомиться со всеми, но хотел бы поделиться рядом работ про нейросетевое ранжирование от LinkedIn и ByteDance вышедшими за это время.

An Industrial-Scale Sequential Recommender for LinkedIn Feed Ranking (LinkedIn)

Федор Борисюк и коллеги описывают, как они улучшили нейросетевое ранжирование в ленте новостей. Ключевая идея: явно кодировать пользователя через трансформер над его историей и подавать полученное представление на вход к DCNv2-подобному ранкеру. Этот трансформер работает над ~1000 последних событий пользователя, где на вход они подаются в формате (item, action, item, action, ...), то есть они смогли занести в ранайм трансформер примерно на 2000 событий в истории! Полученное представление позволило им избавиться от значимой части признаков, которые подавались в предыдущую продовую ранжирущую модель. Также рассказывают про опыты с LLM-ранкером: по оффлайну у них получалось хорошо, а в онлайне какого-то значимого профита поверх продовой модели не увидели. Одна из проблем: кодирование айтема текстом занимает много токенов и не позволяет использовать большую историю. Наконец, как и в ряде предыдущих работ (LiGNN, LiNR), они делятся "уроками внедрения" и инфровыми проблемами, которые им проходилось решать для того чтобы затащить эту модель в прод.

Farewell to Item IDs: Unlocking the Scaling Potential of Large Ranking Models via Semantic Tokens (ByteDance)

Обсуждают проблему масштабирования нейросетевых ранкеров. Называют основной проблемой спарсовые представления для item ID. Мысль очень похожа на статью от Meta: айтемы постоянно появляются и умирают, знания между семантически похожими не шарятся, теряем потенциальный профит. Как решение предлагают заменить разреденные "item id"-based признаки на плотные "semantic id"-based (SIDs). Показывают, что такая наивная замена просаживает качество. Решают это добавлением токенизации поверх SIDs (почти как в Google) и добавлением коллаборативного сигнала в этап построения SIDs (почти как много кто :) ).

TokenMixer-Large: Scaling Up Large Ranking Models in Industrial Recommenders (ByteDance)

Предлагают уже новую версию модели TokenMixer'а, которую улучшали в прошлой статье, TokenMixer-Large. Из основного: cделали TokenMixer слой глубже, теперь сначала токены “перемешиваются” (Mix step, раньше только он был в TokenMixer) в скрытом пространстве, а затем отдельным шагом возвращаются обратно к исходной размерности (Revert step, новый. Помимо этого добавляют еще ряд архитектурных изменений (RMSNorm, pre-norm). Эти изменения сделали архитектуру более стабильной, а sparse per-token MoE помогли сделать модель более глубокой (TokenMixer был обычно до трех слоев, сейчас больше), до 7B в runtime.

ULTRA-HSTU (Meta)

Статья про HSTU была очень вирусной: ребята показали, что можно масштабироваться в RecSys и получать от этого профит. День назад вышла статья "Bending the Scaling Law Curve in Large-Scale Recommendation Systems", где в соавторах есть часть ребят из оригинальной HSTU. В этот раз статья больше уделяет внимания не моделингу, а инженерным трюкам: хотят чтобы обучение и инференс модели работали как можно быстрее. Как итог, получают для финального сценария уменьшение FLOPs в 2 и 10 раз соответственно! Это (и не только) позволило им еще больше замасштабировать модель. Говорят, что это одна из самых больших моделей, которые были выкачены в прод в мире, но явных цифр по параметрам не приводят.

Что именно они добавили?

* Отказ от interleaved представления истории. Вместо входа в виде (item, action, item, action, ...), как это делали в HSTU, просто суммируют эмбеддинги события и действия в один.
Итог: уменьшение FLOPs на 32% и 63% на обучении и инференсе соответственно (для длины истории в 3к).

* Load-Balanced Stochastic Length (LBSL). Обычный подход Stochastic Length ускоряет обучение, обрезая историю на каждом шаге обучения случайно, но в распределенном обучении из-за этого нагрузка на воркеров может сильно разниться, добавляя простои для части из них. LBSL позволяет семплировать так, чтобы нагрузка каждого воркера была как можно ближе к какому-то определенному значению для каждого батча.
Итог: +15% пропускной способности без деградации качества.

* Semi-Local Attention. Вместо полной каузальной маски предлагают считать внимание только по локальному и глобальному окнам, учитывая текущие и долгосрочные интересы. Сложность подсчета из квадратичной становится линейной (почти).
Итог: в 2.7 и 5.1 раза улучшили их метрику training/inference scaling efficiency .

* Mixed precision. Так как HSTU-style внимание memory-bound (основные ресурсы уходят на перенос тензоров из HBM в SRAM и обратно), хотят уменьшить нагрузку на пересылки: большинство операций оставляют в BF16, а матмулы в FP8. Поверх этого добавляют фьюзинг ядер для большего ускорения. Так как обучаются и применяются они минимум на h100, используют и немного модифицируют ядра для Flash Attention v3 для своих STU-блоков.
Итог: +10% и +40% пропускной способности на обучении и применении.

* Attention Truncation. В то время как Semi-Local Attention удешевляет каждый слой, здесь они удешевляют глубину: сначала делаем N слоёв по всей последовательности полученной уже с использованием Semi-Local Attention, затем выбираем сегмент длины L' из этой истории (предлагают брать самые свежие события). После добавляют ещё M слоёв, но уже только по этому последнему сегменту.
Итог: в 1.5 раз меньше FLOPs в схеме (3 + 6 слоев) относительно HSTU с 6 слоями на инференсе.

Какие результаты?

* В прод завезли модель с 18 STU слоями , длина истории 16к, embedding dim 512 (скорее всего), репортят что обучали модель на сотнях GPU, но из секции про LBSL мне кажется, что их суммарно было 512.

* По метрикам получили +4% consumption и +2-8% engagement, говорят, что "single-digit" прирост это уже большой прорыв.

* Еще показали, что при росте глубины cross-attention довольно быстро насыщается, a self-attention продолжает улучшаться при добавлении слоёв.