Мой ТОП-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 не заканчивается, а только начинается)

Мои три стадии понимания АБ-тестов в 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". Поэтому "сомнительно", но пока ничего не поделаешь, поэтому "окей"

#ml #recommender

#dl #llm

#systemdesign #interesting

#career #softskills

Советы для CDO - Part #1
Обзор книги Carruthers, Jackson - The Chief Data Officer's Playbook

Прочитала CDO Playbook и хочу поделиться моментами, которые показались интересными.

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

Итак, что - по мнению авторов - важно понимать, если вы CDO.

Общее - про выстраивание работы в целом:

- Не бывает много коммуникации: прогресс, фидбек, объяснения. Ты не обязательно должен делать работу в совершенстве, но все должны быть в курсе о том, что ты делаешь.

- Первое дело в работе CDO - понять бизнес. При проведении интервью спрашивать не про дату, а про проблемы в бизнесе. И, отталкиваясь от них, предлагать решения на основе данных.

- Для успеха надо вовлекать людей в активности, и особенно искать евангелистов своих идей в бизнесе. Много маленьких поддерживающих армий лучше одной большой. Это становится очень важным при внедрении изменений: одна коммуникация на всех про новые правила не приведёт к результату. Много индивидуальных коммуникаций и продажи своих идей с учётом особенностей и интересов стейкхолдеров даёт сильно больше результата. И развивается и помогает в долгосрочном периоде.

- Важно не увлекаться the empire-building trap. Дело, в первую очередь, не только в том, сколько у вас людей, а в том, какое value вы можете принести.

- Лучше недокоммититься и принести больше, чем наоборот. Это должно быть в основе. Такая вот непреложная истина 😄

Про роль CDO и немного про дата офисы:

- Авторы выделяют два основных типа CDO с точки зрения их роли в компании: first CDO и second CDO. FCDO это risk-averse чувак (фундамент пирамиды), а вот SCDO - это value-add чувак (монетизация данных). Первый должен выстроить технологический и архитектурный фундамент + запустить процессы data governance, но и не забыть про квик вины, ибо ожиданий у бизнеса от роли будет много, так как инвестируют в неё тоже много. Второй CDO - больше рискует и очень плотно общается с бизнесом, а бизнес по идее уже понимает на опыте первого CDO, что от улучшения технологий можно подвинуть границы возможного.

- Нужно понимать, какого типа ты CDO, какие навыки в тебе сильнее. Как минимум, технические (и какие), навыки управленца, бизнес-ориентированности и понимания бизнес-процессов. Слабые стороны нужно подкреплять союзниками и наймом людей. И постоянно анализировать, всё ли ок. Нельзя предавать себя. Стоит понимать, кто нужен организации, и идти туда, где будут применяться твои сильные стороны.

- При централизованной структуре чаще всего бизнес теряет оунершип над развитием дата дривен проектов. Считает, что дата должна все делать сама, а так не бывает.

- Data literacy. Обязательно должна быть база по данным у всех - понимание данных, способность их правильно понимать, уметь интерпретировать и аргументировать свою точку зрения по ним. В компании чаще всего есть значительный слой data unaware людей. В них кроется золотая жила, CDO нужно работать с ними. Они могут дать много value и идей использования данных, когда получат базовый уровень грамотности данных. При этом нужно учитывать, какой уровень грамотности нужен на каких уровнях: операционная деятельность, тактическое принятие решений, стратегическое принятие решений. На операционном важно уметь быть информированным, уметь читать данные, т.е. иметь базовые навыки. На тактическом и стратегическом нужны более индивидуальные программы обучения, плюс обязательно совместная работа с CDO над вовлеченностью к работе с данными - зачем мы это делаем, что можем классного получить.
Важно мониторить и работать над тем, чтобы на всех уровнях развивать нужную степень грамотности данных, и их использования. Плохо, когда на стратуровень поступают классные выверенные данные, но не используются, и плохо, если используются невыверенные.

Вот такие заметки. Будем рады обсудить в комментариях ваши мысли.

Во второй части обзора напишу про рекомендации для бизнеса - как найти себе подходящего CDO.

Ваш @Reliable ML

#business #обзор_книги #cdo

Как поймать прод, если он падает?

Я уже писал о том, как подготовиться к инцидентам на проде, чтобы, если это вдруг произошло, не терять время и разрешить быстро.

Сегодня разберем, что делать, когда инцидент уже просходит, и, например,
- у сервиса отпал регион
- трафик на платформу клиент перестал фильтроваться
- произошел резкий скачек QPS входных запросов, ваш кластер машин не вывозит
- latency резко увеличился и не хочет уменьшаться etc.

1️⃣ Для начала, сразу после того, как вам пришло уведомление, или вас пинганул менеджер, оцените ущерб (или по-модному blast radius). Для таких целей у вас должен быть доступ в аналитическую БД, куда аггрегируются ивенты (по аукционам, пользователям, минутам, регионам), и где вы можете, написав SQL запрос, оценить, на каком регионе, клиентской DSP, сегменте пользователей имеет место инцидент. А еще лучше для таких целей иметь уже готовый дашборд с основными аггрегатами и группами.

2️⃣ После того, как оценили ущерб, определяем состояние сервиса:
- operational: работает, возможно с небольшой долей ошибок
- degraded performance: значительная доля ошибок, ухудшен пользовательский опыт, ухудшено качество ML моделей, но основные сценарии работают или резервные (fallback) модели подхватили трафик
- partial outage: часть функционала отпала, отпал регион, полностью не отправляются запросы на конкретные DSP
- major outage: все полегло

После того, как оценили состояние, эскалируем инцидент своему менеджеру и команде инфры

3️⃣ Локализуйте проблему. Постарайтесь определить, из какого сервиса происходит причина инцидента. Если причина на сервисе, куда вы ранее не контрибьютили, пингуйте соответствующие команды, чтобы они подключились и проверили свои зоны ответственности.

4⃣️️️️️️ Пока ищется причина инцидента сфокусируйтесь на том, чтобы оживить прод (по-модному stop bleeding) - проверьте, какие были крайние коммиты, связанные с ошибками, и откатите их.

Если проблема в новых артефактах, которые кеширует сервис, то зачистите кеш (если у вас есть доступ) и перезалейте рабочие или fallback артефакты.

Если проблема в повышенном использованием CPU/ RAM от выброса трафика, upscal'ите машины на кластере

Детально исследовать, что именно привело к инциденту можно уже после - когда проблема решена.

5️⃣ Если все разрешилось - продолжайте мониторить и составьте postmortem. В нем укажите
- Оцененный ущерб
- Проанализируйте причину, почему так произошло
- Укажите ваши действия, и в какие сроки вы их предприняли

Что делают в это время менеджеры и аналитики?
- помогают связаться со стейкхолдерами (чтобы те были в курсе происходящего и могли со своей стороны что-то сделать - например, включить fallback) или нужными командами разработки
- смотрят на метрики и помогают оценить ущерб и в целом состояние приложения
- помогают эскалировать в нужную команду

Также рекомендую хорошую статью, как поднимают упавший прод на Ozon'е