OnePiece: Bringing Context Engineering and Reasoning to Industrial Cascade Ranking System [2/2]

Продолжаем разбор техрепорта от Shopee. Так чем же интересен reasoning?

Авторы берут hidden state из последнего блока backbone, подают на вход в декодер с блочно-каузальным attention. По словам авторов, блоки позволяют учитывать больше информации о каждом токене.

Блоки в итоге учатся на разные таски:
— Retrieval: binary-cross-entropy loss (будет клик или не будет, добавят товар в корзину или нет, купят ли) и bidirectional contrastive learning (симметричный User to Item и Item to User).
— Ranking: вместо BCL используют set contrastive learning на успешных случаях, чтобы расширить границы положительных и отрицательных исходов.

Для тренировки моделей авторы воспроизводят ежедневное онлайн-дообучение, которое ждёт систему в проде. Данные упорядочены между собой по дням, но внутри них семплы пошаффлены. Результат за каждый день сохраняется и оценивается по итогам следующего. Период данных для обучения — месяц.

Сделав вход модели более информативным, а также добавив многошаговый reasoning, авторы улучшили результаты работы модели. Внедрение нового фреймворка в основной сценарий персонализированного поиска помогло добиться +2% GMV/UU и +2,90% дохода от рекламы.

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

TBGRecall: A Generative Retrieval Model for E-commerce Recommendation Scenarios

Разбираем работу Alibaba, архитектурно напоминающую ARGUS, используемый в Рекламе Яндекса. Модель TBG Recall, описанная в статье, генерирует кандидатов для главной страницы Taobao, крупнейшего e-commerce-сервиса компании.

Во многих работах для рекомендаций применяются генеративные и последовательные модели, но они предполагают, что история пользователя — это строгая последовательность событий. В e-commerce всё иначе: пользователь делает запрос и получает «пачку» товаров, потом ещё одну — внутри таких пачек никакой упорядоченности нет, поэтому обычные sequence-based-подходы здесь работают не совсем корректно.

В качестве решения авторы вводят предсказание следующей сессии, где сессия понимается как один запрос пользователя. Модель учится предсказывать, какие товары пользователь увидит в следующей выдаче.Также в работе используют incremental training, чтобы регулярно обновлять модель на свежих данных без перерасхода GPU.

Архитектура

Как уже сказали, в основе TBGRecall — next session prediction: история пользователя кодируется в вектор и сравнивается с векторами кандидатов через ANN-индекс, как в классических двухбашенных моделях. Слово «генеративная» в названии относится не к инференсу, а к способу обучения — авторегрессионному.

В начале каждой сессии стоит контекстный токен — обобщённое описание запроса. При инференсе он формируется из текущего контекста пользователя и напрямую влияет на итоговый вектор, с которым рекомендательная система делает запрос в индекс. По нашим наблюдениям, контекстные токены дают почти двукратный прирост качества — особенно в сервисах вроде Поиска и Рекламы, где контекст крайне важен.

Кодирование и обучение

Каждое событие описывается набором признаков: Item ID, Action, SideInfo (ID продавца или категория), Context и Timestamp. Вход модели — сумма этих векторов. Сначала они проходят через tower-модули, а затем через HSTU-блоки. Для контекстных и айтемных токенов используются отдельные tower-модули — небольшие проекции, без которых качество падает (что совпадает с нашим опытом в ARGUS).

Основная схема обучения — session-wise autoregressive approach с маской внимания, которая не позволяет айтемам внутри одной сессии «видеть» друг друга. Также применяется session-wise ROPE (sw-ROPE) — позиционные эмбеддинги, нумерующие сессии. Мы пока не видели стабильного выигрыша от подобных схем, но идея любопытная.

Лосс состоит из трёх частей:
1. Lnce — воспроизводит логирующую политику, учит отличать реальные айтемы в сессии от случайных негативов.
2. Lclick — отличает кликнутые айтемы от показанных.
3. Lpay — отличает купленные от всех прочих.

Все три компоненты считаются по разным продуктовым сценариям и взвешиваются по числу сессий в них. Отдельного претрейна или fine-tune-фазы, как в ARGUS, нет — всё обучение проходит за один этап.

Инференс и результаты

В проде модель работает не в реальном времени: кандидаты пересчитываются асинхронно и обновляются с небольшой задержкой. Авторы считают, что контекст пользователя меняется нечасто, поэтому такая схема не вредит качеству.

