Towards Deeper, Lighter and Interpretable Cross Network for CTR Prediction от Fudan University и Microsoft Research Asia:

Авторы тюнят архитектуру нейросетевой модели для задачи предсказания CTR. В целом эти наработки хорошо обобщаются на любую задачу ранжирования, не только на CTR. На текущий момент самая популярная архитектура в области — это DCN-V2 от Google c хитрым кросс-слоем, неявно моделирующим взаимодействия между фичами заданного порядка.

1. В статье предлагается улучшение DCN-V2 с помощью добавления гейтинга в кросс-слой: добавляем поэлементное умножение промежуточного вектора на сигмоиду от вектора, полученного линейным слоем (похоже на всякие GRU/LSTM). Таким образом модель может лучше контролироватЬ, какие взаимодействия между фичами ей важны.

2. Одна из основных проблем CTR моделирования нейросетками — это сложность обработки категориальных фичей. В большинстве моделей используются таблицы эмбеддингов и приходится подбирать размерности эмбеддингов для отдельных фичей. А самих фичей могут быть тысячи. Простой вариант, в котором мы всем фичам даем одну и ту же размерность эмбеддинга, занимает очень много памяти (и флопсы тоже сильно растит). Поэтому приходится выдумывать какие-то эвристики или механизмы автоматического определения размерностей фичей. Авторы приводят как пример эвристику из DCN-V2: embedding_dim = 6 * cardinality^{1/4}, т.е. размер эмбеддинга скейлится от размера словаря фичи. В статье же предлагается более умный подход: сначала обучаем модель с одинаковым размером всех эмбеддингов, затем для каждой отдельной матрицы эмбеддингов с помощью PCA оцениваем какое количество компонент можно оставив, потеряв минимум информации. Полученные количества компонент используем как новые размерности эмбеддингов, с которыми заново обучаем модель.

Результаты у обоих изменений хорошие: гейтинг улучшает качество, FDO (так авторы назвали технику из второго пункта) позволяет в несколько раз ужаться по памяти.

ITEm: Unsupervised Image-Text Embedding Learning for eCommerce от eBay.

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

Архитектура простая, похожа на то, что я видел в других статьях: бьем картинку на патчи, текст бпе-токенизируем (авторы строят свой токенизатор), затем вместе с CLS-эмбеддингом подаем это всё в трансформер. В статье на написано как конкретно патчи превращаются в эмбеддинг, обычно это либо небольшой ResNet, либо просто выпрямление патча в эмбеддинг с небольшой MLP'шкой поверх.

Пять задач предобучения: три довольно стандартные (матчинг тайтла и картинки товара, MLM и MIM, I for image), а вот другие две вижу в первый раз — из глобального представления товара, полученного с помощью CLS токена, предсказываем значения замаскированных токенов/патчей. Для этого конкатенируем глобальный вектор с позицией замаскированного токена и проводим через MLP. Таким образом заставляем модель выучивать хорошее глобальное представление товара.

Лоссы для задач авторы подбирают так, чтобы они были в одном масштабе: IMT (image-noscript matching) с весом 1, языковые задачи про бпе-токены с весом 0.1, и задачи про патчи картинки сс весом 0.01.

Качество оценивают на двух задачах: нахождения дубликатов товаров (данные собрали внутри компании с помощью асессоров) и предсказание листовой категории товара. В первом случае модель применяют сразу, во втором случае на задачу дообучаются. Сравниваются с text-only робертой, image-only ResNet50 и с мультимодальным CLIP'ом (в котором эмбеддинги картинки и текста просто конкатенируются): по качеству всех превосходят.

В статье не хватает ссылок на аналогичные статьи от Алибабы (1, 2, 3, 4, 5, 6, 7, 8) и Меты (хотя бы CommerceMM), видимо либо статья уже старая, либо авторы не сильно прошерстили литературу. Тем не менее, если воспринимать статью как технический репорт, то она довольно неплоха — рассказ цельный, все детали присутствуют.

#spotlight

Hiformer: Heterogeneous Feature Interactions Learning with Transformers for Recommender Systems — статья про нейросетевое ранжирование от Google DeepMind. Препринт, опубликовали сегодня на архиве. Есть авторы DCN-V2.

- В нейросетевом ранжировании, в отличие от других областей, трансформеры все еще не жгут. Авторы статьи выдвинули свою гипотезу и сумели побить нетрансформерную соту, при этом еще и адаптировали свою архитектуру так, чтобы инференс был не тяжелей чем у DCN-V2

- Трансформер плохо работает с гетерогенными, неоднородными данными. В NLP, CV и sequential рекомендашках этот эффект не возникает, т.к. текстовые токены, патчи картинок и пользовательские исторические события довольно однородны и могут спокойно жить в одном семантическом пространстве. Про исторические события пользователя еще можно поспорить, но и по нашим экспериментам, и по статьям кажется что особых проблем с гетерогенностью для них не возникает.

- К каждому токену входной последовательности применяются одни и те же линейные преобразования (Q,K,V в аттеншне и FFN слои). Между каждыми двумя токенами близость считается одной и той же формулой. Такой подход логичен, когда все токены живут в одном семантическом пространстве. Но такое предположение слишком сильно для фичей ранжирования: они очень разные по своей семантике, происхождению, способу получения и т.д.; у фичей могут быть разные распределения. Чтобы выжать максимум качества, нужно применять к разным фичам разные преобразования, и каждая пара фичей должна обрабатываться по-разному. По мнению авторов это главное отличие сеток типа DCN-V2 от простого применения трансформера над фичами: там эту проблему уже давно решили и взаимодействия между фичами учитываются по-разному.

