Персонализация неизбежна

3 CIKM short papers + 2 RecSys demos 🎉 и немного новостей русскоязычного RecSys Последние дни получились довольно насыщенными на хорошие research-новости: у нашей команды в Т-Банке приняли 3 short papers на CIKM 2026 и 2 demo papers на RecSys 2026 🎉 Про CIKM уже немного заспойлерил Кирилл: там у нас работы про evaluation, graphs и linear autoencoders. Про одну из RecSys demo расскажем чуть позже — небольшой спойлер: там будет встречаться DCN 🙂 А вторая — это наш open-source фреймворк Perseus, который вчера приняли в Demo Track RecSys 2026. Для нас это особенно приятно, потому что Perseus мы разрабатываем уже около двух лет: начинали с простых SASRec-like подходов, год назад концептуально рассказали о фреймворке на Practical ML Conf, недавно выложили фреймворк в open source, написали про него на Хабре и рассказали на Turbo ML Conf. Но не хватало ещё одного кирпичика — валидации со стороны международного research-сообщества. Теперь он появился 🙂 Вообще последние недели получились очень насыщенными на recsys-новости не только у нас. За последнюю неделю увидел много репортов о новых статьях ребят из русскоязычного recsys-коммьюнити, принятых на осенние конференции CIKM 🇮🇹 / RecSys 🇺🇸: у Саши Петрова (пост), Даши Тихонович (пост), Евгения Фролова (пост). Если кого-то забыл — напишите, пожалуйста. Совсем недавно закончился SIGIR 🇦🇺, где точно были ребята из VK со статьями, а прямо сейчас проходит KDD 🇰🇷, куда, по сообщениям Кирилла, приехали 70+ русскоговорящих участников. На KDD приехали и мои коллеги из Т-Банка — они презентуют статью с бенчмарком recsys-моделей на одном из самых больших открытых датасетов — 135B взаимодействий. Была проделана огромная работа по анонимизации и зашумлению данных. При этом в статье показано, что относительный порядок recsys-моделей по качеству сохраняется между открытой синтетической версией датасета и настоящими оригинальными данными. Поэтому хочется верить, что датасет будет полезен коммьюнити для бенчмаркинга recsys-моделей и разработки новых алгоритмов. На внутреннем аналоге T-ECD мы, кстати, два года назад и начали развивать идеи, которые в итоге привели к Perseus. Если очень кратко, то у меня есть три основных тезиса про фреймворк: 1. Perseus покрывает простые сценарии типа SASRec на MovieLens-1M. Но для такого это, конечно, стрельба из пушки по воробьям. 2. Через Perseus, скорее всего, можно реализовать большинство прикладных offline-сценариев использования трансформеров для рекомендаций. Иногда я слушал доклады по recsys и ловил себя на мысли: «ну да, это можно реализовать через Perseus». Если вы сможете описать релевантный сценарий, который Perseus не покрывает, — будет очень интересно 🙂 3. Главное преимущество Perseus проявляется, когда у вас есть разнородные данные о пользователе с разными схемами. Например, покупки товаров, просмотры фильмов, отзывы об отелях, посты в соцсетях. Всё это можно упаковать в одну последовательность событий пользователя. Фреймворков, которые позволяли бы достаточно универсально работать с такими разнородными последовательностями, мы в открытом доступе не нашли. Поэтому и сделали Perseus. Подробнее всё описано в статье на Хабре. Надеюсь, кому-нибудь фреймворк понравится и принесёт реальную пользу. Если у вас появится сценарий применения, вопрос или фидбек — пишите в комментарии или в лс @lashinin, будем очень рады!

