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
Разбор подготовил❣ Александр Михеев
В наши дни большинство рекомендательных сервисов используют ML-модели: от линейных и градиентного бустинга до развесистых нейросетей. Если в продукте появляется первая поверхность для подключения продвинутых рекомендательных технологий, то самое простое — внедрить нужную модель в бэкенд сервиса.
Однако после запуска всё только начинается. Нужно как-то обновлять модели, тестировать новые архитектуры, подключать новые рекомендательные сценарии и при этом не упереться в ограничения железа.
Сегодня разбираем пост, в котором описана инфраструктура для инференса ML-моделей в Netflix. Посмотрим, как они решают эти вопросы в рамках своей платформы Switchboard.
Ключевые принципы платформы:
В Netflix используют более широкое понятие serving: кроме самого инференса модели, оно включает получение данных из внешних сервисов по идентификаторам из «контекста», расчёт фичей поверх входных данных, которые идут на вход в инференс, запуск модели и пост-обработку результатов.
Но есть три критичные проблемы:
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
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🔥10👍5❤🔥3
Forwarded from ML Underhood
Выкатили 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 Underhood
В этом месяце у службы рекомендательных технологий Яндекса произошли сразу два больших релиза.
Сначала показали вторую версию 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 получили статзначимый рост главных метрик:
Причём это прирост поверх улучшений от предыдущих внедрений, которые оставались в контрольной выборке в продакшне.
Рост Active Users оказался в 2,35 раза выше прироста, который ранее дала Argus — самая сильная модель, использовавшаяся на этой поверхности до Sona.
Главный результат работы — получили одну совместно обучаемую модель, которая заменяет собой многоступенчатый рекомендательный каскад и при этом повышает качество рекомендаций на реальном пользовательском трафике.
Подробнее о том, как всё устроено и как к этому пришли, руководитель службы рекомендательных технологий Николай Савушкин расскажет на Practical ML Conf.
ML Underhood
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤25🔥11👍7❤🔥6
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 признана экстремистской; её деятельность в России запрещена.
Сегодня разбираем статью InterFormer об архитектуре под задачу CTR-prediction на гетерогенных данных: статичных признаках пользователя/айтема и поведенческих последовательностях.
Авторы выделяют две проблемы существующих подходов:
1. слабое взаимодействие между sequence- и non-sequence-фичами;
2. агрессивное раннее сжатие последовательностей через pooling/summary, из-за чего теряется много информации.
Ключевой вклад — модуль InterFormer, который обрабатывает разные типы признаков отдельно, но на каждом слое обменивает между ними сжатые представления:
Идея в том, чтобы не «схлопывать» все признаки в один вектор слишком рано, а делать «двунаправленный обмен»: 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 подтверждают, что:
Главное достоинство InterFormer — имплементация идеи с двунаправленным взаимодействием между статичными признаками и последовательностями без агрессивного раннего сжатия. Однако архитектура получилась довольно сложной и тяжелой для распараллеливания, приросты на публичных датасетах небольшие, а самые интересные production-результаты получены на закрытых данных Meta.
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤6🔥6❤🔥2👨💻1🫡1
OneReason Technical Report [1/2]
Сегодня разбираем хайповый техрепорт от Kuaishou на 108 страниц, в котором авторы научились получать существенный профит от ризонинг-моделей в рекомендациях.
В предыдущих статьях — OneRec-Think и OpenOneRec — модели уже могли генерировать человекочитаемые рассуждения на естественном языке, но thinking-режим не давал стабильного прироста и иногда даже ухудшал рекомендации. В OneReason авторы предлагают полный рецепт, объединяющий улучшенное восприятие itemic-токенов, структурированный CoT и доменный RL. В результате reasoning trace наконец начинает помогать предсказанию, а общие способности модели в основном сохраняются.
В этом разборе сосредоточимся преимущественно на первой части рецепта: устройстве бенчмарков, токенизации и многоуровневом претрейне, который создаёт семантический фундамент для последующего ризонинга.
Авторы предлагают не предсказывать следующий айтем напрямую по шумной истории пользователя. Сначала модель строит структурированный reasoning trace в три этапа. На этапе Persona Abstraction она сжимает историю в компактный профиль устойчивых предпочтений. Затем Interest Expansion выделяет несколько возможных направлений интереса, подтверждённых поведением пользователя. Наконец, Transition Inference сравнивает эти гипотезы с учётом силы и свежести сигналов, их временной связности и соответствия целевому домену. После этого модель генерирует itemic-токены следующего айтема.
Способности модели авторы оценивают на четырёх последовательных уровнях:
R0 — связывать itemic-токены с их текстовой семантикой и отвечать на вопросы о свойствах айтемов;
R1 — выводить отношения и возможные переходы между айтемами на основе их семантики;
R2 — рассматривать историю пользователя как временную последовательность и восстанавливать эволюцию его интересов;
R3 — объединять предыдущие способности для next-item prediction.
Для каждого уровня в едином OneReason-Bench предусмотрен свой набор диагностических задач. Финальное качество рекомендаций измеряют в двух сетапах:
🔴 single-domain, где модель видит историю только из целевого домена,
🔴 cross-domain, где получает взаимодействия пользователя из всех четырёх доменов, но предсказывает айтем из конкретного. Кросс-доменная история обычно даёт небольшой прирост, но для холодных пользователей помогает больше.
Чтобы модель вообще смогла строить такие рассуждения, сначала её пришлось научить понимать сами itemic-токены и пользовательские истории. Об этом поговорим во второй части.
@RecSysChannel
Разбор подготовил❣ Илья Мурзин
Сегодня разбираем хайповый техрепорт от Kuaishou на 108 страниц, в котором авторы научились получать существенный профит от ризонинг-моделей в рекомендациях.
В предыдущих статьях — OneRec-Think и OpenOneRec — модели уже могли генерировать человекочитаемые рассуждения на естественном языке, но thinking-режим не давал стабильного прироста и иногда даже ухудшал рекомендации. В OneReason авторы предлагают полный рецепт, объединяющий улучшенное восприятие itemic-токенов, структурированный CoT и доменный RL. В результате reasoning trace наконец начинает помогать предсказанию, а общие способности модели в основном сохраняются.
В этом разборе сосредоточимся преимущественно на первой части рецепта: устройстве бенчмарков, токенизации и многоуровневом претрейне, который создаёт семантический фундамент для последующего ризонинга.
Авторы предлагают не предсказывать следующий айтем напрямую по шумной истории пользователя. Сначала модель строит структурированный reasoning trace в три этапа. На этапе Persona Abstraction она сжимает историю в компактный профиль устойчивых предпочтений. Затем Interest Expansion выделяет несколько возможных направлений интереса, подтверждённых поведением пользователя. Наконец, Transition Inference сравнивает эти гипотезы с учётом силы и свежести сигналов, их временной связности и соответствия целевому домену. После этого модель генерирует itemic-токены следующего айтема.
Способности модели авторы оценивают на четырёх последовательных уровнях:
R0 — связывать itemic-токены с их текстовой семантикой и отвечать на вопросы о свойствах айтемов;
R1 — выводить отношения и возможные переходы между айтемами на основе их семантики;
R2 — рассматривать историю пользователя как временную последовательность и восстанавливать эволюцию его интересов;
R3 — объединять предыдущие способности для next-item prediction.
Для каждого уровня в едином OneReason-Bench предусмотрен свой набор диагностических задач. Финальное качество рекомендаций измеряют в двух сетапах:
Чтобы модель вообще смогла строить такие рассуждения, сначала её пришлось научить понимать сами itemic-токены и пользовательские истории. Об этом поговорим во второй части.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13👍5🐳5🔥2
OneReason Technical Report [2/2]
В первой части разобрали, как устроен OneReason-Bench и почему авторы вообще вводят многоступенчатый ризонинг вместо next-item prediction. Теперь посмотрим, как модель учат работать с itemic-токенами и почему претрейн оказался здесь так важен.
На претрейне модель прежде всего учат воспринимать историю пользователя и связывать семантические ID с текстом. Каждый айтем представляют четырьмя токенами: токеном домена и тремя семантическими ID. От завершающего токена из OpenOneRec отказались, чтобы сократить представление айтема и оставить больше контекста.
Данные для претрейна делят на четыре уровня гранулярности:
🔴 на уровне токенов модель учат связывать с текстом отдельные itemic-токены, их префиксы и полные токеновые последовательности;
🔴 на уровне айтемов — генерировать описания, восстанавливать itemic-токены по тексту и отвечать на вопросы о свойствах контента;
🔴 на уровне отношений — понимать связи и переходы между айтемами через естественно-языковые объяснения;
🔴 на уровне пользователя — работать с доменно сгруппированными и хронологически перемешанными историями, моделируя кросс-доменные связи и эволюцию интересов.
То есть претрейн не сводят к одному next-item objective. Обучающая смесь одновременно охватывает задачи от семантики отдельных токенов до моделирования полной пользовательской истории.
Около 28,4% токенов претрейна приходится на данные общего назначения: 26,85% составляют текстовые корпуса, а ещё 1,59% — мультимодальные. Они нужны, чтобы во время специализации на рекомендациях модель сохраняла общие reasoning- и instruction-following-способности. С такой смесью итоговая модель остаётся близка к исходному Qwen3-8B на общих LLM-бенчмарках.
Сам претрейн проходит в три этапа.
1) Сначала при замороженном бэкбоне обучают только новые эмбеддинги и соответствующие веса LM-головы для itemic-токенов.
2) Затем размораживают все параметры и продолжают обучение с меньшим learning rate.
3) На последнем этапе максимальную длину отдельных примеров увеличивают с 4K до 32K токенов, чтобы модель научилась обрабатывать полные пользовательские истории.
OneReason обгоняет рекомендательные бейзлайны и почти не просаживается на LLM-бенчмарках — в отличие от Open OneRec, которая заметно теряла в языковых способностях. При этом модель, обученная получать качество за счёт рассуждений, становится лучше и в режиме без ризонинга.
Аблейшны показывают, что добавление каждого следующего уровня гранулярности улучшает качество, а лучший результат даёт весь претрейн-рецепт целиком.
@RecSysChannel
Разбор подготовил❣ Илья Мурзин
В первой части разобрали, как устроен OneReason-Bench и почему авторы вообще вводят многоступенчатый ризонинг вместо next-item prediction. Теперь посмотрим, как модель учат работать с itemic-токенами и почему претрейн оказался здесь так важен.
На претрейне модель прежде всего учат воспринимать историю пользователя и связывать семантические ID с текстом. Каждый айтем представляют четырьмя токенами: токеном домена и тремя семантическими ID. От завершающего токена из OpenOneRec отказались, чтобы сократить представление айтема и оставить больше контекста.
Данные для претрейна делят на четыре уровня гранулярности:
То есть претрейн не сводят к одному next-item objective. Обучающая смесь одновременно охватывает задачи от семантики отдельных токенов до моделирования полной пользовательской истории.
Около 28,4% токенов претрейна приходится на данные общего назначения: 26,85% составляют текстовые корпуса, а ещё 1,59% — мультимодальные. Они нужны, чтобы во время специализации на рекомендациях модель сохраняла общие reasoning- и instruction-following-способности. С такой смесью итоговая модель остаётся близка к исходному Qwen3-8B на общих LLM-бенчмарках.
Сам претрейн проходит в три этапа.
1) Сначала при замороженном бэкбоне обучают только новые эмбеддинги и соответствующие веса LM-головы для itemic-токенов.
2) Затем размораживают все параметры и продолжают обучение с меньшим learning rate.
3) На последнем этапе максимальную длину отдельных примеров увеличивают с 4K до 32K токенов, чтобы модель научилась обрабатывать полные пользовательские истории.
OneReason обгоняет рекомендательные бейзлайны и почти не просаживается на LLM-бенчмарках — в отличие от Open OneRec, которая заметно теряла в языковых способностях. При этом модель, обученная получать качество за счёт рассуждений, становится лучше и в режиме без ризонинга.
Аблейшны показывают, что добавление каждого следующего уровня гранулярности улучшает качество, а лучший результат даёт весь претрейн-рецепт целиком.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥6💅5👍2👎1🐳1🤝1
GRank: Towards Target-Aware and Streamlined Industrial Retrieval with a Generate-Rank Framework
Сегодня разбираем статью о том, как построить ретривал для миллиардов айтемов, сохранить target-aware-ность, уложиться в жесткий latency budget и при этом обойтись без сложных индексов.
В классическом ретривале из миллиардов кандидатов нужно быстро вернуть тысячи или десятки тысяч айтемов, которые дальше пойдут в ранжирование. Поэтому часто используются двубашенные подходы: отдельно получаем юзерный эмбеддинг, отдельно — эмбеддинги айтемов, а дальше считаем какую-то простую функцию вроде dot product и ищем «ближайшие» к юзеру айтемы.
У такого подхода сильно ограничена выразительная способность, ведь эмбеддинги юзеров и айтемов взаимодействуют только через выбранную простую функцию, но никак иначе.
При этом хочется добавить target-aware-ность в архитектуру через более плотное взаимодействие конкретного кандидата с юзером. Например, если хотим понять, насколько юзеру релевантна компьютерная мышь, то можно посмотреть на историю его действий, увидеть что-то о ноутбуках и обратить внимание именно на это. То есть, хочется «перевзвешивать» историю юзера относительно конкретного таргета.
На ретривал-стадии так сделать не получится из-за того, что кандидатов слишком много и обработать их надо быстро. Можно строить сложные индексы на основе деревьев или графов, но их тяжело поддерживать, они замедляют инференс и становится труднее контролировать latency.
В работе предлагается от всего этого уйти и разбить ретривал на две стадии:
1) Генератор, который должен очень быстро вернуть чуть больше кандидатов, чем в итоге нужно. В продовом сетапе авторов он достаёт 2000 айтемов, количество которые потом сужаются до 500. При этом сам генератор на инференсе остается обычной двубашенной моделью.
2) Преранкер, который представляет собой target-aware-подход уже на маленьком наборе кандидатов через cross-attention, после чего выдает более выразительные скоры релевантности.
Самая интересная часть статьи — о том, как учится генератор.
Обычно мы берём юзерный эмбед после трансформера, считаем dot product с айтемом и учим модель отличать позитив от негативов. В GRank к этому добавляют вспомогательную target-aware-задачу.
Берут те же таргет и негативы, подставляют их в историю, прогоняют через трансформер с ранним связыванием и считают лосс по полученным скорам — генератор одновременно учится на обеих задачах.
На инференсе эта target-aware-компонента никак не используется, и мы получаем классический быстрый двухбашенный подход.
По аблейшенам эта компонента выглядит самой важной частью системы — если взять просто генератор, то жертвуем качеством; если добавить только ранкер, метрики лучше, но всё равно проседают относительно полного GRank. А когда к генератору добавляют target-aware-компоненту в лоссе, получается самый большой прирост.
По экспериментам авторы докладывают о двузначных приростах в Recall и NDCG, причём не только на своём датасете. При этом по пропускной способности GRank остаётся примерно на уровне предыдущего двубашенного решения, а подходы со сложными индексами проседают.
@RecSysChannel
Разбор подготовил❣ Никита Степанов
Сегодня разбираем статью о том, как построить ретривал для миллиардов айтемов, сохранить target-aware-ность, уложиться в жесткий latency budget и при этом обойтись без сложных индексов.
В классическом ретривале из миллиардов кандидатов нужно быстро вернуть тысячи или десятки тысяч айтемов, которые дальше пойдут в ранжирование. Поэтому часто используются двубашенные подходы: отдельно получаем юзерный эмбеддинг, отдельно — эмбеддинги айтемов, а дальше считаем какую-то простую функцию вроде dot product и ищем «ближайшие» к юзеру айтемы.
У такого подхода сильно ограничена выразительная способность, ведь эмбеддинги юзеров и айтемов взаимодействуют только через выбранную простую функцию, но никак иначе.
При этом хочется добавить target-aware-ность в архитектуру через более плотное взаимодействие конкретного кандидата с юзером. Например, если хотим понять, насколько юзеру релевантна компьютерная мышь, то можно посмотреть на историю его действий, увидеть что-то о ноутбуках и обратить внимание именно на это. То есть, хочется «перевзвешивать» историю юзера относительно конкретного таргета.
На ретривал-стадии так сделать не получится из-за того, что кандидатов слишком много и обработать их надо быстро. Можно строить сложные индексы на основе деревьев или графов, но их тяжело поддерживать, они замедляют инференс и становится труднее контролировать latency.
В работе предлагается от всего этого уйти и разбить ретривал на две стадии:
1) Генератор, который должен очень быстро вернуть чуть больше кандидатов, чем в итоге нужно. В продовом сетапе авторов он достаёт 2000 айтемов, количество которые потом сужаются до 500. При этом сам генератор на инференсе остается обычной двубашенной моделью.
2) Преранкер, который представляет собой target-aware-подход уже на маленьком наборе кандидатов через cross-attention, после чего выдает более выразительные скоры релевантности.
Самая интересная часть статьи — о том, как учится генератор.
Обычно мы берём юзерный эмбед после трансформера, считаем dot product с айтемом и учим модель отличать позитив от негативов. В GRank к этому добавляют вспомогательную target-aware-задачу.
Берут те же таргет и негативы, подставляют их в историю, прогоняют через трансформер с ранним связыванием и считают лосс по полученным скорам — генератор одновременно учится на обеих задачах.
На инференсе эта target-aware-компонента никак не используется, и мы получаем классический быстрый двухбашенный подход.
По аблейшенам эта компонента выглядит самой важной частью системы — если взять просто генератор, то жертвуем качеством; если добавить только ранкер, метрики лучше, но всё равно проседают относительно полного GRank. А когда к генератору добавляют target-aware-компоненту в лоссе, получается самый большой прирост.
По экспериментам авторы докладывают о двузначных приростах в Recall и NDCG, причём не только на своём датасете. При этом по пропускной способности GRank остаётся примерно на уровне предыдущего двубашенного решения, а подходы со сложными индексами проседают.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7❤🔥3👍2🔥2🤝1💘1
Три статьи на стыке LLM и Recsys
Сегодня делимся сразу тремя работами о том, как LLM встраивают в разные части рекомендательных и шопинговых систем.
Building a Production Shopping Agent at Scale
Amazon делятся опытом внедрения их шопингового агента Rufus. Здесь LLM — оркестратор: она принимает запрос пользователя, контекст диалога и релевантные пользовательские фичи и по ним понимает, в какие тулы нужно сходить, чтобы удовлетворить интент. По результатам работы тулов модель формирует окончательный ответ пользователю.
Агент работает в нескольких сценариях: 1) помогает с Product Discovery, когда пользователь ещё не знает конкретный товар; 2) отвечает на вопросы о конкретных товарах; 3) обращается к профилю пользователя, например смотрит прошлые покупки и текущие заказы, и может сам добавлять товары в корзину.
Авторы показывают несколько приёмов для ускорения цепочки.
• Отбирают только релевантные события из истории пользователя и сокращают историю диалога, чтобы не засорять контекст и уменьшать время до первого токена.
• Оптимизируют промпты, делая более стабильные и переиспользуемые префиксы, чтобы не пересчитывать одинаковое состояние агента.
• Делают вызовы тулов строже и по возможности параллелят, чтобы быстрее выдавать результат пользователю.
Можно улучшать каждый компонент по отдельности, но просадить общий пользовательский опыт. Чтобы такого не было, авторы предлагают смотреть на систему end-to-end: насколько удачной была работа агента, устроил ли результат пользователя и насколько дорогим и долгим оказался весь пайплайн.
Probe-Then-Plan: Environment-Aware Planning
Авторы из JD решают задачу сложных пользовательских запросов. Здесь «сложные» — не те, что требуют сложного ризонинга, а те, которые понятны человеку, но плохо переводятся на язык каталога. Например, пользователь хочет подобрать что-то «к зелёной рубашке»: человеку понятно, что речь скорее о брюках, джинсах или обуви, а простой поиск может выдать ещё больше рубашек.
Авторы замечают, что часто достаточно один раз посмотреть на выдачу, чтобы понять, как исправить запрос. Поэтому сначала смотрят, что по исходному запросу выдаёт продакшен-стек. Небольшой Qwen определяет, всё ли с выдачей хорошо, слишком ли она маленькая или товаров много, но они не соответствуют запросу, и при необходимости предлагает план исправления. Модель дистиллируют из большой LLM, а затем дообучают с RL на бизнес-цели.
Даже маленькая модель даёт заметное замедление, поэтому 80% простых запросов оставляют текущему продуктовому стеку, а 20% сложных отправляют через новый пайплайн.
В офлайне подход заметно лучше слепого переписывания запроса. По качеству он уступает ReAct, зато сильно выигрывает по времени. В онлайне всё конвертируется в GMV.
RecGPT-Mobile
Здесь on-device LLM используют, чтобы быстро понять изменения интента в рекомендательной ленте.
Допустим, пользователь внезапно начинает чаще кликать по компактным рюкзакам и добавлять их в избранное. Специальный модуль замечает изменение поведения и триггерит систему. Из залогированных на устройстве релевантных событий формируется промпт для on-device LLM, которая генерирует query под новый интент. Он отправляется в облако, где большая продовая система возвращает релевантные товары и обновляет ленту.
Чтобы всё это работало на устройстве, используют Qwen3-0.6B с квантизацией, берут не всю историю, а только полезный контекст и запускают систему не на каждый случайный клик, а только когда поведение действительно меняется.
В экспериментах LoRA обходит полный тюнинг модели, а квантизация теряет не так много качества. В месячном A/B-тесте получили +2,5% GMV на четырёх поверхностях.
@RecSysChannel
Разбор подготовила❣ Екатерина Дмитриева
Сегодня делимся сразу тремя работами о том, как LLM встраивают в разные части рекомендательных и шопинговых систем.
Building a Production Shopping Agent at Scale
Amazon делятся опытом внедрения их шопингового агента Rufus. Здесь LLM — оркестратор: она принимает запрос пользователя, контекст диалога и релевантные пользовательские фичи и по ним понимает, в какие тулы нужно сходить, чтобы удовлетворить интент. По результатам работы тулов модель формирует окончательный ответ пользователю.
Агент работает в нескольких сценариях: 1) помогает с Product Discovery, когда пользователь ещё не знает конкретный товар; 2) отвечает на вопросы о конкретных товарах; 3) обращается к профилю пользователя, например смотрит прошлые покупки и текущие заказы, и может сам добавлять товары в корзину.
Авторы показывают несколько приёмов для ускорения цепочки.
• Отбирают только релевантные события из истории пользователя и сокращают историю диалога, чтобы не засорять контекст и уменьшать время до первого токена.
• Оптимизируют промпты, делая более стабильные и переиспользуемые префиксы, чтобы не пересчитывать одинаковое состояние агента.
• Делают вызовы тулов строже и по возможности параллелят, чтобы быстрее выдавать результат пользователю.
Можно улучшать каждый компонент по отдельности, но просадить общий пользовательский опыт. Чтобы такого не было, авторы предлагают смотреть на систему end-to-end: насколько удачной была работа агента, устроил ли результат пользователя и насколько дорогим и долгим оказался весь пайплайн.
Probe-Then-Plan: Environment-Aware Planning
Авторы из JD решают задачу сложных пользовательских запросов. Здесь «сложные» — не те, что требуют сложного ризонинга, а те, которые понятны человеку, но плохо переводятся на язык каталога. Например, пользователь хочет подобрать что-то «к зелёной рубашке»: человеку понятно, что речь скорее о брюках, джинсах или обуви, а простой поиск может выдать ещё больше рубашек.
Авторы замечают, что часто достаточно один раз посмотреть на выдачу, чтобы понять, как исправить запрос. Поэтому сначала смотрят, что по исходному запросу выдаёт продакшен-стек. Небольшой Qwen определяет, всё ли с выдачей хорошо, слишком ли она маленькая или товаров много, но они не соответствуют запросу, и при необходимости предлагает план исправления. Модель дистиллируют из большой LLM, а затем дообучают с RL на бизнес-цели.
Даже маленькая модель даёт заметное замедление, поэтому 80% простых запросов оставляют текущему продуктовому стеку, а 20% сложных отправляют через новый пайплайн.
В офлайне подход заметно лучше слепого переписывания запроса. По качеству он уступает ReAct, зато сильно выигрывает по времени. В онлайне всё конвертируется в GMV.
RecGPT-Mobile
Здесь on-device LLM используют, чтобы быстро понять изменения интента в рекомендательной ленте.
Допустим, пользователь внезапно начинает чаще кликать по компактным рюкзакам и добавлять их в избранное. Специальный модуль замечает изменение поведения и триггерит систему. Из залогированных на устройстве релевантных событий формируется промпт для on-device LLM, которая генерирует query под новый интент. Он отправляется в облако, где большая продовая система возвращает релевантные товары и обновляет ленту.
Чтобы всё это работало на устройстве, используют Qwen3-0.6B с квантизацией, берут не всю историю, а только полезный контекст и запускают систему не на каждый случайный клик, а только когда поведение действительно меняется.
В экспериментах LoRA обходит полный тюнинг модели, а квантизация теряет не так много качества. В месячном A/B-тесте получили +2,5% GMV на четырёх поверхностях.
@RecSysChannel
Разбор подготовила
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🔥9✍3👌1🤝1