1934
Рекомендательные системы глазами RecSys R&D лида Яндекса Недельные дайджесты arxiv/cs.IR, обзоры статей, образовательные посты и не только Author: @kkhrylchenko
Computer Architecture and Memory Systems.
Прямо сейчас проходит пятидневная летняя школа EFCL Summer School в ETH Zurich, в которой один из треков — про память и компьютеры, в том числе в контексте машинного обучения.
Ведет его научная группа Onur Mutlu, у которой есть очень крутые курсы: вводный Digitial Design and Computer Architecture и продвинутый Computer Architecture. Всё выкладывается на ютуб, включая вышеназванный трек из EFCL. Можно даже на трансляцию подключиться и что-нибудь поспрашивать.
Был довольно забавный keynote от Yale Patt (который, собственно, самого Onur Mutlu и учил когда-то), в котором в том числе промелькнул тезис, что учиться надо в стиле “bottom-up”, изучая системы с самых основ; e.g. сначала изучать как устроен компьютер, и уже потом идти учиться программировать. Был пример с гугловским TPU, где один из авторов когда-то слушал курсы про железо, и поэтому заюзал систолические массивы. Еще Yale жалуется, что сейчас машин лернеры чаще всего ничего про этот самый “bottom” не знают :)
Были и тезисы про ресерч: например, что во многих областях ресерч — это про более глубокое понимание того, что уже есть (или того, что было раньше); а у нас, в более инженерных “науках”, ценится исключительно выдумывание чего-то нового. И что пока это не изменится, будем страдать (см. проблемы в академии, со статьями и конференциями). Что инновации всегда следуют за более глубоким пониманием, и в текущих реалиях многие ресерчеры пытаются этот этап перешагнуть, делая статьи-пустышки.
Когда-то давно, в порывах восполнить пробелы в образовании после ВМК, я искал на просторах интернета хорошие лекции про комп. архитектуру; канал Onur Mutlu — лучшее, что нашел. Лекции всяких MIT выглядят гораздо хуже. Справедливости ради, целиком контент я до сих пор не посмотрел (материала там много), но периодически возвращаюсь и что-то досматриваю :)
Про публичные выступления.
С раннего возраста периодически где-то выступаю: музыкальный хор, интеллектуальные дебаты, и вот, последние лет 6, на ML митапах. Еще люблю спортивную мафию, которая, на мой взгляд, развивает те же навыки (но об этом как-нибудь в другой раз).
Хотел тезисно поделиться парой советов про выступления:
1. Презентация — ваш лучший друг. Хорошая презентация сильно облегчает задачу рассказчику. А хорошо сделанная картинка — лучше тысячи слов. На работе тоже этим активно пользуюсь.
2. У меня плохая дикция: я часто оговариваюсь, не выговариваю какие-то слова, поправляю себя; главное — делать это уверенно. Если вы уверенно говорите, пускай и с оговорками — это смотрится вполне нормально.
3. Прогоны. Полезно сделать парочку прогонов до выступления. Я это делаю еще как минимум чтобы понять, укладываюсь ли в time limit; а еще, после первого прогона обычно становится понятно что надо подправить в презентации, чтобы рассказывать было легче.
А еще пожалуюсь:
1. Не умею делать короткие презентации: пихаю слишком много контента и вынуждаю себя тараторить. Структура доклада всегда получается такая, что еле укладываюсь в time limit. Интересно было бы когда-нибудь попробовать сделать более "медленный" доклад с более медленной манерой речи.
2. Не поборол слова паразиты: "вот", "то есть", "эээ". Без них сложно тараторить :)
3. Срываю голос на каждом выступлении: почему-то начинаю на выступлениях очень громко разговаривать, довольно быстро сажаю голос, и в середине выступления начинаю говорить каким-то странным тембром (и во время нетворкингов тоже)
4. Не смотрю на аудиторию: редко когда получается качественно посмотреть на слушателей, чаще утыкаюсь в презентацию. По канонам ораторских книжек нужно все-таки на людей смотреть :)
Еще заметил интересный эффект: у меня было рабочее полугодие, во время которого очень много разговаривал (докладывал статьи, etc); затем было полугодие, где активность поутихла. Когда я об этом явно задумался, начал гораздо хуже выступать. Fear is a mind killer :)
Data Fest 2024.
Завтра буду рассказывать про RecSys тренды в индустрии на Датафесте, в 15:30. Приходите пообщаться!
А теперь затизерю тренды, которые выбрал для доклада :)
P.S: если ваш любимый тренд в список не попал — не обижайтесь; у меня всего 20-30 минут для рассказа, все не вместить :)
UPD: ссылка на трансляцию
Face reveal: https://youtu.be/iBhGAKFGKdQ?si=2omgFLtuDxv0UjbF
Рассказываю про нейросетевое ранжирование для рекомендаций.
После доклада за кулисами обсудили РЛ, графовые сетки, bias'ы, трансформеры для персонализации, академию, индустрию, роблокс, рекомендательные ленты, next item prediction, movielens, как делать надо и как не надо, симуляции пользователей, языковые модели, объяснения рекомендаций, манипуляции вместо рекомендаций, trust bias, фидбек луп.
P.S: Подписчики на митапе зашеймили за отсутствие постов на канале. Заверил, что это временно :)
Обучаемые векторы для рекомендательных систем.
Есть конечное множество пользователей и айтемов. Хотим рекомендовать пользователям айтемы.
Пусть для каждого объекта задано векторное представление, при этом предпочтения пользователя u определяются через скалярное произведение <u, i> для любого айтема i. Тогда говорят, что векторы пользователей и айтемов находятся в одном семантическом пространстве, а такую модель называют двухбашенной. Эти векторы еще часто называют эмбеддингами, потому что объекты буквально вкладываются (англ. to embed) в векторное пространство.
Почти в любой нейросети возникают векторы объектов. Иногда это целевая задача - получить эмбеддинги, обладающие определенными полезными свойствами (привет, representation learning). В рекомендашках это тоже актуально; и (1) для кандидатогенерации, которую часто делают на основе эмбеддингов (embedding-based retrieval), и (2) для ранжирования, серьезный вклад в которое вносят нейросетевые признаки.
В случае обучаемых эмбеддингов векторы объектов объявляются частью параметров модели; их значения подбираются в процессе оптимизации. Рассмотрим двухбашенную модель с обучаемыми векторами: она задается функционалом потерь (+ данными для обучения), процедурой оптимизации и, непосредственно, набором обучаемых векторов.
Утверждается, что у такой модели максимальная емкость. Что вообще такое емкость модели (англ. model capacity)? Это способность выражать взаимосвязи, аппроксимировать функции. В терминах двухбашенной модели об этом думать проще: представим, что у нас есть некоторая оптимальная структура семантического пространства (если нас волнует только семантическая близость объектов, то с точностью до поворотов, сдвигов и, возможно, масштабов), которую мы хотим получить.
В теории, двухбашенная модель с обучаемыми векторами может выучить любую структуру семантического пространства. Пусть у нас есть какая-то другая модель (e.g. мешок слов, трансформер, графовые нейросети), тогда можно инициализировать обучаемые эмбеддинги векторами из этой модели. В обратную сторону это не работает - имея набор векторов, не всегда можно так настроить "content-based" модель, чтобы она выдавала нужные векторы (привет, дистилляция).
Почему бы тогда не использовать всегда только обучаемые векторы? Несколько причин:
1. Недостаточно данных. Bias-variance tradeoff гласит, что более сложные модели сильнее переобучаются, hence для них нужно больше данных. Double descent в рекомендашках я пока не наблюдал, поэтому будем считать, что это правда :)
2. Тяжелые хвосты (long tail distributions). Если у вас большая часть объектов мало встречается в данных (т.е. хвост тяжелый), то про них сложновато делать выводы без дополнительной информации (e.g. контента), и тем более сложно выучить хорошие векторные представления.
3. Постоянно появляются новые объекты, поэтому нужна индуктивность - умение работать на объектах, не встречавшихся в обучении. У обучаемых векторов она отсутствует, они трансдуктивны.
4. Нестационарность распределений. Интересы пользователей меняются, содержимое айтемов обновляется, тренды (популярности объектов) эволюционируют. Обучаемые векторы это не учитывают.
Последние два пункта частично лечатся инкрементальным дообучением (получили новые данные - дообучились). Но:
* проблема курицы и яйца - чтобы дообучиться, надо накопить фидбек для новых объектов. Чтобы его накопить, нужно их рекомендовать. Если модель на них не дообучалась, то и рекомендовать их не будет.
* у инкрементального дообучения будет определенная задержка, побороть которую можно только невероятными инфраструктурными усилиями. Пока дообучение не произойдет, качество работы на новых и изменившихся объектах будет плохое.
Что же тогда делать? Вносить индуктивное смещение (англ. inductive bias): анализировать содержимое айтемов, делать нейросетевые энкодеры, добавлять регуляризацию, представлять пользователя через историю взаимодействий, etc. Об индуктивном смещении и как оно помогает бороться со всеми этими проблемами поговорим в другой раз :)
Иногда в контексте канала появляются идеи, которые выходят за рамки написания постов. Я, честно говоря, не ожидал, что канал когда-нибудь дойдет до текущих масштабов (преодолели сегодня тысячу участников), и мне казалось, что с ростом аудитории будет только сложнее выходить за рамки уже существующего формата. Но в реальности происходит другое - я наоборот смелею, и желание экспериментировать растет.
Решил заложить под определенное количество подписчиков определенный контент. Не с целью чтобы ускорить рост (не думаю, что это влияет), а чтобы были дедлайны по реализации. В моменте всегда находится что-то, из-за чего эти идеи откладываются. С этим поможет только коммитмент :)
1. Видеозапись с рассказом про ML в Пинтересте, когда наберется 1250 подписчиков. Про ранжирование, графовые сетки, трансформеры для персонализации, etc. Посты в телеграме по размеру ограничены, и я, на самом деле, большую часть постов подбиваю под эти ограничения. Приходится дробить повествование и создавать cliffhanger'ы, но зато меньше времени нужно на написание отдельных постов. Вот в формате часового видео можно довольно много рассказать и никаких ограничений нет. И текст вылизывать не нужно =) На работе я постоянно где-то что-то рассказываю, и не раз посещала мысль, что было бы круто что-то записать и для вас.
2. Пародия на аватарку канала с моей физиономией на 1500 подписчиков. Пункт шуточный, чтобы основательно подготовиться к следующему :)
3. Подкаст про рекомендательные системы на 1750 подписчиков. В составе из четырех яндексоидов, вместе с моим бывшим тимлидом Севой @yalinter, Сашей @knowledge_accumulator и Мишей @WazowskiRecommends. Обсудим тренды рексистем (трансформеры, РЛ, языковые модели, графы, etc), соберем ваши вопросы, и на самые интересные постараемся ответить.
4. Ридинг группа (почти виртуальный митап) на 2000 подписчиков (надеюсь, не все две тысячи придут). Обсудим выбранную голосованием статью, или даже несколько. Может, поговорим про то, как их вообще искать и читать. Я про это уже писал, но, кажется, еще осталось что обсудить. В этом поучаствует Сережа @pragmaticml, который, собственно, недавно пришел ко мне с предложением сделать что-нибудь про чтение статей.
Для меня все эти пункты звучат довольно сложно, но если хотя бы какой-нибудь реализуется, и реализуется успешно - буду доволен. Спасибо за то, что читаете канал, ставите реакции и пишете комментарии!
Необходимое условие для успеха нейросетевого ранжирования — это масштабирование по данным. У нейросетевых рекомендательных моделей качество сильно растет при увеличении обучающего датасета, у градиентного бустинга — нет.
Чаще всего в ранжирующий катбуст запихивают ~50кк сэмплов. В сервисах побольше — это неделя залогированных данных с андерсэмплингом, в сервисах поменьше — две недели / месяц. Для нейросетей с почти любой архитектурой это количество данных далеко от оптимального. Можно использовать вплоть до миллиардов сэмплов, получая приличные приросты метрик качества (как мы делаем с трансформерами над историей пользователя).
У нейросетевого ранжирования емкость модели (возможность выучивать какие-то зависимости) гораздо больше. Почему так получается — обсудим в других постах. Но чтобы эту емкость реализовать, нужны большие датасеты.
Есть такая область, как табличный DL. Там нет e2e анализа последовательностей, upstream моделей, и, самое главное, нет достаточно больших датасетов. Поэтому примерно все существующие статьи (e.g. (1) Are Neural Rankers still Outperformed by Gradient Boosted Decision Trees?, (2) When Do Neural Nets Outperform Boosted Trees on Tabular Data?) репортят доминацию GBDT.
Немного цитат из индустрии:
Applying Deep Learning To Airbnb Search
We were able to deprecate all that complexity by simply scaling the training data 10x and moving to a DNN with 2 hidden layers.
As the dataset size increases, the marginal improvement in the neural ranker’s performance is higher than that of GBDTs.
Deep learning have been dominating recommendation models as the gigantic amount of user data is a natural fit for massively data-driven neural models.
#arxiv_weekly (08.01.24 — 12.01.24)
1. Один из способов борьбы с холодным стартом в рекомендашках — это meta-learning. В статье G-Meta: Distributed Meta Learning in GPU Clusters for Large-Scale Recommender Systems инженеры из Alibaba рассказывают как адаптировали обучение DLRM (нейросетевых рексистем) под мета-лернинг сетап. Говорят, кстати, что с 2022-го года мета-лернинг в проде в поиске и рекомендациях Alipay, и принес +6.48% CVR / +1.06% CTR для рекламы на главной странице.
2. Актуальность сжатия больших матриц эмбеддингов в рекомендашках мы уже обсуждали в дайджесте про JPQ (joint product quantization). Инженеры из Meta адаптировали под сценарий частичного прунинга метод AdaEmbed, который глядя на градиент и частоту лукапов прунит эмбеддинги. Бьем эмбеддинг на чанки, и в рамках каждого чанка используем стратегию из AdaEmbed. При использовании эмбеддинга в обучении/применении паддим (заполняем) нулями запруненные чанки. Статья Fine-Grained Embedding Dimension Optimization During Training for Recommender Systems.
3. В Ant Group (та же Алибаба) предлагают обучать кластеризацию интентов (читай пользовательских намерений) end-to-end, совместно с обучением самих пользовательских эмбеддингов. Прошлые алгоритмы (e.g. ICLRec) делали это двухстайдийно или итеративно, то есть эмбеддинги пользователей и кластеры обучались отдельно. Здесь же предлагается сделать эмбеддинги центроидов обучаемыми параметрами и добавить парочку лоссов к next item prediction. Из интересного — в одном из лоссов эмбеддинг пользователя сближается сразу cо всеми центроидами, таким образом авторы борятся с проблемой confirmation bias. Статья End-to-end Learnable Clustering for Intent Learning in Recommendation.
4. В Deezer выпустили шортпейпер по мотивам своей презентации с ECIR'24 про борьбу с холодным стартом в рекомендациях новых музыкальных релизов: проблемы возникают из-за того, что у них основные модели строятся на коллаборативном сигнале. Рассказывают про использование бандитов и дистилляцию эмбеддингов коллаборативной модели в модель, использующую метаданные. Статья Let's Get It Started: Fostering the Discoverability of New Releases on Deezer.
5. В Sharechat опубликовали сразу две статьи. В Learning-to-Rank with Nested Feedback парадигма learning to rank адаптируется под сценарий “вложенных списков”, в котором взаимодействие с айтемом из выдачи приводит к появлению новой карусели рекомендаций. А в статье Variance Reduction in Ratio Metrics for Efficient Online Experiments предлагается использовать градиентный бустинг для снижения дисперсии в аб-тестах. Я по АБ-тестам не эксперт, возможно насколько это разумно нам подскажет @cryptovalerii.
6. Вышел обзор про кросс-доменные рекомендации от китайского Shenzhen University: A Survey on Cross-Domain Sequential Recommendation.
#arxiv_weekly (01.01.24 - 05.01.24)
1. (Multi-view) contrastive learning — устоявшаяся техника в рекомендашках. Аугментируем пользователя (e.g. сэмплируем историю, аугментируем граф данных, или берем представление из другого момента времени), и затем сближаем его представления, отдаляя от чужих. В Visa Research заметили dimension collapse: выученные векторы неэффективно используют пространство, кучкуясь в небольшом подпространстве. Чтобы это полечить, предлагается специальный лосс. Сравниваются с DirectAU. Статья Towards Mitigating Dimensional Collapse of Representations in Collaborative Filtering.
2. Так как в рексистемах очень большой трафик и строгие требования по времени ответа, мы не можем на все запросы использовать самые сложные модели и набирать для всех десятки тысяч кандидатов из кандгена. Иногда еще и трафик сильно растет (e.g. в праздники), приходится "деградировать", понижая качество всей системы.
В Meituan выделили три подзадачи аллокации ресурсов:
(1) elastic channel — для каждого запроса динамически выбираем какие каналы кандгена использовать и в каком объеме,
(2) elastic queue — динамически обрезаем множество кандидатов перед ранжированием,
и (3) elastic model — динамически выбираем ранжирующую модель, т.е. на разные запросы будет отрабатывать разное ранжирование.
Предлагают использовать RL (DQN) для всех трех задач. Статья RL-MPCA: A Reinforcement Learning Based Multi-Phase Computation Allocation Approach for Recommender Systems.
3. В FARFETCH рассказали как рекомендуют размер одежды покупателям, статья Tailor: Size Recommendations for High-End Fashion Marketplaces.
4. В Tencent пробуют взять разные подходы, использующие LLM'ки для рекомендаций (UniSRec, RecFormer, UniM2Rec), и сдистиллировать их в обычный ортодоксальный SASRec. Статья Distillation is All You Need for Practically Using Different Pre-trained Recommendation Models.
5. Вышло два обзора, про графовые нейросети над табличными данными и про атаки на рексистемы.
Рекомендации от меня, на случай если не знаете, чем занять себя в новогоднюю ночь:
1. Начать с этого короткого ШКЯ видео.
2. Посмотреть видео про самые дикие рождественские традиции в Европе и Америке.
3. Посмотреть рождественское аниме 2003-го года Tokyo Godfathers.
P.S: для рекомендательных систем, новогодние праздники - это всегда тяжелый период. Дикий distribution shift :)
Learning RecSys on Graphs.
Если собрать все данные, которые порождает какой-нибудь продукт (e.g. Яндекс Маркет), получится граф. Строить рекомендации для пользователей с помощью этого графа — это ключевая задача рекомендательной системы.
Вершинами в графе являются всевозможные сущности и объекты — пользователи, товары, поисковые запросы, etc.
Ребра — это взаимодействия между сущностями: e.g. взаимодействия пользователей с товарами, клики на товары по запросу, etc. Метаданные ребер содержат контекст взаимодействия, e.g. время и тип взаимодействия, девайс пользователя, поверхность рекомендации.
Граф — гетерогенный (разнородный). Вершины и ребра в нем имеют разные типы, содержат разные наборы информации.
Это гиперграф. В нем есть гиперребра — ребра, объединяющие произвольное количество вершин. Например, купленные вместе товары (i.e. basket).
Граф — динамический. Он развивается со временем; поток событий в системе порождает новые ребра в графе.
Еще есть граф знаний. Все метаданные вершин можно представить в виде графа с “семантическими вершинами”, e.g. категориями и характеристиками товаров. Сами семантические ноды могут быть связаны между собой, e.g. таксономия категорий товаров.
А еще можно построить граф сразу для всей экосистемы. Добавить в тот же граф для Маркета данные из других сервисов, т.н. кросс-доменный граф: пользователей, айтемы, их метаданные и всевозможные типы взаимодействий.
Задача графовых моделей — извлечь максимум пользы из этих данных. Любые модели рекомендаций так или иначе оперируют этим графом, но, как правило, игнорируют большую его часть. Например, sequential модели (e.g. SASRec) часто рассматривают только пользователей и айтемы, оставляют только один тип ребра, при этом выкидывают все метаданные айтемов и ребер (кроме их порядка по времени), убирают граф знаний и кросс-доменную информацию.
Обучить ультимативную графовую модель на всех данных, получив универсальные эмбеддинги для всех сущностей в системе — одна из задач, которой мы с командой занимаемся в Яндексе.
Персонализация и popularity bias
Распространённая проблема в рекомендательных системах — недостаток персонализации, когда показываются в основном популярные и не очень релевантные пользователю документы.
В сообществе есть известная проблема popularity bias. Но что это в точности такое? Bias — это системное смещение. А где здесь смещение? И есть ли оно вообще?
Если общими словами, то под popularity bias понимается ситуация "the rich get richer", когда популярные документы рекомендуются системой непропорционально чаще непопулярных. Причины у этого могут быть разные, и в литературе освещаются разные аспекты этого явления. Важно разделять эти причины, потому что это сильно помогает дебажить систему.
В работе над рекомендациями очень полезно выделять два важных шага:
1) Обучение модели предсказания отклика пользователя на рекомендованный объект. В простом случае это просто вероятность клика, в более общем — E(engagement | item, user, context).
2) Собственно, построение рекомендаций с помощью этой модели. Простое ранжирование по предсказаниям — не самый оптимальный, хотя и хороший бейзлайн.
Во многих случаях, говоря о popularity bias, подразумевают неоптимальность шага 2. То есть, даже если более популярный объект вызовет у пользователя с большей вероятностью позитивный отклик, может быть лучше порекомендовать ему менее популярный объект. Причин тут тоже может быть несколько — как пользователецентричные (долгосрочно клик на популярный объект менее ценен для этого пользователя, чем клик на непопулярный), так и с точки зрения всей экосистемы (этому пользователю станет чуть хуже, но зато мы выровняем распределение потребления по всей базе объектов). Это, в целом, разумные мысли, но надо честно себе признаться: мы жертвуем engagement-ом в момент конкретного запроса ради светлого будущего.
Самый простой способ имплементировать эту идею (и, по-моему, другие способы не очень-то далеко ушли от этого) — пенализировать за популярность объекта. Это очень тесно связано с PMI, который мы обсуждали в посте про двух-башенные сети.
В других же случаях popularity bias относят к первому пункту: дисбаланс объектов мешает нам хорошо обучить модель E(engagement | item, user, context). В частности, она может плохо учитывать пользовательские фичи и, по сути, просто выучить E(engagement | item), тесно связанную с популярностью (кстати, в этом посте я тоже иногда под популярностью имею в виду не P(item), а E(engagement | item)). Вот это уже очень ощутимая проблема. Хотя я не очень понимаю, почему её называют баисом.
Тут советы зависят от конкретной модели. Вот несколько:
- Убедитесь, что у модели есть информативные персональные фичи.
- Введите отдельный член внутри модели, отвечающий за популярность, чтобы оставшаяся часть модели могла сфокусироваться на специфичности.
- Если модель выучивает эмбеддинги объектов, проверьте, хорошо ли они выучились. Например, посмотрев на самые похожие объекты на данный.
- Если используется negative sampling, то учитывайте в нём популярность. Только не забудьте при применении обратно умножить на неё, чтобы получить E(engagement | ...), как обсуждали в том же посте.
- Ну и просто проверьте, что модель нормально выучилась. Да, это не так-то просто. Это часть довольно сложной, но критически важной темы ML Debugging.
Кстати про "непропорционально чаще". Никто ведь не обещал, что при простом ранжировании вероятность быть порекомендованным будет пропорциональна популярности или CTR документа. Это совсем не так. Может быть, поэтому это и называют bias-ом?
На моей же практике было очень много случаев, когда команды
а) не задумываются, что именно они называют popularity bias-ом и в чём его причины,
б) имеют проблемы с недостатком персонализации просто из-за плохо обученной модели E(engagement | ...).
Очень важно понимать — это мир так устроен, что у популярных, но менее релевантных объектов действительно в среднем лучше отклики, или просто мы модель плохо обучили.
Намного чаще popularity bias — это просто популярный миф, скрывающий баги системы.
Не стоит недооценивать важность хорошей engagement-модели.
#arxiv_weekly (18.12.23 — 22.12.23)
1. Инженеры из SnapChat обучили универсальные векторные представления для пользователей. Утверждают, что на их домене (IM - instant messaging) никто такого не делал. Обучают трансформер над историей пользователя, на задачи masked behavior modeling и user contrastive learning. Вторую задачу вижу впервые — сближают представления пользователя, построенные для разных моментов времени. Используют ALiBi для позиционной информации. Статья Designing and Evaluating General-Purpose User Representations Based on Behavioral Logs from a Measurement Process Perspective: A Case Study with Snapchat.
2. Для рекомендации коротких видеороликов сложно придумать хороший таргет: обучаешься на [просмотр видео > N секунд] — штрафуешь короткие видеоролики, обучаешься на [посмотрели видео полностью] — штрафуешь длинные. Кроме watch time, хочется максимизировать retention и positive explicit feedback (e.g. лайки). В Kuaishou решили автоматизировать процесс создания идеального таргета с помощью мета-лернинга / двухуровневой оптимизации: одновременно учат и ранжирующую нейросеть, и "модель-асессора". Ранжирующая нейросеть учится предсказывать метки из модели-асессора, а модель-асессор учится составлять такие метки, чтобы выдача ранжирующей нейросети была разнообразная (прокси к ретеншну), её дольше смотрели (watch time) и больше лайкали (explicit positive feedback). Статья LabelCraft: Empowering Short Video Recommendations with Automated Label Crafting.
3. Визуализацию рекламного баннера можно персонализировать под пользователя, показывая "креативы", максимизирующие клики/конверсии. Тем не менее, задача выбора креатива нетривиальная, т.к. креативов гораздо больше чем баннеров (10+ креативов на один баннер). Пусть кандидатогенератор отобрал М=1000 баннеров. Отбирать креативы перед ранжированием — долго, а после ранжирования — неоптимально с т.з. качества, т.к. тогда ранжирование не учитывает фичи креатива.
В JD.com в статье Parallel Ranking of Ads and Creatives in Real-Time Advertising Systems предложили делать ранжирование креативов и баннеров в параллель, при этом также придумали для этого совместную процедуру обучения; если учить модели (для креативов и баннеров) независимо — будет работать хуже.
4. Обучение эмбеддингов на графе знаний (Knowledge Graph Embedding Model) — популярная техника для получения эмбеддингов сущностей. Cоставляем граф знаний (вершины — объекты/концепты, ребра — разные типы связей), затем применяем модель обучения эмбеддингов. Например, TransE обучает для сущностей такие эмбеддинги, что vec(objA) + vec(edgeT ) ≈ vec(objB) если в графе существует ребро edgeT из objA в objB. Эту модель, кстати, использует Твиттер для своей рексистемы (см. TwHIN). Ученые из французского Universite de Lorrain задались следующим вопросом: действительно ли эмбеддинги из таких KGEM моделей, обученных на link prediction, можно использовать для определения "семантической" похожести объектов? Ответ можно узнать в статье Do Similar Entities have Similar Embeddings.
5. Ученые из швейцарского EPFL используют РЛ + граф знаний для объяснения рекомендаций. Обучаем эмбеддинги на графе (KGEM), затем учим РЛ-агента блуждать по графу знаний, используя эмбеддинги вершин в качестве состояний. Награда поощряет определенные траектории блуждания по графу. Затем для объяснения рекомендации используется путь в графе знаний, который выбрал агент. Статья Finding Paths for Explainable MOOC Recommendation: A Learner Perspective.
6. Часто для обучения рекомендательной системы не хватает данных, либо же обученная модель обладает некоторыми плохими свойствами из-за большой разреженности информации про взаимодействия (e.g. feedback loop), про айтемы и юзеров (e.g. тяжелые хвосты). Вышел обзор от китайского Jinan University, в котором рассматриваются техники борьбы с data scarcity, включая аугментации, self-supervised learning, transfer learning, broad learning (слышу этот термин впервые, по сути предлагается докинуть побольше фичей) и графы знаний. Статья Data Scarcity in Recommendation Systems: A Survey.
#arxiv_weekly (11.12.23 — 15.12.23)
1. Матрицы эмбеддингов в рексистемах занимают очень много места из-за больших каталогов. Готовую матрицу можно сжать в десятки-сотни раз с помощью Product Quantization: бьем эмбед на кусочки, кластеризуем, представляем эмбед как список центроидов, используем конкатенацию эмбедов центроидов. Минусы: кластеризация происходит уже после обучения. Можно заранее представить айтемы в виде списка айдишников небольшой кардинальности, "центроидов", и обучить эмбеды центроидов end-to-end на задачу (Joint Product Quantization). В статье про RecJPQ ученые из University of Glasgow (Саша Петров @apetrov) применили JPQ к рекомендашкам, попробовав разные эвристики для кластеризации. Работает хорошо, и даже растит качество (за счет регуляризации тяжелого хвоста айтемов).
2. Yahoo выкатили сразу три статьи про улучшения своей флагманской рекламной CTR / CVR модели Offset:
- Ad fatigue: пользователи устают от повторных показов рекламы. В Gemini Native был лимит на два показа баннера за день и пять показов кампании за неделю для пользователя. При этом флагманская CTR/CVR модель Yahoo Offset не использовала фичи-счетчики по пользователю. В статье счетчики типа "сколько раз пользователю показывали этот баннер" добавили в модель, и увидели +7.3% денег. Из интересного: старшие возрастные группы больше страдают от ad fatigue.
- Иногда пользователи случайно кликают на рекламу. Даже если платформе платят за клики (CPC), такие шумные данные стоит обрабатывать отдельно. Отфильтровать миссклики можно с помощью dwelltime, т.е времени пребывания пользователя на странице баннера. Тем не менее, если присвоить коротким кликам нулевой таргет, модель начнет занижать прогнозы вероятности клика. В Yahoo обучили отдельную модель для предсказания коротких кликов и попробовали использовать её предсказания как таргет для скипов и коротких кликов при обучении флагманской Offset модели. Репортят в статье +1.18% денег.
- У e-commerce мерчантов есть возможность использовать механизм dynamic-product-ads (DPA) на рекламных платформах. Мерчант предоставляет весь свой каталог айтемов, а реклама под него подстраивается, показывая пользователям те товары, которые им больше понравятся. Если пользователь уже посещал сайт мерчанта, то реклама помогает ему вернуться (ретаргетинг). Если не посещал — это полноценное привлечение новой аудитории. В статье Audience Prospecting for Dynamic-Product-Ads in Native Advertising тюнят Offset под эти сценарии.
3. Meituan добавили в обучение CTR модели две вспомогательных задачи: (1) сближают вектор пользователя с кликнутыми айтемами и (2) по истории пользователя предсказывают следующий кликнутый айтем. В статье репортят +1.27% revenue per search и +7.21% RoI.
4. Чтобы извлечь профит из "привелигированных" фичей, недоступных в проде, можно использовать дистилляцию модели, обученной с этими фичами, в модель для прода. В своей статье Alibaba пробуют заменить калиброванный pointwise лосс дистилляции на ранжирующий listwise лосс и добавить явную калибровку.
5. Очередная франкенштейн-статья про cross-domain от WeChat, Tencent: Cross Domain LifeLong Sequential Modeling for Online Click-Through Rate Prediction.
Что еще было на архиве:
* мозговые волны для поисковой релевантности
* РЛ для файрволлов
* кулинарный ретривал
* реверс инжиниринг кода бертами
* текстовая хемоинформатика с LM
* предсказание успешности стартапа
* определение фенотипов болезни с LLM
* культурно и социально-экономически осознанные рексистемы
С момента создания канала прошёл ровно месяц. Всем спасибо за комментарии, реакции и поддержку! Захотелось написать метапост с итогами месяца, резюмировать всё происходящее с моей перспективы.
Когда создавал канал, у меня была цель выкладывать дайджесты. Этим я довольно давно начал заниматься внутри Яндекса, но там это скорее было мини-бонусом к reading group, поэтому про формат дайджеста я не сильно парился. Здесь же дайджесты планировались как основной контент, поэтому нужно было сделать их более интересными, читабельными, давать больше контекста. Итого, имеем следующие пять недельных обзоров arxiv'а: раз, два, три, четыре, пять.
Когда стало понятно, что писать слишком подробные дайджесты смысла нет, т.к. иначе это уже не дайджесты, стали появляться обзоры на статьи, а потом и всё остальное:
1. Обзоры тоже были довольно "сухие": про гейтинг в DCN-V2, мультимодальные эмбеды в eBay, ранжирующий трансформер от дипмайнд, негативный фидбек для кандгена, пользовательские эмбеды по фичам от меты. Так получилось, что длиннопосты с этих обзоров и начались, поэтому я пока не успел проверить получится ли сделать их читабельней и содержательней. Думаю, что буду продолжать писать обзоры, но только на самые интересные статьи. Еще был более "свободный" пост про коммуникацию с инопланетянами с помощью техники из статьи с ICLR аж 2018-го года.
2. Случился пост, который по моему субъективному мнению до сих пор является лучшим на канале — про next-item-prediction. Кажется, я уже отточил повествование на эту тему, так как бурчу про нее на нашем внутреннем яндексовом семинаре каждый раз, когда мы натыкаемся на такую схему эвалов. Теперь есть цель превзойти этот пост, но пока не получается :)
3. Люблю изучать что делают другие компании, какие у них технологии. Сейчас это часть рабочих обязанностей, но мне это было очень интересно и года три назад. Помню, как искал статьи от Гугла про устройство ютуба, это казалось каким-то сакральным знанием :) Раньше у меня не было нужного контекста и опыта, чтобы таким заниматься, сейчас, кажется, стало попроще. Пока что я писал только довольно короткие посты: ранжирование в Pinterest, забавный факт про Spotify, но планирую постепенно покрыть длиннопостами интересные рекомендательные технологии всех больших компаний.
4. Написал один технический пост более вводного уровня, про sampled softmax loss. Канал очень технический, много терминологии — хочется такими постами давать больше контекста для чтения других постов. Например, я уверен что будет еще много постов про retrieval. Тот же пост про мою любимую статью на recsys'23 должен быть гораздо понятней после прочтения этого поста. В общем, вводные посты еще будут :)
5. Была и серия "новостных" постов, больше похожих на формат, который я вижу в других AI каналах: появление рекомендаций в tg, доклад Олега на yatalks, конфа по рексистемам от вышки, массовые увольнения в Spotify. Только там это постят скорее в контексте каких-то хайповых тем, e.g. LLM. А здесь хочется покрывать интересные новости, связанные с рекомендательными системами, а то чем мы хуже :)
6. Еще был пост про чтение статей для R&D, который появился благодаря вопросу от @Ppilif. По мотивам вопросов я также задолжал вам посты про графовые сетки, РЛ, языковые модели. Достаточно сложные вопросы в комментариях, на которые мне есть что сказать, буду стараться покрывать отдельными постами, поэтому обязательно задавайте вопросы :)
Еще хочу сказать спасибо ребятам, с каналов / чатов которых большая часть из вас пришла. Это Саша @Fritx, Миша @Wazowski, Антон @toshiksvg и еще чатик reading group Саши Петрова @ods_recommender_systems. У ребят в bio есть ссылки на каналы (UPD: У Миши в bio канала нет, @WazowskiRecommends).
P.S: как будто речь на оскар подготовил =)
What’s on Google's Deepmind? (RecSys статьи за ~последний год).
HyperFormer: Learning Expressive Sparse Feature Representations via Hypergraph Transformer. Улучшают качество на тяжелом хвосте признаков с помощью гиперграфа, в котором вершины — это объекты, а гиперребра — значения признаков. Делают message passing в два этапа (от признаков к объектам и vice versa).
Unified Embedding: Battle-Tested Feature Representations for Web-Scale ML Systems. Используют единую матрицу эмбеддингов для всех признаков, для каждого признака используется несколько лукапов по хэшу (с коллизиями).
Hierarchical Reinforcement Learning for Modeling User Novelty-Seeking Intent in Recommender Systems. С помощью RL оценивают потребность пользователя в новизне и разнообразии. Используют DDPG и DQN (дальше было страшно читать, не стал).
Better Generalization with Semantic IDs: A case study in Ranking for Recommendations. У холодных айтемов плохие обучаемые эмбеды, а контентные эмбеды делать затратно (дорого хранить). Обучают с помощью RQ-VAE "иерархические" семантические айдишники по контенту, которые затем считают для всех (и холодных тоже) айтемов.
Density Weighting for Multi-Interest Personalized Recommendation. Хотят несколько векторов пользователя, но все векторы пользователя забиваются популярными интересами/айтемами. Используют хитрую двухэтапную процедуру обучения. Вводят обучаемые векторы глобальных интересов и делают "параметрический" аттеншн.
Improving Training Stability for Multitask Ranking Models in Recommender Systems. Борятся с нестабильностью обучения больших нейросетевых ранжирующих моделей с помощью своего хитрого клиппинга поверх Adagrad'а.
Fresh Content Needs More Attention: Multi-funnel Fresh Content Recommendation. Строят отдельный стек рекомендаций для нового и long-tail контента (с уклоном в content-based модели), дают ему один слот в выдаче.
Efficient Data Representation Learning in Google-scale Systems. Хвалятся, что unified эмбеддинги и DCN-v2 используют по всему гуглу (>50 моделей).
Online Matching: A Real-time Bandit System for Large-scale Recommendations. Используют контекстуальных линейных бандитов, упрощают их с помощью кластеризации пользователей.
Multitask Ranking System for Immersive Feed and No More Clicks: A Case Study of Short-Form Video Recommendation. Моделируют trailing bias в рекомендациях коротких роликов. Перевзвешивают лоссы c помощью мета лернинга; регуляризуют MoE экспертов, чтобы меньше коррелировали.
Hiformer: Heterogeneous Feature Interactions Learning with Transformers for Recommender Systems. Модифицируют аттеншн для нейросетевого ранжирования, чтобы учитывал гетерогенную природу признаков.
Large Language Models as Data Augmenters for Cold-Start Item Recommendation. С помощью LLM генерят данные для холодных айтемов и тюнят на них рекомендательную модель.
Long-Term Value of Exploration: Measurements, Findings and Algorithms. Исследуют как в A/B замерять эффект от эксплорейшна (делят выборки не только по юзерам, но и по айтемам), используют NeuralLinear бандитов для ранжирования.
Aligning Large Language Models with Recommendation Knowledge. Тюнят LLM на Masked Item Modeling и BPR в текстовом формате.
Cluster Anchor Regularization to Alleviate Popularity Bias in Recommender Systems. Делают иерархическую кластеризацию content-based эмбедов айтемов, добавляют на ее основе регуляризацию для сближания обучаемых векторов head/tail айтемов.
Diversifying by Intent in Recommender Systems. Предсказывают намерения пользователя (intent'ы), используют формулу полной вероятности. Каждый следующий айтем выбирают в предположении, что ранее выбранные интенты не подошли.
LLMs for User Interest Exploration: A Hybrid Approach. С помощью LLM предсказывают верхнеуровневые интересы, далее рекомендательной моделью ищут среди айтемов из этого интереса лучшие.
Много коллабятся с Youtube'ом; фокус на короткие видео (shorts). Киворды: long-tail, матрицы эмбедов, новизна, разнообразие, эксплорейшн, LLM, ранжирование, дебаясинг, RL.
Какая статья вам больше понравилась? Дайте знать в комментариях :)
Data Fest 2024, часть 2.
Видеозапись выступления — https://youtu.be/PvZuTUnZa2Q?t=14345 (пока вроде бы доступна)
Что обсуждали за кулисами:
* двухбашенные модели — плохие кандидатогенераторы
* будущее за LLM'ками?
* является ли человек перемножением матриц?
* кросс-домен рекомендации
* как делать ресерч и как не делать
* рекомендации музыки
* существует ли пространство айтемов вне моделей и Виттгенштейна (Олег в комментариях напомнил)
Спасибо всем, кто подходил со словами что читает канал. Мне это всегда очень приятно =)
Презентацию приложу в комментариях к посту.
Чем занимается наша R&D команда.
С годами задачи меняются: сначала был фокус на развитие одной R&D технологии (трансформерной персонализации), затем на ее распространение по Яндексу, а сейчас мы с командой занимаемся R&D для рекомендаций в целом, не ограничивая себя одной конкретной технологией.
На что декомпозируется работа:
1. Поиск новых технологий — постоянное изучение arxiv'а, конференций, воркшопов, инженерных блогов. Об этом я писал чуть подробней в посте Про чтение статей (для R&D). Потребность в R&D, как правило, драйвится с двух сторон: либо мы сами "приносим" новые технологии для улучшения рекомендаций в продуктах; либо продукты приходят к нам со своими проблемами. Для нас первый сценарий реализуется чаще, поэтому поиск новых технологий — очень важная часть работы.
2. Экспериментальная деятельность, прототипирование — выдвигаем и проверяем различные гипотезы, большая часть из которых выглядит как "если сделаем Х, улучшим базовое качество рекомендаций на Y". Довольно неплохое мерило успешности R&D команды, помимо прямого влияния на бизнес-метрики — это количество выдвинутых / проверенных / успешных гипотез, эдакая "пропускная способность" в гипотезах. При этом, чтобы было много успешных гипотез, нужна хорошая ресерчевская 'интуиция'. Чтобы выработать интуицию, нужна хорошая теоретическая база и опыт (как положительный, так и отрицательный) — про это упоминал в посте "Про ML соревнования".
3. Поддержка и развитие R&D инструментов:
* фреймворк для обучения нейросетей (он же трейн луп) - самая важная компонента, больше всего влияющая на количество проверяемых гипотез. Предела совершенству здесь нет: как лучше сделать конфигурирование обучения, как должен выглядеть конструктор модели, какие нужны коллбеки, что нужно логировать. Хорошая утилизация ресурсов тоже очень важна (не упираться в чтение по сети и в cpu, использовать оптимальные реализации слоев).
* работа с данными — зачастую самые профитные гипотезы связаны именно с данными. Подать что-то новое в модель, изменить представление входных данных, модифицировать целевую задачу, придумать новую процедуру предобучения. При этом нам доступны по-настоящему большие данные, триллионы пользовательских событий. Чтобы не состариться при проверке очередной гипотезы, требующей "варки" нового датасета, нужен удобный, гибкий и быстрый фреймворк. Дата инженеров у нас нет — нам важно уметь самим залезать в обработку данных и что-то быстро в ней менять. Да и инструменты для работы с данными в Яндексе настолько хороши (YQL, YT), что даже ресерчеры вполне способны их освоить :)
* инструменты для внедрений — "быстрые применялки" моделей, регулярные процессы дообучения, сервисы для применения моделей, оффлайн насчеты векторов, индексы для кандидатогенерации, etc. Здесь частично мы справляемся сами, частично нам помогают другие команды. Некоторые инструменты мейнтейнят и развивают выделенные команды. Конечная цель у нас — это всегда real-world impact, поэтому с этим всем мы тоже много сталкиваемся.
* командные процессы — совершенствуем их от полугодия к полугодию. На мой biased взгляд, выстраивание процессов для эффективного R&D гораздо сложнее, чем в обычной разработке. Вопросов много: сколько людей должно заниматься одним проектом, как лучше проводить планирования, сколько проектов должно быть у каждого человека, как логировать эксперименты, как организовать семинары по чтению статей, etc.
4. Внедрения — мы постоянно общаемся с продуктовыми командами, рассказываем про новые технологии и наши планы, договариваемся про совместные внедрения, делаем общие для экосистемы Яндекса инструменты. Зачастую от сервисов узнаем много нового, вырабатываем новые интуиции, а потом еще и "кросс-опыляем" сервисы, рассказывая одному сервису про фишки другого :) Ну и, конечно, очень приятно видеть импакт на продукты, которые использует много людей (Музыка, Кинопоиск, Маркет, Алиса, Поиск, etc)
К чему я это все: у меня есть вакансия; если прочитали и чувствуете, что душа к нам лежит — приходите ко мне в личку @kkhrylchenko :)
P.S: приступаю к созданию видео про Pinterest 🙂
🎉 Делимся предварительной программой ML Party!
Вот первые темы выступлений:
🔘 Кирилл Хрыльченко, руководитель группы исследования перспективных рекомендательных технологий в Яндексе. Расскажет, как и почему градиентный бустинг для ранжирования проигрывает нейросетевым моделям.
🔘 Никита Рыжиков, руководитель службы технологий голосового ввода в Яндексе. Поделится историей о том, как мы переносили Алису с телефона на колонку и какие проблемы решали в процессе.
🔘 Александр Воронцов, руководитель группы машинного обучения рекламной платформы в Яндекс Маркете. Объяснит, как в Маркете запускали автогенерацию рекламных баннеров.
📎 ML Party пройдёт 14 марта в Москве в офлайн- и онлайн-формате. Зарегистрироваться можно здесь.
Подписывайтесь:
💬 @Yandex4ML
📹 YandexforML">@YandexforML
NLP образца 2020-го года.
В далеком 2017-м я начинал познавать дивный нейросетевой мир с области обработки естественного языка. В те времена эмбеддинги слов формировались с помощью предобученных word2vec / glove / fasttext, а в качестве энкодера использовались RNN. Механизм внимания вне NMT почти не использовали (см., например, HAN). Были еще сверточные сети над текстом, как раз кодил такие для соревнования Toxic Comment Classification Challenge.
С этого соревнования, собственно, у меня и остались самые яркие воспоминания про то время. Топ-1 kaggle kernel там был от основателя fastai Jeremy Howard'а. Медальку за соревнование он так и не получил (у меня было серебро).
NLP тогда воспринималось по-другому. Наверно также, как я сейчас воспринимаю рекомендательные системы. Область бурно развивалась, только-только появились трансформеры, было очень интересно вчитываться в статьи. Сам факт, что такие задачи как sentiment analysis, NER, NMT удавалось решать нейросетями — был большим вдохновением.
Успехи в компьютерном зрении мне были не так интересны; на то время могу выделить разве что image captioning и style transfer. Я тогда еще иногда встречался с доуниверситетскими друзьями, и объяснял как работает word2vec и как в машинном обучении мы составляем признаковые пространства для объектов. Это казалось чем-то очень интересным =)
К чему я это все: в те годы у меня не было каких-либо "умных" систем для хранения статей. Как вчерашний студент, я хранил гигантские стопки бумажных заметок. Первая попытка это преодолеть произошла как раз перед выходом в Яндекс, когда я еще самоидентифицировался как NLP'шник и не занимался рексисом. Я сконструировал эдакий граф цитирования важных на мой взгляд NLP/DL статей с временной шкалой.
До сих пор иногда мне пишут коллеги с просьбой скинуть "ту самую NLP пдфку со статьями". Делюсь ею и с вами (см. первый комментарий) :)
У кого лучшие рекомендательные системы в России? Ответ кажется очевидным.
Не будем тянуть. Сегодня наш гость, Кирилл Хрыльченко – лид команды R&D рекомендаций в Яндексе и автор канала @inforetriever, рассказал о том, как работают SOTA персонализации рекомендаций на примере Яндекса.
#arxiv_weekly (15.01.24 — 19.01.24)
1. Один из недостатков ранжирования — при формировании выдачи не учитывается взаимное влияние айтемов; скоры считаются поточечно (pointwise). Чтобы это исправить, добавляется стадия переранжирования, основная проблема которой — вычислительная сложность. Кроме того, сама постановка задачи переранжирования довольна амбициозна — в идеале оно должно заменить большую часть бизнесовой логики постпроцессинга ранжирования, самостоятельно обеспечивая нужные сервису качества выдачи, типа разнообразия, свежести, релевантности. В LinkedIn сделали подход к снаряду и предложили свой жадный последовательный алгоритм с линейной сложностью (еще и с RL сравнились) в статье MultiSlot ReRanker: A Generic Model-based Re-Ranking Framework in Recommendation Systems.
2. Рекомендательные системы многостадийны: кандген, преранжирование, ранжирование, переранжирование, etc. Одна из проблем применения РЛ к рекомендашкам — чаще всего пытаются обучить одного агента, в предположении что он работает с полным корпусом айтемов и формирует выдачу для пользователя. В то время как в реальности агент если и будет применяться, то только в составе одной из стадий. Инженеры из Kuaishou пробуют обучить сразу несколько агентов (MARL — multi-agent RL), по одному на каждую стадию, в статье UNEX-RL: Reinforcing Long-Term Rewards in Multi-Stage Recommender Systems with UNidirectional EXecution.
3. В прошлых дайджестах мы уже обсуждали проблематику формирования таргетов из просмотров видеороликов. Распределение длительности просмотров очень сильно скошено в сторону коротких значений. Стандартный подход в индустрии — побить значения на бакеты (<30 секунд, 30<x<60 секунд, etc; чаще это делают по квантилям) и использовать ординальную регрессию. Инженеры из Kuaishou исследуют как лучше формировать бакеты: придумали довольно сложную систему, в которой есть классификаторы (для бакетов) и "рестораторы", восстанавливающие исходные длительности просмотров. Предлагается подбирать бакеты так, чтобы минимизировать ошибки классификации и "ресторации". Статья CREAD: A Classification-Restoration Framework with Error Adaptive Discretization for Watch Time Prediction in Video Recommender Systems.
4. В Ant Group (Alibaba, Alipay, etc) построили граф данных для рекламных баннеров (из метаданных баннеров и взаимодействий с пользователями и страницами) и обучили на нем вариационный авто-кодировщик. Репортят большие приросты по CTR (особенно для холодного старта) от использования полученных эмбеддингов баннеров в рекламных моделях. Статья GACE: Learning Graph-Based Cross-Page Ads Embedding For Click-Through Rate Prediction.
5. Uber выложили очень простенький pre-print Handling Large-scale Cardinality in building recommendation systems, в котором описывают сетку для, кажется, ранжирования в Uber Eats. Модель очень напоминает 2016-й год :(
6. В Spotify исследуют сценарий, в котором пользователи обмениваются контентом. "Получатель" более склонен провзаимодействовать с контентом, если (1) музыкальный вкус совпадает с "отправителем", (2) они близки и (3) артист, которым поделились, популярен среди круга общения "получателя". Подробности в Link Me Baby One More Time: Social Music Discovery on Spotify.
7. Вышло две статьи про аудио-эмбеддинги от SiriusXM-Pandora: (1) On the Effect of Data-Augmentation on Local Embedding Properties in the Contrastive Learning of Music Audio Representations и (2) Similar but Faster: Manipulation of Tempo in Music Audio Embeddings for Tempo Prediction and Search.
8. Не так давно появился новый сценарий рекомендашек под названием trigger-induced recommendations, в котором рекомендации генерятся в ответ на взаимодействие с айтемом, e.g. при клике на товар появляется плашка с рекомендациями. Утверждается, что это очень важный сценарий для еком платформ типа Алибабы и Амазона. Инженеры из Alibaba предлагают очень мудреную нейросетку в статье Deep Evolutional Instant Interest Network for CTR Prediction in Trigger-Induced Recommendation.
Нейросетевой мир победил (в ранжировании).
В каждой рекомендательной системе есть алгоритм, который определяет финальную выдачу. Иногда он работает сразу над всем каталогом айтемов, т.е. full-scan, но чаще всего ему на вход приходит уже отфильтрованное множество из сотен-тысяч кандидатов.
В составе этого алгоритма могут быть различные бизнес-правила и эвристики. Например, не показывать на соседних позициях в выдаче айтемы из одной категории; или что-то посложнее, типа DPP или MMR. Логика бывает разная: буст разнообразия, новизны, тяжелого хвоста, замешивание разных источников (e.g. органики и рекламы). Сервисы и поверхности (e.g. ленты/фиды, рекомендации похожих айтемов, поиск) довольно сильно разнятся по набору работающих эвристик.
А вот составляющая ранжирования, формирующая для пар (пользователь, айтем) скоры предпочтения, всегда очень похожа:
1. Информация, идущая на вход модели, декомпозируется на пользовательские (user), айтемные (item) и совместные (user-item) признаки. Используется раннее связывание информации про кандидата и пользователя, т.е. в рамках модели моделируется взаимодействие между признаками пользователей и айтемов. Термин не совсем строгий, и приобретает смысл в первую очередь в контексте нейросетей: ему противопоставляются двухбашенные модели, в которых информация про пользователя и айтем анализируется раздельно. Операция скалярного произведения над векторами айтема и пользователя называется поздним связыванием.
2. Для обучения используются в первую очередь объекты, которые прошли через всю воронку рексистемы, т.е. были представлены пользователю. Чаще всего их называют impressions; например, на рексисе есть воркшоп Workshop on Learning and Evaluating Recommendations with Impressions. По сути, все эти объекты уже довольно хороши для пользователя, и зачастую отсутствие положительного фидбека объясняется вспомогательными эффектами, e.g. position bias (пользователь уже удовлетворил свои нужды объектами с более ранних позиций).
3. Модель учится выдавать вероятность положительного события / релевантности (pointwise) или явно ранжировать кандидатов (pairwise, listwise). Либо делает и то, и другое, e.g. Regression Compatible Listwise Objectives for Calibrated Ranking with Binary Relevance от Google.
Можно выделить два основных класса архитектур, использующихся в больших сервисах:
1. Градиентный бустинг (J. Friedman) и его комбинации с линейными моделями (e.g. Practical Lessons from Predicting Clicks on Ads at Facebook). Он прожевывает до десятков миллионов сэмплов (e.g. пар для ранжирования), очень понятным образом работает с признаками (делает по ним сплиты в решающих деревьях), позволяет из коробки интерпретировать важность признаков (e.g. через количество сплитов по признаку), обладает хорошей обобщающей способностью, не сильно страдает от объектов-выбросов, заводится на небольших датасетах и быстро работает на CPU. По сути, это венец эволюции классического ML в контексте ранжирования.
2. Нейросетевое ранжирование. В целом, линейные модели — тоже нейросети. Но обычно подразумевается что-то с более сложной нейросетевой архитектурой. Категориальные признаки превращаются в эмбеддинги, вещественные фичи нормализуются и, зачастую, тоже превращаются в эмбеддинги. Затем следует энное количество различных нейросетевых слоев, явно и неявно моделирующих взаимодействие между признаками. В конце нейросети может быть как предсказание какой-то одной характеристики, так и многоголовая архитектура, предсказывающая одновременно разные типы событий (e.g. клик, лайк, покупку, дизлайк).
Большая часть компаний в своих крупных продуктах использует нейросетевое ранжирование (e.g. YouTube, Pinterest, Airbnb, X (Twitter), Meta, Alibaba). Развитие такого же подхода внутри Яндекса — это одна из задач, которой мы с командой занимаемся (кроме графовых моделей, о которых я уже рассказывал).
В будущих постах обязательно покроем, почему этим стоит заниматься и за счет чего нейросети превосходят градиентный бустинг в ранжировании. А пока, можете почитать посты про нейросетевое ранжирование в Pinterest и YouTube :)
Про ML соревнования.
Свои первые деньги, не связанные со студенческими стипендиями, я заработал ~шесть лет назад, заняв второе место в ML соревновании. На часть из полученных 200 тысяч я собрал мощный комп с 1080ti, чтобы нейроночки обучать и в ведьмака играть :)
Первые два года изучения ML меня очень сильно драйвили соревнования, вплоть до того, что я посвящал им почти все свободное время. Подозреваю, что от улучшения метрик и карабканья по лидерборду у меня выделяется довольно большое количество серотонина, потому что я тогда фигачил без отдыха месяцами, на чистом энтузиазме.
Мой первый контест — Sberbank Data Science Journey 2017; определение релевантности вопроса параграфу текста. Обогнал своего препода с кафедры, заняв 8-е место. Изучал NLP и классический ML буквально по ходу соревнования, и такое изучение теории на практике для меня работало очень хорошо. Еще помню, что там часть вопросов была синтетическая, сгенерированная, и надо было научиться отличать их от настоящих, чтобы сразу ставить им нолики. Я применил марковскую цепь как языковую модель для генерации синтетики и очень радовался, что это сработало :)
Основное, что я вынес с соревнований (и вспомнил во время написания этого поста):
1. Успешность идеи очень сильно зависит от реализации. У контестов, как правило, были чаты, где участники активно общались по ходу соревнования. Я неоднократно наблюдал, как те же идеи, что давали много профита у меня, у других людей не срабатывали. И наоборот. Осталось ощущение, что почти из любой идеи можно выжать профит, если рассмотреть ее под правильным углом.
На работе с этим сложнее: конкретные эксперименты проводит один человек, и если эксперименты закончились неудачно, то всегда остается некоторая неопределенность, почему так получилось. Здесь помогают (1) статьи, по которым мы иногда точно понимаем, что что-то должно работать. (2) правильные формулировки задач, смещение акцента с оффлайн-метрик базового качества на интерпретируемые вопросы и гипотезы, (3) перепроверки друг за другом, а также (4) возвращение к старым направлениям экспериментов.
2. Получил очень много опыта по ведению экспериментов. С одной стороны, оптимизировать какое-то не совсем интерпретируемое чиселко в отрыве от бизнеса — не очень продуктивно. Соревнования сильно разнятся по степени "осмысленности", это зависит от осознанности организаторов. С другой стороны — в отличие от работы, здесь ты соревнуешься с другими людьми, и есть возможность себя относительно них очень хорошо откалибровать. Насколько хорошо ты ставишь эксперименты, а именно: находишь правильные гипотезы, быстро их проверяешь, правильно реализуешь.
На работе все сильно зависит от самокритичности человека, это иногда и плохо, и хорошо. Из неудачной серии экспериментов можно сделать совсем разные выводы. Самый частый вывод — что гипотеза неудачная или задача нерешаемая; он особенно плох, если не получилось при этом сформировать правильную интуицию происходящего. В соревнованиях же, если ты находишься низко по лидерборду, то у этого может быть только одна причина :)
Итого, плюсы соревнований:
* опыт экспериментирования
* возможность откалиброваться относительно других экспериментаторов
* доп. источник заработка
Минусы:
* осмысленность поставленных задач сильно зависит от осознанности организаторов
* прошлый пункт, на самом деле, еще иногда приводит к страшным эффектам по типу ликов в данных и к совсем необобщающимся на бизнес зависимостям, без которых высокую метрику не получишь
* если у вас хорошая работа, то на ней задачи интересней, и необходимость в соревнованиях отпадает. На работе у меня есть возможность самому формулировать задачи, и при этом мне доступны почти неограниченные ресурсы с т.з. данных и железа. После выхода в Яндекс ~3.5 года назад, я перестал участвовать в соревнованиях
На бустерс @boosters после долгого молчания платформы началось новое соревнование по рекомендашкам от hh. Вашего покорного слугу на лидерборде тоже можно найти. Решил тряхнуть стариной :)
#arxiv_weekly (25.12.23 - 29.12.23)
1. Инкрементальное дообучение рексистем уже давно стало мейнстримом. В стандартном сетапе модель дообучается только на новых данных, накопившихся за шаг дообучения (e.g. час/день/неделя). Однако, модель "оверфитится" на новые данные, особенно при сильном distribution drift. Может теряться какой-то более долгосрочный сигнал из более старых данных. Как с этим предлагают бороться инженеры из JD.com можно прочитать в статье An Incremental Update Framework for Online Recommenders with Data-Driven Prior: два доп. лосса и дополнительные фичи в модели.
2. Для рекомендации коротких видеороликов особенно важно учитывать негативный фидбек - пользователи ожидают, что если они скипнули рекомендации, то им быстро начнут показывать что-то другое. В Tencent предлагают доп. лосс для негативов, учитывающий повторные показы и моделирующий "забывание" контента; а также предлагают способ обучения парето-оптимальной модели с помощью подсчета градиентов по лоссам и KKT-based "парето солвера". Статья Pareto-based Multi-Objective Recommender System with Forgetting Curve.
3. Небольшая обзорная статья с метриками ранжирования и кандидатогенерации: A Comprehensive Survey of Evaluation Techniques for Recommendation Systems. Упоминают novelty, diversity, serendipity, catalog coverage. Лично для меня новой метрикой стала "distributional coverage" про энтропию распределения выдачи айтемов для всех пользователей.
4. В ShareChat попробовали проанализировать эволюцию эмбеддингов айтемов по мере обучения для real-time и batch сценариев. В первом случае мы обновляем эмбеддинги сразу после взаимодействия, во втором накапливаем много взаимодействий, и уже потом делаем апдейт эмбеддингов. Говорят, что real-time апдейты гораздо лучше, эмбеды быстрее сходятся к стабильному значению, показывают качество выше, меньше подвержены popularity bias. См Monitoring the Evolution of Behavioural Embeddings in Social Media Recommendation. Подозреваю, что не все выводы из статьи правильные, но само направление исследования интересное.
5. Индексы для кандидатогенерации как правило используют простые метрики близости типа косинуса / l2. Более сложные модели, e.g. нейросетка над конкатенацией векторов запроса и кандидата, не влезают по скорости. В Baidu Research предлагают ускорить процесс поиска по графу (e.g. hnsw) с помощью прунинга кандидатов. Статья GUITAR: Gradient Pruning toward Fast Neural Ranking.
6. Атрибуция конверсий в рекламе - довольно сложная штука; иногда пользователю показываются несколько баннеров из одной кампании, и сложно понять, что именно привело к конверсии. В Criteo предлагают вместо ставок (bid-by-bid optimization) перейти на уровень стратегий (policies) целиком для пользователей. Подробности в Maximizing the Success Probability of Policy Allocations in Online Systems.
7. В Ant Group (Alibaba) уменьшают углеродный след рекомендательной системы, добавив его в оптимизацию: GreenFlow: A Computation Allocation Framework for Building Environmentally Sound Recommendation System.
8. Название статьи Large Language Models are Not Stable Recommender Systems говорит само за себя: переставив в промпте пару слов, можно получить совсем другие рекомендации.
9. В статье Preliminary Study on Incremental Learning for Large Language Model-based Recommender Systems пробуют добавить инкрементальное дообучение для рекомендательных LLM'ок. Сходу не заводится: при инкрементальном дообучении модель забывает долгосрочную информацию, а при обучении с нуля теряется профит на свежих данных.
Это был последний дайджест уходящего 2023-го года. С наступающим!
Дообучение ранжирования в рекомендательных системах.
В посте про ранжирование в Youtube поступил интересный вопрос от @lashinin:
Как думаешь, если систему оставить в покое, обучая ее на все более свежих данных по настроенному процессу, она сойдется к идеальной системе (условно к единичным метрикам ранжирования)?
У Миши вышел хороший пост про popularity bias, призываю почитать 🙂
Часто как синонимы к popularity bias употребляют selection bias, exposure bias, реже position bias. Иногда его рассматривают в контексте проблемы качества рекомендаций на тяжелом хвосте айтемов, что тоже не совсем правильно. Еще очень часто упоминают feedback loop и mathew effect (который у Миши в посте называется rich get richer). Есть еще термин conformity, который носит более социальный характер — когда человек чем-то интересуется, потому что этим интересуется большинство.
Мне про popularity bias нравится думать в RL постановке, через feedback loop'ы. Представим, что алгоритм (рексистема), работающий в проде на момент времени T несовершенен: например, он (1) не знает про какие-то из айтемов, которые могли бы понравиться пользователю и (2) слишком оптимистично относится к определенным популярным айтемам и выдает их чаще, чем нужно. Это наша logging policy (еще иногда говорят behavioral policy). И когда мы на залогированных данных, полученных из такого алгоритма, попытаемся обучить какую-то новую модель (новую policy) в момент времени >T, она все также не будет знать про эти "нишевые" айтемы, которые могли бы понравиться пользователю, так как их не будет в данных для обучения.
И вообще, обучение на данных из другой, изначально неоптимальной политики влечет много проблем. Мат. ожидания любых сущностей, сформированных с помощью залогированных данных, надо корректировать (e.g. с помощью importance sampling, различных дебаясингов и т.д.) чтобы получать несмещенные оценки. Эти коррекции как правило порождают большую дисперсию оценок (e.g. градиентов), что плохо влияет на обучение. Любые недостатки логирующей политики будут плохо влиять на модели, обученные по залогированным данным; особенно если эти недостатки игнорируются.
Путь длиной в тысячу ли до Distinguished Scientist в Google.
В Гугле есть целая научная группа, которая занимается рекомендашками. Из-под их пера вышел DCN-V2, много статей про рексис РЛ, мульти-таск, эмбеды фичей, etc. Они занимались рекомендациями в YouTube, Google Play Store, новостях и рекламе Гугла. И руководит этим всем некий Ed H. Chi. Я его, собственно, приметил как последнего автора почти всех понравившихся мне статей про рексистемы от Гугла. Сейчас он в том числе занимается языковыми моделями (LaMDA/Bard).
Если вы посмотрите на его линкедин, то увидите довольно длинный путь, который он проделал за последние 30 лет. В 26 годков получил PhD от University of Minnesota, затем 12 лет проработал в Palo Alto Research Center (PARC), после чего попал в Гугл и работает там уже почти 13 лет.
На странице есть вся информация про то, как он постепенно “карабкался” по грейдам. В PARC: Research Scientist 6 лет, Senior Research Scientist 5 лет, Area Manager 4 года, Principal Scientist 1 год. Затем в Гугле: 4 года на L6 (Staff), 2.5 года на L7 (Senior Staff), 3.5 года на L8 (Director), и сейчас он уже почти три года как L9 (Senior Director).
Если погуглить, можно также узнать, что он увлекается тхэквондо, фотографией, сноубордом. А вот видео, как он в 2012 году, в 39 лет, в свои первые годы работы в Гугле, полный энергии и энтузиазма посещает WWW’12. Интервьювер его еще и Тедом назвал =)
К чему я это всё: если у вас FOMO, вам кажется, что надо в 20 лет дойти до L10 Google Fellow, изучить все имеющиеся отрасли науки и покорить все существующие карьерные лестницы, то возможно стоит переосмыслить стратегию. Тише едешь — дальше будешь. Гораздо важнее соблюдать правильный work-life balance, следить за здоровьем и спокойненько продвигаться в работе, чтобы не выгореть через пару лет и, не дай бог, не состариться преждевременно :)
Можно, конечно, мне возразить — откуда я знаю, что он все эти 30 лет не фигачил без отдыха. На это ответ скорее такой, что по моим ощущениям сейчас отношение к работе такое, что если ты не получаешь каждый год невероятные повышения — что-то делаешь не так. Возникает порочный круг — люди слишком сильно напрягаются и фигачат, это приводит к нестабильности, затем они не получают ожидаемых повышений, и продолжают также фигачить и копить в себе негатив.
Делать обобщения и говорить, что все обязательно должны соблюдать work-life balance и никуда не спешить — точно неправильно. Это, конечно, вопрос приоритетов. Да и некоторые люди действительно могут фигачить 24/7 без последствий. Но лично для меня пример Ed H. Chi выглядит хорошо :)
Ранжирование в YouTube.
Досмотрел запись воркшопа VideoRecsys, на котором были доклады от YouTube, Instagram, Google Deepmind, Netflix, Kuaishou (не хватает только ByteDance). Сделал небольшие заметки по всем докладам. Этот пост посвящен докладу про Youtube от Lukasz Heldt, principal engineer в YouTube Discovery.
Эволюция ранжирования в YouTube. Модели растут по сложности и количеству параметров:
- (2015) линейная модель с сотней-другой признаков, много feature engineering'а и ручное скрещивание фичей.
- (2016) нейросетки (знаменитый YoutubeDNN): перестали подбирать фичи, сфокусировались на архитектуре нейросети.
- (2019) мультизадачная ранжирующая модель (тоже есть статья): mixture of experts, позиционный дебаясинг, многозадачность.
- (2023) продолжали усложнять модель, добавлять больше фичей; это привело к нестабильности обучения, про которую рассказывают в свежей статье.
Почему скейлинг (увеличение) моделей — это хорошо:
1. Чем больше модель (обучаемые параметры), тем меньше эвристик (необучаемых параметров) поверх нее нужно для адекватного качества рекомендаций. Чем меньше эвристик, тем лучше. Вот, например, пост от Миши на эту тему.
2. ML-лоссы для больших моделей лучше коррелируют с a/b тестами! Улучшения больших моделей влекут улучшения в "точности" рекомендаций, в то время как изменения более простых моделей зачастую влияют на бизнес-метрики по другим причинам: например, растет разнообразие рекомендаций.
Оптимизация метрик. Любая ранжирующая система, которая дообучается на результате своей работы, т.е. порождает фидбек луп, является РЛ агентом. До тех пор, пока она дообучается на своем фидбеке, она будет улучшаться. Если считать, что модель оценивает вероятность положительного взаимодействия, то она будет совершать ошибки двух типов — overprediction и underprediction. Т.е. давать завышенные и заниженные прогнозы.
Так как модель используется для ранжирования, то в выдачу в первую очередь будут прорастать ошибки, связанные с завышением предсказаний. Если какой-то айтем был недооценен, то он и в выдачу не попадет. Получается, что модель не сможет при дообучении понять, что он был недооценен, т.к. не получит про него фидбек.
А значит, в основном с помощью дообучения мы исправляем ошибки, связанные с завышением прогнозов. Есть еще и такой неприятный эффект, что модель при дообучении, видя эти ошибки, будет "понижать" все свои прогнозы, сдвигая среднее значение предсказаний вниз. Ранжирование с дообучением — это такой неявный UCB алгоритм, скошенный в сторону завышенных прогнозов.
Как с этим бороться? Использовать бандитов. Например, fixed slot exploration — выделяем позицию в выдаче, в которую стараемся помещать underprediction'ы. Статья Online Matching: A Real-time Bandit System for Large-scale Recommendations.
Был еще и третий раздел доклада, Modeling Product Behavior. На исход рекомендаций влияет много разных факторов: на какой позиции был айтем (position bias), какие айтемы находились рядом (neighbour bias), в каком порядке пользователь просматривает выдачу (cascade click models), etc. Чтобы получше обучить модель, нужно все эти эффекты моделировать.
Что запомнилось из Q&A секции:
1. На вопрос про позитивы/негативы для обучения явно сказали, что используют только impressions — показанные в выдаче объекты.
2. Есть рандомизированная доля трафика, в которой выдача ранжируется случайно (т.е. перемешивается).
3. На вопрос "а не стало ли хуже с интерпретируемостью из-за усложнения моделей" ответили, что и про линейные модели не особо понимали что они делают, из-за гигантских матриц эмбеддингов :)
4. Чтобы побороть холодный старт для айтемов, (1) подсовывают холодных кандидатов ранжированию и (2) используют explicit item exploration (те же бандиты, по сути).
5. Кто-то спросил "а не тяжело ли будет использовать LLM'ки для ранжирования из-за костов на обучение/сервинг"? Ответ не запомнил, кажется, там было что-то типа "Да, тяжело." :)
#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.