Модель предскажет

Как понять, что на самом деле означают кластеры?

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

Кластеризация — классная штука: модель сама разбивает объекты на группы, и никакая разметка не обязательна. Но проблемы обычно начинаются потом — когда необходимо понять, что вообще означают эти кластеры?

Дело в том, что просто получить лейблы модели недостаточно: если вы не интерпретировали кластеры, ценность такого решения стремится к нулю.

Держите два простых и очень наглядных способа, которые быстро помогают «прочитать» кластеры 👇

1️⃣ Тепловая карта (heatmap)

Идея — берём признаки и считаем их средние значения внутри каждого кластера и дальше строим heatmap:

➖ по строкам — кластеры;
➖ по столбцам — признаки;
➖ цвет — значение.

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

📌 В plotly можно использовать px.imshow или go.Heatmap

2️⃣ Полярная диаграмма (Radar Chart)

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

Что здесь удобно:
➖ Легко сравнивать кластеры между собой;
➖ Сразу видно, по каким признакам кластер «выделяется»;
➖ Отлично заходит для презентаций.

📌 В plotly можно использовать go.Scatterpolar

Зачем это нужно?

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

Поэтому после ML-ной части с экспериментами и метриками не забывайте о простой, но самой важной части — интерпретации 😉

Сохраняйте — пригодится в реальных задачах!

Выкатили модель скоринга — метрики идеальные, но через месяц дефолты поползли вверх. Почему?

Привет! Я Наталия Воронова, спикер курса «Дата-сайентист» 👋🏻

Расскажу кейс из практики про то, где на самом деле ломаются ML-модели после деплоя. И спойлер: дело не в алгоритмах.

Ситуация

Мы обучили модель кредитного скоринга. ROC-AUC стабильный, валидация чистая, и модель уходит в прод.

Через время качество начинает ухудшаться. Не резко, постепенно. Самый неприятный сценарий: модель работает (ошибок нет), но бизнес-метрики ползут вниз.

Что произошло?

Смещение распределений признаков между train и prod. В обучении признаки считались на историческом срезе: доход клиента, транзакционная активность, поведенческие агрегаты.

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

Как диагностировали?

PSI (Population Stability Index) — стандарт в кредитном скоринге. PSI показывает, насколько распределение признака в проде отличается от обучающего.

Мы сравнили train и текущий поток. Результат: по ключевым фичам PSI > 0.3. Получается, модель работала уже в другой реальности.

Правило интерпретации PSI:
➖ < 0.1 → стабильно
➖ 0.1–0.25 → есть сдвиг, следить
➖ > 0.25 → критическое изменение

Почему это происходит?

Данные не живут в вакууме. Особенно в динамичных задачах:
🟠 Кредитный риск → меняется макроэкономика, ставки, доходы
🟠 Маркетинг → меняются каналы, сезонность, поведение
🟠 churn → меняется продукт, конкуренты, акции

Модель не ломается. Она начинает экстраполировать туда, где никогда не обучалась.

Что сделали:
🔹 Синхронизировали пайплайны расчёта признаков (train = prod);
🔹 Зафиксировали временные окна;
🔹 Добавили мониторинг PSI по ключевым фичам;
🔹 Ввели алерты на drift.

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

Мониторите drift в проектах? 😉

Катастрофа в проде: модель идеально работает в ноутбуке, но ломается после выкатки в продакшн

Привет! На связи Кристина Желтова, директор по разработке моделей в Газпромбанке и преподаватель курса «Инженер машинного обучения» 👋🏻

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

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

❓ Какие могут быть причины такого поведения модели, и как узнать о существовании проблемы не от заказчиков, а во время экспериментов?

1️⃣ Temporal Leakage: неправильная разбивка данных, упорядоченных по времени

Проблема: команда использовала обычный train_test_split с shuffle=True на упорядоченных данных с временными метками.

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

Правильный подход: использовать специальную валидацию для временных данных — TrainTestSplit.

2️⃣ Feature Leakage: признаки из «будущего»

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

Правильный подход: проверять, что все признаки, агрегации и статистики считаются только на данных до целевой даты предсказания.

3️⃣ Target Leakage: утечка информации из целевой переменной

Проблема: для моделирования использовали признаки, напрямую связанные с целевой переменной или вычисляемые из неё.

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

У вас бывали подобные случаи? Делитесь в комментариях!

Всем привет, я Наталия Воронова, Senior ML Engineer/Data Scientist, разработчик AI-платформы в маркетинге и спикер Симулейтив 👋

