Между тем, как выглядит ML в курсах и соревнованиях, и тем, как он устроен в реальной повседневной работе — разница намного больше, чем кажется
Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻
Разберём три вещи, которые удивляют почти всех, кто переходит в ML. Речь не про «недостаточное знание алгоритмов» — поговорим про разрыв ожиданий и реальности самой роли.
1️⃣ Работа с данными — это больше половины времени, а не «быстрый подготовительный этап»
В голове новичка проект устроен так: сначала быстренько готовим данные за пару часов, а дальше начинается «настоящая работа» — модели, гиперпараметры, метрики. В реальности пропорции обратные: львиную часть времени занимают подготовка, чистка, стыковка источников, разбирательства «а почему у нас в одной таблице user_id — int, а в другой — string», проверка на утечки, построение фичей…
И это не из-за того, что в больших компаниях данных много и они всегда грязные. А потому что понимание данных — это и есть залог успешного моделирования. Важно понимать, что высокого качества ML-алгоритма можно достичь далеко не только благодаря SOTA-моделям, а часто благодаря качественно подготовленным данным для обучения.
На соревнованиях и в учебных проектах для новичков этого разрыва часто не видно, потому что там датасеты уже отобраны, размечены и разложены по табличкам. А в проде могут быть несколько источников, у каждого свой владелец, у каждого свои представления о качестве, и никакого единого эталона нет.
2️⃣ Модель — это маленький кусочек системы, а не её центр
Ещё одно открытие, которое приходит только с опытом: сама модель — обычно самая простая часть проекта. Поставить на обучение в сотый раз CatBoost — дело нескольких минут. А вот вокруг модели живёт целая инфраструктура, которую и надо уметь строить для каждого случая индивидуально:
➖ Откуда берутся фичи в проде и совпадают ли они с тем, на чем модель обучалась;
➖ Что происходит, если модель упала или отвечает слишком долго;
➖ Как её версионировать, откатывать, катить постепенно;
➖ Как понять, что она устарела и её пора переобучать.
Джун обычно приходит с мыслью «я умею обучать модели» — но это лишь входной билет, а настоящая работа начинается там, где модель едет в прод. Именно поэтому в вакансиях ML-инженера всё чаще появляются требования, схожие со списом инструментария бэкенд-разработчика — Python на приличном уровне, Docker, Kubernetes, CI/CD, базы данных, очереди, стриминг. Без этого модель так и остаётся Jupyter–ноутбуком.
3️⃣ Коммуникация с бизнесом — часть роли, а не «пусть менеджеры этим занимаются»
Самая недооценённая часть работы, особенно у технически сильных ребят. Мысль «я делаю модель, а с бизнесом пусть говорит продакт» — очень частая, и очень мешающая.
Проблема в том, что ML-задачи почти никогда не приходят в готовом виде. «Хотим предсказывать отток» — это не задача, это направление для размышлений. Что считать оттоком? На каком горизонте? Что с этим предсказанием потом делать — рассылать промо, звонить, менять тариф? Какая цена ошибки в одну и другую сторону? Ответы на эти вопросы определяют всё — от разметки до выбора метрики — и получить их можно только в разговоре с бизнесом.
Опытные ML-инженеры эту часть тащат самостоятельно: они умеют прийти с правильными вопросами, объяснить ограничения модели без матана, показать “вот здесь можно сделать точнее, но это займёт месяц — стоит ли оно того?”. Джун же часто молча берёт задачу как есть, несколько недель что-то делает, приносит результат — и выясняется, что решал совсем не ту проблему.
Это не про софт-скиллы в вакууме, а про то, что без предварительной коммуникации технически идеальная модель может оказаться никому не нужной.
Что делать с этой информацией?
Плохая новость: по туториалам и соревнованиям всего это не выучить 🙂 Там просто нет таких данных, такой инфраструктуры и такого контекста.
Хорошая — этому можно научиться, но нужна структурированная программа, где рядом с алгоритмами разбирают инфраструктуру, работу с реальными грязными данными и постановку задач от бизнеса.
Именно поэтому у нас на курсе эти три темы вплетены в каждый модуль, а не вынесены в «дополнительные материалы для интересующихся». Без них ML-инженер быстро упирается в потолок «человека, который умеет обучать модели», а роль требует сильно большего.
Сохраняйте, чтобы не потерять! ❤️
Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻
Разберём три вещи, которые удивляют почти всех, кто переходит в ML. Речь не про «недостаточное знание алгоритмов» — поговорим про разрыв ожиданий и реальности самой роли.
1️⃣ Работа с данными — это больше половины времени, а не «быстрый подготовительный этап»
В голове новичка проект устроен так: сначала быстренько готовим данные за пару часов, а дальше начинается «настоящая работа» — модели, гиперпараметры, метрики. В реальности пропорции обратные: львиную часть времени занимают подготовка, чистка, стыковка источников, разбирательства «а почему у нас в одной таблице user_id — int, а в другой — string», проверка на утечки, построение фичей…
И это не из-за того, что в больших компаниях данных много и они всегда грязные. А потому что понимание данных — это и есть залог успешного моделирования. Важно понимать, что высокого качества ML-алгоритма можно достичь далеко не только благодаря SOTA-моделям, а часто благодаря качественно подготовленным данным для обучения.
На соревнованиях и в учебных проектах для новичков этого разрыва часто не видно, потому что там датасеты уже отобраны, размечены и разложены по табличкам. А в проде могут быть несколько источников, у каждого свой владелец, у каждого свои представления о качестве, и никакого единого эталона нет.
2️⃣ Модель — это маленький кусочек системы, а не её центр
Ещё одно открытие, которое приходит только с опытом: сама модель — обычно самая простая часть проекта. Поставить на обучение в сотый раз CatBoost — дело нескольких минут. А вот вокруг модели живёт целая инфраструктура, которую и надо уметь строить для каждого случая индивидуально:
➖ Откуда берутся фичи в проде и совпадают ли они с тем, на чем модель обучалась;
➖ Что происходит, если модель упала или отвечает слишком долго;
➖ Как её версионировать, откатывать, катить постепенно;
➖ Как понять, что она устарела и её пора переобучать.
Джун обычно приходит с мыслью «я умею обучать модели» — но это лишь входной билет, а настоящая работа начинается там, где модель едет в прод. Именно поэтому в вакансиях ML-инженера всё чаще появляются требования, схожие со списом инструментария бэкенд-разработчика — Python на приличном уровне, Docker, Kubernetes, CI/CD, базы данных, очереди, стриминг. Без этого модель так и остаётся Jupyter–ноутбуком.
3️⃣ Коммуникация с бизнесом — часть роли, а не «пусть менеджеры этим занимаются»
Самая недооценённая часть работы, особенно у технически сильных ребят. Мысль «я делаю модель, а с бизнесом пусть говорит продакт» — очень частая, и очень мешающая.
Проблема в том, что ML-задачи почти никогда не приходят в готовом виде. «Хотим предсказывать отток» — это не задача, это направление для размышлений. Что считать оттоком? На каком горизонте? Что с этим предсказанием потом делать — рассылать промо, звонить, менять тариф? Какая цена ошибки в одну и другую сторону? Ответы на эти вопросы определяют всё — от разметки до выбора метрики — и получить их можно только в разговоре с бизнесом.
Опытные ML-инженеры эту часть тащат самостоятельно: они умеют прийти с правильными вопросами, объяснить ограничения модели без матана, показать “вот здесь можно сделать точнее, но это займёт месяц — стоит ли оно того?”. Джун же часто молча берёт задачу как есть, несколько недель что-то делает, приносит результат — и выясняется, что решал совсем не ту проблему.
Это не про софт-скиллы в вакууме, а про то, что без предварительной коммуникации технически идеальная модель может оказаться никому не нужной.
Что делать с этой информацией?
Плохая новость: по туториалам и соревнованиям всего это не выучить 🙂 Там просто нет таких данных, такой инфраструктуры и такого контекста.
Хорошая — этому можно научиться, но нужна структурированная программа, где рядом с алгоритмами разбирают инфраструктуру, работу с реальными грязными данными и постановку задач от бизнеса.
Именно поэтому у нас на курсе эти три темы вплетены в каждый модуль, а не вынесены в «дополнительные материалы для интересующихся». Без них ML-инженер быстро упирается в потолок «человека, который умеет обучать модели», а роль требует сильно большего.
Сохраняйте, чтобы не потерять! ❤️