AI Driver & RecSys 2026

Тренды.

• generative и sequential — два самых частых слова в названиях работ: у последовательных рекомендаций (sequential recommendation — предсказание следующего айтема по истории взаимодействий) около трети статей, генеративные за 1–2 года вышли вперёд и затрагивают примерно треть, по оценке спикера местами половину.
• Крупные компании (Google, Amazon, Alibaba и одна крупная соцсеть) в сумме дали около четверти всех статей; средняя команда — почти 10 авторов, в индустриальных статьях авторов больше, чем в академических, максимум — 28.
• Агенты вошли с двух сторон: как часть рекомендательного алгоритма и как потребитель рекомендаций. Второе меняет требования к выдаче: агенту-покупателю кликбейтная картинка товара не важна.
• Главный вопрос про LLM — экономика: окупается ли инференс приростом конверсии. Часть работ именно про то, как эти затраты сократить.

Где ломаются генеративные рекомендации.

• Токенизация: разбиение айтема на Semantic ID (идентификатор из обучаемого кодового словаря) может разрушать соседство похожих айтемов, при этом корректная токенизация сама по себе даёт прирост качества.
• Beam search (поиск по нескольким вариантам продолжения последовательности) удлиняет инференс, с этим надо что-то делать.
• Компрессия истории: при большом числе событий нужен способ сжать историю пользователя, иначе модель разрастается и занимает память. Отдельный кластер работ сдвигает фокус с последнего айтема (характерная особенность SASRec) на более раннюю историю.

Стоит ли переходить на Semantic ID. Плюсы: новый товар получает код сразу и попадает в рекомендации; код резко сокращает словарь, что критично на миллионах и миллиардах айтемов; коды нативно стыкуются с LLM. Минусы: коллизии — редкий товар получает тот же код, что популярный, и рекомендуется наравне с ним; коды не обновляются вместе с каталогом, дрифт требует переобучения; модель состоит из нескольких частей и сложнее в эксплуатации. Вывод спикера: Semantic ID оправдан в больших каталогах, средним и малым компаниям достаточно обычных последовательных моделей.

Числа из доклада.

• 2 из 41 работы по рекомендации лекарств воспроизводятся полностью, хотя код есть почти у всех.
• В обзоре по оценке рекомендаций команда Сбера упомянута среди 60 исследователей и команд с пятью и более статьями по теме — единственная российская.
• Best paper RecSys 26 — Disney: рекомендации как способ узнать о пользователе и закрыть долгосрочную цель, а не только поднять клики. Best student paper — про анализ длинной истории в генеративных рекомендациях на Semantic ID.
• RecSys Challenge: 20 треков плюс объяснение, объяснения оценивал LLM-судья; синтетические данные челленджа спикер назвал сомнительной идеей.

Что забрать. Токенизация Semantic ID — самостоятельный рычаг качества, а не деталь реализации: её варианты надо сравнивать при фиксированном рецепте обучения. Компрессия истории — кандидат в рычаг длины и окна последовательности. Требование воспроизводимости и проверки переноса офлайн-метрик в онлайн — гигиена офлайн-экспериментов, а не академическая формальность.

Оговорки. Доклад обзорный: собственных A/B-приростов в нём нет, все числа — доли и факты о корпусе RecSys 26, а не результат эксперимента.

Что показали.

• Зачем корпорации вкладываются в комьюнити: персональные данные, на которых учатся рекомендательные системы (recsys), — коммерческая тайна, поэтому экспертиза растёт внутри больших компаний, а академические результаты на открытых и синтетических данных «на практике не всегда повторяются»;
• доказать эффективность алгоритма в recsys без онлайн-теста нельзя, а промышленный A/B-контур есть только у крупных игроков — отсюда дефицит публично проверяемых результатов;
• кадры: максимально востребован стык NLP и recsys, потому что генеративные архитектуры идут через языковые модели; реже всего встречаются продуктологи персонализации;
• Никита Зелинский описал условия, без которых сильные не придут: интересная задача, готовая инфраструктура, собранные данные и продуктовая культура.

Метод.

• МТС Web Service в 2022 выложили датасет в open source, проводили соревнования и отдавали курсы по recsys — сигнал рынку, что есть продукт (KION), данные и инфраструктура; размер recsys-команды — около 40 человек;
• Сбер в Центре прикладного ИИ держит примерно 20% ресурсов в research и 80% во внедрение: внедрение дороже из-за «налога» большой корпорации;
• роль лидера переопределили: не «тот, кто знает больше команды», а тот, кто даёт контекст и удерживает цель, потому что технические решения теперь быстро собираются с LLM, а до прода доводятся единицы.

Числа.

• 20% и 80% — доли research и внедрения в Центре прикладного ИИ Сбера;
• 16–17% — доля выигрышных A/B-тестов в МТС Web Service, формулировка спикера: «один к семи, в лучшие годы к шести»;
• плюс 140% в A/B у команды рекомендаций коротких видео, тогда как у команды длинных видео значимых различий не было: блок длинных видео продукт убрал в низ страницы, продукт позже закрыли;
• около 40 человек — размер recsys-команды МТС Web Service.

Что забрать.

• Планка реальности для A/B: выигрывает примерно один тест из шести — это аргумент за конвейер экспериментов и предзарегистрированные критерии, а не за единичные запуски;
• слабая корреляция офлайн- и онлайн-метрик названа нерешённой задачей индустрии: рецепт офлайн-эксперимента без проверки переноса в онлайн ничего не гарантирует;
• продуктовый слой решает судьбу модели: одинаковое по качеству ранжирование даёт разный эффект в зависимости от места блока в интерфейсе, поэтому офлайн-метрика не описывает эффект без учёта точки показа.

Оговорки. Это пленарная дискуссия, а не технический доклад: архитектур, моделей и гиперпараметров в ней не было, все числа относятся к организации работы, а не к качеству рекомендаций. Точные метрики спикеры не раскрывали намеренно — вместо значений называли порядок величины («иксы»: двузначный или трёхзначный прирост).

Что показали.

• Классические системы путают намерение с интересом: детские песни для ребёнка утром становятся потоком детских треков, а покупка краски и инструментов — потоком шуруповёртов, хотя задача пользователя — ремонт квартиры;
• сигнал не равен интересу: покупка бывает подарком, разовая потребность (кроссовки перед походом) закрывается сразу, а лайки к року не значат, что стоит рекомендовать только рок;
• решение — семантический слой интерпретируемых знаний между историей пользователя и выдачей: интересы, намерения как цели и контекст.

Метод.

• Pinterest: история кластеризуется в задачу пользователя («выбрать новую кухню в фермерском стиле»), и после выбора фасада и плитки система рекомендует не похожее из истории, а то, что задачу завершает — светильники, барные стулья;
• Alibaba: memory hub из текстовых карточек о пользователе («интересен бадминтон»), обновляемых новой историей; агенты-эксперты по доменам (спорт, электроника) получают интересы и контекст (последние клики, просмотры) и формулируют намерение; генеративная модель отдаёт текстовые описания и семантические идентификаторы (semantic IDs) для поиска товаров;
• Google: из интерпретируемых интересов генерируются гипотезы — просмотр бенгальских сериалов даёт интервью с актёрами и похожие сериалы; по словам спикера, это сильно подняло метрики exploration (исследования нового в выдаче);
• Сбер: агент оценивает интересы пользователя и валидирует выдачу, потому что офлайн-метрики считаются относительно истории и плохо ловят разнообразие, новизну и discovery. Это проверка до A/B, но не замена A/B: точной копии человека агент не воспроизводит;
• электронная коммерция: оперировать не идентификаторами товаров, а текстовым описанием, которое расширяет LLM, и подавать его в трансформер вместо ID. Мыло в подарочной упаковке — подарок, куриный шашлык — история для пикника; LLM предлагает категории под выделенные интересы, они матчатся с каталогом — растут разнообразие и новизна, слабеет смещение в пользу популярного (popularity bias);
• развитие идеи — третья башня в двухбашенной архитектуре (two-tower): к башням пользователя и товара добавляется башня интересов. На момент доклада эксперимент шёл.

Числа. Точных метрик и A/B-приростов не называли: приросты от текстовых описаний и рост exploration у Google — без значений. Числовые утверждения доклада структурные: три модуля у Alibaba, три башни в Сбере.

Что забрать.

• Слой интересов приносит пользу без новой архитектуры: он подключается к работающей модели как правило формирования кандидатов и как фильтр заведомо неподходящего («нужна философская лирика, глубокое звучание» — русская попса исключается);
• он же закрывает три задачи: релевантность (не рекомендуем под закрытые потребности), разнообразие (ищем осознанно новое, а не похожее на историю) и адаптивность — сегодня поход, завтра ремонт;
• интересы и намерения подаются на вход генеративной модели, которая отдаёт описания и семантические идентификаторы: слой стыкуется с генеративными рекомендациями напрямую.

Оговорки. Внедрения Сбера описаны без чисел и архитектурных деталей: третья башня на момент доклада была экспериментом, эффект текстовых описаний назван качественно. Разобранные статьи — работы Pinterest, Alibaba и Google на их данных, автоматически не переносятся. Окончание доклада — тезис без развития: модель с большим контекстом отдаёт более релевантные товары семантическими ID.

Что показали.