- Авторы вводят гетерогенный трансформер, в котором для каждого токена-фичи i вводятся свои матрицы Q_i, K_i, V_i, и в FFN-слоях тоже матрицы отдельные. Получается, что все фичи обрабатываются по-разному, и скалярные произведения между разными фичами тоже разные. Мы довольно сильно раздуваемся по памяти, но по флопсам такой трансформер эквивалентен обычному.

- Следующий вариант архитектуры, Hiformer, выглядит еще сложнее: конкатенируем эмбеды фичей в единый большой эмбеддинг [x1, x2, ..., xn], затем домножаем на гигантскую матрицу, возвращающую вектор той же размерности. Так делаем чтобы получить Q, K, V представления фичей для аттеншна. Мы предполагаем что в этом новом векторе координаты сооветствуют всё тем же фичам, и сплитим этот вектор обратно в отдельные фичи. Чтобы такая штука была внедряема, нужно добавить низкоранговое разложение для этой большой матрички.

- Другие интересности: уменьшают количество входных вещественных фичей — конкатенируют их и домножают на матричку, порождающую N разных эмбедов одинаковой размерности; для лоссов и решения задач используют CLS токены на входе трансформера, которые называют task embeddings; размерности эмбеддингов фичей — 128, размерности ключей и запросов в одной голове аттеншна — 16, размерности value — 64.

- Внедряются в Google Play Store: всего 30 вещественных фичей и 31 категориальная. Размеры словарей категориальных фичей от сотен до миллионов. По флопсам равны DCN-V2, по качеству дают +0.4% "engagement metrics". Оффлайн метрики можно посмотреть в табличке.

Learning from Negative User Feedback and Measuring Responsiveness for Sequential Recommenders от Google — моя любимая статья с прошедшего в августе RecSys 2023.

Обычно в кандидатогенерации мы используем contrastive loss, заточенный под положительный фидбек пользователя. Самый популярный сеттинг — берем "позитив" пользователя, добавляем к нему "in-batch" и "random" негативы, возможно делаем log-q correction (Mixed Negative Sampling, PinnerFormer). И максимизируем логарифм позитива после взятия софтмакса по всем объектам. Если вас испугало обилие терминологии, загляните в комментарии :)

Одна из проблем такого подхода — он плохо учитывает explicit и implicit негативы пользователя. Для продукта youtube shorts, про который идет речь в статье, негативный фидбек — это скипы и дизлайки коротких видео. У модели с таким лоссом нет реактивности на негативный фидбек. В какой-то мере это можно полечить простой фильтрацией по историческим негативам пользователя, идущей уже после кандидатогенерации. Тем не менее такой способ тратит ёмкость и квоту нашего кандидатогенератора.

Авторы предлагают добавить "not-to-recommend" лосс, который является полной противоположностью стандартному лоссу: берем "негатив" пользователя, добавляем к нему чужие "in-batch" объекты. Затем максимизируем вероятность, что мы НЕ выберем истинный негатив пользователя. По сути, мы учим модель рекомендовать что угодно кроме истинного негатива, т.е. чужие объекты из батча. Важно, что здесь именно максимизируется log(1 - prob(neg)), а не минимизируется log(prob(neg)) — второй вариант вычислительно не стабилен при маленьких вероятностях. Обычный "позитив" лосс всё так же остается, т.е. теперь мы оптимизируем два лосса.

Также авторы добавляют негативный фидбек в историю, но это уже не ноу-хау — в рекомендациях short-form content так делают многие, в т.ч. мы в трансформерах для Яндекс Музыки. Тем не менее сам факт, что этого недостаточно для хорошей реактивности на негативный фидбек, вызывает интерес. Лосс авторов дает значительное улучшение метрик поверх добавления негативов в историю. Конкретные метрики можно сравнить в статье, их там довольно много.

Последний интересный момент — авторы с помощью симуляции проверяют, что их новая модель реактивна к негативному фидбеку, что рекомендации меняются, когда приходит негативный фидбек. Симуляциям пользователей я обычно не доверяю. Учить с помощью них модели или оценивать качество страшновато, т.к. сами модели, используемые для симуляции, довольно плохо приближают пользователей. Иначе они сами по себе были бы хорошими рекомендательными системами и ничего симулировать не нужно было бы :) Но в данном случае идея выглядит здраво: генерируем какую-нибудь случайную траекторию пользовательских взаимодействий, затем в конце траектории рассматриваем два сценария — положительное и отрицательное взаимодействие с одним и тем же айтемом. Затем сравниваем насколько сильно меняется распределение по рекомендованным айтемам. Авторы показывают что их архитектура гораздо больше реагирует на негативный фидбек, чем варианты без негативного лосса или без негативного фидбека в истории.

Дорогие подписчики, для вас ребус. Нужно найти несуществующую рекомендательную модель :)

P.S: здесь почти все модели — это так называемые sequential recommenders, по истории пользователя предсказывающие его следующие взаимодействия.

#arxiv_weekly (13.11.23 - 17.11.23)

1. Hiformer: Heterogeneous Feature Interactions Learning with Transformers for Recommender Systems от Google Deepmind. Авторы предлагают свою трансформерную архитектуру для ранжирования, хорошо работающую с гетерогенными данными, т.е. фичами разной природы. Бьют по качеству DCN-V2 с таким же latency, в проде +0.4 "engagement metrics" для Google Play Store. Разбор статьи.

