Тренды рекомендательных систем на 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 признана экстремистской; её деятельность в России запрещена.

Тренды рекомендательных систем на 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 признана экстремистской; её деятельность в России запрещена.

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
Разбор подготовил ❣ Александр Михеев

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
Разбор подготовил ❣ Александр Михеев