• Рекомендательные системы учатся на взаимодействиях (клики, покупки), а часть каталога таких данных не имеет: контентная информация — фото, текст, аудио — есть у всех товаров;
• контентные эмбеддинги (content embeddings — вектор товара из его описания) есть у каждого товара, коллаборативные эмбеддинги (collaborative embeddings — вектор, выученный рекомендательной моделью по взаимодействиям) — только у «тёплых». Задача: восстановить коллаборативные эмбеддинги для товаров без кликов.

Метод.

• Наивный перенос «контент → коллаборативный» (линейная регрессия или MLP на парах эмбеддингов) работает плохо. Предлагается переносить не вектора, а структуру попарного сходства: похожесть контентных эмбеддингов переносится в коллаборативное пространство, а тёплые товары служат «мягкими якорями»;
• в основе — локально-линейное вложение (Local Linear Embedding, LLE) и предыдущая работа автора ImplicitSLIM, где та же схема применялась к кликовым данным. Шаг 1 — вычислить матрицу B, выражающую одни контентные эмбеддинги через другие; шаг 2 — при фиксированной B оптимизировать коллаборативные эмбеддинги так, чтобы выученные соотношения сохранились и не потерялась информация исходной матрицы. Коэффициенты регуляризации отдельно взвешивают тёплые и холодные товары;
• у обеих подзадач есть аналитические решения, но они требуют обращения матрицы «число товаров × число товаров». Подстановка решения первого шага во второй снимает это: сложность линейна по числу товаров, а обращать нужно матрицу размерности контентного эмбеддинга;
• предложенная модель называется Worm Propagation (по аналогии с Label Propagation, распространением меток): качество на уровне самой дорогой альтернативы, но матрица сходства хранится неявно.

Числа.

• Три гиперпараметра, итеративных операций нет: фиксированное число умножений низкоразмерных матриц;
• линейная сложность по времени и памяти относительно количества товаров: каталоги на миллионы позиций не проблема;
• все эксперименты на графике компромисса для второго датасета заняли меньше минуты суммарно: метод применяется к уже обученной модели, а базовой альтернативе нужно переобучение с нуля;
• точных значений метрик (recall, NDCG@k) не называли: качество описывалось качественно — не хуже ядерной регрессии (kernel regression) и лучше остальных базлайнов.

Что забрать.

• Регуляризация как рычаг: коэффициент, взвешивающий холодные и тёплые эмбеддинги, даёт управляемый трейд-офф (trade-off) между качеством на холодных позициях и общим качеством, а на графике Парето-фронт (Pareto frontier) целиком принадлежит предложенному методу;
• одно согласованное пространство: модель обучают и на холодные, и на тёплые эмбеддинги, поэтому метод улучшает качество и на тёплых позициях за счёт контентной информации. Если обновлять только холодные, метрики на холодных почти не растут;
• метод накладывается на уже обученную модель без переобучения — дешёвая проверка гипотезы «контентные эмбеддинги как инициализация» до смены архитектуры.

Оговорки. Доклад про один метод и в основном про один датасет: результаты обновления тёплых и холодных эмбеддингов на других датасетах, по словам спикера, не так хороши. Аппроксимация ядерной регрессии по Нюстрему (Nyström) роняет качество: модель перестаёт явно хранить исходные коллаборативные эмбеддинги обучения.

Что показали.

• Проблема — перекос в сторону популярного: 2% каталога собирают 40% всех взаимодействий, новые айтемы без пуш-маркетинга и ручных эвристик наверх не выходят.
• Решение — полностью семантическая модель: в неё подаются эмбеддинги описаний, а не идентификаторы. Каталог KION небольшой, около 5000 айтемов, поэтому взяли UniSRec-like подход без RQ-VAE (residual-quantized VAE — модель, дискретизирующая описания в Semantic ID): выигрыша от дискретизации при малом каталоге не ожидали.
• Семантику усилили претрейном на открытых данных: описания приводятся LLM к одному формату (английский), векторизуются Qwen и подаются в модель наравне с описаниями своего каталога — модель не различает, на чьи айтемы смотрит. Новый айтем рекомендуется сразу, без логов, тогда как в ID-модели он не рекомендовался до первых взаимодействий.
• Претрейн не отменяет дебайасинг: даже с перенесёнными знаниями модель быстро сходится к популярному, как обычная ID-модель, поэтому сверху добавили регуляризацию IPW (inverse propensity weighting — обратное взвешивание по склонности) с небольшим весом.
• Лифт на непопулярных айтемах: 4–5% без претрейна и около 11% с претрейном. Какая часть прироста от претрейна, а какая от дебайасинга, пока не разделено — проверять в A/B.

Метод.

• Отличия от оригинальной UniSRec: в адаптере mixture-of-experts (MoE, смесь экспертов) добавлена нелинейность (в оригинале он почти раскладывается в линейную сумму, кроме softmax-роутера), а whitening (выбеливание входных эмбеддингов) вынесен за пределы MoE.
• Трубка претрейна: описание айтема, LLM-унификация, эмбеддинг Qwen, UniSRec; вектор на выходе — в том же семантическом пространстве, что у открытых датасетов. Маленькая и большая версии эмбеддера отличаются на i2i-задачах, на рекомендациях — мало.
• Файнтюн: MoE обучают медленнее трансформера, чтобы не перезаписать пространство претрейна; whitening морозили и обучали — при обучении небольшой прирост.
• Открытые данные: MovieLens-32M плюс Amazon, Goodreads, H&M и другие, около 15 датасетов. Домены не пересекаются (e-com, книги, фильмы, игры), плотные забирают градиент, описания унифицируются через LLM.

Числа.

• 2% каталога — 40% взаимодействий, 13% каталога — 80%; около 5000 айтемов в KION;
• в наборе Amazon порядка 12 млн айтемов, LLM-унификация такого объёма описаний «накладна»;
• zero-shot на KION лучше семантического KNN-байзлайна на 50–60%; сам KNN в 10 раз хуже SASRec и в 10 раз лучше случайного, на открытых бенчмарках качество на уровне SASRec;
• к 20 эпохам файнтюна первые слои сохраняются, последние блоки и выход переобучаются под свой каталог.

Что забрать.

• Переход от ID к эмбеддингам описаний снимает холодный старт без отдельного решателя: новому айтему достаточно описания — аргумент и для семантического этапа с Semantic ID;
• «претрейн не спасает от перекоса популярного» — дебайасинг нужен поверх любой архитектуры, включая семантическую;
• дисциплина сравнения: zero-shot мерили против случайного и семантического KNN, ориентиром называли уровень SASRec.

Оговорки. A/B-тестов нет: лифт на непопулярных — офлайн-замер, и мерить это надо в A/B. Вклад факторов не разделён — рост разнообразия может идти и от семантики с претрейном, и от IPW. Значений recall@k, NDCG@k не называли. RQ-VAE не пробовали из-за малого каталога — на большой каталог вывод «кодбук не нужен» не переносится.

Что показали.

• Проверяли гипотезу «один эмбеддинг пользователя на все downstream-задачи» (downstream — прикладные задачи поверх представления). Стенд — 12 датасетов: транзакционные, рекомендательные, временные ряды, текст.
• Регрессия и прогноз: почти все методы предсказывают будущее плохо. Исключение — next token prediction (предсказание следующего токена): он обучен смотреть вперёд, тогда как контрастивные методы (contrastive learning — обучение на сходстве аугментаций одного фрагмента) работают локально и в будущее не заглядывают.
• Валидационный лосс самообучаемых представлений (SSL, self-supervised learning) не коррелирует с downstream-качеством. Единой метрики «эмбеддинг хорош для всех задач» нет: взвешенная сумма по пяти задачам разваливается, как только приходит шестая.
• Способ оценки вносит смещение: на одних и тех же эмбеддингах разные downstream-модели дают разный ранг методов. LightGBM (градиентный бустинг над деревьями) лучше всех в среднем и на классификации, MLP — на прогнозе, LightGBM — на регрессии, логистическая регрессия — на поиске аномалий.
• Агрегация истории меняет результат: для прогноза лучше последний токен, для классификации и поиска аномалий — усреднение по всем токенам.
• Объединение эмбеддингов разных энкодеров конкатенацией раздувает размерность и не всегда даёт прирост; снижение размерности тензорными методами спикер назвал рабочим направлением, но не исследовал.

Метод. Перебор гиперпараметров (Optuna) в двух точках — первые 10 трайлов, то есть почти случайные параметры, и последние, устоявшиеся; ранг методов от этого не меняется. Эмбеддинги оценивали тремя downstream-моделями. Спектральные метрики качества представлений (собственные числа, взаимная информация) проверяли отдельно: «работает, но уровень шума большой».

Числа.

• 12 датасетов и 4 типа задач (классификация, регрессия, прогноз, поиск аномалий) — стенд бенчмарка;
• первые 10 и последние 10 трайлов Optuna — два режима отбора гиперпараметров;
• вместо значений метрик — ранги методов с учётом статистической значимости: числа лежат в проекте, ссылка на который давалась по QR-коду.

Что забрать.

• Отбор чекпоинта предобучения по валидационному лоссу SSL не годится: лосс не коррелирует с прикладными метриками;
• оценка представления одной моделью и одной метрикой даёт смещение — вывод стоит проверять несколькими приёмниками;
• агрегация последовательности (последний токен против усреднения) — самостоятельный рычаг: ранги методов на разных задачах расходятся;
• «одно представление на всё» плохо стыкуется с отсутствием единого обжекива (objective — целевая функция): оптимизация под сегодняшние задачи не гарантирует перенос на новые.

