GenRec: A Preference-Oriented Generative Framework for Large-Scale Recommendation
Разбираем статью от команды JD App — крупного китайского маркетплейса. Работа небольшая, но в ней есть несколько интересных идей на тему генеративных рекомендаций.
Обычный Next Item Prediction плохо соответствует тому, как пользователь в действительности взаимодействует со страницей. Юзер видит набор товаров, кликает, покупает, скроллит — и порядок этих действий не всегда отражает реальные намерения. Также есть проблемы логирования: события могут записываться не в том порядке, в котором пользователь их совершал.
Авторы предлагают перейти от Next Item Prediction к Page-Wise Next Token Prediction. Вместо того чтобы обучаться на отдельных действиях, модель рассматривает сразу всю страницу и все действия пользователя на ней. Действия сортируются по важности: покупки, клики, показы. Дальше модель делает один forward pass и суммирует лог-пробы всех действий. За счёт этого сигнал становится плотнее, а проблема неконсистентности между действиями и их логированием уменьшается.
Вторая часть работы посвящена сжатию длинных последовательностей. Каждый айтем представляют тремя семантическими id, поэтому без сжатия вычислительные затраты значительны. Чтобы сократить длину последовательности, используют Token Merger: конкатенируют три семантических токена и пропускают через линейную проекцию, получая один токен вместо трёх. Между семантиками одного айтема остаются разделительные токены, поэтому последовательность уменьшается не в три, а в два раза без сильной просадки качества.
Сами семантики получают через мультимодальный Qwen2.5-VL, добавляют коллаборативный сигнал и затем применяют residual quantization с K-means, получая три кодбука семантических токенов.
Третья часть — алайнмент через модификацию GRPO. Авторы используют preference model, которая оценивает айтемы из роллаутов и выдаёт реворд. Это нужно потому, что реальные пользовательские сигналы вроде кликов слишком спарсовые. Но при этом preference model может давать высокие скоры нерелевантным айтемам, поэтому добавляют gating-механизм, который зануляет реворд для нерелевантных пользователю рекомендаций.
Если пользователь действительно кликал или покупал айтемы из роллаута, его реворд дополнительно повышается — таким объектам назначают максимальный скор внутри группы. Дальше эти реворды используют в обычной формуле GRPO для подсчёта advantage. Вместо KL-регуляризации используют NLL-регуляризацию.
Основной прирост качества даёт именно Page-Wise-NTP. Когда сравнивают с LC-Rec на одинаковом backbone (Qwen2.5-3B) метрики выше. Token merger немного ухудшает качество, что логично — часть информации теряется при сжатии семантик.
Интересный момент при скейлинге. При переходе от 1,5B к 3B качество сильно выросло, а дальше — почти нет. Авторы связывают это с тем, что для генеративных рекомендаций важнее глубина модели, чем увеличение hidden size.
В онлайне получились большие приросты: около +9,5% по кликам и +8,7% по транзакциям. В аблейшнах видно, что основной вклад в RL-части даёт gating-механизм: без него reward alignment работает заметно хуже и больше галлюцинаций с невалидными айтемами.
@RecSysChannel
Разбор подготовила❣ Вероника Иванова
Разбираем статью от команды JD App — крупного китайского маркетплейса. Работа небольшая, но в ней есть несколько интересных идей на тему генеративных рекомендаций.
Обычный Next Item Prediction плохо соответствует тому, как пользователь в действительности взаимодействует со страницей. Юзер видит набор товаров, кликает, покупает, скроллит — и порядок этих действий не всегда отражает реальные намерения. Также есть проблемы логирования: события могут записываться не в том порядке, в котором пользователь их совершал.
Авторы предлагают перейти от Next Item Prediction к Page-Wise Next Token Prediction. Вместо того чтобы обучаться на отдельных действиях, модель рассматривает сразу всю страницу и все действия пользователя на ней. Действия сортируются по важности: покупки, клики, показы. Дальше модель делает один forward pass и суммирует лог-пробы всех действий. За счёт этого сигнал становится плотнее, а проблема неконсистентности между действиями и их логированием уменьшается.
Вторая часть работы посвящена сжатию длинных последовательностей. Каждый айтем представляют тремя семантическими id, поэтому без сжатия вычислительные затраты значительны. Чтобы сократить длину последовательности, используют Token Merger: конкатенируют три семантических токена и пропускают через линейную проекцию, получая один токен вместо трёх. Между семантиками одного айтема остаются разделительные токены, поэтому последовательность уменьшается не в три, а в два раза без сильной просадки качества.
Сами семантики получают через мультимодальный Qwen2.5-VL, добавляют коллаборативный сигнал и затем применяют residual quantization с K-means, получая три кодбука семантических токенов.
Третья часть — алайнмент через модификацию GRPO. Авторы используют preference model, которая оценивает айтемы из роллаутов и выдаёт реворд. Это нужно потому, что реальные пользовательские сигналы вроде кликов слишком спарсовые. Но при этом preference model может давать высокие скоры нерелевантным айтемам, поэтому добавляют gating-механизм, который зануляет реворд для нерелевантных пользователю рекомендаций.
Если пользователь действительно кликал или покупал айтемы из роллаута, его реворд дополнительно повышается — таким объектам назначают максимальный скор внутри группы. Дальше эти реворды используют в обычной формуле GRPO для подсчёта advantage. Вместо KL-регуляризации используют NLL-регуляризацию.
Основной прирост качества даёт именно Page-Wise-NTP. Когда сравнивают с LC-Rec на одинаковом backbone (Qwen2.5-3B) метрики выше. Token merger немного ухудшает качество, что логично — часть информации теряется при сжатии семантик.
Интересный момент при скейлинге. При переходе от 1,5B к 3B качество сильно выросло, а дальше — почти нет. Авторы связывают это с тем, что для генеративных рекомендаций важнее глубина модели, чем увеличение hidden size.
В онлайне получились большие приросты: около +9,5% по кликам и +8,7% по транзакциям. В аблейшнах видно, что основной вклад в RL-части даёт gating-механизм: без него reward alignment работает заметно хуже и больше галлюцинаций с невалидными айтемами.
@RecSysChannel
Разбор подготовила
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍7🔥5🥰1
Gryphon: A Unified Architecture for Semantic-ID Generation and Item-Level Scoring in Industrial Recommendations
Разбираем статью о гибридной генеративно-ранжирующей модели в рекомендациях Яндекс Музыки. О ней на Data Fest рассказала Дарья Тихонович, руководитель Яндекс RND-команды, которая разрабатывает новые рекомендательные технологии.
Генеративные рекомендации на базе Semantic IDs позволяют применять подход next token prediction к огромным каталогам, где невозможно напрямую выбирать следующий объект из миллионов вариантов. Вместо того чтобы предсказывать конкретный трек сразу, модель генерирует его поэтапно через последовательность семантических токенов. Например, сначала определяет жанр (русский рок), затем исполнителя («Сплин»), а потом конкретную композицию («Летучий Голландец»).
Такие токены получают с помощью иерархической кластеризации контентных эмбеддингов объектов, где каждый уровень уточняет описание айтема. В результате каждый объект представлен компактным Semantic ID, а генеративная модель (например, TIGER от Google) предсказывает не сам объект, а последовательность его семантических токенов, благодаря чему возможно обучение и использование рексистем на многомиллионных каталогах.
Но у генеративных рекомендательных моделей есть ряд проблем:
🔴 Коллизии Semantic IDs — разные айтемы могут получать одинаковые семантические идентификаторы, из-за чего модель не различает их.
🔴 Слой разрешения коллизий не масштабируется — работает офлайн, но не подходит для динамического каталога, который постоянно пополняется.
🔴 Без разрешения коллизий падает качество — при удалении этого слоя качество может снижаться в разы.
🔴 Нужно расширять пространство токенов — для лучшей уникализации нужны более крупные кодбуки и больше семантических токенов.
🔴 Копятся ошибки генерации — ошибка в раннем токене ведёт к неверной оценке всей траектории.
🔴 Потолок качества при длинных Semantic ID — увеличение числа токенов увеличивает уникализацию, но перестаёт улучшать качество рекомендаций.
Gryphon: генерация + ранжирование в одной модели
Gryphon — гибридная архитектура, которая объединяет генерацию кандидатов и их ранжирование. В основе encoder-decoder: по истории пользователя модель через beam search генерирует набор Semantic IDs. Чтобы избежать накопления ошибок при генерации (Semantic Drift), в beam search используется PRM (Process Reward Model), которая оценивает траектории генерации и помогает выбирать только релевантные пути для продолжения.
После генерации все Semantic IDs отображаются в общем пуле айтемов-кандидатов, релевантность которых оценивается через ORM (Output Reward Model). В результате, генеративная часть отвечает за кандидатогенерацию на уровне Semantic ID, а ORM — за финальное ранжирование айтемов. PRM и ORM — это легковесные модули на основе cross-attention, которые переиспользуют выходы энкодера генеративной модели, и поэтому лишь незначительно растят общее количество параметров и стоимость инференса.
При обучении ORM на задачу next-item-prediction в офлайне Gryphon показал +20% прироста Recal@1000 относительно Argus. Более того, модель опередила по качеству полный softmax по каталогу Яндекс Музыки.
В A/B-тестах Gryphon полностью заменил стек кандидатогенерации и преранжирования Яндекс.Музыки (15+ моделей), сократив число кандидатов для финального ранкера с 3000 до 1000 без потери качества. В сравнении с генеративным бейзлайном модель дала +3,6% команд Like, сохранила продуктовые метрики и увеличила разнообразие рекомендаций.
Модель работает в рантайме и регулярно дообучается. Семантический индекс строится на мультимодальных эмбеддингах (аудио, текст, метаданные), полученных с помощью Qwen 2.5 Omni и дополнительно обученных на коллаборативном InfoNCE-лоссе.
Теперь у нас есть архитектура, которая объединяет генерацию и ранжирование и уже показывает качество значительно выше классических кандидатогенераторов и полного softmax. Сейчас Gryphon активно развивается в экспериментах с end-to-end-рекомендациями и кросс-доменными генеративными моделями Яндекса.
@RecSysChannel
Разбор подготовила❣ Дарья Тихонович
Разбираем статью о гибридной генеративно-ранжирующей модели в рекомендациях Яндекс Музыки. О ней на Data Fest рассказала Дарья Тихонович, руководитель Яндекс RND-команды, которая разрабатывает новые рекомендательные технологии.
Генеративные рекомендации на базе Semantic IDs позволяют применять подход next token prediction к огромным каталогам, где невозможно напрямую выбирать следующий объект из миллионов вариантов. Вместо того чтобы предсказывать конкретный трек сразу, модель генерирует его поэтапно через последовательность семантических токенов. Например, сначала определяет жанр (русский рок), затем исполнителя («Сплин»), а потом конкретную композицию («Летучий Голландец»).
Такие токены получают с помощью иерархической кластеризации контентных эмбеддингов объектов, где каждый уровень уточняет описание айтема. В результате каждый объект представлен компактным Semantic ID, а генеративная модель (например, TIGER от Google) предсказывает не сам объект, а последовательность его семантических токенов, благодаря чему возможно обучение и использование рексистем на многомиллионных каталогах.
Но у генеративных рекомендательных моделей есть ряд проблем:
Gryphon: генерация + ранжирование в одной модели
Gryphon — гибридная архитектура, которая объединяет генерацию кандидатов и их ранжирование. В основе encoder-decoder: по истории пользователя модель через beam search генерирует набор Semantic IDs. Чтобы избежать накопления ошибок при генерации (Semantic Drift), в beam search используется PRM (Process Reward Model), которая оценивает траектории генерации и помогает выбирать только релевантные пути для продолжения.
После генерации все Semantic IDs отображаются в общем пуле айтемов-кандидатов, релевантность которых оценивается через ORM (Output Reward Model). В результате, генеративная часть отвечает за кандидатогенерацию на уровне Semantic ID, а ORM — за финальное ранжирование айтемов. PRM и ORM — это легковесные модули на основе cross-attention, которые переиспользуют выходы энкодера генеративной модели, и поэтому лишь незначительно растят общее количество параметров и стоимость инференса.
При обучении ORM на задачу next-item-prediction в офлайне Gryphon показал +20% прироста Recal@1000 относительно Argus. Более того, модель опередила по качеству полный softmax по каталогу Яндекс Музыки.
В A/B-тестах Gryphon полностью заменил стек кандидатогенерации и преранжирования Яндекс.Музыки (15+ моделей), сократив число кандидатов для финального ранкера с 3000 до 1000 без потери качества. В сравнении с генеративным бейзлайном модель дала +3,6% команд Like, сохранила продуктовые метрики и увеличила разнообразие рекомендаций.
Модель работает в рантайме и регулярно дообучается. Семантический индекс строится на мультимодальных эмбеддингах (аудио, текст, метаданные), полученных с помощью Qwen 2.5 Omni и дополнительно обученных на коллаборативном InfoNCE-лоссе.
Теперь у нас есть архитектура, которая объединяет генерацию и ранжирование и уже показывает качество значительно выше классических кандидатогенераторов и полного softmax. Сейчас Gryphon активно развивается в экспериментах с end-to-end-рекомендациями и кросс-доменными генеративными моделями Яндекса.
@RecSysChannel
Разбор подготовила
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17❤12🔥9💘2
Closing the Online-Offline Gap: A Scalable Framework for Composed Model Evaluation
В рекомендательных системах итоговый скор обычно считается не одной моделью, а композицией нескольких предсказаний. Например, одна модель предсказывает вероятность клика, другая — конверсии после клика, третья — конверсии без клика. Затем эти значения объединяются в итоговый eCVR — оценённую вероятность конверсии, которая используется в ранжировании.
Проблема в том, что модели часто обучают и оценивают изолированно: по AUC, logloss, Normalized Entropy и другим офлайн-метрикам на собственном целевом событии. Но в продакшене предсказание модели — это только один компонент итогового скора. Поэтому улучшение локальной офлайн-метрики не всегда означает улучшение онлайн-метрик.
Meta* предлагает фреймворк iPCF — Intelligent Prediction Composition Framework. Его идея в том, чтобы оценивать новую модель не отдельно, а внутри той продакшн-композиции, в которой она реально используется. Для этого в логи добавляют предсказания всех моделей, участвовавших в итоговом скоре, идентификатор версии конфигурации ранжирования, информацию о том, куда какие предсказания подставлялись в композиционное дерево, и фактические метки: клик, конверсия и т.д.
Сама логика вычисления итогового скора хранится как версионированная конфигурация. Поэтому для исторического показа можно восстановить формулу, по которой тогда считался итоговый скор.
При оценке кандидата iPCF воспроизводит исторические запросы. В старую продакшн-композицию подставляют предсказания новой модели, а предсказания остальных моделей и бизнес-логику оставляют такими, какими они были в логах.
В результате получают симулированный итоговый eCVR — оценку итогового скора, если бы в тот момент вместо старой модели использовалась новая.
После этого офлайн-метрику считают уже не по локальному выходу модели, а по пересчитанному итоговому скору. Так можно сравнить базовый eCVR и симулированный eCVR кандидата, получить iPCF NE или другую iPCF-метрику и оценить офлайн-прирост кандидата.
Смысл в том, что iPCF измеряет не просто качество модели на её собственном целевом событии, а влияние замены этой модели на итоговый ранжирующий скор.
В экспериментах авторы проверяют, насколько хорошо офлайн-прирост предсказывает настоящий онлайн-прирост из A/B-тестов. Для этого используют простую линейную калибровку: предсказанный онлайн-прирост считают пропорциональным офлайн-приросту. Затем сравнивают предсказанный и реальный онлайн-прирост через L1-ошибку.
При использовании iPCF-метрики вместо обычной офлайн-метрики L1-ошибка снизилась на двух группах моделей: на M1 — примерно на 18%, на M2 — примерно на 2,8%. То есть iPCF в этих экспериментах лучше согласовывал офлайн-оценку с онлайн-результатами.
@RecSysChannel
Разбор подготовил❣ Влад Аверков
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
В рекомендательных системах итоговый скор обычно считается не одной моделью, а композицией нескольких предсказаний. Например, одна модель предсказывает вероятность клика, другая — конверсии после клика, третья — конверсии без клика. Затем эти значения объединяются в итоговый eCVR — оценённую вероятность конверсии, которая используется в ранжировании.
Проблема в том, что модели часто обучают и оценивают изолированно: по AUC, logloss, Normalized Entropy и другим офлайн-метрикам на собственном целевом событии. Но в продакшене предсказание модели — это только один компонент итогового скора. Поэтому улучшение локальной офлайн-метрики не всегда означает улучшение онлайн-метрик.
Meta* предлагает фреймворк iPCF — Intelligent Prediction Composition Framework. Его идея в том, чтобы оценивать новую модель не отдельно, а внутри той продакшн-композиции, в которой она реально используется. Для этого в логи добавляют предсказания всех моделей, участвовавших в итоговом скоре, идентификатор версии конфигурации ранжирования, информацию о том, куда какие предсказания подставлялись в композиционное дерево, и фактические метки: клик, конверсия и т.д.
Сама логика вычисления итогового скора хранится как версионированная конфигурация. Поэтому для исторического показа можно восстановить формулу, по которой тогда считался итоговый скор.
При оценке кандидата iPCF воспроизводит исторические запросы. В старую продакшн-композицию подставляют предсказания новой модели, а предсказания остальных моделей и бизнес-логику оставляют такими, какими они были в логах.
В результате получают симулированный итоговый eCVR — оценку итогового скора, если бы в тот момент вместо старой модели использовалась новая.
После этого офлайн-метрику считают уже не по локальному выходу модели, а по пересчитанному итоговому скору. Так можно сравнить базовый eCVR и симулированный eCVR кандидата, получить iPCF NE или другую iPCF-метрику и оценить офлайн-прирост кандидата.
Смысл в том, что iPCF измеряет не просто качество модели на её собственном целевом событии, а влияние замены этой модели на итоговый ранжирующий скор.
В экспериментах авторы проверяют, насколько хорошо офлайн-прирост предсказывает настоящий онлайн-прирост из A/B-тестов. Для этого используют простую линейную калибровку: предсказанный онлайн-прирост считают пропорциональным офлайн-приросту. Затем сравнивают предсказанный и реальный онлайн-прирост через L1-ошибку.
При использовании iPCF-метрики вместо обычной офлайн-метрики L1-ошибка снизилась на двух группах моделей: на M1 — примерно на 18%, на M2 — примерно на 2,8%. То есть iPCF в этих экспериментах лучше согласовывал офлайн-оценку с онлайн-результатами.
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
🐳34👍15🔥9❤4
Поточечное ранжирование vs генеративное: три работы с ICML 2026
Прямо сейчас в Южной Корее идёт ICML — одно из самых масштабных событий в мире машинного обучения. Почти все бигтехи рассказывают похожую историю: обычное поточечное ранжирование постепенно пытаются заменить генеративным.
Вместо моделей в духе HSTU, предсказывающих CTR для каждого кандидата по истории пользователя, всё чаще обсуждают модели, которые генерируют порядок, объяснение или идентификаторы объектов напрямую. А затем — дообучаются через RL на симуляторе, оценивающем финальное ранжирование.
Вот три примера таких моделей, которые обсуждали на ICML.
Meta GR2: Advancing LLM-Based Recommendation System through Reasoning
Команда Meta представила GR2 — генеративный реранкер для финального этапа рекомендательной воронки. Сначала отдельная кандидатогенерация отбирает около 100 кандидатов, затем генеративная модель переранжирует их.
Для обучения строят симулятор, который оценивает итоговое ранжирование, а потом оптимизируют модель через RL по этому сигналу. Основной упор делают на рассуждениях модели: по эмпирическим результатам, именно этот блок даёт большой прирост качества.
Основной интерес работы в том, что кандидатогенерация реализована отдельно от ранжирования. Это не подход в духе OneRec, где модель пытается сама генерировать объекты из огромного пространства, а более практичная схема: сначала привычно отобрали кандидатов, потом генеративно улучшили финальный порядок. Для рекламных систем такой вариант звучит особенно реалистично.
OneReason: from Scaling to Reasoning in recommender systems
OneReason — более общий подход: здесь нет отдельной кандидатогенерации, модель должна сама работать с объектами и генерировать рекомендации.
Интересно, что простое добавление рассуждений сначала сильно портило качество, и значительная часть работы посвящена тому, как это исправить. Авторы подробно разбирают, как привязывать идентификаторы объектов к их смысловому описанию, как учить модель рассуждать над историей пользователя и как не потерять качество при переходе от обычного скоринга к генерации.
В этом главное отличие от GR2: там генеративный реранкер встраивается в уже готовую воронку, а здесь пытаются построить более общую генеративную модель рекомендаций.
Generative Catalog Search
Shopify рассказали про генеративный поиск по каталогу для e-commerce. По сути, они движутся в ту же сторону, что и старшие коллеги: уходят от поточечной оценки кандидатов к оптимизации итоговой выдачи через RL.
До явного рассуждения модели они пока не дошли, но сам переход от pointwise к обучению на сигнале качества финального ранжирования уже дал заметный прирост. В такой постановке это особенно естественно для интернет-магазинов, где важно не просто оценить каждый товар отдельно, а собрать хорошую выдачу под запрос пользователя.
Общий тренд
Индустрия движется от каскадных рекомендательных систем к генеративным рекомендациям, а от прямого обучения на сигналах из прода — к RL на моделях, которые оценивают качество финальной выдачи.
Пока самые практичные варианты выглядят как надстройка над существующим пайплайном: кандидатогенерация происходит отдельно, а генеративная модель улучшает финальное ранжирование. Мы в Яндекс Рекламе тоже собираемся пробовать такие подходы.
#YaICML2026
@RecSysChannel
Разбор подготовил❣ Максим Кузин
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Прямо сейчас в Южной Корее идёт ICML — одно из самых масштабных событий в мире машинного обучения. Почти все бигтехи рассказывают похожую историю: обычное поточечное ранжирование постепенно пытаются заменить генеративным.
Вместо моделей в духе HSTU, предсказывающих CTR для каждого кандидата по истории пользователя, всё чаще обсуждают модели, которые генерируют порядок, объяснение или идентификаторы объектов напрямую. А затем — дообучаются через RL на симуляторе, оценивающем финальное ранжирование.
Вот три примера таких моделей, которые обсуждали на ICML.
Meta GR2: Advancing LLM-Based Recommendation System through Reasoning
Команда Meta представила GR2 — генеративный реранкер для финального этапа рекомендательной воронки. Сначала отдельная кандидатогенерация отбирает около 100 кандидатов, затем генеративная модель переранжирует их.
Для обучения строят симулятор, который оценивает итоговое ранжирование, а потом оптимизируют модель через RL по этому сигналу. Основной упор делают на рассуждениях модели: по эмпирическим результатам, именно этот блок даёт большой прирост качества.
Основной интерес работы в том, что кандидатогенерация реализована отдельно от ранжирования. Это не подход в духе OneRec, где модель пытается сама генерировать объекты из огромного пространства, а более практичная схема: сначала привычно отобрали кандидатов, потом генеративно улучшили финальный порядок. Для рекламных систем такой вариант звучит особенно реалистично.
OneReason: from Scaling to Reasoning in recommender systems
OneReason — более общий подход: здесь нет отдельной кандидатогенерации, модель должна сама работать с объектами и генерировать рекомендации.
Интересно, что простое добавление рассуждений сначала сильно портило качество, и значительная часть работы посвящена тому, как это исправить. Авторы подробно разбирают, как привязывать идентификаторы объектов к их смысловому описанию, как учить модель рассуждать над историей пользователя и как не потерять качество при переходе от обычного скоринга к генерации.
В этом главное отличие от GR2: там генеративный реранкер встраивается в уже готовую воронку, а здесь пытаются построить более общую генеративную модель рекомендаций.
Generative Catalog Search
Shopify рассказали про генеративный поиск по каталогу для e-commerce. По сути, они движутся в ту же сторону, что и старшие коллеги: уходят от поточечной оценки кандидатов к оптимизации итоговой выдачи через RL.
До явного рассуждения модели они пока не дошли, но сам переход от pointwise к обучению на сигнале качества финального ранжирования уже дал заметный прирост. В такой постановке это особенно естественно для интернет-магазинов, где важно не просто оценить каждый товар отдельно, а собрать хорошую выдачу под запрос пользователя.
Общий тренд
Индустрия движется от каскадных рекомендательных систем к генеративным рекомендациям, а от прямого обучения на сигналах из прода — к RL на моделях, которые оценивают качество финальной выдачи.
Пока самые практичные варианты выглядят как надстройка над существующим пайплайном: кандидатогенерация происходит отдельно, а генеративная модель улучшает финальное ранжирование. Мы в Яндекс Рекламе тоже собираемся пробовать такие подходы.
#YaICML2026
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18🔥13❤🔥8🦄1
Тренды рекомендательных систем на ICML 2026 [1/2]
В этом году о рекомендациях много говорили на тематическом воркшопе The Generative Turn in Search and Recommendation. Сегодня разберём доклады оттуда.
Meta GR2: Advancing LLM-Based Recommendation System through Reasoning
Unified RecSys with RL end-to-end optimization. Делают модель, переранжирующую список кандидатов — что отличает их от чисто генеративных рекомендаций. Механизм примерно следующий:
Шаг 0. Большая текстовая reasoning-модель получает на вход контекст и список кандидатов. А на выходе возвращает итоговый порядок — качественно и дорого в плане инференса. Далее стоимость будет падать при относительном сохранении качества.
Шаг 1. Mid-train: обучение студента, где товары обозначены Semantic ID — спецтокенами, обозначающими подсклеенные айтемы, полученные через RQ-VAE. Как делать это хорошо — отдельный разговор. Используют и рекомендательные задачи (следующий товар, суммаризация интересов пользователя и т.п.), и некие general-domain data.
Шаг 2. RL post-training, on-policy distillation, etc. Разных техник описано много. Cодержательно, что авторы заявляют -3% качества к проду у zero-shot, +5% у SFT, +18% у итогового решения. То есть, основной профит прячется здесь.
Шаг 3. Дистилляция reasoning в low-think/no-think — всё ещё экономят токены.
Шаг 4. Инфраструктурные улучшения — собирают X'ы ускорения за счёт плясок вокруг CUDA graph pre-fill, KV cache, prompt compression. Полный список не влез даже в исходную презентацию.
В итоге со всеми ухищрениями получают маленькие — 0.6B и 1.7B — модельки с вполне катабельными таймингами. Имхо, приятное свойство доклада — опциональность шагов. Это хороший план действий.
Generative Catalog Search. Building Shopify’s Generative Product Search
Относительно обычный генеративный подход — SID-LLM. Но интересным показалось не это, а их бейзлайн — прошлый прод. Там указан Generative Query Rewriting + Hybrid Retrieval (lexical matching + embedding-based retrieval).
Далее утверждается, что чисто генеративная часть ухудшала метрики на 10%, а будучи замешанной в параллель с их прошлым способом поиска товаров, наоборот, подрастила на 2%.
Связано ли это с тем, что бейзлайн был сильнее, или с тем, что последний шаг на Model Training Stages — SFT, непонятно. Впрочем, внедрить Generative Query Rewriting явно проще, чем полноценные генеративные рекомендации, раз уж он есть у Shopify — значит, в нём есть толк.
Ground Truth for the Generative Turn: Human Judgment at Scale for Search and Recommendation
Учитывая, в скольких разных местах используются разные вариации на тему LLM-as-a-judge, несложно догадаться, что в докладе замешана Toloka.
Несколько обрывочно говорят о том, почему люди всё-таки нужны, и что одной только информации о кликах-покупках не хватит. Еë недостаточно, например, для оценки всяких рассуждений и рефразов. Рассказывают о своих экспертах: нашли 5000 оценщиков с подтверждёнными покупками на целевом US/Canada-рынке, отсеяли 90% по качеству, через 14 недель устаканились на уровне в 315 человек.
Далее заметили, что в большинстве категорий люди оценивают покупки из своей категории заметно строже, что должно растить качество разметки. При этом переучивать и сводить строгих/слабых разметчиков у авторов не получилось, разброс строгости остаётся прежним на протяжении недель.
Выделяют пять слоёв контроля разметки:
1. Контрольные задания — выкинуть 90% самых слабых.
2. Технические проверки — всё, что верифицируемо.
3. LLM-проверки или LLM-критик, который подсвечивает ключевое, но не принимает решения за человека.
4. Кворум — ловит шум отдельных разметчиков.
5. Проверка заказчиком.
В целом, из своего опыта замечу, что заказывать людям хорошую разметку очень дорого, а плохая разметка в целом уже не нужна.
#YaICML2026
@RecSysChannel
Разбор подготовил❣ Кирилл Шевкунов
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
В этом году о рекомендациях много говорили на тематическом воркшопе The Generative Turn in Search and Recommendation. Сегодня разберём доклады оттуда.
Meta GR2: Advancing LLM-Based Recommendation System through Reasoning
Unified RecSys with RL end-to-end optimization. Делают модель, переранжирующую список кандидатов — что отличает их от чисто генеративных рекомендаций. Механизм примерно следующий:
Шаг 0. Большая текстовая reasoning-модель получает на вход контекст и список кандидатов. А на выходе возвращает итоговый порядок — качественно и дорого в плане инференса. Далее стоимость будет падать при относительном сохранении качества.
Шаг 1. Mid-train: обучение студента, где товары обозначены Semantic ID — спецтокенами, обозначающими подсклеенные айтемы, полученные через RQ-VAE. Как делать это хорошо — отдельный разговор. Используют и рекомендательные задачи (следующий товар, суммаризация интересов пользователя и т.п.), и некие general-domain data.
Шаг 2. RL post-training, on-policy distillation, etc. Разных техник описано много. Cодержательно, что авторы заявляют -3% качества к проду у zero-shot, +5% у SFT, +18% у итогового решения. То есть, основной профит прячется здесь.
Шаг 3. Дистилляция reasoning в low-think/no-think — всё ещё экономят токены.
Шаг 4. Инфраструктурные улучшения — собирают X'ы ускорения за счёт плясок вокруг CUDA graph pre-fill, KV cache, prompt compression. Полный список не влез даже в исходную презентацию.
В итоге со всеми ухищрениями получают маленькие — 0.6B и 1.7B — модельки с вполне катабельными таймингами. Имхо, приятное свойство доклада — опциональность шагов. Это хороший план действий.
Generative Catalog Search. Building Shopify’s Generative Product Search
Относительно обычный генеративный подход — SID-LLM. Но интересным показалось не это, а их бейзлайн — прошлый прод. Там указан Generative Query Rewriting + Hybrid Retrieval (lexical matching + embedding-based retrieval).
Далее утверждается, что чисто генеративная часть ухудшала метрики на 10%, а будучи замешанной в параллель с их прошлым способом поиска товаров, наоборот, подрастила на 2%.
Связано ли это с тем, что бейзлайн был сильнее, или с тем, что последний шаг на Model Training Stages — SFT, непонятно. Впрочем, внедрить Generative Query Rewriting явно проще, чем полноценные генеративные рекомендации, раз уж он есть у Shopify — значит, в нём есть толк.
Ground Truth for the Generative Turn: Human Judgment at Scale for Search and Recommendation
Учитывая, в скольких разных местах используются разные вариации на тему LLM-as-a-judge, несложно догадаться, что в докладе замешана Toloka.
Несколько обрывочно говорят о том, почему люди всё-таки нужны, и что одной только информации о кликах-покупках не хватит. Еë недостаточно, например, для оценки всяких рассуждений и рефразов. Рассказывают о своих экспертах: нашли 5000 оценщиков с подтверждёнными покупками на целевом US/Canada-рынке, отсеяли 90% по качеству, через 14 недель устаканились на уровне в 315 человек.
Далее заметили, что в большинстве категорий люди оценивают покупки из своей категории заметно строже, что должно растить качество разметки. При этом переучивать и сводить строгих/слабых разметчиков у авторов не получилось, разброс строгости остаётся прежним на протяжении недель.
Выделяют пять слоёв контроля разметки:
1. Контрольные задания — выкинуть 90% самых слабых.
2. Технические проверки — всё, что верифицируемо.
3. LLM-проверки или LLM-критик, который подсвечивает ключевое, но не принимает решения за человека.
4. Кворум — ловит шум отдельных разметчиков.
5. Проверка заказчиком.
В целом, из своего опыта замечу, что заказывать людям хорошую разметку очень дорого, а плохая разметка в целом уже не нужна.
#YaICML2026
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥5👍3
Тренды рекомендательных систем на ICML 2026 [2/2]
Продолжаем разбор докладов о рекомендациях с воркшопа The Generative Turn in Search and Recommendation.
OneReason: From Scaling to Reasoning in Recommender Systems
Доклад о том, как из OneRec V1/V2 многократно пытались сделать reasoning-модель, но получилось далеко не с первой попытки — рассуждающая модель оказалась хуже.
Выделяют четыре аспекта рассуждений — R0-R3: понимание товаров (разумеется, речь о Semantic ID), взаимоотношения/связи товаров, развитие интересов, рекомендации. На базе этих задач собирают претрейн, и он хуже не-думающего варианта.
Далее с помощью GRPO учат четырёх экспертов по доменам (Ad/Video/Product/Live — от 7% до 19% профита относительно универсального mix-варианта) и с помощью rejection sampling поверх mix-RL-варианта дистиллируют их в одну модель, в которой думающая версия наконец-то побеждает.
При этом, если верить слайдам, думающая модель применяется не в реальном времени (чтобы победить задержки и вычислительную сложность) и в параллель с не-reasoning-версией.
Towards Generative Recommender in Facebook Marketplace Jobs
В этом докладе во многом идёт рассуждение о Semantic ID. Выносится понятная мысль, что они позволяют сократить контекст на 50X с одной стороны, и увеличить глубину истории до 1K+ с другой. К тому же оперировать токенами модели всё-таки привычнее.
Авторы утверждают, что в их задаче — Jobs — это критично: описания длинные, элементы обновляются слишком часто, документы холодные, сигналы разреженные.
Как и в докладе Shopify, обучение состоит из отображения товаров в Semantic ID — RQ-KMeans/RQ-VAE, их выравнивания и Multitask-SFT, при этом без RL, что несколько конфликтует с другими докладами.
Касательно SID: авторы замечают, что они весьма lossy, то есть, теряют много информации. Умное добавление текста к SID может помочь, не сильно теряя выигрыш от скорости — всё ещё X20 к полнотекстовому варианту.
Как и в первом докладе, утверждается, что запущенный вариант — поточечное LLM-ранжирование + традиционная value model поверх неё, что позволяет сохранить гибкость в решении: например, крутить свежесть в выдаче понятным образом.
Осмысление
В целом, можно было бы сказать, что RecSys движется от каскадных рекомендательных систем к генеративным рекомендациям, да вот в первом докладе было переранжирование, а в последнем — вообще pointwise-ранжирование.
Можно было бы сказать, что всё движется в сторону advanced RL-подходов, да вот снова в двух других докладах им не уделили внимания.
Что можно утверждать наверняка: методы из NLP, как и 10 лет назад, продолжают проникать в RecSys, и эта тенденция не планирует останавливаться. А с появлением разного рода «товарных» чатов интеграция будет заметно глубже.
P. S. У нас тоже был постер о рекомендациях. Правда, довольно нишевых.
#YaICML2026
@RecSysChannel
Разбор подготовил❣ Кирилл Шевкунов
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Продолжаем разбор докладов о рекомендациях с воркшопа The Generative Turn in Search and Recommendation.
OneReason: From Scaling to Reasoning in Recommender Systems
Доклад о том, как из OneRec V1/V2 многократно пытались сделать reasoning-модель, но получилось далеко не с первой попытки — рассуждающая модель оказалась хуже.
Выделяют четыре аспекта рассуждений — R0-R3: понимание товаров (разумеется, речь о Semantic ID), взаимоотношения/связи товаров, развитие интересов, рекомендации. На базе этих задач собирают претрейн, и он хуже не-думающего варианта.
Далее с помощью GRPO учат четырёх экспертов по доменам (Ad/Video/Product/Live — от 7% до 19% профита относительно универсального mix-варианта) и с помощью rejection sampling поверх mix-RL-варианта дистиллируют их в одну модель, в которой думающая версия наконец-то побеждает.
При этом, если верить слайдам, думающая модель применяется не в реальном времени (чтобы победить задержки и вычислительную сложность) и в параллель с не-reasoning-версией.
Towards Generative Recommender in Facebook Marketplace Jobs
В этом докладе во многом идёт рассуждение о Semantic ID. Выносится понятная мысль, что они позволяют сократить контекст на 50X с одной стороны, и увеличить глубину истории до 1K+ с другой. К тому же оперировать токенами модели всё-таки привычнее.
Авторы утверждают, что в их задаче — Jobs — это критично: описания длинные, элементы обновляются слишком часто, документы холодные, сигналы разреженные.
Как и в докладе Shopify, обучение состоит из отображения товаров в Semantic ID — RQ-KMeans/RQ-VAE, их выравнивания и Multitask-SFT, при этом без RL, что несколько конфликтует с другими докладами.
Касательно SID: авторы замечают, что они весьма lossy, то есть, теряют много информации. Умное добавление текста к SID может помочь, не сильно теряя выигрыш от скорости — всё ещё X20 к полнотекстовому варианту.
Как и в первом докладе, утверждается, что запущенный вариант — поточечное LLM-ранжирование + традиционная value model поверх неё, что позволяет сохранить гибкость в решении: например, крутить свежесть в выдаче понятным образом.
Осмысление
В целом, можно было бы сказать, что RecSys движется от каскадных рекомендательных систем к генеративным рекомендациям, да вот в первом докладе было переранжирование, а в последнем — вообще pointwise-ранжирование.
Можно было бы сказать, что всё движется в сторону advanced RL-подходов, да вот снова в двух других докладах им не уделили внимания.
Что можно утверждать наверняка: методы из NLP, как и 10 лет назад, продолжают проникать в RecSys, и эта тенденция не планирует останавливаться. А с появлением разного рода «товарных» чатов интеграция будет заметно глубже.
P. S. У нас тоже был постер о рекомендациях. Правда, довольно нишевых.
#YaICML2026
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12❤🔥5🔥4🙏2