На закрытом датасете (около 2 трлн записей) TBGRecall превзошёл собственный dual-tower baseline компании. В A/B-тестах модель показала +0,5% по числу транзакций и +2% по обороту. Новый кандидат-генератор теперь отвечает за 24% показов на поверхности Guess You Like — одной из ключевых страниц Taobao.

В целом, TBGRecall — это шаг от классической двухбашенной архитектуры к генеративному обучению. Контекстные токены дают сильный прирост, MoE и SW-ROPE работают стабильно, а near-line-инференс показывает себя лучше, чем ожидалось.

@RecSysChannel
Разбор подготовил ❣ Николай Савушкин

PLUM: Adapting Pre-trained Language Models for Industrial-scale Generative Recommendations

Сегодня разбираем совместную статью Google DeepMind и YouTube. Об этой работе было известно заранее — на конференции RecSys авторы проекта, включая Ed Chi и Lichan Hong, упоминали, что готовится статья о генеративных рекомендациях. Через пару недель после конференции она действительно вышла.

Исследование продолжает трек генеративных рекомендаций, заданный предыдущей работой авторов TIGER. На этот раз основная идея — использование предобученных больших языковых моделей в рекомендательных пайплайнах (в случае Google — это Gemini). Простая LLM из коробки не подходит: модель не знает ни о корпусе айтемов, ни о пользовательских поведенческих сценариях, что приводит к плохим результатам. Чтобы исправить это, команда предлагает фреймворк PLUM, включающий три стадии: item tokenization, continued pre-training и task-specific fine-tuning. Кратко разберём каждую из них.

1) Item tokenization. За основу взята работа TIGER. В ней семантические идентификаторы (SIDs) формировались через RQ-VAE поверх текстового описания товара (эксперименты были на открытых датасетах Amazon). В PLUM к этому подходу добавляют коллаборативный сигнал и мультимодальные контентные представления. Используются уже готовые аудио-, видео- и текстовые эмбеддинги YouTube, которые конкатенируются и проходят через энкодер RQ-VAE.

Новые предложенные компоненты:

— Multi-Resolution Codebooks: число идентификаторов в кодбуках уменьшается от слоя к слою, чтобы верхние уровни разделяли крупные семантические категории, а нижние — более гранулярные признаки.
— Progressive Masking: модель обучается восстанавливать не полный набор SIDs, а его префикс.

Ключевая вещь в архитектуре — дополнительный contrastive learning на RQ-VAE, который вводит коллаборативный сигнал прямо в процесс токенизации. Берутся пары айтемов, встречавшихся рядом в пользовательской истории как позитивные пары, обучается с помощью InfoNCE по батчу. Так коллаборативный сигнал тоже участвует в формировании кодбуков без отдельной стадии дообучения как, например, в OneRec. В итоге SIDs начинают отражать не только контентную информацию об айтемах, но и коллаборативные пользовательские связи между ними.

2) Continued Pre-Training (CPT). Здесь языковая модель дообучается с увеличенным словарём, в который, помимо изначальных токенов, встроены токены айтемов. Модель обучается на смешанной задаче (supervised + self-supervised). Цель этой стадии — заставить LLM встроить в общее семантическое пространство представления токенов и SIDs.

3) Task-Specific Fine-Tuning. Это полноценное обучение на задачу генеративного ретривала: модель предсказывает релевантные айтемы в пользовательских историях (обучение на next token prediction).

В целом идея PLUM строится на прямой аналогии между словами в языковых моделях и айтемами в RecSys: если в NLP слова токенизируются для работы с огромным словарём, то в рекомендациях можно аналогично токенизировать айтемы.

Эксперименты и результаты

Основная модель — Mixture-of-Experts с ~900 млн активных параметров (всего 4,2 млрд).

В онлайн-A/B-тестах PLUM показывает рост ключевых метрик: CTR и вовлечённости пользователей, особенно в коротких видео (YouTube Shorts). Аблейшены подтверждают, что важны все предложенные компоненты.

В работе показывают законы масштабирования для предложенного фреймворка: при увеличении размера моделей при разном фиксированном вычислительном бюджете ошибки на обучении и валидации снижаются, но самые большие модели (около 3 млрд активных параметров, 20 млрд всего) пока упираются в ограничения вычислительных ресурсов. Исследователям не хватило времени, данных и мощностей, чтобы хорошо обучить модели такого размера, однако инженеры считают, что при дальнейшем масштабировании качество может вырасти ещё больше.