Оговорки. Значения метрик не называли: спикер сказал, что результаты «плюс-минус очевидные», а числа — в проекте по QR-коду. Рекомендательная задача здесь одна из четырёх: отдельного замера на последовательных рекомендациях с recall@k и NDCG@k не было. Вопрос из зала «чем это лучше таблицы признаков по клиентам» числового ответа не получил — ответ был «всё зависит от задачи»; один из байзлайнов — TSFresh (автогенерация признаков временного ряда).

Что показали. Рамка — эссе The Bitter Lesson (Ричард Саттон, 2019): эксперты усложняют существующий стек, а затем более общее знание вытесняет это усложнение. Аналогия с policy iteration: представление пользователя — это policy evaluation (оценка состояния), ранкер — policy improvement. Первый шаг — собрать все продукты в одну «суперисторию» пользователя и прогнать её через трансформерный энкодер, получив компактное представление рядом с признаками объекта. Наивная единая модель на всех данных не пошла: лоссы осциллируют, градиенты нестабильны, в A/B модель непригодна. Дальше — цепочка уточнений: предобработка признаков, разделение на многоголовое предсказание фидбэков и learn-to-rank (LTR, обучение ранжированию), кросс-признаки, место пользовательского представления в архитектуре. Итог внедрён в VK Клипах и VK Видео.

Метод.

• ID-признаки подаются через хэшированные эмбеддинги, числовые — через нормализацию выпуклой комбинацией бакетов: масштабы несопоставимы, счётчики доходят до 200 млн;
• многоголовое предсказание: отдельные головы под лайк, дизлайк и время просмотра; для времени предсказывается всё распределение, а статистики (медиана, матожидание) берутся из него;
• кросс-признаки: выбран DCNv2 (низкоранговое произведение признаков), внимание отдано части, работающей с историей пользователя; в DCNv2 добавлено слагаемое, без которого не моделируются признаки вида «доля», то есть деление;
• представление пользователя из энкодера ставится перед головами фидбэков, а ранкер связан с головами структурно, но не градиентами — градиенты после предсказаний голов останавливаются.

Числа.

• Синтетическая задача на 12 признаках (клики, показы и 10 шумных значений, цель — доля кликов от показов): DCN не сходится к оптимуму ни при каком тюнинге, вариант с добавленным слагаемым сходится; в проде это позволило отказаться от вычисляемых признаков с делением;
• двухстадийная модель без многоголовой части заняла первое место с конца: бустинг её превосходит, потому что комбинацию сигналов в одно число эксперты подбирали годами, а отдельные бустинги на каждую поверхность уже проигрывают многоголовой нейросети;
• сквозное обучение с градиентами от итогового скора ухудшило и головы, и финальный скор: сведение фидбэков в одно число сообщает модели, что лайк в разы важнее времени просмотра, и голова времени деградирует;
• внедрение: плюс 5,5% общего времени просмотра в VK Клипах и плюс 6% на поверхности VK Видео.

Что забрать. Разделять «признаки объекта» и «представление пользователя»: подстановка истории в признаковое пространство дала результат хуже, чем полный отказ от неё, — индуктивный сдвиг в сторону попадания в историю; работающее место — перед головами фидбэков. Объединение нескольких фидбэков в один скор — отдельная задача обучения: сквозные градиенты от LTR и равновесный подход через кривую Парето (Pareto frontier, кривая компромисса между метриками) провалились, сработало разделение обучения с остановкой градиентов. Предсказание полного распределения непрерывной цели вместо её статистики переносится на любую регрессионную цель.

Оговорки. Офлайн-метрик вида NDCG@k не называли; 5,5% и 6% — A/B-замеры на своих поверхностях. Часть архитектур отброшена не по качеству, а по скорости: решение работает в рантайме.

Что показали. Бенчмарк для контекстных рекомендаций: он отделяет переходы, которые модель уверенно предсказывает по истории, от сложных эпизодов, где одной истории не хватает, и измеряет, сколько полезного сигнала даёт текстовое описание ситуации. Стандартные метрики ранжирования усредняют лёгкие и трудные переходы вместе, поэтому вклад контекста в них теряется. Схема замера парная: один и тот же пользователь прогоняется через модель дважды — без контекста и с контекстом — и два ранжирования сравниваются по DCG и recall. Такой замер ловит не только пользу контекста, но и вред: контекст может ухудшать выдачу, и это тоже результат.

Метод. Стенд собран на MovieLens-25M с 5-core фильтрацией (не менее 5 взаимодействий у пользователя и у айтема). Два сценария: observed — реальные переходы из логов, которые коллаборативная модель не угадывает (пользователь смотрел триллеры и боевики, а затем включил семейный фильм); neighbor — синтетические, где ищутся пользователи с похожей историей, но разошедшимся следующим айтемом, и этот айтем подставляется в историю целевого пользователя. Контекст («к пользователю приехали племянники») генерирует языковая модель по истории, метаданным и тегам целевого фильма, без названия и описания — чтобы не подсказать модели ответ. Эпизоды разбиты на train и test, поэтому сетап воспроизводим.

Числа. Около 27 тысяч эпизодов в сценарии observed и порядка 13 тысяч в neighbor. Все семейства моделей получили прирост от контекста; лучший результат — у CARCA (вариант SASRec с кросс-вниманием, подмешивающий контекст в эмбеддинги айтемов): четырёхкратный прирост по метрикам. Контрольный опыт: если подставить каждому эпизоду контекст другого, случайного эпизода, почти все модели падают ниже байзлайна без истории — то есть контекст несёт реальный сигнал, а не работает дополнительной регуляризацией.

Что забрать.

• Парный протокол «с контекстом против без контекста» на одной модели — дешёвый способ измерить вклад любого текстового сигнала (описания айтема, LLM-признаков, ситуации) отдельно от архитектуры;
• перемешивание контекста — готовый контроль на версию «текст помогает только как регуляризация», его стоит держать в наборе абляций;
• оценка на срезе трудных переходов, а не на всём трафике: тот же принцип, что при разборе качества по классам айтемов.

Оговорки. Эпизоды neighbor синтетические, а в observed ситуация восстанавливается задним числом по уже случившемуся переходу — это проверка гипотезы, а не онлайн-эффект. Датасет — фильмы, домен e-commerce авторы только планируют проверить. Правдоподобность сгенерированных ситуаций проверяли опросом: в observed 40% респондентов сочли контекст возможным в реальной жизни, в neighbor 46,7%, ещё около 20% затруднились с ответом, а оценки разных людей сильно расходились; LLM-судья давал 50–60% в зависимости от модели. A/B-тестов и онлайн-метрик в докладе не было.

Что показали.

• LLM-ассистент WOW-поиск в приложении Самоката в реалтайм обычного поиска не влезает: 200–300 мс до первого токена, ответ в среднем до 5 с, поэтому выбрана офлайн-генерация;
• конвейер: аналитика заранее отбирает запросы с низкими позициями добавлений из обычного поиска, LLM генерирует идеи подборок и поисковые запросы, товары добираются обычным поиском по каждому ЦФЗ (CFZ, darkstore — склад, с которого курьер везёт заказ), фильтруются и сохраняются в Dragonfly DB, хранилище, совместимое с Redis;
• генерация идёт не по всем складам: ассортименты различаются на порядок, поэтому склады кластеризуются по составу ассортимента;
• запуск — середина сентября 2026, A/B-тест закончился 14.10.2026; результаты на момент доклада считались, часть срезов выигрывает, часть нет;
• спикер отдельно оговорил, что доклад про поисковую врезку, а не про рекомендательную модель.

Метод.

• Кластеризация складов: MinHash (хэш-схема для оценки близости множеств) даёт Jaccard-близость из коробки, из неё на уровне множеств считается containment — вложенность одного ассортимента в другой; в кластере берётся центроид и минимальное покрытие, кластеры сразу легли по регионам (Поволжье, Москва большими и малыми складами, Сибирь);
• стек минимальный: Airflow и файлы на S3, без брокеров сообщений, реализация — 1–1,5 месяца небольшой командой;
• врезка отделена от ассистента: у ассистента контекст 10–16 тыс. токенов и большой KV-кэш (кэш ключей и значений механизма внимания), для нерелевантных запросов стоит блок антифрода с LLM-классификатором; малая модель около 0,8B по качеству заметно уступает большой, на которой делалась офлайн-генерация.

Числа.

• 200–300 мс до первого токена и до 5 с на ответ ассистента;
• 50 000–300 000 уникальных товаров в ассортименте одного склада — отсюда кластеризация вместо перебора пар;
• внутренние бенчмарки врезки на точные совпадения по ассоциированным товарам: 0,9 плюс, что ожидаемо, поскольку врезка всегда генерирует ассоциированные товары;
• приростов из A/B в докладе нет: тест закончился за три дня до выступления, результаты ещё считались.

Что забрать. Офлайн-генерация снимает бюджет задержки: тяжёлая LLM работает вне критического пути запроса, а онлайн получает только готовый результат — схема переносима туда, где генеративная модель не успевает в продовый таймаут. Кластеризация каталога через MinHash и containment дешева, не требует разметки и сжимает региональную специфику. Стек из планировщика, объектного хранилища и Redis-совместимой базы достаточен для врезки, обслуживающей тысячи складов.

Оговорки. Офлайн-метрик ранжирования (NDCG@k, recall@k) не называли, 0,9 — внутренний бенчмарк на точные совпадения, а не качество ранжирования. Число 2500 спикер назвал с оговоркой, что не должен был, и в записи не привязано к объекту, поэтому здесь не приводится.

Что показали.

