tgindex

Рекомендательная [RecSys Channel]

описание

Канал про рекомендательные системы от ml-специалистов Яндекса. Делимся опытом, обсуждаем новые подходы и интересные статьи. Вопросы и предложения > @yandex_ml_brand

← к каналу@RecSysChannel
3 178
подписчиков
Охват к подписчикам
52,8%
ERR
Реакции к просмотрам
1,18%
457 на 23 постов
Пересылки к просмотрам
1,31%
509
Постов в день
0,4
всего 23

Где отзываются чаще

доля реакций к просмотрам
  • 13 авг.Выкатили Sona Technical Report — о модели, которая заменила весь рекомендательный стек Яндекс Музыки В этом месяце у службы рекомендательных технологий Яндекса произошли сразу два больших релиза. Сначала показали вторую версию Gryphon — unified-архитектуры, которая объединяет в себе кандидатогенерацию и ранжирование. Это альтернативный OneRec подход к построению рекомендательных end-to-end-моделей. А сегодня представили Sona — итог целого года работы команды, в результате которого удалось заменить весь стек рекомендаций Яндекс Музыки на единую модель. Внутри репорта — много деталей об архитектуре, инфраструктуре, многочисленные аблейшны. Это лучшее внедрение трансформеров в истории А/B-тестов в Яндекс Музыке. Три основные вещи, благодаря которым это получилось. 1. Масштабируемая архитектура Encoder-decoder, обучающийся хронологически на задачу Next Token Prediction без единой ручной фичи. Одной из самых сложных частей было сделать рецепт токенизации, который бы обеспечивал рост качества при росте словаря и числа токенов на документ. 2. Единая модель кандидатогенерации и ранжирования OneRec ранжирует кандидатов отдельной моделью, причём с использованием ручных фич. Мы же стремились к совместному рецепту обучения и инференса. Проблема в том, что задача ранжирования слишком спарсовая и модель просто не обучается выполнять её достаточно хорошо. Решение — сжать год данных в ранжирующую модель, обучающуюся авторегрессивно, дистиллировать эти знания в совместную модель. 3. Инфраструктура обучения и инференса Любые большие изменения в ML приводят к настолько же большим изменениям в инфраструктуре. Нам пришлось фактически построить новый движок рекомендаций с нуля. Очень важной компонентой стало онлайн-обучение: end-to-end-путь события от возникновения до обновления модели в инференсе укладывается в 1 час в 99% случаев. Чтобы лучше понять, что именно в модели поменялось между двумя А/B-тестами — который показывали в Gryphon-v2 и который репортим в Sona, — посмотрите табличку с масштабированием слоёв ранжирующего модуля и контекста и компрессией истории (картинка №2). По сравнению же с текущей продакшен-системой в Sona получили статзначимый рост главных метрик: 🔴+4,53% Active Users — основной метрики эксперимента; 🔴+6,30% Total Listening Time — общего времени прослушивания; 🔴+11,42% Likes — количества лайков. Причём это прирост поверх улучшений от предыдущих внедрений, которые оставались в контрольной выборке в продакшне. Рост Active Users оказался в 2,35 раза выше прироста, который ранее дала Argus — самая сильная модель, использовавшаяся на этой поверхности до Sona. Главный результат работы — получили одну совместно обучаемую модель, которая заменяет собой многоступенчатый рекомендательный каскад и при этом повышает качество рекомендаций на реальном пользовательском трафике. Подробнее о том, как всё устроено и как к этому пришли, руководитель службы рекомендательных технологий Николай Савушкин расскажет на Practical ML Conf. ML Underhood8,32%
  • 14 авг.InterFormer: Effective Heterogeneous Interaction Learning for CTR Prediction Сегодня разбираем статью InterFormer об архитектуре под задачу CTR-prediction на гетерогенных данных: статичных признаках пользователя/айтема и поведенческих последовательностях. Авторы выделяют две проблемы существующих подходов: 1. слабое взаимодействие между sequence- и non-sequence-фичами; 2. агрессивное раннее сжатие последовательностей через pooling/summary, из-за чего теряется много информации. Ключевой вклад — модуль InterFormer, который обрабатывает разные типы признаков отдельно, но на каждом слое обменивает между ними сжатые представления: 🔴Interaction Arch — работает с non-sequence-фичами: user profile, item features, context. Ко входу добавляется summary последовательности, а в качестве бекбона можно использовать разные interaction-модули, например DCNv2 или DHEN. 🔴Sequence Arch — моделирует историю пользователя. Здесь sequence-эмбеддинги обновляются с учётом summary от non-sequence-фичей: сначала через personalized FFN, затем через multi-head attention. 🔴Cross Arch — слой обмена между двумя ветками. Non-sequence-признаки сжимаются через gated selection, а sequence-информация суммаризуется через комбинацию CLS-, PMA- и recent-tokens. Эти summary передаются в соседнюю ветку на следующем слое. Идея в том, чтобы не «схлопывать» все признаки в один вектор слишком рано, а делать «двунаправленный обмен»: sequence помогает non-sequence-части, а non-sequence-контекст помогает sequence-моделированию. Для задачи CTR используется стандартная бинарная кросс-энтропия. Из публичных: AmazonElectronics (3M), TaobaoAds (25M), KuaiVideo (137M). Также авторы используют крупный внутренний датасет Meta* на 70B семплов. На публичных датасетах InterFormer даёт лучшие результаты среди бейзлайнов. На внутреннем датасете Meta авторы показывают +0,15% NE, +24% QPS, а в pilot launch +0,6% uplift по по основным продуктовым метрикам. Ablation studies подтверждают, что: 🔴bidirectional interaction лучше однонаправленного обмена; 🔴selective aggregation лучше раннего pooling/MLP/MHA-сжатия; 🔴удаление PMA, recent tokens, gating, PFFN или MHA ухудшает качество. Главное достоинство InterFormer — имплементация идеи с двунаправленным взаимодействием между статичными признаками и последовательностями без агрессивного раннего сжатия. Однако архитектура получилась довольно сложной и тяжелой для распараллеливания, приросты на публичных датасетах небольшие, а самые интересные production-результаты получены на закрытых данных Meta. @RecSysChannel Разбор подготовил ❣ Никита Степанов ___ Компания Meta признана экстремистской; её деятельность в России запрещена.3,93%
  • 5 авг.State of Routing in Model Serving at Netflix В наши дни большинство рекомендательных сервисов используют ML-модели: от линейных и градиентного бустинга до развесистых нейросетей. Если в продукте появляется первая поверхность для подключения продвинутых рекомендательных технологий, то самое простое — внедрить нужную модель в бэкенд сервиса. Однако после запуска всё только начинается. Нужно как-то обновлять модели, тестировать новые архитектуры, подключать новые рекомендательные сценарии и при этом не упереться в ограничения железа. Сегодня разбираем пост, в котором описана инфраструктура для инференса ML-моделей в Netflix. Посмотрим, как они решают эти вопросы в рамках своей платформы Switchboard. Ключевые принципы платформы: 🔴Сотни типов моделей и десятки поверхностей для их использования (персонализированные рекомендации фильмов, антифрод). 🔴Суммарно ~1M RPS. 🔴В API есть абстракция Objective — идентификатор поверхности, для которой нужно посчитать ML-модель. 🔴В продуктовом коде один раз пишется интеграция с платформой, а в запросе передаётся информация о текущем Objective и текущем «контексте» (например, UserId, CountryId, DeviceId). В Netflix используют более широкое понятие serving: кроме самого инференса модели, оно включает получение данных из внешних сервисов по идентификаторам из «контекста», расчёт фичей поверх входных данных, которые идут на вход в инференс, запуск модели и пост-обработку результатов. 🔴Продуктовый код «не знает», что у ML-моделей бывает версионирование, изменение архитектуры и постоянные A/B-эксперименты. Не знает, какие данные реально будут использованы при вычислении. 🔴ML-инженеры проводят эксперименты через Switchboard и могут с помощью динамических конфигов выбирать, какие модели будут обслуживать разные Objective. 🔴Инженеры Switchboard имеют контракты по SLA для нужных Objective и скрывают шардирование ML-моделей по различным кластерам, переливание трафика между моделями, A/B-эксперименты и миграции. Но есть три критичные проблемы: 1. Switchboard становится единой точкой отказа — любой сбой на уровне входной прокси может задеть много ML-сценариев. 2. Появляется просадка по latency (~10–20 мс): дополнительный сетевой хоп, обработка входного payload'а (парсинг всего запроса для определения Objective и параметров, необходимых для управления трафиком) и нарезка A/B-экспериментов (тоже через внешний сервис). 3. «Шумные соседи»: клиенты могут неожиданно повысить нагрузку и неявно помешать запросам других клиентов. Тогда в Netflix решают аккуратно избавиться от единой прокси в Switchboard. Но при этом важно не потерять классные свойства и абстракции, которые уже устоялись. Нужно, чтобы в клиенте появилась вся информация, которой владеет Switchboard, для определения, куда именно проксировать запрос. Логику Switchboard делят на два компонента, которые скрыли в более умном клиенте на стороне продуктового кода: 1. Появляется отдельный легковесный сервис Lightbulb, в который клиенту надо отправить нужные «контекстные» данные и получить информацию, какую модель (routingKey) надо считать (по сути, нарезка трафика для необходимых кейсов). 2. Локально поднимается Envoy-прокси, куда независимо доставляют маппинги, на каких хостах какие ML-модели живут (routingKey → hosts). Со стороны клиента остаётся пробросить routingKey в хедерах запроса в локальный Envoy, который согласно своим маппингам сделает запрос в нужный хост. В итоге удалось избавиться от единой прокси и дополнительного сетевого хопа, а также от лишнего парсинга запроса на стороне Switchboard в пользу легковесных запросов в Lightbulb. И сохранить все продуктовые свойства платформы тоже удалось. Ребята из Netflix репортят это как заслуженный успех, но часть деталей в статье не раскрыта и, скорее всего, требует отдельной проработки. Например, не сказано, что происходит в случае сбоев Lightbulb, который по сути стал новой единой точкой отказа и как происходит расселение ML-моделей по хостам. Поэтому ждём от Netflix постов с новыми деталями. @RecSysChannel Разбор подготовил ❣ Александр Михеев2,76%
  • 22 июл.TurboQuant: Redefining AI efficiency with extreme compression Обсудим небольшую статью от Google о новом способе квантования векторов для сжатия KV-кэшей. Она зафорсилась после публикации и обросла множеством домыслов. Сейчас, когда ажиотаж схлынул, попробуем разобраться, в чём её суть. В отличие от классических подходов для сжатия KV-кэшей в статье рассматривают задачу квантизации векторов в общем виде. По сути, её свели к независимой квантизации отдельных компонент вектора. Методов квантизации вещественных чисел много, но почему этого недостаточно? При восстановлении векторов после квантизации важно получить не вектора в первоначальном виде, а сохранить свойства относительно их конфигурации в пространстве. В частности, хочется минимизировать ошибку нормы вектора и скалярного произведения между парами векторов до квантизации и после восстановления. Как задачу квантизации вектора свести к независимой квантизации его отдельных компонент? Наши вектора будут иметь равномерное распределение на единичном n-мерном шаре. Из этого следует, что при больших размерностях векторов каждая компонента распределена «почти нормально», а между собой они «нескореллированы и почти независимы». Предположения сильные, но сводят задачу к независимой квантизации отдельных компонент, где каждая хорошо распределена. Для квантизации с учётом желаемых свойств авторы предлагают подход TurboQuant. Он состоит из двух алгоритмов, применяющихся к каждой компоненте вектора: 1) Минимизация дисторшена (норма разницы вектора в исходном виде и после восстановления) за счёт того, что каждая компонента распределена «почти нормально». По сути используется известный подход «квантование с порогами», где оптимальные «пороги» можно посчитать заранее и закодировать нужным количеством бит. 2) Несмотря на минимизацию дисторшена, в отдельных компонентах будет накапливаться ошибка восстановления. Это влияет на скалярные произведения между векторами — будут получаться смещённые значения. Для минимизации таких ошибок отдельно кодируют 1 битом «поправку» к каждой компоненте при помощи ранее разработанного алгоритма. И получают теоретическую гарантию, что оценка скалярного произведения не будет смещённой. Это уже описано в статьях. Главное же новшество работы в том, что удалось объединить известные методы и теоретически обосновать, что такая комбинация даёт нужные свойства с минимизацией ошибок. Для оценки TurboQuant авторы попробовали разные типы задач (сжатие KV-кешей для LLM, приближенный поиск векторов), где было заявлено, что алгоритм показал приемлемое качество при простой реализации с точки зрения вычислений. На примере рассмотрим, как проверяли способы квантизации KV-кэшей для Llama-3.1-8B-Instruct на тесте Needle-In-A-Haystack. Для проверки модель должна восстанавливать скрытое предложение из последовательности с длинным контекстом. Способы квантизации, перечисленные на иллюстрации, справились хуже, а алгоритм TurboQuant без проблем прошёл его с учётом 4x сжатия. Эти результаты подтвердили теоретические выкладки: при квантовании методом TurboQuant нет существенных просадок по качеству. Неужели всё так хорошо и TurboQuant — новый стандарт в индустрии? Есть нюансы: 🔴Для достижения специального распределения векторов требуется, чтобы они были отномированы и умножены на случайную матрицу. Это может быть непрактичным с точки зрения вычислений для некоторых приложений. 🔴Авторы заявляют что TurboQuant сжимает KV-кеши в 8 раз. Но в качестве бейзлайна берется формат fp32. Хотя в индустрии квантование в 4 или 8 бит — уже стандарт. 🔴Методы сжатия KV-кешей, связанные с изменением архитектуры моделей, позволяют ценой качества сжать их сильнее и получить приросты несравнимые с квантизацией отдельных компонент вектора. Революция пока не произошла, хоть после поста в блоге Google и наблюдалась просадка рыночных котировок производителей полупроводников. Но, возможно, авторы смогут эти подходы усилить — и стоит ждать новых практических результатов. @RecSysChannel Разбор подготовил ❣ Александр Михеев2,46%
  • 8 июл.Поточечное ранжирование 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 признана экстремистской; её деятельность в России запрещена.2,32%
  • 18 июл.Тренды рекомендательных систем на 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 признана экстремистской; её деятельность в России запрещена.2,08%
  • 31 июл.Работы о рексистемах на SIGIR 2026 На прошлой неделе в Мельбурне прошла конференция по исследованиям и разработке информационного поиска. Наша коллега Екатерина Дмитриева побывала в Австралии и рассказала о трёх работах, которые отражают основные тренды SIGIR. Ключевая мысль — генеративный ретривал остаётся очень актуальным направлением в исследованиях, но при этом пока в индустрии не готовы полноценно заменять им всю каскадную систему. Поэтому более классические работы по улучшению ранжирующих моделей всё ещё важны. HyFormer: Revisiting the Roles of Sequence Modeling and Feature Interaction in CTR Prediction Одна из таких классических работ. Авторы из ByteDance предлагает CTR-модель, в которой обработка пользовательской истории и ручных фичей объединена в многоуровневой архитектуре. Основная фишка модели — использование специальных Global Tokens, которые изначально строятся из смеси непоследовательных признаков и агрегированных представлений истории для связи двух источников сигналов. Эти токены в каждом HyFormer-блоке проходят две стадии: 1) в Query Decoding используются как queries для cross-attention к layer-wise K/V истории; 2) в Query Boosting смешиваются с признаками пользователя, контекста и кандидата через лёгкий MLP-Mixer. После обеих стадий обновлённые Global Tokens передаются в следующий HyFormer-блок. В отличие от более устоявшейся архитектуры — как, например, LONGER + RankMixer — HyFormer связывает историю и остальные признаки на всей глубине модели, а не только после её сжатия. По сравнению же с MTGR и OneTrans, она раздельно обрабатывает разные последовательности и использует небольшое число Global Tokens вместо общего дорогого self-attention. GenRec: A Preference-Oriented Generative Framework for Large-Scale Recommendation Работа команды JD.com о генеративном кандгене в ленте на главной странице JD App, где decoder-only-модель напрямую генерирует Semantic IDs товаров из всего каталога. Главная особенность GenRec — Page-wise NTP, при котором вместо обучения на одном следующем товаре модель предсказывает сразу все взаимодействия внутри страницы: заказы, клики и показы товаров. Так авторы борются с проблемой Point-wise NTP, где одному контексту соответствуют несколько разных таргетов, и одновременно получают более плотный обучающий сигнал. Помимо Page-wise NTP, предложены ещё два улучшения. Token Merger объединяет токены Semantic ID товара в один вектор, примерно вдвое сокращая историю, а к стандартному GRPO добавляется NLL-регуляризация, не позволяя генерации слишком далеко уйти от реальных пользовательских взаимодействий. OxygenREC: An Instruction-Following Generative Framework for E-commerce Recommendation Ещё одна работа команды JD.com о генеративных рекомендациях, но уже сразу в нескольких сценариях JD App: от главной и товарных лент до корзины и чекаута. Работа следует принципу Fast-Slow Thinking: near-line LLM анализирует профиль, контекст, запросы и историю пользователя, формируя кэшируемые Contextual Reasoning Instructions. Во время обучения представления инструкций сближаются с таргетными товарами через Query-to-Item loss, а во время инференса используются для отбора наиболее релевантных событий из долгосрочной истории. Чтобы одну модель можно было использовать на разных поверхностях, на этапе постобучения MCTS отдельно для каждого сценария исследует последовательности Semantic IDs. А Joint Pareto Optimization совместно обучает общую policy, балансируя цели разных сценариев. #YaSIGIR26 @RecSysChannel Интересное увидела ❣ Екатерина Дмитриева1,83%
  • 30 июн.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 признана экстремистской; её деятельность в России запрещена.1,71%
  • 27 маяКак в ARGUS решали проблемы контекста, кросс-доменных знаний и претрейна Мы уже разбирали статью Scaling Recommender Transformers to One Billion Parameters, в которой представили генеративную модель персонализации ARGUS, от Яндекса. За последний год модель заметно изменилась и адаптировалась под разные домены внутри компании. О генеративной постановке в рексистемах и развитии ARGUS подробно написал на Хабре руководитель службы рекомендательных технологий Николай Савушкин. Ну а мы рассказываем о трёх ограничениях, с которыми столкнулся подход, и о том, как удалось с ними разобраться. Проблема 1: офлайн-обработка и позднее связывание Раньше ARGUS обрабатывал пользовательскую историю офлайн, поэтому видел её только раз в сутки и не учитывал свежие действия. Контекст подключался на последнем шаге — через позднее связывание. Модель прогоняла через трансформер последовательность троек (context, item, action), а контекст следующего документа подставлялся уже на выходе. Из-за этого вся информация о связи между историей и текущим контекстом должна была «протаскиваться» через трансформер, что со временем стало архитектурным боттлнеком. Решение: перешли на context-aware-токенизацию Чтобы контекст перестал быть внешней надстройкой, его сделали полноценной частью последовательности. Историю пользователя перестроили в цепочки вида «контекст — связанные события». Следующий документ модель теперь предсказывает именно из контекстного токена. Такой переход убирает позднее связывание и позволяет учитывать контекст с самого начала работы модели. Трансформер пришлось перенести в рантайм, зато модель начала лучше работать в сценариях, где контекст особенно важен, например, в Рекламе, Поиске и doc2doc-рекомендациях. Проблема 2: не было кросс-сервисных знаний Изначально ARGUS был монодоменной моделью: данные брали только из текущего сервиса — например, Маркета или Музыки. Одна из главных идей генеративной постановки — научиться использовать обезличенные сигналы о поведении пользователя сразу из нескольких сервисов. Решение: прокачали кросс-сервисные знания События из разных сервисов собрали в единую кросс-доменную последовательность и начали обрабатывать одной моделью. Каждое событие представляли через набор признаков: item_id, категории и текстовые фичи. Категориальные признаки кодировались мультихешингом в общую unified-матрицу эмбеддингов, а текстовые — через BoW. Для каждого домена использовали отдельную башню, которая обрабатывала признаки событий этого домена и комбинировала их через DCNv2. При этом эмбеддинговая матрица оставалась общей. Так смогли нарастить качество, даже не меняя лоссы и процедуры обучения. Следующим шагом расширили претрейн на несколько доменов: модель начала предсказывать следующий item не только в целевом сервисе, но и в других доменах в истории пользователя. Для этого добавили отдельный Sampled Softmax для каждого домена, а итоговый лосс сделали суммой доменных лоссов. С таким претрейном получили заметный рост качества в downstream-ранжировании. Также проверили, можно ли отказаться от претрейна и оставить только файн-тюнинг. Оказалось, нет: файн-тюнинг быстро переставал расти, а даже одна эпоха претрейна давала прирост, который не удавалось компенсировать дополнительными эпохами файн-тюнинга. Проблема 3: нестабильный и сложный этап претрейна Первоначальный претрейн ARGUS работал, но был сложным и не очень стабильным. Было не до конца понятно, какие части схемы действительно полезны, а какие усложняют обучение. Решение: упростили претрейн Выяснилось, что feedback-loss почти не влияет на результат, поэтому его полностью убрали. В итоге в ARGUS оставили только Next-Item Prediction — эта часть оказалась решающей для роста качества. Больше деталей об экспериментах с ARGUS, разбор отличий от других генеративных моделей и результаты, к которым в итоге пришли авторы, — обо всём этом читайте в хабростатье. @RecSysChannel1,68%
  • 2 июн.MTGR: Industrial-Scale Generative Recommendation Framework in Meituan Сегодня разбираем недавнюю статью от Meituan, крупнейшего сервиса доставки в Китае. В ней предлагают архитектуру ранжирования MTGR, которая использует ручные кросс-фичи, но при этом обладает масштабируемостью генеративных моделей. Авторы выделяют две проблемы: 1. В классических моделях Deep Learning Recommendation (DLRM) вычислительная сложность и инференс масштабируются линейно по числу кандидатов. Если хотим сделать модель тяжелее, втиснуть её в прод становится невозможно по latency. 2. Generative Recommendation Model (GRM) решает проблему масштабирования. Но чтобы это работало, приходится отказываться от кросс-фичей. Авторы показывают, что их удаление настолько просаживает качество, что никакое увеличение параметров это не компенсирует. Чтобы обойти ограничения, пробуют токенизировать все входные признаки: - Профиль пользователя (U) — набор токенов, где каждая фича — отдельный токен. - Историю делят на долгосрочную (S) и краткосрочную (R). Её токенизируют на уровне событий: эмбеддинги фич одного события конкатенируются и прогоняются через MLP. - Кандидатов (C) токенизируют аналогично, но в них замешивают важные кросс-признаки. Затем идёт агрегация: вместо обработки пар «пользователь-кандидат» по отдельности, все кандидаты юзера объединяются в один пример. Полученные токены образуют последовательность U → S → R → C. За один forward-pass модель оценивает сразу всех кандидатов, давая сублинейное масштабирование. Токены подают в модифицированный трансформер HSTU со следующими внедрениями: - Group-Layer Normalization (GLN). Так как токены имеют разную семантику, нормализация делается независимо для каждой группы (U, S, R, C). - Dynamic Masking. Кастомная маска защищает от утечки данных. Пользователь и долгая история (U+S) видны всем. Краткосрочная (R) — подчиняется каузальности. Кандидаты (C) видят только предшествующую часть R и не видят других кандидатов. Над токенами кандидатов на выходе строится MLP для предсказания CTR и CVR. Авторы применили оптимизации, которые увеличили пропускную способность в 1,6–2,4 раза в сравнении с TorchRec. Также им удалось получить x65 FLOPs на один пример без увеличения затрат на обучение в сравнении с DLRM. Вместо статических таблиц внедрили динамические хэшированные эмбеддинги, которые позволяют выделять память для новых пользователей/айтемов в реальном времени без переполнения. Размер батчей сделали динамическим. Семплы с длинной историей объединяются в батчи с меньшим числом семплов. Семплы с короткой историей — в батчи с большим числом семплов. Это даёт примерно одинаковую вычислительную нагрузку на все GPU. Обучение проводили в bf16 mixed precision с префетчингом. Его разбивали на три потока: copy (загрузка данных), dispatch (lookup эмбеддингов), compute (forward/backward), что позволило перекрывать I/O-операции с вычислениями. Эксперименты и результаты Для обучения использовали внутренние логи Meituan, так как открытые датасеты слишком маленькие и в них нет нужных кросс-фичей. В качестве бейзлайнов взяли передовые DLRM-архитектуры: Wukong, UserTower, DNN, MoE, MultiEmbed. Качество оценивали по AUC и GAUC. По сравнению с лучшим бейзлайном (UserTower-SIM) офлайн-метрики (CTR/CTCVR, AUC/GAUC) улучшились на 0,5–1,5%. Проверка показала, что все компоненты архитектуры критичны. Отсутствие кросс-фичей просаживает качество сильнее всего — без них MTGR сразу проигрывает старым бейзлайнам. GroupLN и Dynamic Masking также дают значимый прирост в качестве. Авторы продемонстрировали линейный прирост качества (CTCVR GAUC) от log(flops). Отдельно показали, что модель масштабируется по всем осям: можно наращивать как число слоёв, так и скрытую размерность или длину истории. В онлайн-эксперименте MTGR даёт +1,9% CTR и +1,02% CTCVR в сравнении с лучшим DLRM-бейзлайном. @RecSysChannel Разбор подготовил ❣ Влад Аверков1,68%
  • 10 июн.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 признана экстремистской; её деятельность в России запрещена.1,66%
  • 18 июл.Тренды рекомендательных систем на 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 признана экстремистской; её деятельность в России запрещена.1,47%