Рексистемы — одна из тех областей, где красивая теория очень быстро встречается с суровой реальностью продакшена

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Разберём типичный кейс, через который проходит почти каждая команда, которая берётся за рекомендации с нуля.

Стартовая точка: а что вообще рекомендовать?

Обычно всё начинается так: есть каталог (товары, видео, статьи, треки — назовём их обобщённо айтемы) и есть пользователи, которые с ним как-то взаимодействуют. Бизнес говорит: «сделайте, чтобы люди больше кликали/покупали/смотрели». И тут появляется первая ловушка — кажется, что задача про алгоритмы, а на самом деле она про данные.

Первые вопросы, на которые приходится отвечать:
➡️ Какие взаимодействия считать «положительными» — клик? Просмотр дольше 30 секунд? Покупка?
➡️ Как быть с неявным фидбэком, когда пользователь просто проскроллил, и непонятно, понравилось ему или нет, а может просто кот прошёлся по клавиатуре;
➡️ Что делать с новыми юзерами и новыми айтемами, про которых мы ничего не знаем? (знаменитая проблема cold start).

✅ Первая итерация: baseline, который очень простой, но нужный

Классика жанра — начать с чего-то максимально простого: топ популярного, топ популярного в сегменте пользователя или content-based (похожие айтемы по описанию/тегам).

Звучит скучно, но именно на этом этапе выясняется куча важного: где в логах дырки и пропуски, какие товары давно неактуальны и их вообще не стоит рекомендовать, и — сюрприз — что простой топ популярного уже даёт вполне приличные клики, и обогнать его сложными моделями не так-то просто.

✅ Вторая итерация: коллаборативная фильтрация и двухстадийная схема

Дальше обычно строится честная двухстадийная архитектура:

➖ Candidate generation — быстро отобрать сотни кандидатов из миллионов (ALS, item2item, эмбеддинги);
➖ Ranking — аккуратно переранжировать топ градиентным бустингом или нейронкой с добавлением фичей.

Именно здесь появляется ощущение «настоящей» рексистемы. И именно здесь всплывает вторая типичная ловушка — оффлайн-метрики не всегда хорошо коррелируют с онлайном. Знакомая история: NDCG на исторических данных подрос, а в A/B-тесте — тишина. Причин может быть много:

🔶 Выбрана не совсем та оффлайн-метрика под бизнес-задачу;
🔶 Сказывается смещение в обучающих данных, особенно если они собраны предыдущей версией рексистемы — привет, feedback loop;
🔶 Иногда дело в том, что рост качества модели просто не транслируется в поведение пользователя напрямую.

Поэтому в зрелых командах оффлайн-эксперименты воспринимают скорее как фильтр гипотез, а финальное слово всегда за A/B.

✅ Третья итерация: а что мы вообще оптимизируем?

Момент, когда команда понимает: максимизировать CTR — это прямой путь к кликбейту в выдаче. Пользователь кликает, но не досматривает, не возвращается, отписывается. Поэтому в продовых системах почти всегда появляется:

➖ Многокритериальная оптимизация (клик + удержание + разнообразие);
➖ Бизнес-правила поверх модели (не показывать одно и то же, поддерживать новинки);
➖ Контроль за разнообразием выдачи, чтобы пользователь не оказался запертым в «пузыре» из одного и того же типа контента.

Ещё раз кратко, что запомнить:
📌 Сначала данные и метрика, потом модель, а не наоборот;
📌 Простой baseline экономит месяцы — без него не с чем сравнивать;
📌 Offline-качество ≠ бизнес-эффект, финальный судья — A/B-тест;
📌 Рексистема — это не одна модель, а пайплайн из отбора, ранжирования и правил.

Рекомендации — та область, где инженерная аккуратность важнее модного алгоритма. И это, пожалуй, главный инсайт, который приходит с практикой ❤️

Сохраняйте, если было полезно!

Гайд: практическое применение алгоритмов ML

Знаете, как компьютеры могут учиться на данных и делать точные прогнозы? Благодаря алгоритмам машинного обучения — набору методов, которые позволяют компьютерам учиться на данных и делать прогнозы без явного программирования.

Подготовили для вас материал с обзором и примерами применения таких алгоритмов.

Что вы получите от нашего материала?

⭐️ 16 алгоритмов с реальными примерами кода, такими как прогнозирование стоимости недвижимости, классификация электронных писем как спам или не-спам и многое другое;

⭐️ Разберётесь в принципах работы алгоритмов и их практическом применении. Вы узнаете, как использовать их для автоматизации рутинных задач и улучшения процессов принятия решений;

⭐️ Узнаете, как использовать эти алгоритмы для решения реальных задач в бизнесе, науке и других областях. Это может существенно повысить эффективность ваших проектов и дать вам конкурентное преимущество.

✅ Получить материал

Встроенная магия Jupyter и библиотека importlib

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Знакомая ситуация: пишете код в .py-файле, импортируете его в ноутбук, находите баг, правите — и ничего не меняется, пока не перезапустишь ядро и не потеряешь все переменные из памяти 😩 Сегодня про то, как это лечится в две строчки.

Разберём сразу два подхода — встроенную магию Jupyter и библиотеку importlib. Оба решают одну задачу: подхватывать изменения в модулях без перезапуска ядра. Но работают они чуть по-разному, поэтому полезно знать оба.