• Задача из двух сценариев: выбрать гиперпараметры, архитектуру и лучший чекпоинт обучаемого эмбеддера и понять, как готовые эмбеддинги поведут себя там, где разметки нет (out-of-time в банковских данных, out-of-domain в изображениях), не подгоняя обучение под конечную задачу;
• существующие безразметочные метрики опираются на линейную структуру, то есть на ковариационную матрицу, — это грубая характеристика, реальные данные сложнее;
• первая характеристика — кластерная структура на разных масштабах, через фильтрацию Виеториса–Рипса (Vietoris–Rips filtration, топологический анализ данных);
• вторая — нелинейное отображение между двумя наборами эмбеддингов на одних и тех же объектах, которое приближается локальными линейными отображениями;
• обе проверены на финансовых данных и на поведении пользователей онлайн-платформ; спикер называет результат прокси-оценкой качества, а не метрикой в математическом смысле.

Метод.

• Фильтрация Виеториса–Рипса: порог евклидова расстояния растёт от нуля до максимального, считается число связных компонент на каждом пороге, времена жизни компонент суммируются и нормируются на максимальное расстояние; характеристика растёт с внутренней размерностью набора и падает при анизотропии, то есть вытянутости от формы шара;
• сравнение наборов: спектр локальных матриц отображения агрегируется по всем точкам, поэтому характеристика предсказывает не абсолютное качество, а разницу качеств двух наборов — отвечает на вопрос «какой набор лучше»;
• правило из экспериментов — брать локальную характеристику вместо глобальной; лучшая функция спектра (например, эффективный ранг) зависит от датасета; сложнее всего сравнение эмбеддингов из разных семейств датасетов, в докладе — плохо на vision-трансформерах.

Числа. Конкретных значений не называли: сравнение шло по доле пар, где правильно определён лучший из двух наборов, и по глобальной корреляции с качеством. Итог сформулирован качественно — предлагаемые характеристики превосходят метрики на ковариационной матрице по большинству датасетов, задач и характеристик качества, в том числе на данных финансовой сферы и рекомендательных систем; в презентацию вошла не вся таблица статьи.

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

Оговорки. Численных результатов и таблиц в докладе не было. Доклад объединяет две статьи: одна уже доложена, вторая готовится.

Что показали.

• Главная — почти 55% всех просмотров и около 35% контактов сервиса; архитектура трёхстадийная: отбор кандидатов с векторными конгенами, ранжирование, блендер;
• генеративная модель (в программе конференции — ???Rec) встроена как дополнительный источник, а не замена векторного поиска: она даёт сигнал в существующие рекомендации и повышает разнообразие;
• в A/B выросли контакты с новых объявлений и контакты из истории: модель сама подмешивает ранее просмотренные айтемы;
• генератор запускался на претрейне, без файнтюна; вывод спикера — генеративная модель не серебряная пуля, а дополнительный сигнал.

Метод.

• Три компонента: векторизация объявления, семантические идентификаторы (RQ-kmeans, кластеризация остатков, как в RQ-VAE) и генератор-декодер LLaMA, обученный с нуля; айтемы достаются из индекса по предсказанным семантикам;
• что завело наивный сетап: токен локации (для услуг локация критична и дала наибольший скачок) и токен типа события; плюс псевдолейблинг типа события на инференсе — в историю подставляется токен просмотра (forced decoding), токен «избранное» давал хуже;
• индекс на Redis: прямой (айтем — комбинации префиксов его семантиков с учётом иерархии) и обратный (префикс — айтемы); инференс — TensorRT-LLM (TRT-LLM) под Triton с группировкой историй в батчи и переиспользованием KV-кэша; кластеризацию переписали с FAISS на PyTorch;
• управление разнообразием: сэмплирование семантиков (20 хуже 10 — топ забивается однотипными), добор айтемов из бимов и ширина поиска до 120 бимов; временные признаки — разница времени между событиями в 6 диапазонах.

Числа.

• Накопленный аплифт на финальной метрике: токен локации дал наибольший скачок, с токеном типа события — до 68%;
• инференс: 42 тыс. запросов в минуту на одной GPU, 85 событий истории, 80 бимов, глубина генерации 5 токенов — 50 мс генерация и 10 мс индекс Redis, около 60 мс полный цикл; TRT-LLM срезал задержку примерно в 4 раза;
• продовая конфигурация RQ — 4 уровня по 1024 на 5 млн векторов; варианты 3×8000 и 16000 — прирост или паритет; на малых размерах Qwen уступал LLaMA, на размере M — паритет.

Что забрать.

• Генеративный ретривал заводится как добавка и без файнтюна: ранжирующую модель не переобучали, генеративный источник сам поднял объявления из истории;
• иерархия семантических идентификаторов требует хранить префиксы: прямой плюс обратный индекс на Redis zset достают айтемы за 10 мс;
• дешёвые приёмы, дающие метрику: токен локации, токен типа события, псевдолейблинг токена события на инференсе, добор айтемов из бимов.

Оговорки.

• Часть выводов — относительные приросты без абсолютных значений; финальную таблицу со всеми улучшениями не собирали, модель со всеми изменениями не обучена;
• деньги на генеративный сценарий напрямую не замеряли: смотрят GMV, стоимость собственного железа не оценивали;
• обучение сразу на все вертикали работает, но даёт метрики немного хуже эксперта по одной вертикали.

Что показали.

• Путь к нейроранкеру занял два года: первая попытка завести DCN (Deep & Cross Network) в продукте кэшбэков просадила бизнес-метрики в A/B, вторая дала серый результат, и только третья, в ленте рекомендаций постов для инвесторов, заменила бустинг;
• прирост дали не архитектурные надстройки: расширение DCN в глубину и ширину и GDCN офлайн-метрики не улучшили, а сработали кодирование признаков, лоссы и настройка обучения;
• Perseus решает обратную задачу: собрать много типов событий (транзакции, кэшбэк, покупки в приложении) в одной последовательной модели;
• библиотеки используются вместе: Perseus генерирует кандидатов и эмбеддинги айтемов, их ранжирует DCN-ранкер из scikit-rank.

Метод.

• Сработавшие приёмы: активация SiLU, низкоранговое разложение, модификации AdamW, лоссы от BPR и LambdaRank до ранее не использовавшихся в команде, мультихэш и PLR-кодирование числовых признаков, векторы пользователя и айтема из трансформеров;
• scikit-rank: установка через pip, замена LightGBM-ранкера на DCN-ранкер, указание лосса и энкодера признаков, обучение через fit; внутри DCNv2 и FunnelNet, энкодеры чисел PLE, PLR и квантильная нормализация, около 20 лоссов для ранжирования, регрессии и классификации, вход NumPy, Pandas и Polars, обучение на нескольких GPU;
• Perseus: конфигурация только через YAML — тип задачи (генерация кандидатов, ранжирование, классификация, регрессия) и колонки признаков; энкодеры текста, чисел и категорий; бэкбоны от BERT и ModernBERT до HSTU и Mamba; контекстные признаки уровня пользователя и айтема.

Числа.

• Офлайн на трёх внутренних доменах: на доставке продуктов паритет с бустингом (домен считался сложным из-за повторных покупок), на двух других приросты 7,3% и 5,6%;
• комбинация Perseus и DCN-ранкера вместо бустинга на домене ритейла — плюс 1% против плюс 0,3% у одного DCN;
• Perseus на открытых данных: NDCG улучшен на 7 датасетах из 7, на 6 из 7 модель лучше бейзлайнов SASRec и BERT4Rec, в одинаковом сетапе — на их уровне;
• абляции на датасете Yambda: обучение только на идентификаторах айтемов, затем добавление признаков, затем добавление новых типов событий — почти двукратный прирост;
• кросс-доменность: добавление трёх доменов к двум обучающим дало дополнительный прирост, всё — правками конфига в несколько строк.

Что забрать.

• Порядок работ: сначала лоссы, кодирование признаков и оптимизатор, только потом архитектура — усложнение DCN прироста не дало;
• интерфейс в стиле scikit-learn резко снижает цену проверки нейроранкера: модель меняется в существующем пайплайне без переписывания кода;
• сигнал из типов событий, не совпадающих с целевым: почти двукратный офлайн-прирост в абляции на Yambda;
• обе библиотеки открыты на GitHub вместе со статьёй о сетапе экспериментов.

Оговорки.

• Perseus не рассчитан на онлайн-инференс: заявлены офлайн и near-time, для онлайн спикер советует бустинг и DCN;
• библиотека работает только с последовательными данными, графы знаний не подключаются; она не заменяет multilevel ranking и не решает качество данных;
• сравнения с ансамблями CatBoost и LightGBM не проводились: сравнение шло с самой сильной продовой моделью продуктовой команды;
• часть офлайн-приростов названа без указания метрики, по которой они измерены.

Что показали.

• Нейросетевой ранжировщик заменяет ранжировщик на градиентном бустинге в бесконечной музыкальной выдаче: кандидатов по-прежнему даёт двухбашенная модель (two-tower), меняется только этап ранжирования;
• мотивация: не нужны ручные признаки; модель работает с последовательностью событий, а не агрегатами; возможно раннее связывание кандидата с историей;
• сигналы заданы явно: позитив — полное прослушивание и лайк, негатив — скип (skip); свойства выдачи формирует связка модели, таргета, негативов и функций потерь, а не один блок;
• офлайн-метрики относительно two-tower выросли, при этом популярность выдачи снизилась: рост не объясняется уходом в популярные треки;
• A/B-тест в активной фазе, изменения идут пакетом: метрика ATC (аббревиатура из записи, расшифровки спикер не давал) выросла, skip rate снизился, listen rate и like rate выросли, поднялась фрешность рекомендаций.

