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

🔥 Ваш шанс получить крепкую базу в data science Привет! На связи Мария Жарова, ментор курса «Дата-сайентист» 👋🏻 Спешу сообщить, что 26 августа стартует новый поток курса «Дата-сайентист» с моей менторской поддержкой ❤️ На курсе объединили опыт практикующих экспертов, чтобы за 8 месяцев вы: ➖ Освоили полный стек инструментов аналитики и инженерии данных: от SQL и Python до Docker, Airflow и ETL-пайплайнов; ➖ Погрузились в мир data science: от регрессии, кластеризации и рекомендательных систем до архитектур нейронных сетей, обработки текста (NLP) и компьютерного зрения; ➖ Решили реальные бизнес-кейсы: только практика от действующих аналитиков, которая ляжет в ваше портфолио. На курсе я покажу не только как обучить модель, но и как довести её до продакшена на реальных кейсах. Места на поток ограничены! Узнайте подробности о курсе по кнопке ниже: ✅ Узнать подробности и записаться

Батч или 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 — тема сильно недооценённая, а без неё модель так и остаётся ноутбуком. Сохраняйте, чтобы не потерять! ❤️

Всем привет! Я Валерия Елпатьевская, инженер данных в Альфа Банке и ментор Симулейтив 👋🏻 Пришла рассказать, что мы стартуем второй поток бесплатного ML-интенсива 12-18 августа — буду помогать вам сделать первые шаги в data science и не дам застрять на задачах. Что ещё будет на интенсиве: ➖ Практика на Kaggle — решаете реальные задачи и сразу кладёте их в портфолио; ➖ Закрытый финальный эфир — разберём, как оформить готовый проект в GitHub так, чтобы его не стыдно было показать работодателю; ➖ Сертификат и призы самым активным участникам! Продвинутый Python и математика не нужны — стартуем с азов, а разбираться в непонятных местах будет с кем. Буду ждать вас на интенсиве! ➡️ Зарегистрироваться на интенсив

Оффлайн-метрики врут: почему рексистема с идеальным 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-инженер» и «Дата-сайентист» 👋🏻 Технический скилл вырастить можно за полгода. А вот привычки, из-за которых с джуном хотят или не хотят работать дальше — формируются уже с первых проектов. Расскажу, что реально ценят в команде — не «уметь бустинг руками написать», а гораздо более приземлённые вещи. Именно они отличают джуна, которого через полгода зовут на новые задачи, от того, за кем приходится всё переделывать. ✅ Смотреть на данные, а не на метрики Первое, что делает опытный человек, получив датасет — открывает и листает его глазами. Буквально смотрит на распределения, на пропуски, на дубликаты, на подозрительно ровные значения и на выбросы. Джун же часто сразу летит обучать модель — и потом на код-ревью выясняется, что 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 делается один раз и сохраняется, а не пересобирается на каждом запуске. ✅ Задавать вопросы, но правильные И последнее, что часто недооценивают. Джун, который молча сидит и три дня борется с ошибкой, потому что «неудобно спросить» — это боль для тимлида. Но джун, который приходит с «у меня не работает, помогите» — тоже. Золотая середина: пришёл с вопросом — покажи, что ты уже попробовал, что прочитал, какие гипотезы отбросил и почему. Это экономит время всем и очень быстро прокачивает. Классные хард-скиллы — это входной билет. А в команде остаются те, с кем спокойно и понятно работать ❤️ Сохраняйте, чтобы не потерять!