Способ 1: магические команды %load_ext autoreload

Это самый удобный вариант для повседневной работы. В начале ноутбука пишем две строчки:

%load_ext autoreload
%autoreload 2

И всё — теперь при каждом выполнении ячейки Jupyter будет автоматически перечитывать все импортированные модули, если в них что-то поменялось.

Что означают режимы:
➖ %autoreload 0 — выключено;
➖ %autoreload 1 — перезагружаются только модули, импортированные через %aimport;
➖ %autoreload 2 — перезагружаются все импортированные модули (то, что нужно в 99% случаев).

Типичный сценарий использования:

%load_ext autoreload
%autoreload 2

from my_project.features import build_features
from my_project.models import train_model

X = build_features(df)         # запустили
# ... идём в features.py, правим build_features ...
X = build_features(df)         # уже работает новая версия, ядро живо

Все переменные (df, обученные модели, загруженные датасеты) остаются в памяти. Магия ✨

Способ 2: importlib.reload — когда нужен контроль

autoreload штука удобная, но иногда мешает: например, если модуль тяжёлый и вы не хотите перечитывать его каждый раз, или если работаете вне Jupyter. Для таких случаев есть встроенный модуль importlib:

import importlib
import my_project.features as features

# ... правим features.py ...

importlib.reload(features)
X = features.build_features(df)

Работает надёжно, но есть нюанс — если вы делали from my_project.features import build_features, то после reload старое имя build_features продолжит указывать на старую функцию. Нужно либо переимпортировать явно:

importlib.reload(features)
from my_project.features import build_features   # обновили ссылку

…либо изначально импортировать модуль целиком (import features + features.build_features(...)), а не отдельные функции.

Итог: что когда что использовать

📌 %autoreload 2 — дефолт для исследовательской работы в ноутбуках, ставим в первую ячейку и забываем;
📌 importlib.reload — когда autoreload конфликтует с чем-то (иногда бывает с C-расширениями, декораторами, dataclass-ами) или когда нужен точечный контроль;
📌 Комбинация — тоже вариант: autoreload 2 для большинства обычных модулей, а %aimport с режимом 1 для тяжёлых, которые дорого перечитывать.

Сохраняйте, чтобы не потерять ❤️

Кажется, что задача сегментации — это просто. Но самое интересное появляется после обучения моделей, когда возникает главный вопрос: «N кластеров получили… и что дальше?» 😄

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Сегментация — задача, которая почти всегда живёт на стыке ML и бизнеса, и именно поэтому в ней столько подводных камней. Разберём типовой сценарий.

✅ Стартовая точка: зачем вообще сегментировать?

Первая и главная ловушка — начать кластеризовать без чёткого ответа на вопрос «что мы потом будем делать с сегментами?». Подобные истории почти всегда максимум заканчиваются красивой презентацией, которая пылится в архиве.

Возможные цели могут быть совершенно разные:

➖ Персонализировать коммуникации (например, разные письма разным группам);
➖ Построить продуктовые предложения под конкретный сегмент;
➖ Найти «спящих» клиентов, которых можно реактивировать;
➖ Понять, кто приносит основную выручку, а кто — основные затраты.

И под каждую цель — свои признаки, своя гранулярность, свои требования к интерпретируемости. Универсальной «правильной» сегментации не существует.

✅ Первая итерация: baseline через бизнес-правила

Прежде чем доставать K-Means и DBSCAN, полезно построить сегментацию руками — по простым правилам. Классический пример — RFM-анализ (Recency, Frequency, Monetary): разбиваем клиентов на группы по трём осям и получаем понятные сегменты вроде «новички», «лояльные», «уходящие», «VIP».

Плюсы такого подхода — легко объяснить бизнесу, легко воспроизвести, и сразу видно, что делать с каждой группой. И часто оказывается, что этого уже достаточно, а сложная кластеризация не даёт заметных улучшений.

✅ Вторая итерация: кластеризация и её ловушки

Когда бизнес-правил становится мало, в ход идут алгоритмы. И тут вылезают типичные грабли:

➖ Выбор признаков важнее выбора алгоритма: сегментация по «сырым» фичам почти всегда даёт мусор. Нужны продуманные агрегаты: частота, средний чек, доля категорий, поведенческие паттерны;
➖ Масштабирование обязательно, иначе одна большая по значениям фича задавит все остальные;
➖ Число кластеров: метрики вроде коэффициента силуэта и метода локтя помогают, но финальное слово всегда за интерпретацией: если 5 кластеров осмысленны, а 8 — нет, берём 5;
➖ Проклятие размерности: на большом числе фичей расстояния «схлопываются», и почти всё оказывается одинаково далёким друг от друга. Спасают снижение размерности (PCA, UMAP) и отбор признаков.

✅ Третья ловушка: сегменты, которые нельзя объяснить

Допустим, кластеризация отработала, выделили N групп. И дальше наступает самый интересный момент — надо объяснить бизнесу, кто это такие. Если сегменты не поддаются простой интерпретации («вот эти — экономные семейные, а вот эти — импульсивные молодые»), то результатом невозможно пользоваться.

Полезные приёмы для интерпретации:
➖ Посмотреть на средние и медианы ключевых признаков по кластерам + в сравнении с общим средним;
➖ «Портреты» типичных представителей каждого сегмента;
➖ Дерево решений, обученное предсказывать метку кластера — оно буквально выдаёт правила, по которым сегменты отличаются.

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

