💬 Yet another dataset?

Сегодня — честный обзор на уже захайпленный датасет.
Если вы когда-либо занимались ресерчем в рексисе, то точно сталкивались с проблемами датасетов.
(Можно вспомнить классическую статью Are We Really Making Much Progress?)

Сначала — немного боли из прошлого:
— гигантский гэп между train и test
— однотипный фидбек
— отсутствие разнообразия пользовательских паттернов

И это всё — на фоне постоянных споров в академии про то, что вообще считается хорошим датасетом.

Даже если вы соберёте SOTA-модель — она может просто не «прокраситься» на кривом сете.
Ну серьёзно, в том же MovieLens test отстоит от train на несколько лет.

И вот — датасет от Яндекс Музыки.
Огромный:
⭐ 4.78 млрд взаимодействий
⭐ 9.39 млн треков
⭐ 1 млн пользователей
⭐ и впервые — флаг is_organic, который показывает:
пришёл ли пользователь к треку сам или его привёл алгоритм

С одной стороны — это прям must-have для исследовательского пула.
Многоуровневый фидбек:
⭐ implicit (прослушивания)
⭐ explicit (лайки, дизлайки, отмены)

Даже эмбеддинги спектрограмм есть.

А ещё — продуманный split:
⭐ leave-one-last (не используется в экспериментах)
⭐ temporal global
(приложу картинку в комментах — очень в тему для продовой оценки)

По сравнению с Netflix, Steam и прочими — это реально большой и комплексный датасет.

Я бы еще упомянул о бенчмарках и красивом коде куда на мой взгляд легко интегрировать свои решения.

Один момент, о котором почти никто не говорит — это домен.

Яндекс Музыка — это, как и TikTok, продукт с ярко выраженными короткими и длинными предпочтениями.
Здесь трансформеры можно не просто тестировать — здесь они раскрываются.

Но. Доверяй, но проверяй.
👀 Насколько честно размечена органика?
👀 Подходит ли датасет для cold-start задач?
👀 Для многих экспериментов вокруг LLM, мне бы хотелось увидеть больше фичей о пользователях, да и в целом фичей. (btw я понимаю, из-за чего их не включают)

Спасибо ребятам из Яндекса за такой летний подгон.
Реально мощный вклад в сообщество, действительно мало компаний могут себе это позволить.

➡️ Hugging Face и arxiv

✅ Как быстро отличить senior-специалиста от того, кто просто занимает высокую должность?

Недавно в чатике обсуждал смысл алгокодинга и Валера привел мне как аргумент, что алгокодинг сильно коррелирует с навыками в работе. (А я скорее склонен верить). И соответственно возник вопрос, а как тогда определять синьерность?

Мне кажется, нашёл один из железных критериев. Senior — это не просто человек с опытом, который умеет писать код или красиво говорить на митингах. Это человек, способный принимать рациональные, системные решения. И тут есть пара тревожных звоночков, которые выдают отсутствие senior-подхода:

1️⃣ Если разработчик или аналитик сразу пытается построить космический корабль вместо того, чтобы запустить простой и понятный baseline — это красный флаг. Реальный senior понимает: сначала нужно поставить понятный ориентир, с которым дальше можно сравнивать любые улучшения.

2️⃣ Хаотичное генерирование гипотез, которые никак не связаны друг с другом, — признак отсутствия системного мышления. Senior всегда (я надеюсь) старается формализовать решения, писать понятные дизайн-документы и видеть картину целиком.

Важно понимать, что senior — это прежде всего про умение выбирать наилучшее решение с минимальными затратами. И если ваш тимлид или техлид начинает сразу с усложнения, минуя baseline, задумайтесь...

➡️ А вашего покорного слугу еще стажером такому учил Богдан

🍔 Бургер Кинг — всё.

Сегодня был мой последний день в компании.

Очень тёплое ощущение — работать с командой, с которой мы строили сильные решения. Часто вслепую, часто через боль, с ошибками и переработками. Но всегда с верой в то, что делаем что-то важное.

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

Скоро расскажу про новое место и команду. Подогреваю интерес: если всё пойдёт по плану, до конца лета покажем пару действительно крутых проектов. 😀

✅ Как завести PinnerFormer в real-time?

Недавно в одном чате по курсу рекомендашек ребята собрались рассказать про TransAct.

Достаточно логичное продолжение моего рассказал про PinnerFormer.

➡️ Смотрим тут

✅ HSTU — или как получить 1 триллион параметров в RecSys

