Как вырасти в ML? Что меняется, когда повышается ответственность

Про рост в ML часто говорят как про набор навыков: продакшен, инфраструктура, MLOps, ещё несколько технологий. Кажется, этого достаточно для следующего шага в карьере. Но на практике важнее не стек, а подход: как вы влияете на продукт, качество и надёжность ML-систем. В историях выпускников курса «Практическая ML-инженерия» разбираем:

1. Почему для Senior AI Engineer одного backend-опыта мало.

2. Как перестать быть «человеком с ноутбуком» и начать влиять на продукт.

3. Чем ML/AI полезны тимлиду по автоматизации (RPA + AI) в США?

Рост в роли начинается с того, что вам дают более размытые задачи

Саша Пулинец

Senior AI Engineer, MWS

До курса Саша работал в испанском стартапе по геоанализу данных и в «Честном знаке». Делал AI-агентов, агентские системы, местами занимался деплоем и дообучением LLM. Параллельно была обычная инженерная работа: AWS, Docker, Kubernetes, backend. На курс пришел в первую очередь для поступления в магистратуру. 

Первоначально курс рассматривался как шаг для поступления в AI Talent Hub — на выходе был проект, который можно подать на JMLC. Но ключевой интерес был в MLOps-блоке.

Где вырос

MLOps дал именно то, чего не хватало:

• инструменты отслеживания экспериментов,

• понимание пайплайнов,

• инженерная обвязка вокруг модели,

• Airflow — как инструмент, который регулярно встречается в требованиях.

«Airflow был приятным бонусом и даже своего рода понтом на собеседованиях — интервьюеров это приятно удивляло».

Что изменилось в работе

С ноября Саша перешел в MWS (Cloud-платформа МТС) на позиции Senior AI Engineer. Главное изменение — тип задач. Раньше чаще был понятный кусок работы. Сейчас чаще есть проект и примерные требования, а дальше решение нужно собирать самому. Саша хорошо формулирует разницу между middle и senior: senior можно поставить задачу менее подробно и дать больше свободы в архитектурных и технологических решениях.

«Теперь я Senior AI Engineer, уровень задач стал более “синьерский”: нужен проект, вот примерные требования, занимайся сам, мы тебя не трогаем —  то есть больше свободы в разработке, больше доверия, ну и ответственность тоже больше. Зарплата тоже стала больше —  в 2 раза, что приятно».

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

Рост внутри роли начинается с языка, на котором вы говорите о задаче

Далер Хомидов

Middle DS в Сбере

До повышения Далер работал MLE в WinSolutions / AvaGroup. В основном он брал задачи частичного цикла: классический DS-пайплайн — EDA, выбор алгоритмов, обучение моделей, тюнинг метрик. Деплой, мониторинг и интеграция в инфраструктуру чаще оставались на стороне IT-команд или ограничивались «ручным» запуском скриптов.

Технически уровень был хороший, но мышление оставалось в рамке «модель — метрики — код».

«Не хватало структурированного подхода к оценке бизнес-ценности. Как перевести улучшение метрики в язык выгод для бизнеса? Как упаковать и презентовать решение стейкхолдерам?»

Именно здесь возникало ограничение — не столько в технологиях, сколько в уровне влияния.

Где вырос

Самый сильный сдвиг Далер связывает с переходом от «модели в ноутбуке» к продуктовому мышлению. ML-решение перестало быть просто моделью с accuracy 95%. Оно стало частью бизнес-процесса, где нужно отвечать на вопросы: какую ценность создает, как будет поддерживаться, какие риски есть в эксплуатации и как ими управлять.

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

«Это заставляет мыслить не как человек, который просто обучает модель, а как тот, кто отвечает за весь цикл — от PoC до прода».

Что изменилось в работе

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

В текущей роли это дало возможность претендовать на задачи уровня Middle+ / Senior — там, где требуется не «код в ноутбуке», а системное видение.

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

Как он видит разницу ролей

Для Далера ML-инженер — более широкое понятие, чем MLE в узком смысле.

Если MLE часто фокусируется на данных и модели, то ML-инженер — это мост между Data Science и Software Engineering. Это специалист, который одинаково хорошо понимает и как обучить модель, и как написать production-ready код на Python, спроектировать API и настроить CI/CD пайплайн, а также имеет настроенность и может объяснить бизнесу свои решения.

Можно вырасти без смены должности, если меняется уровень инженерной работы

Анатолий Банников

Lead, RPA и AI в компании “N” в США

На момент старта Анатолий уже был тимлидом в компании в США, вел направление автоматизации, в том числе RPA и AI и многолетний управленческий и инженерный опыт. 

Однако автоматизация все чаще упиралась в задачи, где одних правил и классического RPA было недостаточно. Все чаще возникал вопрос: как правильно встроить ML/AI в процессы — и где это действительно оправдано.

«Хотелось собрать целостную картину: как устроены такие решения, какие у них ограничения, что нужно для нормального продакшена».

Где вырос

«Пришло понимание, что модель — это лишь небольшая часть системы».

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

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

Что изменилось в работе

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

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

Чеклист: как перейти на новый уровень ответственности

1. Рост начинается там, где появляется неопределенность

Middle чаще получает уже нарезанную задачу. Следующий уровень начинается там, где рамку задачи нужно собирать самому:

• уточнять требования;

• выбирать архитектуру;

• объяснять компромиссы;

• отвечать за последствия.

2. Модель перестает быть финальной точкой

Раньше результатом была модель. Теперь результат — рабочее решение:

• сервис;

• интеграция;

• продакшен;

• мониторинг;

• поддержка;

• понятная ценность для бизнеса.

3. Времени до кода становится больше

Это повторяется в каждой истории в своем виде:

• спецификация;

• требования;

• проверка гипотез;

• рамка решения;

• риски.

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

4. У роста нет одного сценария, каждый кейс уникален :)

Что можно забрать из этих историй, если вы сейчас на уровне middle

1. Сначала собирайте рамку задачи

До выбора модели ответьте на вопросы:

• что считаем успехом;

• где будет эффект;

• кто будет пользоваться решением;

• что нужно после релиза.

2. Берите на себя кусок системы шире, чем обучение модели

Даже если вы DS, полезно разбираться в:

• сервисном слое;

• пайплайнах;

• мониторинге;

• эксплуатации.

3. Учитесь объяснять решение

Рост в ML сильно зависит от того, как вы разговариваете:

• с бизнесом;

• с backend и DevOps;

• с командой;

• со стейкхолдерами.

4. Не путайте скорость с быстрым стартом

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

Вывод

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

Курс «Практическая ML-инженерия: MLOps и разработка проектов» стартует 13 марта. Его структура объясняет, почему у выпускников получаются похожие карьерные сдвиги:

1. Разработка ML-сервиса
   Python, FastAPI, дизайн API, backend-часть, запуск и эксплуатация.

2. MLOps
   Оркестраторы, версионирование данных, эксперименты, model registry, model serving, CI/CD.

3. Полный цикл ML-продукта
   От выбора задачи и бизнес-анализа до MVP, интеграции, мониторинга и презентации результата.

Когда специалист проходит весь цикл целиком — меняется способ мышления и уровень ответственности и траектория карьеры.