Сегментация — редкий случай, когда самый большой прирост даёт не улучшение модели, а улучшение постановки задачи ❤️

Сохраняйте, чтобы не потерять!

Привет! На связи Мария Жарова, ML-инженер команды рекомендаций в Wildberries и ментор курса «ML-инженер» 👋🏻

Задумывались, чем ML-подход отличается от обычной разработки и что вообще происходит «под капотом», когда компьютер сам находит закономерности в данных, а не работает по прописанным правилам? Приходите на мой вебинар — разберём это на реальных примерах.

Разберём три вещи:

➖ Чем ML-подход отличается от обычной разработки — на примере того, как устроен поиск;
➖ Где ML реально работает в индустрии — беспилотный транспорт, голосовые помощники, генеративные сети, рекомендательные системы, финтех, медицина — и какие тренды у профессии в 2026 году;
➖ Прямо на вебинаре обучим модель оценивать стоимость недвижимости по реальным данным и соберём из неё интерактивное приложение.

Если хотите понять, как устроена работа ML-инженера и что реально нужно знать на старте — приходите!

📆 22 июля, 19:00 МСК, онлайн
➡️ Ставьте напоминание в календарь, чтобы не забыть!

Классификация — одна из первых задач, которую почти каждый кладет в свое портфолио ML. Кажется, что здесь всё просто, но это пока не начинаешь работать с реальными данными.

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Разберём типичный кейс классификации, через который проходит большинство команд — на примере задачи вроде «определить, уйдёт ли клиент» или «мошенническая ли это транзакция». Детали разные, а сценарий удивительно похожий.

✅ Стартовая точка: что такое «положительный класс»?

Всё начинается с разметки, и первый вопрос, который часто недооценивают: что мы вообще считаем целевым событием?

❓ Если задача про отток: уход клиента — это отсутствие покупок 30 дней? 60? Или может, отписка от рассылки?
❓ Если про фрод — это подтверждённые кейсы от службы безопасности или все подозрительные транзакции?
❓ Если про дефолт — просрочка 30, 60 или 90 дней?

От этого решения зависит буквально всё: размер выборки, качество разметки, интерпретация метрик. И почти всегда оказывается, что «очевидное» определение целевого события на деле не такое уж очевидное — приходится идти к бизнесу и договариваться.

✅ Первая ловушка: дисбаланс классов

Классика жанра — положительный класс сильно меньше отрицательного. Мошенников — доли процента, ушедших клиентов — единицы процентов. И тут появляется искушение посмотреть на accuracy и обрадоваться цифре 99%. Только вот модель, которая всегда предсказывает «не мошенник», даёт ровно такую же точность и абсолютно бесполезна.

Лайфхаки, которые важно запомнить:
➖ Смотреть не на accuracy, а на precision, recall, F1 и PR-AUC;
➖ Отдельно думать про кастомные пороги — дефолтный 0.5 почти никогда не оптимален;
➖ Ресемплинг (SMOTE и подобные) — не серебряная пуля, иногда только ухудшает результат.

✅ Вторая ловушка: утечки в данных

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

Типичные источники утечек:
➖ В фичи попала информация, которая физически недоступна на момент предсказания (например, дата закрытия сделки в модели прогноза этой сделки);
➖ Временной сплит сделан не по времени, а случайно — и модель "подсматривает" в будущее;
➖ Таргет закодирован в одной из фичей через агрегаты, посчитанные по всей выборке.

Правило простое: если качество слишком хорошее — скорее всего, где-то утечка. Лучше потратить день на проверку, чем потом ловить это в продакшене.

✅ Третья ловушка: калибровка вероятностей

Часто от классификатора нужна не просто метка, а вероятность — чтобы ранжировать клиентов по риску или выставлять пороги под разные сценарии. И тут выясняется, что многие модели выдают «степень своей уверенности» в предсказании, но никак не вероятности с математической точки зрения.

Лечится это калибровкой (например, изотонической регрессией или калибровкой Платта) и проверкой через calibration curve. Это простой, но важный для бизнеса шаг, о котором почти всегда забывают.

Классификация — обманчиво простая задача, и именно поэтому в ней столько мест, где можно споткнуться ❤️

Сохраняйте, чтобы не потерять!

Как правильно выбрать метрики в ML?

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Выбор метрики в ML — это половина успеха. А иногда и все 100%, если случайно ошибиться на старте.

Метрика — это не «строчка в отчёте», а способ договориться с собой и с бизнесом о том, что вообще считается хорошей моделью. Новички часто идут по накатанной: accuracy для классификации, RMSE для регрессии — и вперёд. Но заказчику важны совсем другие цифры: выручка, заказы, подписки... и идеальный accuracy далеко не всегда значит, что в проде модель принесёт пользу.

Итак, метрика — это отражение бизнес-задачи, а не наоборот.

Самая частая ошибка — сначала обучить модель, а потом думать, как измерить её качество. На деле должно быть строго наоборот: прежде чем писать fit, стоит задать себе один вопрос: какая ошибка нам обойдётся дороже?