2. Scaling User Modeling: Large-scale Online User Representations for Ads Personalization in Meta от **** про единые пользовательские эмбеддинги по пользовательским фичам (не путать с sequential recommender) для рекламных CTR моделей. Сервис считает эмбеддинги асинхронно с запросом, отдавая устаревшую версию с нулевым latency. Борятся с embedding distribution shift при дообучении с помощью усреднения последних трех версий пользовательского эмбеддинга. В проде +2.67% "online ads metric gains", интегрально по всей Мете. Разобрали в прошлом посте.

3. Mitigating Pooling Bias in E-commerce Search via False Negative от Instacart и Pennsylvania State University. Авторы рассматривают задачу e-commerce поиска, в которой надо для запроса находить релевантные товары. Предлагается использовать близость между поисковыми запросами, чтобы уменьшать количество false negative'ов среди отобранных из батча отрицательных примеров.

4. Towards a Technical Debt for Recommender System от Tampere University, Roku Inc. и University of Oulu про технический долг в рекомендательных системах. Парочка интересных пунктов есть, но обычно мне такие пдфки нравятся больше, здесь она довольно короткая и без особенных инсайтов. Для сравнения, есть крутая пдфка от Google 2015-го года Hidden Technical Debt in Machine Learning Systems, а про рекомендательные системы не так давно вышла Methodologies for Improving Modern Industrial Recommender Systems.

5. От **** вышло еще две статьи с говорящими за себя названиями, про NAS (Neural Architecture Search) и AutoML: Rankitect: Ranking Architecture Search Battling World-class Engineers at Meta Scale и AutoML for Large Capacity Modeling of Meta's Ranking Systems.

6. Вышло две статьи, в которых много аффилиаций из Kuaishou: Mixed Attention Network for Cross-domain Sequential Recommendation с довольно сложной нейросеткой для кросс-домен сценария и Inverse Learning with Extremely Sparse Feedback for Recommendation про металернинг для борьбы с шумными таргетами в рекомендациях.

7. ID Embedding as Subtle Features of Content and Structure for Multimodal Recommendation от китайского Northeastern University про использование обучаемых эмбеддингов по айдишникам в мультимодальных рекомендательных моделях.

P.S: прошлый arxiv weekly отредактировал, привёл в похожий формат с короткими комментариями. Посты про добавление гейтинга в DCN-V2 и мультимодальный эмбеддинг товара в eBay тоже причесал. Призываю глянуть :)

Сегодня вышла статья Scaling Law of Large Sequential Recommendation Models от WeChat, Tencent и Gaoling School of Artificial Intelligence. Я, заинтригованный, бросился её читать. И тут на пятой странице вижу следующий абзац:

We adopt the widely-used leave-oneout strategy, in which the last item is used as the test item, the item before the last item is used as the validation item, and the remaining items are used for training.

Т.е. авторы используют постановку next item prediction, в которой нужно глядя на историю пользователя предсказывать следующее взаимодействие. Причем для теста откладывается последнее взаимодействие из каждой пользовательской истории.

Почему это плохо:

1. Нет деления на трейн/тест по времени. Это буквально data leakage, не соответствующий сценарию реального применения модели в продакшне. В таком сетапе можно выбить высокие метрики не за счет обобщающей способности, а за счет меморизации. Трансдуктивные модели, которые используют обучаемые айдишники, могут в таком сетапе показывать очень высокие метрики, а потом в продакшне давать нулевой профит. Референсы для чтения: A Critical Study on Data Leakage in Recommender System Offline Evaluation и Take a Fresh Look at Recommender Systems from an Evaluation Standpoint от Nanyang Technological University.

2. Предсказание следующего айтема, даже если добавить тайм-сплит, не очень хорошая задача. Траектория взаимодействий пользователя очень сильно зависит от продакшна (logging policy). Более хорошие метрики с большой вероятностью получит та модель, которая будет лучше имитировать продакшн. Даже если в продакшне очень плохие рекомендации. Референс: Offline Evaluation for Reinforcement Learning-based Recommendation: A Critical Issue and Some Alternatives от Naver Labs Europe.

3. Предсказывать следующее событие в истории пользователя без лага — жадная задача, которая приводит к плохому разнообразию рекомендаций. Об этом писал Pinterest в статье TransAct: Transformer-based Realtime User Action Model for Recommendation at Pinterest. Лучше эмулировать хотя бы небольшую задержку доставки данных. Pinterest, например, при обучении случайным образом выкидывает сколько-то последних событий пользователя за последний день, чтобы модель не скатывалась в эдакий "локальный оптимум" однообразных рекомендаций, похожих на недавнюю историю.

4. Обычно в таком сетапе для оценки качества сэмплируют небольшое количество случайных негативов (сотню). В качестве метрик репортится nDCG и HitRatio для позитива против негативов. Такая метрика не очень устойчива, от сэмплирования к сэмплированию все меняется. И непонятно что оценивает, т.к. реальный сценарий использования модели будет другой. Либо модель предполагается как верхняя стадия рекомендаций, ранжирование, и тогда эта сотня кандидатов будет вовсе не случайная, а из кандидатогенератора. Либо модель используется как кандидатогенератор / одностадийная рекомендательная система, тогда в качестве негативов надо использовать весь каталог айтемов. Референс: On Sampled Metrics for Item Recommendation от Google Research.

