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

Generating Long Semantic IDs in Parallel for Recommendation

Генеративные модели с Semantic ID обычно используют короткие ID, например из четырёх токенов. Делают так, потому что авторегрессионная генерация длинных даёт высокую задержку и большой расход памяти. Но с короткими тоже есть проблема — они ощутимо ограничивают выразительность представления объектов.

В статье RPG предложили отказаться от авторегрессионной генерации и предсказывать все токены Semantic ID параллельно. Благодаря этому можно использовать длинные Semantic ID — до 64 токенов, и это ключевой вклад работы.

Но для параллельной генерации не очень подходят обычные Semantic ID на основе RQ. В RQ каждый следующий токен кодирует остаток после предыдущего, поэтому токены последовательно зависят друг от друга, а первые оказываются важнее последних. Вместо RQ авторы используют OPQ, который сначала преобразует item-вектор, а затем делит его на отдельно квантуемые подпространства. Поэтому токены получаются более независимыми и сбалансированными.

На обучении используется multi-token prediction loss. Модель параллельно предсказывает токены, а не сами товары, и для каждой позиции Semantic ID задан конкретный таргетный токен. Хотя генерация параллельная, позиции ID фиксированы — эквивалентность между разными комбинациями токенов на обучении не учитывается.

На инференсе возникает другая проблема. Независимо предсказанные токены могут сложиться в комбинацию, которой нет ни у одного реального айтема. Чтобы решить это, авторы используют graph-constrained decoding. Вершины графа соответствуют валидным Semantic ID реальных айтемов, а рёбра связывают похожие ID. Поиск проходит по этому графу и не требует полного перебора каталога.

Согласно приведённым результатам, RPG занимает первое место в 15 из 16 сравнений среди бейзлайнов. А по метрике NDCG@10 показывает в среднем относительный прирост 12,6% по сравнению с сильнейшим бейзлайном.

При этом в эксперименте на датасете Sports runtime GPU memory примерно в 25 раз ниже, а инференс почти в 15 раз быстрее относительно TIGER. При фиксированных параметрах декодирования время инференса и используемая GPU-память не зависят напрямую от числа айтемов. Однако полное хранилище, включая decoding graph и отображение айтемов в токены, растёт вместе с каталогом.

Отдельно авторы анализируют выразительность Semantic ID на энкодерах sentence-t5-base и text-embedding-3-large. Получается интересное: сильный энкодер сам по себе не гарантирует прирост. TIGER с коротким ID может потерять часть информации из хорошего эмбеддинга, тогда как RPG с длинным OPQ-ID лучше её сохраняет.

Абляции, которые в работе довольно подробные и убедительные, подтверждают, что отдельные части подхода работают именно вместе. При этом в целом статья пока выглядит скорее как исследование, чем как готовое продакшн-решение, потому что эксперименты проведены только на публичных Amazon-датасетах, production latency benchmark отсутствует, а обновление графа при изменении каталога не исследовано.

@RecSysChannel
Разбор подготовила ❣ Варвара Родионова

Три статьи на стыке 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
Разбор подготовила ❣ Екатерина Дмитриева

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

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 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
Разбор подготовил ❣ Илья Мурзин

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

Выкатили 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

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

Работы о рексистемах на 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
Интересное увидела ❣ Екатерина Дмитриева

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