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
Разбор подготовил❣ Александр Михеев
Обсудим небольшую статью от 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 — новый стандарт в индустрии? Есть нюансы:
Революция пока не произошла, хоть после поста в блоге Google и наблюдалась просадка рыночных котировок производителей полупроводников. Но, возможно, авторы смогут эти подходы усилить — и стоит ждать новых практических результатов.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16❤9👍9🕊1💯1
Работы о рексистемах на 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
Интересное увидела❣ Екатерина Дмитриева
На прошлой неделе в Мельбурне прошла конференция по исследованиям и разработке информационного поиска. Наша коллега Екатерина Дмитриева побывала в Австралии и рассказала о трёх работах, которые отражают основные тренды 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
Интересное увидела
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9❤6👌3💯2👍1
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
❤21🔥9👍6❤🔥4