Финальная PLUM-модель дообучается ежедневно на ~0,25 млрд примеров, тогда как предыдущие LEM (Large Embedding Models) подходы требовали многомиллиардных датасетов.

@RecSysChannel
Разбор подготовил ❣ Владимир Байкалов

Balancing Fine-tuning and RAG: A Hybrid Strategy for Dynamic LLM Recommendation Updates

Сегодня разберём статью от компании Google DeepMind, главный фокус которой в последнее время — LLM в рекомендациях. У рекомендательных моделей есть ряд преимуществ относительно более традиционных рексистем: богатое понимание мира, ризонинг, способность объяснять, почему был порекомендован тот или иной объект, и многое другое. Но это не отменяет слабые места, например, проблему динамики в интересах пользователей и корпусе айтемов. Именно этот аспект авторы разбирают в статье.

Эксперименты проводятся в YouTube Shorts. Авторы выясняют: нужно ли вообще обновлять рекомендательную LLM в таком домене, или со своим знанием мира она и так справится. Отвечают интересным экспериментом: кластеризуют тематики шортсов и по логам пользователей собирают тройки (c1, c2, c_next) кластеров, с которыми кто-то последовательно провзаимодействовал. Делают так отдельно для нескольких месяцев, после чего для всех пар (c1, c2) собирают топ-5 переходов в c_next для каждого месяца i: {c_next_1, …, c_next_5}_i. Далее для пар (c1, c2) считают IoU множеств переходов за соседние месяцы (i vs. i+1) и получают низкое значение 0,17, что подчеркивает высокую изменчивость паттернов пользователей во времени. Отсюда возникает необходимость постоянного обновления рекомендательной LLM.

В статье сравниваются два метода: fine-tuning и RAG. Первый обновляет веса модели через дообучение на новом трафике. Второй, грубо говоря, усиливает промпт недостающей информацией о пользователе и домене, при этом никак не влияет на саму модель.

Fine-tuning. Модель дообучается предсказывать следующий кластер, с которым провзаимодействовало большинство пользователей: (c_1, c_2, …, c_n) → c_{n+1}. Описания кластеров поступают в LLM в словесной форме. Из минусов метода — сложность, возможность переобучения и высокие вычислительные затраты. Из-за последнего дообучение происходит лишь ежемесячно.

RAG. Точно так же представляет историю в виде последних взаимодействий с кластерами (обновленные интересы пользователя), но ещё и добавляет в промпт наиболее популярное продолжение для этой последовательности взаимодействий (обновленные реалии домена). Поскольку множество всевозможных историй вида (c_1, c_2, …, c_k) невелико и конечно, инференс производится несколько раз в неделю, а предпосчитанные кандидаты для каждой истории достаются в реальном времени лукапом.

В офлайн-эксперименте проверяют, нужен ли RAG и стоит ли пересчитывать кандидатов раз в несколько дней. Оказывается, что на оба вопроса ответ положительный. В A/B-тесте отчитываются о приростах Satisfied User Outcomes, Satisfaction Rate и об уменьшении Dissatisfaction Rate и Negative Interaction.

@RecSysChannel
Разбор подготовил ❣ Сергей Макеев

OneTrans: Unified Feature Interaction and Sequence Modeling with One Transformer in Industrial Recommender

Сегодня разберём статью о OneTrans — нейросетевом ранкере от TikTok. Его можно было бы назвать аналогом HSTU от Meta* или TransAct от Pinterest, но ни на одну из этих работ авторы не ссылаются, упоминают только Wukong и RankMixer.

Исследователи называют свою разработку единой ранжирующей моделью в рамках каскадного рекомендательного стека, которая заменяет финальный ранкер за счёт того, что совмещает sequence-моделирование и взаимодействие признаков (feature interaction).

Классический подход к финальному ранжированию, ставший стандартом индустрии, обычно предполагает, что историю пользователя обрабатывают отдельно от обработки ручных счётчиков. Сначала входную последовательность событий пропускают через Sequence Modeling Block, где вытаскивают и сжимают информацию о пользователе, необходимую для построения рекомендаций. Потом сжатое представление попадает в Interaction-блок. Параллельно набор Non-Seq-фичей (например, ручные счëтчики) конкатенируют или каким-то другим способом подают в тот же Interaction-блок.