Довольно много статей репортят такие метрики. Иногда на это можно закрыть глаза, если предлагаемый в статье inductive bias должен увеличивать скорее генерализацию, а не меморизацию. Но в статье про скейлинг моделей это довольно сомнительно, т.к. при росте модели может очень сильно буститься меморизация.

Я часто использую термины трансдуктивность / индуктивность. Индуктивность предполагает, что модель умеет работать на новых объектах, не встречавшихся в обучении. Например, языковые модели и рекомендательные модели, представляющие айтемы через текст, индуктивны. А модели, использующие для айтемов обучаемые айдишники, e.g. SASRec, трансдуктивны. Почитать про это можно в Situating Recommender Systems in Practice:Towards Inductive Learning and Incremental Updates от Microsoft.

Меморизация — это больше про способность запоминать корреляции в обучающих данных. Генерализация, т.е. обобщающая способность, больше про транзитивность, умение выводить новые знания. См. Wide & Deep Learning for Recommender Systems от Google.

Пару дней назад, на конфе Сбера состоялся доклад от Pinterest. Рассказывали про эволюцию ранжирования рекламы. По выступлению Andrew Zhai на WWW'22 можно сказать, что вся информация справедлива и для рекомендательного стека. Итак, эволюция ранжирования:

1. (2014) Логистическая регрессия над вручную подобранными, handcrafted фичами.

2. (2017) Добавили трансформацию фичей с помощью градиентного бустинга, вдохновившись статьей Practical Lessons from Predicting Clicks on Ads at Facebook. Т.е. листья деревьев из GBDT используются как фичи для логрега. Меморизующий логрег инкрементально дообучается каждый час, генерализующий GBDT обучается реже, оффлайново.

3. (2018) Перешли на нейросеть для ранжирования. Называют её Deep&Wide, но кажется, что в отличие от оригинала, она без линейной модельки. В первой версии оставили всё те же фичи, которые были у прошлой модели. Чтобы измерять важность фичей, используют случайные перестановки. Overall важный переход, без которого будущие улучшения были невозможны.

4. (2020) Вместо отдельной нейросетки под каждый таргет, сделали одну мультизадачную нейросеть. Убрали ручной feature engineering, добавили в нейросеть неявное моделирование взаимодействия фичей с помощью LatentCross слоёв (e.g. DCN-V2 и MaskNet). Решили назвать это AutoML (не путать с neural architecture search).

5. (2021) Добавили attention для обработки краткосрочной истории пользователя. Как и у Алибабы в Deep Interest Network, используют раннее связывание кандидата и истории. Айтемы представляют через предобученные PinSage эмбеддинги.

6. (2022) Апгрейднули аттеншн до трансформера, стали обрабатывать долгосрочную историю (100+ событий за 3 месяца истории), подтюнили работу с последовательностями (умная обработка таймстемпов, эмбеддинг типа события).

7. (2022) PinnerFormer. Сделали универсальный эмбеддинг пользователя в Пинтересте с помощью оффлайнового трансформера, заточенного под long-term сигнал. End-to-end архитектуру можно глянуть в Rethinking Personalized Ranking at Pinterest: An End-to-End Approach.

#arxiv_weekly (20.11.23 — 23.11.23)

Неделя в плане статей была неурожайная, поэтому дайджест будет не совсем рекомендательный и не совсем серьезный. Тем не менее, все статьи из секции information retrieval:

1. У китайского e-commerce гиганта Meituan вышла статья про использование глубокой пользовательской истории в CTR моделях: Deep Group Interest Modeling of Full Lifelong User Behaviors for CTR Prediction. Добавляют в историю к кликам другие действия (добавления в корзину, заказы, etc). "Сжимают" все события с одинаковым item_id в один "групповой" вектор. Чтобы сформировать предсказание для кандидата, используют эти групповые векторы + все события с таким же item_id, как у кандидата, на входе в аттеншн.

2. Deezer, один из крупнейших музыкальных сервисов, выпустил статью про Mere Exposure Effect: когда пользователю рекомендуешь один и тот же айтем, его интерес сначала возрастает, затем падает. Моделируют этот эффект в своей простенькой модельке, чтобы получить побольше качества. См. Ex2Vec: Characterizing Users and Items from the Mere Exposure Effect.

3. LLM'ки всё еще не бьют по качеству более классические рекомендательные модели, тем не менее у них есть большое преимущество в виде возможности генерировать объяснения рекомендациям. А что если мы научим LLM'ку генерировать объяснения для рекомендаций какой-то другой модели? Авторы из University of Science and Technology of China и Microsoft Research Asia исследуют этот сценарий в статье RecExplainer: Aligning Large Language Models for Recommendation Model Interpretability.

4. Машинное обучение поможет шарить за мемы: авторы из USC Information Sciences Institute и Vrije Universiteit Amsterdam с помощью визуального трансформера и готового каталога с мемами анализируют посты с Дискорда и Реддита. Ищут среди них мемы, соотносят с каталогом, анализируют тренды. Статья Contextualizing Internet Memes Across Social Media Platforms.

5. Коллаб между KAIST и корейской таможней: авторы из KAIST совместно с корейскими таможенными офицерами разработали модельку, по текстовому описанию помогающую классифицировать товар. Она также предлагает объяснение своему выбору, выделяя кусочек описания выбранного кода классификации. Explainable Product Classification for Customs.

