Как правильно выбрать метрики в 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 и математика не нужны — стартуем с азов, а разбираться в непонятных местах будет с кем. Буду ждать вас на интенсиве!

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

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