Как правильно выбрать метрики в 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. Кажется, что здесь всё просто, но это пока не начинаешь работать с реальными данными. Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻 Разберём типичный кейс классификации, через который проходит большинство команд — на примере задачи вроде «определить, уйдёт ли клиент» или «мошенническая ли это транзакция». Детали разные, а сценарий удивительно похожий. ✅ Стартовая точка: что такое «положительный класс»? Всё начинается с разметки, и первый вопрос, который часто недооценивают: что мы вообще считаем целевым событием? ❓ Если задача про отток: уход клиента — это отсутствие покупок 30 дней? 60? Или может, отписка от рассылки? ❓ Если про фрод — это подтверждённые кейсы от службы безопасности или все подозрительные транзакции? ❓ Если про дефолт — просрочка 30, 60 или 90 дней? От этого решения зависит буквально всё: размер выборки, качество разметки, интерпретация метрик. И почти всегда оказывается, что «очевидное» определение целевого события на деле не такое уж очевидное — приходится идти к бизнесу и договариваться. ✅ Первая ловушка: дисбаланс классов Классика жанра — положительный класс сильно меньше отрицательного. Мошенников — доли процента, ушедших клиентов — единицы процентов. И тут появляется искушение посмотреть на accuracy и обрадоваться цифре 99%. Только вот модель, которая всегда предсказывает «не мошенник», даёт ровно такую же точность и абсолютно бесполезна. Лайфхаки, которые важно запомнить: ➖ Смотреть не на accuracy, а на precision, recall, F1 и PR-AUC; ➖ Отдельно думать про кастомные пороги — дефолтный 0.5 почти никогда не оптимален; ➖ Ресемплинг (SMOTE и подобные) — не серебряная пуля, иногда только ухудшает результат. ✅ Вторая ловушка: утечки в данных Пожалуй, самая коварная штука в классификации, когда модель показывает подозрительно высокое качество на валидации. Но опытный человек в этот момент не радуется, а начинает искать, где и что могло пойти не так. Типичные источники утечек: ➖ В фичи попала информация, которая физически недоступна на момент предсказания (например, дата закрытия сделки в модели прогноза этой сделки); ➖ Временной сплит сделан не по времени, а случайно — и модель "подсматривает" в будущее; ➖ Таргет закодирован в одной из фичей через агрегаты, посчитанные по всей выборке. Правило простое: если качество слишком хорошее — скорее всего, где-то утечка. Лучше потратить день на проверку, чем потом ловить это в продакшене. ✅ Третья ловушка: калибровка вероятностей Часто от классификатора нужна не просто метка, а вероятность — чтобы ранжировать клиентов по риску или выставлять пороги под разные сценарии. И тут выясняется, что многие модели выдают «степень своей уверенности» в предсказании, но никак не вероятности с математической точки зрения. Лечится это калибровкой (например, изотонической регрессией или калибровкой Платта) и проверкой через calibration curve. Это простой, но важный для бизнеса шаг, о котором почти всегда забывают. Классификация — обманчиво простая задача, и именно поэтому в ней столько мест, где можно споткнуться ❤️ Сохраняйте, чтобы не потерять!

Привет! На связи Мария Жарова, ML-инженер команды рекомендаций в Wildberries и ментор курса «ML-инженер» 👋🏻 Задумывались, чем ML-подход отличается от обычной разработки и что вообще происходит «под капотом», когда компьютер сам находит закономерности в данных, а не работает по прописанным правилам? Приходите на мой вебинар — разберём это на реальных примерах. Разберём три вещи: ➖ Чем ML-подход отличается от обычной разработки — на примере того, как устроен поиск; ➖ Где ML реально работает в индустрии — беспилотный транспорт, голосовые помощники, генеративные сети, рекомендательные системы, финтех, медицина — и какие тренды у профессии в 2026 году; ➖ Прямо на вебинаре обучим модель оценивать стоимость недвижимости по реальным данным и соберём из неё интерактивное приложение. Если хотите понять, как устроена работа ML-инженера и что реально нужно знать на старте — приходите! 📆 22 июля, 19:00 МСК, онлайн ➡️ Ставьте напоминание в календарь, чтобы не забыть!