+1 short paper на RecSys 2026! Давно ничего не писал, но наконец-то появился хороший повод. Нашу с коллегами из Т-Банка статью приняли на ACM RecSys 2026, которая осенью пройдет в США. В этом году приняли только 27 из 152 short papers — около 18%. Поэтому пройти этот отбор особенно приятно! Статья посвящена масштабированию линейных автоэнкодеров на каталоги больших размеров. Надеюсь, она станет достойным продолжением линии: EASE → SANSA → L³AE → наша модель. Больше подробностей о нашей модели пока раскрывать не буду, но немного расскажу, почему линейные автоэнкодеры вообще интересны. Есть классический EASE — линейный автоэнкодер, который учит связи между айтемами по истории пользовательских взаимодействий. У модели есть аналитическое решение, а на практике она остается очень сильным бейзлайном, который сложно победить даже более сложными архитектурами. При этом возникает естественная идея: использовать не только item ID, но и текстовую семантику айтемов. Например, получить для каждого айтема embedding с помощью языковой модели и обучать представления так, чтобы они отражали сходство пользовательских взаимодействий. Именно такую идею я впервые увидел в beeFormer в 2024 году — кажется, это была первая RecSys-модель на Hugging Face, которую я встретил. Результаты в статье выглядели очень впечатляюще: Но затем для меня вскрылась серьезная проблема, которую я называю «проблемой 100 батонов» — видимо, потому что я долго работал в grocery-домене. Представим, что в каталоге есть 100 товаров с разными item_id, но очень похожими названиями: «батон», «батон белый 200 г», «батон нарезной 500 г» и так далее. Для языковой модели эти товары будут очень близки, поэтому модель без полноценного item-ID-сигнала может почти не различать их. При этом в реальности один батон уже может быть снят с продажи, второй — продаваться редко, а третий — быть популярным. Но семантическая модель присвоит им близкие скоры. В результате ей будет сложно выбрать правильный SKU: либо сразу несколько похожих товаров попадут в рекомендации, либо все туда не попадут. Отсюда возникают две практические проблемы: 1. Страдают offline-метрики: модель не угадывает конкретный item_id, который оказался в тесте. 2. Рекомендации становятся однообразными: без дополнительной диверсификации пользователь действительно может увидеть условные 100 батонов подряд. А вот item-ID-based EASE различает эти товары через их собственные паттерны взаимодействий и поэтому лучше учитывает разницу в популярности похожих айтемов, и "конкретном графе совстречаемости". Однако это не означает, что LLM-эмбеддинги айтемов еще никуда не прикрутили. Интересный вариант предлагает L³AE: модель сохраняет отдельные item ID-based item-to-item-матрицу, но добавляет семантическое сходство айтемов как регуляризацию. То есть семантика не заменяет behavioral signal, а дополняет его. И сколько бы я ни думал над тем, как отказаться от item-ID, и не столкнуться с двумя проблемами выше - пока ничего не придумалось. В общем, скоро надеюсь поделиться свежими наработками на эту тему!

Моё решение — 5/216 место на VK RecSys Challenge LSVD Мне было интересно снова поучаствовать в соревновании, чтобы проверить некоторые идеи, поучить Polars и поразвивать интуицию вокруг RecSys. Ниже кратко напишу про результаты. Задача: нужно было предсказать 100 пользователей, которые лайкнут клип VK Видео, причём с самим клипом в истории нет взаимодействий. Бейзлайн: будем «рекомендовать» тех юзеров, которые уже лайкали автора в прошлом. Сортируем по сумме лайков. Это уже ~30/216 место. Решение: возьмём всех юзеров, которые видели автора клипа, и отсортируем их с помощью LGBMRanker. Подробнее — в презентации. Чего было у тех, кто выше, но не было у меня: трансформер, DCN, SANSA, CatBoost. Я не смог это качественно заиспользовать. Чем хочется поделиться: 1) Я использовал идею из поста 2023 года канала Wazowski Recommends с экспоненциальными счётчиками, чтобы «переварить» все данные. Для расчёта фичей я использовал словари в словарях в Python с помощью кода на ~500 строк, который мне полностью написала ChatGPT. Грубо говоря, я пробежался for-циклом по всему датасету и с экспоненциальным затуханием насчитал все фичи без даталиков. 2) Всех юзеров я разбил по user_id % M == k и работал только с выбранной пачкой (простое шардирование), что позволило гибко настраивать trade-off «скорость vs RAM». Это был ключевой шаг, чтобы обработать все данные. 3) Я пытался искусственно побить клипы на кластеры по контенту и насчитать фичи, но это оказалось бесполезным занятием. У меня есть теория, что когда ты создаёшь группировку user/item на основе контента, но такой группировки не существует в самом сервисе, — это бесполезно для качества. Например, если мы рекомендуем продукты питания, у нас есть категоризация сервиса и фичи вида user–category. Категории существуют в каталоге → фичи значимые. Если же мы создадим semantic id и посчитаем фичи вида user–semantic-id, эти фичи дадут меньший эффект, чем user–category. 4) Задача подбора аудитории в целом — это во многом история про борьбу за активных людей. Если у вас есть приложение, в котором вы показываете баннер, и вы спросите: кто кликнет на него завтра? Я бы собрал аудиторию из самых активных пользователей приложения. Если отправлять email и собирать аудиторию, кто его прочитает, — это те, кто чаще всего читает email. Тут никакой RecSys / ML не нужен. И здесь есть тонкая грань между персонализацией и простой эксплуатацией самого активного ядра юзеров под любые нужды. Недаром авторы RecSys Challenge поставили ограничение, что нельзя выбирать одного юзера 101+ раз. 5) Соревнование для меня — во многом про аккуратность, правильную приоритизацию гипотез и доведение их проверки до конца. Также важны тайм-менеджмент, готовность полностью погружаться в эксперименты и терпимость к тому, что очередная идея не улучшает результат. В общем, участие оказалось очень полезным, всем советую попробовать себя в соревнованиях по Recsys)

