Чтобы прокоммуницировать с инопланетянами, нужен всего лишь 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 двубашенных рекомендаций, когда у нас есть векторы объектов. С помощью обученного генератора можно получить рекомендации для пользователей, даже если нет взаимодействий между пользователями и айтемами.
В своё время статья Word Translation Without Parallel Data, опубликованная на ICLR 2018, произвела на меня неизгладимое впечатление. За что люблю машинное обучение и deep learning в частности — за "вау-эффекты", вызываемые разными прикольными результатами.
В статье демонстрируется, что при наличии двух никак не связанных текстовых корпусов на разных языках можно научиться переводить слова. Что это значит: если к нам заявятся инопланетяне, мы сможем быстро наладить коммуникацию — нужен всего лишь текстовый корпус.
Обучаем для обоих корпусов векторные пространства слов, например, с помощью word2vec. Затем учим GAN: генератор (умножение на обучаемую матрицу) учится переводить элементы из одного пространства в другое, а дискриминатор учится определять исходное пространство. Чтобы перевести слово, применяем генератор (умножаем вектор слова на матрицу) и ищем наиболее близкое слово из другого языка в векторном пространстве. И это адекватно работает!
Какой гипотезой мы здесь пользуемся: векторные пространства языков имеют похожую структуру. Поэтому можно попытаться "наложить" одно векторное пространство на другое, что мы умножением на матрицу генератора и делаем. По-научному сейчас это назвали бы "unsupervised alignment of embedding spaces".
Когда-то философ Виттгенштейн опубликовал свой труд Tractatus Logico-Philosophicus, в котором пытался задать язык, идеально описывающий реальность. Язык фактов :) Опираясь на этот труд, можно было бы и поверить в нашу гипотезу. Но сам же Виттгенштейн в более поздние годы переобулся и постулировал, что язык задаётся контекстом использования. Иногда его цитируют, когда объясняют word2vec :)
И на затравку: такой подход с unsupervised alignment можно применять для zero-shot двубашенных рекомендаций, когда у нас есть векторы объектов. С помощью обученного генератора можно получить рекомендации для пользователей, даже если нет взаимодействий между пользователями и айтемами.
❤10👍6
#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:
Мораль думайте сами :)
На этой неделе невероятных прорывов опять нет, тем не менее статьи поинтересней, чем на прошлой.
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.
Мораль думайте сами :)
👍15
Сегодня на YaTalks выступал Олег Лашинин @lashinin с обзорным докладом про рекомендательные системы.
Рассказывал про:
1. Проблемы с оценкой качества и результатами: global timeline, movielens, фидбек лупы, баги в имплементациях, etc
2. Модели: матричная факторизация, линейные модели, графовые сети, трансформеры
3. Тренды: chatgpt для рекомендаций, обучение с подкреплением (для предсказания следующего взаимодействия или бизнес-метрик, бандиты для рекомендаций)
Призываю посмотреть, доклад хороший. Ссылочка :)
Рассказывал про:
1. Проблемы с оценкой качества и результатами: global timeline, movielens, фидбек лупы, баги в имплементациях, etc
2. Модели: матричная факторизация, линейные модели, графовые сети, трансформеры
3. Тренды: chatgpt для рекомендаций, обучение с подкреплением (для предсказания следующего взаимодействия или бизнес-метрик, бандиты для рекомендаций)
Призываю посмотреть, доклад хороший. Ссылочка :)
❤11🌭3👍1
Посетил сегодня конференцию по рекомендательным системам от Вышки. Тезисно:
1. Во время нетворкинга пытался всех убедить, что будущее за графовыми сетками и РЛ. Надеюсь, сработало
2. Попросили точный прогноз когда РЛ заработает, сказал “через 5-15 лет”
3. Получил подтверждение, что другие рексис лиды тоже скептически относятся к языковым моделям. Ждем, пока настанет наше время
4. One hot encoding — “один бит горит”
5. Фраза “у нас kpi не на статьи” — фиговая отмазка для отсутствия публикаций
1. Во время нетворкинга пытался всех убедить, что будущее за графовыми сетками и РЛ. Надеюсь, сработало
2. Попросили точный прогноз когда РЛ заработает, сказал “через 5-15 лет”
3. Получил подтверждение, что другие рексис лиды тоже скептически относятся к языковым моделям. Ждем, пока настанет наше время
4. One hot encoding — “один бит горит”
5. Фраза “у нас kpi не на статьи” — фиговая отмазка для отсутствия публикаций
❤16🔥10
Про чтение статей (для 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 для хранения и структурирования пдфок со статьями. Создание иерархий, использование тэгов. Потом стал вписывать аффилиацию авторов в отдельное поле.
Доклад, по которому я планировал писать пост, был структурирован следующим образом — (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 для хранения и структурирования пдфок со статьями. Создание иерархий, использование тэгов. Потом стал вписывать аффилиацию авторов в отдельное поле.
🔥33🙏1
Массовые увольнения в Spotify.
В Spotify прошла уже третья, самая большая волна увольнений. Уволили 1500 человек, 17% сотрудников.
Как можно было понять по прошлым постам, мне Spotify импонирует. У них крутая рабочая этика с акцентом на правильный work-life balancе. Например, есть wellness week — дополнительная оплачиваемая неделя отпуска для всех сотрудников. Ресерч тоже крутой, ребята публикуют хорошие статьи по РЛ в рекомендациях. Ну и сам продукт очень приятный, я уже много лет абсолютно каждую неделю прослушиваю свои рекомендации в discovery weekly и release radar.
Судя по всему, не выгорела движуха с подкастами, в которую они довольно сильно вкладывались с 2019-го года (СМИ пишут про 1 млрд долларов). Выход на IPO в 2018, думаю, тоже не помог с текущей ситуацией. Много ресерча в последние годы было сфокусировано именно на подкастах, что тоже обидно.
Какие-то подробности можно почитать на Линкедине.
В Spotify прошла уже третья, самая большая волна увольнений. Уволили 1500 человек, 17% сотрудников.
Как можно было понять по прошлым постам, мне Spotify импонирует. У них крутая рабочая этика с акцентом на правильный work-life balancе. Например, есть wellness week — дополнительная оплачиваемая неделя отпуска для всех сотрудников. Ресерч тоже крутой, ребята публикуют хорошие статьи по РЛ в рекомендациях. Ну и сам продукт очень приятный, я уже много лет абсолютно каждую неделю прослушиваю свои рекомендации в discovery weekly и release radar.
Судя по всему, не выгорела движуха с подкастами, в которую они довольно сильно вкладывались с 2019-го года (СМИ пишут про 1 млрд долларов). Выход на IPO в 2018, думаю, тоже не помог с текущей ситуацией. Много ресерча в последние годы было сфокусировано именно на подкастах, что тоже обидно.
Какие-то подробности можно почитать на Линкедине.
😢18🎄3👍2
#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.
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.
🔥28👍6
С момента создания канала прошёл ровно месяц. Всем спасибо за комментарии, реакции и поддержку! Захотелось написать метапост с итогами месяца, резюмировать всё происходящее с моей перспективы.
Когда создавал канал, у меня была цель выкладывать дайджесты. Этим я довольно давно начал заниматься внутри Яндекса, но там это скорее было мини-бонусом к 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, Антон @toshiknoscript и еще чатик reading group Саши Петрова @ods_recommender_systems. У ребят в bio есть ссылки на каналы (UPD: У Миши в bio канала нет, @WazowskiRecommends).
P.S: как будто речь на оскар подготовил =)
Когда создавал канал, у меня была цель выкладывать дайджесты. Этим я довольно давно начал заниматься внутри Яндекса, но там это скорее было мини-бонусом к 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, Антон @toshiknoscript и еще чатик reading group Саши Петрова @ods_recommender_systems. У ребят в bio есть ссылки на каналы (UPD: У Миши в bio канала нет, @WazowskiRecommends).
P.S: как будто речь на оскар подготовил =)
👍34🔥13❤9
Ранжирование в 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'ки для ранжирования из-за костов на обучение/сервинг"? Ответ не запомнил, кажется, там было что-то типа "Да, тяжело." :)
Досмотрел запись воркшопа 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'ки для ранжирования из-за костов на обучение/сервинг"? Ответ не запомнил, кажется, там было что-то типа "Да, тяжело." :)
🔥26👍5❤3
#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
* культурно и социально-экономически осознанные рексистемы
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
* культурно и социально-экономически осознанные рексистемы
🔥19👍6
Путь длиной в тысячу ли до 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 выглядит хорошо :)
В Гугле есть целая научная группа, которая занимается рекомендашками. Из-под их пера вышел 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
Ed H. Chi P Research Scientist at Google Research www2012
💯34❤23👍10🤔4✍1🔥1
#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 обучает для сущностей такие эмбеддинги, что
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.
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.
👍18🔥4❤🔥1❤1🫡1🗿1🤷1
У Миши вышел хороший пост про 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. градиентов), что плохо влияет на обучение. Любые недостатки логирующей политики будут плохо влиять на модели, обученные по залогированным данным; особенно если эти недостатки игнорируются.
Часто как синонимы к 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. градиентов), что плохо влияет на обучение. Любые недостатки логирующей политики будут плохо влиять на модели, обученные по залогированным данным; особенно если эти недостатки игнорируются.
👍12🔥3❤1
Forwarded from Wazowski Recommends
Персонализация и 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-модели.
Распространённая проблема в рекомендательных системах — недостаток персонализации, когда показываются в основном популярные и не очень релевантные пользователю документы.
В сообществе есть известная проблема 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-модели.
❤6
Дообучение ранжирования в рекомендательных системах.
В посте про ранжирование в Youtube поступил интересный вопрос от @lashinin:
Довести типичные метрики рекомендаций до единичных значений мы скорее всего не сможем. В рекомендациях есть свой bayes error rate, возникающий из-за (1) стохастичности системы и (2) невозможности получить всю информацию про состояние мира. Первый пункт немного философский, тут можно поспорить про детерминизм происходящего. Второй полностью объективен — нам в рекомендательных системах никогда не доступна вся информация. С точки зрения РЛ, наша система больше похожа на POMDP (partially observable MDP), в котором нужно учитывать, что агент видит только часть информации.
Если забить на единичные метрики качества и предположить, что у нас есть какой-то потолок метрик, который мы хотим достичь, то можно переформулировать вопрос как "достигнем ли мы этот потолок метрик при дообучении?". Ответ — не факт:
1. Система многостадийная, и ранжирование — это только одна из стадий. Если другие стадии неидеальны, то они не дадут обучить идеальное ранжирование. Например, если у нас кандидатогенератор обладает каким-то bias'ом и систематически не выдает часть хороших кандидатов, то ранжирование не сможет научиться хорошо на них работать.
2. Feedback loop. Пусть у нас одностадийная система, в которой наша модель из всего множества кандидатов сразу формирует выдачу, и даже нет никакого дополнительного процессинга с бизнес-логикой. Если в момент Т, когда мы настроили дообучение, у модели были какие-то недостатки (те же bias'ы), то ничего не гарантирует, что она полечит их дообучением. Пример Ютуба с overprediction'ми наглядно показывает, что без дополнительных трюков модель сможет корректировать только один тип своих ошибок, а другой останется без внимания. То есть, нужно так настроить процесс, чтобы модель cмогла cкорректировать все свои недостатки. В примере Ютуба добавляется fixed slot exploration, но в реальности могут быть и другие проблемы, для которых нужно придумывать свои решения.
3. Может быть такое, что даже если мы добавили в дообучение все средства борьбы с недостатками модели, она все равно не придет к "оптимальному состоянию", а будет блуждать возле него. Т.е. каждую итерацию дообучения мы будем исправлять одни недостатки и порождать другие. И так далее.
4. Среда, в которой функционирует рекомендательная система, очень динамичная. И у пользователей, и у айтемов все меняется, происходит distribution shift всевозможных типов. Чтобы его побороть, нужно обучаться на новых данных без малейшей задержки. Такое сложно обеспечить, хотя некоторые пытаются (см. Monolith от ByteDance). Получается, нужно буквально наладить online RL :)
А вы что думаете? Согласны ли с вышеперечисленными пунктами, есть ли дополнительные? Жду в комментариях :)
В посте про ранжирование в Youtube поступил интересный вопрос от @lashinin:
Как думаешь, если систему оставить в покое, обучая ее на все более свежих данных по настроенному процессу, она сойдется к идеальной системе (условно к единичным метрикам ранжирования)?
Довести типичные метрики рекомендаций до единичных значений мы скорее всего не сможем. В рекомендациях есть свой bayes error rate, возникающий из-за (1) стохастичности системы и (2) невозможности получить всю информацию про состояние мира. Первый пункт немного философский, тут можно поспорить про детерминизм происходящего. Второй полностью объективен — нам в рекомендательных системах никогда не доступна вся информация. С точки зрения РЛ, наша система больше похожа на POMDP (partially observable MDP), в котором нужно учитывать, что агент видит только часть информации.
Если забить на единичные метрики качества и предположить, что у нас есть какой-то потолок метрик, который мы хотим достичь, то можно переформулировать вопрос как "достигнем ли мы этот потолок метрик при дообучении?". Ответ — не факт:
1. Система многостадийная, и ранжирование — это только одна из стадий. Если другие стадии неидеальны, то они не дадут обучить идеальное ранжирование. Например, если у нас кандидатогенератор обладает каким-то bias'ом и систематически не выдает часть хороших кандидатов, то ранжирование не сможет научиться хорошо на них работать.
2. Feedback loop. Пусть у нас одностадийная система, в которой наша модель из всего множества кандидатов сразу формирует выдачу, и даже нет никакого дополнительного процессинга с бизнес-логикой. Если в момент Т, когда мы настроили дообучение, у модели были какие-то недостатки (те же bias'ы), то ничего не гарантирует, что она полечит их дообучением. Пример Ютуба с overprediction'ми наглядно показывает, что без дополнительных трюков модель сможет корректировать только один тип своих ошибок, а другой останется без внимания. То есть, нужно так настроить процесс, чтобы модель cмогла cкорректировать все свои недостатки. В примере Ютуба добавляется fixed slot exploration, но в реальности могут быть и другие проблемы, для которых нужно придумывать свои решения.
3. Может быть такое, что даже если мы добавили в дообучение все средства борьбы с недостатками модели, она все равно не придет к "оптимальному состоянию", а будет блуждать возле него. Т.е. каждую итерацию дообучения мы будем исправлять одни недостатки и порождать другие. И так далее.
4. Среда, в которой функционирует рекомендательная система, очень динамичная. И у пользователей, и у айтемов все меняется, происходит distribution shift всевозможных типов. Чтобы его побороть, нужно обучаться на новых данных без малейшей задержки. Такое сложно обеспечить, хотя некоторые пытаются (см. Monolith от ByteDance). Получается, нужно буквально наладить online RL :)
А вы что думаете? Согласны ли с вышеперечисленными пунктами, есть ли дополнительные? Жду в комментариях :)
👍14🔥3🤔3
Learning RecSys on Graphs.
Если собрать все данные, которые порождает какой-нибудь продукт (e.g. Яндекс Маркет), получится граф. Строить рекомендации для пользователей с помощью этого графа — это ключевая задача рекомендательной системы.
Вершинами в графе являются всевозможные сущности и объекты — пользователи, товары, поисковые запросы, etc.
Ребра — это взаимодействия между сущностями: e.g. взаимодействия пользователей с товарами, клики на товары по запросу, etc. Метаданные ребер содержат контекст взаимодействия, e.g. время и тип взаимодействия, девайс пользователя, поверхность рекомендации.
Граф — гетерогенный (разнородный). Вершины и ребра в нем имеют разные типы, содержат разные наборы информации.
Это гиперграф. В нем есть гиперребра — ребра, объединяющие произвольное количество вершин. Например, купленные вместе товары (i.e. basket).
Граф — динамический. Он развивается со временем; поток событий в системе порождает новые ребра в графе.
Еще есть граф знаний. Все метаданные вершин можно представить в виде графа с “семантическими вершинами”, e.g. категориями и характеристиками товаров. Сами семантические ноды могут быть связаны между собой, e.g. таксономия категорий товаров.
А еще можно построить граф сразу для всей экосистемы. Добавить в тот же граф для Маркета данные из других сервисов, т.н. кросс-доменный граф: пользователей, айтемы, их метаданные и всевозможные типы взаимодействий.
Задача графовых моделей — извлечь максимум пользы из этих данных. Любые модели рекомендаций так или иначе оперируют этим графом, но, как правило, игнорируют большую его часть. Например, sequential модели (e.g. SASRec) часто рассматривают только пользователей и айтемы, оставляют только один тип ребра, при этом выкидывают все метаданные айтемов и ребер (кроме их порядка по времени), убирают граф знаний и кросс-доменную информацию.
Обучить ультимативную графовую модель на всех данных, получив универсальные эмбеддинги для всех сущностей в системе — одна из задач, которой мы с командой занимаемся в Яндексе.
Если собрать все данные, которые порождает какой-нибудь продукт (e.g. Яндекс Маркет), получится граф. Строить рекомендации для пользователей с помощью этого графа — это ключевая задача рекомендательной системы.
Вершинами в графе являются всевозможные сущности и объекты — пользователи, товары, поисковые запросы, etc.
Ребра — это взаимодействия между сущностями: e.g. взаимодействия пользователей с товарами, клики на товары по запросу, etc. Метаданные ребер содержат контекст взаимодействия, e.g. время и тип взаимодействия, девайс пользователя, поверхность рекомендации.
Граф — гетерогенный (разнородный). Вершины и ребра в нем имеют разные типы, содержат разные наборы информации.
Это гиперграф. В нем есть гиперребра — ребра, объединяющие произвольное количество вершин. Например, купленные вместе товары (i.e. basket).
Граф — динамический. Он развивается со временем; поток событий в системе порождает новые ребра в графе.
Еще есть граф знаний. Все метаданные вершин можно представить в виде графа с “семантическими вершинами”, e.g. категориями и характеристиками товаров. Сами семантические ноды могут быть связаны между собой, e.g. таксономия категорий товаров.
А еще можно построить граф сразу для всей экосистемы. Добавить в тот же граф для Маркета данные из других сервисов, т.н. кросс-доменный граф: пользователей, айтемы, их метаданные и всевозможные типы взаимодействий.
Задача графовых моделей — извлечь максимум пользы из этих данных. Любые модели рекомендаций так или иначе оперируют этим графом, но, как правило, игнорируют большую его часть. Например, sequential модели (e.g. SASRec) часто рассматривают только пользователей и айтемы, оставляют только один тип ребра, при этом выкидывают все метаданные айтемов и ребер (кроме их порядка по времени), убирают граф знаний и кросс-доменную информацию.
Обучить ультимативную графовую модель на всех данных, получив универсальные эмбеддинги для всех сущностей в системе — одна из задач, которой мы с командой занимаемся в Яндексе.
🔥25👍8😎6
#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-го года. С наступающим!
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-го года. С наступающим!
🎄39👍2🔥2🕊1
Рекомендации от меня, на случай если не знаете, чем занять себя в новогоднюю ночь:
1. Начать с этого короткого ШКЯ видео.
2. Посмотреть видео про самые дикие рождественские традиции в Европе и Америке.
3. Посмотреть рождественское аниме 2003-го года Tokyo Godfathers.
P.S: для рекомендательных систем, новогодние праздники - это всегда тяжелый период. Дикий distribution shift :)
1. Начать с этого короткого ШКЯ видео.
2. Посмотреть видео про самые дикие рождественские традиции в Европе и Америке.
3. Посмотреть рождественское аниме 2003-го года Tokyo Godfathers.
P.S: для рекомендательных систем, новогодние праздники - это всегда тяжелый период. Дикий distribution shift :)
❤12👍5🔥1
Про ML соревнования.
Свои первые деньги, не связанные со студенческими стипендиями, я заработал ~шесть лет назад, заняв второе место в ML соревновании. На часть из полученных 200 тысяч я собрал мощный комп с 1080ti, чтобы нейроночки обучать и в ведьмака играть :)
Первые два года изучения ML меня очень сильно драйвили соревнования, вплоть до того, что я посвящал им почти все свободное время. Подозреваю, что от улучшения метрик и карабканья по лидерборду у меня выделяется довольно большое количество серотонина, потому что я тогда фигачил без отдыха месяцами, на чистом энтузиазме.
Мой первый контест — Sberbank Data Science Journey 2017; определение релевантности вопроса параграфу текста. Обогнал своего препода с кафедры, заняв 8-е место. Изучал NLP и классический ML буквально по ходу соревнования, и такое изучение теории на практике для меня работало очень хорошо. Еще помню, что там часть вопросов была синтетическая, сгенерированная, и надо было научиться отличать их от настоящих, чтобы сразу ставить им нолики. Я применил марковскую цепь как языковую модель для генерации синтетики и очень радовался, что это сработало :)
Основное, что я вынес с соревнований(и вспомнил во время написания этого поста):
1. Успешность идеи очень сильно зависит от реализации. У контестов, как правило, были чаты, где участники активно общались по ходу соревнования. Я неоднократно наблюдал, как те же идеи, что давали много профита у меня, у других людей не срабатывали. И наоборот. Осталось ощущение, что почти из любой идеи можно выжать профит, если рассмотреть ее под правильным углом.
На работе с этим сложнее: конкретные эксперименты проводит один человек, и если эксперименты закончились неудачно, то всегда остается некоторая неопределенность, почему так получилось. Здесь помогают (1) статьи, по которым мы иногда точно понимаем, что что-то должно работать. (2) правильные формулировки задач, смещение акцента с оффлайн-метрик базового качества на интерпретируемые вопросы и гипотезы, (3) перепроверки друг за другом, а также (4) возвращение к старым направлениям экспериментов.
2. Получил очень много опыта по ведению экспериментов. С одной стороны, оптимизировать какое-то не совсем интерпретируемое чиселко в отрыве от бизнеса — не очень продуктивно. Соревнования сильно разнятся по степени "осмысленности", это зависит от осознанности организаторов. С другой стороны — в отличие от работы, здесь ты соревнуешься с другими людьми, и есть возможность себя относительно них очень хорошо откалибровать. Насколько хорошо ты ставишь эксперименты, а именно: находишь правильные гипотезы, быстро их проверяешь, правильно реализуешь.
На работе все сильно зависит от самокритичности человека, это иногда и плохо, и хорошо. Из неудачной серии экспериментов можно сделать совсем разные выводы. Самый частый вывод — что гипотеза неудачная или задача нерешаемая; он особенно плох, если не получилось при этом сформировать правильную интуицию происходящего. В соревнованиях же, если ты находишься низко по лидерборду, то у этого может быть только одна причина :)
Итого, плюсы соревнований:
* опыт экспериментирования
* возможность откалиброваться относительно других экспериментаторов
* доп. источник заработка
Минусы:
* осмысленность поставленных задач сильно зависит от осознанности организаторов
* прошлый пункт, на самом деле, еще иногда приводит к страшным эффектам по типу ликов в данных и к совсем необобщающимся на бизнес зависимостям, без которых высокую метрику не получишь
* если у вас хорошая работа, то на ней задачи интересней, и необходимость в соревнованиях отпадает. На работе у меня есть возможность самому формулировать задачи, и при этом мне доступны почти неограниченные ресурсы с т.з. данных и железа. После выхода в Яндекс ~3.5 года назад, я перестал участвовать в соревнованиях
На бустерс @boosters после долгого молчания платформы началось новое соревнование по рекомендашкам от hh. Вашего покорного слугу на лидерборде тоже можно найти. Решил тряхнуть стариной :)
Свои первые деньги, не связанные со студенческими стипендиями, я заработал ~шесть лет назад, заняв второе место в ML соревновании. На часть из полученных 200 тысяч я собрал мощный комп с 1080ti, чтобы нейроночки обучать и в ведьмака играть :)
Первые два года изучения ML меня очень сильно драйвили соревнования, вплоть до того, что я посвящал им почти все свободное время. Подозреваю, что от улучшения метрик и карабканья по лидерборду у меня выделяется довольно большое количество серотонина, потому что я тогда фигачил без отдыха месяцами, на чистом энтузиазме.
Мой первый контест — Sberbank Data Science Journey 2017; определение релевантности вопроса параграфу текста. Обогнал своего препода с кафедры, заняв 8-е место. Изучал NLP и классический ML буквально по ходу соревнования, и такое изучение теории на практике для меня работало очень хорошо. Еще помню, что там часть вопросов была синтетическая, сгенерированная, и надо было научиться отличать их от настоящих, чтобы сразу ставить им нолики. Я применил марковскую цепь как языковую модель для генерации синтетики и очень радовался, что это сработало :)
Основное, что я вынес с соревнований
1. Успешность идеи очень сильно зависит от реализации. У контестов, как правило, были чаты, где участники активно общались по ходу соревнования. Я неоднократно наблюдал, как те же идеи, что давали много профита у меня, у других людей не срабатывали. И наоборот. Осталось ощущение, что почти из любой идеи можно выжать профит, если рассмотреть ее под правильным углом.
На работе с этим сложнее: конкретные эксперименты проводит один человек, и если эксперименты закончились неудачно, то всегда остается некоторая неопределенность, почему так получилось. Здесь помогают (1) статьи, по которым мы иногда точно понимаем, что что-то должно работать. (2) правильные формулировки задач, смещение акцента с оффлайн-метрик базового качества на интерпретируемые вопросы и гипотезы, (3) перепроверки друг за другом, а также (4) возвращение к старым направлениям экспериментов.
2. Получил очень много опыта по ведению экспериментов. С одной стороны, оптимизировать какое-то не совсем интерпретируемое чиселко в отрыве от бизнеса — не очень продуктивно. Соревнования сильно разнятся по степени "осмысленности", это зависит от осознанности организаторов. С другой стороны — в отличие от работы, здесь ты соревнуешься с другими людьми, и есть возможность себя относительно них очень хорошо откалибровать. Насколько хорошо ты ставишь эксперименты, а именно: находишь правильные гипотезы, быстро их проверяешь, правильно реализуешь.
На работе все сильно зависит от самокритичности человека, это иногда и плохо, и хорошо. Из неудачной серии экспериментов можно сделать совсем разные выводы. Самый частый вывод — что гипотеза неудачная или задача нерешаемая; он особенно плох, если не получилось при этом сформировать правильную интуицию происходящего. В соревнованиях же, если ты находишься низко по лидерборду, то у этого может быть только одна причина :)
Итого, плюсы соревнований:
* опыт экспериментирования
* возможность откалиброваться относительно других экспериментаторов
* доп. источник заработка
Минусы:
* осмысленность поставленных задач сильно зависит от осознанности организаторов
* прошлый пункт, на самом деле, еще иногда приводит к страшным эффектам по типу ликов в данных и к совсем необобщающимся на бизнес зависимостям, без которых высокую метрику не получишь
* если у вас хорошая работа, то на ней задачи интересней, и необходимость в соревнованиях отпадает. На работе у меня есть возможность самому формулировать задачи, и при этом мне доступны почти неограниченные ресурсы с т.з. данных и железа. После выхода в Яндекс ~3.5 года назад, я перестал участвовать в соревнованиях
На бустерс @boosters после долгого молчания платформы началось новое соревнование по рекомендашкам от hh. Вашего покорного слугу на лидерборде тоже можно найти. Решил тряхнуть стариной :)
👍25🔥11🏆2
#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. (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. Вышло два обзора, про графовые нейросети над табличными данными и про атаки на рексистемы.
👍21
Нейросетевой мир победил (в ранжировании).
В каждой рекомендательной системе есть алгоритм, который определяет финальную выдачу. Иногда он работает сразу над всем каталогом айтемов, т.е. 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 :)
В каждой рекомендательной системе есть алгоритм, который определяет финальную выдачу. Иногда он работает сразу над всем каталогом айтемов, т.е. 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 :)
🔥27👍8❤1🤔1