Кажется, что задача сегментации — это просто. Но самое интересное появляется после обучения моделей, когда возникает главный вопрос: «N кластеров получили… и что дальше?» 😄 Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻 Сегментация — задача, которая почти всегда живёт на стыке ML и бизнеса, и именно поэтому в ней столько подводных камней. Разберём типовой сценарий. ✅ Стартовая точка: зачем вообще сегментировать? Первая и главная ловушка — начать кластеризовать без чёткого ответа на вопрос «что мы потом будем делать с сегментами?». Подобные истории почти всегда максимум заканчиваются красивой презентацией, которая пылится в архиве. Возможные цели могут быть совершенно разные: ➖ Персонализировать коммуникации (например, разные письма разным группам); ➖ Построить продуктовые предложения под конкретный сегмент; ➖ Найти «спящих» клиентов, которых можно реактивировать; ➖ Понять, кто приносит основную выручку, а кто — основные затраты. И под каждую цель — свои признаки, своя гранулярность, свои требования к интерпретируемости. Универсальной «правильной» сегментации не существует. ✅ Первая итерация: baseline через бизнес-правила Прежде чем доставать K-Means и DBSCAN, полезно построить сегментацию руками — по простым правилам. Классический пример — RFM-анализ (Recency, Frequency, Monetary): разбиваем клиентов на группы по трём осям и получаем понятные сегменты вроде «новички», «лояльные», «уходящие», «VIP». Плюсы такого подхода — легко объяснить бизнесу, легко воспроизвести, и сразу видно, что делать с каждой группой. И часто оказывается, что этого уже достаточно, а сложная кластеризация не даёт заметных улучшений. ✅ Вторая итерация: кластеризация и её ловушки Когда бизнес-правил становится мало, в ход идут алгоритмы. И тут вылезают типичные грабли: ➖ Выбор признаков важнее выбора алгоритма: сегментация по «сырым» фичам почти всегда даёт мусор. Нужны продуманные агрегаты: частота, средний чек, доля категорий, поведенческие паттерны; ➖ Масштабирование обязательно, иначе одна большая по значениям фича задавит все остальные; ➖ Число кластеров: метрики вроде коэффициента силуэта и метода локтя помогают, но финальное слово всегда за интерпретацией: если 5 кластеров осмысленны, а 8 — нет, берём 5; ➖ Проклятие размерности: на большом числе фичей расстояния «схлопываются», и почти всё оказывается одинаково далёким друг от друга. Спасают снижение размерности (PCA, UMAP) и отбор признаков. ✅ Третья ловушка: сегменты, которые нельзя объяснить Допустим, кластеризация отработала, выделили N групп. И дальше наступает самый интересный момент — надо объяснить бизнесу, кто это такие. Если сегменты не поддаются простой интерпретации («вот эти — экономные семейные, а вот эти — импульсивные молодые»), то результатом невозможно пользоваться. Полезные приёмы для интерпретации: ➖ Посмотреть на средние и медианы ключевых признаков по кластерам + в сравнении с общим средним; ➖ «Портреты» типичных представителей каждого сегмента; ➖ Дерево решений, обученное предсказывать метку кластера — оно буквально выдаёт правила, по которым сегменты отличаются. Если интерпретация не складывается, почти всегда стоит вернуться назад и пересобрать фичи или уменьшить число кластеров. Сегментация — редкий случай, когда самый большой прирост даёт не улучшение модели, а улучшение постановки задачи ❤️ Сохраняйте, чтобы не потерять!

Встроенная магия 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 для тяжёлых, которые дорого перечитывать. Сохраняйте, чтобы не потерять ❤️

Гайд: практическое применение алгоритмов ML Знаете, как компьютеры могут учиться на данных и делать точные прогнозы? Благодаря алгоритмам машинного обучения — набору методов, которые позволяют компьютерам учиться на данных и делать прогнозы без явного программирования. Подготовили для вас материал с обзором и примерами применения таких алгоритмов. Что вы получите от нашего материала? ⭐️ 16 алгоритмов с реальными примерами кода, такими как прогнозирование стоимости недвижимости, классификация электронных писем как спам или не-спам и многое другое; ⭐️ Разберётесь в принципах работы алгоритмов и их практическом применении. Вы узнаете, как использовать их для автоматизации рутинных задач и улучшения процессов принятия решений; ⭐️ Узнаете, как использовать эти алгоритмы для решения реальных задач в бизнесе, науке и других областях. Это может существенно повысить эффективность ваших проектов и дать вам конкурентное преимущество. ✅ Получить материал

