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
Accelerating Generative Recommendation via Simple Categorical User Sequence Compression
Сегодня разбираем статью CAUSE, посвящённую проблеме производительности рекомендательных архитектур на длинных последовательностях айтемов. Авторы предлагают агрегировать айтемы в бакеты по некоторому категориальному признаку и затем longterm-историю представлять в модели через эмбеддинги бакетов.
Ключевой вклад работы — механизм сжатия longterm-информации, получивший название CAUSE. На картинке выше изображено, как работает этот механизм:
- айтемы из longterm-истории бьются на бакеты по категориальному признаку, recent-история подаётся в модель полностью;
- берётся максимум V бакетов по последнему таймстемпу айтема внутри;
- внутри бакетов берётся максимум G айтемов, также отсортированных по таймстемпу;
- каждый эмбед айтема внутри бакета пропускают через MLP-проектор, затем их усредняют по размерности бакета и складывают с обучаемым эмбедом бакета;
- дополнительно в начало последовательности ставят аналог CLS-токена, причём все сегменты отделены друг от друга SEP-токенами.
Для задачи next item prediction используют InfoNCE, а для action prediction — cross-entropy loss.
Авторы выбрали датасеты KuaiRand-27K (логи интеракций с короткими видео) и MovieLens-20M (классика рекомендательных датасетов).
Эксперименты проводят на модели HSTU (3 слоя, hidden size 64, 8 attention heads), в качестве метрик берут NDCG@k и MRR, а бейзлайны — стандартный HSTU и подход GenRank, который агрегирует item и action. В результате подход даёт наилучшие метрики даже в сравнении с сетапами с более длинными последовательностями юзеров с ускорением до 6x на инференсе и до 4x на обучении.
Также авторы проводят аблейшны своего подхода: проверяют, что при отсутствии категориальных признаков событий использование кластеров из K-Means как категорий даёт улучшение относительно бейзлайна, а при исключении отдельных частей подхода качество падает.
Главное достоинство CAUSE — логичный и простой метод сжатия истории. Среди моментов для улучшения можно назвать то, что в статье нет оценки внедряемости и онлайн-результатов, а также рассматривается только одна архитектура с небольшим количеством параметров.
@RecSysChannel
Разбор подготовил❣ Никита Степанов
Сегодня разбираем статью CAUSE, посвящённую проблеме производительности рекомендательных архитектур на длинных последовательностях айтемов. Авторы предлагают агрегировать айтемы в бакеты по некоторому категориальному признаку и затем longterm-историю представлять в модели через эмбеддинги бакетов.
Ключевой вклад работы — механизм сжатия longterm-информации, получивший название CAUSE. На картинке выше изображено, как работает этот механизм:
- айтемы из longterm-истории бьются на бакеты по категориальному признаку, recent-история подаётся в модель полностью;
- берётся максимум V бакетов по последнему таймстемпу айтема внутри;
- внутри бакетов берётся максимум G айтемов, также отсортированных по таймстемпу;
- каждый эмбед айтема внутри бакета пропускают через MLP-проектор, затем их усредняют по размерности бакета и складывают с обучаемым эмбедом бакета;
- дополнительно в начало последовательности ставят аналог CLS-токена, причём все сегменты отделены друг от друга SEP-токенами.
Для задачи next item prediction используют InfoNCE, а для action prediction — cross-entropy loss.
Авторы выбрали датасеты KuaiRand-27K (логи интеракций с короткими видео) и MovieLens-20M (классика рекомендательных датасетов).
Эксперименты проводят на модели HSTU (3 слоя, hidden size 64, 8 attention heads), в качестве метрик берут NDCG@k и MRR, а бейзлайны — стандартный HSTU и подход GenRank, который агрегирует item и action. В результате подход даёт наилучшие метрики даже в сравнении с сетапами с более длинными последовательностями юзеров с ускорением до 6x на инференсе и до 4x на обучении.
Также авторы проводят аблейшны своего подхода: проверяют, что при отсутствии категориальных признаков событий использование кластеров из K-Means как категорий даёт улучшение относительно бейзлайна, а при исключении отдельных частей подхода качество падает.
Главное достоинство CAUSE — логичный и простой метод сжатия истории. Среди моментов для улучшения можно назвать то, что в статье нет оценки внедряемости и онлайн-результатов, а также рассматривается только одна архитектура с небольшим количеством параметров.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥7❤6🔥6👍2
RecIS: Sparse to Dense, A Unified Training Framework for Recommendation Models
Сегодня разберём работу Alibaba под названием RecIS (Recommendation Intelligence System). Это фреймворк для обучения рекомендательных систем, который нужен, чтобы масштабировать «всё и вся» в разных контекстах, оставаясь при этом PyTorch-френдли и пригодными для продакшена.
В рексистемах есть два разных типа нагрузки. В sparse-части, связанной с эмбеддингами, мало вычислений, но много обращений к памяти. В dense-части, наоборот, много вычислений и меньше работы с памятью. В рексистемах по сравнению с другими областями (NLP, CV) ощутимо больше sparse-нагрузки, поэтому оптимизации касаются именно этой части.
В статье обращают внимание, что скорость доступа к памяти на GPU быстро растёт и уже сильно выше, чем на CPU. Долго считалось, что доступ к памяти остаётся боттлнеком и на GPU, но в работе говорят, что память уже не такая и медленная. Отсюда идея, что можно сделать размен в другую сторону — больше обращений к памяти и уменьшение количества вычислений за счёт большего количества операций с ней.
Авторы вводят метрику MBU — максимальная утилизация пропускной способности. Опираются на идею roofline-модели, где оценивается баланс между вычислениями и доступом к памяти. В классическом варианте по горизонтали откладывают число операций на загруженный байт, а по вертикали — количество FLOPs, которые модель может утилизровать.
Для рексистем такая постановка не очень подходит из-за sparse-нагрузки. Важно не количество вычислений, а то, насколько хорошо утилизируется пропускная способность памяти. Поэтому в работе рассматривают bandwidth-based-вариант, где по вертикали откладывается bandwidth, которую может утилизировать модель, а по горизонтали — объём обращений к памяти на количество вычислений.
Одно из применений этой идеи — работа со sparse-эмбеддингами. Стандартно таблица эмбеддингов реплицируется на все GPU: после каждой эпохи градиенты собираются, усредняются и рассылаются обратно. Здесь предлагают шардировать таблицу так, чтобы каждая GPU хранила только свою часть.
На форварде каждая GPU определяет, какие эмбеддинги ей нужны с других устройств, после происходит all-to-all-коммуникация, и карты обмениваются нужной информацией. Затем каждая GPU читает свои эмбеддинги и отправляет их туда, где они нужны.
На бэкварде происходит то же самое: каждая GPU знает, куда нужно записать градиенты, и они пересылаются напрямую в соответствующие шарды. В итоге всё укладывается в две all-to-all-коммуникации, а таблица занимает меньше памяти на каждой видеокарте.
Также делают оптимизации. Есть стандартные вещи, такие как mixed precision, FlashAttention, ZeRO, fused softmax и cross-entropy. Есть специфичные для рекомендаций. Например, если у нескольких embedding-таблиц одинаковая размерность, их объединяют в одну, чтобы оптимизировать доступ к памяти.
Данные хранят в колоночном формате, для sparse-структур используют CSR.
После загрузки данных есть всего четыре типа операций:
- бакетизация / взятие по модулю;
- (мульти)хэширование;
- обрезание истории;
- построение пар фичей.
Каждую фичу представляют как последовательность таких операций. Некоторые из них (например, хэширование по нескольким разным сидам) можно объединить и зафьюзить.
Эксперименты проводят на двух моделях: MSE (предсказание вероятности клика) и LMA (предсказание следующего баннера по истории). По времени обучения RecIS работает быстрее, чем TensorFlow и PyTorch. По метрике MBU тоже более высокая утилизация пропускной способности.
При этом упоминают и проблемы:
- загрузка данных из сети может занимать много времени (сэмплы до ~6GB);
- embedding-таблицы остаются очень большими, в том числе из-за старых объектов;
- в старых фреймворках вроде TensorFlow 1.x есть ограничения на размер тензоров.
В конце авторы делают вывод, что в современных multi-GPU-системах памяти обычно достаточно. И это позволяет сместить баланс: делать больше операций с памятью и меньше вычислений.
@RecSysChannel
Разбор подготовил❣ Семён Паненко
Сегодня разберём работу Alibaba под названием RecIS (Recommendation Intelligence System). Это фреймворк для обучения рекомендательных систем, который нужен, чтобы масштабировать «всё и вся» в разных контекстах, оставаясь при этом PyTorch-френдли и пригодными для продакшена.
В рексистемах есть два разных типа нагрузки. В sparse-части, связанной с эмбеддингами, мало вычислений, но много обращений к памяти. В dense-части, наоборот, много вычислений и меньше работы с памятью. В рексистемах по сравнению с другими областями (NLP, CV) ощутимо больше sparse-нагрузки, поэтому оптимизации касаются именно этой части.
В статье обращают внимание, что скорость доступа к памяти на GPU быстро растёт и уже сильно выше, чем на CPU. Долго считалось, что доступ к памяти остаётся боттлнеком и на GPU, но в работе говорят, что память уже не такая и медленная. Отсюда идея, что можно сделать размен в другую сторону — больше обращений к памяти и уменьшение количества вычислений за счёт большего количества операций с ней.
Авторы вводят метрику MBU — максимальная утилизация пропускной способности. Опираются на идею roofline-модели, где оценивается баланс между вычислениями и доступом к памяти. В классическом варианте по горизонтали откладывают число операций на загруженный байт, а по вертикали — количество FLOPs, которые модель может утилизровать.
Для рексистем такая постановка не очень подходит из-за sparse-нагрузки. Важно не количество вычислений, а то, насколько хорошо утилизируется пропускная способность памяти. Поэтому в работе рассматривают bandwidth-based-вариант, где по вертикали откладывается bandwidth, которую может утилизировать модель, а по горизонтали — объём обращений к памяти на количество вычислений.
Одно из применений этой идеи — работа со sparse-эмбеддингами. Стандартно таблица эмбеддингов реплицируется на все GPU: после каждой эпохи градиенты собираются, усредняются и рассылаются обратно. Здесь предлагают шардировать таблицу так, чтобы каждая GPU хранила только свою часть.
На форварде каждая GPU определяет, какие эмбеддинги ей нужны с других устройств, после происходит all-to-all-коммуникация, и карты обмениваются нужной информацией. Затем каждая GPU читает свои эмбеддинги и отправляет их туда, где они нужны.
На бэкварде происходит то же самое: каждая GPU знает, куда нужно записать градиенты, и они пересылаются напрямую в соответствующие шарды. В итоге всё укладывается в две all-to-all-коммуникации, а таблица занимает меньше памяти на каждой видеокарте.
Также делают оптимизации. Есть стандартные вещи, такие как mixed precision, FlashAttention, ZeRO, fused softmax и cross-entropy. Есть специфичные для рекомендаций. Например, если у нескольких embedding-таблиц одинаковая размерность, их объединяют в одну, чтобы оптимизировать доступ к памяти.
Данные хранят в колоночном формате, для sparse-структур используют CSR.
После загрузки данных есть всего четыре типа операций:
- бакетизация / взятие по модулю;
- (мульти)хэширование;
- обрезание истории;
- построение пар фичей.
Каждую фичу представляют как последовательность таких операций. Некоторые из них (например, хэширование по нескольким разным сидам) можно объединить и зафьюзить.
Эксперименты проводят на двух моделях: MSE (предсказание вероятности клика) и LMA (предсказание следующего баннера по истории). По времени обучения RecIS работает быстрее, чем TensorFlow и PyTorch. По метрике MBU тоже более высокая утилизация пропускной способности.
При этом упоминают и проблемы:
- загрузка данных из сети может занимать много времени (сэмплы до ~6GB);
- embedding-таблицы остаются очень большими, в том числе из-за старых объектов;
- в старых фреймворках вроде TensorFlow 1.x есть ограничения на размер тензоров.
В конце авторы делают вывод, что в современных multi-GPU-системах памяти обычно достаточно. И это позволяет сместить баланс: делать больше операций с памятью и меньше вычислений.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18👍9🔥9❤🔥4
Как в ARGUS решали проблемы контекста, кросс-доменных знаний и претрейна
Мы уже разбирали статью Scaling Recommender Transformers to One Billion Parameters, в которой представили генеративную модель персонализации ARGUS, от Яндекса. За последний год модель заметно изменилась и адаптировалась под разные домены внутри компании.
О генеративной постановке в рексистемах и развитии ARGUS подробно написал на Хабре руководитель службы рекомендательных технологий Николай Савушкин. Ну а мы рассказываем о трёх ограничениях, с которыми столкнулся подход, и о том, как удалось с ними разобраться.
Проблема 1: офлайн-обработка и позднее связывание
Раньше ARGUS обрабатывал пользовательскую историю офлайн, поэтому видел её только раз в сутки и не учитывал свежие действия. Контекст подключался на последнем шаге — через позднее связывание. Модель прогоняла через трансформер последовательность троек (context, item, action), а контекст следующего документа подставлялся уже на выходе. Из-за этого вся информация о связи между историей и текущим контекстом должна была «протаскиваться» через трансформер, что со временем стало архитектурным боттлнеком.
Решение: перешли на context-aware-токенизацию
Чтобы контекст перестал быть внешней надстройкой, его сделали полноценной частью последовательности. Историю пользователя перестроили в цепочки вида «контекст — связанные события». Следующий документ модель теперь предсказывает именно из контекстного токена. Такой переход убирает позднее связывание и позволяет учитывать контекст с самого начала работы модели. Трансформер пришлось перенести в рантайм, зато модель начала лучше работать в сценариях, где контекст особенно важен, например, в Рекламе, Поиске и doc2doc-рекомендациях.
Проблема 2: не было кросс-сервисных знаний
Изначально ARGUS был монодоменной моделью: данные брали только из текущего сервиса — например, Маркета или Музыки. Одна из главных идей генеративной постановки — научиться использовать обезличенные сигналы о поведении пользователя сразу из нескольких сервисов.
Решение: прокачали кросс-сервисные знания
События из разных сервисов собрали в единую кросс-доменную последовательность и начали обрабатывать одной моделью. Каждое событие представляли через набор признаков: item_id, категории и текстовые фичи. Категориальные признаки кодировались мультихешингом в общую unified-матрицу эмбеддингов, а текстовые — через BoW.
Для каждого домена использовали отдельную башню, которая обрабатывала признаки событий этого домена и комбинировала их через DCNv2. При этом эмбеддинговая матрица оставалась общей. Так смогли нарастить качество, даже не меняя лоссы и процедуры обучения.
Следующим шагом расширили претрейн на несколько доменов: модель начала предсказывать следующий item не только в целевом сервисе, но и в других доменах в истории пользователя. Для этого добавили отдельный Sampled Softmax для каждого домена, а итоговый лосс сделали суммой доменных лоссов. С таким претрейном получили заметный рост качества в downstream-ранжировании.
Также проверили, можно ли отказаться от претрейна и оставить только файн-тюнинг. Оказалось, нет: файн-тюнинг быстро переставал расти, а даже одна эпоха претрейна давала прирост, который не удавалось компенсировать дополнительными эпохами файн-тюнинга.
Проблема 3: нестабильный и сложный этап претрейна
Первоначальный претрейн ARGUS работал, но был сложным и не очень стабильным. Было не до конца понятно, какие части схемы действительно полезны, а какие усложняют обучение.
Решение: упростили претрейн
Выяснилось, что feedback-loss почти не влияет на результат, поэтому его полностью убрали. В итоге в ARGUS оставили только Next-Item Prediction — эта часть оказалась решающей для роста качества.
Больше деталей об экспериментах с ARGUS, разбор отличий от других генеративных моделей и результаты, к которым в итоге пришли авторы, — обо всём этом читайте в хабростатье.
@RecSysChannel
Мы уже разбирали статью Scaling Recommender Transformers to One Billion Parameters, в которой представили генеративную модель персонализации ARGUS, от Яндекса. За последний год модель заметно изменилась и адаптировалась под разные домены внутри компании.
О генеративной постановке в рексистемах и развитии ARGUS подробно написал на Хабре руководитель службы рекомендательных технологий Николай Савушкин. Ну а мы рассказываем о трёх ограничениях, с которыми столкнулся подход, и о том, как удалось с ними разобраться.
Проблема 1: офлайн-обработка и позднее связывание
Раньше ARGUS обрабатывал пользовательскую историю офлайн, поэтому видел её только раз в сутки и не учитывал свежие действия. Контекст подключался на последнем шаге — через позднее связывание. Модель прогоняла через трансформер последовательность троек (context, item, action), а контекст следующего документа подставлялся уже на выходе. Из-за этого вся информация о связи между историей и текущим контекстом должна была «протаскиваться» через трансформер, что со временем стало архитектурным боттлнеком.
Решение: перешли на context-aware-токенизацию
Чтобы контекст перестал быть внешней надстройкой, его сделали полноценной частью последовательности. Историю пользователя перестроили в цепочки вида «контекст — связанные события». Следующий документ модель теперь предсказывает именно из контекстного токена. Такой переход убирает позднее связывание и позволяет учитывать контекст с самого начала работы модели. Трансформер пришлось перенести в рантайм, зато модель начала лучше работать в сценариях, где контекст особенно важен, например, в Рекламе, Поиске и doc2doc-рекомендациях.
Проблема 2: не было кросс-сервисных знаний
Изначально ARGUS был монодоменной моделью: данные брали только из текущего сервиса — например, Маркета или Музыки. Одна из главных идей генеративной постановки — научиться использовать обезличенные сигналы о поведении пользователя сразу из нескольких сервисов.
Решение: прокачали кросс-сервисные знания
События из разных сервисов собрали в единую кросс-доменную последовательность и начали обрабатывать одной моделью. Каждое событие представляли через набор признаков: item_id, категории и текстовые фичи. Категориальные признаки кодировались мультихешингом в общую unified-матрицу эмбеддингов, а текстовые — через BoW.
Для каждого домена использовали отдельную башню, которая обрабатывала признаки событий этого домена и комбинировала их через DCNv2. При этом эмбеддинговая матрица оставалась общей. Так смогли нарастить качество, даже не меняя лоссы и процедуры обучения.
Следующим шагом расширили претрейн на несколько доменов: модель начала предсказывать следующий item не только в целевом сервисе, но и в других доменах в истории пользователя. Для этого добавили отдельный Sampled Softmax для каждого домена, а итоговый лосс сделали суммой доменных лоссов. С таким претрейном получили заметный рост качества в downstream-ранжировании.
Также проверили, можно ли отказаться от претрейна и оставить только файн-тюнинг. Оказалось, нет: файн-тюнинг быстро переставал расти, а даже одна эпоха претрейна давала прирост, который не удавалось компенсировать дополнительными эпохами файн-тюнинга.
Проблема 3: нестабильный и сложный этап претрейна
Первоначальный претрейн ARGUS работал, но был сложным и не очень стабильным. Было не до конца понятно, какие части схемы действительно полезны, а какие усложняют обучение.
Решение: упростили претрейн
Выяснилось, что feedback-loss почти не влияет на результат, поэтому его полностью убрали. В итоге в ARGUS оставили только Next-Item Prediction — эта часть оказалась решающей для роста качества.
Больше деталей об экспериментах с ARGUS, разбор отличий от других генеративных моделей и результаты, к которым в итоге пришли авторы, — обо всём этом читайте в хабростатье.
@RecSysChannel
❤15👍9🔥8👏1
MTGR: Industrial-Scale Generative Recommendation Framework in Meituan
Сегодня разбираем недавнюю статью от Meituan, крупнейшего сервиса доставки в Китае. В ней предлагают архитектуру ранжирования MTGR, которая использует ручные кросс-фичи, но при этом обладает масштабируемостью генеративных моделей.
Авторы выделяют две проблемы:
1. В классических моделях Deep Learning Recommendation (DLRM) вычислительная сложность и инференс масштабируются линейно по числу кандидатов. Если хотим сделать модель тяжелее, втиснуть её в прод становится невозможно по latency.
2. Generative Recommendation Model (GRM) решает проблему масштабирования. Но чтобы это работало, приходится отказываться от кросс-фичей. Авторы показывают, что их удаление настолько просаживает качество, что никакое увеличение параметров это не компенсирует.
Чтобы обойти ограничения, пробуют токенизировать все входные признаки:
- Профиль пользователя (U) — набор токенов, где каждая фича — отдельный токен.
- Историю делят на долгосрочную (S) и краткосрочную (R). Её токенизируют на уровне событий: эмбеддинги фич одного события конкатенируются и прогоняются через MLP.
- Кандидатов (C) токенизируют аналогично, но в них замешивают важные кросс-признаки.
Затем идёт агрегация: вместо обработки пар «пользователь-кандидат» по отдельности, все кандидаты юзера объединяются в один пример. Полученные токены образуют последовательность U → S → R → C. За один forward-pass модель оценивает сразу всех кандидатов, давая сублинейное масштабирование.
Токены подают в модифицированный трансформер HSTU со следующими внедрениями:
- Group-Layer Normalization (GLN). Так как токены имеют разную семантику, нормализация делается независимо для каждой группы (U, S, R, C).
- Dynamic Masking. Кастомная маска защищает от утечки данных. Пользователь и долгая история (U+S) видны всем. Краткосрочная (R) — подчиняется каузальности. Кандидаты (C) видят только предшествующую часть R и не видят других кандидатов.
Над токенами кандидатов на выходе строится MLP для предсказания CTR и CVR.
Авторы применили оптимизации, которые увеличили пропускную способность в 1,6–2,4 раза в сравнении с TorchRec. Также им удалось получить x65 FLOPs на один пример без увеличения затрат на обучение в сравнении с DLRM.
Вместо статических таблиц внедрили динамические хэшированные эмбеддинги, которые позволяют выделять память для новых пользователей/айтемов в реальном времени без переполнения.
Размер батчей сделали динамическим. Семплы с длинной историей объединяются в батчи с меньшим числом семплов. Семплы с короткой историей — в батчи с большим числом семплов. Это даёт примерно одинаковую вычислительную нагрузку на все GPU.
Обучение проводили в bf16 mixed precision с префетчингом. Его разбивали на три потока: copy (загрузка данных), dispatch (lookup эмбеддингов), compute (forward/backward), что позволило перекрывать I/O-операции с вычислениями.
Эксперименты и результаты
Для обучения использовали внутренние логи Meituan, так как открытые датасеты слишком маленькие и в них нет нужных кросс-фичей. В качестве бейзлайнов взяли передовые DLRM-архитектуры: Wukong, UserTower, DNN, MoE, MultiEmbed. Качество оценивали по AUC и GAUC.
По сравнению с лучшим бейзлайном (UserTower-SIM) офлайн-метрики (CTR/CTCVR, AUC/GAUC) улучшились на 0,5–1,5%.
Проверка показала, что все компоненты архитектуры критичны. Отсутствие кросс-фичей просаживает качество сильнее всего — без них MTGR сразу проигрывает старым бейзлайнам. GroupLN и Dynamic Masking также дают значимый прирост в качестве.
Авторы продемонстрировали линейный прирост качества (CTCVR GAUC) от log(flops). Отдельно показали, что модель масштабируется по всем осям: можно наращивать как число слоёв, так и скрытую размерность или длину истории.
В онлайн-эксперименте MTGR даёт +1,9% CTR и +1,02% CTCVR в сравнении с лучшим DLRM-бейзлайном.
@RecSysChannel
Разбор подготовил❣ Влад Аверков
Сегодня разбираем недавнюю статью от Meituan, крупнейшего сервиса доставки в Китае. В ней предлагают архитектуру ранжирования MTGR, которая использует ручные кросс-фичи, но при этом обладает масштабируемостью генеративных моделей.
Авторы выделяют две проблемы:
1. В классических моделях Deep Learning Recommendation (DLRM) вычислительная сложность и инференс масштабируются линейно по числу кандидатов. Если хотим сделать модель тяжелее, втиснуть её в прод становится невозможно по latency.
2. Generative Recommendation Model (GRM) решает проблему масштабирования. Но чтобы это работало, приходится отказываться от кросс-фичей. Авторы показывают, что их удаление настолько просаживает качество, что никакое увеличение параметров это не компенсирует.
Чтобы обойти ограничения, пробуют токенизировать все входные признаки:
- Профиль пользователя (U) — набор токенов, где каждая фича — отдельный токен.
- Историю делят на долгосрочную (S) и краткосрочную (R). Её токенизируют на уровне событий: эмбеддинги фич одного события конкатенируются и прогоняются через MLP.
- Кандидатов (C) токенизируют аналогично, но в них замешивают важные кросс-признаки.
Затем идёт агрегация: вместо обработки пар «пользователь-кандидат» по отдельности, все кандидаты юзера объединяются в один пример. Полученные токены образуют последовательность U → S → R → C. За один forward-pass модель оценивает сразу всех кандидатов, давая сублинейное масштабирование.
Токены подают в модифицированный трансформер HSTU со следующими внедрениями:
- Group-Layer Normalization (GLN). Так как токены имеют разную семантику, нормализация делается независимо для каждой группы (U, S, R, C).
- Dynamic Masking. Кастомная маска защищает от утечки данных. Пользователь и долгая история (U+S) видны всем. Краткосрочная (R) — подчиняется каузальности. Кандидаты (C) видят только предшествующую часть R и не видят других кандидатов.
Над токенами кандидатов на выходе строится MLP для предсказания CTR и CVR.
Авторы применили оптимизации, которые увеличили пропускную способность в 1,6–2,4 раза в сравнении с TorchRec. Также им удалось получить x65 FLOPs на один пример без увеличения затрат на обучение в сравнении с DLRM.
Вместо статических таблиц внедрили динамические хэшированные эмбеддинги, которые позволяют выделять память для новых пользователей/айтемов в реальном времени без переполнения.
Размер батчей сделали динамическим. Семплы с длинной историей объединяются в батчи с меньшим числом семплов. Семплы с короткой историей — в батчи с большим числом семплов. Это даёт примерно одинаковую вычислительную нагрузку на все GPU.
Обучение проводили в bf16 mixed precision с префетчингом. Его разбивали на три потока: copy (загрузка данных), dispatch (lookup эмбеддингов), compute (forward/backward), что позволило перекрывать I/O-операции с вычислениями.
Эксперименты и результаты
Для обучения использовали внутренние логи Meituan, так как открытые датасеты слишком маленькие и в них нет нужных кросс-фичей. В качестве бейзлайнов взяли передовые DLRM-архитектуры: Wukong, UserTower, DNN, MoE, MultiEmbed. Качество оценивали по AUC и GAUC.
По сравнению с лучшим бейзлайном (UserTower-SIM) офлайн-метрики (CTR/CTCVR, AUC/GAUC) улучшились на 0,5–1,5%.
Проверка показала, что все компоненты архитектуры критичны. Отсутствие кросс-фичей просаживает качество сильнее всего — без них MTGR сразу проигрывает старым бейзлайнам. GroupLN и Dynamic Masking также дают значимый прирост в качестве.
Авторы продемонстрировали линейный прирост качества (CTCVR GAUC) от log(flops). Отдельно показали, что модель масштабируется по всем осям: можно наращивать как число слоёв, так и скрытую размерность или длину истории.
В онлайн-эксперименте MTGR даёт +1,9% CTR и +1,02% CTCVR в сравнении с лучшим DLRM-бейзлайном.
@RecSysChannel
Разбор подготовил
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10👍8🔥6🥰1
Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations
В рекомендациях для разных поверхностей, доменов и таргетов часто обучают отдельные модели. Но такой подход плохо масштабируется и усложняет поддержку системы. Чтобы решить проблему, авторы Meta Lattice построили фундаментальную модель, сочетающую разные органические и рекламные поверхности Meta*.
Основной вклад статьи в том, что в ней собран большой набор инженерных «рецептов» для такого объединения. Разбирают, как совмещать конверсии с разными окнами атрибуции, отбирать фичи, стабилизировать мультидоменное обучение, делать дистилляцию, включая inference-time-дистилляцию.
Ещё в работе предлагают несколько неочевидных и при этом работающих идей:
- correlation-based loss для смешивания таргетов из разных доменов — решение простое и, судя по статье, эффективное. Это элемент, который позволяет обучать модель для разных поверхностей и одновременно бустить качество на них;
- inference-time distillation — подстановка эмбеддингов учителя в ученика в момент запроса. Технологически это означает, что нужно поддерживать near-realtime-контур с инференсом модели-учителя и кеш эмбеддингов на недавних запросах (не путать с KV-cache);
- совместная модель для pCTR и pCVR — очевидное сокращение компьюта.
В Meta Lattice вводят понятие портфеля — пары поверхности и таргета. Портфели объединяются между доменами с достаточным перекрытием пользователей и одинаковым типом таргетов (моментальные или отложенные). Для каждого объединённого портфеля обучается и деплоится одна модель на общем датасете со всеми таргетами.
Как всё работет в общих чертах:
- Lattice Partitioner — объединяет портфели по перекрытию user_id и схожему типу таргетов.
- Lattice Zipper — объединяет разные окна атрибуции; все они смешиваются в один датасет, для каждого клика случайно выбирается одно окно, а в модели обучают отдельные головы под каждое окно атрибуции. На инференсе используют oracle-head с самым длинным окном.
- Lattice Filter — фильтрует фичи через permutation feature importance и отбор по Парето-фронтам.
- Lattice Models — архитектура на базе DenseNet-like блоков, DHEN/Wukong для feature interaction и трансформера для последовательностей. Используются domain-specific FFN, QK-norm и дополнительный correlation-based loss для multi-domain multi-target обучения.
- Lattice Sketch — подбирает гиперпараметры модели и стратегию FSDP-шардирования с ограничениями по latency и quality.
- Lattice KTAP — inference-time-дистилляция + обычная knowledge-дистилляция: teacher embeddings, soft targets, label smoothing и feature clipping.
Используют два датасета: KuaiVideo (13 млн событий для like/follow/click prediction) и production-scale-датасет Meta на 100 млрд событий для CTR/CVR prediction с ~2 тысячами рекламных фичей.
Обучение идёт на общем датасете со всеми таргетами и доменами внутри объединённого портфеля. У каждого семпла при этом только один таргет.
Фичи берутся из объединения всех фичей портфеля. Если фича отсутствует для конкретного домена или задачи, используют zero-fill. Для каждого семпла считают соответствующий task-specific loss, после чего лоссы суммируются по батчу. Дополнительно добавлен correlation-based loss между предиктами и таргетами.
Дистилляция делается через soft-targets и teacher embeddings на входе модели.
В работе есть аблейшны всех частей пайплайна, а также разбивка по вкладу: Lattice Partitioner (36%), Lattice Zipper (11%), Lattice Filter (13%), Lattice Networks (23%), and Lattice KTAP (17%).
Архитектурные улучшения сравнивают с индустриальными SOTA-подходами, вроде Wukong, — на открытом датасете и на приватном.
Подход уже внедрили в прод, где он принёс двузначные приросты при сокращении компьюта.
@RecSysChannel
Разбор подготовил❣ Александр Плошкин
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
В рекомендациях для разных поверхностей, доменов и таргетов часто обучают отдельные модели. Но такой подход плохо масштабируется и усложняет поддержку системы. Чтобы решить проблему, авторы Meta Lattice построили фундаментальную модель, сочетающую разные органические и рекламные поверхности Meta*.
Основной вклад статьи в том, что в ней собран большой набор инженерных «рецептов» для такого объединения. Разбирают, как совмещать конверсии с разными окнами атрибуции, отбирать фичи, стабилизировать мультидоменное обучение, делать дистилляцию, включая inference-time-дистилляцию.
Ещё в работе предлагают несколько неочевидных и при этом работающих идей:
- correlation-based loss для смешивания таргетов из разных доменов — решение простое и, судя по статье, эффективное. Это элемент, который позволяет обучать модель для разных поверхностей и одновременно бустить качество на них;
- inference-time distillation — подстановка эмбеддингов учителя в ученика в момент запроса. Технологически это означает, что нужно поддерживать near-realtime-контур с инференсом модели-учителя и кеш эмбеддингов на недавних запросах (не путать с KV-cache);
- совместная модель для pCTR и pCVR — очевидное сокращение компьюта.
В Meta Lattice вводят понятие портфеля — пары поверхности и таргета. Портфели объединяются между доменами с достаточным перекрытием пользователей и одинаковым типом таргетов (моментальные или отложенные). Для каждого объединённого портфеля обучается и деплоится одна модель на общем датасете со всеми таргетами.
Как всё работет в общих чертах:
- Lattice Partitioner — объединяет портфели по перекрытию user_id и схожему типу таргетов.
- Lattice Zipper — объединяет разные окна атрибуции; все они смешиваются в один датасет, для каждого клика случайно выбирается одно окно, а в модели обучают отдельные головы под каждое окно атрибуции. На инференсе используют oracle-head с самым длинным окном.
- Lattice Filter — фильтрует фичи через permutation feature importance и отбор по Парето-фронтам.
- Lattice Models — архитектура на базе DenseNet-like блоков, DHEN/Wukong для feature interaction и трансформера для последовательностей. Используются domain-specific FFN, QK-norm и дополнительный correlation-based loss для multi-domain multi-target обучения.
- Lattice Sketch — подбирает гиперпараметры модели и стратегию FSDP-шардирования с ограничениями по latency и quality.
- Lattice KTAP — inference-time-дистилляция + обычная knowledge-дистилляция: teacher embeddings, soft targets, label smoothing и feature clipping.
Используют два датасета: KuaiVideo (13 млн событий для like/follow/click prediction) и production-scale-датасет Meta на 100 млрд событий для CTR/CVR prediction с ~2 тысячами рекламных фичей.
Обучение идёт на общем датасете со всеми таргетами и доменами внутри объединённого портфеля. У каждого семпла при этом только один таргет.
Фичи берутся из объединения всех фичей портфеля. Если фича отсутствует для конкретного домена или задачи, используют zero-fill. Для каждого семпла считают соответствующий task-specific loss, после чего лоссы суммируются по батчу. Дополнительно добавлен correlation-based loss между предиктами и таргетами.
Дистилляция делается через soft-targets и teacher embeddings на входе модели.
В работе есть аблейшны всех частей пайплайна, а также разбивка по вкладу: Lattice Partitioner (36%), Lattice Zipper (11%), Lattice Filter (13%), Lattice Networks (23%), and Lattice KTAP (17%).
Архитектурные улучшения сравнивают с индустриальными SOTA-подходами, вроде Wukong, — на открытом датасете и на приватном.
Подход уже внедрили в прод, где он принёс двузначные приросты при сокращении компьюта.
@RecSysChannel
Разбор подготовил
___
Компания Meta признана экстремистской; её деятельность в России запрещена.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8🔥7👍3🥰1