6. Я тут выше задокументировал свое негодование по поводу сомнительных эвалов в next-item-prediction в контексте статьи Scaling Law of Large Sequential Recommendation Models от WeChat, Tencent и Gaoling School of Artificial Intelligence. Если вас это не смутило или у вас есть юзкейсы, похожие на next-item-prediction, то в этой статье может быть вполне интересная информация про скейлинг (рост качества в зависимости от размера) sequential recommender'ов.

7. На arxiv мелькнула статья с названием Fact-based Court Judgment Prediction от Indian Institute of Technology. Название интересное, ситуация страшная.

Хочу порекомендовать вам канал своего коллеги из Яндекса @toshiknoscript. Антон пишет про программирование, нейросети, компьютерное зрение, тайм-менеджмент, рабочие процессы, постит мемы. Все посты очень читабельные и понятные: даже мне, два раза в год пишущему код на плюсах, удаётся их распарсить. Не говоря уже о мемах :)

Это уникальная возможность посмотреть на все эти вещи через призму сеньор-разработчика из Яндекса и главного мемолога Службы Компьютерного Зрения.

Ссылка на канал: @blog_toxa

Забавный факт про Spotify.

Первые пять лет существования (2008 — 2013) в Spotify не было рекомендательной системы. Затем один из инженеров, Erik Bernhardsson, в своё свободное время сколотил первую версию Discover Weekly. Менеджеры к этому сначала отнеслись скептически, но поделку хорошо оценили сами сотрудники и по итогу фича проросла в продукт.

Первая рекомендательная система была довольно простенькая. Erik вдохновлялся успехами Нетфликса (Netflix Prize), а также word2vec и PLSA. Построил большую user-item матрицу количества прослушиваний, в которой в качестве айтемов были треки и возможно другие сущности (артисты, альбомы, etc). Затем применил матричную факторизацию. Итоговые векторы размерности 40 использовались для рекомендации новых треков пользователю. Чтобы батчовая джоба поиска ближайших соседей бежала побыстрее, Эрик написал собственный движок ANNOY. Судя по всему, и по сей день подобная коллаборативная фильтрация является основным кандидатогенератором для персональных рекомендаций в Spotify.

Ну и, наконец, держите видео, на котором Эрик прыгает через диван в офисе Спотифая 12 лет назад :)

Представляю вашему вниманию самый популярный лосс для кандидатогенерации, знаменитый Sampled Softmax Loss. Он же InfoNCE, NTExent и Softmax with sampled negatives.

Обычно я посты пишу на русском, и затем перевожу на англ для Линкедина, в этот раз получилось наоборот. Если ваш english is perfect, призываю прочитать оригинал. Формулы вставить в телеграме я не смог, они будут в комментариях к посту.

Надеюсь, после этого поста будет проще распарсить часть моих будущих (и прошлых) постов.

Sampled Softmax Loss for Retrieval Stage in Recommender Systems.

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

Чтобы обучить кандген модельку, чаще всего используется contrastive learning. Самый популярный нынче вариант — это sampled softmax loss. У него много разных названий, пожалуй, два других самых известных — это InfoNCE и NTExent. По названию можно понять в чём суть: чтобы посчитать вероятность позитива, вместо софтмакса по всей коллекции айтемов сэмплируем небольшое количество негативов. Можно считать, что мы таким образом аппроксимируем исходный софтмакс по всей коллекции. Почему бы не сделать полный софтмакс? Это медленно. Что-то подобное, кстати, уже делали во времена word2vec в качестве альтернативы иерархическому софтмаксу.

Cпособов сэмплировать негативы несколько. Самый очевидный — сэмплировать равномерно по всей коллекции. Градиент лосса с таким софтмаксом будет несмещенной оценкой градиента лосса для софтмакса по всей коллекции (it's nice actually). Подход рабочий, особенно если используются трансдуктивные эмбеды по айдишникам: не нужно делать никаких особенных телодвижений для получения векторов, только лукап по таблице эмбеддингов.

Теперь, если вы вдруг обучаете нейросетку над айтемом, т.н. айтем башню, то равномерно сэмплировать негативы уже больновато. Нужно целиком прогонять эту нейросетку для каждого сэмплированного негатива. Да еще и данные, которые идут на вход нейросетке, тоже надо откуда-то доставать. По счастью есть еще один потенциальный источник негативов, in-batch negatives: когда мы набираем батч из пар <юзер, айтем>, айтемы других пар из батча можно переиспользовать как негативы для текущей пары. Так как эмбеды всех пар мы и так считаем, это бесплатно. В мульти-гпу сетапе так вообще можно использовать в качестве негативов айтемы со всех гпу-карточек — cross-device in-batch negatives.

Однако оценка градиента становится смещённой. Ин-батч негативы не совсем "случайны". Вероятность айтема попасть в батч пропорциональна частоте его появления в данных, aka unigram distribution. Чем популярнее айтем, тем чаще он появляется в батче, а значит используется как негатив для остальных пар из батча. Эффект довольно легко интерпретировать: модель часто видит в качестве негативов популярные айтемы и начинает их больше штрафовать, "меморизуя" их популярность. С какой-то точки зрения это полноценный popularity debiasing, см. Contrastive Learning for Debiased Candidate Generation in Large-Scale Recommender Systems by DAMO Academy, Alibaba Group.

Смещение оценки градиента приводит к падению римской империи качества, что демонстрирует Google в статье Sampling-Bias-Corrected Neural Modeling for Large Corpus Item Recommendations. Для спасения предлагается техника под названием logQ correction, под капотом которой дважды применяется importance sampling.

Ещё не все проблемы решены: хоть у нас теперь и правильное распределение, но в негативах не встречаются объекты, редко попадающие в выдачу, aka стюпиды aka изи негативы. А когда мы выкатываемся в продакшн, эти стюпиды попадут в ANN индекс и мы на них будем плохо работать. В качестве фикса нужно добавить щепотку равномерно сэмплированных негативов. Получаем технику Mixed Negative Sampling от Google: Mixed Negative Sampling for Learning Two-tower Neural Networks in Recommendations.

Кроме Гугла ин-батч негативы || logQ || MNS
используют такие компании, как JD.com, Pinterest, Meta, Instacart, Miscrosoft, Alibaba, Etsy, eBay, Walmart, Baidu.

Fun fact: Yoshua Bengio это всё исследовал еще в начале нулевых, см. раз и два.

P.S: оригинал поста на линкедине.

P. P. S: у Миши @WazowskiRecommends есть хороший пост на эту же тему, я его специально не перечитывал, чтобы сделать ансамблирование :)

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