Метод.

• Два этапа обучения: сначала two-tower на Next Item Prediction с сэмплированной кросс-энтропией и большим числом негативов (позднее связывание, ранжирует весь каталог на инференсе), затем ранжировщик в отдельном out-of-time интервале;
• протокол воспроизводит прод: случайные брейкпоинты на пользователя; события до брейкпоинта — входные истории для two-tower и ранжировщика, после — позитивные и негативные таргеты; к кандидатам применяются те же бизнес-правила, что в проде;
• вход ранжировщика: кандидаты, короткая и длинная история (отдельные унифицированные блоки), фидбэк по треку и таймстемпы; в блоках self-attention, затем target attention, где query — эмбеддинг кандидата, поэтому кандидат цепляется за разные участки истории, а не только за последние события;
• представления треков переносятся из two-tower (transfer learning), дообучаются на низком learning rate и смешиваются с типом события: один трек получает разный эмбеддинг в зависимости от прослушивания или скипа;
• время — интервал между каждым событием и точкой рекомендации плюс интервалы между соседними событиями, всё обучаемые эмбеддинги временных бакетов; ранг из two-tower подаётся бакетированным с rank dropout, чтобы развязать генератор и ранжировщик;
• голова с двумя выходами: ранжирование (мультипозитивная взвешенная кросс-энтропия в listwise-варианте) и тип фидбэка (binary cross entropy), итоговый лосс — сумма с коэффициентом, подобранным на валидации;
• дебайасинг негативами: популярные треки чаще попадают в таргет, коротким легче пройти порог прослушивания; негативы по популярным и коротким айтемам берутся из распределения выдачи two-tower, а по скипам — того же жанра и артиста.

Числа.

• Абсолютных значений офлайн-метрик не называли: показаны приросты относительно two-tower без чисел и снижение популярности выдачи;
• A/B в активной фазе, поэтому вместо процентов — направления изменений (ATC вверх, skip rate вниз);
• метрики протокола: NDCG+ (будущие позитивы в топ-k), NDCG− (будущие негативы из топ-k, чем меньше, тем лучше), User ROC AUC (позитив выше негатива), плюс популярность и разнообразие выдачи;
• в голове два выхода и две функции потерь.

Что забрать.

• Пара NDCG+ и NDCG− разделяет «подняли релевантное» и «перестали показывать нерелевантное»;
• дебайасинг негативами из распределения кандидатов работает против шортката популярности и против позитивов, проходящих порог события лишь из-за малой длительности айтема;
• тест на свойства выдачи: прирост ранжирующих метрик должен идти вместе со снижением популярности.

Оговорки.

• Численных приростов ни в офлайне, ни в A/B доклад не содержит — только направления;
• скип спикер не считает жёстким негативом и не использует как фильтр; текущая схема названа простой, работа продолжается;
• рост фрешности рекомендаций спикер сам не относит однозначно к позитиву.

Что показали.

• Инференс генеративной рекомендательной модели по семантическим идентификаторам (semantic IDs) ускорен на CPU: медианная задержка одного запроса снижена с 300 мс до 120–125 мс;
• beam search в генеративной схеме не даёт того, что даёт каскад с дешёвым кандидат-генератором (двухбашенная модель выдаёт тысячи кандидатов за миллисекунды почти бесплатно): тысячи кандидатов генерацией набрать нельзя, поэтому бизнес-ограничения перенесены внутрь генерации;
• фильтрация на последнем шаге оказалась плохой: при ограниченном каталоге и ограниченном стартовом числе бимов большая часть бимов не выживает. При пошаговой фильтрации выживает больше бимов, а доля отфильтрованных айтемов в экспериментах практически нулевая — второй круг по выдаче почти не нужен;
• если кандидатов всё же не хватило, второй круг обходится почти бесплатно — переиспользованием KV-кэша (кэш ключей и значений внимания).

Метод.

• Стек — библиотека transformers поверх PyTorch. Критерий выбора не только скорость на CPU, но и сочетание beam search с кастомными логит-процессорами (logit processors), которого нет у большинства фреймворков; ближайшая альтернатива ORT GenAI не прошла их тесты;
• логит-процессор маскирует запрещённые токены на каждом шаге генерации. Для whitelist (разрешённый каталог) решение эффективно: каталог предфильтруется, префиксы семантических ID сравниваются бинарным поиском — логарифмическая сложность. Для blacklist (запрещённые айтемы) такого решения нет: нужно доказать невалидность всех постфиксов текущего префикса;
• семантический ID — это 2–4 идущих подряд токена; они пакуются в одно число int64: дешевле по памяти и даёт лексикографическую сортировку на лету. Словарь модели заметно меньше 16 бит;
• динамический KV-кэш заменён статическим: длина последовательности известна заранее, кэш предаллоцируется и переиспользуется между запросами; аллокация выполняется один раз, а не на каждый запрос. Снизились и задержка, и волатильность потребления памяти;
• профилировка по модели roofline показала, что generate почти целиком лежит в память-ограниченной зоне: время уходит на перекопирование KV-кэша, а не на вычисления.

Числа.

• 300 мс на инференс одного запроса в начале работы, 120–125 мс в медиане после оптимизаций, железо — CPU;
• до 128 кандидатов в выдаче генеративной модели, если на последнем шаге не перекопировать KV-кэш; число первых кандидатов ограничено beam size, последний токен регулируется отдельным параметром фильтрации;
• каталог 32–128 айтемов — порог, где вместо generate дешевле считать transition scores: prefill один раз, затем оценка каждого семантического ID за один вызов модели; побочный эффект — бимы не теряются.

Что забрать.

• Логит-процессоры переносят бизнес-фильтры внутрь генерации: отфильтрованные кандидаты не расходуют бюджет поиска, что при жёстких ограничениях на выдачу дешевле постфильтрации;
• переиспользуемый статический KV-кэш и отказ от его перекопирования на последнем шаге — приёмы для любого авторегрессионного декодера семантических идентификаторов;
• упаковка семантического ID в int64 применима и в офлайн-пайплайне: сравнение префиксов и дедупликация кодов становятся операциями над целыми числами.

Оговорки.

• Абсолютных значений качества в докладе нет: он про латентность и железо, метрики ранжирования не назывались;
• задержки относятся к инференсу на CPU на конкретном сервере; размер модели и конфигурация железа не названы;
• пошаговую фильтрацию для blacklist спикер не решил: называет её открытой задачей.

Что показали.

• Постановка: можно ли методами alignment, прежде всего обучением с подкреплением (RL, reinforcement learning), довести одну генеративную end-to-end модель до качества полного пайплайна — сильного retrieval (отбор кандидатов), сильного ранжирования и бизнес-правил;
• ограничение жёсткое: на инференсе одна модель, без дополнительных стадий скоринга и голов; смысл — упростить сервинг (загрузили веса в движок — получили рекомендации) и убрать bottleneck отсутствия end-to-end градиента;
• данные внутренние, музыкальный домен: 8 млн пользователей, 5 млн треков, 4 млрд событий, разнородные сигналы; сплит «честный», как рекомендуют коллеги из Sber AI Lab;
• итог: ни один метод alignment не дотянул до связки «генеративный претрейн плюс ранкер»: ранкер по-прежнему нужен и видит больше признаков, чем генеративная модель.

Метод.

• Притрейн: текстовый dense-эмбеддер дообучается на коллаборативных парах из одного контекста пользователя, затем RQ-VAE (residual-quantized VAE — дискретизация в кодовые токены) даёт семантические идентификаторы (semantic IDs) трёх уровней без коллизий;
• генеративный претрейн — next-token prediction по семантикам треков плюс feedback-токен: категорийный признак реакции пользователя; модель — трансформер 100 млн параметров без учёта эмбеддингов;
• метрики по каждому пользователю: ROC-AUC (площадь под ROC-кривой), NDCG+ (попадание в отложенные позитивы, должен расти) и NDCG− (попадание в негативы, должен падать);
• варианты alignment: дообучение на позитивах с teacher forcing; GRPO (Group Relative Policy Optimization — on-policy метод, где advantage есть рост награды относительно средней по группе рулаутов, без value-функции) с бинарной наградой; GRPO с наградой от модели предпочтения, в роли которой выступил нейросетевой ранкер; DPO (Direct Preference Optimization — off-policy pairwise-лосс).

Числа.

• GRPO — де-факто стандарт alignment в рекомендациях: за 2025–2026 год спикер насчитал порядка 100 работ в домене recsys с GRPO;
• награда от нейросетевого ранкера в процессе GRPO выросла примерно на +9% относительно претрейна, но ROC-AUC на отложенной выборке рос слабее;
• наивная бинарная награда (плюс за попадание в позитив, минус в негатив, ноль иначе) не работает: награды разрежены (reward sparsity), при сэмплировании рулаутов редко попадаем в отложенную выборку;
• абсолютных значений ROC-AUC и NDCG не называли: только направления метрик.

Что забрать.

• end-to-end генеративная система не отменяет ранжирования: двухэтапную схему стоит сохранять, а не делать её замену критерием успеха;
• чужой опыт про GRPO читать внимательно: в техрепортах с заявленным успехом модель внедрялась на стадии retrieval или retrieval плюс преранжирование, а не заменяла финальное ранжирование;
• расхождение «награда растёт, основная метрика нет» объясняется либо слабой моделью награды, либо reward hacking (оптимизацией награды вместо задачи): RL-этап валидировать по отложенной метрике, а не по значению награды;
• пара NDCG+ и NDCG− разделяет «стали попадать в хорошее» и «перестали показывать плохое»; feedback-токен — дешёвый кандидат на проверку в генеративном претрейне.