Как вы уже могли заметить отовсюду только и слышно про масштабирование рекомендашек. Яндекс везде рассказывают про свой мега крутой аргуес. Если коротко то:
вот в LLMках получилось, а у нас в RecSys не получается. Да и данных у нас столько нет…
Ребята из Meta AI, как мне кажется, наконец-то доделали трансформеры в том виде в котором они и должны быть. Вот вспомним статьи SASRec, BERT4rec, etc. Это все базовые модели написанные на основе LLM архитектур которые пытаются по сути представить товары как токены.

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

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

Так вот HSTU (Hierarchical Sequential Transduction Units) — переосмысляет задачу рекомендаций как генеративное последовательное преобразование событий пользователя. Без классического позиционного эмбеддинга, без агрегации всех признаков в один вектор на шаг — всё последовательнизируется (если так можно сказать).

Забудь про обычный self-attention, где ты нормируешь веса softmax'ом по всей последовательности. В HSTU используется Pointwise Aggregated Attention — здесь внимание считается *по каждой паре токенов отдельно*, без нормализации между ними.

Если пользователь 10 раз кликнул на один айтем, а другой посмотрел 1 раз — softmax вряд-ли что-то там почувствует в отличие от pointwise.

Кроме того, pointwise-внимание более устойчиво к нестационарному словарю объектов в стриминговых данных — то есть когда постоянно появляются новые элементы (товары, контент) и распределение взаимодействий со временем меняется.

HSTU вводит иерархическое представление признаков во времени: все категориальные признаки (идентификаторы пользователя, товара, контента и др.) преобразуются во вспомогательные «события» и вставляются в последовательность наряду с основными событиями взаимодействия пользователя.

Это превращает классическую схему рекомендации (где различные признаки объединяются в статический вектор признаков) в единый последовательный поток событий, который модель обрабатывает авторегрессионно с причинным вниманием.

В классических DLRM-моделях (e.g. sasrec etc) отдельные группы признаков (числовые метрики, категориальные ID и т.п.) проходят через сеть и агрегируются для предсказания (например, вероятности клика).

В HSTU же эти признаки «последовательнизируются»: формируется основной временной ряд из событий (например, просмотр элемента) и несколько вспомогательных рядов с категориальными признаками (например, ID категории, создателя контента и др.), которые вставляются как отдельные токены.

Модель с причинно-маскированным вниманием обучается предсказывать последующие события по этим объединенным последовательностям (тем самым интегрируя признаки непосредственно в процессе предсказания)

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

Проще говоря, если в HSTU входная последовательность на одном такте может выглядеть так:

[item_id=123] → [action_type=click] → [category_id=456] → [num_clicks=3] → [user_id=789] → …
то в SASRec придётся предварительно для этого «шага» собрать единый вектор:

E_input = Emb(item_id=123)
+ Emb(action_type=click)
+ Emb(category_id=456)
+ Emb(num_clicks=3)
+ Emb(user_id=789)
+ PositionalEmbedding(position_t)

Архитектура HSTU также оптимизирована по ряду других направлений. Модель существенно сокращает число линейных слоёв вне блока внимания — вместо шести линейных проекций, характерных для каждого слоя Transformer, остаются только две.

Это достигается более *простым и слитным дизайном* слоёв, уменьшающим объём активаций в памяти. По сути, HSTU объединяет некоторые этапы проекции и нормализации, что экономит память без потери качества.

Ещё одно отличие — эффективная реализация самовнимания с учётом разреженности последовательностей. Авторы HSTU разработали специальное оптимизированное *ядро внимания* для GPU, которое преобразует вычисление внимания в серию сгруппированных матричных умножений (аналогично идеям FlashAttention). Это позволяет добиться того, что сложность по памяти и времени растёт почти *линейно* от фактической длины непустой части последовательности, делая внимание memory, а не compute.

Дополнительно вводится метод Stochastic Length (SL) — стохастическое усечение последовательностей во время обучения.

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

Алгоритм SL выбирает подпоследовательность фиксированной длины из полного исторического списка действий пользователя, за счёт чего снижает затратность самовнимания с O(n²) до примерно O(n) на обучении. (не уверен точно не квадратичная)

В совокупности такие архитектурные решения делают HSTU более *лёгким и масштабируемым* по сравнению с классическим трансформером: модель получила возможность быть в > 2 раза глубже (больше слоёв) при том же объёме памяти, а скорость обучения и вывода превосходит оптимизированный Transformer++ в 1.5 – 15 раз на длинных последовательностях.

Также HSTU включает улучшенные механизмы относительного позиционного смещения, позволяющие лучше моделировать порядок элементов во временном ряду по сравнению с базовыми реализациями трансформера

Меньшее число активаций и весов вне блока внимания означает, что HSTU потребляет меньше VRAM/RAM на каждый обучающий пример, что критично в продакшене. Это позволило увеличить глубину модели (число слоёв) более чем вдвое без переполнения памяти, что способствует более тонкому обучению сложных зависимостей. В условиях рекомендательных систем с множеством гетерогенных признаков это важно: HSTU фактически интегрирует тысячи признаков пользователя и элемента прямо в последовательность событий, не взрывая при этом требования к памяти.

