Персонализация неизбежна
Open in Telegram
603
Subscribers
No data24 hours
+117 days
+5430 days
Data loading in progress...
Similar Channels
No data
Any problems? Please refresh the page or contact our support manager.
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
January '25
January '25
+57
in 0 channels
December '24
+549
in 2 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 28 January | +2 | |||
| 27 January | +1 | |||
| 26 January | +2 | |||
| 25 January | +6 | |||
| 24 January | 0 | |||
| 23 January | 0 | |||
| 22 January | +3 | |||
| 21 January | +1 | |||
| 20 January | +3 | |||
| 19 January | +2 | |||
| 18 January | +1 | |||
| 17 January | +3 | |||
| 16 January | +4 | |||
| 15 January | +2 | |||
| 14 January | +7 | |||
| 13 January | +4 | |||
| 12 January | +2 | |||
| 11 January | +3 | |||
| 10 January | 0 | |||
| 09 January | 0 | |||
| 08 January | +3 | |||
| 07 January | 0 | |||
| 06 January | +1 | |||
| 05 January | +3 | |||
| 04 January | +1 | |||
| 03 January | 0 | |||
| 02 January | 0 | |||
| 01 January | +3 |
Channel Posts
А теперь — мои прогнозы на 2025 год в мире рекомендательных систем:
1. Ждём RecSys Arena по аналогии с lmarena.ai! Это будет захватывающая перспектива — валидировать модели не только с помощью разметки от людей, но и используя LLM.
2. Уверен, что российские компании поделятся успешным кейсом внедрения LLM в продакшн-рекомендации с реальным профитом для бизнеса. Будет очень интересно! 🤞
3. Наконец-то появятся open-source решения (модели + методы) для рекомендательных систем, которые достойно справятся с проблемой холодного старта. И, возможно, даже превзойдут кастомные разработки!
4. Рекомендательные системы и Поиск станут ещё ближе. Кто-то из индустрии наверняка начнёт эксперименты (или даже представит результаты) с объединённой системой. Это может быть революционное решение!
5. Какой-нибудь NLP-проект научится давать действительно полезные рекомендации на сторонних сайтах, и люди начнут им пользоваться именно из-за этой крутой персонализации. И может возникнуть конкуренция с нативной персонализацией на самом сайте.
6. В академической среде, по инерции, продолжат выходить статьи на основе MovieLens-1M… Но, боюсь, интерес к ним будет угасать (смотрим на это с грустной улыбкой). 😔
7. Персонализация будет не только про RecSys! Речь пойдет уже не только о ранжировании, но и о персонализации дизайна интерфейсов и самого контента. Мы увидим больше контента, который создаётся изначально персонализированным, а не просто адаптируется на этапе выдачи.
8. RecSys модели будут расти по размеру, количеству обрабатываемых данных и скорости этой обработки. В Яндексе уже сделали трансформер 1B, а я в этом году начал пользоваться рекомендациями на Яндекс.Музыке)
9. Российское RecSys сообщество продолжит активно развиваться. В этом году был полноценный день на датафесте про recsys от VK, митапы от Сбера, Т-Банка, WB, VK, доклады на конференциях ai-conf, Turbo ML Conf, E-Code, Practical ML Conf. Уверен, что что-то упустил из виду, но все вспомнить сложно. А также много с кем виделись на RecSys 24 в Италии. Надеюсь, что в следующем году будет еще больше интересных ивентов.
Посмотрим, что из этого списка сбудется к концу следующего года! 😉 Всех с наступающим Новым Годом! 🎄🎉
| 2 | Подводим предновогодние итоги 2024 года! 🥂
Ровно год назад я выступал на конференции Яндекса с докладом "Тренды, подходы и проблемы в рекомендательных системах 2023 года". Пролетел год, и давайте посмотрим, что изменилось, если пройтись по основным пунктам.
Помните про "нечестную" оценку моделей в статьях с подглядыванием в будущее? Так вот, открываем главную конференцию по рекомендациям RecSys 24 и что видим? Всё те же грабли! Случайно выбранные статьи из трека full paper используют: user-based split (8 работ: 1, 2, 3, 4, 5, 6, 7, 8 🤯), random split (2 работы: 1, 2) и лишь одна — самый предпочтительный global timeline-based. Подробнее об этих подходах можно почитать здесь. В общем, ситуация, похоже, кардинально не изменилась. 😔
А что по поводу сложности оценки рекомендаций на исторических данных? Все упомянутые 11 статей по-прежнему используют "типичную" парадигму, пытаясь максимально точно предсказать исторические данные. Если модель начинает рекомендовать что-то отличное от исторических данных (но более релевантное), то она в проигрыше. Лично я возлагаю большие надежды на LLM-based evaluation и жду прорыва в этой области в 2025 году. И вот свежий пример — совсем недавно вышла статья про RecSys Arena! Наш старый знакомый SASRec сравнили с LightGCN с помощью GPT-4o. Осталось дело за малым: показать и доказать корреляцию LLM-оценок с результатами А/Б-тестов (и, конечно, научиться воспроизводимо получать такие оценки). Представляете, какие горизонты это откроет? ✨
Отсутствие кода в статьях. Тут, пожалуй, и добавить нечего. Ситуация, кажется, не меняется.
Некачественные имплементации порождают слабые результаты моделей. Год назад я говорил про работы, в которых обнаружили слабые open-source реализации GRU4Rec и BERT4Rec. В этом году мы с коллегами показали, что одна из самых популярных моделей BPR в таких популярных фреймворках как implicit/RecBole/LightFM реализована не самым оптимальным образом, поэтом проигрывает по качеству более качественным имплементациям.
Маленькие датасеты — проблема академических исследований. Из 11 упомянутых выше статей, только одна может похвастаться датасетом с более чем 1 миллионом пользователей. Ещё две работы оперируют данными в районе 100 тысяч, а остальные — и вовсе несколькими десятками тысяч. Проблема в том, что модели, показывающие отличные результаты на скромных 10 тысячах пользователей, могут попросту "потеряться" при масштабировании на миллионы. И те "впечатляющие" приросты метрик, скорее всего, испарятся. 💨
Тренд на LLM & RecSys — в самом разгаре! И это не может не радовать! Алиса от Яндекса уже вовсю рекомендует товары и собирает корзины в Яндекс.Лавке. YouTube Shorts использует LLM для подбора контента, максимально отвечающего вашим интересам. Даже старый добрый EASE прокачали знаниями, полученными от больших языковых моделей. А сколько интересных статей выходит про симуляцию поведения пользователей с помощью LLM! В общем, направление развивается семимильными шагами. 🚀
Тренд на RL & RecSys — небольшая неопределенность. На Turbo ML Conf я делился, как мы завели RL в рекомендательных системах и выиграли у обычного бустинга? Правда, тут же проиграли другому, ещё более качествнному бустингу 🙂. Но я, и коллеги из Яндекса отметили, что на RecSys24 работ по RL & RecSys было на удивление мало. Похоже, этому тренду нужен свежий импульс с прорывными идеями. | 715 |
| 3 | Про мой опыт в RecSys Research
Вчера нашу новую статью приняли на ECIR 2025 - это A-конференция (значит, входит в некоторый топ-23% от некоторого набора конференций) по информационному поиску в Италии 🎉! Статья про e-grocery рекомендации, но подробности позже. Это четвертая статья на основном треке A-конференций с моим участием и четырнадцатая, если считать еще воркшопы. В этом посте напишу про свой путь, как я к этому пришел.
Весна 2019 года. Я на 4 курсе ФРКТ МФТИ, меня берут на стажировку в ML-команду. Первая задача там - сделать обзор на методы объяснений рекомендаций. Я читаю статьи, вникаю в сам домен рекомендаций. В итоге получаю табличку с ~20 статьями, где выделены важные пункты про каждую работу. На тот момент кажется, что я прекрасно разобрался в теме.
2019-2020 учебные годы. Меня берут лаборантом в VK Lab при МФТИ в recsys. Чтобы пройти отбор, я реализовывал статью про музыкальные рекомендации и пытался догнать ALS по качеству. На тот момент отгремела статья "Are we really making much progress", где авторы победили нейронные модели через простые линейные. Моя же задача была либо в поиске, либо в создании такой нейромодели, которая в честном сравнении все-таки победила бы простую модель. Мы с коллегами собрали статью на RecSys 20, но ее не взяли. Это была моя первая статья на английском языке, писать было очень сложно и получалось плохо.
2021 год. На работе начинается ресерч. Я подключаюсь, провожу эксперименты, помогаю с текстом. Мы не успеваем подать статью на RecSys 21, подаем на CIKM 21. Там нашу статью не берут, в том числе потому, что мы подали не на тот трек. Статью мы все равно выложили и ее даже процитировали зарубежные авторы. Также в этом году мы занимаем 4 место в SIGIR challenge, и пишем статью на Хабр.
2022 год. Мы пишем дипломы со студентами ВШЭ. Темы предложили исходя из наших интересов, которые потенциально могли раскрутиться и доехать до прода. Некоторым студентам предлагаем обернуть результаты в научные статьи и подать на воркшопы при конференциях. Получаем публикации про графы знаний, индуктивные sequential модели. Также в октябре мы пишем статью на ECIR 23 про next-basket recommendation и ее берут!
2023 год. В этом году у нас получается много работ со студентами ВШЭ на воркшопах, которые преобразуются в статьи. Также мы едем на первую для нас международную конференцию ECIR в Ирландию, где рассказываем про нашу статью. Впечатлений много, и мы по возвращении вкладываемся в еще одну работу, и ее тоже принимают на RecSys 23! Мы едем презентовать статью и Сингапур, оказываемся в международном RecSys коммьюнити. Также я удивляюсь, как много людей приехало из России от разных компаний: Сбер, Яндекс, Одноклассники, Дзен. В этом же году я поступаю в аспирантуру МФТИ на кафедру от Т-Банка. Статьи-то уже есть, и вроде их можно будет засчитать для защиты диссертации.
2024 год. Мы занимаемся RnD по RL&RecSys, о чем я рассказывал в докладе на Turbo ML Conf. Также у нас принимают статью по BPR на reproducibility track на RecSys 24 - полноценный full paper. Чуть позже мы пишем новую статью на ECIR 2025 по e-grocery рекомендациям, и вот, под конец года, получаем решение, что ее принимают! Параллельно у нас ведется и другая работа, о которой расскажу позже)
Итого, мой опыт с recsys research - это постепенное и довольно долгое развитие. Чем больше пишешь тексты статей, тем лучше и легче они получаются. Есть еще много идей и планов, одной из которых является написание и защита диссертации в МФТИ. Кроме этого, конечно, в recsys research есть еще много плюсов, но о них я расскажу в другом посте. | 835 |
| 4 | Offline vs online vs business metrics
Метрики качества можно считать в оффлайне на исторических данных или онлайне. Онлайн - это когда применяется оцениваемый алгоритм. В оффлайне на исторических данных применялось (или не применялось) что-то другое. NDCG@k, Recall@k, Precision@k, MAP@K и т.д. можно считать и в оффлайне и в онлайне. Beyond-accuracy метрики (diversity/coverage, и др.) в retrieval сетапе нет смысла делить на онлайн/оффлайн, но в ranking варианте из-за ограниченного множества айтемов, они будут другими.
Бизнес метрики - это все, что важно продукту (ctr/продажи/число лайков/retention, ...). Бизнес метрики алгоритма всегда считаются в онлайне. Но онлайн метрики - не бизнес метрики, а более широкое понятие.
Парадокс онлайн метрик ранжирования.
Пусть будут две модели "А" и "Б". Двум разным юзерам они порекомендовали некоторые айтемы, и первый юзер накликал по убыванию ранга [1, 0, 0, 0], а второй пользователь - [1, 0, 0, 1]. Первый юзер кликнул только на первый айтем, второй на первый и четвертый. NDCG у первого юзера 1, у второго <1. Recall@1 у первого - 1, у второго Recall@1=0.5. Получается, у первого юзера метрики ранжирования лучше, но если нам важно число кликов, то, очевидно, второй случай лучше, ведь там два клика. Поэтому, если важны клики, и метрики ранжирования считаются в онлайне, то этот парадокс надо учитывать.
Выиграть в оффлайн метрике не значит выиграть АБ-тест
Основной подвох в том, что если модель А лучше модели Б на какой-то оффлайн метрике, то на онлайн тесте модель А может заминусить бизнес метрики. На это есть множество причин. Можно пробовать искать такую оффлайн метрику, рост которой будет означать увеличение нужной бизнес метрики. Например, доклад от Тихонович Даши. Но если ваши оффлайн метрики не коррелируют с АБ, то тогда под вопросом вообще необходимость оффлайн оценки метрик качества. В retrieval сетапе оценить двух кандидато-генераторов и заметить отличие по точности в два раза, скорее всего, нужно и полезно. Увидеть увеличение в ranking сетапе на 3% и запускать АБ-тест - уже сомнительно, зависит от продукта. Эта тема заслуживает отдельного поста.
Источник сбора ground truth и "просмотров" могут быть важнее, чем выбор метрики
Супер важно понимать, какие именно интеракции вы заложили на ground truth. Есть открытый датасет Movielens, там есть рейтинги от 1 до 5. Если взять все рейтинги в качестве ground truth, то вы будете оценивать, насколько модель хорошо предсказывает фильмы, которым человек поставил рейтинг как 5, так и 1. И "лучшей" может оказаться модель, которая нарекомендует фильмы, которые человек оценит на 1. Поэтому лучше брать только те интеракции, где человек ставил 4-5, и оценивать модели только с точки зрения точности таких рекомендаций. Другой пример: пусть есть данные просмотров фильмов в формате (user, item, timstamp, duration), и мы строим next-item prediction модель. Если мы на тесте оставим такие интеракции, что пользователь посмотрел фильм 1 минуту, то "хорошая" модель должна будет уметь такой фильм рекомендовать. Но точно ли это нам надо?
Итого:
Важно знать формулы метрик, упомянутых выше. Но еще важнее понимать, зачем и на основе каких данных нужно их считать. Метрики - это лишь инструмент, который эффективен только в случае хорошего понимания его области принимости. Также, возможно, позже напишу подробнее про проблему корреляции оффлайн-онлайн метрик | 1 026 |
| 5 | Метрики оценки качества рекомендательных систем: что мне кажется важным
В этом посте я собрал основные накопленные мною знания и сгруппировал их по основным концепциям.
Accuracy vs beyond-accuracy метрики:
Accuracy измеряет, насколько точно алгоритм предсказывает "ground truth". Ground truth - это пары user-item, которые действительно встречались в данных, то есть было взаимодействие между user-item.
Beyond-accuracy - это такие метрики, которые важны "после точности" (=при прочих равных). Если две модели дают одинаковые метрики точности, но вторая умудрилась рекомендовать менее популярные айтемы/более разнообразные категории - она, скорее всего, лучше. Максимизация beyond-accuracy метрик важна при сохранении точности. Пример - если хотите выдавать разнообразные рекомендации, можно просто выдавать всем рандомные айтемы. Это даст максимальный результат, но вас вряд ли это устроит.
Между accuracy и beyond-accuracy обычно есть размен (отдаешь точность, повышаешь новизну). Размен бывает разной степени выгоды, для примера советую глянуть статью Саши Петрова (таблица 3 и рисунки 4-5)
Основные метрики качества
Accuracy:
1) NDCG@K/MAP@K/MRR@K измеряют, насколько близко ground truth объекты находятся близко к началу списка.
2) Recall@k/precision@k/HR@K - метрики оценивают список из k элементов целиком (= метрика не поменяется, если внутри k элементов перемешать список)
Beyond-accuracy:
1) Diversity (разнообразие). Есть как минимум три вида: а) внутри списка одного юзера (чтобы не показывать айтемы только одного типа) б) про отличие рекомендаций между юзерами (то есть не показываем ли мы всем одно и то же), в) рекомендаций у одного юзера с течением времени (меняется ли у пользователя лента или нет)
2) Popular/novelty показывает, насколько популярные/новые айтемы в среднем рекомендуются. Если популярность меньше, от этого, как правило, много плюсов.
3) User/item Covarage показывает какая доля юзеров/айтемов используется и показывается
4) Fairness. Тут очень широкий смысл. Например, насколько айтемы одинаково хорошо рекомендуются? Правда ли, что у юзеров одинаково хорошая персонализация?. Например, рандомные рекомендации одинаково честны ко всем айтемам - они дают им одинаковый процент влияния. Есть интересный туториал.
5) Serendipity - насколько пользователя "удивляют" рекомендации. Как написано в обзоре на эту тему, нет точного понимания как это считать единым и единственно верным способом
Accuracy метрики важно знать, они достаточно точны в определениях. Beyond-accuracy метрики более обширны, их скорее следует понимать и уметь адаптировать под конкретную задачу. Не зря на fairness/serendipity есть по отдельному обзору. Также замечал, что Recall@k иногда считают по-разному (делят либо на min(k, |gt items|), либо на |gt items|), MAP@K иногда определяют двумя разными способами.
Retrieval vs ranking.
Глобально, метрики качества считаются в двух основных вариантах:
Retrieval оценивает качество генерации кандидатов, либо просто "угадывание" айтемов. Множество рекоендуемых айтемов - максимально возможное (весь каталог, или то, что может порекомендовать модель). Ground truth - это реальные интеракции пользователя, и их надо угадать. Но ключевое: модель может порекомендовать юзеру все что угодно.
Ranking. У нас есть сэмплы user-item-timstamp-label. Это могут быть просмотры какой-то ленты, или просто факты того, что юзер видел. Задача алгоритма - отранжировать items из этого множества, чтобы вверху оказались полезные действия (клики/лайки/покупки). Отличие от retrieval: в ranking сетапе модель ранжирует только те айтемы, которые юзер, скорее всего, видел, и множество айтемов сильно сужено.
Иногда в статьях делают negative sampling для оценки метрик. Берут позитивный айтем, и рандомно/по популярности 100 айтемов из каталога. Ранжируют одно против другого. Это может привести к плохим последствиям (вы неверно найдете лучшую модель), и в моей парадигме это как раз "ranking". | 937 |
| 6 | Мой ТОП-10 проверенных и популярных моделей RecSys.
Для меня модели рекомендаций начинаются с тех, которые можно построить на данных формата (user_id, item_id, timestamp). Если у вас есть такие наборы данных, то с помощью следующих моделей можно составить список персональных рекомендаций для каждого пользователя внутри датасета. Этот список я составил по субъективной популярности и уверенности в том, что модели проверены временем:
1. iALS (2008, 4к+ цитирований) - масштабируемая на большие объемы данных матричная факторизация. Крупные компании в РФ часто упоминают ее как кандидатогенератор, рассказывают про различные трюки с оптимизациями. Скорее всего, про ALS на собеседованиях хотят слышать в первую очередь.
2. EASE (2019, 250+ цитат) - моя любимая модель. Один гиперпараметр, решение в явном виде. Моделька - матрица весов item*item. Топ-1 модель по мнению авторов из Сбера. Мы взяли первое место на Hack the cart, используя только эту модель. Ее минус - большие каталоги айтемов, но на них можно использовать ELSA или SANSA.
3. SLIM (2011, 900+ цитат) - аналог EASE. Матрица весов разреженная, зависимость от гиперпарметров более сильная, их больше. По качеству SLIM похуже EASE. С ней возиться сложнее. Однако, в силу разреженности матрицы весов есть и плюс. Помню, SLIM весил 100 Кб, а EASE около 600 МБ на одинаковых размерах.
4. MultiVAE (2018, 1350+ цитат) - модель от Netflix. Та самая, которая в обзоре are we really... выиграла SLIM и стала единственной нейронкой, которая это сделала. На вход модели идет только вектор интеракций, поэтому ее можно обучить на 1000 юзерах, а инференсить на 100к юзерах без дообучения - это прекрасно!
5. ItemKNN (2001, 13к+ цитат). Про этот алгоритм обычно не говорят на собеседованиях, так как "что-то на старом", а зря. У recsys есть open benchmark BARS, и на датасете Amazon Books ItemKNN занимает второе место среди многих моделей. И ни GCN, ни LightGCN, ни даже UltraGCN его не побеждают.
6. GRU4Rec (2015, 3400+ цитат). В 2019 году я занял 17/264 место в Rekko Challenge от Okko. Тогда я в первый раз обучил нейронку для рекомендаций, и это была GRU4Rec. Ожидния не оправдались, но для старта нормально. Кстати, недавно автор разобрал популярные ошибки в ее имплементации.
7. SASRec (2018, 2400+ цитат). Это трансформер для next-item recommendation. Основа основ для использования трансформеров в мире рекомендаций. Имеет множество расширений (TiSASRec).
8. BERT4Rec (2019, 1900+ цитат). Чуть лучше SASRec, например, по статье Саши Петрова. По опыту, часто нет смысла использовать SASRec и BERT4Rec вместе, лучше выбрать что-то одно.
9. LightGCN (2020, 3300+ цитат) - графовая сверточная сеть. В графе есть только юзеры и айтемы, модель оценивает связи user-item с точки зрения графа и делает рекомендации. На мой взгляд, крайне громоздкая, медленно обучаемая и негибкая модель, куда лучше ее улучшение в виде GFCF.
10. TIFU KNN (2020, 120+ цитат). Если в ваших данных есть повторные действия между юзерами и айтемами (например, покупки в супермаркетах), то, скорее всего, все модели выше проиграют по качеству TIFU KNN. Эта модель играет вокруг персональной частоты покупок пользователя. Если человек купил 100 раз молоко, именно TIFU KNN без проблем порекомендует его 101 раз и не ошибется. Остальные модели могут повторить персональные частоты, но все равно по качеству уступят TIFU KNN.
Мне кажется, если вы хотите ввести модель полноценно в свой инструментарий, надо сделать следующее:
✅ Прочитать оригинальную статью.
✅ Посмотреть ее имплементацию: какие идут данные на вход на трейне и инференсе, как данные идут внутри, что на выходе.
✅ Запустить модель на любом датасете, посмотреть за метриками, возможно, на рекомендации.
✅ Изучить гиперпараметры, посмотреть, как они влияют на модель.
✅ Повторить то же для расширений модели. Например, EASE -> ELSA, Lightgcn - GFCF и т.д..
✅ В идеале, применить на проде в АБ или в рамках соревнования.
Выучив все эти модели и пройдя чек-листы, уже можно уверенно ориентироваться в основных моделях, но на этом recsys не заканчивается, а только начинается) | 5 590 |
| 7 |  Мои три стадии понимания АБ-тестов в recsys
Пост про то, что в последнее время все больше и больше возникает вопросов к тому, как тестируются recsys модели в АБ-тестах. Я разделил свое отношение к ним на 3 стадии:
1) Концепция не знакома. На собеседовании на стажировку меня спрашивали, как сравнить две версии сайта, намекая на АБ-тест. Я не знал про такой подход, и на аналитика меня не взяли (зато взяли на ML 😃)
2) Концепция знакома. Прочитал статьи, запускал АБ-тесты. В каком-то виде знаю такие слова и понятия, как "p_value", "статзначимость", "гомогенность", "MDE", "ошибки I и II рода", "проблема подглядывания", "мощность теста". Все это применяется, на основе этого принимаются решения, в это есть вера. Знания и подходы соответствуют общепринятым стандартам сейчас
3) Концепция сомнительна, но окей. На этой стадии у меня есть вопросы к времени тестирования и к наличию даталиков.
Время тестирования. На эту тему много статей в интернете. Некоторые просто рекомендуют тестировать 2-3 недели. Другие предлагают рассчитать по ожидаемому эффекту размер выборки, а потом уже прикинуть количество дней. Такой подход хорош тем, что он универсален. Но в некоторых ситуациях смотреть нужно чуть шире:
а) допустим, мы тестируем RL-recsys модель, которая обещает долгосрочную оптимизацию пользовательского retention. Через сколько это "сработает"?
б) допустим, мы тестируем любую модель, которая за счет более классной персонализации увеличит retention, потому что у них произойдет "aha moment" в сторону качества персонализации или усилится привычка пользоваться сервисом. Через сколько это произойдет?
в) два тестируемых подхода (тест и контроль) рекомендаций - сложные системы, которые меняются сами и меняют пользователей. Об этом чуть позже напишу отдельным постом. Через какое время можно считать, что пользователи и модели уже достаточно устоялись в своих метриках?
Даталики. Даталиков в АБ-тестах recsys моделей, как минимум, два.
а) первый я узнал год назад из статьи от Netflix. Пусть есть две группы с моделями А и Б. Клиенты в группе А - 🔴, в группе Б - 🟡. Модель - функция от действий клиентов. Если у вас общий датасет для тренировки, то А(🔴🟡🟡🔴) и Б(🔴🟡🟡🔴) вы получите после каждого обучения. Клиенты 🔴 действуют в силу модели А, а клиенты 🟡 - в силу Б. Дальше вы признаете, что модель А лучше Б, и после отключения Б, вы получаете А(🔴🔴🔴🔴). Желтые клиенты превращаются в красных и действуют теперь по-другому. То есть вы приняли А(🔴🟡🟡🔴), а после раскатки получаете А(🔴🔴🔴🔴). Пример на "пальцах":
Модель Б отличается от А тем, что есть рандомные вставки айтемов (пусть это 🟢 действия). Вторая модель теряет метрики, но ищет новые интересы юзеров и находит Б(🔴🟡🟡🟢). Она "платит" за это падением релевантности. А первая модель, если вы ничего не делали специально, "бесплатно" делает тот же самый exploration А(🔴🟡🟡🟢). В таком сетапе, даже в случае "серого" теста, вы не сможете оценить ценность exploration. Пусть А > Б, но после раскатки вы получите не А(🔴🟡🟡🟢), а А(🔴🔴🔴🔴). Хотя, возможно, Б(🟡🟡🟡🟢) была бы лучше против А(🔴🔴🔴🔴).
Вы скажете - давайте сделаем 2 train набора для групп А и Б. Тогда а) скорее всего это время на разработку пайплайна раздельного сбора, б) это уменьшит каждую выборку, в) скорее всего останется период "общей части", если у вас train данные собираются за долго время, г) что если групп > 2?
б) Дальше хуже - если у вас бустинг и там есть CTR/Counter фичи, по-честному это тоже надо считать в разрезе каждой группы. CTR айтема в группе 1 и 2 по отдельности. На RecSys24 мы спросили у инженера из гугла - что делать с этим? Она сказала удвоить хранилище 🙂. Постер прикладываю.
Таким образом, сложно забыть все эти факты, и даже при соблюдении аналитических канонов верить так же в АБ-тесты, как на "стадии 2". Поэтому "сомнительно", но пока ничего не поделаешь, поэтому "окей" | 1 549 |
| 8 |  +5ACM RecSys 24: мои заметки, часть 1 (по первым двум дням)
Сейчас проходит главная международная научная конференция по рекомендательным системам, которая в этот раз проводится в Италии 🇮🇹. Я тоже тут, поэтому могу написать с места событий.
Интересные идеи из статей, которые, мне кажется, можно применить с невысоким риском или заставляют задуматься:
1) в EASE (моя любимая модель) на инференсе все веса применили по модулю (abs(w)) и получили хороший перформанс на top-n recommendation. А еще туда можно накидывать теперь негативы (например, просмотры без позитивов), но автор с просмотрами посоветовал быть осторожнее
2) EASE, конечно, хорош, но в нем нет контентой информации про айтемы. А вот beeFormer добавляет информацию о текстовом описании товаров в ELSA (аналог EASE). Нельзя сказать, что объединение контента и коллаборативной информации - что-то новое, но здесь есть проверенная модель ELSA, в которую аккуратно добавляют контентную информацию в end-to-end формате, что как минимум вряд ли испортит качество. А с другой стороны - возможно и правда получится улучшить его. Статья понравилась тем, что в ней нет сложных наворотов, идея становится понятна довольно быстро
3) Те, кто занимался item2item (i2i) рекомендациями, наверняка знают, что есть условно сопутствующие (complementary) и заменяющие (substitute) товары. Однако совстречаемость не значит комплементарность. Люди могут покупать часто молоко и борщ вместе, они будут совстречаемыми, но не комплементарными. Добавив борщ, вы вряд ли захотите добавить молоко. Поэтому на странице борща вряд ли стоит рекомендовать молоко. В этой статье подсветили, что если вручную рзметить комплементарность, то модели на основе совстречаемости не смогут и на половину догнать идеальную разметку. А на деле это значит, что, делая i2i через совстречаемость, будут сайд эффекты в виде рекомендаций молока к борщу.
4) "с языка сняли" - это про ресерч датасетов в recsys. Вот есть user-item-timestamp датасеты: movielens/amazon и прочие. Я давно думал над тем, что между ними может быть общее. Что если мы будем знать, что частный датасет (с которым вы работаете на работе) из компании - на самом деле похож на MovieLens по свойстам? Тогда можно найти SOTA модель на Movielens, и сразу заводить ее - это сократит время на разработку и эксперименты. Вот тут авторы построили пространство датасетов recsys, где каждая компонента - метрика какого-то алгоритма. Если два датасета в этом пространстве похожи - значит эксперименты можно проводить только на одном датасете (логично). А если вы сразу правильно помапите свой проприетарный датасет на open-source - можно будет найти наилушую модель, не проводя эксперименты. Сюда же добавлю статью от Сбера, где проверили - а есть ли в данных последовательная природа? В видео может быть важно смотреть серию №2 после серии №1. А если вы собираете корзину товаров в супермаркете - тут последовательность уже вряд ли важна. Эти две статьи не про новые модели, а про углубление понимания recsys - а что вообще происходит в данных.
5) Одна из моих целей - найти что-то по LLM4RecSys, что можно использовать в реальной задаче (масштабируемо, окупится, несложно попробовать так как высокие риски). Прочитал статью от Youtube, и советую вам, если преследуете ту же цель. В отличие от обилия академических статей по LLM4RecSys, тут авторы подробно описывают, как они применили и извлекли реальную пользу из LLM для Youtube Shorts (видимо). Взяли кластеры видео, их у них 761. Юзеры представлены набором из двух кластеров. LLM предсказывает, какой кластер новый можно порекомендовать по двум заданным кластерам пользователя. Например, я смотрел [видео по recsys, видео про науку] -> [мне порекомендуют через LLM видео про Италию]. Дальше любой способ, который достанет по кластеру видео - можно пробовать. В итоге, вырастили exploration новых интересов юзеров. Наконец-то что-то, что можно попробовать, и не получится сказать, что такое нельзя использовать в проде, потому что у нас много данных
Часть статей положил в беклог и разберу позже. Также в аттаче фотографии, чтобы поделиться атмосферой | 1 205 |
| 9 | Это первое сообщение в канале. Я назвал его так, потому что часто вокруг слышу про персонализацию. На это есть две причины:
1) Я связан с рекомендательными системами уже более 5 лет, так как работаю в этом направлении.
2) При условиях роста количества контента, данных, развития интернет-сервисов, растет необходимость учесть все имеющиеся данные и показать пользователям как можно более релевантный контент.
В изначальной идее канала, я хотел бы постить контент на следующие темы:
1) какие новые статьи выходят по рекомендательным системам или в целом персонализации, которые заслуживают внимания
2) что рассказывают компании в РФ и в мире про свои рекомендательные системы
3) подборки статей/докладов/фактов на определенные темы по рекомендациям, которыми мне интересно поделиться
4) выжимки по некоторым темам, которые, как мне кажется, важно знать при работе с recsys
5) прочие темы вокруг мира recsys: анонсы конференций, доклады, разборы, мысли, обсуждения и тд
Надеюсь, будет полезно | 818 |