OneTrans одновременно моделирует и последовательные, и Non-Seq-входы внутри единой модели OneTrans. Архитектура ранкера — на схеме: последовательности (голубые блоки S на схеме) и non-seq (NS, оранжевые) айтемы токенизируют по отдельности. Блоки поведения пользователей разделяют специальными блоками [SEP], после чего единую последовательность подают на вход OneTrans Pyramid Stack. Внутри этой пирамиды последовательность S итеративно сжимают до тех пор, пока её длина не совпадёт с NS.

OneTrans Block — казуальный трансформер с RMSNorm, Mixed Causal Attention и Mixed FFN. Под Mixed авторы понимают смешанную параметризацию: у S-токенов общие QKV/FFN-матрицы, а каждый NS получает свои токен-специфичные веса.

По результатам экспериментов на индустриальных датасетах, OneTrans эффективно масштабируется с ростом параметров: систематиически обгоняет сильные бейзлайны и показывает рост на 5,68% per-user GMV в онлайн-A/B-тестах.

*Компания Meta, владеющая Instagram, признана экстремистской; её деятельность в России запрещена.

@RecSysChannel
Разбор подготовил ❣ Артём Матвеев

MiniOneRec: An Open-Source Framework for Scaling Generative Recommendation [1/2]

Сегодня начинаем разбирать неожиданно вышедшую статью MiniOneRec. В ней использованы подходы из нашумевшей серии техрепортов OneRec от Kuaishou. Авторы MiniOneRec — исследователи из университетов Китая и Сингапура — фактически берут ключевые идеи OneRec, переносят их в минимально жизнеспособный фреймворк и подтверждают, что они действительно работают на открытых данных. Это выглядит как попытка «повторить OneRec», но в академии и без доступа к приватным датасетам. И действительно, LLM-подходы в NLP работают слишком хорошо, чтобы не пытаться перенести их в другие домены — в том числе в рекомендации.

Семантические ID и подготовка данных

Первое препятствие, которое сразу появляется в рекомендациях, — огромный каталог документов. Нельзя просто взять LLM и обучить её поверх ID в десятки или сотни миллионов: embedding/de-embedding-слои и softmax станут непригодными. Поэтому MiniOneRec, как и OneRec, используют семантические ID из работы TIGER.

Суть простая: каждый документ кодируется короткой последовательностью токенов. Из исходного текста (название + описание) получают эмбеддинг: текст прогоняется через замороженную Qwen3-Embedding-4B, затем hidden states последнего слоя усредняются (mean pooling) в один вектор, который и подаётся в трёхуровневую RQ-VAE-кластеризацию. На каждом уровне отнимается ближайший из 256 центроид (получается semantic_id_0), формируется остаток, который проходит ту же процедуру кластеризации следующего уровня — в итоге документ получает трёхтокенную семантическую подпись. Это резко уменьшает словарь: вместо миллионов ID становится 3x256 дополнительных к словарю токенов. У Tiger и OneRec эта идея ключевая, и MiniOneRec полностью повторяет её.

Авторы также отмечают проблему коллапса кластеров (слишком много документов в одном кластере), поэтому в коде используют не случайную инициализацию, а RQ k-means из оригинального OneRec. Это увеличивает энтропию кластеров и улучшает токенизацию.

SFT и перенос NLP в рекомендации

После токенизации авторы делают SFT поверх предобученной LLM (берут Qwen). В случае с академией это более чем оправдано: экономятся ресурсы, не нужно тренировать архитектуру с нуля и сразу есть сильный старт. Истории пользователя подаются в виде последовательностей семантических токенов, а модель учится предсказывать следующий айтем.

В этот процесс также привносят новизну вида алайнмента между NLP и рекомендациями. Авторы подмешивают в обучение разные форматы примеров, с тем чтобы перенести world knowledge модели на новые токены.

Получается несколько типов задач:

- история на естественном языке — нужно предсказать следующий айтем в виде семантических токенов;

- история в виде семантических токенов — нужно предсказать текстовое описание следующего айтема;

- просто перевод айтема между двумя представлениями — из текста в семантические токены и наоборот.