Оговорки.

• Абсолютных значений качества нет ни у одного варианта: доклад показывает направления метрик;
• результат назван промежуточным; ответ про долгосрочный эффект и exploration раскрыт не полностью: long-term мерят в онлайне, по времени в сервисе;
• +9% относится к значению награды в процессе обучения, а не к метрике качества на отложенной выборке.

Что показали.

• Доклад о том, как меняется рекомендательная платформа, когда ML-инженер работает вместе с агентами: взять LLM и агента недостаточно, нужен harness — окружение для работы агента, и он «не менее важен, чем сама LLM»;
• агенты применяются на каждом этапе: генерация гипотез, анализ данных, ML-эксперименты, разработка, подготовка системы к проду, разбор A/B-тестов и поведения моделей в проде;
• роль инженера смещается, а не исчезает: он направляет агентов, задаёт цели и критерии, ревьюит гипотезы, сплиты, метрики, архитектуру кода и сетап A/B, отвечает за результат;
• агенту нужны три вещи: контекст, действия (возможность взаимодействовать с внешним миром) и инструкции; качество ответа начинается с контекста, потому что про конкретную задачу и recsys-подходы LLM не знает ничего;
• контракт платформы меняется: вместо CLI, SDK, документации и UI она предоставляет контекст, действия и инструкции.

Метод.

• Контекст собирается по доменам: проверенные источники и подходы индустрии, история успехов и неудач, данные (описания, каталоги, структура, SQL-доступ), операционный и технический контекст платформы (поверхности показа, модели, статусы задач, логи, метрики);
• в контекст не нужно отдавать всё озеро данных: достаточно схем, профилей и агрегатов; но SQL и pandas-запросы от прогона к прогону считают, например, CTR в сегменте по-разному, поэтому нужны датамарты с верифицированными данными по фиксированной методологии;
• инструменты подключаются через MCP (Model Context Protocol), поверх — федерация из MCP как общий гейтвей для управления всеми тулами; плагины инкапсулируют скиллы, инструкции, настройки и дефолтные пути до MCP;
• контроль и безопасность: ролевая модель доступа, политики, аудит действий агентов, изоляция по данным и по вычислительным ресурсам;
• память об итерациях (вики, Jira, специализированные инструменты), чтобы агент не повторял работу, сделанную месяц или год назад, плюс скиллы и чек-листы как инструкции.

Числа.

• Больше 15 компаний работают на платформе рекомендаций Сбера, прожёваны сотни терабайт данных;
• нагрузка меняется качественно: раньше инженер делал три запроса в день и ждал расчёта, агенты запрашивают круглосуточно, отсюда рост утилизации ресурсов и необходимость лимитов и бюджетирования задач агентов;
• общего бенчмарка по рекомендательным системам нет и не будет; из LLM-бенчмарков названы SWE-бенч, Terminal-bench и Tau-bench, из ML — наборы на Kaggle-задачах;
• A/B «команда из 5–10 инженеров без агентов против одного тимлида с агентами» спикер считает невозможным: сравнимые команды на одинаковые задачи не поставить; индустрия измеряет скорость выпуска моделей и метрики по опросам.

Что забрать.

• Принцип «платформа = контекст + действия + инструкции» применим к контуру экспериментов не меньше, чем к продукту;
• метрики и срезы считать по верифицированным витринам, а не генеративным запросом на лету: иначе один и тот же показатель меняется от прогона к прогону;
• harness стоит измерять: бенчмарки на реальных анонимизированных кейсах, метрики и фидбэк от инженеров, песочницы, устроенные так, что агент не видит, как его проверяют.

Оговорки.

• Численных приростов качества в докладе нет: сравнений моделей не было, бенчмарки обсуждались как инфраструктура, а не как результат;
• эффект от агентов оценён качественно, измеримого A/B с командой без агентов спикер не проводил, ссылаясь на статьи Google по продуктивности разработки, где разница небольшая;
• доклад платформенный: метрики ранжирования (recall@k, NDCG@k) не обсуждались.

Mitigating Popularity Bias in Sequential Recommendations with Sparse Prior-Regularized Objective Антон Пембек, Sber AI Lab — Большой зал, 15:20–15:40 MSK. Работа принята в Full Paper Track конференции CIKM.

Что показали. Перекос в сторону популярного разобран по механизму, а не по симптому.

• обучение SASRec (sequential-трансформер для предсказания следующего айтема) с кросс-энтропией (CE, cross-entropy) даёт на t-SNE-карте эмбеддингов айтемов два раздельных кластера: редкие айтемы собираются отдельно, популярные отдельно;
• причина в градиенте CE по логитам: для негатива это вероятность из softmax, для позитива — та же вероятность минус единица, при этом softmax не насыщается и никогда не равен ровно нулю или единице;
• при 10 млрд взаимодействий айтем, встречающийся десятки–сотни раз, получает сигнал «понизить вероятность» порядка десяти миллиардов раз и лишь около десятка сигналов «повысить»: модель выучивает признак редкости и занижает вероятность;
• цель — не просто чаще показывать редкое, а рекомендовать его лучше, не ухудшая релевантные популярные рекомендации.

Метод. Дебайасинг перенесён в функцию потерь, архитектура не меняется.

• softmax записан как решение вариационной задачи: максимум скалярного произведения распределения на логиты плюс энтропия Шеннона в роли регуляризатора;
• замена энтропии Шеннона на энтропию Тсаллиса (Tsallis entropy, α-деформированный логарифм) даёт семейство α-entmax из работы про Sparse Sequence-to-Sequence Models: при α = 1 это softmax, при α = 2 — sparsemax, где нерелевантные негативы получают ровно нулевую вероятность;
• зануление нерелевантных негативов отдаёт редким айтемам больший градиент на их немногих обучающих примерах;
• новое — кросс-энтропийный член между распределением модели и распределением айтемов в датасете (частота айтема, делённая на число взаимодействий): его максимизация работает как коррекция логитов по популярности с гиперпараметром γ;
• популярный ground-truth получает надбавку логита, быстрее насыщается и даёт меньше градиента, а редкий айтем в роли позитива даёт большой градиент; спикер называет это hard-negative mining, так как негативами становятся лучше всего выученные популярные айтемы;
• подходит и SASRec, и two-tower: обучение идёт по скорректированным логитам, на инференсе ранжирование по исходным; logit adjustment получается частным случаем при γ = минус единица.

Числа. Абсолютных значений метрик не называли — результаты показаны графиками.

• лучшая конфигурация: α = 1.5, γ больше нуля, θ = 10;
• бейзлайны: CE-лосс, logit adjustment, inverse propensity weighting (IPW, обратное взвешивание по склонности); метод по докладу выше всех сразу по двум осям — novelty и NDCG;
• кривая Лоренца по показам: по оси X доля наименее популярных айтемов каталога, по оси Y накопленная доля показов; равномерная выдача даёт диагональ y = x, ближе всех к диагонали их метод;
• датасеты брали разные, эффект заявлен стабильным.

Что забрать.

• Дебайасинг встраивается в лосс без смены архитектуры: проверка на существующей модели — замена лосса и коррекция логитов;
• t-SNE эмбеддингов с раскраской по популярности и кривая Лоренца показов — дешёвая диагностика перекоса до эксперимента;
• рост novelty без роста NDCG авторы успехом не считают, метрики перекоса контролируются против падения качества;
• ценно не «чаще показываем редкое», а рост качества на редком при сохранении качества на популярном.

Оговорки.

• Онлайн-A/B в докладе нет, всё показано офлайн;
• popularity-aware negative sampling не сравнивали: базовый pop-sampling проверяли и он работал неплохо, вариант с учётом популярности назван будущей работой;
• на вопрос про показ редкого айтема не тому пользователю ответили: первый этап — кандидат-генерация, а «понравится ли пользователю» решает A/B;
• значений recall@k и NDCG@k в докладе не звучало.

Что показали. Три года внутренней рекомендательной платформы и ошибки команды.

• платформа обслуживает KION (онлайн-кинотеатр), Строки (книги), Ticketland и ещё около десяти клиентов;
• типовая развилка: команду выделяют под платформу, когда рекомендации уже кто-то делает, и получаются два параллельных стрима на одну задачу; выход — функциональное разделение, где продуктовая команда делает рекомендации, а платформа даёт инструменты;
• общее вынесено в отдельные контуры: A/B, инфраструктура, надёжность, базовые сервисы; A/B отделён намеренно — антипаттерн, когда команда сама проводит и обсчитывает свой эксперимент, а корректный A/B сам по себе сложен;
• главная проблема разделения: у платформы нет своего прода, поэтому она не понимает реальные потребности, и контакта не возникает даже когда продукт о них говорит;
• решение: платформа сама закрывает продуктовые задачи через модульные рекомендации (внутреннее имя конвейера — recflow, задаётся конфигом): менее важные точки берёт платформа, глубокие методы в ключевых точках делают продуктовые команды; одно решение работает в нескольких точках, поэтому небольшая правка даёт широкий выигрыш, а новый продукт с 2 RPS проверяется дешёво;
• агенты: эксперименты на подготовку данных при подключении продуктов и на доступ к рекомендациям через MCP (Model Context Protocol), но люди обязательны — агент склонен к тривиальным решениям и иногда предлагает очень плохие вещи, а инсайты из данных приносят пока только люди.

