KVzap: Fast, Adaptive, and Faithful KV Cache Pruning
Сегодня посмотрим на совсем свежую статью от NVIDIA о сжатии KV-кэша. KV-кэш — это сохраненные K- и V-стейты трансформера для последующей авторегрессивной генерации токенов в декодере. В первую очередь проблема сжатия возникает на стадии генерации в LLM, однако она актуальна и для ускорения инференса рекомендательных моделей, например, имеющих encoder-decoder-архитектуру.
Размер KV-кэша линейно зависит от числа слоёв трансформера L, от числа аттеншн-голов H, от длины входной последовательности T и от размерности векторов D. Таким образом, он имеет размерность (2, L, H, T, D), где 2 соответствует хранению K- и V-кэшей в одном тензоре. Сжатие по L-размерности достигается чередованием обычных MHA-слоёв и слоёв со Sliding Window Attention (SWA): GPT-OSS-120B, Gemma3, Kimi-Linear, и др. Для сжатия по размерности H применяют Grouped Query Attention (GQA), в котором одни и те же KV-головы используются в нескольких Q-головах: Llama3, GLM 4.5, Qwen3-235B-A22B. Вдоль размерности D сжатия добиваются с использованием хранения латентных представлений KV-векторов значительно меньшей размерности — Multi-head Latent Attention (MLA): DeepSeek V2.
Текущая SOTA для сжатия вдоль размерности T — KVzip, который:
1. получает входной промпт пользователя;
2. просит модель его повторить, аугментируя промпт следующим образом: «user: <input prompt>. Repeat the previous context exactly. assistant: »;
3. для каждой KV-головы для каждого вектора k_i из input prompt запоминают наибольший по длине повторённого промпта вес аттеншна (а в случае GQA максимум берётся и по группе Q-голов);
4. фиксированный процент K_i и v_i, соответствующих наименьшим запомненным весам, удаляются;
5. сжатый промпт подаётся модели.
Во-первых, такая схема скоринга очень дорога. Во-вторых, она применима только к стадии cache prefilling — стадия cache decoding сохраняется целиком. Последняя проблема особенно актуальна в контексте рассуждающих моделей, которые на стадии декодинга генерируют тысячи токенов.
В работе предлагают дистиллировать слегка модифицированные скоры KVzip в легковесный MLP. Для каждого слоя трансформера и каждого входного скрытого состояния MLP предсказывает вектор скоров из H (число KV-голов) компонент, после чего откидываются KV-пары, скоры которых не превосходят некоторый порог. Таким образом, степень сжатия зависит от информативности промпта. Локальный контекст из ближайших 128 токенов, однако, сохраняется полностью. MLP обучается поверх обученной модели на специальном датасете, содержащем целевые скоры KV-пар.
Поскольку MLP не добавляет значительной вычислительной сложности и применяется к входным токенам поточечно, KVzap можно использовать как во время prefilling’a, так и во время декодинга. Сжатие prefilling-стадии также становится дешевле.
Эвалятся авторы на Qwen3-8B, Llama-3.1-8B-Instruct, и Qwen3-32B, KV-кэш удаётся сжать в 2–4 раза при незначительных потерях качества.
@RecSysChannel
Разбор подготовил❣ Сергей Макеев
Сегодня посмотрим на совсем свежую статью от NVIDIA о сжатии KV-кэша. KV-кэш — это сохраненные K- и V-стейты трансформера для последующей авторегрессивной генерации токенов в декодере. В первую очередь проблема сжатия возникает на стадии генерации в LLM, однако она актуальна и для ускорения инференса рекомендательных моделей, например, имеющих encoder-decoder-архитектуру.
Размер KV-кэша линейно зависит от числа слоёв трансформера L, от числа аттеншн-голов H, от длины входной последовательности T и от размерности векторов D. Таким образом, он имеет размерность (2, L, H, T, D), где 2 соответствует хранению K- и V-кэшей в одном тензоре. Сжатие по L-размерности достигается чередованием обычных MHA-слоёв и слоёв со Sliding Window Attention (SWA): GPT-OSS-120B, Gemma3, Kimi-Linear, и др. Для сжатия по размерности H применяют Grouped Query Attention (GQA), в котором одни и те же KV-головы используются в нескольких Q-головах: Llama3, GLM 4.5, Qwen3-235B-A22B. Вдоль размерности D сжатия добиваются с использованием хранения латентных представлений KV-векторов значительно меньшей размерности — Multi-head Latent Attention (MLA): DeepSeek V2.
Текущая SOTA для сжатия вдоль размерности T — KVzip, который:
1. получает входной промпт пользователя;
2. просит модель его повторить, аугментируя промпт следующим образом: «user: <input prompt>. Repeat the previous context exactly. assistant: »;
3. для каждой KV-головы для каждого вектора k_i из input prompt запоминают наибольший по длине повторённого промпта вес аттеншна (а в случае GQA максимум берётся и по группе Q-голов);
4. фиксированный процент K_i и v_i, соответствующих наименьшим запомненным весам, удаляются;
5. сжатый промпт подаётся модели.
Во-первых, такая схема скоринга очень дорога. Во-вторых, она применима только к стадии cache prefilling — стадия cache decoding сохраняется целиком. Последняя проблема особенно актуальна в контексте рассуждающих моделей, которые на стадии декодинга генерируют тысячи токенов.
В работе предлагают дистиллировать слегка модифицированные скоры KVzip в легковесный MLP. Для каждого слоя трансформера и каждого входного скрытого состояния MLP предсказывает вектор скоров из H (число KV-голов) компонент, после чего откидываются KV-пары, скоры которых не превосходят некоторый порог. Таким образом, степень сжатия зависит от информативности промпта. Локальный контекст из ближайших 128 токенов, однако, сохраняется полностью. MLP обучается поверх обученной модели на специальном датасете, содержащем целевые скоры KV-пар.
Поскольку MLP не добавляет значительной вычислительной сложности и применяется к входным токенам поточечно, KVzap можно использовать как во время prefilling’a, так и во время декодинга. Сжатие prefilling-стадии также становится дешевле.
Эвалятся авторы на Qwen3-8B, Llama-3.1-8B-Instruct, и Qwen3-32B, KV-кэш удаётся сжать в 2–4 раза при незначительных потерях качества.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9❤8👍8
OneRec-Think: In-Text Reasoning for Generative Recommendation
Сегодня обсудим работу, в которой продолжается история с генеративными рекомендациями от Kuaishou. Авторы по-прежнему хотят заменить классический рекомендательный стек одной генеративной моделью, но теперь ещё и добавить туда LLM-ный ризонинг и диалог.
OneRec хорошо предсказывает следующий айтем по истории пользователя, но остаётся узкодоменной моделью: у неё нет широкого world knowledge, как у LLM, и нет развитых механизмов следования инструкциям и рассуждения. Поэтому авторы добавляют в OneRec-Think ризонинг, рассчитывая улучшить точность рекомендаций. Причём он используется непосредственно в процессе предсказания следующего айтема.
Тут возникают две сложности. Во-первых, LLM изначально не знает, что такое рекомендательные айтемы (видео, треки и прочее). Во-вторых, даже если заставить её «думать», она не умеет думать именно в рекомендательном домене: длинные и шумные истории пользователей ломают красивый ризонинг.
Авторы решают эти проблемы в три этапа.
Сначала делают Itemic Alignment. В словарь добавляют айтем-токены (3×8К = 24К новых токенов) и учат модель понимать айтем-токены в одном контексте с текстовыми. Делают это аккуратно: сначала замораживают бэкбон и обучают только эмбеддинги новых токенов, чтобы сохранить языковые способности модели, а затем размораживают все параметры и обучают модель совместно. Используют несколько задач, включая интерпретацию пользовательской истории, sequential next-item prediction и декодирование айтемов в текстовые описания.
Дальше — Reasoning Activation. Просто взять полную историю и попросить «подумай» не работает: слишком много шума и длинный контекст. Поэтому ризонинг-траектории извлекают хитрее. Берут таргет-айтем и с помощью внешней модели близости айтемов g(·,·) достают top-k (k=10) самых релевантных айтемов из истории пользователя. На этом подмножестве модель способна сгенерировать осмысленное объяснение того, почему пользователь взаимодействовал с таргетным айтемом. Эти объяснения затем используют как SFT-данные: уже на полной истории учат сначала генерировать ризонинг-трейс, а потом — следующий айтем.
И финальный этап — Reasoning Enhancement. Модель сэмплит несколько объяснений, а дальше под каждое считают reward — не в бинарной форме «угадал / не угадал», а на основе степени совпадения семантических токенов предсказанных кандидатов с таргетным айтемом. Для этого используется beam search по продолжениям. В результате ризонинг-траектории, ведущие к более точным предсказаниям, получают больший вес и становятся более вероятными.
В статье обсуждают, как такую модель можно внедрить при больших RPS. Авторы предлагают схему Think-Ahead: вычислительно тяжёлую часть — генерацию ризонинга и первых шагов декодирования айтем-токенов — считают офлайн и сохраняют для пользователя набор возможных префиксов.
В онлайне обычный OneRec ограничивается этим множеством и быстро достраивает финальный айтем. За счёт этого снижается стоимость инференса и одновременно в продакшн-систему переносятся знания LLM, зашитые в ризонинг-префиксы.
В результате модель не только генерирует объяснения и учитывает текстовые ограничения, но и сохраняет качество предсказания следующего айтема, что подтверждают онлайн-эксперименты.
@RecSysChannel
Разбор подготовил❣ Артём Матвеев
Сегодня обсудим работу, в которой продолжается история с генеративными рекомендациями от Kuaishou. Авторы по-прежнему хотят заменить классический рекомендательный стек одной генеративной моделью, но теперь ещё и добавить туда LLM-ный ризонинг и диалог.
OneRec хорошо предсказывает следующий айтем по истории пользователя, но остаётся узкодоменной моделью: у неё нет широкого world knowledge, как у LLM, и нет развитых механизмов следования инструкциям и рассуждения. Поэтому авторы добавляют в OneRec-Think ризонинг, рассчитывая улучшить точность рекомендаций. Причём он используется непосредственно в процессе предсказания следующего айтема.
Тут возникают две сложности. Во-первых, LLM изначально не знает, что такое рекомендательные айтемы (видео, треки и прочее). Во-вторых, даже если заставить её «думать», она не умеет думать именно в рекомендательном домене: длинные и шумные истории пользователей ломают красивый ризонинг.
Авторы решают эти проблемы в три этапа.
Сначала делают Itemic Alignment. В словарь добавляют айтем-токены (3×8К = 24К новых токенов) и учат модель понимать айтем-токены в одном контексте с текстовыми. Делают это аккуратно: сначала замораживают бэкбон и обучают только эмбеддинги новых токенов, чтобы сохранить языковые способности модели, а затем размораживают все параметры и обучают модель совместно. Используют несколько задач, включая интерпретацию пользовательской истории, sequential next-item prediction и декодирование айтемов в текстовые описания.
Дальше — Reasoning Activation. Просто взять полную историю и попросить «подумай» не работает: слишком много шума и длинный контекст. Поэтому ризонинг-траектории извлекают хитрее. Берут таргет-айтем и с помощью внешней модели близости айтемов g(·,·) достают top-k (k=10) самых релевантных айтемов из истории пользователя. На этом подмножестве модель способна сгенерировать осмысленное объяснение того, почему пользователь взаимодействовал с таргетным айтемом. Эти объяснения затем используют как SFT-данные: уже на полной истории учат сначала генерировать ризонинг-трейс, а потом — следующий айтем.
И финальный этап — Reasoning Enhancement. Модель сэмплит несколько объяснений, а дальше под каждое считают reward — не в бинарной форме «угадал / не угадал», а на основе степени совпадения семантических токенов предсказанных кандидатов с таргетным айтемом. Для этого используется beam search по продолжениям. В результате ризонинг-траектории, ведущие к более точным предсказаниям, получают больший вес и становятся более вероятными.
В статье обсуждают, как такую модель можно внедрить при больших RPS. Авторы предлагают схему Think-Ahead: вычислительно тяжёлую часть — генерацию ризонинга и первых шагов декодирования айтем-токенов — считают офлайн и сохраняют для пользователя набор возможных префиксов.
В онлайне обычный OneRec ограничивается этим множеством и быстро достраивает финальный айтем. За счёт этого снижается стоимость инференса и одновременно в продакшн-систему переносятся знания LLM, зашитые в ризонинг-префиксы.
В результате модель не только генерирует объяснения и учитывает текстовые ограничения, но и сохраняет качество предсказания следующего айтема, что подтверждают онлайн-эксперименты.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍8❤7
Massive Memorization with Hundreds of Trillions of Parameters for Sequential Transducer Generative Recommenders
Скейлинг рекомендательных моделей — один из ключевых трендов рексистем последних лет. Исследователи Яндекса в рамках подхода Argus показывали, что качество моделей сильнее всего растёт при увеличении длины последовательности, которую обрабатывает трансформер. Однако рост до десятков и сотен тысяч событий сопряжен уже с инфраструктурными сложностями, и применение таких моделей в реалтайме за разумное время не представляется возможным.
Сегодня рассказываем о статье, в которой авторы из Meta* предлагают элегантный двухстадийный фреймворк. Вместо того, чтобы тяжелым трансформером держать в контексте 1 млн событий, можно в офлайне сжать всю lifelong-историю, а в рантайме использовать это сжатое представление.
Идея сама по себе не нова, но в близких по духу работах SIM, TWIN V2 или Transact V2 утилизация lifelong-контекста была сопряжена либо с тривиальным и неэффективным сжатием последовательности, либо с обработкой ограниченного подмножества событий, что в итоге ведёт к сильной просадке качества.
В статье сжатие истории проводят так: берётся полная история пользователя, над которой строят квазилинейный аттеншн, и вводят ряд суммаризирующих эмбеддингов — рассматривают до 128 штук. Модифицированный аттеншн помогает обрабатывать сверхдлинные последовательности за разумное время, а нелинейность, введенная с помощью SiLU, позволяет лучше моделировать сложные взаимодействия. Для эффективного сжатия истории авторы также вводят дополнительный reconstructive loss, чтобы из полученных эмбеддингов можно было как можно лучше восстановить исходную последовательность.
Эмбеддинги складываются в кэш, который обновляется асинхронно. Во время инференса их берут и строят target attention между сжатыми представлениями и айтемами-кандидатами.
Результаты офлайн-экспериментов оказались примерно сопоставимы с HSTU, вместе с этим скорость инференса при увеличении длины последовательности остаётся практически константной.
A/B-тест проводился, скорее всего, на базе Reels, в качестве бейзлайна выступала HSTU-модель. Ключевая внутренняя метрика вовлеченности C-task выросла на 0,5%, а дополнительные метрики удержания — O1 и O2 tasks — на 0,2% и 0,04%. Утверждается, что рост O2 даже на 0,01% — это существенный успех.
@RecSysChannel
Разбор подготовил❣ Руслан Кулиев
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Скейлинг рекомендательных моделей — один из ключевых трендов рексистем последних лет. Исследователи Яндекса в рамках подхода Argus показывали, что качество моделей сильнее всего растёт при увеличении длины последовательности, которую обрабатывает трансформер. Однако рост до десятков и сотен тысяч событий сопряжен уже с инфраструктурными сложностями, и применение таких моделей в реалтайме за разумное время не представляется возможным.
Сегодня рассказываем о статье, в которой авторы из Meta* предлагают элегантный двухстадийный фреймворк. Вместо того, чтобы тяжелым трансформером держать в контексте 1 млн событий, можно в офлайне сжать всю lifelong-историю, а в рантайме использовать это сжатое представление.
Идея сама по себе не нова, но в близких по духу работах SIM, TWIN V2 или Transact V2 утилизация lifelong-контекста была сопряжена либо с тривиальным и неэффективным сжатием последовательности, либо с обработкой ограниченного подмножества событий, что в итоге ведёт к сильной просадке качества.
В статье сжатие истории проводят так: берётся полная история пользователя, над которой строят квазилинейный аттеншн, и вводят ряд суммаризирующих эмбеддингов — рассматривают до 128 штук. Модифицированный аттеншн помогает обрабатывать сверхдлинные последовательности за разумное время, а нелинейность, введенная с помощью SiLU, позволяет лучше моделировать сложные взаимодействия. Для эффективного сжатия истории авторы также вводят дополнительный reconstructive loss, чтобы из полученных эмбеддингов можно было как можно лучше восстановить исходную последовательность.
Эмбеддинги складываются в кэш, который обновляется асинхронно. Во время инференса их берут и строят target attention между сжатыми представлениями и айтемами-кандидатами.
Результаты офлайн-экспериментов оказались примерно сопоставимы с HSTU, вместе с этим скорость инференса при увеличении длины последовательности остаётся практически константной.
A/B-тест проводился, скорее всего, на базе Reels, в качестве бейзлайна выступала HSTU-модель. Ключевая внутренняя метрика вовлеченности C-task выросла на 0,5%, а дополнительные метрики удержания — O1 и O2 tasks — на 0,2% и 0,04%. Утверждается, что рост O2 даже на 0,01% — это существенный успех.
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11🔥9👍8
OpenOneRec Technical Report
Сегодня кратко пересказываем техрепорт от Kuaishou о рекомендательной модели, которая должна быть способна не только рекомендовать, но ещё и понимать, что она рекомендует, и уметь это объяснять.
Авторы исходят из проблемы, что современные рекомендательные модели учатся и применяются на узком срезе данных, что мешает им приобретать общие знания и масштабироваться, как большим языковым моделям. Для преодоления этого разрыва предлагают бенчмарк, открытый датасет и семейство опенсорсных моделей.
RecIF-Bench
В бенчмарке три домена: short video, ads и products. Всего около 200 тысяч пользователей, больше 15 миллионов айтемов и почти 120 миллионов взаимодействий. Домены при этом сильно отличаются.
В видео у пользователей очень длинные истории с сотнями взаимодействий. В рекламе айтемов и кликов меньше. Products — это отдельный e-commerce-домен со своими паттернами.
Для кодирования айтемов используется семантические id, которые добавляются в словарь базовой LLM. История пользователя в виде единой последовательности, а обучение просходит авторегрессивно. Это позволяет обучать архитектуру LLM без изменений по принципу next-token prediction, но в рекомендательном контексте.
Кроме логов взаимодействий, датасет содержит три источника информации: пользователь, айтем и само взаимодействие. Пользователь описывается через текстовый User Portrait: демография, история просмотров, поиски, подписки, покупки и т.д. У айтемов есть мультимодальные эмбеддинги и dense captions (для видео). Во взаимодействиях учитывают разные сигналы: лайки, комментарии, просмотры, дизлайки.
Какие задачи проверяют
Всего выделяют восемь типов задач и распределяют их по четырём уровням. Каждый следующий требует от модели более «общего» поведения. Сначала понимание айтемов и простые рекомендации. Потом условные рекомендации, вроде «предскажи видео, которое лайкнут». И в конце задачи на объяснение рекомендаций.
Как обучают модель
Обучение во многом похоже на OneRec Think. Сначала делают warm-up для айтемных токенов, потом претрейн на основном датасете с добавлением обычных текстов, чтобы предотвратить катастрофическое забывание языка. Полностью это всё равно не спасает, поэтому дальше идут стадии посттрейнинга.
В посттрейне главная стадия — восстановление текстового рассуждения. Модель дистиллируют из замороженной Qwen и обучают не генерировать айтемные токены в обычных текстовых вопросах. В самом конце добавляют RL-стадию, чтобы улучшить рекомендации.
Отдельно говорят о масштабировании, что для таких моделей данные нужно скейлить чуть агрессивнее, чем параметры. Это хорошо ложится на общий опыт обучения рекомендательных моделей: относительно небольшие модели учатся на больших датасетах.
Результаты
На своём бенчмарке модели ожидаемо обгоняют базлайны. Интересно, что есть трейд-офф между обычной 8B и 8B Pro: вторая лучше в рекомендациях, но обычная 8B часто сильнее в задачах, где нужно говорить и объяснять.
На Amazon-бенчмарках тоже показывают хорошие цифры, но эти эксперименты по сути нельзя воспроизвести, так как слишком много закрытых деталей и дополнительного дообучения.
@RecSysChannel
Разбор подготовил❣ Иван Артемьев
Сегодня кратко пересказываем техрепорт от Kuaishou о рекомендательной модели, которая должна быть способна не только рекомендовать, но ещё и понимать, что она рекомендует, и уметь это объяснять.
Авторы исходят из проблемы, что современные рекомендательные модели учатся и применяются на узком срезе данных, что мешает им приобретать общие знания и масштабироваться, как большим языковым моделям. Для преодоления этого разрыва предлагают бенчмарк, открытый датасет и семейство опенсорсных моделей.
RecIF-Bench
В бенчмарке три домена: short video, ads и products. Всего около 200 тысяч пользователей, больше 15 миллионов айтемов и почти 120 миллионов взаимодействий. Домены при этом сильно отличаются.
В видео у пользователей очень длинные истории с сотнями взаимодействий. В рекламе айтемов и кликов меньше. Products — это отдельный e-commerce-домен со своими паттернами.
Для кодирования айтемов используется семантические id, которые добавляются в словарь базовой LLM. История пользователя в виде единой последовательности, а обучение просходит авторегрессивно. Это позволяет обучать архитектуру LLM без изменений по принципу next-token prediction, но в рекомендательном контексте.
Кроме логов взаимодействий, датасет содержит три источника информации: пользователь, айтем и само взаимодействие. Пользователь описывается через текстовый User Portrait: демография, история просмотров, поиски, подписки, покупки и т.д. У айтемов есть мультимодальные эмбеддинги и dense captions (для видео). Во взаимодействиях учитывают разные сигналы: лайки, комментарии, просмотры, дизлайки.
Какие задачи проверяют
Всего выделяют восемь типов задач и распределяют их по четырём уровням. Каждый следующий требует от модели более «общего» поведения. Сначала понимание айтемов и простые рекомендации. Потом условные рекомендации, вроде «предскажи видео, которое лайкнут». И в конце задачи на объяснение рекомендаций.
Как обучают модель
Обучение во многом похоже на OneRec Think. Сначала делают warm-up для айтемных токенов, потом претрейн на основном датасете с добавлением обычных текстов, чтобы предотвратить катастрофическое забывание языка. Полностью это всё равно не спасает, поэтому дальше идут стадии посттрейнинга.
В посттрейне главная стадия — восстановление текстового рассуждения. Модель дистиллируют из замороженной Qwen и обучают не генерировать айтемные токены в обычных текстовых вопросах. В самом конце добавляют RL-стадию, чтобы улучшить рекомендации.
Отдельно говорят о масштабировании, что для таких моделей данные нужно скейлить чуть агрессивнее, чем параметры. Это хорошо ложится на общий опыт обучения рекомендательных моделей: относительно небольшие модели учатся на больших датасетах.
Результаты
На своём бенчмарке модели ожидаемо обгоняют базлайны. Интересно, что есть трейд-офф между обычной 8B и 8B Pro: вторая лучше в рекомендациях, но обычная 8B часто сильнее в задачах, где нужно говорить и объяснять.
На Amazon-бенчмарках тоже показывают хорошие цифры, но эти эксперименты по сути нельзя воспроизвести, так как слишком много закрытых деталей и дополнительного дообучения.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍6🔥3🤔1🤩1
SilverTorch: A Unified Model-based System to Democratize Large-Scale Recommendation on GPUs
Сегодня разбираем статью от Meta* на тему кандидатогенерации на основе GPU. Авторы рассказывают, как именно уносят кандидатогенераторы на GPU и какой профит получают.
Индустриальные рекомендательные системы скейлятся на десятки и сотни миллионов айтемов, поэтому приходится строить каскад, где на ранней стадии кандидатов достают из ANN-индекса и дополнительно фильтруют по разным бизнес-правилам.
В работе утверждают, что типичный пайплайн «ANN на CPU + фильтрующий сервис + сетевые вызовы между компонентами» дорогой и неэффективный. Сюда прибавляется проблема неконсистентности: юзерная часть двубашенной модели обновляется часто, а документная — редко, потому что перестроение индекса стоит дорого. Это приводит к миссматчу версий и создаёт целых 30% дропа перформанса.
В SilverTorch объединяют индексацию и фильтрацию на одной видеокарте и реализуют всё как один PyTorch-граф без пересылок между отдельными сервисами. Для фильтрации вместо обратного индекса используют Bloom-index: строят битовые маски по атрибутам (язык, регион и прочее), транспонируют представление так, чтобы обрабатывать куски по 64 документа за инструкцию и избегать рандомных обращений к памяти. Фильтрацию делают сразу во время ANN-поиска, чтобы топ на выходе ANN-индекса содержал строго айтемы, соответствующие всем бизнес-правилам. Bloom-маску строят только по айтемам из выбранных кластеров — это, по оценке авторов, в 30 раз сократило стоимость стадии фильтрации фичей.
Сам ANN-поиск реализован как KNN с кластеризацией (сначала топ центроидов, потом дот-продакты внутри кластеров). Эмбеддинги квантуют в Int8, что в два раза сокращает потребление памяти и сильно поднимает пропускную способность.
Высвободившийся бюджет тратят на OverArch scoring layer — нейросеть, которая усложняет функцию матчинга поверх дот-продакта и даёт более высокий recall. Отдельно говорят, что такой дизайн упрощает мультитаск-ретривал: не нужно строить несколько индексов, так как все таски считаются в одной копии индекса, а потом комбинируются value-моделью.
По результатам на двух industry-scale-датасетах (10 млн и 80 млн айтемов) авторы получили снижение latency более чем в 5 раз, рост пропускной способности в 23 раза и сокращение костов на сёрвинг в 13 раз. Систему уже внедрили в сотни моделей в продуктах Meta, и она сёрвит миллиарды пользователей.
@RecSysChannel
Разбор подготовил❣ Николай Савушкин
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Сегодня разбираем статью от Meta* на тему кандидатогенерации на основе GPU. Авторы рассказывают, как именно уносят кандидатогенераторы на GPU и какой профит получают.
Индустриальные рекомендательные системы скейлятся на десятки и сотни миллионов айтемов, поэтому приходится строить каскад, где на ранней стадии кандидатов достают из ANN-индекса и дополнительно фильтруют по разным бизнес-правилам.
В работе утверждают, что типичный пайплайн «ANN на CPU + фильтрующий сервис + сетевые вызовы между компонентами» дорогой и неэффективный. Сюда прибавляется проблема неконсистентности: юзерная часть двубашенной модели обновляется часто, а документная — редко, потому что перестроение индекса стоит дорого. Это приводит к миссматчу версий и создаёт целых 30% дропа перформанса.
В SilverTorch объединяют индексацию и фильтрацию на одной видеокарте и реализуют всё как один PyTorch-граф без пересылок между отдельными сервисами. Для фильтрации вместо обратного индекса используют Bloom-index: строят битовые маски по атрибутам (язык, регион и прочее), транспонируют представление так, чтобы обрабатывать куски по 64 документа за инструкцию и избегать рандомных обращений к памяти. Фильтрацию делают сразу во время ANN-поиска, чтобы топ на выходе ANN-индекса содержал строго айтемы, соответствующие всем бизнес-правилам. Bloom-маску строят только по айтемам из выбранных кластеров — это, по оценке авторов, в 30 раз сократило стоимость стадии фильтрации фичей.
Сам ANN-поиск реализован как KNN с кластеризацией (сначала топ центроидов, потом дот-продакты внутри кластеров). Эмбеддинги квантуют в Int8, что в два раза сокращает потребление памяти и сильно поднимает пропускную способность.
Высвободившийся бюджет тратят на OverArch scoring layer — нейросеть, которая усложняет функцию матчинга поверх дот-продакта и даёт более высокий recall. Отдельно говорят, что такой дизайн упрощает мультитаск-ретривал: не нужно строить несколько индексов, так как все таски считаются в одной копии индекса, а потом комбинируются value-моделью.
По результатам на двух industry-scale-датасетах (10 млн и 80 млн айтемов) авторы получили снижение latency более чем в 5 раз, рост пропускной способности в 23 раза и сокращение костов на сёрвинг в 13 раз. Систему уже внедрили в сотни моделей в продуктах Meta, и она сёрвит миллиарды пользователей.
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🔥10👍8
RankMixer: Scaling Up Ranking Models in Industrial Recommenders
Сегодня разберём статью от ByteDance. Авторы предлагают модель RankMixer, новую масштабируемую архитектуру ранжирования для индустриальных рекомендаций.
Современные ранжирующие модели часто плохо используют GPU. Многие подходы исторически оптимизировались под CPU, из-за чего GPU-утилизация остаётся низкой. Авторы хотят повысить MFU (Model FLOPs Utilization) — то, насколько эффективно модель использует вычисления.
RankMixer позиционируется как продолжение линейки работ по deep learning в рекомендациях: Wide&Deep, DeepFM, DCNv2 и других моделей, развивающих feature interactions.
Архитектура
На вход подаются гетерогенные признаки: профиль пользователя, профиль видео, видеофичи и сигналы взаимодействий. Раньше такие взаимодействия часто учитывались либо неэффективно, либо через простые схемы вроде конкатенаций. Поэтому в RankMixer предложили другую структуру.
Сначала все признаки переводятся в token-based-представление, то есть представляются токенами одинаковой размерности. На входе получается матрица T×D, где T — число токенов, а D — их размерность.
Дальше токены подаются в RankMixer block, который состоит из двух частей:
- Multi-head Token Mixing,
- Per-token FFN (PFFN).
В Multi-head Token Mixing каждый токен разбивается на H голов, чтобы смешивать разные семантические фрагменты и лучше учитывать гетерогенность признаков.
Смешивание происходит через конкатенацию: для каждой головы берётся соответствующая часть всех токенов и собирается новая матрица. Так учитываются взаимодействия и внутри токенов, и между разными группами признаков.
Дальше идёт Per-token FFN, где каждый токен обрабатывается индивидуально. По сути это feed-forward-слой, но применяется он отдельно для каждого токена.
В PFFN также используют Sparse Mixture-of-Experts (MoE). Это позволяет увеличивать capacity модели без такого же роста флопсов: вместо одного FFN берут набор экспертов, и для каждого токена активируют только часть из них.
В статье отдельно обсуждают проблему dying experts, когда работают только несколько доминирующих экспертов. Для борьбы с этим используют routing-стратегию: роутер выбирает несколько экспертов; а также добавляют load balancing losses, чтобы эксперты использовались равномернее.
После нескольких блоков выход агрегируется через pooling, и дальше модель предсказывает таргетные сигналы: например, skip, like, completion и другие.
Эксперименты
В работе есть сравнения по эффективности и качеству. Также авторы провели долгий A/B-эксперимент онлайн в Douyin и Douyin Lite, по итогам которого заменили в проде 16M модель на RankMixer 1B без существенного увеличения времени на инференс.
Для офлайн-оценки взяты стандартные метрики AUC и UAUC. Эксперименты провели сначала на рекомендациях видео, а затем и на рекламе.
В качестве бейзлайнов сравнивают RankMixer с MLP + feature crossing, DCNv2, а также с более современными моделями (например, AutoInt и HiFormer).
Результаты
RankMixer выигрывает у бейзлайнов как в варианте около 100M параметров, так и в варианте около 1B параметров. Полученные улучшения статзначимы.
Также в работе есть графики по скейлингу: рост AUC сопоставляется с числом параметров. RankMixer показывает более выгодное соотношение между качеством и масштабом модели.
В аблейшнах видно, что главный вклад дают два компонента RankMixer block:
1) Удаление Multi-head Token Mixing сильно снижает качество.
2) Замена Per-token FFN на shared FFN тоже ухудшает метрики.
Итоговый вывод авторов — они получили универсальный бэкбон для индустриального ранжирования, который позволяет одновременно улучшить качество рекомендаций и повысить эффективность использования GPU.
@RecSysChannel
Разбор подготовила❣ Василиса Григорьева
Сегодня разберём статью от ByteDance. Авторы предлагают модель RankMixer, новую масштабируемую архитектуру ранжирования для индустриальных рекомендаций.
Современные ранжирующие модели часто плохо используют GPU. Многие подходы исторически оптимизировались под CPU, из-за чего GPU-утилизация остаётся низкой. Авторы хотят повысить MFU (Model FLOPs Utilization) — то, насколько эффективно модель использует вычисления.
RankMixer позиционируется как продолжение линейки работ по deep learning в рекомендациях: Wide&Deep, DeepFM, DCNv2 и других моделей, развивающих feature interactions.
Архитектура
На вход подаются гетерогенные признаки: профиль пользователя, профиль видео, видеофичи и сигналы взаимодействий. Раньше такие взаимодействия часто учитывались либо неэффективно, либо через простые схемы вроде конкатенаций. Поэтому в RankMixer предложили другую структуру.
Сначала все признаки переводятся в token-based-представление, то есть представляются токенами одинаковой размерности. На входе получается матрица T×D, где T — число токенов, а D — их размерность.
Дальше токены подаются в RankMixer block, который состоит из двух частей:
- Multi-head Token Mixing,
- Per-token FFN (PFFN).
В Multi-head Token Mixing каждый токен разбивается на H голов, чтобы смешивать разные семантические фрагменты и лучше учитывать гетерогенность признаков.
Смешивание происходит через конкатенацию: для каждой головы берётся соответствующая часть всех токенов и собирается новая матрица. Так учитываются взаимодействия и внутри токенов, и между разными группами признаков.
Дальше идёт Per-token FFN, где каждый токен обрабатывается индивидуально. По сути это feed-forward-слой, но применяется он отдельно для каждого токена.
В PFFN также используют Sparse Mixture-of-Experts (MoE). Это позволяет увеличивать capacity модели без такого же роста флопсов: вместо одного FFN берут набор экспертов, и для каждого токена активируют только часть из них.
В статье отдельно обсуждают проблему dying experts, когда работают только несколько доминирующих экспертов. Для борьбы с этим используют routing-стратегию: роутер выбирает несколько экспертов; а также добавляют load balancing losses, чтобы эксперты использовались равномернее.
После нескольких блоков выход агрегируется через pooling, и дальше модель предсказывает таргетные сигналы: например, skip, like, completion и другие.
Эксперименты
В работе есть сравнения по эффективности и качеству. Также авторы провели долгий A/B-эксперимент онлайн в Douyin и Douyin Lite, по итогам которого заменили в проде 16M модель на RankMixer 1B без существенного увеличения времени на инференс.
Для офлайн-оценки взяты стандартные метрики AUC и UAUC. Эксперименты провели сначала на рекомендациях видео, а затем и на рекламе.
В качестве бейзлайнов сравнивают RankMixer с MLP + feature crossing, DCNv2, а также с более современными моделями (например, AutoInt и HiFormer).
Результаты
RankMixer выигрывает у бейзлайнов как в варианте около 100M параметров, так и в варианте около 1B параметров. Полученные улучшения статзначимы.
Также в работе есть графики по скейлингу: рост AUC сопоставляется с числом параметров. RankMixer показывает более выгодное соотношение между качеством и масштабом модели.
В аблейшнах видно, что главный вклад дают два компонента RankMixer block:
1) Удаление Multi-head Token Mixing сильно снижает качество.
2) Замена Per-token FFN на shared FFN тоже ухудшает метрики.
Итоговый вывод авторов — они получили универсальный бэкбон для индустриального ранжирования, который позволяет одновременно улучшить качество рекомендаций и повысить эффективность использования GPU.
@RecSysChannel
Разбор подготовила
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤5🔥3❤🔥1⚡1🥰1😍1
Айсберг KV-кэшей, или Как эффективно считать трансформеры
Не так давно мы разбирали статью KVZap от NVIDIA на тему сжатия KV-кэша. В этом посте сделаем шаг назад и посмотрим шире: какие в целом есть проблемы у подхода, почему он становится узким местом в проде и как решаются инфровые челленджи на практике.
В какой-то момент все, кто занимается авторегрессионными трансформерами, приходят к мысли: в каузальном аттеншне прошлые токены не зависят от нового. Значит, K и V для уже увиденных токенов можно посчитать один раз, сохранить и переиспользовать при авторегрессионной генерации. Казалось бы, — вот она, победа.
Но дальше всплывает «айсберг». KV-кэш быстро становится гигантским, потому что растёт сразу по нескольким осям: число слоёв, длина контекста, число KV‑голов, head_dim и dtype. Например, если хранить KV в FP16/BF16 (2 байта), то для контекста 8K порядок цифр на одну последовательность получается примерно такой:
- 2 ГБ для моделей 30B с GQA (зависит от точной архитектуры);
- 4 ГБ для LLaMA‑2‑7B;
- 36 ГБ для GPT‑3‑175B.
И это ещё до того, как мы вспомним о большом количестве одновременных пользователей. Закономерный вопрос: как такое внедрять в прод?
Где обычно ужимают KV-кэш
Хорошая новость: оптимизироваться можно почти по любой размерности, используя разные подходы. Например:
- по головам — Multi‑Query или Grouped‑Query Attention (меньше K/V-голов при том же числе Q-голов);
- по слоям или доступному контексту — Sliding Window Attention (держим только окно последних W-токенов);
- по dtype — квантизации;
- по head_dim — подходы, вроде Multi Latent Attention;
- и отдельный класс — умное сокращение контекста, например KVZip и KVZap.
На последнем пункте остановимся подробнее.
KVZip/KVZap — это «умное выкидывание» токенов (а точнее, KV-пар) по важности для контекста. KVZip оценивает важность через аттеншн при реконструкции промпта (teacher‑forcing) — но для этого нужен дополнительный прогон. KVZap предсказывает важность по скрытому состоянию и режет по порогу, делая сжатие адаптивным. Главное ограничение подхода — пока нет хорошей реализации, совместимой с Paged Attention (неравномерная длина кэша для голов требует работы с блоками переменной длины), что критично для использования в высоконагруженной системе.
Немного GPU-реальности
Даже с красивым прунингом остаётся системная проблема: если аллоцировать KV-кэш как один большой непрерывный блок, память со временем фрагментируется. В итоге могут оставаться «дырки», куда уже не помещаются новые большие кэши, хотя суммарно свободной памяти вроде бы достаточно. Из-за этого возникает серьёзная недоутилизация GPU-памяти.
Типовое решение — Paged Attention: KV-кэш режут на страницы фиксированного размера и управляют ими через таблицу блоков. Вместо одного большого куска появляются небольшие блоки, которыми проще управлять и переиспользовать между запросами.
Как это используют
Есть несколько популярных проектов, которые по-разному решают задачу KV-кэша. Разберём некоторые из них.
1) vLLM — цельный inference‑движок вокруг Paged Attention
Плюсы:
- зрелая реализация paged‑подхода;
- multi‑GPU (tensor parallel) и коммуникации через NCCL;
- опенсорс.
Минусы:
- сложнее «вклинивать» нестандартные политики работы с KV (не всегда удобно расширять под свои эксперименты);
- KV‑кэш в основном локален узлу/серверу (шаринг и распределённое хранение — отдельная задача).
2) LMCache — KV‑кэш как отдельный слой (многоуровневый)
Плюсы:
- явная работа со страницами или блоками и несколькими уровнями кэша (GPU, CPU, SSD, распределённый);
- поддержка распределённого хранения KV;
- фокус на расширяемости и интеграции;
- опенсорс.
Минус:
- сочетание с оптимизациями внутри узла (NVLink/NVSwitch, tensor parallel) зависит от конкретной интеграции с движком и не всегда «из коробки».
В итоге можно сказать, что KV-кэш — важный фактор, который определяет, как модель будет работать в проде. Уже есть подходы, которые помогают сократить объём кэша, но без продуманной архитектуры хранения и управления памятью, проблему они не решают.
@RecSysChannel
Разбор подготовил❣ Кирилл Маляев
Не так давно мы разбирали статью KVZap от NVIDIA на тему сжатия KV-кэша. В этом посте сделаем шаг назад и посмотрим шире: какие в целом есть проблемы у подхода, почему он становится узким местом в проде и как решаются инфровые челленджи на практике.
В какой-то момент все, кто занимается авторегрессионными трансформерами, приходят к мысли: в каузальном аттеншне прошлые токены не зависят от нового. Значит, K и V для уже увиденных токенов можно посчитать один раз, сохранить и переиспользовать при авторегрессионной генерации. Казалось бы, — вот она, победа.
Но дальше всплывает «айсберг». KV-кэш быстро становится гигантским, потому что растёт сразу по нескольким осям: число слоёв, длина контекста, число KV‑голов, head_dim и dtype. Например, если хранить KV в FP16/BF16 (2 байта), то для контекста 8K порядок цифр на одну последовательность получается примерно такой:
- 2 ГБ для моделей 30B с GQA (зависит от точной архитектуры);
- 4 ГБ для LLaMA‑2‑7B;
- 36 ГБ для GPT‑3‑175B.
И это ещё до того, как мы вспомним о большом количестве одновременных пользователей. Закономерный вопрос: как такое внедрять в прод?
Где обычно ужимают KV-кэш
Хорошая новость: оптимизироваться можно почти по любой размерности, используя разные подходы. Например:
- по головам — Multi‑Query или Grouped‑Query Attention (меньше K/V-голов при том же числе Q-голов);
- по слоям или доступному контексту — Sliding Window Attention (держим только окно последних W-токенов);
- по dtype — квантизации;
- по head_dim — подходы, вроде Multi Latent Attention;
- и отдельный класс — умное сокращение контекста, например KVZip и KVZap.
На последнем пункте остановимся подробнее.
KVZip/KVZap — это «умное выкидывание» токенов (а точнее, KV-пар) по важности для контекста. KVZip оценивает важность через аттеншн при реконструкции промпта (teacher‑forcing) — но для этого нужен дополнительный прогон. KVZap предсказывает важность по скрытому состоянию и режет по порогу, делая сжатие адаптивным. Главное ограничение подхода — пока нет хорошей реализации, совместимой с Paged Attention (неравномерная длина кэша для голов требует работы с блоками переменной длины), что критично для использования в высоконагруженной системе.
Немного GPU-реальности
Даже с красивым прунингом остаётся системная проблема: если аллоцировать KV-кэш как один большой непрерывный блок, память со временем фрагментируется. В итоге могут оставаться «дырки», куда уже не помещаются новые большие кэши, хотя суммарно свободной памяти вроде бы достаточно. Из-за этого возникает серьёзная недоутилизация GPU-памяти.
Типовое решение — Paged Attention: KV-кэш режут на страницы фиксированного размера и управляют ими через таблицу блоков. Вместо одного большого куска появляются небольшие блоки, которыми проще управлять и переиспользовать между запросами.
Как это используют
Есть несколько популярных проектов, которые по-разному решают задачу KV-кэша. Разберём некоторые из них.
1) vLLM — цельный inference‑движок вокруг Paged Attention
Плюсы:
- зрелая реализация paged‑подхода;
- multi‑GPU (tensor parallel) и коммуникации через NCCL;
- опенсорс.
Минусы:
- сложнее «вклинивать» нестандартные политики работы с KV (не всегда удобно расширять под свои эксперименты);
- KV‑кэш в основном локален узлу/серверу (шаринг и распределённое хранение — отдельная задача).
2) LMCache — KV‑кэш как отдельный слой (многоуровневый)
Плюсы:
- явная работа со страницами или блоками и несколькими уровнями кэша (GPU, CPU, SSD, распределённый);
- поддержка распределённого хранения KV;
- фокус на расширяемости и интеграции;
- опенсорс.
Минус:
- сочетание с оптимизациями внутри узла (NVLink/NVSwitch, tensor parallel) зависит от конкретной интеграции с движком и не всегда «из коробки».
В итоге можно сказать, что KV-кэш — важный фактор, который определяет, как модель будет работать в проде. Уже есть подходы, которые помогают сократить объём кэша, но без продуманной архитектуры хранения и управления памятью, проблему они не решают.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15👍7🔥5👏1
Efficient Sequential Recommendation for Long Term User Interest Via Personalization
Сегодня разберём недавнюю статью от Meta* на тему сжатия историй в sequential рекомендательных моделях.
Авторы исследуют, как сжимать long-term-историю пользователя так, чтобы её можно было эффективно обрабатывать на инференсе и при этом не потерять в качестве. Это не новая архитектура, а скорее фреймворк или метод сжатия истории, который можно применять к разным моделям. Например, в статье рассматриваются HSTU и HLLM.
Проблема
Sequential recommender обычно строится на трансформерной архитектуре, которая страдает от квадратичной сложности механизма аттешнна. Из-за этого обрабатывать длинные последовательности вычислительно дорого, хоть они и приносят стабильный профит.
В релевантных работах эту проблему решают в два этапа: сначала long-term-историю сокращают (например, семплируют или кластеризуют события), а затем объединяют с последними событиями и прогоняют через модель. В статье приводят примеры подходов KuaiFormer, SIM, TWIN V2.
Идея
Авторы предлагают новый подход — сжимать историю с помощью выучиваемых токенов (personalized experts).
Длинную историю разбивают на сегменты — например по сессиям, дням или фиксированному числу событий. Затем каждый сегмент сжимают в несколько токенов-«экспертов», которые используются для дальнейших предсказаний. При этом последний сегмент истории на момент предсказания не сжимается — модель видит его полностью.
Обучение
Обучение авторегрессивное, используется специальная аттеншн-маска: каждый токен может смотреть на предыдущие токены своего сегмента и на «экспертов» из предыдущих сегментов, при этом сами токены этих сегментов скрыты маской.
Модель обучается стандартно на задачу next item prediction, при этом для «экспертов» лосс не считается.
На инференсе сегменты обрабатывают последовательно, а key- и value-эмбеддинги сжимающих токенов сохраняются. При предсказании следующего айтема используют только текущий сегмент и сохраненные key и value «экспертов» с предыдущих сегментов. Благодаря этому пропадает необходимость обрабатывать всю long-term-историю как одну длинную последовательность.
Интересно, что на обучении появляется лишь небольшой оверхед из-за добавленных токенов, однако на инференсе выигрыш существенный: в экспериментальном сетапе получают примерно четверть от исходной вычислительной стоимости.
Эксперименты
Они проводятся на двух датасетах:
- MerRec — e-commerce датасет из Mercari;
- EB-NeRD — новостной датасет из газеты Ekstra Bladet.
Метод почти полностью сохраняет качество моделей на полной истории и заметно превосходит варианты, где используется только recent-история. На MerRec метрики даже немного лучше бейзлайна с полной историей.
Авторы также показывают, что количество «экспертов» почти не влияет на качество, а сжатое представление long-term-истории можно переиспользовать довольно долго без заметной деградации. Лучше всего сработала такая схема: вставить всех «экспертов» после одного большого претрейн-сегмента.
Как оказалось при анализе результатов, «эксперты» часто содержат информацию по небольшому набору айтемов из истории, релевантных таргетному. Например, для айтема “LEGO” среди наиболее важных элементов из истории оказываются другие LEGO-товары.
Исходный код доступен на GitHub.
@RecSysChannel
Разбор подготовил❣ Никита Степанов
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Сегодня разберём недавнюю статью от Meta* на тему сжатия историй в sequential рекомендательных моделях.
Авторы исследуют, как сжимать long-term-историю пользователя так, чтобы её можно было эффективно обрабатывать на инференсе и при этом не потерять в качестве. Это не новая архитектура, а скорее фреймворк или метод сжатия истории, который можно применять к разным моделям. Например, в статье рассматриваются HSTU и HLLM.
Проблема
Sequential recommender обычно строится на трансформерной архитектуре, которая страдает от квадратичной сложности механизма аттешнна. Из-за этого обрабатывать длинные последовательности вычислительно дорого, хоть они и приносят стабильный профит.
В релевантных работах эту проблему решают в два этапа: сначала long-term-историю сокращают (например, семплируют или кластеризуют события), а затем объединяют с последними событиями и прогоняют через модель. В статье приводят примеры подходов KuaiFormer, SIM, TWIN V2.
Идея
Авторы предлагают новый подход — сжимать историю с помощью выучиваемых токенов (personalized experts).
Длинную историю разбивают на сегменты — например по сессиям, дням или фиксированному числу событий. Затем каждый сегмент сжимают в несколько токенов-«экспертов», которые используются для дальнейших предсказаний. При этом последний сегмент истории на момент предсказания не сжимается — модель видит его полностью.
Обучение
Обучение авторегрессивное, используется специальная аттеншн-маска: каждый токен может смотреть на предыдущие токены своего сегмента и на «экспертов» из предыдущих сегментов, при этом сами токены этих сегментов скрыты маской.
Модель обучается стандартно на задачу next item prediction, при этом для «экспертов» лосс не считается.
На инференсе сегменты обрабатывают последовательно, а key- и value-эмбеддинги сжимающих токенов сохраняются. При предсказании следующего айтема используют только текущий сегмент и сохраненные key и value «экспертов» с предыдущих сегментов. Благодаря этому пропадает необходимость обрабатывать всю long-term-историю как одну длинную последовательность.
Интересно, что на обучении появляется лишь небольшой оверхед из-за добавленных токенов, однако на инференсе выигрыш существенный: в экспериментальном сетапе получают примерно четверть от исходной вычислительной стоимости.
Эксперименты
Они проводятся на двух датасетах:
- MerRec — e-commerce датасет из Mercari;
- EB-NeRD — новостной датасет из газеты Ekstra Bladet.
Метод почти полностью сохраняет качество моделей на полной истории и заметно превосходит варианты, где используется только recent-история. На MerRec метрики даже немного лучше бейзлайна с полной историей.
Авторы также показывают, что количество «экспертов» почти не влияет на качество, а сжатое представление long-term-истории можно переиспользовать довольно долго без заметной деградации. Лучше всего сработала такая схема: вставить всех «экспертов» после одного большого претрейн-сегмента.
Как оказалось при анализе результатов, «эксперты» часто содержат информацию по небольшому набору айтемов из истории, релевантных таргетному. Например, для айтема “LEGO” среди наиболее важных элементов из истории оказываются другие LEGO-товары.
Исходный код доступен на GitHub.
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14❤11🔥7
QARM V2: Quantitative Alignment Multi-Modal Recommendation for Reasoning User Sequence Modeling
Сегодня разбираем статью от Kuaishou о том, как использовать LLM для формирования семантических фичей в ранжирующих моделях.
В индустрии для ранжирования используют трансформеры. История действий пользователя представляется в виде последовательности айтемов, и модель учится предсказывать на её основе, будет ли релевантен тот или иной новый айтем из числа кандидатов.
Когда последовательности становятся длинными, используют двухэтапную схему:
1) General Search Unit (GSU) выбирает из истории пользователя айтемы, наиболее близкие к текущему кандидату;
2) Exact Search Unit (ESU) точно оценивает релевантность кандидата по этой сжатой истории.
Такая схема давно устоялась и хорошо работает. Но в ней всё критически зависит от того, какие именно эмбеддинги используются для айтемов. Классические модели опираются на ID-based-эмбеддинги. Авторы формулируют фундаментальные ограничения такого подхода:
- низкая информативность (эмбеддинг не раскрывает семантику);
- изолированность знаний;
- слабая генерализация без постоянного дообучения;
- проблемы long-tail и cold start.
LLM-эмбеддинги выглядят как альтернатива: они содержат плотную семантику, обобщают знания и хорошо генерализуют. Но на практике их использование в «зафриженном» виде даёт лишь ограниченный прирост качества.
Причина в рассинхроне с задачей рекомендаций:
- Representation Unmatch — LLM понимает айтем, но не его релевантность пользователю;
- Representation Unlearning — эмбеддинги нельзя обучать end-to-end вместе с моделью.
QARM V2 решает эту проблему, адаптируя LLM-эмбеддинги под задачу рекомендаций через механизм Reasoning Item Alignment. Идея подхода в том, чтобы затюнить LLM под генерацию эмбеддингов, одновременно отражающих хорошее понимание айтемов и способных предсказывать их со-встречаемость:
1) на основе коллаборативных моделей собираются item-item-пары в качестве таргета для контрастивного обучения;
2) пары фильтруются, убирается шум и bias на популярные айтемы;
3) для айтемов также генерируются QA-пары в качестве таргета для генерации ответов;
4) обучение идёт по схеме «входные данные -> EMB-токены –> генерация ответов + контрастивный лосс».
Важно, что контрастивный лосс считается по EMB-токенам, и через них же модель отвечает на заранее подготовленные вопросы. В итоге всё понимание айтема сжимается в компактный эмбеддинг, — одновременно семантический и коллаборативный.
Вторая часть пайплайна — построение semantic IDs через квантизацию. Базовый Residual KMeans хорошо ловит грубую семантику, но даёт много коллизий (разные айтемы получают одинаковые коды).
Авторы предлагают гибрид, в котором верхние уровни (Residual KMeans) захватывают грубую семантику, а последний (FSQ) помогает различать близкие айтемы и снижает коллизии.
Дальше подход встраивается в обычную схему GSU/ESU. Сначала с помощью полученных LLM эмбеддингов из истории пользователя выбираются наиболее близкие кандидату айтемы, а затем уже в ESU используются semantic IDs как признаки для более точного ранжирования.
Важно, что эмбеддинги для semantic IDs обучаются end-to-end вместе с ранжирующей моделью, в отличие от зафриженных LLM-эмбеддингов.
По результатам всё выглядит ожидаемо «сильным»: стабильные улучшения в офлайн-метриках, заметный буст в cold-start-сценариях, снижение количества коллизий после новой квантизации. Основные бизнес-метрики (CTR, GMV) демонстрируют ощутимые приросты в онлайн-экспериментах.
В целом работа показывает, что ключевой эффект даёт не просто использование эмбеддингов из LLM, а их правильный алайнмент под задачу рекомендаций.
@RecSysChannel
Разбор подготовила❣ Дарья Тихонович
Сегодня разбираем статью от Kuaishou о том, как использовать LLM для формирования семантических фичей в ранжирующих моделях.
В индустрии для ранжирования используют трансформеры. История действий пользователя представляется в виде последовательности айтемов, и модель учится предсказывать на её основе, будет ли релевантен тот или иной новый айтем из числа кандидатов.
Когда последовательности становятся длинными, используют двухэтапную схему:
1) General Search Unit (GSU) выбирает из истории пользователя айтемы, наиболее близкие к текущему кандидату;
2) Exact Search Unit (ESU) точно оценивает релевантность кандидата по этой сжатой истории.
Такая схема давно устоялась и хорошо работает. Но в ней всё критически зависит от того, какие именно эмбеддинги используются для айтемов. Классические модели опираются на ID-based-эмбеддинги. Авторы формулируют фундаментальные ограничения такого подхода:
- низкая информативность (эмбеддинг не раскрывает семантику);
- изолированность знаний;
- слабая генерализация без постоянного дообучения;
- проблемы long-tail и cold start.
LLM-эмбеддинги выглядят как альтернатива: они содержат плотную семантику, обобщают знания и хорошо генерализуют. Но на практике их использование в «зафриженном» виде даёт лишь ограниченный прирост качества.
Причина в рассинхроне с задачей рекомендаций:
- Representation Unmatch — LLM понимает айтем, но не его релевантность пользователю;
- Representation Unlearning — эмбеддинги нельзя обучать end-to-end вместе с моделью.
QARM V2 решает эту проблему, адаптируя LLM-эмбеддинги под задачу рекомендаций через механизм Reasoning Item Alignment. Идея подхода в том, чтобы затюнить LLM под генерацию эмбеддингов, одновременно отражающих хорошее понимание айтемов и способных предсказывать их со-встречаемость:
1) на основе коллаборативных моделей собираются item-item-пары в качестве таргета для контрастивного обучения;
2) пары фильтруются, убирается шум и bias на популярные айтемы;
3) для айтемов также генерируются QA-пары в качестве таргета для генерации ответов;
4) обучение идёт по схеме «входные данные -> EMB-токены –> генерация ответов + контрастивный лосс».
Важно, что контрастивный лосс считается по EMB-токенам, и через них же модель отвечает на заранее подготовленные вопросы. В итоге всё понимание айтема сжимается в компактный эмбеддинг, — одновременно семантический и коллаборативный.
Вторая часть пайплайна — построение semantic IDs через квантизацию. Базовый Residual KMeans хорошо ловит грубую семантику, но даёт много коллизий (разные айтемы получают одинаковые коды).
Авторы предлагают гибрид, в котором верхние уровни (Residual KMeans) захватывают грубую семантику, а последний (FSQ) помогает различать близкие айтемы и снижает коллизии.
Дальше подход встраивается в обычную схему GSU/ESU. Сначала с помощью полученных LLM эмбеддингов из истории пользователя выбираются наиболее близкие кандидату айтемы, а затем уже в ESU используются semantic IDs как признаки для более точного ранжирования.
Важно, что эмбеддинги для semantic IDs обучаются end-to-end вместе с ранжирующей моделью, в отличие от зафриженных LLM-эмбеддингов.
По результатам всё выглядит ожидаемо «сильным»: стабильные улучшения в офлайн-метриках, заметный буст в cold-start-сценариях, снижение количества коллизий после новой квантизации. Основные бизнес-метрики (CTR, GMV) демонстрируют ощутимые приросты в онлайн-экспериментах.
В целом работа показывает, что ключевой эффект даёт не просто использование эмбеддингов из LLM, а их правильный алайнмент под задачу рекомендаций.
@RecSysChannel
Разбор подготовила
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15🔥9👍4🥰1👌1
Generative Recommendation for Large-Scale Advertising
Сегодня разбираем статью, где авторы из Kuaishou расширяют парадигму OneRec на рекламный домен. Они выделяют три проблемы, которые в рекламных рекомендациях проявляются особенно остро по сравнению с обычными LLM.
1. Рекламу сложно токенизировать: одно объявление — это сразу видео, текст, продукт, бренд, рекламодатель и бизнес-метаданные.
2. Важно не просто генерировать рекомендации — важен порядок объявлений в выдаче и eCPM.
3. Всё это должно работать в проде с жёсткими ограничениями по latency.
Ответом становится GR4AD (Generative Recommendation for ADdvertising) — генеративная рекламная система, в которой для каждой из этих проблем есть отдельное решение.
Нововведения такие:
- UA-SID (unified advertisement semantic ID) — единый семантический идентификатор объявления. Объявление прогоняют через мультимодальную модель с instruction tuning для получения эмбеда с учётом прикладной семантики (контент, продукт, рекламодатель и так далее). Потом с помощью co-occurrence learning дообучают эмбеддинги под рекламный домен. Это нужно, чтобы модель лучше улавливала совместимость между рекламными сущностями. Далее полученные эмбеды с помощью MGMR RQ-KMeans квантуют в многоуровневые SID. Первые уровни ловят грубую семантику, следующие — уточняют остаточную информацию. Последний токен — хэш бизнес-ID для борьбы с коллизиями.
- LazyAR ускоряет декодер. Самый важный первый токен генерируется честно авторегрессивно, а часть промежуточных слоёв переиспользуется и считается не авторегрессивно. Для сохранения качества на выходы этих слоев навешивается дополнительный MTP-loss.
- VSL+RSPO — VSL добавляет в обучение бизнес-сигнал: модель предсказывает не только последовательность SID-токенов, но и дискретизированный eCPM. Добавляют перевзвешивание: более ценные пользователи и более важные действия получают больший вес. RSPO — RL-style компонента для list-wise-оптимизации. Вместо point-wise-обучения модель учат ранжировать список объявлений так, чтобы улучшать NDCG.
Ещё можно отметить оптимизации, например Dynamic Beam Serving, который подстраивает beam search под стадию генерации и текущую нагрузку. На ранних шагах beam шире. При высоком QPS — уже. Добавляются TTL-кэши, beam-cache, KV-cache, FP8.
Система построена как замкнутый цикл, в котором новые объявления переводятся в UA-SID и попадают в realtime index. При запросе модель генерирует и ранжирует кандидатов, после чего их показывают пользователю. Дальше система собирает reward-сигналы и отправляет их в онлайн-обучение, где обновляются VSL и RSPO. Так, модель постоянно дообучается на живом трафике.
Результаты у статьи впечатляющие. UA-SID сам по себе даёт ограниченный прирост к базовому генеративному ранкеру, основной буст происходит от способа обучения: VSL + RSPO заметно поднимают revenue относительно OneRec-V2. Сервисные оптимизации тоже ощутимые: LazyAR почти удваивает QPS без заметной просадки по качеству, а DBS помогает поймать баланс между скоростью и доходом. В A/B-тестах репортят увеличение рекламной выручки до 4,2% по сравнению с сильным бейзлайном на основе DLRM. Модель здорово масштабируется по качеству в зависимости от beam search width и количества параметров.
В целом работа выглядит как практичная попытка «приземлить» генеративные рекомендации в рекламу. Главная мысль статьи в том, что для использования LLM в рекламе, нужно учитывать специфику домена — например, свои SID, business-aware-лоссы и serving-оптимизации.
@RecSysChannel
Обзор подготовила❣ Маргарита Мишустина
Сегодня разбираем статью, где авторы из Kuaishou расширяют парадигму OneRec на рекламный домен. Они выделяют три проблемы, которые в рекламных рекомендациях проявляются особенно остро по сравнению с обычными LLM.
1. Рекламу сложно токенизировать: одно объявление — это сразу видео, текст, продукт, бренд, рекламодатель и бизнес-метаданные.
2. Важно не просто генерировать рекомендации — важен порядок объявлений в выдаче и eCPM.
3. Всё это должно работать в проде с жёсткими ограничениями по latency.
Ответом становится GR4AD (Generative Recommendation for ADdvertising) — генеративная рекламная система, в которой для каждой из этих проблем есть отдельное решение.
Нововведения такие:
- UA-SID (unified advertisement semantic ID) — единый семантический идентификатор объявления. Объявление прогоняют через мультимодальную модель с instruction tuning для получения эмбеда с учётом прикладной семантики (контент, продукт, рекламодатель и так далее). Потом с помощью co-occurrence learning дообучают эмбеддинги под рекламный домен. Это нужно, чтобы модель лучше улавливала совместимость между рекламными сущностями. Далее полученные эмбеды с помощью MGMR RQ-KMeans квантуют в многоуровневые SID. Первые уровни ловят грубую семантику, следующие — уточняют остаточную информацию. Последний токен — хэш бизнес-ID для борьбы с коллизиями.
- LazyAR ускоряет декодер. Самый важный первый токен генерируется честно авторегрессивно, а часть промежуточных слоёв переиспользуется и считается не авторегрессивно. Для сохранения качества на выходы этих слоев навешивается дополнительный MTP-loss.
- VSL+RSPO — VSL добавляет в обучение бизнес-сигнал: модель предсказывает не только последовательность SID-токенов, но и дискретизированный eCPM. Добавляют перевзвешивание: более ценные пользователи и более важные действия получают больший вес. RSPO — RL-style компонента для list-wise-оптимизации. Вместо point-wise-обучения модель учат ранжировать список объявлений так, чтобы улучшать NDCG.
Ещё можно отметить оптимизации, например Dynamic Beam Serving, который подстраивает beam search под стадию генерации и текущую нагрузку. На ранних шагах beam шире. При высоком QPS — уже. Добавляются TTL-кэши, beam-cache, KV-cache, FP8.
Система построена как замкнутый цикл, в котором новые объявления переводятся в UA-SID и попадают в realtime index. При запросе модель генерирует и ранжирует кандидатов, после чего их показывают пользователю. Дальше система собирает reward-сигналы и отправляет их в онлайн-обучение, где обновляются VSL и RSPO. Так, модель постоянно дообучается на живом трафике.
Результаты у статьи впечатляющие. UA-SID сам по себе даёт ограниченный прирост к базовому генеративному ранкеру, основной буст происходит от способа обучения: VSL + RSPO заметно поднимают revenue относительно OneRec-V2. Сервисные оптимизации тоже ощутимые: LazyAR почти удваивает QPS без заметной просадки по качеству, а DBS помогает поймать баланс между скоростью и доходом. В A/B-тестах репортят увеличение рекламной выручки до 4,2% по сравнению с сильным бейзлайном на основе DLRM. Модель здорово масштабируется по качеству в зависимости от beam search width и количества параметров.
В целом работа выглядит как практичная попытка «приземлить» генеративные рекомендации в рекламу. Главная мысль статьи в том, что для использования LLM в рекламе, нужно учитывать специфику домена — например, свои SID, business-aware-лоссы и serving-оптимизации.
@RecSysChannel
Обзор подготовила
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15🎉4👍2🔥1🐳1
Что читает команда алайнмента рекомендательных моделей
Сегодня делимся статьями, которые обсуждают инженеры Яндекса из команда алайнмента рекомендательных моделей. В подборке: новый подход к учёту мультимодальных интересов пользователей, разбор генеративной рексистемы AliExpress и исследование на тему генеративных рекомендаций.
Progressive Semantic Residual Quantization for Multimodal-Joint
Interest Modeling in Music Recommendation
В работе предлагают по-новому учитывать мультимодальные интересы пользователей.
Главная проблема предыдущих методов — при сжатии фичей трека в компактные семантические ID смысл музыки постепенно теряется. Её назвали intra-modal semantic degradation: чем больше кодбуков, тем больше семантические ID отражают мелкие технические детали вместо реального содержания трека.
Вторая проблема — inter-modal modeling gaps: старые модели либо «склеивали» все модальности (текст, аудио) в один вектор, теряя нюансы, либо, наоборот, обрабатывали их изолированно, не улавливая синергию между грустным текстом и мажорной мелодией.
Решение состоит из двух этапов:
1) Progressive Semantic Residual Quantization (PSRQ). В отличие от обычного RQ, который на каждом новом слое квантует лишь ошибку с предыдущего шага, PSRQ всегда «помнит» оригинал. Начиная со второго кодбука он смотрит не только на текущий остаток, но и на то, какая часть исходного эмбеддинга уже была закодирована, и конкатенирует такие векторы с остатками. Благодаря этому семантические ID на всех уровнях сохраняют связь с реальным смыслом трека.
2) Multi-Codebook Cross-Attention (MCCA). Авторы ввели отдельные кодбуки для аудио и текста, а также для совместного представления (modal-joint). Предпочтения пользователя моделируется через кросс-аттеншн, где в качестве query выступает modal-joint эмбеддинг таргета. Это позволяет одновременно улавливать и нюансы предпочтений по отдельным модальностям, и их корреляции («как текст трека работает в связке с битом»).
Фреймворк не только бьёт SOTA на офлайн-бенчмарках, но и в реальном A/B-тесте на крупной стриминговой платформе даёт значимый прирост в добавлении треков в избранное и количестве прослушиваний треков до конца.
SIGMA: A Semantic-Grounded Instruction-Driven Generative Multi-Task Recommender at AliExpress
AliExpress рассказывает о своей генеративной рекомендательной системе на базе LLM. Ключевое нововведение — многоуровневое семантическое выравнивание, при котором система объединяет текстовую семантику, визуальные признаки, общие знания и коллаборативные сигналы в едином латентном пространстве.
Для токенизации товаров разработали гибридный метод, сочетающий семантические ID с уникальными вектором айтема, что обеспечивает как общее, так и уникальное представление каждого товара.
Подход показывает значительные приросты в A/B-тесте: +7,84% GMV, +3,84% конверсии.
Masked Diffusion for Generative Recommendation
Статья продолжает линию исследований генеративных рекомендаций, где предсказание следующего айтема формулируется как генерация последовательности дискретных семантических токенов. Авторы предлагают отказаться от схемы «остаточная квантизация + авторегрессивная генерация» в пользу независимой токенизации через параллельные кодбуки и генерации через masked diffusion.
Качество растёт за счёт bidirectional attention при денойзинге, который позволяет каждому токену SID видеть контекст со всех сторон, а не только левый префикс, что даёт лучшую глобальную согласованность между атрибутами предмета. Также сработал произвольный порядок генерации — модель выбирает, какие позиции заполнять первыми на основе своей уверенности, что лучше соответствует тому, как пользователи по-разному обращают внимание на свойства товара.
По скорости инференса выигрыш достигается за счёт параллельного декодирования: после короткой фазы прогрева, где модель по одному закрепляет самые уверенные семантические якоря, она переключается в параллельный режим и заполняет несколько позиций SID за один шаг, сокращая число forward pass'ов.
@RecSysChannel
Статьями поделились❣ Вероника Иванова, Иван Артемьев и Илья Мурзин
Сегодня делимся статьями, которые обсуждают инженеры Яндекса из команда алайнмента рекомендательных моделей. В подборке: новый подход к учёту мультимодальных интересов пользователей, разбор генеративной рексистемы AliExpress и исследование на тему генеративных рекомендаций.
Progressive Semantic Residual Quantization for Multimodal-Joint
Interest Modeling in Music Recommendation
В работе предлагают по-новому учитывать мультимодальные интересы пользователей.
Главная проблема предыдущих методов — при сжатии фичей трека в компактные семантические ID смысл музыки постепенно теряется. Её назвали intra-modal semantic degradation: чем больше кодбуков, тем больше семантические ID отражают мелкие технические детали вместо реального содержания трека.
Вторая проблема — inter-modal modeling gaps: старые модели либо «склеивали» все модальности (текст, аудио) в один вектор, теряя нюансы, либо, наоборот, обрабатывали их изолированно, не улавливая синергию между грустным текстом и мажорной мелодией.
Решение состоит из двух этапов:
1) Progressive Semantic Residual Quantization (PSRQ). В отличие от обычного RQ, который на каждом новом слое квантует лишь ошибку с предыдущего шага, PSRQ всегда «помнит» оригинал. Начиная со второго кодбука он смотрит не только на текущий остаток, но и на то, какая часть исходного эмбеддинга уже была закодирована, и конкатенирует такие векторы с остатками. Благодаря этому семантические ID на всех уровнях сохраняют связь с реальным смыслом трека.
2) Multi-Codebook Cross-Attention (MCCA). Авторы ввели отдельные кодбуки для аудио и текста, а также для совместного представления (modal-joint). Предпочтения пользователя моделируется через кросс-аттеншн, где в качестве query выступает modal-joint эмбеддинг таргета. Это позволяет одновременно улавливать и нюансы предпочтений по отдельным модальностям, и их корреляции («как текст трека работает в связке с битом»).
Фреймворк не только бьёт SOTA на офлайн-бенчмарках, но и в реальном A/B-тесте на крупной стриминговой платформе даёт значимый прирост в добавлении треков в избранное и количестве прослушиваний треков до конца.
SIGMA: A Semantic-Grounded Instruction-Driven Generative Multi-Task Recommender at AliExpress
AliExpress рассказывает о своей генеративной рекомендательной системе на базе LLM. Ключевое нововведение — многоуровневое семантическое выравнивание, при котором система объединяет текстовую семантику, визуальные признаки, общие знания и коллаборативные сигналы в едином латентном пространстве.
Для токенизации товаров разработали гибридный метод, сочетающий семантические ID с уникальными вектором айтема, что обеспечивает как общее, так и уникальное представление каждого товара.
Подход показывает значительные приросты в A/B-тесте: +7,84% GMV, +3,84% конверсии.
Masked Diffusion for Generative Recommendation
Статья продолжает линию исследований генеративных рекомендаций, где предсказание следующего айтема формулируется как генерация последовательности дискретных семантических токенов. Авторы предлагают отказаться от схемы «остаточная квантизация + авторегрессивная генерация» в пользу независимой токенизации через параллельные кодбуки и генерации через masked diffusion.
Качество растёт за счёт bidirectional attention при денойзинге, который позволяет каждому токену SID видеть контекст со всех сторон, а не только левый префикс, что даёт лучшую глобальную согласованность между атрибутами предмета. Также сработал произвольный порядок генерации — модель выбирает, какие позиции заполнять первыми на основе своей уверенности, что лучше соответствует тому, как пользователи по-разному обращают внимание на свойства товара.
По скорости инференса выигрыш достигается за счёт параллельного декодирования: после короткой фазы прогрева, где модель по одному закрепляет самые уверенные семантические якоря, она переключается в параллельный режим и заполняет несколько позиций SID за один шаг, сокращая число forward pass'ов.
@RecSysChannel
Статьями поделились
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14👍9🔥8👏1
Masked Diffusion Generative Recommendation
В прошлом посте мы упомянули статью MDGR. В ней от авторегрессивной генерации авторы уходят к параллельной реконструкции айтема через дискретную диффузию. Разберём детальнее, как это было сделано.
Сначала в работе перечисляют ограничения авторегрессивного подхода:
1) Нужно укладывать информацию об айтеме в строгую иерархию семантических ID, и это навязывает модели дополнительный inductive bias.
2) Генерация всегда идёт в фиксированном порядке, независимо от истории пользователя.
3) Эффективность на инференсе низкая, так как модель нужно прогонять по каждому семантическому токену.
Вместо этого предлагают поход, где генерация:
- агностична к порядку — генерируем семантик из любого кодбука первым, вторым или третьим, и это определяется историей пользователя;
- итеративно улучшает предсказания — следующие семантики уточняются с учётом сгенерированных;
- происходит параллельно, что ускоряет инференс.
Этим пунктам соответствует генерация на базе дискретной диффузии. Модель работает с замаскированными семантическими токенами и учится их расшумлять, восстанавливая по истории пользователя. В отличие от каузальной генерации здесь токены могут учитывать весь текущий контекст.
Но появляется вопрос, как использовать диффузионку в качестве кандидата-генератора. Она умеет расшумлять все токены сразу, но непонятно, как получить несколько объектов. Поэтому вводят гибридную схему с элементами beam search. Модель фиксирует самые уверенные токены и дальше — по следующим по уверенности семантикам — отбираются кандидаты.
Чтобы заалайнить диффузию под рекомендательный домен, вводят history-aware masking allocation strategy. В отличие от равномерного маскирования учитывается, что семантические токены разные по сложности. Поэтому чаще маскируются те, которые реже встречались в истории пользователя, — такие семантики для модели сложнее предсказать. То есть задачу обучения дополнительно усложняют и за счёт этого получают прирост качества по сравнению с равномерным маскированием.
Авторы используют параллельные семантики, то есть айтем представляется через несколько независимых кодбуков. Эмбеддинг разбивается на несколько подпространств, и каждое из них квантизируется отдельно, в результате получаем набор независимых семантических ID.
На инференсе к истории пользователя подклеиваются mask-токены по числу семантиков, которые модель должна расшумить. Сначала происходит варм-ап, на котором модель фиксирует один самый уверенный токен. Причём это может быть любая позиция, в зависимости от того, где модель больше уверена. После нескольких таких шагов модель переходит к параллельной генерации и за один проход может фиксировать сразу несколько семантиков.
Количество варм-ап-шагов и ширина beam search влияют на качество и скорость инференса. Если делать слишком мало шагов, качество падает, потому что семантики хуже обусловлены друг на друга. Если делать больше шагов, качество растёт, но при этом теряется выигрыш в скорости.
На офлайн-датасетах Amazon Books и Electronics модель показывает SOTA среди item- и semantic-based-подходов. При этом она достаточно небольшая модель: шестислойный трансформер с hidden size порядка 256. На онлайн-тестах репортят рост GMV и CTR.
@RecSysChannel
Разбор подготовил❣ Илья Мурзин
В прошлом посте мы упомянули статью MDGR. В ней от авторегрессивной генерации авторы уходят к параллельной реконструкции айтема через дискретную диффузию. Разберём детальнее, как это было сделано.
Сначала в работе перечисляют ограничения авторегрессивного подхода:
1) Нужно укладывать информацию об айтеме в строгую иерархию семантических ID, и это навязывает модели дополнительный inductive bias.
2) Генерация всегда идёт в фиксированном порядке, независимо от истории пользователя.
3) Эффективность на инференсе низкая, так как модель нужно прогонять по каждому семантическому токену.
Вместо этого предлагают поход, где генерация:
- агностична к порядку — генерируем семантик из любого кодбука первым, вторым или третьим, и это определяется историей пользователя;
- итеративно улучшает предсказания — следующие семантики уточняются с учётом сгенерированных;
- происходит параллельно, что ускоряет инференс.
Этим пунктам соответствует генерация на базе дискретной диффузии. Модель работает с замаскированными семантическими токенами и учится их расшумлять, восстанавливая по истории пользователя. В отличие от каузальной генерации здесь токены могут учитывать весь текущий контекст.
Но появляется вопрос, как использовать диффузионку в качестве кандидата-генератора. Она умеет расшумлять все токены сразу, но непонятно, как получить несколько объектов. Поэтому вводят гибридную схему с элементами beam search. Модель фиксирует самые уверенные токены и дальше — по следующим по уверенности семантикам — отбираются кандидаты.
Чтобы заалайнить диффузию под рекомендательный домен, вводят history-aware masking allocation strategy. В отличие от равномерного маскирования учитывается, что семантические токены разные по сложности. Поэтому чаще маскируются те, которые реже встречались в истории пользователя, — такие семантики для модели сложнее предсказать. То есть задачу обучения дополнительно усложняют и за счёт этого получают прирост качества по сравнению с равномерным маскированием.
Авторы используют параллельные семантики, то есть айтем представляется через несколько независимых кодбуков. Эмбеддинг разбивается на несколько подпространств, и каждое из них квантизируется отдельно, в результате получаем набор независимых семантических ID.
На инференсе к истории пользователя подклеиваются mask-токены по числу семантиков, которые модель должна расшумить. Сначала происходит варм-ап, на котором модель фиксирует один самый уверенный токен. Причём это может быть любая позиция, в зависимости от того, где модель больше уверена. После нескольких таких шагов модель переходит к параллельной генерации и за один проход может фиксировать сразу несколько семантиков.
Количество варм-ап-шагов и ширина beam search влияют на качество и скорость инференса. Если делать слишком мало шагов, качество падает, потому что семантики хуже обусловлены друг на друга. Если делать больше шагов, качество растёт, но при этом теряется выигрыш в скорости.
На офлайн-датасетах Amazon Books и Electronics модель показывает SOTA среди item- и semantic-based-подходов. При этом она достаточно небольшая модель: шестислойный трансформер с hidden size порядка 256. На онлайн-тестах репортят рост GMV и CTR.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13🔥10👍7🕊1
A Unified Language Model for Large Scale Search, Recommendation, and Reasoning
В сегодняшней статье Spotify представляют NEO — унифицированную модель decoder-only, которая работает с гетерогенными данными (текст и рекомендательные объекты). При этом она должна удовлетворять жёстким требованиям к качеству выдачи и латентности.
Традиционные рекомендательные системы, несмотря на доказанную эффективность на больших объёмах данных, по-прежнему плохо справляются с двумя задачами: пониманием неявных пользовательских интересов и обобщением текстовых представлений объектов.
В статье обращают внимание на то, что существующие подходы не умеют одновременно рассуждать над доменными объектами, пользовательским поведением и естественным языком. Вдохновляясь мультимодальными архитектурами, авторы NEO решают эту проблему, интерпретируя Semantic ID объектов как отдельную модальность наравне с текстовыми токенами. Обучение ведут на смешанных данных, где в текстовые последовательности подмешивают идентификаторы рекомендательных объектов.
Предложенный фреймворк поддерживает несколько режимов: генерацию рекомендаций, генерацию текстов, текстовый ретривал, а также адаптацию ответов на основе инструкций. Обучение модели проходит в три этапа:
1. Создание семантических представлений (Semantic ID creation). Формируется база соответствий «объект — Semantic ID», которая задаёт словарь доменных токенов. То есть в дальнейшем модель сможет ссылаться на конкретные объекты.
2. Формирование знаний о домене (Domain Grounding). Модель учится воспринимать Semantic ID наравне с текстовыми токенами, выстраивая единое представление для обоих типов данных. Цель — научить модель воспринимать доменные токены как полноценную часть языка: понимать контекст вокруг них, связывать их с текстовыми описаниями и выстраивать единое семантическое пространство для обеих модальностей.
3. Формирование навыков через инструкции (Capability Induction via Instruction Tuning). Модель дообучается на конкретных задачах: next item prediction, ретривал по текстовым запросам, описание интересов пользователя, обоснование рекомендаций.
Чтобы показать, что фреймворк не привязан к конкретной архитектуре, авторы провели адаптацию Llama 3.2 1B с использованием NEO. Стадия Domain Grounding дала прирост около 18% в текстовом ретривале, что подтверждает эффективность подхода.
Авторы проводят серию аблейшнов, которые подтверждают, что выбранная архитектура обучения обоснована. Наивная замена Semantic ID на стандартные идентификаторы, схлопывание стадий алайнмента в одну или переход на continuous pretrain ухудшают либо качество рекомендаций, либо способность модели генерировать связные тексты.
Особенно это заметно на задачах, требующих строгого следования инструкциям, и при генерации последовательностей смешанной структуры (текст + рекомендательные объекты). В офлайн-экспериментах NEO демонстрирует небольшой, но стабильный прирост над базовыми моделями в монозадачах по метрикам HR@K и NDCG@K.
@RecSysChannel
Обзор подготовила❣ Василиса Григорьева
В сегодняшней статье Spotify представляют NEO — унифицированную модель decoder-only, которая работает с гетерогенными данными (текст и рекомендательные объекты). При этом она должна удовлетворять жёстким требованиям к качеству выдачи и латентности.
Традиционные рекомендательные системы, несмотря на доказанную эффективность на больших объёмах данных, по-прежнему плохо справляются с двумя задачами: пониманием неявных пользовательских интересов и обобщением текстовых представлений объектов.
В статье обращают внимание на то, что существующие подходы не умеют одновременно рассуждать над доменными объектами, пользовательским поведением и естественным языком. Вдохновляясь мультимодальными архитектурами, авторы NEO решают эту проблему, интерпретируя Semantic ID объектов как отдельную модальность наравне с текстовыми токенами. Обучение ведут на смешанных данных, где в текстовые последовательности подмешивают идентификаторы рекомендательных объектов.
Предложенный фреймворк поддерживает несколько режимов: генерацию рекомендаций, генерацию текстов, текстовый ретривал, а также адаптацию ответов на основе инструкций. Обучение модели проходит в три этапа:
1. Создание семантических представлений (Semantic ID creation). Формируется база соответствий «объект — Semantic ID», которая задаёт словарь доменных токенов. То есть в дальнейшем модель сможет ссылаться на конкретные объекты.
2. Формирование знаний о домене (Domain Grounding). Модель учится воспринимать Semantic ID наравне с текстовыми токенами, выстраивая единое представление для обоих типов данных. Цель — научить модель воспринимать доменные токены как полноценную часть языка: понимать контекст вокруг них, связывать их с текстовыми описаниями и выстраивать единое семантическое пространство для обеих модальностей.
3. Формирование навыков через инструкции (Capability Induction via Instruction Tuning). Модель дообучается на конкретных задачах: next item prediction, ретривал по текстовым запросам, описание интересов пользователя, обоснование рекомендаций.
Чтобы показать, что фреймворк не привязан к конкретной архитектуре, авторы провели адаптацию Llama 3.2 1B с использованием NEO. Стадия Domain Grounding дала прирост около 18% в текстовом ретривале, что подтверждает эффективность подхода.
Авторы проводят серию аблейшнов, которые подтверждают, что выбранная архитектура обучения обоснована. Наивная замена Semantic ID на стандартные идентификаторы, схлопывание стадий алайнмента в одну или переход на continuous pretrain ухудшают либо качество рекомендаций, либо способность модели генерировать связные тексты.
Особенно это заметно на задачах, требующих строгого следования инструкциям, и при генерации последовательностей смешанной структуры (текст + рекомендательные объекты). В офлайн-экспериментах NEO демонстрирует небольшой, но стабильный прирост над базовыми моделями в монозадачах по метрикам HR@K и NDCG@K.
@RecSysChannel
Обзор подготовила
Please open Telegram to view this post
VIEW IN TELEGRAM
❤17🔥13👍10❤🔥1👏1
Пара интересных статей с ICLR 2026 в Рио
В этом году работ на тему рекомендательных технологий не так много, как хотелось бы. Делимся двумя интересными: одна — о том, как лучше использовать имеющиеся сигналы, чтобы повысить качество ранжирования, другая — об ускорении и работе с памятью.
Denoising Neural Reranker for Recommender Systems
В статье исследуют стандартный подход «ретривер + реранкер». Идея в том, чтобы немного «накостылять» — в реранкере использовать каким-то образом не только сигнал от пользователя (клики, заказы, лайки), но и информацию от ретривера.
Основной подход — учить реранкер решать задачу удаления шума. Предлагается метод DNR, в котором:
1) собираем скоры ретривера и зашумляем их;
2) учим реранкер очищать простой шум;
3) начинается adversarial learning, где также учим генератор создавать неочищаемый шум;
4) для генератора распределение зашумлённых оценок должно сходиться к распределению реальных скоров ретривера.
CollectiveKV: Decoupling and Sharing Collaborative Information in Sequential Recommendation
Трансформерные модели в рекомендациях на длинных последовательностях долго инференсятся, так как они авторегрессионные. Для ускорения инференса часто используют KV-кэши, но в случаях с длинными историями они сильно раздуваются по памяти.
Авторы предлагают следующее. KV-представления пользователей декомпозируют с помощью SVD, как в стандартной коллаборативной фильтрации. Затем выделяют две части: высокоразмерную общую KV и компактные персональные KV. При инференсе предлагается «подглядывать» и туда, и туда.
По результатам удалось сжать KV-кэш до 0,8% от его исходного размера (!), не просадив качество.
#YaICLR26
@RecSysChannel
Интересное увидел❣ Александр Воронцов
В этом году работ на тему рекомендательных технологий не так много, как хотелось бы. Делимся двумя интересными: одна — о том, как лучше использовать имеющиеся сигналы, чтобы повысить качество ранжирования, другая — об ускорении и работе с памятью.
Denoising Neural Reranker for Recommender Systems
В статье исследуют стандартный подход «ретривер + реранкер». Идея в том, чтобы немного «накостылять» — в реранкере использовать каким-то образом не только сигнал от пользователя (клики, заказы, лайки), но и информацию от ретривера.
Основной подход — учить реранкер решать задачу удаления шума. Предлагается метод DNR, в котором:
1) собираем скоры ретривера и зашумляем их;
2) учим реранкер очищать простой шум;
3) начинается adversarial learning, где также учим генератор создавать неочищаемый шум;
4) для генератора распределение зашумлённых оценок должно сходиться к распределению реальных скоров ретривера.
CollectiveKV: Decoupling and Sharing Collaborative Information in Sequential Recommendation
Трансформерные модели в рекомендациях на длинных последовательностях долго инференсятся, так как они авторегрессионные. Для ускорения инференса часто используют KV-кэши, но в случаях с длинными историями они сильно раздуваются по памяти.
Авторы предлагают следующее. KV-представления пользователей декомпозируют с помощью SVD, как в стандартной коллаборативной фильтрации. Затем выделяют две части: высокоразмерную общую KV и компактные персональные KV. При инференсе предлагается «подглядывать» и туда, и туда.
По результатам удалось сжать KV-кэш до 0,8% от его исходного размера (!), не просадив качество.
#YaICLR26
@RecSysChannel
Интересное увидел
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤16🔥7👍5❤🔥1
Kunlun: Establishing Scaling Laws for Massive‑Scale Recommendation Systems [1/2]
Сегодня приступаем к разбору статьи, в которой Meta* обращает внимание на вопросы масштабирования моделей и эффективного использования GPU для задач рекомендательных систем. Начнём с предпосылок и овервью.
Авторы замечают, что в отличие от LLM, где все фичи представляют собой последовательности токенов, в RecSys сочетаются как контекстные фичи (соцдем пользователя, метаданные документа и прочее), так и фичи-последовательности (поведение пользователя). Отказ от использования контекстных фичей зачастую приводит к снижению ключевых для бизнеса метрик. Поэтому приходится искать архитектуры, учитывающие оба типа фичей и позволяющее им эффективно взаимодействовать.
При попытке масштабировать подобные модели возникают два главных боттлнека:
1) неэффективные блоки в моделях, которые утилизируют только 3-15% вычислительных возможностей GPU (Model FLOPs Utilization, MFU) в сравнении с 40-60% для LLM;
2) неэффективное распределение ресурсов при масштабировании (равномерное повышение ресурсов по всем частям модели неоптимально, вместо этого надо точечно повышать сложность отдельных модулей).
В качестве решения авторы предлагают совместный (co-design) подход к повышению эффективности, сочетающий низкоуровневые оптимизации (по отдельным блокам) и высокоуровневое управление ресурсами (какие именно части системы усиливать). Свой подход они применяют к архитектуре модели, работающей с контекстными фичами и последовательностями.
В основе архитектуры Kunlun лежат три основные работы (хотя авторы указывают в числе референсов больше статей):
- Wukong — предлагает способ взаимодействия высокого порядка между контекстными фичами, но не работает с последовательностями;
- HSTU — хорошо работает с последовательностями, но почти не умеет с контекстом;
- Interformer — предыдущая попытка объединить контекстные фичи и последовательности, которая оказалась не очень эффективной на GPU.
Дальше — подробнее об архитектуре и масштабировании.
@RecSysChannel
Разбор подготовил❣ Артём Ваншулин
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Сегодня приступаем к разбору статьи, в которой Meta* обращает внимание на вопросы масштабирования моделей и эффективного использования GPU для задач рекомендательных систем. Начнём с предпосылок и овервью.
Авторы замечают, что в отличие от LLM, где все фичи представляют собой последовательности токенов, в RecSys сочетаются как контекстные фичи (соцдем пользователя, метаданные документа и прочее), так и фичи-последовательности (поведение пользователя). Отказ от использования контекстных фичей зачастую приводит к снижению ключевых для бизнеса метрик. Поэтому приходится искать архитектуры, учитывающие оба типа фичей и позволяющее им эффективно взаимодействовать.
При попытке масштабировать подобные модели возникают два главных боттлнека:
1) неэффективные блоки в моделях, которые утилизируют только 3-15% вычислительных возможностей GPU (Model FLOPs Utilization, MFU) в сравнении с 40-60% для LLM;
2) неэффективное распределение ресурсов при масштабировании (равномерное повышение ресурсов по всем частям модели неоптимально, вместо этого надо точечно повышать сложность отдельных модулей).
В качестве решения авторы предлагают совместный (co-design) подход к повышению эффективности, сочетающий низкоуровневые оптимизации (по отдельным блокам) и высокоуровневое управление ресурсами (какие именно части системы усиливать). Свой подход они применяют к архитектуре модели, работающей с контекстными фичами и последовательностями.
В основе архитектуры Kunlun лежат три основные работы (хотя авторы указывают в числе референсов больше статей):
- Wukong — предлагает способ взаимодействия высокого порядка между контекстными фичами, но не работает с последовательностями;
- HSTU — хорошо работает с последовательностями, но почти не умеет с контекстом;
- Interformer — предыдущая попытка объединить контекстные фичи и последовательности, которая оказалась не очень эффективной на GPU.
Дальше — подробнее об архитектуре и масштабировании.
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11❤5👍3
Kunlun: Establishing Scaling Laws for Massive‑Scale Recommendation Systems [2/2]
Продолжаем разбор статьи Kunlun — переходим к архитектуре и масштабированию.
Авторы высокоуровнево выделяют в модели два блока:
- Kunlun Transformer Block — отвечает за обработку истории с учётом контекста.
- Kunlun Interaction Block — отвечает за обмен информацией между последовательными и непоследовательными признаками.
Рассмотрим подробнее один слой модели, чтобы понять, как достигается взаимодействие между фичами различной природы.
1) Из контекстных фичей получаются матрицы K и V, которые потом используют для извлечения информации из последовательности благодаря cross-attention. Авторы рассматривают это как обогащение истории пользователя контекстом/персонализацией. Ребята значимо поработали над low-level-оптимизациями, перенеся их из FlashAttention, благодаря чему ускорили этот блок в шесть раз по сравнению с Interformer.
2) GDPA — Generalized Dot Product Attention. Последовательность событий преобразуют в Q, с которой «смотрят» на полученные K, V с предыдущего шага.
3) Hierarchical Seed Pooling (HSP) — замена традиционному PMA (Pooling by Multihead Attention). Смысл — донести информацию из истории действий пользователя для взаимодействия с контекстными фичами. Тут тоже применяют трюк, чтоб захватить побольше информации, не усложнив значимо компьют.
4) Multi-expert Wukong — для захвата взаимодействий (в том числе и высоких порядков) между контекстными фичами и историей пользователя
5) Стандартный блок self-attention для последовательности, уже обогащённой контекстом.
6) После заключительного слоя для каждой задачи с его помощью вычисляется MLP-шапка (Multi-Layer Perceptron).
В целом ощущение, что Kunlun — это доведённый до ума Interformer, в котором неэффективные блоки заменили на более GPU-friendly, а также применили трюки из LLM для оптимизации ресурсов: sliding-window attention, чередование блоков с attention по последовательности с блоками взаимодействия/суммаризации по контекстным фичам (computation skip), mixture of experts (необычно, что экспертом выступают wukong-блоки).
Также авторы немного упоминают event-level personalization. У пользователя могут быть последовательности из разных событий, и вес/важность событий разных типов (барабанная дробь!) разная. Поэтому — якобы — для разных последовательностей можно управлять гиперпараметрами:
d — размерность эмбеддингов;
n_heads — количество голов в multi-head attention;
n_tokens — количество токенов, участвующих в взаимодействии с контекстными фичами;
L — количество слоёв;
w — размер окна в sliding window self-attention.
Относительно остальных оптимизаций этот пункт выглядит наименее понятным и объяснённым. С одной стороны, идея довольно простая. С другой — непонятно, как поддерживают разные гиперпараметры для разных событий, поскольку в архитектуре есть завязки на единый размер эмбеддингов и практически все гиперпараметры — ключевые (например, количество слоёв модели). Разве что это фактически разные модели — по одной для каждой последовательности (для кликов, для показов, для конверсий).
Что касается цифр, модель масштабируется примерно в два раза эффективнее бейзлайнов (прирост метрик на одинаковый прирост компьюта стал в два раза выше), использование GPU (MFU) на B200 выросло с 17% до ~37%, а в Meta Ads это дало прирост бизнес-метрик на +1,2%.
@RecSysChannel
Разбор подготовил❣ Артём Ваншулин
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Продолжаем разбор статьи Kunlun — переходим к архитектуре и масштабированию.
Авторы высокоуровнево выделяют в модели два блока:
- Kunlun Transformer Block — отвечает за обработку истории с учётом контекста.
- Kunlun Interaction Block — отвечает за обмен информацией между последовательными и непоследовательными признаками.
Рассмотрим подробнее один слой модели, чтобы понять, как достигается взаимодействие между фичами различной природы.
1) Из контекстных фичей получаются матрицы K и V, которые потом используют для извлечения информации из последовательности благодаря cross-attention. Авторы рассматривают это как обогащение истории пользователя контекстом/персонализацией. Ребята значимо поработали над low-level-оптимизациями, перенеся их из FlashAttention, благодаря чему ускорили этот блок в шесть раз по сравнению с Interformer.
2) GDPA — Generalized Dot Product Attention. Последовательность событий преобразуют в Q, с которой «смотрят» на полученные K, V с предыдущего шага.
3) Hierarchical Seed Pooling (HSP) — замена традиционному PMA (Pooling by Multihead Attention). Смысл — донести информацию из истории действий пользователя для взаимодействия с контекстными фичами. Тут тоже применяют трюк, чтоб захватить побольше информации, не усложнив значимо компьют.
4) Multi-expert Wukong — для захвата взаимодействий (в том числе и высоких порядков) между контекстными фичами и историей пользователя
5) Стандартный блок self-attention для последовательности, уже обогащённой контекстом.
6) После заключительного слоя для каждой задачи с его помощью вычисляется MLP-шапка (Multi-Layer Perceptron).
В целом ощущение, что Kunlun — это доведённый до ума Interformer, в котором неэффективные блоки заменили на более GPU-friendly, а также применили трюки из LLM для оптимизации ресурсов: sliding-window attention, чередование блоков с attention по последовательности с блоками взаимодействия/суммаризации по контекстным фичам (computation skip), mixture of experts (необычно, что экспертом выступают wukong-блоки).
Также авторы немного упоминают event-level personalization. У пользователя могут быть последовательности из разных событий, и вес/важность событий разных типов (барабанная дробь!) разная. Поэтому — якобы — для разных последовательностей можно управлять гиперпараметрами:
d — размерность эмбеддингов;
n_heads — количество голов в multi-head attention;
n_tokens — количество токенов, участвующих в взаимодействии с контекстными фичами;
L — количество слоёв;
w — размер окна в sliding window self-attention.
Относительно остальных оптимизаций этот пункт выглядит наименее понятным и объяснённым. С одной стороны, идея довольно простая. С другой — непонятно, как поддерживают разные гиперпараметры для разных событий, поскольку в архитектуре есть завязки на единый размер эмбеддингов и практически все гиперпараметры — ключевые (например, количество слоёв модели). Разве что это фактически разные модели — по одной для каждой последовательности (для кликов, для показов, для конверсий).
Что касается цифр, модель масштабируется примерно в два раза эффективнее бейзлайнов (прирост метрик на одинаковый прирост компьюта стал в два раза выше), использование GPU (MFU) на B200 выросло с 17% до ~37%, а в Meta Ads это дало прирост бизнес-метрик на +1,2%.
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤🔥6❤5