Вообще идей для рекомендаций в тг можно нагенерировать кучу, интересно что в итоге действительно реализуется.

Чтобы прокоммуницировать с инопланетянами, нужен всего лишь word2vec.

В своё время статья Word Translation Without Parallel Data, опубликованная на ICLR 2018, произвела на меня неизгладимое впечатление. За что люблю машинное обучение и deep learning в частности — за "вау-эффекты", вызываемые разными прикольными результатами.

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

Обучаем для обоих корпусов векторные пространства слов, например, с помощью word2vec. Затем учим GAN: генератор (умножение на обучаемую матрицу) учится переводить элементы из одного пространства в другое, а дискриминатор учится определять исходное пространство. Чтобы перевести слово, применяем генератор (умножаем вектор слова на матрицу) и ищем наиболее близкое слово из другого языка в векторном пространстве. И это адекватно работает!

Какой гипотезой мы здесь пользуемся: векторные пространства языков имеют похожую структуру. Поэтому можно попытаться "наложить" одно векторное пространство на другое, что мы умножением на матрицу генератора и делаем. По-научному сейчас это назвали бы "unsupervised alignment of embedding spaces".

Когда-то философ Виттгенштейн опубликовал свой труд Tractatus Logico-Philosophicus, в котором пытался задать язык, идеально описывающий реальность. Язык фактов :) Опираясь на этот труд, можно было бы и поверить в нашу гипотезу. Но сам же Виттгенштейн в более поздние годы переобулся и постулировал, что язык задаётся контекстом использования. Иногда его цитируют, когда объясняют word2vec :)

И на затравку: такой подход с unsupervised alignment можно применять для zero-shot двубашенных рекомендаций, когда у нас есть векторы объектов. С помощью обученного генератора можно получить рекомендации для пользователей, даже если нет взаимодействий между пользователями и айтемами.

#arxiv_weekly (27.11.23 — 01,12,23)

На этой неделе невероятных прорывов опять нет, тем не менее статьи поинтересней, чем на прошлой.

1. Насколько важна информация про автора твита для рекомендации твитов к новостям? Таким вопросом задались (внезапно) в Google Research в статье Creator Context for Tweet Recommendation. Спойлер: важна, с помощью метаданных автора (имя, логин, био, вебсайт, локация) можно довольно сильно забустить качество.

2. NAVER LABS Europe, много занимающиеся РЛ'ем, опубликовали статью про свой симулятор пользователя SARDINE: A Simulator for Automated Recommendation in Dynamic and Interactive Environments. Я не большой фанат симуляции пользователей, но фанат этой лабы. Всегда приятно читать в их статьях описания разных явлений, эффектов, проблем в рекомендательных системах.

3. В рекомендашках самая толстая часть модели — это эмбеддинги. Есть куча способов ужаться: хэширование, квантизация, прунинг, dimension reduction, product quantization. Авторы из Peking University попробовали их все в статье Experimental Analysis of Large-scale Learnable Vector Storage Compression.

4. Одна из главных проблем в CTR моделях — это data drift. Распределения нестационарные: тренды, поведение пользователей, потребности рекламодателей меняются. На академических датасетах часто на это забивают, а вот авторы из Huawei Turkey R&D Center продемонстрировали хорошие приросты в статье Temporal Importance Factor for Loss Functions for CTR Prediction, добавив пропорциональное свежести взвешивание сэмплов. В индустрии такая техника пригодится разве что для обучения нулевой версии модели, а дальше её лучше дообучать в онлайне. Тем не менее демонстрация проблемы data drift хорошая.

5. Если вы любите джаву, и вам очень хочется завести гибридную (hnsw + inverted index) кандидатогенерацию на CPU, то лучший вариант — это Apache Lucene + onnx runtime. Так утверждают ресерчеры из University of Waterloo в статье End-to-End Retrieval with Learned Dense and Sparse Representations Using Lucene.

Отдельная секция про LLM:

1. В Meituan экспериментируют с одновременной подачей айдишников и естественного языка в LLM'ки для рекомендаций. Чтобы LLM адекватно работала с айдишниками, добавляют contrastive learning между айдишником айтема и его описанием, а также задачу предсказания описания следующего айтема по истории айдишников. Подробности в ControlRec: Bridging the Semantic Gap between Language Model and Personalized Recommendation.