Так что это точно надо пробовать заводить в прод, скорее всего заменит все текущие трансформеры в ближайшее время. UPD в комментах выяснили что пока не заводим в прод 😂

Если вы что-то такое уже пробовали можете поделиться в комментах

➡️ Читать тут

✅ TrueTechDay RecSys

Сегодня на TrueTechDay смотрел как Никита Зелинский рассказывал про разные модельки после sasrec: bert4rec, pinnerformer, hstu, fuxi alpha etc.

Неплохая обзорная лекция, скажем про тренды. Ожидал что будет что-то как применяли в проде, но нет 😔

✅ FuXi-α — правильно ли мы учитываем фичи в трансформерах?

В прошлой серии мы обсудили концепцию генеративок, а именно HSTU и если коротко говорить они предложили учитывать все взаимодействия, а не агрегировать их софтмаксом и тем самым мы раздуваем модель и улучшаем качество. Так вот так же в комментах мы выяснили, что пока что ее пока что достаточно сложно завести в прод с позиционным кодированием (хотя у яндексовского Аргуса то получилось, а значит решение существует). Сегодня давайте посмотрим на другое решение, которое кажется более правдоподобным с продом.

FuXi-α — это модель от исследователей Huawei (USTC и Noah’s Ark Lab), разработанная как дальнейшее развитие идей трансформеров для рекомендаций с упором на учёт взаимодействий признаков и масштабирование.

Название модели к слову отсылает к Фуси (Fu Xi) – культурному герою, приписываемому создание систем предсказаний, что символично для рекомендательной системы. Было немного странно слышать от Никиты (смотреть TrueTechDay), что мы не называем свои модели какими нибудь Рюриками (щас Кандинский где-то заплакал).

Архитектурно FuXi-α представляет собой стек из нескольких FuXi-блоков, аналогичных декодерам трансформера (с самовниманием и полносвязными слоями). Однако внутри каждого такого блока применяются два нововведения:

➡️ Adaptive Multi-channel Self-Attention (AMS) – адаптивное многоканальное самовнимание

➡️ Multi-stage Feed-Forward Network (MFFN) – многоэтапный полносвязный блок

AMS по сути является модификацией стандартного multi-head self-attention, в которой внимание раздельно обрабатывает семантические, временные и позиционные аспекты последовательности.

Идея заключается в разделении разных типов сигналов: обычно трансформеры кодируют позицию добавлением позиционного эмбеддинга к входу и не имеют явного понятия о времени между событиями.

➡️ Семантический канал обрабатывает скрытые представления последовательности привычным образом, вычисляя матрицы QKV и веса внимания между элементами (например, между просмотренными item’ами)
➡️ Временной канал параллельно вычисляет веса внимания, основываясь только на разнице во времени между событиями (временных метках).
➡️ Позиционный канал – аналогично – учитывает только разницу позиций элементов в последовательности (индексы). Для этих двух каналов (временного и позиционного) не вычисляются обычные Q,K матрицы – вместо этого разницы времён и индексов дискретизируются по «корзинам» (bucket’ам) с learnable-параметрами для каждой разницы.

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

Кроме того, в реализации AMS у временного и позиционного каналов разделяются головы внимания, но значения (Value) для них берутся из того же пространства, что и у семантического канала.

Авторы отказались от собственных матриц Value для времени/позиции, чтобы не раздуть сложность – вместо этого эти каналы переиспользуют V из семантического, действуя скорее как модификаторы веса для семантических содержательных эмбеддингов.

Формально выход AMS получается конкатенацией результатов трёх каналов (семантического, позиционного, временного), которая затем проходит через RMS-нормализацию (layer norm в виде корня из среднеквадр. отклонения) и скалируется через поэлементное перемножение с матрицей параметров.

То есть FuXi-α также уходит от классического softmax, но делает это в контексте каждого канала: φ(QK) в семантическом канале – некоторая активационная функция (указана SiLU), а веса во временном/позиционном канала получаются через обучаемые функции от разниц (можно считать, тоже своеобразные нелинейности).

Вторая составляющая архитектуры – многоэтапный полносвязный блок (Multi-stage FFN) – направлена на усиление неявных (implicit) взаимодействий между признаками. Дело в том, что после слоя самовнимания модель всё ещё должна комбинировать информацию о различных признаках и элементах нерекуррентным образом (как это делают FFN в трансформере, захватывая попарные взаимодействия между признаками через нелинейность). FuXi-α расширяет этот процесс до двух стадий.