Итоги 2025 года. Ровно год назад я сделал 9 предположений о том, что произойдет в мире рекомендательных систем в 2025 году. Сейчас стало интересно посмотреть, насколько они оказались точными. Некоторые пункты трудно оценить однозначно, поэтому опираюсь на собственное мнение. Посмотрим, что получилось. Не случилось ❌ : 1. Ждём RecSys Arena по аналогии с lmarena.ai! ChatGPT/Perplixity ничего такого не нашли. Понятно, что не так просто это сделать. Частично сама lmarena возможно содержит часть запросов на рекомендации, но это сложно оценить. 3. Наконец-то появятся open-source решения (модели + методы) для рекомендательных систем, которые достойно справятся с проблемой холодного старта. Вообще тут я скорее имел ввиду какие-то модельки по аналогии с NLP, которые берешь, распаковываешь и применяешь на своих данных. Для user-to-item рекомендаций такие модели, кажется, не появились. Есть beeformer с 2024 года, у которого 10 скачиваний за месяц. Очень интересная идея, но по нашим экспериментам плохо работает. 4. Рекомендательные системы и Поиск станут ещё ближе. Недавно коллеги из Яндекса делали обзор на статью GenSAR из Kuaishou про общую систему поиска и рекомендаций. Думаю, надо еще подождать, когда будет больше кейсов, особенно в продакшене. Случилось ✔️: 2. Уверен, что российские компании поделятся успешным кейсом внедрения LLM в продакшн-рекомендации с реальным профитом для бизнеса. Буквально под конец года был доклад от Сбера про контентный трансформер, куда добавили специальным образом выдачу от LLM по товарам и получили реальный профит в АБ (если я правильно запомнил все, когда будут запись, советую посмотреть). 5. Какой-нибудь NLP-проект научится давать действительно полезные рекомендации на сторонних сайтах, и люди начнут им пользоваться именно из-за этой крутой персонализации. Чуть неточно сформулировал, но в целом попал. Упомяну ChatGPT и встроенные рекомендации музыки от Spotify и сошлюсь на пост Саши Петрова: тот факт, что ChatGPT постепенно становится эдаким “единым” источником рекомендаций; кажется, еком-рекомендации они уже тоже подключили — как минимум, сделали интеграцию с Etsy и Shopify 6. В академической среде, по инерции, продолжат выходить статьи на основе MovieLens-1M… Это тоже было легко - наука все-таки имеет некую инерцию. В статье коллег из Сбера 2025 года, например, ML-1M присутствует 7. Персонализация будет не только про RecSys! Массово появились AI-сгенерированные шортсы, фотографии и музыка. Персонализированные новогодние открытки многие видели. Но особенно интересен контентный тренд: каждый может генерировать видео «под аудиторию» и заливать на площадки, где пользователи подписываются, и дальше получают персонализированный AI-контент в своих лентах. Похоже, это будет расти. 8. RecSys модели будут расти по размеру, количеству обрабатываемых данных и скорости этой обработки. Если не считать LLM как рекоммендеров, то специализированные модели действительно растут. В 2025 появился OneRec с 2.6B параметрами. Раньше обсуждали модели около 1B — теперь планка поднялась. 9. Российское RecSys сообщество продолжит активно развиваться. Формулировка размытая, но думаю можно зачесть: Трек RecSys на DataFest от VK, Practical ML Conf от Яндекса, Turbo ML Conf от Т-Банка, RecSys темы от Сбера, Fall into ML от ВШЭ, Митап от WB; соревнования от Ozon, Avito, VK по рекомендациям; Открытые датасеты от Яндекса, VK и Т-Банка. Также получилось много статей по recsys на международных конференциях: если чисто по аффиляциям, помню были Т-Банк, Сбер, Яндекс, ВШЭ, AIRI, МФТИ, Сколтех Если что-то забыл или упустил, готов обновить пост. Год получился насыщенным. Надеюсь, следующий будет еще результативнее. Уверен, что все девять пунктов останутся актуальными для 2026 года, а нового добавлять не буду. Всех с наступающим Новым Годом! 🎄