Рексистемы — одна из тех областей, где красивая теория очень быстро встречается с суровой реальностью продакшена Привет! На связи Мария Жарова, ментор курсов «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 или Data Science?» Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻 На самом деле в ML приходят из очень разных направлений. И почти всегда предыдущий опыт всё равно оказывается полезным — просто у каждого бэкграунда свои сильные стороны и свои пробелы, которые нужно закрывать. ⭐️ Например, аналитика — наверное, один из самых естественных входов в Data Science. DA хорошо умеют работать с данными, знают Python и SQL, понимают метрики, визуализацию и логику продуктовых задач. Обычно здесь остаётся посмотреть только темы, связанные непосредственно с машинным обучением: какие бывают модели, их валидацию, концепции подготовки данных для ML и базовый production-подход. ⭐️ А вот разработчикам легче даётся инженерная часть: код, архитектура, оптимизация, работа с инфраструктурой. При переходе в ML они обычно прокачивают математику и принципы работы с данными и экспериментами. ⭐️ У дата-инженеров часто уже есть очень сильная база по пайплайнам, хранению и обработке больших объёмов данных. Поэтому переход в ML тоже бывает довольно органичным — тут также нужно добавить понимание моделей и ML-логики. ⭐️ А ещё в ML очень много людей из совсем других сфер: экономики, физики, биологии, маркетинга, финансов — и это тоже нормально. Во многих задачах доменная экспертиза оказывается не менее важной, чем знание очередной библиотеки. Последнее время можно наблюдать интересную тенденцию: нередко в описаниях вакансий встречаются требования про знание доменной сферы. Но есть вещь, которая почти одинаково важна для всех, независимо от точки входа: без практики перейти в ML очень сложно. Можно долго смотреть лекции и читать статьи, но настоящее понимание обычно появляется только в момент, когда сам пытаешься обучить модель, разобраться с данными, починить странную ошибку или понять, почему качество внезапно стало хуже. Именно поэтому почти у всех успешных переходов в ML есть что-то общее: пет-проекты, стажировки, практические задачи, участие в соревнованиях или работа с наставником, который помогает быстрее пройти через типичные проблемы. Так что если вам кажется, что у вас «не тот» бэкграунд для ML — скорее всего, это не так. Намного важнее другое: насколько системно вы готовы закрывать пробелы и превращать теорию в практику ❤️

Один из самых недооценённых лайфхаков в ML — это правильные негативные примеры Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻 Когда люди начинают изучать ML, обычно всё выглядит довольно просто: есть объект и есть правильный ответ. В процессе обучения мы показываем модели много таких примеров, чтобы она сама научилась предсказывать. Но в серьёзных ML-задачах этого часто недостаточно, потому что модели важно не только понимать, что является правильным, но и уметь отличать это от неправильного. Например: ➖ В рекомендациях нужно выбрать лучшие товары среди тысяч других и расположить их в правильном порядке; ➖ Аналогично в поиске — найти самые подходящие документы; ➖ В матчинг-задачах — отличать похожие объекты от непохожих; ➖ В CV и NLP — понимать, какие изображения или тексты действительно близки по смыслу, а какие нет. И тут всегда возникает проблема: потенциально «неправильных» вариантов обычно слишком много. Представьте рекомендательную систему: пользователь купил кроссовки — это позитивный пример. Но товаров в магазине могут быть миллионы. В процессе обучения нельзя каждый раз сравнивать покупку вообще со всеми остальными товарами маркетплейса — это слишком дорого по памяти и вычислениям. Поэтому во время обучения обычно берут только часть негативных примеров — то есть специально выбирают, какие «неправильные» ответы показать модели. Простейший вариант — взять негативы случайно, но в этом есть свои риски: например, пользователь купил кроссовки, а в негативы попал холодильник. Формально всё правильно — холодильник действительно не купили, но проблема в том, что такой «негатив» слишком простой. Другими словами, модель быстро выучится, что «кроссовки ≠ холодильник» — и почти ничего полезного из этого не получит. Потому что реальные ошибки обычно происходят не между совершенно разными объектами, а между похожими: то есть не между кроссовками и холодильником, а между двумя похожими моделями кроссовок. Поэтому в хороших production ML-системах негативы стараются делать более «сложными». Например, в негативы могут специально добавлять товары из той же категории, похожие фильмы, близкие тексты, объекты с похожими эмбеддингами или товары, на которые пользователь кликнул, но не купил. Такие примеры заставляют модель учиться гораздо лучше, потому что ей приходится разбираться в мелких различиях, а не в очевидных. И очень часто качество негативных примеров влияет на итоговый результат сильнее, чем очередная сложная архитектура или тюнинг гиперпараметров. Поэтому две команды могут использовать одну и ту же модель, но получать совершенно разное качество 🙂 Сохраняйте, чтобы не потерять ❤️