Стадия 1 MFFN берет выходы всех каналов AMS и объединяет их с исходным входом слоя посредством линейной проекции и резидуального суммирования. То есть, на первом этапе полносвязного блока модель возвращает в смесь сырые эмбеддинги предыдущего слоя, чтобы убедиться, что оригинальный контекст не потерян после внимания. Это похоже на расширенный residual connection: выход AMS сперва линейно трансформируется, а затем к нему добавляется (concat + sum) исходный вектор слоя, обеспечивая проход исходной информации дальше. (p.s. тут ничего нового)

Стадия 2 MFFN занимается собственно моделированием скрытых взаимодействий признаков. Выход Stage 1 пропускается через нормализацию (RMSNorm), затем через активацию SwiGLU (Switchable Gated Linear Unit) внутри ещё одного линейного слоя. Активация SwiGLU – это вариант нелинейности, где одна часть нейронов используется как управляющие «ворота» для другой части, что усиливает способность сети выражать сложные функции. После SwiGLU результата добавляется резидуальное соединение (skip connection) из Stage 1. (Как будто тоже не сильно лучше чем DCN с которым они сравниваются)

Таким образом, Stage 2 фактически реализует улучшенный FFN-трансформер (с GLU вместо ReLU), получающий на вход уже сочетание исходных признаков и осмысленных вниманиями представлений. Благодаря такому устройству, MFFN позволяет модели эффективно захватывать сложные нелинейные взаимодействия между эмбеддингами признаков и историей, одновременно избегая затухания градиента за счёт skip-коннектов на каждой стадии.

В остальном архитектура FuXi-α следует шаблону авторегрессивного трансформера: выход нескольких FuXi-блоков (AMS + MFFN) преобразуется в распределение на следующий объект через умножение на транспонированную матрицу эмбеддингов и softmax на выходном слое. Обучается модель по задаче прогнозирования следующих элементов последовательности (next-item prediction) с использованием loss-функции sampled softmax (семплирование негативных примеров для ускорения).

НО! Все их результаты они приводят на мувиленсе (вообще не смотрим на него) и на куайранд (относительно небольшой датасет музыки). Имеются вопросики к честной оценке и выборе датасетов, но идея неплохая.

➡️ Архив кстати с кодом

✅ Админ закончил школу

Вчера в ИТМО проходила защита дипломов — успешно защитил свою магистерскую на тему применения LLM в рекоме.

Скоро мою коллекцию пополнит красный диплом магистра и останется Last Dance до аспиранта и кандидата технических наук.

За время в магистратуре я попробовал себя и в стартап проектах, и в науке. Особенно круто было рисерчить статью с Ильей Макаровым и Никитой Севериным, надеюсь на продолжение. Для остальных все так-же открыт к call for collaboration 😀

Всем остальным желаю удачи в экзаменах и поступлении 🍀

👀 Такое редко бывает

…Но на Kaggle соревнование по рексису, участвовать я конечно не буду (Только если позовет Олег)

Всем кто будет участвовать удачи, поделитесь потом своими решениями, может пост какой сделаю 😎

UPD медалей нет, ток деньги

➡️ кагл

✅ Стоит ли верить в Scaling Law?

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

И в итоге мы получим три параметра в формуле масштабирования:
⭐️ объёма модели (число параметров)
⭐️ размера обучающего датасета
⭐️ вычислительных ресурсов (число FLOPs)

Эти законы были впервые систематически описаны в контексте трансформеров в статье OpenAI:
😛 `Kaplan et al., 2020 — "Scaling Laws for Neural Language Models"`

Они показали, что loss моделей убывает как степенная функция от размера модели, данных и compute.

Да и в общем-то в LLM, кажется логичным фурор над self attention и трансформерами, данные повсюду, и они бесплатные бери да пользуйся. Именно поэтому scaling law часто обсуждается в контексте трансформеров. Трансформеры оказались архитектурой, которая масштабируется очень хорошо.

В общем-то в сообществе RecSys посмотрели на это и подумали, а можем ли мы сделать тоже самое? И тут мы сталкиваемся со проблемами:
1️⃣А откуда взять столько данных? Большинство данных вообще не отображают предпочтения пользователя, они шумные да и вообще разряженные процентов 70 юзеров сделают меньше 30 кликов, тогда как в LLM счет на тысячи токенов.
2️⃣А как это все вместить в десятки мс инференса, инференс по всей истории юзера даже самых актуальных ллм явно даже с этим не справится (либо у вас есть свой датацентр для этого)

Ну вот у нас есть sasrec, bert4rec, any transformer, которые вполне справляются, но несравнимы по объему даже с самой маленький LLM.

Получится ли нам решить проблему масштабирования или нет? Оставлю открытую концовку для ваших комментов