Буду делиться опытом в этом канале. Несколько фактов обо мне:

1️⃣ 10 лет в банковском секторе на руководящих позициях. Отвечала за решения по кредитным портфелям. PD, LGD и дефолты — это моя практика.

2️⃣ У меня 5 дипломов: Data Science, Fullstack-разработка, а также экономическое, филологическое и юридическое образование.

3️⃣ Я Data Scientist, который работает с бизнес-метриками. Мои модели про прибыль, риск и решения.

4️⃣ Строю ML-системы end-to-end. От данных к продакшену и влиянию на бизнес
(scoring, churn, pricing, recommender systems, NLP, CV).

5️⃣ Сейчас разрабатываю собственную AI-платформу. Она помогает оценивать прибыль от привлечения клиентов с учётом риска и оттока.

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

Рада познакомиться 💙

Как понять, что вы реально готовы искать работу ML-инженером

Привет! На связи Кристина Желтова, директор по разработке моделей в Газпромбанке и ментор курса «ML-инженер» 👋🏻

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

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

Как же всё-таки понять, что уже пора выйти на рынок? У меня есть для вас три критерия:

1️⃣ Вы можете объяснить своё решение, а не только запустить его и сделать fit-predict

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

На реальных собеседованиях вас вряд ли попросят воспроизвести статью, зато могут спросить: «А почему так? А что будет если...?»

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

2️⃣ У вас есть хотя бы один проект, который решает какую-то проблему

Не «я реализовал нейронную сеть из туториала на MNIST или модель на датасете Titanic», а «я сформулировал задачу, взял данные, обучил модель, развернул её, и она делает что-то полезное».

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

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

3️⃣ Вы знаете, чего не знаете

Звучит парадоксально, но это один из самых зрелых признаков.

Джун, который не готов, часто либо думает, что знает всё, либо уверен, что не знает ничего (и не идёт на собес вообще).

Более зрелый кандидат говорит: «Я хорошо разбираюсь в классическом ML и понимаю, как работают трансформеры. В MLOps у меня базовый уровень — могу развернуть, но с оркестрацией опыта мало. Готов учиться». Это стадия осознанной некомпетентности, от которой один шаг к профессионализму. Рекрутер и технический интервьюер это оценят.

И один контрольный вопрос напоследок: если бы вам прямо сейчас написал рекрутер с приглашением на техническое собеседование по ML, какой была бы ваша первая реакция?

➖ «О, интересно, надо попробовать» — скорее всего, вы готовы
➖ «Мне нужно ещё немного времени подготовиться» — вероятно, вы в ловушке готовности
➖ «Я сначала дочитаю вот эту книгу» — ну вы поняли 🙂

Готовность — это умение работать, несмотря на пробелы!

Что влияет на зарплату и карьеру аналитика?

Дождались большого исследования рынка аналитики от коллег из NEWHR за 2025 год! Спасибо всем, кто принял участие 🧡

В исследовании приняли участие 1493 аналитика из 14+ специализаций. Они рассказали, где живут, на какие компании работают, на какие рынки ориентируются, как ищут работу и к чему стремятся. А также — сколько зарабатывают и как изменилась их зарплата.

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

Также прикрепляем несколько прямых ссылок на интересные инсайты:
➖ Какие задачи решают аналитики сегодня
➖ На какие компании и в каком формате работают
➖ Как менялись зарплаты аналитиков в течение 2025 года
➖ Сколько они получают сегодня в зависимости от специализации и грейда
➖ Откуда пришли в профессию и как планируют развиваться дальше
➖ ТОП и Анти-ТОП российских компаний по мнению аналитиков
➖ Что ценят в аналитической культуре
➖ На какие конференции ходят и за кем из экспертов следят

➡️ Для сравнения — исследование за 2024 год.

📈 Симулейтив | ВК | YouTube

Как одна «незначительная» фича сломала модель в бою

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

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

Мы решали задачу предсказания оттока пользователей. Классическая история: табличные данные, градиентный бустинг, аккуратный пайплайн, валидация — всё как надо. На кросс-валидации модель давала стабильный прирост к бейзлайну, метрики выглядели уверенно.

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

Но через несколько дней после выкатки метрики в проде поползли вниз… Сначала думали на данные, потом на инфраструктуру, потом на сдвиг распределений — но оказалось, дело в одной фиче! Как раз «время последнего действия» в обучении считалось относительно фиксированной даты (условно, «срез данных на момент выгрузки»). А в проде — относительно текущего времени.