🎯 T-Meetup: RecSys — 27 ноября, 19:00, Санкт-Петербург Открыли регистрацию на наш митап по рекомендательным системам от Т-Банка — ссылка на регистрацию Митап пройдёт в новом офисе Т в Санкт-Петербурге, и в конце вас ждёт экскурсия по новому офису Т в СПБ 🏢 На митапе будет три доклада: 1️⃣ Роман Силаков, Т-Банк: Эволюция бэкенда рекомендательной системы: от офлайна до онлайна. Роман — руководитель группы RecSys Platform в Т-Банке. Сейчас команда активно двигается от батчевых офлайн-рекомендаций к онлайн-расчётам. Он расскажет, как мы шаг за шагом переводим все recsys-пайплайны в онлайн, с какими проблемами сталкиваемся и какие решения принимаем. 💡 2️⃣ Артём Посынкин, Т-Банк: Персонализация скидок и лояльности с помощью модели эластичности. Артём — исследователь-разработчик в команде RecSys-RnD. В прошлом посте я писал про “рекомендательные системы скидок и бонусов” и затронул тему данных и валидации экспериментов. Артём расскажет, как вообще подступиться к задаче определения чувствительности клиента к размером скидок, ценам и бонусам, какие методы для этого существуют и как они помогли нам провести успешные A/B-тесты 💪 3️⃣ Маргарита Мишустина, Яндекс: Подходы к замене ранжирующего бустинга на нейросеть: наш опыт. Рита расскажет, как в рекламной сети Яндекса (РСЯ) переходили от бустинга к нейросетевому ранжированию (DeepRanker). Если вы всё ещё используете бустинг для ранжирования — отличный шанс узнать, как перейти на следующий уровень качества 🚀 🎙 Ведущим митапа буду я. 📼 Запись будет, но трансляции не будет. 👉 Зарегистрироваться можно здесь: meetup.tbank.ru/event/recsys

