Я хотел бы возразить, что определенная работа или роль важнее, чем можно предположить по сегодняшнему размеру ее рядов, и что ее важность даже возрастет. Уже существует множество сбивающих с толку профессий, связанных с данными и машинным обучением, поэтому первый вопрос: зачем иметь другую или чем она отличается?
Мотивация, стоящая за моей мыслью, заключается в том, что многие компании, похоже, изо всех сил пытаются воспользоваться преимуществами данных с помощью машинного обучения, несмотря на наличие значительных отделов для этой цели и несмотря на множество достижений в технических и научных областях. Я мог бы, вероятно, процитировать какой-нибудь технический документ из Гарвардского бизнес-обзора из Magic Gartner Quadrant под названием Business Not Reaping ML Benefits Enough, но мне лень его искать, вам будет лень его читать, да и исследование, скорее всего, в любом случае будет ошибочным. . Я имею в виду, что все, что называется Мегатенденции в цикле шумихи, — это своего рода sus.
Так что давайте просто останемся на уровне чистой мысли и анекдотических свидетельств.
Аспекты ролей машинного обучения
Типичные требования к работе для списка должностей ML / Data: знание фреймворков для машинного обучения (Tensorflow, Keras) и обработки данных (Pandas, Spark), университетская степень или самостоятельное понимание теоретических основ машинного обучения и некоторое универсальное программное обеспечение. инженерные навыки.
По-разному, у вас может быть послужной список академических публикаций, вы можете сосредоточиться на определенной области (распознавание изображений, обучение с подкреплением) или владеть некоторыми облачными инструментами или средами развертывания.
В процессе собеседования кандидата просят решить некоторые проблемы с искусственными данными и продемонстрировать технические знания. Часто это сопровождается шутливыми замечаниями о том, что большая часть работы связана с собраниями и очисткой данных.
Давайте теперь поместим такую роль в контекст жизненного цикла бизнеса. Для упрощения я считаю жизненный цикл проектов (продуктов) состоящим из:
- Идеи — например, разговоры с потенциальными клиентами, слежка за конкурентами, размышления (из рабочего кабинета);
- Исследование — например, выполнение PoC и макетов, представление потенциальным пользователям, проведение маркетинговых исследований;
- Реализация — например, разработка фактического кода;
- Техническое обслуживание — например, продажи, поддержка клиентов, мониторинг облачной инфраструктуры, исправление ошибок.
Большая часть того, что мы понимаем под прикладной работой по машинному обучению, прочно относится к этапу реализации — очистке данных, обучению модели, развертыванию модели. Существует также большая часть деятельности по обслуживанию (анализ изменения производительности/концепции), обычно называемая MLOps.
Иногда в разведке есть активность (например, разработка модели PoC), но часто сначала «недостаточно данных». ML намного проще придумывать и развертывать при улучшении существующих эвристических/человеческих процессов.
Идеальная задача специалиста по машинному обучению включает в себя полное определение задачи (распознавание рукописной цифры), критерии приемлемости (границы показателей производительности) — чтобы они могли затем начать делать то, для чего они были обучены, все функции разработки. , выбор модели, настройка гиперпараметров…
Таким образом, если МО должно принести потенциал не только как постепенное улучшение существующих четко определенных задач (рейтинг кликов, отток и т. д.), но и как прорывная инновация, кто-то должен быть в состоянии придумать проекты, которые используют потенциал МО, и сформулировать их. , или их части, как проблемы ML. И этот человек должен быть очень деловым/клиентским здравым смыслом. Иногда отделы машинного обучения рассматриваются как черный ящик, в который вы заливаете данные, а инновации вытекают наружу, но, исходя из моего ограниченного опыта, это не так.
Текущие исследования ML, вероятно, не слишком сосредоточены на деревьях решений или линейных регрессиях, поскольку они уже «научно скучны» — их потенциал понятен, лучшие практики их использования определены. Практик может даже уклоняться от их использования и тратить время на их точную настройку для конкретной проблемы, вместо того, чтобы владеть какой-то мощной универсальной архитектурой нейронной сети, которая обобщает гораздо более высокий класс проблем «сама по себе» или обещает бумажную публикацию. кроме того.
Тем не менее, вероятно, остается много неиспользованных возможностей для бизнеса, которые можно было бы использовать только с помощью основных методов. Недавно я решил две простые, но важные задачи, связанные с временными рядами потребления электроэнергии и классификацией/прогнозами, просто наблюдая на глаз, какие функции и коэффициенты может использовать линейный алгоритм — и это было достаточно для бизнес-требований.
Эволюция специалиста по машинному обучению
Я абсолютно не утверждаю, что исследования в чистом виде ML не нужны или что все можно решить простыми методами.
Но с улучшением доступности машинного обучения или даже появлением технологий AutoML в таких предложениях, как Google Vertex, для стартапа или инновационного отдела становится менее важным нанимать экспертов с глубоким знанием различных методов машинного обучения — ограниченная интуиция что может/должно работать, понимание того, как проверить, действительно ли это работает, понимание роли меток, знание когда вызвать настоящего эксперта по машинному обучению и т. д. может быть достаточным.
Людей, занимающихся этапом формирования идей и передающих требования инженерам-программистам для реализации, обычно называют менеджерами по продукту и UX-дизайнерами. Требования к их работе сильно отличаются от требований к машинному обучению — не столько технических, сколько навыков общения, презентации, сочувствия, драйва, понимания бизнеса…
Не звучит ли наивно, что мы ожидаем, что между ML-ученым и UX-дизайнером каким-то образом произойдет взаимопонимание? С традиционной разработкой программного обеспечения это каким-то образом сработало, но мне кажется, что в наиболее эффективном сотрудничестве одна из сторон знала основы ремесла другой.
Тем не менее, мне кажется, что с машинным обучением все сторонние группы — разработчики программного обеспечения, менеджеры по продуктам, руководители — относятся к нему как к некоему таинственному черному ящику. Кроме того, в отношении разработки программного обеспечения часто не ожидается, что сами разработчики программного обеспечения будут привносить прорывные идеи и инновации; вместо этого они рассматриваются в лучшем случае как партнеры или конструктивные противники в этом процессе.
Различное отношение к машинному обучению в определенной степени оправдано, поскольку оно не всегда легко или просто. Поэтому я считаю, что в ближайшем будущем особая роль менеджера по продуктам машинного обучения приобретет все большее значение. Я, конечно, не придумываю — Google Trends показывает несколько хитов уже в 2014 году, а в 2018 году их число увеличилось примерно в три раза. именно такие названные позиции всеми крупными игроками (Meta, Amazon, Google, …). Другие писали статьи с таким названием, например, здесь от августа 2020 года (и даже цитирует исследование PWC — смело читайте).
Однако точное определение не важно — независимо от того, будет ли первоначальный опыт управлять продуктом или машинным обучением, действительно важно понимать и то, и другое, а также готовность заботиться о них обоих. В этой статье я использую ML Product Manager, но можно было бы использовать ML Product Designer или ML Business Analyst, что угодно. А в специализированных областях (здравоохранение, физика и т. д.) эксперт в предметной области, по сути, является продакт-менеджером.
Заключение
Если вы работаете в компании, которая рассчитывает получить выгоду от наличия отдела машинного обучения, спросите: кто человек, соединяющий миры? Кто способен сформулировать проблемы как задачи машинного обучения и в то же время оценить, является ли данное решение достаточным/выгодным для бизнеса?
Если вам нужно назвать комбинацию менеджера по управлению проектами плюс специалиста по машинному обучению — возможно, в вашей компании отсутствует ссылка.
Конечно, есть и другие подходы, например, вообще не иметь отдела машинного обучения, а скорее рассредоточить практиков машинного обучения по продуктовым командам и относиться к машинному обучению просто как к еще одному инструменту решения проблем в наборе инструментов разработки программного обеспечения; и внедряйте инновации, не используя инструменты. Определить, какой из этих двух лучше подходит для вашего случая, непросто.
Возможно, правильный путь для машинного обучения состоит в том, чтобы перевести своих экспертов из обычных коммерческих компаний и превратить их во фрилансеров или наемные компании, ориентированные на машинное обучение, которые также работают как исследовательские лаборатории; и оставить только общее знание того, «какова типичная сила ML» среди продакт-менеджеров и руководителей, и общее знание «как обучать готовую модель» среди обычных инженеров SW (кажется довольно амбициозным, что «полное- стек dev» уже придуман). С точки зрения теории категорий это отражает то, что произошло с предложениями PaaS, или то, что может произойти с No Code.