Этот шаг даёт самый большой прирост качества. В аблейшенах видно, что это важнее, чем стартовать со случайных весов. Вместе с тем сама идея достаточно проста: смешивать рекомендации с задачами NLP, чтобы модель лучше экстраполировала знания. Это похоже на недавнюю работу от Google — PLUM, хотя авторы на неё не ссылаются (возможно результаты получены параллельно).

В следующей части обзора расскажем о RL-дообучении, масштабировании и результатах.

@RecSysChannel
Разбор подготовил ❣ Илья Мурзин

MiniOneRec: An Open-Source Framework for Scaling Generative Recommendation [2/2]

Завершаем разбор статьи MiniOneRec. В первой части обсуждали SFT и семантические ID, а теперь посмотрим, что происходит дальше: RL-дообучение, генерация траекторий и насколько авторы смогли воспроизвести индустриальные результаты на открытых данных.

RL-дообучение: GRPO и генерация траекторий

После SFT и алайнмента применяется reinforcement learning по аналогии с OneRec — используется GRPO. Модель уже умеет генерировать последовательности семантических токенов, каждая из которых соответствует айтему. Генерируются несколько траекторий (beam search или dynamic sampling), затем по каждой считается награда. Награда включает два компонента: корректность следующего айтема и ранжирование согласно frozen collaborative модели (SASRec в реализации авторов).

Чтобы модель генерировала только валидные токены, используется constrained beam search: логиты, не соответствующие существующим айтемам из кодбука, маскируются. То есть стратегия гарантирует, что каждая сгенерированная последовательность соответствует реальному айтему.

GRPO здесь в «ванильной» версии: есть ограничение на отклонение от начальной политики, чтобы избежать reward hacking — классического случая, когда модель накручивает награду, но начинает генерировать бесполезные последовательности.

Результаты и масштабирование

Авторы говорят о законе масштабирования: модели большего размера достигают лучшего качества (меньше лосс). Но есть важный момент: все модели обучаются одинаковое количество эпох на одном и том же датасете. Нет параметризации по количеству данных, а значит это не полноценный закон масштабирования, а скорее наблюдение: «большая модель лучше маленькой». С другой стороны, до этой работы таких результатов на открытых датасетах не было — и это важное подтверждение работоспособности индустриальных подходов вне Kuaishou.

В целом, MiniOneRec повторяет ключевые идеи OneRec — но делает это на открытых данных, с полностью доступным кодом и понятными экспериментами. Авторы аккуратно воспроизводят семантическую токенизацию Tiger, SFT поверх LLM, алайнмент между NLP и рекомендациями и RL-дообучение через GRPO. Это первая попытка показать, что индустриальные результаты действительно можно повторить за пределами приватных данных.

@RecSysChannel
Разбор подготовил ❣ Илья Мурзин

LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders

Сегодня разбираем статью от ByteDance, представленную на RecSys'25. Работа посвящена эффективным end-to-end-рекомендациям на GPU с использованием длинных пользовательских последовательностей (до 10 тыс. событий). Авторы рассматривают кейсы Douyin (китайского TikTok) — как в рекламе, так и в e-commerce.

Основная проблема длинных последовательностей — квадратичная сложность аттеншна по длине L. Авторы предлагают архитектуру LONGER, решающую эту задачу.

1) Token Merging. Рядом стоящие токены в истории группируются по K штук. Группировка выполняется либо простой конкатенацией, либо через лёгкий внутренний трансформер (InnerTrans). Это уменьшает эффективную длину последовательности с L до L/K. Для типичных настроек (L=2000, d=32) TokenMerge(K=4) снижает FLOPs аттеншна примерно на 40–50% при минимальной потере качества.

Авторы аккуратно разбирают TokenMerge и InnerTrans в ablation study:
— без Merge (L=2000): FLOPs ≈ 3,73e9;
— c Merge (K=8, concat, L=250): FLOPs ≈ 3,03e9, ΔAUC +1,58%, ΔLogLoss −3,48%;
— добавление InnerTrans даёт ещё небольшой, но устойчивый буст.

Таким образом, TokenMerge не только снижает вычислительные затраты, но и даёт буст по метрикам качества, в сравнении с ванильным вариантом.

2) Global Tokens. На вход подаётся конкатенация глобальных токенов и пользовательской истории. Глобальные токены играют роль «якорей» (User Profiles, Context & Cross Features).