Про "рекомендательные системы" скидок, бонусов, тритментов и пр. Все посты до этого были про персонализацию на больших каталогах (когда айтемов много). Но есть задачи по персонализации некоторых "стратегий" (или тритментов), в которых может быть очень много бизнес-профита (советую посмотреть статьи D. Goldenberg из Booking на RecSys 20/22 и др.). Например, вам могут принести задачу: "построить рекомендательную систему скидок в такси, чтобы она рекомендовала, какую скидку дать конкретному клиенту". Тут можно спорить о терминах — рек. система это или нет, — но персонализация явно может помочь. Датасет будет примерно такой: user_id, treatment_group (0%, 5%, 10% скидки), date, target Я сталкивался с 4 разными прикладными задачами из разных доменов, которые подходят под это условие. И можно было бы сэкономить много времени, если бы знал следующее: делать что-то хорошее можно только на рандомизированной раздаче тритментов (то есть вы сначала делаете рандомную раздачу, и поверх нее только обучаете модель). И вот почему: 1. Это важно для обучения модели. Если большую скидку давать тем, кто вряд ли закажет, а маленькую — тем, кто пользуется постоянно, то модель выучит контринтуитивную связь: Чем больше скидка, тем меньше вероятность, что человек купит → значит, всем надо дать маленькую скидку. Когда же тритменты назначаются случайно, появляется шанс выучить что-то адекватное. 2. Это важно для валидации модели. Задачи часто связаны с финансами, и очень важно корректно оценить стратегию по эффективности. Когда-то я долго гуглил тему "evaluation of multiple treatments" и нашел вот такую статью. Я показал её коллеге Вите Харламову (@xapulc) и очень удивился, когда через пару дней Витя прислал ~5 страниц математического текста с доказательством корректности метода при определённых условиях. Потом узнал, что Витя учится в аспирантуре ММ МГУ :) Вот ссылка на его пост, где он рассказывает про метод и в целом обещал продолжить писать на тему персонализации. Но иметь рандомизированную выборку дорого — её надо постоянно поддерживать для обновления модели; больший размер = меньше эффект от персонализации и т. д. Поэтому хочется использовать смещённые данные (а) для обучения и (б) для валидации. Сейчас думаю так: для обучения можно пробовать разные методы "устойчивые к смещению" (они легко гуглятся) — например, аккуратно добавлять смещённую часть данных к рандомной. Но вот валидацию моделей, насколько я знаю, можно делать только на чистом рандомном эксперименте. Если вы знаете другие способы — пишите в комментариях 👇

Про мой доклад на Turbo ML Conf 2025 Вчера выступил на конференции Т-Банка. Рассказал о том: - Как мы видим академический research с точки зрения продуктовой команды - Какие инсайты получили из продуктовой разработки (и чего не найдёшь в статьях) - Как преобразовали продуктовую проблему в статью про SMMR Ключевые тезисы: 1️⃣ Next-basket recommendation По нашим экспериментам — не увеличивает GMV. Чем точнее предсказываешь корзину пользователя: ✔️ Больше используют рекомендации ✖️ Но пропорционально меньше пользуются поиском и каталогом Есть надежды на uplift-рекомендации, но пока work in progress. 2️⃣ Формальный подход к фичам в ранкере Мы пришли к почти формальной методике: - Применима к любому сервису - Покрывает почти все значимые признаки - Позволяет генерировать тысячи фичей Алгоритм: 1. Расписать все степени свободы 2. Выделить приоритетные 3. Реализовать 📌 Очень похожий подход описывал Иван Брагин в докладе про 3 место на VK RecSys Challenge 3️⃣ "Нельзя выучить то, чего нет" Много докладов по recsys про более точные предсказания next item или улучшения трансформерных моделей. Но почти ничего про важное условие: это работает только при наличии персональных паттернов в данных Пример: ❌ Если дачники не покупали семена в сервисе → никакая модель не порекомендует семена дачникам ✔️ Частичное решение через LLM: статья YouTube 2024 Вывод: Качество рекомендаций = не только код, но и качество данных. Как сказал DeepSeek: "На доброй земле и крапива цветёт, на худой и рожь сохнет." 4️⃣ RL в RecSys: год спустя После прошлогоднего доклада "RL в RecSys: хайп или игра в долгую": 🔹 Пока склоняемся к "хайп" 🔹 Но продолжаем наблюдать за ситуацией

В России нашли способ ускорить и разнообразить сетевые рекомендации — Известия. Давно не писал, но вот наконец-то появился повод: мы вместе с коллегами приехали на ACM SIGIR (A* конф.) в Италию и уже сегодня презентовали нашу статью: SMMR: Sampling-Based MMR Reranking for Faster, More Diverse, and Balanced Recommendations and Retrieval. SMMR расширяет классический метод MMR (1998 г., тот же SIGIR). 📌 Как работают MMR/DPP? - На входе: список рекомендаций типа [a, b, c, d...] и "похожесть" айтемов (через векторные представления) - Принцип работы: исходные списки пересобираются заново по одному элементу, но теперь берется в учет как релевантность, так и потенциальное разнообразие при добавлении каждого нового айтема. - Пример: Было: [смартфон, смартфон, смартфон, мяч, утюг, смартфон] Стало: [смартфон, мяч, утюг, смартфон, смартфон, смартфон] - Результат: пользователь видит больше разнообразия в топе. Если в примере он долистает только до трех айтемов, то выдача будет полностью разнообразной по категориям. ⚡️ Наш вклад (SMMR): 1. Добавляем айтемы батчами, а не по одному. Так работает быстрее. Размер батча увеличиваем на каждой итерации. 2. Сэмплируем айтем на основе их ценности, а не каждый раз берем самый лучший. 📊 Что получили: • Скорость работы ↑ • Баланс качества/разнообразия ↑ • Обобщение MMR (при некоторых параметрах совпадает, но более гибкий) В общем, идея несложная, но работает лучше классических MMR/DPP. Во время постерной сессии получили много фидбека и вопросов. А про остальные интересные вещи на SIGIR расскажу позже и отдельно)

