Комментарии 23
Моделирование в работе ML-инженера занимает меньше 20% времени
А можно расписать собственно кто такой ml инженер и в чём его работа? Я ковырял ml модели и сделал сервис на их основе. Прикольно, подумал я и начал задумываться "может быть из backend когда-нибудь в ml перейти?". Но не понятно, чем придётся заниматься в качестве ml инженера. В обучении ml оно как происходит - вот мне дали данные, я выбрали модели, протестировал, выбрал лучшую, радуюсь. Какие тут вещи повседневно надо делать помимо оборачивания в сервис? Получение и очистка данных это тоже работа ml инженера? Можно ли сказать, что ml инженер это программист, который делает сервисы, но при этом специализируется на определённом классе задач и владеет статистикой для оценки работоспособности своих решений?
Очень, кстати интересный вопрос, я тоже задумывался над тем же самым.
Вот отличный материал по теме: Workera AI Career Pathways
Если кратко, то вот сравнение ML-профессий:
Описание типичных задач предлагаю посмотреть в документе.
Спасибо большое за очень хороший вопрос.
Идём по порядку. Инженер машинного обучения end-2-end специалист.
Один из ключевых навыков - это продуктовое мышление и способность быстро освоиться в новом домене, понять, где бизнес получает или теряет деньги, какую ценность мы даем пользователю и какую роль в каком месте какой цепочки играет или будет играть ML сервис. Отсюда: поговорить с заказчиками, аналитиками, бекендерами, разобраться что и как работает сейчас с разных сторон, понять какую цель или боль бизнеса покроем.
Следующий пласт навыков - ML System Design. Умение декомпозировать большой проект на составляющие (примерный план упомянут в статье во 2 пункте).
Датасет никто за вас не подготовит, поэтому SQL и навыки работы с БД (включая аналитические) также входят в наш инструментарий. Также в больших компаниях нужно работать с распределенными системами, HDFS или, доводилось, ODPS. Здесь какие-то азы из дата инженерии лишними не будут. В каком-то случае нужные под задачу данные еще не собираются, соответственно нужно дата инженеру или бекендеру сформировать набор требований. К этому же кластеру отнесем data quality, методы препроцессинга, чистки, мониторинга данных.
Само машинное обучение - отдельная большая тема. Умение быстро разобраться в новой или старой задаче; читать научные статьи, искать имплементации, знать что как запускать, валидировать, оценивать в оффлайн/онлайн.
Сюда же включим навыки писать качественный код на Python, включая оптимизацию, тестирование (как общее, так и специфическое для ML кода), дебаг и остальное.
Первая версия построена - вопросы интеграции, деплоя. Какие-то базовые вещи из MLOps будут не лишними: написать CI/CD, завести версионирование моделей, версионирование данных. Мониторинг моделей.
Навык дизайна А/Б экспериментов. Отдельная большая тема. Не всегда в компании есть платформа А/Б или выделен аналитик. Всегда нужно понимать что тестируем, как и на что это повлияет, отдельная тема для исследования в каждой отдельной задаче как мы оцениваем ожидаемый эффект в онлайн метриках по оффлайн метрикам.
Ну и широкий спектр soft skills: навык презентации, объяснение что мы сделали или что будем делать (так чтобы было понятно человеку без математического склада ума), работа с разными командами, приоритизация, дисциплина, всё всё.
Надеюсь, верхнеуровнево обрисовал
Я так понимаю это к сеньору требования, т.е. то, к чему надо стремиться?
От джуна ждут что у него всего, каждого пункта, понемногу либо на поверхностном уровне. Например, джун не участвовал в проведении реальных А/Б, поэтому от него ждут уверенной ориентации в статистической терминологии, но не более; не дизайнил системы, не имеет насмотренности, поэтому здесь от него ждут больше здравого смысла в рассуждениях о том как применить ML, а не способности за 45 минут задизайнить с нуля новый для себя ML сервис.
В Яндекс-практикум предлагают такие характеристики профессий:
Аналитик данных — помогает бизнесу принимать решения на основе данных;
Специалист по Data Science — исследует данные с помощью алгоритмов, чтобы найти неочевидные закономерности;
ML-инженер, скорее всего, человек, который может работать в одной из этих профессий, но с большем акцентом на инженерную, а не исследовательскую деятельность. Хотя моя версия - только личное мнение, основанное на логических умозаключениях.
Постараюсь ответить. Есть такое понятие как data scientist под которым часто путают ML-инженера, но на самом деле это набор профессий (аналитик, дата инженер, ML-щик) как computer scientist - программист, но так никто не говорит.
Работа ML-инженера состоит из 3-х этапов:
1) Сбор и подготовка данных. Сюда входит написание sql и mapreduce запросов, аугментация и синтез данных, их очистка от ненужных признаков, заполнение пропусков, приведение к одному виду и т.д.
2) Подбор, обучение или создание модели, оценка её качества - здесь мы можем выбирать готовую модель и обучать на ней данные или создавать собственную. Нужно хорошее понимание как работает каждая модель изнутри, а для этого нужна неплохая математика.
3) Вывод в продакшн и поддержка. Когда модель готова и хорошо справляется с поставленном задачей, то нужно её внедрить в продукт, запустить на серваке, проверить как она работает в реальных условиях. Тут уже пригодятся всякие докеры, линуксы и т.д. Также иногда бывает, что модель учат на питоне, а в прод тащат на плюсах или джаве.
В data science есть куча направлений:
аналитики, которые используют ML для предиктивной аналитики и которые этого не умеют и просто рисуют дэшборды в Power BI;
дата-инженеры: админы баз данных, sql-разработчики, cloud-разработчики и т.д.;
ML-щики: classic ML и deep learning (NLP, CV, ASR и т.д.);
reseearch ML - те, кто разрабатывает новые модели и нейросети;
ML-ops - девопсеры, знающие специфику работы с ML.
Ещё ML-инженеры могут очень сильно разниться по скиллам и задачам: кто-то пользуется готовыми моделями без понимания как они работают - это плохие ML-инженеры, а кто-то умеет их реализовывать с нуля самостоятельно, что говорит о том, что человек имеет очень глубокое понимание как всё устроено изнутри и у такого специалиста модель никогда не накроется, кто-то просто учит модели, а кто-то делает всё подряд.
Хороший ML-инженер - это всё, что я описал выше и даже больше, и это уровень хорошего джуна, но очень часто от них требуют гораздо меньше. К слову, алгоритмы и системный дизайн тоже нужно знать.
Уважаемый автор, написано очень интересно. Задумываюсь о переквалификации из бэкенда и у меня к вам пару вопросов.
1. Исходя из вашего опыта, насколько важно иметь математический бэкграунд?
2. Сколько, по вашему мнению, мне может понадобиться, чтобы стать ML джуниором, в моем случае? Имеется в виду самостоятельное обучение. Курсы и т.п.
У меня высшее техническое, опыт в ИТ с безостановочным обучением и разными сертификатами от Microsoft, IBM и AWS - 20 лет.
Ни с Docker, ни с языками программирования проблем нет.
Не автор, но попробую ответить. Чтобы работать на профессиональном уровне, желательно хотя бы в первом приближении понимать, как работают все этим модели. Для этого нужна математика, но совершенно базового уровня: линейная алгебра, матан, теорвер, статистика, численные методы. В принципе это должны давать в вузе по многим техническим специальностям. Собственные оригинальные модели вы разрабатывать или реализовывать вряд ли будете, это все уже есть в библиотеках и гитхабе. Но что куда втыкать и почему, понимать крайне желательно.
Если хочется просто попробовать и понять насколько это вам подходит и интересно, есть kaggle, где можно позатягивать разные соревнования.
Спасибо за приятный отзыв,
Знаю много матёрых коллег которые пришли в ML из гуманитарных наук, в ML нет сложной математики. Вот к примеру 4 странички (алгебра, матан, диффуры, теорвер) необходимого минимума для Deep Learning (http://www.d2l.ai/chapter_preliminaries/linear-algebra.html). Сложной математики в ML нет, более того, чтобы применять ML и строить ML сервисы её знать необязательно. Да, это во многих местах ускоряет поиск проблем или даёт идеи попробовать нестандартные метрики, нестандартные модификации моделей – но такое пригождается нечасто.
Дам консервативную оценку, за 4-6 месяцев или даже быстрее сможете. Тем более, с таким опытом в бекенде. Многие чисто технические вещи будут даваться быстро. Вопрос чисто в усидчивости.
Не соглашусь по поводу математики: если вы работаете в research отделе и разрабатываете, например, алгоритмы компьютерного зрения, то здесь тоже нет сложной математики? Сингулярное разложение матриц, дискретное преобразование Фурье и т.д. - это всё нужно понимать и с нуля это быстро изучить не получится, увы.
Всё сильно зависит от задач и компании: если шатать регрессию в банках, то сильно знать математику мб и не стоит, но если заниматься всякими чатами GPT, беспилотниками и т.д., то здесь уже описанный вами подход не прокатит.
Сингулярное разложение это простая математика. Я писал по нему курсовую, включая тензорное расширение. Берешь находишь перпендикулярные друг другу вектора, так чтобы аппроксимировать исходные данные минимизируя фробениусову норму. За два-три вечера можно разобраться.
В deep learning тоже не знаю где там сложности. Никаких тебе интегральных и вариационных исчислений, знаний 11 класса про первую-вторую производную достаточно.
Кстати, @uberkinderбольшое спасибо за ваш ответ выше. Я поверил в себя, осознал, что можно начинать и без 5-ти лет обучения в физ мате и записался на один из курсов по машинному обучению :)
Сейчас прохожу мини-курс по линейной алгебре. Далее в программе курса будут Производные, Градиенты, Линейные модели и т.п.
Понятно, что этим дело не ограничится, и нужно будет снова и снова углубляться в теорию.
Но, главное, начало положено :) Ещё раз спасибо :)
Полноценный дизайн-документ для более долгосрочных ML-проектов требует более глубокой проработки и включает в себя
…
● описание онлайн и оффлайн метрик;
Что подразумевается под оффлайн и онлайн метриками? Правильно ли я понимаю, что на оффлайн мы обучаем модель, а онлайн показываем бизнесу?
Есть три уровня метрик: офлайн, онлайн и бизнес-метрики. Офлайн метрики - это как раз наши accuracy, recall, precision - всё, что можно измерить на модели без пользователей. Далее. Вы построили модель машинного обучения, максимизировали скажем recall и теперь хотите посмотреть, на что это влияет. Вы деплоите модель и смотрите как она влияет на средний чек, конверсию и пр. Эти метрики необходимо измерять на живых пользователях, поэтому это и называется онлайн-метрики. Здесь уже нужны АB тесты, чтобы понять, что после внедрения вашей модели онлайн-метрика изменилась и это не просто случайное совпадение.
Да, как верно сказано выше, offline-метрики можно посчитать на исторических данных, online-метрики только в боевых условиях. Оффлайн мы можем посчитать быстро не рискуя пользователями. Онлайн только в ходе А/Б или пилота (что "долго", но ближе к цели проекта).
Не всегда онлайн-метрики в ходе АБ совпадают с целью проекта. Например, хотим увеличить на 20% месячный оборот, в качестве хорошей прокси-метрики подойдёт средняя выручка на 1 клик. Прокси-метрика – косвенная метрика, коррелирующая с данной, но обладающая другими полезными свойствами, например, её быстрее посчитать, более чувствительна и т.д.
Хорошо выбранные оффлайн метрики будут хорошими прокси для наших онлайн метрик. Конкретно оценить ожидаемый прирост по онлайн зная прирост по оффлайн (прикинуть MDE) очень сложно.
Либо у нас есть история АБ и мы примерно знаем что каждые X% прироста по такой-то оффлайн метрике (например nDCG, ERR, PFound) дают в среднем прирост на Y% по такой-то онлайн метрике (например CTR)
Либо мы делаем симуляцию среды в которой будет находиться модель (разработка может быть очень трудоемкой и легко занять месяц).
Либо пытаемся строить корреляцию на истории, если для этого собирались данные по текущему сервису.
Есть также квази-онлайн метрики - валидация от разметчиков (релевантная / нерелевантная выдача; матч / не матч). Они занимают промежуточное место между оффлайн и онлайн, их дольше считать (ручной труд), но мы не рискуем реальными юзерами.
А где, кстати, принято сейчас размечать данные? Вот есть Толока, а ещё?
Кроме Толоки, из русских, знаю, у мейл.ру были разметчики. Но знакомые говорят что собираются отказываться от них в пользу Толоки.
Из зарубежных много говорят про Scale AI, "толоку на стероидах".
Далее цитирую Игоря Котенкова:
Еще ~год назад я увидел, что OpenAI пользуются их [Scale AI] услугами для найма контрактных сотрудников, которые будут помогать готовить данные для моделей, основанных на GPT (включая ChatGPT?). Вот он, успех :)
Документация облегчает коммуникацию с другими командами, сохраняет актуальный контекст проекта и уменьшает Bus Factor…
Bus Factor (согласно этой же ссылке) — количество программистов, которые должны «попасть под автобус», чтобы проект остановился. То есть наоборот, документация помогает повысить фактор.
ARIMA лучше по скорости чем gradboosting...? Вот ни разу не видел ARIMA в проде, и сам сколько не работал с ней - плевался. Конечно, если надо посчитать 1 мини-ряд на 100-200 значений, то все хорошо. А вот если запустить оптимизатор авто-аримы на нормальном датасете с несколькими десятками тысяч значений (я не говорю про сотни тысяч и миллионы), то она улетит по времени далеко за все известные градиентные бустинги. Лучше уже тогда наделать lag-фичей shift'ом, понасчитать разности ряда и тд, и использоавть линейную модель, чем Arima (это моя личная боль xD). Да я даже нейросетки больше люблю, чем arima))
10 первых ошибок в карьере ML-инженера