3) Тонкости обучения. Dense- и sparse-параметры (огромные embedding-таблицы) находятся на GPU-кластере. Обучение в BF16/FP16, часть активаций не хранится, а пересчитывается на backward. На инференсе используется KV Cache Serving.

Эксперименты и результаты

В офлайне LONGER решает задачу предсказания conversion rate (CVR) на 5,2 млрд примеров (130 дней данных Douyin Ads) на кластере 48 × A100. По сравнению с базовым Transformer даёт +0,21% AUC и −0,39% LogLoss.

Онлайн A/B-тесты в Douyin Ads:
— Live Streaming: ADSS +1,06%, ADVV +1,17%
— Short Video: ADSS +2,10%, ADVV +2,15%
— Mall: ADSS +1,82%, ADVV +1,41%

Онлайн A/B-тесты в Douyin E-commerce:
— Live Streaming: Order/U +7,92%, GMV/U +6654%
— Short Video: Order/U +4,61%, GMV/U +5,28%

@RecSysChannel
Разбор подготовил ❣ Михаил Сёмин

GenSAR: Unified Generative Search and Recommendation

Сегодня разбираем статью от исследователей из Renmin University of China и Kuaishou Technology, представленную на RecSys'25. Работа посвящена объединённому моделированию поиска и рекомендаций с использованием генеративного подхода на основе больших языковых моделей.

Современные коммерческие платформы (e-commerce, видео, музыка) предлагают одновременно и поиск, и рекомендации. Совместное моделирование этих задач выглядит перспективно, однако авторы выявили ключевой trade-off: улучшение одной задачи часто приводит к деградации другой.

Причина кроется в различных информационных требованиях:

— Поиск фокусируется на семантической релевантности между запросами и айтемами — традиционные варианты поиска часто основаны на предобученных языковых моделях (BGE, BERT);
— Рекомендации сильно зависят от коллаборативных сигналов между пользователями и айтемами — ID-based-рекомендации дают отличные результаты.

GenSAR — унифицированный генеративный фреймворк для сбалансированного поиска и рекомендаций.

Для каждого айтема берутся два эмбеддинга: семантический (из текста) и коллаборативный (из user-item-взаимодействий). Оба прогоняются через отдельные MLP-энкодеры и приводятся к одной размерности, затем конкатенируются в общий вектор.

Объединённый вектор квантуется через общие кодбуки: на каждом уровне выбирается ближайший код, его индекс записывается в идентификатор, а сам код вычитается из текущего вектора. Накопленная последовательность — это shared prefix, содержащий общую информацию обоих эмбеддингов.

Далее остаточный вектор делится пополам. Одна половина подаётся в семантические кодбуки, другая — в коллаборативные. В итоге:

— Semantic ID (SID) = shared codes + semantic-specific codes;
— Collaborative ID (CID) = shared codes + collaborative-specific codes.

Лосс состоит из суммы:
1) Reconstruction loss: декодеры должны восстановить исходные эмбеддинги по кодам.
2) Loss for residual quantization: считается для трёх наборов кодбуков (shared, semantic, collaborative) и включает codebook loss + commitment loss для каждого.

Выход модели зависит от задачи:
- Рекомендации → CID (коллаборативный сигнал важнее);
- Поиск → SID (семантика важнее);
Модель различает задачи через task-specific-промпты. Обучение — joint training на смешанных батчах с балансировкой лоссов между задачами.

Оффлайн-эксперименты проводились на публичном датасете Amazon и коммерческом датасете Kuaishou. Сравнение с бейзлайнами: SASRec, TIGER (рекомендации), DPR, DSI (поиск), JSR и UniSAR (совместные модели).

На Amazon GenSAR показывает +12,9% по Recall@10 для рекомендаций и +12,8% для поиска относительно лучшего бейзлайна UniSAR. На коммерческом датасете Kuaishou прирост составляет +10,4% и +11,7% соответственно.

Ablation study подтверждает важность обоих компонентов:
— Без CID качество рекомендаций падает на 8,9%;
— Без SID качество поиска падает на 14,7%;
— Dual-ID подход даёт +12,7% к рекомендациям по сравнению с single-ID.

@RecSysChannel
Разбор подготовили ❣ Михаил Сёмин и Никита Мирошниченко