Пропустить мошенника или заблокировать честного клиента? Не найти больного или отправить здорового на дорогое обследование? Порекомендовать не тот товар или не порекомендовать вообще ничего? Ответы на эти вопросы — и есть ключ к выбору будущей метрики.

F1 — это не «улучшенная accuracy»

F1 любят советовать как универсальную замену accuracy при дисбалансе, но у неё есть неочевидная особенность: в базовой вариации она даёт precision и recall равный вес, а это редко когда правда с точки зрения бизнеса. В антифроде цена FN и FP различаются на порядки, и там честнее смотреть на взвешенную F-beta (с разным вкладом точности и полноты) или сразу считать денежные метрики по историческим данным.

Ещё важный момент: F1 (как и precision, recall) зависит от конкретного порога, и дефолтный 0.5 почти никогда не оптимален. Достаточно пробежаться по сетке порогов от 0.1 до 0.9 и выбрать тот, где метрика максимальна. В большинстве кейсов (особенно при дисбалансе) качество вырастет буквально «из воздуха», без всякого переобучения модели.

ROC-AUC vs PR-AUC — не одно и то же

Классический вопрос, на котором новички часто спотыкаются: формально ROC-AUC «устойчива к дисбалансу» — её значение почти не меняется от того, сколько у вас положительных объектов — но именно в этом и подвох, т. к. устойчивость != информативность.

Представьте: у вас 1% мошенников и 99% честных. Модель может отлично отделять «средних» честных от «средних» мошенников — и ROC-AUC покажет красивые 0.95. Но в топ-100 самых подозрительных транзакций, куда реально пойдут аналитики, окажется всего пара реальных фродов. Для бизнеса модель бесполезна, а метрика говорит, что всё отлично.

PR-AUC смотрит именно на то, что происходит в топе выдачи — как соотносятся precision и recall на положительном классе. Она чувствительна к дисбалансу, «проседает» честно и показывает то, что вам реально важно: насколько хорошо модель ловит редкое событие.

Правило: чем сильнее дисбаланс и чем важнее позитивный класс — тем тщательнее стоит смотреть на PR-AUC, а не на ROC-AUC.

Бизнес-метрики бьют ML-метрики почти всегда

Самое неприятное открытие для многих: можно улучшить ROC-AUC с 0.82 до 0.87 и не сдвинуть выручку ни на копейку. А можно ухудшить F1 и при этом заработать больше — потому что модель начала лучше работать в том сегменте, где чек выше.

Как с этим быть:
🤔 Договариваться с бизнесом про конкретную бизнес-метрику ещё на этапе постановки (uplift, конверсия, средний чек в сегменте, сэкономленные деньги на фроде);
🤔 Считать её параллельно с ML-метрикой на валидации;
🤔 Под каждый сценарий использования подбирать свой порог — часто «одна модель, но три порога под три бизнес-процесса» работает лучше, чем три разные модели.

Хорошая метрика — не та, что красиво выглядит в ноутбуке. А та, по которой можно +- понять, принесет модель пользу или нет ❤️

Сохраняйте, чтобы не потерять!

Растим в себе сильного джуна 💪🏻

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Технический скилл вырастить можно за полгода. А вот привычки, из-за которых с джуном хотят или не хотят работать дальше — формируются уже с первых проектов.

Расскажу, что реально ценят в команде — не «уметь бустинг руками написать», а гораздо более приземлённые вещи. Именно они отличают джуна, которого через полгода зовут на новые задачи, от того, за кем приходится всё переделывать.

✅ Смотреть на данные, а не на метрики

Первое, что делает опытный человек, получив датасет — открывает и листает его глазами. Буквально смотрит на распределения, на пропуски, на дубликаты, на подозрительно ровные значения и на выбросы. Джун же часто сразу летит обучать модель — и потом на код-ревью выясняется, что 15% таргета — это -1 вместо NaN, даты в разных форматах, а половина id мусорные.

Простое правило: прежде чем что-то предсказывать по данным, проведите с ними хотя бы час. EDA — это не формальность из курса, а инженерная гигиена.

✅ Логировать всё, что двигается

Самая частая боль на ревью: «а покажи, какие ты гиперпараметры использовал в том эксперименте на прошлой неделе?». Или файлы model_final.pkl, model_final_v2.pkl, model_final_real.pkl.

Что стоит взять в привычку:
🔶 MLflow, Weights & Biases или хотя бы аккуратный google-табличный лог с датой, параметрами, метриками и коммитом;
🔶 Сохранять не только модель, но и препроцессинг (иначе воспроизвести результат не получится);
🔶 Фиксировать random_state везде, где он есть — да, это скучно, но без этого «у меня получилось 0.84» ничего не значит.

✅ Писать код так, будто через месяц его будет читать незнакомый человек

А это, кстати, вы сами через месяц 🙂 Никто не помнит, зачем в ячейке 47 стоит df = df[df['x'] > 3.14] — не потому что джун неправильный, а потому что человеческая память так устроена.

Что помогает:
🔶 Вынести подготовку данных из ноутбука в .py-модули, как только пайплайн стабилизировался;
🔶 Писать короткие docstring'и к функциям и хотя бы небольшие пояснения к нетривиальным моментам;
🔶 Держать README, из которого быстро можно понять, что делает проект и как его запустить.

Это не «оверинжиниринг» и не «мы же не в проде». Это про уважение к чужому времени — включая своё будущее!