Наша статья принята на SIGIR (конференция уровня A*) 2025 🎉! Мы долго шли к этому моменту - и вот, наконец, наша с коллегами статья принята на SIGIR 2025, международную конференцию в Италии 🇮🇹! Это уже третья итальянская конференция за год, куда нам посчастливилось пройти. SIGIR (Special Interest Group on Information Retrieval) — по данным Вики, проводится с 1978 года. Конференция в целом посвящена информационному поиску: обычный поиск, рекомендательные системы, ответы на вопросы по базам знаний и т. д. Наша статья посвящена новому способу диверсификации (= внесения разнообразия) в выдачах. Он был придуман из практических соображений, после того как мы попробовали хорошо известные MMR и DPP. Про статью и наш метод напишу после публикации, пока же — пару мыслей про диверсификацию. Откуда возникает потребность в диверсификации? Представим, что у нас есть бустинг-ранкер, который ранжирует айтемы и формирует финальную выдачу. Скорее всего, важными окажутся следующие признаки: 1) Схожесть пользователя с айтемом. 2) Схожесть + счётчики взаимодействий между пользователем и категорией/жанром/типом айтема. 3) Схожесть + счётчики взаимодействий между кластером пользователя (соцдемом/другим) и категорией/жанром/типом айтема. 4) Счётчики по категории/жанру/типу айтема. Пусть среди айтемов-кандидатов есть 300 смартфонов. Тогда все 4 типа признаков у этих 300 телефонов будут примерно одинаковы! И если ранкер присвоит хоть одному смартфону высокий скор, то и остальным 299 смартфонам придётся выставить столь же высокие скоры (если другие группы фичей не позволят их различать). Теперь представим, что мы играем с пользователем в «Поле чудес». Пользователь загадывает слово (где буквы — его интересы), а мы угадываем его, предлагая айтемы в ленте. В этом случае лента с 300 смартфонами без диверсификации — это как если бы мы называли одну и ту же букву снова и снова. Даже если пользователь говорит «нет» (= не взаимодействует с ними), мы продолжаем предлагать ему ту же самую «букву». Чтобы использовать попытки разумнее, можно попробовать назвать что-то менее вероятное, но зато другое. Тогда шанс угадать вырастет. В целом, MMR и DPP — это эвристики, которые помогают «играть» в эту игру эффективнее, если у нас есть оценки релевантности айтемов и функции сходства между ними. Без таких эвристик система может составлять ленту из полностью однотипного контента, потому что обычно скоры рекомендаций рассчитываются для каждого айтема независимо. Когда модель рекомендует смартфон на 50-й позиции, она не знает, что выше уже было 49 смартфонов, и поэтому всё так же уверена, что 50-му нужно присвоить высокий скор. Кому интересно копнуть чуть глубже в моделирование для автоматической диверсификации - советую прочитать статью 2024 года от LinkedIn и статью про Generative Next-Basket Recommendation от Tencent (постер скину в комментариях). Однако на практике, кажется, пока не существует хорошего автоматического диверсификатора, который был бы широко распространён и не являлся бы эвристикой.

Пишите в комменты, если у вас есть какие-то мысли/возражения на этот счет. Или также если знаете хорошие ресерч статьи на эту тему, которые я пропустил)

