Структура для продуктовых команд, позволяющая сбалансировать определенные риски с помощью машинного обучения и повысить вероятность разработки успешных продуктов.
Создание продуктов, основанных на таких технологиях, как машинное обучение, связано с другими соображениями, рисками и ограничениями, чем обычные продукты. Чтобы добиться успеха в работе над продуктом, в процессе разработки следует признать эти неотъемлемые проблемы и противостоять им лицом к лицу, даже если это может не устраивать вашу команду разработчиков
Вы действительно в восторге от нового проекта на работе. Вы работаете с командой самых сильных инженеров и ученых своей компании над разработкой нового классного продукта, в основе которого лежит индивидуальный подход к машинному обучению для достижения результатов. Чтобы сделать его конкретным, это может быть инструмент, определяющий, когда пополнять запасы ваших розничных магазинов и автоматическое планирование перевозки грузовиков, или это может быть новое приложение, помогающее вашим клиентам предварительно просмотреть, как ваша мебель будет выглядеть в их доме перед покупкой, автоматическая проверка неисправностей. система для производственной линии вашей компании или что-то совсем другое.
Все начинают работать над проектом. Большой объем работ по техническому проектированию и развитию. Три месяца спустя специалисты по обработке данных работают над сложной новой архитектурой глубокого обучения и не могут заставить ее работать. Инженеры создали довольно простое приложение, но на самом деле не знают, как развиваться, пока модель не будет готова. В то же время руководство просит статуса, и энергия в команде, когда-то очень сильная от волнения, падает по мере того, как разочарование берет верх.
С большой задержкой пилотный продукт в конечном итоге запускается, но каким-то образом предполагаемые пользователи не понимают его. Менеджмент недоволен, как и техническая команда. Некоторые инженеры и ученые чувствуют себя неудачниками, а некоторые даже почувствовали, что их статус в компании упал.
Если вы пережили что-то подобное, описанное выше, вы не одиноки. Успешное создание продуктов, использующих машинное обучение [1] в качестве основной технологии, отличается от других инициатив в области цифровых продуктов. Показателей много: процент неудач «проектов ИИ» значительно превышает 50% (хотя точные цифры получить трудно) [2, 3], что выходит за рамки пилотного проекта или подтверждения концепции. оказалось сложной задачей для многих [4,5], а общее удержание талантов ИИ - большая проблема [6]. Хотя сама технология за последнее десятилетие превратилась из захватывающей в довольно массовую - благодаря многочисленным разработкам, улучшающим доступность - между разработчиками продуктов и техническими специалистами все еще нет единого понимания того, как подходить к разработке продуктов машинного обучения, хотя кажется, что есть некоторое понимание того, что технические требования и профиль рисков при разработке продуктов машинного обучения отличаются от обычных цифровых продуктов и что необходимы некоторые корректировки.
Основная причина неудачных попыток разработки продукта заключается в том, что специалисты по обработке данных и специалисты по разработке продукта не разделяют одинаковое понимание рисков и не согласны с порядком их устранения. Будучи в первую очередь озабочены «основным интеллектом» специалисты по обработке данных интуитивно сосредоточатся на прикладных НИОКР по разработке моделей, чтобы изучить техническую осуществимость; это трудоемкая и исследовательская работа, которая часто протекает нелинейно. С другой стороны, продуктовые лидеры будут больше озабочены созданием сильных и удобных для пользователей ценностных предложений, которые работают на компанию (рассмотрите сочетание ценности, желательности и жизнеспособности вместе с технической осуществимостью [7]) и будут хочу быстро повторить, чтобы изучить это. Это тоже нелинейный процесс обнаружения, только с другими ручками управления и критериями успеха. И часто никто не думает о том, как гарантировать, что нужные данные нужного качества могут быть получены последовательно и с той скоростью, которая требуется для нового продукта.
Всегда сложно найти подходящие продукты, которые работают как для пользователя, так и для компании, при этом постоянно уравновешивая и минимизируя четыре риска ценности, желательности, жизнеспособности и осуществимости, даже для продуктов, основанных на знакомых технологиях. Однако эти четыре высокоуровневых риска имеют некоторые специфические проявления для продуктов, основанных на машинном обучении, которые, возможно, не очевидны. Они не заменяют четыре больших риска, это лишь ключевые моменты из тех четырех, которые требуют особого внимания. Эти
- Тратить слишком мало времени на оценку осуществимости модели на раннем этапе: техническая осуществимость машинного обучения ограничена данными и навыками. После этого легко улучшить модель машинного обучения, если фундамент прочен, но невозможно, если основы не будут на месте. Это убьет весь ваш продукт, если модель, которую вы предполагаете, невозможно разработать с научной точки зрения. Поэтому вы должны следовать принципу #monkeyfirst [8]: сначала делайте сложные вещи, а если они невозможны, вы должны оценить, возможен ли другой подход, или отказаться от идеи продукта.
Ограничивающими факторами для машинного обучения являются: а) есть ли у вас постоянный и своевременный доступ к нужным данным и б) есть ли у вас навыки для разработки и развертывания правильных моделей, и поэтому это обязательно чтобы установить правильный уровень уверенности в этих аспектах на раннем этапе разработки продукта. - Тратить слишком много времени на модель машинного обучения на ранней стадии (до проверки продукта). Повышение производительности модели требует времени, но это может быть значительной тратой времени, если не будет подтверждено, что продукт, который мы даем нашим пользователям, также улучшается в результате этих усилий. Итак, в то время как первый риск заключался в том, чтобы достаточно глубоко оценить, будет ли машинное обучение работать, второй риск заключается в слишком раннем чрезмерном инвестировании и игнорировании потребностей пользователя (рисков ценности и желательности).
- Недовольные специалисты по данным. Специалисты по обработке данных действительно любят работать с моделями машинного обучения, и, имея возможность выбора, они предпочли бы работать с более продвинутыми типами моделей, которые позволяют им развивать свои навыки и опыт. С другой стороны, многие специалисты по обработке данных не так сильны, как коллеги по разработке программного обеспечения, в создании систем для развертывания моделей машинного обучения, и специалисты по обработке данных также часто считают, что им не следует выполнять эту работу.
Если принять во внимание первые два указанных выше риска, специалисты по обработке данных будут справедливо беспокоиться о том, смогут ли они использовать свои основные компетенции. Для этого есть время, когда продукт MVP доказал свою ценность для пользователей. Тем не менее, это может привести к разочарованию и высокой текучести кадров, если не будет решено своевременно и надлежащим образом.
Ключевым моментом является достижение общего понимания желаемого результата и рисков, связанных с его достижением, а также согласие с методологией разработки, которая позволяет команде решать эти проблемы. Технические группы часто забывают, что ожидаемый результат - отличный пользовательский опыт, решающий важные, ценные проблемы - одной только рабочей технологии машинного обучения недостаточно. Фактически, обработка исключений и то, как пользователь должен действовать в соответствии с прогнозами машинного обучения, являются ключами к успеху, но часто полностью выходят за рамки самой технологии машинного обучения. Трудно быть предельно четким в отношении рисков и проблем, особенно на раннем этапе, когда команда все еще изучает пространство ценностных предложений и технических проблем. Тем не менее, очень важно провести открытый разговор как о желаемых результатах для пользователей, так и о методологии разработки на раннем этапе, а после этого регулярно проводить проверки для повторной оценки и корректировки, если это необходимо.
Подход к разработке продуктов на основе машинного обучения
Следующий подход представляет собой объединение опыта из первых рук и наблюдений других команд, пытающихся найти хороший баланс. Как и в любом другом творческом поиске, вам не следует стремиться к идеальному процессу, а вместо этого пытаться создавать отличные («идеальные») результаты и уважать то, чему вы научитесь на этом пути: поэтому ожидайте, что иногда это будет беспорядочно и беспорядочно. что будут совершаться ошибки. При этом есть надежда, что приведенный ниже подход покажет, как наиболее важные риски меняются в процессе разработки, и, как мы надеемся, предоставит некоторую перспективу как техническим командам, так и руководителям продуктов.
Подход на самом деле сводится к признанию того, какие из упомянутых ранее рисков продукта являются наибольшими на каком этапе, а также к некоторым предложениям по устранению этих рисков. Надеюсь, это позволит вам двигаться быстрее и повысить вашу уверенность и вероятность успеха при разработке нового продукта. Во время исследования нового продукта, который потенциально может использовать машинное обучение, два важных риска - это техническая осуществимость и желательность пользователя предлагаемого продукта, то есть, решает ли продукт важную проблему привлекательным способом (первые два риска выделено выше). Лучший способ решить эту проблему во время открытия продукта - двигаться с правильным балансом скорости и детализации, чтобы идентифицировать ценный продукт, который нравится пользователям и который также технически осуществим. Эти первые два шага (1a и 1b, см. Рисунок) связаны с выполнением подходящего количества циклов открытия / разработки, чтобы найти надежного кандидата на продукт, который, как мы уверены, мы сможем создать технически. Результатом итерации шагов 1a и 1b является минимально жизнеспособный продукт (MVP), который мы можем запустить, чтобы учиться.
Основная часть технической разработки будет происходить на этапе 2а, который посвящен созреванию продукта. Именно здесь произойдет большая часть детальной оптимизации машинного обучения, оптимизации конвейера данных и т. Д. Наконец, шаг 2b - это общий аспект продукта, расширяющий его функциональность.
Шаг 1а: возможно ли решить проблему с помощью технологий?
Когда менеджер по продукту приходит с идеей, задача технической группы - оценить, возможно ли вообще реализовать ее с помощью технологий. Хотя вам не следует слишком рано сосредотачиваться на конкретном техническом решении на раннем этапе обнаружения, вам все равно необходимо быть уверенным в том, что технически осуществимое решение проблемы может быть разработано. В противном случае вы не будете знать, как создать продукт, и вам следует переключить внимание на другой способ удовлетворения потребностей пользователя.
Это не означает, что «у нас есть технологии, теперь давайте поищем проблему, которую нужно решить», но даже если поставить проблему пользователя во главу угла, технические возможности команды и контекст проблемы совместно играют большую роль в техническом плане. возможность доставки решения.
Поэтому цель этого первого шага - продумать детали потенциальных технологических решений с достаточным уровнем детализации, сохраняя при этом соответствующую скорость. В частности, это означает оценку того, реально ли для вашей команды и вашего продукта создать технологию машинного обучения для предоставления необходимого решения пользовательской проблемы (включая некоторое приблизительное понимание производительности модели), гарантируя, что данные для машинного обучения могут быть последовательно получены для продукта, когда необходимо делать прогнозы и устанавливать возможные способы измерения производительности.
В качестве одного из важных примеров неспособность последовательно получать и очищать данные, необходимые для работы модели, часто является большой проблемой, потому что не существует пути для их получения. Частой причиной этого являются модели, обученные на статических наборах данных, которые не работают при преобразовании в продукты, потому что недостаточно продумано, как взять под контроль процесс генерации данных [9]. Важно продумать возможность создания хорошего процесса генерации данных уже на этапе обнаружения: это не только может сэкономить много времени, денег и головной боли [10], но и отсутствие стратегии сбора данных остановит масштабирование и, следовательно, эффективно убейте продукт, прежде чем он взлетит.
Оценка осуществимости моделей машинного обучения и сбора данных обычно проводится с помощью технических доказательств концепций, но, конечно же, способы ее реализации могут варьироваться. Как бы вы это ни делали, это необходимо для того, чтобы внутри команды разработчиков продукта появилась уверенность в том, что эти проблемы можно решить. Хотя в некоторых случаях это могло произойти, я был бы удивлен, если бы на этом этапе было выполнено расширенное математическое моделирование; скорее, речь идет о том, чтобы установить, можно ли сформулировать проблему таким образом, чтобы ее можно было решить даже с помощью математического моделирования, установив некоторую раннюю уверенность в том, что характеристики модели (точность, время предоставления результатов и т. д.) могут быть доведены до требуемого уровня. через точную настройку, а также возможность постоянного доступа к требуемому материалу данных.
Шаг 1б. Сосредоточьтесь на доказательстве ценного предложения для пользователей
Этот второй шаг является обращением к пользователю, параллельным шагу 1а: обнаружение продукта, процесс определения того, как придать продукту такую форму, чтобы он был ценным и привлекательным для пользователей. Я назвал эти шаги 1a и 1b, чтобы указать, что в идеале их следует выполнять одновременно [11]. Ожидайте, что выполнение 1a и 1b будет итеративным циклом в направлении соответствия продукта рынку.
Цель состоит в том, чтобы изучить факторы создания ценности для пользователей, чтобы понять, как проектировать и создавать продукт. То есть это процесс определения идей, в которые мы верим при разработке MVP для тестирования с пользователями, и все это с целью выявления сильного ценностного предложения. Ключевой вопрос связан с выявлением фактических факторов ценности машинного обучения в глазах пользователей, в том числе с тем, как представить результаты машинного обучения таким образом, чтобы пользователь мог максимально легко предпринять правильные действия. Детали, конечно, будут сильно зависеть от контекста, но хороший пример - автомобильные навигационные системы: чтобы добиться успеха, такие системы должны иметь возможность предоставлять хороший план с помощью GPS (машинное обучение и оптимизация) и своевременные устные обновления ( интерпретация результатов относительно движения) являются ключами к успеху. Первое требует хороших возможностей планирования и приличной скорости вычислений, в то время как низкая задержка для второго, чтобы постоянно иметь возможность оценивать, где находится автомобиль по отношению к плану, - это разница между полезным и бесполезным продуктом.
Ключ к успеху на этом этапе - это способность действовать быстро, оценивая, будут ли идеи работать, и сигнал, который мы ищем, заключается в том, даем ли мы пользователям то, что им действительно нужно. В результате пришло время для простых готовых моделей машинного обучения (или, возможно, имитируемой модели, то есть никакой реальной модели!); как только будет установлено, что проблема может быть решена с помощью машинного обучения (проблемы шага 1а были устранены), больше ничего делать не нужно.
Однако в рамках изучения возможных ценностных предложений часто бывает актуально изучить, как представить результаты пользователям. То есть какие показатели лучше всего передают сообщение пользователям? Как должны быть представлены результаты (в виде графика? Как рекомендованное действие?) И должен ли пользователь иметь возможность исследовать результаты в интерактивном режиме (например, перемещаться по карте для автомобильной навигационной системы в вышеупомянутом примере). Какова относительная важность точности по сравнению со временем, необходимым для достижения результата? Каков правильный уровень детализации для отображения результатов? GPS, который может вести вас только из города в город, но не имеет разрешения, чтобы вести вас в пределах города, не представляет особой ценности для большинства. Все эти вопросы лежат на стыке науки о продуктах и данных, и поиск хороших решений может сделать или испортить конечный продукт.
Шаг 2а. Развитие продукта: повышение эффективности машинного обучения и повышение ценности
Когда вы обнаружили продукт, который является одновременно ценным, желательным и осуществимым, научные и инженерные разработки могут начать улучшать возможности машинного обучения. Это детальная работа по улучшению, при которой решение становится более надежным, и где новые архитектуры машинного обучения и типы моделей тщательно исследуются, рассматриваются крайние случаи и т. Д. Чтобы быть ясным, совершенствование технологии и взаимодействия с пользователем распространяется на все аспекты продукта, не только машинное обучение; В дальнейшем я сосредоточусь только на некоторых аспектах, особенно важных для частей машинного обучения, которые являются основополагающими для масштабирования и долговечности.
На этом этапе стратегии мониторинга и переподготовки разрабатываются на основе набросков из шага 1а, чтобы они поддерживали продукт, область, также известная как MLOps [12–14]. Большая часть машинного обучения, а также других типов прикладных математических механизмов со временем ухудшается, и MLOps - это то, что гарантирует, что мы отслеживаем производительность и проактивно корректируем модели, чтобы они продолжали обеспечивать работу продукта. Без MLOps модели машинного обучения быстро перестанут давать полезные результаты, и продукт станет бесполезным. Менеджеры по продуктам должны играть активную роль в определении стратегий MLOps вместе с технической командой, чтобы гарантировать, что ценностное предложение пользователя находится в центре внимания, а ключевые показатели эффективности машинного обучения должны быть частью KPI, ежедневно проверяемых менеджером по продукту.
Одна часть MLOps требует особого упоминания, потому что лучшее решение часто заключается в разработке продукта: ухудшение качества данных. Иногда случается, что один или несколько источников данных начинают смещаться после запуска продукта. В маркетинговых ситуациях это может произойти, когда представлен новый продукт, который ранее не входил в набор данных, который меняет поведение (может даже быть введением нашего собственного продукта), это могут быть новые правила (например, GDPR) и в других контекстах. это может быть результатом износа физического датчика, изменения контекста изображений (беспорядок на заднем плане) производственной линии и т. д. MLOps позволит проактивно реагировать на изменения в данных, но не гарантирует, что качество изображения модель машинного обучения сохраняется. Лучший способ решить эту проблему - спроектировать продукт таким образом, чтобы вы контролировали генерацию данных, или, в качестве альтернативы, чтобы продукт был позиционирован таким образом, чтобы ценностное предложение не ухудшалось, если иногда модель не может быть запущена . Определение стратегии решения этих проблем - это вопрос продукта, и он должен быть активным.
Шаг 2б. Развивайте продукт, но остерегайтесь непреднамеренных аварий из-за неисправных моделей
Прежде чем обсуждать детали этого раздела, необходимо уточнить некоторые аспекты моделей машинного обучения. В рамках процесса разработки эти модели «обучаются» (подгоняются) на исторических репрезентативных данных, чтобы адаптировать их возможности прогнозирования к конкретной проблеме и данным, над которыми вы работаете. Однако производительность обычно падает, если она применяется вне области данных, на которой была обучена модель, и это может произойти как в случае изменений в процессе генерации данных (например, другое поведение пользователя), так и в том, как мы его измеряем (например, при чтении одного источник данных с использованием другого датчика). Эти аспекты имеют некоторые последствия для масштабирования продуктов, основанных на машинном обучении.
Если дела пойдут хорошо, продукт в какой-то момент потребует масштабирования. Масштабирование обслуживания и операций моделей машинного обучения является технической проблемой (которая может быть сложной сама по себе), если это происходит в пределах одной и той же пользовательской базы, но масштабирование в новые группы или сегменты пользователей сопряжено с дополнительной сложностью, поскольку создание данных процесс может измениться. В таких ситуациях тщательный мониторинг часто является хорошей стратегией: поскольку модели машинного обучения часто используются для помощи в принятии решений, и поскольку решения и / или поведение новых групп пользователей могут отличаться от предыдущих сегментов, эти изменения будут отражаться в мониторинг данных и производительности. Если есть основания полагать, что новая целевая группа пользователей ведет себя иначе, или если части процесса генерации данных для этой новой группы отличаются, следует ожидать, что добавление этой новой группы потребует настройки самой модели машинного обучения (по сути, через шаги 1a, 1b и 2a), а не просто переключение переключателя существующей модели на этот новый сегмент. В качестве примера в случае GPS, который мы использовали ранее: добавление Великобритании в качестве новой страны потребует значительной настройки механизма маршрутизации, потому что на все решения по маршрутизации влияет левостороннее движение. Ключевой момент для команды - знать об этой важной работе и учитывать ее в нужный момент.
Как и в случае с любым другим продуктом, как только у нас появляется продукт с хорошей популярностью и масштабом, «последний» шаг - это дальнейшее развитие предложения за счет добавления дополнительных функций. Это включает в себя непрерывные циклы открытия, создания прототипа и проверки пользователем для определения соответствия продукта рынку каждой новой функции, как это хорошо описано в другом месте [7]. Некоторые из этих новых функций могут быть новыми решениями на основе машинного обучения, которые не имеют технического отношения к основному предложению, и если это так, их разработка будет осуществляться в соответствии с шагами, описанными выше. Здесь важно отметить, что любые новые функции, которые изменяют поведение пользователя, также повлияют (потенциально подорвут) существующие модели машинного обучения, поддерживающие устаревшие функции. Например, HR в одной глобальной энергетической компании оценивал вероятность будущего успеха компании при каждом новом найме, но в то же время использовал эту оценку вместе с производительностью и другими переменными, чтобы определить, каким сотрудникам будут предложены возможности роста; из-за этого (вероятно, непреднамеренного) цикла отрицательной обратной связи люди, не получившие высоких оценок при присоединении, не получали таких же возможностей, что в целом привело к меньшему разнообразию кадрового резерва и более высокой текучести кадров. Важно внимательно следить за этими неинтуитивно понятными зависимостями, и также важно знать, что они могут быть обнаружены только в некоторых сегментах или даже могут различаться в разных сегментах. Помимо осведомленности о самом риске, тщательное измерение влияния на поведение пользователей и производительность существующих моделей и проведение контролируемых экспериментов при внедрении новых функций - это лучшие методы, позволяющие избежать непреднамеренного подрыва вашего предыдущего успеха.
Подтверждение
Тщательный обзор Саймона Килериха Веделя (не имеет отношения), включая идеи, которые значительно улучшили этот пост, был признан (Профиль LinkedIn).
использованная литература
[1] То, что я описываю в этом посте, применимо ко всем случаям, использующим расширенное математическое моделирование в качестве предпосылки для решения проблем, и не ограничивается только проблемами машинного обучения (или даже традиционными проблемами науки о данных). То есть аналогичные проблемы будут обнаружены в математическом моделировании, оптимизации и смежных областях. Я буду использовать термин машинное обучение для краткости, но читатель должен помнить, что обсуждаемые темы применимы в более широком смысле.
[3] Ирвинг Владавски-Бергер: Почему некоторые усилия ИИ достигают успеха, а многие терпят неудачу, Wall Street Journal, 24 января 2020 г., https://www.wsj.com/articles/why-some-ai-efforts-succeed- while -many-fail-01579901883
[5] https://www.bcg.com/publications/2019/travel-time-push-ai-beyond-pilot-phase
[7] Марти Кейган: Вдохновленный, https://svpg.com/inspired-how-to-create-products-customers-love/
[8] Astro Teller: Сначала займись обезьяной, 2016 https://blog.x.company/tackle-the-monkey-first-90fd6223e04d
[9] Уилл Дуглас Хевен: Медицинский ИИ Google был очень точным в лаборатории. В реальной жизни все было иначе. Обзор технологий MIT, 27 апреля 2020 г., https://www.technologyreview.com/2020/04/27/1000658/google-medical-ai-accurate-lab-real-life-clinic-covid-diabetes-retina-disease /
[10] Эндрю Нг: ИИ не обязательно должен быть слишком сложным или дорогим для вашего бизнеса, Harvard Business Review, 29 июля 2021 г., https://hbr.org/2021/07/ai-doesnt-have-to- будь слишком сложным или дорогим для своего бизнеса
[11] Этот пост посвящен случаям, когда доказательство ценности для пользователей является частью проблемы, поскольку это распространенная ситуация, с которой сталкиваются от стартапов до предприятий. Однако следует отметить, что есть участки, в которых ценностное предложение является ясным, а рабочие процессы / усилия по разработке продукта рассчитаны на использование машинного обучения, например слуховые аппараты и другие встроенные средства обработки сигналов, ценообразование опционов и обнаружение мошенничества в банках и т. д. В таких случаях проблемы, которые пытается решить Шаг 1b, не столь серьезны.
[12] Для специалистов: я широко использую термин MLOps, поэтому он также включает DataOps (эквивалент данных DevOps). Между ними есть важные различия, но для целей этого сообщения в блоге они представляют собой две стороны одного и того же вопроса о том, как реализовать масштабные продукты машинного обучения и обработки данных.
[13] https://en.wikipedia.org/wiki/MLOps
[14] Теренс Це и др., Тупая причина, по которой ваш проект ИИ потерпит неудачу, Harvard Business Review, 8 января 2020 г., https://hbr.org/2020/06/the-dumb-reason-your-ai- проект-потерпит неудачу