✅ Уметь воспроизвести свой же результат

Классика: джун показывает крутую метрику, модель выкатывают в АБ, и внезапно оказывается, что цифру не удаётся повторить даже на том же датасете... Потому что где-то в пайплайне была случайность без сида, где-то фичи считались на всей выборке, а где-то использовалась версия библиотеки, которую с тех пор обновили.

Минимум, который спасает:
➖ requirements.txt или pyproject.toml с зафиксированными версиями;
➖ Сиды в модели, в сплитах, в SMOTE — везде;
➖ Разделение train/val/test делается один раз и сохраняется, а не пересобирается на каждом запуске.

✅ Задавать вопросы, но правильные

И последнее, что часто недооценивают. Джун, который молча сидит и три дня борется с ошибкой, потому что «неудобно спросить» — это боль для тимлида. Но джун, который приходит с «у меня не работает, помогите» — тоже.

Золотая середина: пришёл с вопросом — покажи, что ты уже попробовал, что прочитал, какие гипотезы отбросил и почему. Это экономит время всем и очень быстро прокачивает.

Классные хард-скиллы — это входной билет. А в команде остаются те, с кем спокойно и понятно работать ❤️

Сохраняйте, чтобы не потерять!

Оффлайн-метрики врут: почему рексистема с идеальным NDCG проваливается в A/B-тесте?

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Обучили рекомендательную модель, NDCG@10 вырос с 0.31 до 0.38, все радуются. Катят в A/B — а бизнес-метрики не двигаются... Знакомо?

Это, пожалуй, самая частая история в рексистемах — и одна из самых болезненных. Разберём, почему офлайн-метрики != успех, и что с этим делать.

🤨 Оффлайн-тест не знает, что пользователь ещё не видел

Это самый главный подвох: тестовые данные — не «правда о вкусах пользователей», а история их взаимодействий с сервисом. Часть этой истории — то, что показывала прошлая рекомендательная модель + намерения пользователей, ищущих через поиск + переходы по прямым ссылкам, из рекламы, по советам друзей… В любом случае этот срез — то, с чем человек уже как-то столкнулся.

А теперь представьте: новая модель находит объект, про который пользователь раньше никогда не знал и сам бы просто на него не наткнулся. Возможно, увидев его, он скажет «вау, хочу» — но узнаем мы это только через A/B-тест. А пока в отложенной выборке для оценки этого клика нет — по NDCG это будет «ошибкой», и метрика оштрафует модель за то, что она на самом деле стала лучше.

🤨 Popularity bias: оффлайн любит популярное, онлайн — нет

Ещё одна ловушка: популярные объекты в исторических данных представлены в разы чаще — модель, которая хорошо ранжирует именно популярное, будет показывать отличный NDCG (даже если внутри ML-алгоритм, а не просто топ-продаж). Проблема в том, что для пользователя разницы почти нет: он и так знает про эти объекты, «вау-эффекта» от рекомендаций нет и вовлечённость не растёт. А редкие, но потенциально интересные именно ему вещи модель обходит стороной — просто потому, что в логах по ним слишком мало сигнала.

Что помогает диагностировать эту проблему:

➖ Смотреть на coverage — какую долю каталога модель вообще рекомендует;
➖ Считать метрики отдельно по началу, середине и хвосту распределения объектов;
➖ Если на «хвосте» метрики близки к нулю, модель просто выучила популярное.

🤨 Feedback loop: модель обучается на себе же

Как только модель уехала в прод, она начинает влиять на данные, на которых будет обучаться следующая версия. Показали что-то в топе → получили клики → переобучили модели → снова показали то же самое. Через пару итераций система схлопывается в узкий набор рекомендаций, а оффлайн-метрики этого вообще не видят: с точки зрения NDCG всё прекрасно, модель отлично предсказывает клики, которые сама же и породила.

🤨 NDCG и Recall@k считают число угадываний, а бизнесу нужны деньги

Даже если оффлайн-оценка честная, есть вторая проблема: NDCG, Recall@k и им подобные — это метрики про число попаданий. Неважно, что вы кладёте в позитив: клики, заказы, добавления в избранное, купленные товары — метрика считает, сколько из них попало в топ-k. А бизнесу нужна выручка!

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

Что с этим делать:

➖ Считать оффлайн не только NDCG/Recall, но и взвешенные версии (по цене, марже, длительности просмотра — по тому, что реально важно);
➖ Обязательно смотреть на новизну и разнообразие рекомендаций, а не только на релевантность;
➖ И всегда помнить: оффлайн-метрика — это гипотеза, а не окончательный приговор.

🙂 Так что же делать?

Короткий ответ — не отменять оффлайн, а честно относиться к его ограничениям. Он нужен, чтобы отсеять заведомо плохие модели и не тратить трафик на A/B-тесты впустую — но финальное решение всегда за онлайном.

Из продвинутых идей — если у вас уже накопилась история A/B-тестов, полезно провести отдельное исследование: взять прошедшие эксперименты, посмотреть, как для этих моделей выглядели оффлайн-метрики, и сопоставить с тем, что показал онлайн. Дальше посчитать корреляцию между оффлайн- и онлайн-метриками. Иногда выясняется, что ваш любимый NDCG@10 вообще не коррелирует с выручкой, а какой-нибудь Recall@50 с фильтрацией по хвосту — коррелирует отлично. Такое знание про свой домен экономит потом кучу циклов разработки.

