Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations
В рекомендациях для разных поверхностей, доменов и таргетов часто обучают отдельные модели. Но такой подход плохо масштабируется и усложняет поддержку системы. Чтобы решить проблему, авторы Meta Lattice построили фундаментальную модель, сочетающую разные органические и рекламные поверхности Meta*.
Основной вклад статьи в том, что в ней собран большой набор инженерных «рецептов» для такого объединения. Разбирают, как совмещать конверсии с разными окнами атрибуции, отбирать фичи, стабилизировать мультидоменное обучение, делать дистилляцию, включая inference-time-дистилляцию.
Ещё в работе предлагают несколько неочевидных и при этом работающих идей:
- correlation-based loss для смешивания таргетов из разных доменов — решение простое и, судя по статье, эффективное. Это элемент, который позволяет обучать модель для разных поверхностей и одновременно бустить качество на них;
- inference-time distillation — подстановка эмбеддингов учителя в ученика в момент запроса. Технологически это означает, что нужно поддерживать near-realtime-контур с инференсом модели-учителя и кеш эмбеддингов на недавних запросах (не путать с KV-cache);
- совместная модель для pCTR и pCVR — очевидное сокращение компьюта.
В Meta Lattice вводят понятие портфеля — пары поверхности и таргета. Портфели объединяются между доменами с достаточным перекрытием пользователей и одинаковым типом таргетов (моментальные или отложенные). Для каждого объединённого портфеля обучается и деплоится одна модель на общем датасете со всеми таргетами.
Как всё работет в общих чертах:
- Lattice Partitioner — объединяет портфели по перекрытию user_id и схожему типу таргетов.
- Lattice Zipper — объединяет разные окна атрибуции; все они смешиваются в один датасет, для каждого клика случайно выбирается одно окно, а в модели обучают отдельные головы под каждое окно атрибуции. На инференсе используют oracle-head с самым длинным окном.
- Lattice Filter — фильтрует фичи через permutation feature importance и отбор по Парето-фронтам.
- Lattice Models — архитектура на базе DenseNet-like блоков, DHEN/Wukong для feature interaction и трансформера для последовательностей. Используются domain-specific FFN, QK-norm и дополнительный correlation-based loss для multi-domain multi-target обучения.
- Lattice Sketch — подбирает гиперпараметры модели и стратегию FSDP-шардирования с ограничениями по latency и quality.
- Lattice KTAP — inference-time-дистилляция + обычная knowledge-дистилляция: teacher embeddings, soft targets, label smoothing и feature clipping.
Используют два датасета: KuaiVideo (13 млн событий для like/follow/click prediction) и production-scale-датасет Meta на 100 млрд событий для CTR/CVR prediction с ~2 тысячами рекламных фичей.
Обучение идёт на общем датасете со всеми таргетами и доменами внутри объединённого портфеля. У каждого семпла при этом только один таргет.
Фичи берутся из объединения всех фичей портфеля. Если фича отсутствует для конкретного домена или задачи, используют zero-fill. Для каждого семпла считают соответствующий task-specific loss, после чего лоссы суммируются по батчу. Дополнительно добавлен correlation-based loss между предиктами и таргетами.
Дистилляция делается через soft-targets и teacher embeddings на входе модели.
В работе есть аблейшны всех частей пайплайна, а также разбивка по вкладу: Lattice Partitioner (36%), Lattice Zipper (11%), Lattice Filter (13%), Lattice Networks (23%), and Lattice KTAP (17%).
Архитектурные улучшения сравнивают с индустриальными SOTA-подходами, вроде Wukong, — на открытом датасете и на приватном.
Подход уже внедрили в прод, где он принёс двузначные приросты при сокращении компьюта.
@RecSysChannel
Разбор подготовил❣ Александр Плошкин
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
В рекомендациях для разных поверхностей, доменов и таргетов часто обучают отдельные модели. Но такой подход плохо масштабируется и усложняет поддержку системы. Чтобы решить проблему, авторы Meta Lattice построили фундаментальную модель, сочетающую разные органические и рекламные поверхности Meta*.
Основной вклад статьи в том, что в ней собран большой набор инженерных «рецептов» для такого объединения. Разбирают, как совмещать конверсии с разными окнами атрибуции, отбирать фичи, стабилизировать мультидоменное обучение, делать дистилляцию, включая inference-time-дистилляцию.
Ещё в работе предлагают несколько неочевидных и при этом работающих идей:
- correlation-based loss для смешивания таргетов из разных доменов — решение простое и, судя по статье, эффективное. Это элемент, который позволяет обучать модель для разных поверхностей и одновременно бустить качество на них;
- inference-time distillation — подстановка эмбеддингов учителя в ученика в момент запроса. Технологически это означает, что нужно поддерживать near-realtime-контур с инференсом модели-учителя и кеш эмбеддингов на недавних запросах (не путать с KV-cache);
- совместная модель для pCTR и pCVR — очевидное сокращение компьюта.
В Meta Lattice вводят понятие портфеля — пары поверхности и таргета. Портфели объединяются между доменами с достаточным перекрытием пользователей и одинаковым типом таргетов (моментальные или отложенные). Для каждого объединённого портфеля обучается и деплоится одна модель на общем датасете со всеми таргетами.
Как всё работет в общих чертах:
- Lattice Partitioner — объединяет портфели по перекрытию user_id и схожему типу таргетов.
- Lattice Zipper — объединяет разные окна атрибуции; все они смешиваются в один датасет, для каждого клика случайно выбирается одно окно, а в модели обучают отдельные головы под каждое окно атрибуции. На инференсе используют oracle-head с самым длинным окном.
- Lattice Filter — фильтрует фичи через permutation feature importance и отбор по Парето-фронтам.
- Lattice Models — архитектура на базе DenseNet-like блоков, DHEN/Wukong для feature interaction и трансформера для последовательностей. Используются domain-specific FFN, QK-norm и дополнительный correlation-based loss для multi-domain multi-target обучения.
- Lattice Sketch — подбирает гиперпараметры модели и стратегию FSDP-шардирования с ограничениями по latency и quality.
- Lattice KTAP — inference-time-дистилляция + обычная knowledge-дистилляция: teacher embeddings, soft targets, label smoothing и feature clipping.
Используют два датасета: KuaiVideo (13 млн событий для like/follow/click prediction) и production-scale-датасет Meta на 100 млрд событий для CTR/CVR prediction с ~2 тысячами рекламных фичей.
Обучение идёт на общем датасете со всеми таргетами и доменами внутри объединённого портфеля. У каждого семпла при этом только один таргет.
Фичи берутся из объединения всех фичей портфеля. Если фича отсутствует для конкретного домена или задачи, используют zero-fill. Для каждого семпла считают соответствующий task-specific loss, после чего лоссы суммируются по батчу. Дополнительно добавлен correlation-based loss между предиктами и таргетами.
Дистилляция делается через soft-targets и teacher embeddings на входе модели.
В работе есть аблейшны всех частей пайплайна, а также разбивка по вкладу: Lattice Partitioner (36%), Lattice Zipper (11%), Lattice Filter (13%), Lattice Networks (23%), and Lattice KTAP (17%).
Архитектурные улучшения сравнивают с индустриальными SOTA-подходами, вроде Wukong, — на открытом датасете и на приватном.
Подход уже внедрили в прод, где он принёс двузначные приросты при сокращении компьюта.
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🔥10👍5🥰1
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