Всем привет! Я Валерия Елпатьевская, инженер данных в Альфа Банке и ментор Симулейтив 👋🏻 Мой путь начался не в IT: филология, преподавание, потом Data Science. Но быстро поняла, что без инженерной базы далеко не уедешь. Пошла разбираться в очередях, оркестрации и архитектуре… и как-то незаметно стала Data Engineer. С 8 по 16 июля я буду ментором бесплатного ML-интенсива — буду помогать вам сделать первые шаги в data science и не дам застрять на задачах. Что ещё будет на интенсиве: ➖ Практика на Kaggle — решаете реальные задачи и сразу кладёте их в портфолио; ➖ Финальный эфир — разберём, как оформить готовый проект в GitHub так, чтобы его не стыдно было показать работодателю; ➖ Сертификат и призы самым активным участникам недели! Продвинутый Python и математика не нужны — стартуем с азов, а разбираться в непонятных местах будет с кем. Буду ждать вас на интенсиве! ➡️ Зарегистрироваться на интенсив

Поэтому в задачах, где размер таблиц исчисляется более чем десятками миллионов строк, наилучшим выбором будет библиотека Polars! Её синтаксис очень похож на Pandas, но работает она гораздо быстрее и эффективнее.

Лучший совет для начинающих — начните 😄 Но с чего начать, когда вокруг столько информации? Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻 Хоть Data Science и относительно молодое направление, по нему уже успело накопиться ооочень много ресурсов и литературы. Собрала для вас 3 книги, которые хорошо подойдут на старте — без перегруза и с понятной логикой роста. 📕 Луис Серра «Грокаем машинное обучение» Это одна из самых дружелюбных книг для входа в тему: здесь нет ощущения, что тебя сразу бросили в линейную алгебру или матанализ и сказали «разбирайся». В книге огромное множество интуитивных объяснений, которые отвечают на большую часть вопросов: ➖ Что такое модель и почему она «учится»; ➖ Что значит ошибка и качество; ➖ Зачем делить данные на train/test; ➖ И почему модели иногда «переучиваются». Издание довольно новое (2024 года), и закрывает весь стек классического ML. 📖 Ссылка на PDF 📗 Джейк ВандерПлас «Python для сложных задач» Это отличное практическое дополнение к теории. Несмотря на устрашающее название, в книге понятно и на примерах объясняются все базовые инструменты и библиотеки дата-сайентиста: NumPy, Pandas, визуализация и базовый ML через sklearn. Хоть DS и считается исследовательско-математическим направлением, все идеи и алгоритмы реализуются через Python, поэтому его знание необходимо. 📖 Ссылка на PDF 📘 В. Савельев «Статистика и котики» Если первые две книги дают понимание машинного обучения и практики, то эта очень мягко вводит в статистическое мышление. В книге удивительно просто объясняются сложные статистические явления — без перегруза и без ощущения, что ты снова на парах в университете 😄 Можно наконец-то осознать: ➖ Почему маленькие выборки могут легко вводить в заблуждение; ➖ Почему любые «примерные оценки» всегда с погрешностью и почему это нормально; ➖ И как перестать воспринимать цифры как что-то точное, а начать видеть в них неопределённость. И всё это через простые, жизненные примеры. 📖 Ссылка на PDF В итоге получается очень комфортная траектория: ➡️ «Грокаем» — чтобы понять основы ML; ➡️ Python ВандерПласа — чтобы начать делать руками; ➡️ «Статистика и котики» — чтобы научиться мыслить аналитически. На такую базу можно уже «наращивать» более сложный материал. Сохраняйте, чтобы не потерять ❤️