Кстати, про то, как правильно оценивать модели именно в проде — у нас есть отдельный модуль на курсе. Тема сильно недооценённая, а без неё в реальных задачах никуда.

Сохраняйте, чтобы не потерять! ❤️

Всем привет! Я Валерия Елпатьевская, инженер данных в Альфа Банке и ментор Симулейтив 👋🏻

Пришла рассказать, что мы стартуем второй поток бесплатного ML-интенсива 12-18 августа — буду помогать вам сделать первые шаги в data science и не дам застрять на задачах.

Что ещё будет на интенсиве:

➖ Практика на Kaggle — решаете реальные задачи и сразу кладёте их в портфолио;
➖ Закрытый финальный эфир — разберём, как оформить готовый проект в GitHub так, чтобы его не стыдно было показать работодателю;
➖ Сертификат и призы самым активным участникам!

Продвинутый Python и математика не нужны — стартуем с азов, а разбираться в непонятных местах будет с кем. Буду ждать вас на интенсиве!

➡️ Зарегистрироваться на интенсив

Батч или real-time: выбор, который делают до того, как обучили модель

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Обучить модель — это в лучшем случае половина работы ML-инженера. Дальше возникает вопрос, от которого многие новички просто отмахиваются: а как эта модель будет работать в проде?

Про сам факт деплоя обычно все помнят: «завернём в докер и поднимем сервис». А вот про то, что архитектура инференса модели — это отдельное инженерное решение с кучей нюансов, задумываются далеко не сразу. Разберём два типа инференса: real-time vs батч.

Батч-предсказания: посчитали заранее и положили в хранилище

Идея простая: раз в сутки (или в час, или в неделю) прогоняем модель на всей базе пользователей/объектов, складываем предсказания в таблицу или кэш — и когда они понадобятся, просто достаём готовое.

Где это отлично работает:

➖ Скоринг оттока клиентов раз в неделю;
➖ Ежедневные рассылки и запланированные рекламные кампании;
➖ Сегментация клиентов раз в месяц.

Обратите внимание, что в каждом из перечисленных кейсов задано некоторое регулярное расписание обновления — ничего не происходит в режиме онлайн.

✅ Плюсы такого подхода очевидны: дёшево, просто эксплуатировать, легко переобучать, никаких проблем со скоростью ответа сервиса — предсказание уже готово и ждёт где-нибудь в базе данных. 

❌ Минус тоже очевиден: это свежесть предсказаний. Если пользователь зарегистрировался час назад, а батч прогонится только ночью, до утра его для системы «не существует». Также невозможно учитывать контекст «в прямом эфире»: что человек только что положил в корзину, что накликал, с какого устройства сейчас зашёл.

Real-time инференс: модель отвечает на запрос здесь и сейчас

Противоположный подход — модель поднята сервисом, к нему летят запросы, и на каждый нужно выдать предсказание за десятки, максимум сотни, миллисекунд. Именно так работают антифрод, поисковое ранжирование, онлайн-рекомендации или динамическое ценообразование.

И вот тут начинаются те самые «нюансы, о которых не рассказывают в курсах по ML»:

➖ Скорость ответа бьётся на бюджеты. У вас есть, скажем, 200 мс на весь ответ пользователю. Из них съест сеть 30 мс, бизнес-логика — 50 мс, достать фичи из feature store — 40 мс. И на саму модель остаётся 80 мс, а это уже жёсткое ограничение на архитектуру: тяжёлый бустинг на 5000 деревьях сюда просто не влезет.

➖ Фичи должны быть доступны онлайн. Если в трейне вы использовали «средний чек пользователя за последние 30 дней», в проде эту фичу надо где-то оперативно считать и хранить. Отсюда снова вырастает целый слой инфраструктуры.

➖ Динамическое разбиение на батчи. Отдельная история для нейросетей на GPU: запросы приходят по одному, но обрабатывать их так же по одному — сильное расточительство. Поэтому сервис копит их в очереди несколько миллисекунд и прогоняет через модель сразу пачкой. Это уже не про ML, а про инженерию, но без этого GPU-инференс просто нерентабелен.

➖ Отказоустойчивость. Модель может упасть, быть перегруженной, отвечать слишком долго. Что показывать пользователю в этом случае? Fallback на популярное или более простую эвристику? А может, закэшированное предсказание? Это тоже часть архитектуры, а не «додумаем потом».

Гибрид: чаще всего в проде именно он

В реальности чистый real-time и чистый батч встречаются реже, чем гибриды. Классика жанра — двухстадийные системы: тяжёлая модель раз в сутки считает эмбеддинги и отбирает кандидатов (батч), а лёгкий ранкер переставляет их онлайн с учётом свежего контекста (real-time). Или есть near-real-time: например, когда фичи обновляются через потоковые системы с задержкой в секунды (допустим, по триггеру), а предсказание считается по запросу.

Такой подход даёт лучшее из двух миров: тяжёлую логику выносим в офлайн, а онлайн оставляем ровно столько, сколько нужно для свежести.

Как выбирать?

Стоит задать себе несколько вопросов ещё до обучения модели:

❓ Насколько быстро предсказание должно реагировать на новые события? Если разница между «сейчас» и «через сутки» для бизнеса не важна, берите батч и не усложняйте.
❓ Сколько объектов надо скорить? Если базу в 100 млн пользователей раз в день, выбирайте батч; а если это редкие входящие запросы — можно и real-time.
❓ Какая пиковая нагрузка на сервис (RPS — количество запросов в секунду)? Порядка 10 запросов в секунду и порядка 10 000 — это разные архитектуры и разные затраты.

Понимание всего этого — то, что отличает ML-инженера от «человека, который умеет обучать модели». У нас на курсе есть отдельный модуль как раз про фишки production — тема сильно недооценённая, а без неё модель так и остаётся ноутбуком.

Сохраняйте, чтобы не потерять! ❤️

🔥 Ваш шанс получить крепкую базу в data science

Привет! На связи Мария Жарова, ментор курса «Дата-сайентист» 👋🏻

Спешу сообщить, что 26 августа стартует новый поток курса «Дата-сайентист» с моей менторской поддержкой ❤️

На курсе объединили опыт практикующих экспертов, чтобы за 8 месяцев вы:

➖ Освоили полный стек инструментов аналитики и инженерии данных: от SQL и Python до Docker, Airflow и ETL-пайплайнов;
➖ Погрузились в мир data science: от регрессии, кластеризации и рекомендательных систем до архитектур нейронных сетей, обработки текста (NLP) и компьютерного зрения;
➖ Решили реальные бизнес-кейсы: только практика от действующих аналитиков, которая ляжет в ваше портфолио.

На курсе я покажу не только как обучить модель, но и как довести её до продакшена на реальных кейсах.

Места на поток ограничены! Узнайте подробности о курсе по кнопке ниже:

✅ Узнать подробности и записаться

Модель уже начала деградировать. Просто вы об этом ещё не знаете

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Модель в проде — это не «настроил и забыл». Это живой сервис, который потихоньку деградирует с первого же дня после релиза. Вопрос только в том, заметите вы это сами или расскажут коллеги из бизнеса, когда посыпется выручка.

Разберём, как выстроить мониторинг модели так, чтобы про её “устаревание” узнавать заранее, а не постфактум — что смотреть, с какой периодичностью и на что ставить триггеры.

В целом, мониторинг модели можно разбить на три разных слоя, где каждый отлавливает свой тип проблем.

📌 Слой 1: входные данные. Проблемы на этом этапе часто называют data drift: 

➖ Меняется ли распределение фичей относительно того, на чём модель училась?
➖ Появились ли новые категории, которых раньше не было? 
➖ Не стало ли внезапно 30% пропусков там, где раньше было 2%?

Инструменты для проверки здесь стандартные статистические: PSI (Population Stability Index), KS-тест, сравнение распределений по бакетам. По каждой ключевой фиче — свой контроль (не по всему набору, а именно по ключевым, иначе алерты превратятся в шум).

📌 Слой 2: предсказания модели — это уже называется prediction drift. Даже если входные данные стабильны, может поехать распределение предсказаний — вот несколько типичных примеров: 

➖ Модель начала чаще предсказывать положительный класс;
➖ Средний скор пополз вверх.

Иногда, кстати, проблема оказывается во входных данных — когда по отдельным фичам её не поймать, а в предсказаниях на комбинации признаков она проявляется.

📌 Слой 3: качество модели или concept drift — это самое важное и самое сложное, тут мы смотрим на реальные метрики: precision, recall, ROC-AUC, бизнес-KPI. Основная загвоздка здесь в том, что настоящий таргет обычно приходит с задержкой — факт оттока станет известен через месяц, факт возврата кредита через год… И до этого момента честно посчитать качество нельзя.

Но всё же есть способ поймать проблему, даже пока таргет ещё не пришёл!

➖ Использовать прокси-метрики: часто есть промежуточный сигнал, который приходит быстрее (клик до покупки, первая просрочка до дефолта, отписка до оттока). Конечно, это не идеально, но обычно даёт хоть какой-то ранний неплохой сигнал.
➖ Сравнить с бенчмарком: держите рядом простую эвристику или прошлую версию модели и мониторьте разрыв. Если разрыв схлопывается — модель теряет своё преимущество.
➖ Смотрите на сегментные метрики: часто модель деградирует не целиком, а на конкретных срезах (новые пользователи, определённый регион, новая версия приложения). Общий скор может быть в норме, а вот в разрезе по сегментам — катастрофа.

💡 Совет: ставьте триггеры на переобучение

Классический подход: «переобучаем модель раз в месяц, потому что так решили на глаз». Иногда это оверкилл — если модель стабильна и трогать её нет смысла, а иногда наоборот — за месяц уже всё развалилось.

Поэтому более зрелый подход — комбинировать регулярное переобучение по расписанию как базовый цикл с добавлением триггерного переобучения по алертам (PSI по ключевой фиче ушёл за порог, качество на прокси-метрике просело на N%, доля новых значений категорий превысила X%).

💡 И ещё совет — джентльменский набор метрик для мониторинга модели в проде:

➖ Распределение ключевых фичей и алерт на их сдвиг;
➖ Распределение предсказаний модели во времени;
➖ Доступные онлайн-метрики (те самые прокси);
➖ Реальные метрики с лагом, как только таргет приезжает;
➖ Разбивка по ключевым сегментам, а не только общая цифра;
➖ Отдельно health--чек самого сервиса: скорость ответа, количество ошибок.