Метод. Базовые сервисы платформы.

• оркестратор: решение описывается YAML-конфигом, а не своим микросервисом — ночью при падении быстрее понять, что чинить, а код естественно выделяется в переносимые модули;
• сервис офлайн-рекомендаций поднимается одной строкой и отдаёт предсохранённые рекомендации — удобен для MVP;
• сервисы контекста по пользователю и айтему плюс сервис истории пользователя, без которого не собирается ни одна sequential-модель;
• сервис постпроцессинга для бизнес-правил, которые в ядре решения накапливаются и забываются; самое частое правило — если в выдаче пять объектов одной категории подряд, следующие не из этой категории;
• надёжность из коробки: мониторинги, логи, поддержка; при ночном падении первым подключается человек с платформы, потому что ML-инженер думает о модели, а не о таймингах и проценте ошибок.

Числа. Качественных метрик нет — числа только про организацию работы.

• платформа делается три года, число A/B-тестов растёт примерно на четверть за год: времени на гипотезы больше, на операционку меньше;
• за год 30% рекомендаций подключены к A/B через автоматический пайплайн;
• порог входа нового продукта — 2 RPS, что и делает проверку «нужны ли тут рекомендации» дешёвой.

Что забрать.

• Отдельная функция A/B и запрет команде считать свой эксперимент самой — организационная гарантия того же, что даёт фиксированная методология метрики;
• описание решения конфигом вместо своего сервиса: разбор инцидента сводится к чтению одного файла;
• бизнес-правила в отдельном сервисе постпроцессинга — аналог фильтров доступности и разнообразия в выдаче;
• в платформенном треке малого зала переносимы ровно эти вещи: единый конвейер, бизнес-правила, история, A/B-обвязка.

Оговорки.

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

Что показали. Доклад о том, как корректно упорядочивать алгоритмы рекомендаций между собой, когда результаты получены на десятках разнородных датасетов.

• наивная агрегация (среднее или сумма NDCG по датасетам) неустойчива: шкалы метрик на разных датасетах несопоставимы, и на нескольких датасетах один алгоритм выигрывает с большим отрывом, задирая среднее;
• пример из работы: EASE-R при ранжировании по среднему NDCG оказывается первым, обгоняя SASRec и методы на ближайших соседях (KNN), а статистическая модель предпочтений ставит его пятым;
• вместо усреднения сравнения алгоритмов на каждом датасете трактуются как матчи и сводятся в единую турнирную таблицу;
• модель даёт не только порядок, но и интервалы и спокойно переживает пропуски: не все алгоритмы обсчитаны на всех датасетах, пустая клетка — это просто отсутствующий матч.

Метод. Модель предпочтений Брэдли-Терри (Bradley-Terry, BT) поверх турнирной таблицы.

• у алгоритма i есть параметр силы θi, вероятность победы над j равна сигмоиде от θi − θj, параметры оцениваются методом максимального правдоподобия;
• неидентифицируемость (сдвиг всех θ на константу ничего не меняет) снимается фиксацией одного параметра либо регуляризацией; с регуляризацией появляется байесовская интерпретация, доверительные интервалы на силу алгоритмов и сэмплирование апостериора через MCMC (достаточно метрополис-хастингса);
• обобщения: модель Плакетта-Льюса (Plackett-Luce) для сравнений сразу нескольких алгоритмов — результаты почти те же; вариант с отдельным учётом ничьих, когда разрыв в пределах статистической погрешности; BT с ковариатами по свойствам датасета (плотность, размер, число пользователей, секвенциальность); BT-деревья с рекурсивным разбиением на подклассы;
• качество самого ранжирования измеряется долей транзитивных триплетов: если A бьёт B, а B бьёт C, то A должен бить C.

Числа.

• 14 популярных алгоритмов (простые бейзлайны, KNN-методы, матричные факторизации, EASE-R, shallow autoencoder, две GCN-архитектуры, SASRec) и 89 датасетов по единому протоколу обучения, валидации и теста; рейтинги устойчивы к смене сплита;
• по транзитивности триплетов BT немного, но стабильно лучше ранжирования по среднему — и на всей коллекции, и внутри классов «длинная история» и «разрежённые данные»;
• устойчивость к пропускам: при случайном выкидывании сравнений среднее и сумма быстро теряют транзитивность, BT и Плакетт-Льюс держатся, пока не выброшено 60% сравнений;
• предсказание ранжирования на новых датасетах: 10 датасетов в holdout, BT с ковариатами заметно лучше и наивного усреднения, и базового BT по попаданию в top-1 и top-3 алгоритма;
• доверительные интервалы: SASRec уверенно выше EASE-R — интервалы на силу не пересекаются.

Что забрать.

• не усреднять метрику качества, снятую на разных датасетах или осях: расхождение шкал делает такой порядок недостоверным;
• BT-модель даёт способ свести журнал экспериментов в устойчивый порядок с интервалами и проверять перевес одной модели над другой на множестве прогонов, а не по одному замеру;
• непересекающиеся доверительные интервалы как формальный признак того, что перевес не в пределах шума.

Оговорки.

• это методологический доклад: приростов качества конкретных моделей в нём нет;
• классы датасетов заданы вручную, и спикер сам отметил связанное с этим чувство неудовлетворённости — отсюда варианты с ковариатами и деревьями;
• времени на вопросы не осталось; устойчивость рейтингов к вариациям сплита вынесена в статью.

Что показали. Как офлайн-пайплайн рекомендательной платформы перестал платить за память «на глаз»: фактическое потребление каждой задачи измеряется, история копится во внешнем хранилище, а запрошенный объём памяти на следующий запуск подставляется автоматически.

• масштаб платформы: около 45 офлайн-сценариев, порядка 350 DAG (directed acyclic graph, направленный ациклический граф задач) и около 3,5 тысяч задач в сутки, каждая задача — отдельный под Kubernetes, запуск через KubernetesExecutor;
• механика перерасхода: разработчик ставит памяти с запасом, получает out of memory (OOM), удваивает запрос и останавливается далеко за реальной потребностью — техдолг по ресурсам сам не уменьшается;
• подстановка происходит на создании пода, поэтому логику пользовательских задач переписывать не нужно.

Метод. Рекомендация объёма считается по истории успешных запусков, а не по профилировщику в реальном времени.

• рекомендация = среднее фактического потребления по последним трём успешным запускам плюс 20–30% надёжности;
• на каждый следующий try number после OOM надбавка растёт; при падении по обычному исключению память не трогают, потому что она тут ни при чём;
• отклонённые варианты: перегрузка PythonOperator — обращение к внешнему хранилищу попадает в init, а шедулер обходит файлы DAG каждые 15–30 секунд, то есть ходил бы в S3 постоянно и стал бы узким местом; перегрузка KubernetesPodOperator — в изолированном окружении нет доступа к базе метаданных Airflow, а паттерн пользовательской задачи меняется;
• рабочий вариант: pod mutation hook (мутирующий вебхук на создании пода) в экзекьюторе Airflow — хук вписывает рекомендованную память в под, библиотека регистрируется как провайдер Airflow, а обращение к хранилищу идёт только в момент запуска задачи.

Числа. Сравнение одно — до и после на одном пользовательском сценарии.

• суммарный перерасход по задачам сценария: от 1,5 до 8 раз;
• экономия на одном пайплайне — порядка 1 ТБ оперативной памяти, уже с заложенным запасом 20–30%;
• сценарий: 41 задача в DAG;
• автоматический подбор CPU и «холодный старт» без участия пользователя заявлены как следующие шаги, внедрения ещё нет.

Что забрать.

• аудит «запрошено против фактически использовано» — дешёвый источник ресурсов на кластере, не требующий смены архитектуры;
• изменение параметров запуска на уровне admission-хука, без правок кода задач: приём переносится на любой оркестратор с мутацией объекта;
• протокол ретраев по памяти: надбавка на каждый повтор вместо ухода сразу в максимальный запрос.

Оговорки.

• метрик качества моделей в докладе нет: это инфраструктурный доклад, числа только ресурсные;
• замер сделан на одном сценарии, выигрыш на полном парке задач не заявлялся;
• контрибуции в открытый Airflow пока нет: спикер назвал вопрос упирающимся в NDA, но перегрузку pod mutation hook и Python operator — воспроизводимой самостоятельно.

Что показали. EASE (Embarrassingly Shallow Autoencoders, «до неприличия простой автоэнкодер») — модель из одной обучаемой item-to-item матрицы (попарных переходов между айтемами) — остаётся сильным бейзлайном и в 2026 году: в свежих сравнениях на разных сетапах она почти везде в лидирующей группе, а выпуклая квадратичная задача решается аналитически, без градиентного спуска. Слабое место — нет контентного сигнала; расширение L3AE (LLM-Enhanced Linear Autoencoders) подмешивает замороженные текстовые эмбеддинги через вторую item-to-item матрицу. Две новые работы: Scalable L3AE (RecSys 2026) снимает ограничение по памяти на больших каталогах, E2L3AE (CIKM 2026) дообучает текстовый энкодер под задачу рекомендаций.

Метод.