Полезные инструменты и библиотеки для MLOps Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻 Когда впервые сталкиваешься с MLOps, бывает сложно понять, для чего нужно такое множество инструментов и почему production не может без них жить. Чтобы понять важность MLOps-инструментов, давайте разберём типичный ML-пайплайн по шагам. 1️⃣ Сначала вы обучаете модель и начинаете экспериментировать: пробуете разные признаки, гиперпараметры, алгоритмы. Довольно быстро становится неудобно хранить результаты «вручную» — в блокнотах, Excel или названиях файлов вроде final_model_v2_last_really_last 😁 И как раз для этого существуют трекеры экспериментов: MLflow, Weights & Biases, ClearML! Они автоматически сохраняют параметры запуска, метрики, версии датасетов, модели, графики обучения и артефакты. Благодаря им потом можно нормально сравнивать эксперименты и наглядно видеть, почему одна версия модели сработала лучше другой. 2️⃣ Теперь представим, что ваша модель оказалась успешной, и её нужно выкатить в production — к примеру, рекомендательную систему. Что это значит? Как минимум то, что пользователи теперь должны регулярно получать актуальные рекомендации от вашей модели — а для этого её нужно регулярно перезапускать. Если взять типичный пайплайн, то скорее всего, он будет состоять из нескольких частей: выгрузить свежие данные, подготовить датасет, обучить модель, провалидировать качество, сохранить артефакты, залить новые предсказания в базу или обновить сервис. И всё это должно происходить строго по порядку. Делать такое руками каждый день довольно быстро становится невозможно. Особенно если пайплайнов несколько, а задач десятки… К счастью, для этого существуют оркестраторы: Airflow, Prefect, Luigi. Они позволяют описывать ML-процессы как последовательность задач и автоматически запускать их по расписанию. Плюс они умеют отслеживать статус задач, самостоятельно перезапускать упавшие этапы, хранить логи и строить зависимости между шагами пайплайна. По сути это инструмент для автоматизации и управления сложными процессами. 3️⃣ Также при выкатке в прод почти все сталкиваются с проблемой: «локально всё работает, а на сервере внезапно нет». Причины могут быть разные — например, другая версия Python, не та версия библиотеки, отсутствует нужный пакет, или модель вообще ведёт себя по-другому из-за окружения. Чтобы проект запускался одинаково на любой машине, используют Docker: он позволяет упаковать приложение вместе со всеми зависимостями, библиотеками и настройками в отдельный контейнер. Благодаря этому можно один раз собрать окружение и потом запускать его где угодно: локально, на сервере, в облаке или у другого разработчика в команде. Концепция Docker уже давно стала стандартом для ML, да и в принципе в разработке. 4️⃣ А уже после выкатки модели обычно хочется понимать, не упал ли сервис, не начала ли модель отвечать слишком медленно, не закончилась ли память, не выросла ли нагрузка на сервер. Для ответа на эти вопросы обычно используют связку Prometheus + Grafana. Prometheus — это система сбора метрик, она регулярно ходит в сервисы и собирает техническую информацию: нагрузку CPU, использование памяти, время ответа, количество запросов, ошибки и другие показатели. А Grafana — это инструмент для визуализации этих данных. В ней можно подключать разные источники данных и через UI собирать дашборды с графиками, таблицами и мониторингом сервисов. 5️⃣ А когда ML-систем становится много — появляются Kubernetes, feature store, CI/CD и другие инфраструктурные инструменты. Но это уже следующий уровень зрелости проекта. Так что каждый инструмент MLOps решает вполне конкретную практическую проблему, с которой рано или поздно сталкивается любая ML-команда. Сохраняйте, чтобы не потерять ❤️

Привет! Снова на связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻 Сегодня вечером снова приду на эфир — разберём, как выглядит подготовка датасетов в реальных проектах и пошагово пройдём по базовой «рутине» дата-сайентиста: 1️⃣ Дубликаты…