И помните, что мониторинг — это не «сделаем, когда будет время», а часть релиза наравне с самим сервисом алгоритмом. Модель без мониторинга — это чёрный ящик, который однажды перестанет работать, и вы узнаете об этом последним.

Кстати, про то, как грамотно построить мониторинг и MLOps-обвязку вокруг моделей в проде, у нас есть отдельный модуль на курсе.

Сохраняйте, чтобы не потерять! ❤️

Между тем, как выглядит ML в курсах и соревнованиях, и тем, как он устроен в реальной повседневной работе — разница намного больше, чем кажется

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Разберём три вещи, которые удивляют почти всех, кто переходит в ML. Речь не про «недостаточное знание алгоритмов» — поговорим про разрыв ожиданий и реальности самой роли.

1️⃣ Работа с данными — это больше половины времени, а не «быстрый подготовительный этап»

В голове новичка проект устроен так: сначала быстренько готовим данные за пару часов, а дальше начинается «настоящая работа» — модели, гиперпараметры, метрики. В реальности пропорции обратные: львиную часть времени занимают подготовка, чистка, стыковка источников, разбирательства «а почему у нас в одной таблице user_id — int, а в другой — string», проверка на утечки, построение фичей…

И это не из-за того, что в больших компаниях данных много и они всегда грязные. А потому что понимание данных — это и есть залог успешного моделирования. Важно понимать, что высокого качества ML-алгоритма можно достичь далеко не только благодаря SOTA-моделям, а часто благодаря качественно подготовленным данным для обучения.

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

2️⃣ Модель — это маленький кусочек системы, а не её центр

Ещё одно открытие, которое приходит только с опытом: сама модель — обычно самая простая часть проекта. Поставить на обучение в сотый раз CatBoost — дело нескольких минут. А вот вокруг модели живёт целая инфраструктура, которую и надо уметь строить для каждого случая индивидуально:

➖ Откуда берутся фичи в проде и совпадают ли они с тем, на чем модель обучалась;
➖ Что происходит, если модель упала или отвечает слишком долго;
➖ Как её версионировать, откатывать, катить постепенно;
➖ Как понять, что она устарела и её пора переобучать.

Джун обычно приходит с мыслью «я умею обучать модели» — но это лишь входной билет, а настоящая работа начинается там, где модель едет в прод. Именно поэтому в вакансиях ML-инженера всё чаще появляются требования, схожие со списом инструментария бэкенд-разработчика — Python на приличном уровне, Docker, Kubernetes, CI/CD, базы данных, очереди, стриминг. Без этого модель так и остаётся Jupyter–ноутбуком.

3️⃣ Коммуникация с бизнесом — часть роли, а не «пусть менеджеры этим занимаются»

Самая недооценённая часть работы, особенно у технически сильных ребят. Мысль «я делаю модель, а с бизнесом пусть говорит продакт» — очень частая, и очень мешающая.

Проблема в том, что ML-задачи почти никогда не приходят в готовом виде. «Хотим предсказывать отток» — это не задача, это направление для размышлений. Что считать оттоком? На каком горизонте? Что с этим предсказанием потом делать — рассылать промо, звонить, менять тариф? Какая цена ошибки в одну и другую сторону? Ответы на эти вопросы определяют всё — от разметки до выбора метрики — и получить их можно только в разговоре с бизнесом.

Опытные ML-инженеры эту часть тащат самостоятельно: они умеют прийти с правильными вопросами, объяснить ограничения модели без матана, показать “вот здесь можно сделать точнее, но это займёт месяц — стоит ли оно того?”. Джун же часто молча берёт задачу как есть, несколько недель что-то делает, приносит результат — и выясняется, что решал совсем не ту проблему.

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

Что делать с этой информацией?

Плохая новость: по туториалам и соревнованиям всего это не выучить 🙂 Там просто нет таких данных, такой инфраструктуры и такого контекста.

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

Именно поэтому у нас на курсе эти три темы вплетены в каждый модуль, а не вынесены в «дополнительные материалы для интересующихся». Без них ML-инженер быстро упирается в потолок «человека, который умеет обучать модели», а роль требует сильно большего.

Сохраняйте, чтобы не потерять! ❤️

🔥 Новый поток интенсива по ML

9-16 сентября пройдёт следующий поток ML-интенсива с менторской поддержкой!

Ментор Валерия Елпатьевская, инженер данных в Альфа Банке, будет помогать вам сделать первые шаги в data science и не даст застрять на задачах.

Что ещё будет на интенсиве:

➖ Практика и соревнование на Kaggle — решаете реальные задачи и сразу кладёте их в портфолио, а также соревнуетесь с другими участниками;
➖ Закрытый эфир для участников интенсива — поговорим о профессиях в data science и возможностях для развития начинающего специалиста;
➖ Сертификат и призы самым активным участникам!

Продвинутый Python и математика не нужны — стартуем с азов, а разбираться в непонятных местах будет с кем. Буду ждать вас на интенсиве!

➡️ Зарегистрироваться на интенсив

Всем привет! Небольшой опрос нашей аудитории — пожалуйста, ответьте на несколько вопросов ниже, а мы в ответ сделаем наш контент лучше и интереснее ⬇️