2. Один из способов ранжировать документы по запросу с помощью LLM — это считать вероятность генерации запроса после документа. В Alibaba Group улучшают этот подход: сначала (1) дообучаются на weakly supervised корпусах с парами типа "ответ, вопрос", "коммент, пост", "содержимое страницы, заголовок", затем (2) дообучаются на задачу ранжирования. Чтобы у LLM'ки не пропала способность генерировать связный текст, добавляют доп. лоссы во вторую стадию. Результаты в RankingGPT: Empowering Large Language Models in Text Ranking with Progressive Enhancement

3. Ни для кого не секрет, что в языковых моделях есть bias'ы. Обычно при обучении их пытаются убрать или хотя бы минимизировать. Ученые из Technische Hochschule Köln поступили наоборот и научились вносить в языковую модель нужный bias. Затюнив модель на корпусе левых (или правых) политических статей, можно научить модель выдавать нужную пропаганду. Статья 𝑄𝑏𝑖𝑎𝑠 - A Dataset on Media Bias in Search Queries and Query Suggestions

На десерт перескажу цитату из статьи Word for Person: Zero-shot Composed Person Retrieval от Beijing University of Posts and Telecommunications:

Searching for specific person has great security value and social benefits.

Мораль думайте сами :)

Сегодня на YaTalks выступал Олег Лашинин @lashinin с обзорным докладом про рекомендательные системы.

Рассказывал про:
1. Проблемы с оценкой качества и результатами: global timeline, movielens, фидбек лупы, баги в имплементациях, etc
2. Модели: матричная факторизация, линейные модели, графовые сети, трансформеры
3. Тренды: chatgpt для рекомендаций, обучение с подкреплением (для предсказания следующего взаимодействия или бизнес-метрик, бандиты для рекомендаций)

Призываю посмотреть, доклад хороший. Ссылочка :)

Посетил сегодня конференцию по рекомендательным системам от Вышки. Тезисно:

1. Во время нетворкинга пытался всех убедить, что будущее за графовыми сетками и РЛ. Надеюсь, сработало

2. Попросили точный прогноз когда РЛ заработает, сказал “через 5-15 лет”

3. Получил подтверждение, что другие рексис лиды тоже скептически относятся к языковым моделям. Ждем, пока настанет наше время

4. One hot encoding — “один бит горит”

5. Фраза “у нас kpi не на статьи” — фиговая отмазка для отсутствия публикаций

Про чтение статей (для R&D).

Доклад, по которому я планировал писать пост, был структурирован следующим образом — (1) мотивация, (2) где искать информацию, и (3) как её структурировать. Но как-то в текстовом виде нормально написать про мотивацию не получается, в голову лезут одни банальности, поэтому напишу следующее: я испытываю эстетическое удовольствие от получения новой информации по интересующим меня темам. У меня в голове есть образ архивного историка в гигантской библиотеке, копающегося в древних пергаментах в поисках истины.

Другие причины для ресерча: он влечёт долгосрочные улучшения качества базовых технологий, развитием которых вы занимаетесь. Помогает дотягиваться до высоко висящих фруктов и не застревать в локальных оптимумах. Еще можно приплести exploration vs exploitation аналогию, где exploration — это чтение литературы, а exploitation — копание в собственных идеях.

Для себя я выделил два основных сценария поиска информации:
1. Retrieval — поиск информации по конкретной теме. Вы уже знаете какая у вас задача, ну или просто хочется стать экспертом в конкретной теме. Т.е. более точечное, узконаправленное развитие знаний.
2. Discovery — вас интересует достаточно широкая область, без конкретики; целью является скорее не отставать от трендов, не упустить появление новых технологий. Это больше про широту (ширину?) познаний.

Более простой из двух — определенно retrieval:
1. Главное — найти хотя бы одну хорошую статью по теме. Дальше поможет граф цитирований. Надо смотреть на кого ссылаются авторы, кто ссылается на них (google scholar). Полезно смотреть другие публикации авторов (тоже google scholar); и прошлые, и будущие. Последний автор статьи это, как правило, руководитель группы, в публикациях которого отражена работа всей команды. Related works даёт чуть больше контекста про то, на что ссылаются авторы.
2. Поиск по arxiv и гугление: поиск по архиву, конечно, странно работает; иногда можно не найти статью по присутствующему в ней киворду.
3. У лидеров индустрии есть страницы с публикациями, инженерные/ресерч блоги. Полезно сформировать у себя понимание какие компании на чем специализируются, чтобы знать чьи блоги просматривать. E.g. Spotify, Pinterest, Twitter, Google
4. Тематические воркшопы на конференциях. Обзоры (статьи, блоги).

