Менеджер продукта имеет дело с массой проблем, вот контрольный список, если вы тоже создаете решение ML для своей проблемы
Машинное обучение (ML) способно учиться на данных и применять статистическое понимание для решения проблем, с которыми сталкивается пользователь, например, для прогнозирования, классификации и распознавания объектов. Тем не менее, продукты ML не являются безошибочными, и часто можно увидеть продукты ML, на разработку которых ушло несколько месяцев и спринтов, но которые едва ли представляют ценность для пользователей. Фактически, отказ продукта ML обычно возникает из-за неправильного применения необходимых аналитических методов, а не из-за технического исполнения.
«Если мы не решаем правильную проблему, независимо от того, насколько хороша команда или насколько эффективна методология, проект проваливается»
Несомненно, сбой продукта — это самая важная область для PM, и вот что нужно сделать, прежде чем приступить к разработке продукта ML.
1. Подтвердите свой вариант использования машинного обучения
Плохо определенные бизнес-цели для варианта использования ML часто являются причинами неудач продукта ML. Следовательно, интервьюирование вашего бизнес-пользователя для решения проблемы и бизнес-цели — отличное начало для анализа того, нуждается ли проблема в решении с помощью машинного обучения. Однако не спрашивайте о потенциальном решении, иначе, держу пари, до 90% ответов будут примерно такими: «Окончательное решение — иметь автоматизированную систему, способную принимать умные и правильные решения на… от имени людей и не должен быть склонен к ошибкам, и…». Сосредоточьтесь на том, чтобы разрушить болевые точки основного бизнеса, чтобы ваш продукт машинного обучения мог иметь правильную проблему и аналитическое соответствие. PM может работать в обратном направлении от ожидаемого бизнес-результата и отвечать на несколько ключевых вопросов, таких как (1) Почему именно эта цель? (2) Что ML может сделать для решения вопроса «Почему?» (3) Каков базовый KPI без ML (4) Каков выходной KPI продукта ML? затем перейдите к обсуждению с специалистом по данным, чтобы проверить техническую возможность применения машины изучение бизнес-проблемы, которую вы пытаетесь решить.
Хитрость здесь заключается в том, чтобы знать, когда использовать продукт машинного обучения, когда достаточно некоторых других инструментов. Машинное обучение может стать увлекательным дополнением к вашему решению, но иногда простая бизнес-логика или эвристика могут привести к тому же результату с меньшими затратами. Имейте в виду, что финансовый и временной стресс после запуска продукта машинного обучения может легко выйти из-под контроля, поэтому не решайте простую проблему причудливыми решениями. Как только заинтересованные стороны из бизнеса и науки пришли к консенсусу в отношении того, что бизнес-цель достижима с помощью приложения машинного обучения, мы можем смело принять это как допустимый вариант использования ML и перейти к следующему пункту.
2. Определите простейшую модель для вашего варианта использования машинного обучения
Сложная модель и модель не обещают более высокой эффективности вашего продукта машинного обучения. Как только вариант использования ML определен, PM должен обратиться к специалистам по обработке и анализу данных, чтобы глубже погрузиться в потенциальные модели и алгоритмы для приложения ML. Обладая четким пониманием бизнес-целей, ученые могут разбить научные проблемы и предложить простейшую модель для их решения. Кроме того, нам бессмысленно копать глубже в поисках наиболее эффективной модели, даже не протестировав простейшую точку данных, которую ваш продукт машинного обучения будет потреблять и прогнозировать.
Обсудите со своим специалистом по данным следующие вопросы, чтобы определить простейшую модель для применения на ранней стадии: (1) Какую проблему машинного обучения мы решаем — регрессию/классификацию/одномерную/многомерную? (2) Обучение под наблюдением/обучение без учителя? (3) Каковы выходные данные, которые мы ожидаем от модели?Вот карта разума, какую модель следует применять для решения проблемы, которую вы решаете, для удобства:
Никогда не забывайте понимать технические ограничения выбранной модели, прежде чем принимать окончательное решение. Каждая модель должна иметь свои ограничения, и нет абсолютно правильной/неправильной модели для использования, поскольку решение в основном сильно зависит от источника данных, ожиданий пользователя и варианта использования ML в вашем продукте. После того, как будет выбрана простейшая модель, основное внимание будет обращено на органическое питательное вещество для модели — данные, данные, данные…
3. Изучите соответствующие источники данных
Отсутствие релевантных и достаточных данных является одной из основных причин неудач в продуктах машинного обучения. Проверка того, есть ли в вашей проблеме ML исторические данные, которые позволяют вам изучить наблюдение и узнать результат, является обязательной. Обычный сценарий заключается в том, что мы не знаем, какие данные могут быть полезны для обучения модели, в то время как эффективный способ получить первый набор релевантных данных — отследить доступную бизнес-эвристику в обратном направлении, где вы можете легко получить не менее 10–20 точек данных за одно наблюдение. Как PM, вы должны сосредоточиться на релевантности данных, а не беспокоиться об их удобстве использования/производительности в начале, никто не знает, способствуют ли данные тому, если только не будет надлежащего запуска процесса разработки функций.
Кроме того, качество данных так же важно, как и их количество. Имейте в виду, что вы не получите надежную модель из грязного и противоречивого пула данных. Многие продакт-менеджеры забыли о важнейших шагах Исследования данных и сразу переходят к выбору функций, что приводит к тому, что модель потребляет тонны данных NULL, а затем неэффективна в целевом варианте использования. Прежде чем переходить к следующему шагу, убедитесь, что все выбранные релевантные данные имеют правильное число — т. е. ‹10 % пустых значений из пулов данных. Тем не менее, здоровая модель должна придерживаться сбалансированной диеты, которая относится к подсчету сбалансированных наблюдений для каждой выходной категории. Например, если ваша модель решает проблему классификации для определения спама и не-спама, ваш набор данных должен иметь правильное соотношение, т. е. (6:4) для (спама:не-спама) так что эта модель имеет достаточно наблюдений в обоих случаях. Как только вы узнаете, какие данные релевантны для выбора, и набор данных исправен, вы можете начать оценивать возможность создания конвейера данных для получения этих данных.
4. Оцените усилия по созданию конвейера данных для вашего продукта машинного обучения
Чистый конвейер данных — это ключ к поддержанию качества данных до, во время и после разработки модели машинного обучения. Он направляет необработанные данные, будь то неструктурированные/полуструктурированные, из исходного источника (производственная БД), преобразует и загружает их в хранилища данных в структурированном и чистом виде, чтобы специалист по данным мог использовать данные, широко известный как процесс ETL. . Если в вашей организации нет инженера данных (DE), вы можете поговорить с аналитиком данных, который иногда разделяет шляпы DE в предварительной обработке данных и конвейере.
Создание продукта машинного обучения похоже на выпечку торта, а данные — самый важный ингредиент, от которого зависит, будет ваш торт вкусным или нет. Наличие хорошего конвейера данных помогает в (A) предоставлении обновленных данных для непрерывного обучения модели (B) облегчении предварительной обработки данных для всех пользователей данных, (C) понимании потока данных в ваших данных продукт.Как менеджер по проектам, мы должны оценить работу, необходимую для создания конвейера данных для модели, еще до начала проекта. Ваша команда по обработке и анализу данных будет страдать от нехватки данных или их несогласованности, если нет конвейера данных, который берет на себя работу по поддержанию актуальности данных, получаемых моделью, и это определенно приводит к длительному обмену данными, когда дело доходит до обучения и развертывания. Следовательно, ваша работа как продакт-менеджера состоит в том, чтобы иметь дело с DE и проверять, возможно ли создать конвейер данных, который собирает и обрабатывает необходимые необработанные данные для вариантов использования ML, поскольку ваши нижестоящие работники данных сильно зависят от качества данных для достижения успеха продукта. .
Кроме того, PM должен способствовать диалогу между инженером данных и специалистом по данным, чтобы уточнить требования к данным, чтобы созданный конвейер данных соответствовал потребностям пользователя данных при создании продуктов ML. НЕ ПРЕДПОЛАГАЕМ, что DS знает, что им нужно, а DE знает, что нужно преобразовать, еще раз проведите их через постановку задачи и вариант использования ML, чтобы убедиться, что они находятся на одной странице, прежде чем что-либо создавать.
5. Выявление возможных предубеждений
К этому моменту вы подтвердили свой вариант использования ML, определили модель и использование данных, знаете, что у вас будет устойчивый источник данных для изучения модели, все звезды сошлись, и вы сделали свою работу правильно, но что общего, что ваша маленькая программа все еще не работает в большом мире. Единая модель, которая решает все проблемы, обычно существует, когда она построена из нескольких подмоделей в модульном подходе, а устранение потенциальных смещений между модулями определенно улучшит производительность вашей модели. Как продакт-менеджеру лучше подумать о потенциальных предубеждениях или проблемах, которые могут быть обнаружены в процессе, когда ваша модель начнет изучать данные, которые вы вводите. Распространенной причиной такой предвзятости является то, что мы не помещаем достаточно данных для обучения, поэтому вам, возможно, придется вернуться к пункту 3 выше и изучить, относятся ли данные вообще к варианту использования ML, выберите новый или опустите их и повторите проверку.
В худшем случае, если ваша предвзятость особенно плоха, вы даже можете столкнуться с проблемой, что ваши данные не работают в том контексте, на который вы надеетесь, и вам, возможно, придется начать все сначала. Однако, распознав предубеждения на ранней стадии и приняв меры по их устранению, вы сможете сэкономить массу времени и работы, прежде чем плакать над пролитым молоком.
Заключение + Мои 2️ цента:
Продукт машинного обучения отличается от обычного цифрового продукта, поскольку он включает в себя незначительные, но чувствительные факторы и манипуляции, которые могут повлиять на успех продукта. Помимо характера продукта, вам требуется обширный эмоциональный контроль в общении с заинтересованными сторонами, которые, вероятно, исходят из исследовательской среды и требуют большего внедрения бизнес-целей и целей во время выполнения дорожной карты продукта. Следовательно, сделайте:
- Подтвердите свой вариант использования ML
- Определите простейшую модель для задачи ML
- Изучите соответствующие источники данных
- Оцените усилия по созданию конвейеров данных для вашего продукта машинного обучения.
- Определите потенциальные предубеждения
еще до того, как приступить к разработке MVP.
Ну, это то, что мы рассматриваем в этой статье, и я надеюсь, что приведенный выше контрольный список поможет PM, который создает продукт машинного обучения, спланировать непростую дорожную карту заранее! 🚀🚀🚀 Здорово~ 🤖 💻