• EASE: выучить матрицу B так, чтобы X·B восстанавливала матрицу взаимодействий X; диагональ B занулена, чтобы айтем не копировал сам себя; решение аналитическое.
• L3AE: матрица S учится на текстовых эмбеддингах по той же логике, в лосс добавляется член, толкающий B к S. Смысл — на популярных айтемах коллаборативное разложение устойчиво, на длинном хвосте шумно, и семантика работает как заземление.
• Scalable L3AE: семантическая матрица раскладывается на диагональ плюс произведение узких матриц, коллаборативная часть заменяется разреженной аппроксимацией SANSA (Scalable Approximate NonSymmetric Autoencoder); асимптотика памяти из n² превращается в n²·ρ, где ρ — плотность факторов порядка 10⁻³.
• E2L3AE: семантику переносят из члена регуляризации внутрь восстанавливающей матрицы, чтобы не сдвигать уже выученные связи; у текстового энкодера два компонента лосса (восстановление взаимодействий через эмбеддинги и взаимное согласование эмбеддингов через S), обучение в alternating-режиме: шаги энкодера, затем аналитический пересчёт матриц.

Числа.

• item-to-item матрица на каталоге в 1 млн айтемов — 4 ТБ; переход к float16 или int8 положения не спасает;
• Scalable L3AE: 35 ГБ на каталоге 500 тыс. айтемов и 170 ГБ на 1 млн, тогда как EASE и L3AE не влезли в доступные 512 ГБ;
• крайняя точка сравнения по памяти и времени: L3AE — 450 ГБ и 4 часа обучения, Scalable L3AE — 70 ГБ и вдвое быстрее;
• качество: таблиц в докладе не показали, прозвучало только, что метрики не падают; дообученный текстовый энкодер в режиме item-to-item обошёл замороженный и оказался выше метода с дообучаемым энкодером, с которым сравнивались;
• long tail: эксперименты шли без k-core фильтрации (в оригинальных работах обычно 5-core или 10-core), и чем слабее фильтрация, тем больше прирост относительно коллаборативного варианта — выигрыш даёт именно семантика на редких айтемах.

Что забрать.

• перед тяжёлой генеративной схемой (Semantic ID, авторегрессионная генерация кодов) прогнать EASE/L3AE как дешёвый бейзлайн: две обучаемые матрицы против GPU-дней обучения;
• приём «нулевая диагональ плюс семантическая матрица» переносится на оценку качества кодов: там, где коллаборативное разложение шумно (длинный хвост, discovery), вклад семантики проверяется отдельно;
• дообучение текстового энкодера под задачу рекомендаций и переиспользование его вне конструкции, в том числе как входа для квантования в Semantic ID, — рычаг для этапа энкодера;
• память считать заранее: n²·ρ вместо n².

Оговорки. Продуктовых A/B-приростов не раскрывали: спикер подтвердил, что A/B в проде есть, но результаты не публикуются; в проде тестировали не Scalable-версию (каталог был небольшой), масштабируемую версию только планируют проверить. Сравнение качества Scalable L3AE с альтернативами в докладе не показали — только память и время обучения, утверждение «метрики не падают» дано без чисел.

Что показали. Позиционный сигнал в последовательных моделях обычно добавляют аддитивно на входе и эвристически: внимание без позиционных эмбеддингов и без причинной маски эквивариантно к перестановкам, то есть порядок айтемов по структуре не чувствует. Тензорная постановка даёт предписание, куда его вносить: последовательность пользователя — трёхмерный тензор (пользователи × айтемы × позиции), факторизация Такера, а позиционное ядро C стоит между ядром похожести айтемов и выходом внимания. Ядро C нарушает эквивариантность, поэтому чувствительность к порядку возникает естественным образом, а корреляции между айтемами не обнуляются при сдвиге последовательности на шаг. Для Semantic ID это даёт двухуровневую схему: восстановить айтем по его кодам и восстановить последовательность из айтемов.

Метод.

• база — тензорная факторизация с attention в линии GA-SATF (globally attentive sequence-aware tensor factorization), решение на перемежающихся наименьших квадратах; в ранжировании алгоритмов из предыдущего доклада эта модель заняла второе место после SASRec;
• позиционное ядро C = произведение двух треугольных матриц с затуханием вдоль последовательности; их можно задавать структурой или учить, в том числе свои для каждого блока внимания — тогда блоки отвечают за разную динамику;
• Semantic ID: последовательность разворачивается скользящим окном длины 3 (по числу кодов на айтем) в матрицу Ганкеля — приём из SSA (Singular Spectrum Analysis), обобщённый на много временных рядов (ряд на пользователя). Внимание идёт по строкам матрицы (уровень кодов) и по столбцам (уровень айтемов), маска блочно-треугольная, так как коды генерируются авторегрессионно; дальше деганкелизация — усреднение по антидиагоналям;
• раздувание в матрицу Ганкеля и структурированные Q и K строятся вычислительно, раздутая последовательность не хранится.

Числа. Чисел не называли: результаты показаны цветом статистической значимости, часть выводов автор называет предварительными. Из сравниваемых моделей значимо лучше базового SASRec улучшилась только предложенная; удаление позиционных эмбеддингов (NoPE) работало даже лучше, чем SASRec с ними, а тензорная модель на этом фоне продолжала улучшаться. На Semantic ID от двух разных генераторов: иерархическое тензорное внимание подняло более слабую базу на GPT-2 настолько, что она стала значимо лучше более сильной модели на Qwen.

Что забрать.

• позиционное ядро как отдельная обучаемая сущность вместо аддитивных эмбеддингов — изолированная правка последовательной модели при неизменном рецепте обучения;
• удаление позиционных эмбеддингов как быстрая абляция: в докладе она улучшила SASRec, то есть аддитивный позиционный сигнал там работал во вред;
• уровень «код против айтема» — аргумент за двухуровневое внимание в декодере генеративных рекомендаций вместо одного общего слоя;
• блочно-треугольная маска и контроль каузальности как деталь для авторегрессионной генерации Semantic ID.

Оговорки. Работа в начальной стадии: ни чисел, ни таблиц, ни числа датасетов в докладе нет, значимость показана цветом на графиках. Гиперпараметры (размерности факторов, режим обучения матриц C) не называли. На вопрос из онлайн-платформы, может ли низкоранговая тензорная модель воспроизвести специализацию голов multi-head attention, спикер ответил, что исследование до мультихеда ещё не дошло: сначала они разбираются с тем, что делает один блок и одна голова.

Что показали. Две работы по семантическим идентификаторам (Semantic ID — дискретный код айтема, полученный квантованием его эмбеддинга), принятые на трек Research and Practice Notes конференции RecSys 2026 — трек для незавершённых исследований; вторая сделана с AIRI. Первая тема — коллизии: один код достаётся нескольким айтемам, неоднозначность возникает дважды: при присвоении кода и при обратном отображении предсказанного кода в айтем; без этого нельзя считать офлайн-метрики, так как непонятно, попадание ли это в ground truth. Вторая тема — обязателен ли для айтема набор семантических токенов: айтем целен, его можно трактовать как концепт (в языковых моделях аналог — предложение), а к токенам возвращаться только на декодировании.

Метод.

• обзор работы с коллизиями: разрешать их на выдаче бизнес-правилами — по свежести или популярности либо лёгкой ранжирующей моделью (так делает Avito); ограничивать квантователь; переназначать коды после квантования;
• взятая группа — дополнительный кодбук; база из статьи Tiger: токен-счётчик, айтемы внутри коллизионной группы нумеруются по порядку, у большинства последний токен равен нулю, а кодбук приходится держать в истории пользователя — контекст раздувается и добавляется шаг генерации;
• сравнивали заполнение кодбука: sequential, популярность внутри группы, ребалансировку по расстоянию резидуалов до свободных центроидов, random-solver со случайным кодом и глобальную популярность, где код — номер бина популярности айтема по тренировочным данным;
• вторая работа: три варианта — тяжёлый бэкбон-декодер (Qwen или GPT-2-like) с beam search; сжатие айтема через MLP в один вектор; лёгкий декодер, ведущий поиск по концепту от бэкбона без cross-attention с историей. Обучение end-to-end кросс-энтропией, от переобучения спасают dropout на бэкбоне и label smoothing распределением более гладкой модели-учителя по KL.

Числа. Три датасета Amazon 2014 с временным сплитом: при разрешении коллизий по популярности NDCG растёт на всех трёх, у случайного варианта рост на двух. На Yambda-50M (последние 128 взаимодействий пользователя) модель масштабируется по глубине, но при истории меньше месяца преимущество предложенных решателей держится, а на всех данных почти исчезает: остаются слабые приросты NDCG@10. Во второй работе — до 5,5% NDCG@10 на части больших датасетов и небольшие просадки на двух; просадку при переобучении называли как от 8 до 5% и отыграли моделью-учителем.

Что забрать.

• разрешение коллизий — управляемый элемент конвейера Semantic ID: изолированный выбор кодбука и заполнения последнего токена, проверяемый полным рецептом, а не перебором эпох;
• отрицательный результат важен сам по себе: информативные токены коллизий помогают на малых данных и почти не помогают на всей истории;
• дополнительный кодбук раздувает контекст истории и добавляет шаг генерации — цена схемы по латентности, а не только качество ретривала;
• «концепт → семантические токены» с лёгким декодером даёт выбор: ускорить генерацию или в том же бюджете расширить beam search и поднять качество поиска.

Оговорки. Материалы незавершённые: абсолютных метрик и гиперпараметров не называли. Ускорение замерено на beam search из Hugging Face, который спикер сама назвала плохо оптимизированным для широких бимов: в промышленном конвейере выигрыш ожидается меньше. Систематического сравнения с разрешением коллизии в пользу самого популярного айтема не было.