Основные источники discovery:
1. Регулярное чтение arxiv секции нужной области (e.g. cs.IR). Есть и ежедневные (new), и еженедельные (recent) списки новых публикаций. Просматривать надо не в лоб, а с некоторой процедурой отбора кандидатов (см. ниже).
2. Свежие конференции. Может быть небольшая задержка относительно arxiv, в который статьи часто попадают еще будучи пре-принтами.
3. Научные семинары на работе и общение с коллегами.
4. Дайджесты (e.g. #arxiv_weekly)

Процедура фильтрации нерелевантных статей в arxiv для discovery:
1. Чтобы отфильтровать 3/4 публикаций, достаточно названия, абстракта и авторов.
2. Введение и результаты. Введение — это расширенный абстракт, в котором ближе к концу тезисно расписаны достижения статьи.
3. Иногда что-то неладное получается отловить только на секциях моделирования, экспериментов, ablation study.
4. Есть еще такие критерии, как воспроизводимость и публикация на конференции, но на них я не смотрю.

Моя эволюция структурирования информации про статьи:
1. Никаких записей, всё в голове.
2. Рукописные заметки к статьям на бумаге, затем на планшете.
3. Выделение текста в пдфке, короткие заметки.
4. Выделение цельных предложений / абзацов вместо фраз, терминов, коротких кусочков предложений.
5. Использование Zotero для хранения и структурирования пдфок со статьями. Создание иерархий, использование тэгов. Потом стал вписывать аффилиацию авторов в отдельное поле.

Массовые увольнения в Spotify.

В Spotify прошла уже третья, самая большая волна увольнений. Уволили 1500 человек, 17% сотрудников.

Как можно было понять по прошлым постам, мне Spotify импонирует. У них крутая рабочая этика с акцентом на правильный work-life balancе. Например, есть wellness week — дополнительная оплачиваемая неделя отпуска для всех сотрудников. Ресерч тоже крутой, ребята публикуют хорошие статьи по РЛ в рекомендациях. Ну и сам продукт очень приятный, я уже много лет абсолютно каждую неделю прослушиваю свои рекомендации в discovery weekly и release radar.

Судя по всему, не выгорела движуха с подкастами, в которую они довольно сильно вкладывались с 2019-го года (СМИ пишут про 1 млрд долларов). Выход на IPO в 2018, думаю, тоже не помог с текущей ситуацией. Много ресерча в последние годы было сфокусировано именно на подкастах, что тоже обидно.

Какие-то подробности можно почитать на Линкедине.

#arxiv_weekly (04.12.23 — 08.12.23)

1. Инженеры из Нетфликса добавили метаданные фильмов (i.e. граф знаний) в свою графовую сетку, построенную на пользовательском фидбеке. Репортят, что получилось сильно улучшиться на задаче определения похожих фильмов, особенно для тяжелого хвоста и холодных айтемов. См. Synergistic Signals: Exploiting Co-Engagement and Semantic Links via Graph Neural Networks.

2. С увеличением размера датасета нейросети начинают выигрывать у градиентного бустинга на задаче ранжирования — именно такой тезис проверили ShareChat на своих данных в статье On Gradient Boosted Decision Trees and Neural Rankers: A Case-Study on Short-Video Recommendations at ShareChat. При этом нейросетка довольно простая — MMoE, а в качестве бустинга используют катбуст. Получилось, что (1) нейросети гораздо лучше скейлятся по данным (т.е. хорошо растут по качеству с ростом размера датасета), и (2) в градиентный бустинг не влезают датасеты больше определенного размера.

3. Можно ли как-то улучшить двубашенную модель для кандгена на своем домене, не дообучая саму нейросеть? Например, хотим адаптировать обученный на веб-поиске двубашенный энкодер для еком поиска. В Amazon предложили метод, использующий индекс из запросов и релевантные для домена пары (запрос, документ). Репортят большие приросты полноты ретривала на задаче товарного поиска в статье PEFA: Parameter-Free Adapters for Large-scale Embedding-based Retrieval Models.

4. Вышло сразу две статьи про кросс-доменный сценарий, в котором мы за счет данных из одного домена (source) пытаемся улучшить качество модели на другом домене (target). Архитектуры очень мудрёные. Статьи от Ant Group / Alibaba Group: Enhancing Cross-domain Click-Through Rate Prediction via Explicit Feature Augmentation и PEACE: Prototype lEarning Augmented transferable framework for Cross-domain rEcommendation.

5. Tencent PCG в статье Event-driven Real-time Retrieval in Web Search предлагают аугментировать веб-поисковый запрос с помощью релевантного новостного заголовка, чтобы лучше находить релевантные документы.

6. Есть такая задачка online news story discovery, в которой нужно кластеризовать входящий новостной поток на разные "сюжеты". Чтобы побороть отсутствие разметки и постоянную эволюцию новостей, можно использовать unsupervised подходы — например, кодировать новости в эмбеддинги с помощью предобученного текстового энкодера и применять онлайн кластеризацию. Авторы из UIUC предлагают self-supervised метод, с помощью которого можно все-таки как-то подтюнить энкодер статьи под задачу. Статья SCStory: Self-supervised and Continual Online Story Discovery.

Про LLM:

1. В Instacart выпустили объемный opinion paper про использование LLM для еком поиска. Предлагают model-based подход: впихивать знание о товарах в саму LLM и использовать её в качестве полноценной базы данных. Всю информацию превращаем в тексты, тюним на них LLM'ку. Если появился новый товар, формулируем информацию про него в предложения вида "товар X — самокат зелёного цвета с характеристиками A, B, C", где X — айдишник товара. Дообучаем модель на эти предложения, и ожидаем, что по пользовательскому запросу сможем вытащить нужный айдишник товара. Статья Rethinking E-Commerce Search.

2. Подавать на вход LLM текстовые представления товаров из истории пользователя — плохая идея. А что надо делать? Вышло сразу две статьи, в которых историю пользователя (1) сначала прогоняют через предобученный sequential recommender (e.g. SASRec), затем (2) применяют обучаемый адаптер-слой, переводящий события в пространство входов для LLM, после чего (3) применяется уже сама LLM, для генерации рекомендаций. Статьи E4SRec: An Elegant Effective Efficient Extensible Solution of Large Language Models for Sequential Recommendation от Tsinghua Univerisity и LLaRA: Aligning Large Language Models with Sequential Recommenders от University of Science and Technology of China.