Звучит безобидно, но по факту:
➖ в обучении модель видела, что«“клиент давно не заходил» — это, например, 30 дней;
➖ в проде это же значение могло стать 60, 90 и т. д., потому что время идёт, а логика пересчёта не была синхронизирована.

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

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

Поэтому всегда имейте в виду:
😶 Любая фича, завязанная на время — почти всегда источник проблем, если не продумана логика её расчёта в проде;
😶 Важно проверять не только код обучения, но и код генерации признаков для прода — они должны быть идентичны по смыслу;
😶 Полезно смотреть на распределения признаков: train vs prod, хотя бы на базовом уровне;
😶 Если фича становится топ-важной — к ней должно быть повышенное внимание, потому что именно она может «уронить» модель.

И да, чаще всего модель ломает не сложная математика, а такие вот мелочи, которые сначала кажутся очевидными.

Сохраняйте, чтобы не наступить на те же грабли!

Привет! На связи Кристина Желтова, директор по разработке моделей в Газпромбанке 👋🏻

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

Именно здесь помогает регуляризация.

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

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

Какие бывают подходы к регуляризации:

1️⃣ Ограничить «сложность» модели. Идея простая — не давать модели слишком сильно подстраиваться под каждую деталь в данных.

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

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

2️⃣ Случайно ансамблировать — «смешивать» модели во время обучения. Звучит странно, но иногда модели полезно немного усложнить жизнь.

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

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

3️⃣ Остановить обучение вовремя. Иногда лучшая регуляризация — просто не дать модели переобучиться.

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

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

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

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

Переобучение: почему ваша модель врёт и что с этим делать

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

Представьте ситуацию: вы обучили модель, на трейне — почти идеальная точность, а на новых данных всё разваливается… Значит, вы столкнулись с переобучением 🙂

Что это вообще такое?

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

Классический сигнал переобучения:
🟠 На тренировочных данных ошибка падает;
🟠 На валидационных данных начинает расти.

В классическом (и не только) ML причины, как правило, делятся на две группы: либо проблема в данных (мультиколлинеарность, много дубликатов или маленький объем), либо в модели (слишком сложная или неподходящая архитектура, не те гиперпараметры).

Как с этим бороться?

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

1️⃣ Штраф на большие веса

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

Существует несколько разных подходов: L1 (Lasso), L2 (Ridge) и их комбинация (Elastic Net), вот псевдокод вариантов этого «добавочного» слагаемого:

alpha * sum(abs(w))       # добавка к loss при L1
alpha * sum(w**2)         # добавка к loss при L2

2️⃣ Ранняя остановка обучения

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

3️⃣ Больше данных (или их имитация)

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

4️⃣ «Упрощение» модели

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

➖ Уменьшить глубину дерева;
➖ Уменьшить число обучаемых параметров;
➖ Попробовать в принципе более простую архитектуру.

Так что переобучение — это не баг, а естественное поведение модели. И ваша задача — держать его под контролем.

Ставьте ❤️, если было полезно — и сохраняйте, чтобы не потерять!

Как собрать простой RAG-пайплайн

Привет! На связи Кристина Желтова, директор по разработке моделей в Газпромбанке 👋🏻

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

Если совсем просто, то RAG — это LLM с внешней памятью, только в этой памяти документы лежат как векторы, а сами тексты хранятся в их метаданных.

Минимальный пайплайн состоит всего из нескольких шагов:

1️⃣ Берём приглянувшийся датасет с текстами;
2️⃣ Считаем для них эмбеддинги;
3️⃣ Складываем в векторную базу данных;
4️⃣ По запросу пользователя ищем top-k ближайших фрагментов;
5️⃣ Подкладываем найденный контекст в промпт LLM и просим ответить с использованием этой информации.

Такой пайплайн можно собрать даже на маленькой русской базе знаний: FAQ, конспектах, памятках или учебных материалах.

➡️ По ссылке доступна минималистичная реализация базового пайплайна с моделями intfloat/multilingual-e5-small и Qwen/Qwen3-0.6B.

Станьте востребованным дата-сайентистом

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

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

После курса вы сможете не просто обрабатывать данные, а прогнозировать будущее и находить скрытые возможности. Получите диплом государственного образца и уверенно ворвётесь на рынок труда с полным набором навыков!

🧡 Записаться на поток со скидкой 30%: simulative.ru/data-scientist

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

Замечали, что рекомендации как будто читают ваши мысли? В этом ролике рассказала о рекомендательных системах и как мы их неосознанно учим 👆🏻