Куда движется рекомендательная система? После некоторого времени работы с рекомендательными системами проблемы и подходы к их решению начинают встречаться повторно. Например, если есть проблема холодного старта, то есть и N докладов на эту тему, и M научных статей об этом. Иногда, однако, хочется подумать о великом, о чем, кажется, нет хороших и известных материалов на сегодняшний день. Об одной из таких дум пишу первый пост в 2025 году. Начнем с такого примера. Есть одна рек. система, которая регулярно обучается на свежих данных и показывается пользователям. Под системой буду иметь ввиду весь программный код, всех юзеров и айтемов, которые участвуют в системе. Посмотрим на нее сегодня (система "Н" = новая) и неделю назад (система "С" = старая). Дальше хочется сказать, что это две разные системы и подумать, правда ли что "Н" лучше, чем "С"? Что общего между системами "С" и "Н"? - Весь программный код, он не менялся. Какие есть интересные отличия между системами "С" и "Н"? - Пользовательский опыт взаимодействия с системой. Пользователь Вася неделю назад не делал клики вообще ни на что из каталога айтемов, а вчера сделал три клика где-либо. Система "С" не знала об этих трех кликах Васи, а система "Н" уже знает. - Статистики по айтемам. Скорее всего, для системы "С" и "Н" есть айтемы с высокими конверсиями, но списки отличаются между двумя системами. - Модели. Будь это нейронка или градиентный бустинг, их чекпоинты/веса будут отличны между собой. Причина: они обучались на разных датасетах, хоть и собраны одинаковым способом (кодом), но в разное время. Теперь представим, что есть система с плюс-минус стандартным пайплайном и фичами в модели, и она в целом работает неплохо. Если вернуть этот код во время начала проекта, когда люди кликали только на популярные товары из небольшого набора, то, вероятно, вся персонализация исчезнет. В обратную сторону, если проект только стартует, а данные не разнообразны, то даже если код достаточно хороший, он все равно не поможет сделать персонализацию. Однако через время именно этот код позволит получить достойные результаты. Поэтому на большом временном промежутке я точно уверен, что "С" и "Н" сильно отличаются, а значит, есть и малые промежуточные изменения. Осознав это, я стал думать, что система находится в постоянном движении. Дальше несколько вопросов, на которые я пока не нашел ответа: 1. Как распознать, стала ли система "Н" лучше "С", если мы с ней ничего и не делали? Может быть, следует изучить метрики ранжирования оффлайн/онлайн? Я с этим не согласен, так как на них влияют разные факторы. Может тогда провести АБ тест между "Н" и "С"? Тоже не считаю данный способ эффективным, ведь честный АБ дизайн почти не реализуем. 2. Что сделать, чтобы "Н" была лучше чем "С" при идентичности их кода? Забудем про то, что без ответа на вопрос №1 мы не сможем это оценить. Напихать околорандомные айтемы в ленты рекомендаций, чтобы случайно угадать интерес пользователя и за него зацепиться - это, кажется, единственный ответ, который приходит в голову. Но это эвристика, а значит может оказаться не самым хорошим решением. Да и вряд ли масштабно решает проблему. 3. Как описать движение системы на понятном для людей языке? Все оффлайн/онлайн метрики описывают системы "С" и "Н", но не описывают разницу между ними. Хотелось бы человеческого описания. Например, система "Н" заступила на прод в час ночи 13.03.25. Пользователи стали более разнообразно кликать на q%, что позволило вырастить количество обнаруженных интересов на w%. Это повысило значимость признаков X, Y, Z, что улучшило персонализацию на сегментах R и T. Система "Н" стала лучше персонализировать, потому что случились события а) ..., б) .... Для последующего улучшения предприняты действия A, S, D. Подобное описание, думаю, здорово бы помогло осознать, что вообще происходит. Еще один наброс: если система "Н" лучше чем "С" и принесет еще +x% метрик, то вы об этом не узнаете, ведь на это скорее всего нет АБ теста. В обратную сторону данная логика тоже работает 🙂

А теперь — мои прогнозы на 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 в Италии. Надеюсь, что в следующем году будет еще больше интересных ивентов. Посмотрим, что из этого списка сбудется к концу следующего года! 😉 Всех с наступающим Новым Годом! 🎄🎉

Подводим предновогодние итоги 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 было на удивление мало. Похоже, этому тренду нужен свежий импульс с прорывными идеями.