Управление продуктами ИИ

Осуществимость, желательность и жизнеспособность

Хенрик Скогстрём / 17 января 2022 г.

По мере того как машинное обучение проникает в мейнстрим цифровых продуктов, понимание основ машинного обучения становится все более актуальным для многих менеджеров по продуктам. Люди, работающие над продуктом, сегодня — довольно разнородная группа. Для некоторых основное внимание уделяется пользовательскому опыту (например, если основное ценностное предложение вращается вокруг потрясающего пользовательского интерфейса), в то время как другие уже управляют продуктами, требующими глубокого понимания данных и кода.

Понимание ML будет необходимо для обоих концов спектра — только по немного разным причинам. Для продуктов, ориентированных на пользовательский интерфейс, и PM функции нечеткой логики и машинного обучения радикально изменят то, как пользователь взаимодействует с продуктом. Таким образом, представление таких функций становится очень важным. С другой стороны, менеджеры по продуктам, которые управляют API или техническими платформами, будут больше озабочены тем, как интегрируется алгоритм ИИ.

Управление продуктом — такая же важная тема, как и машинное обучение, поэтому давайте начнем с фундаментального вопроса. Когда стоит разрабатывать продукт с искусственным интеллектом? Конечно, вы также можете применить этот вопрос к функции в контексте более крупного продукта.

Полезный инструмент, который большинство менеджеров по проектам видели для этого, — это Золотая точка для инноваций, которую популяризировала IDEO. Он исследует осуществимость, желательность и жизнеспособность продукта, и стоящие идеи, как правило, затрагивают все эти аспекты. Если вы не знакомы с фреймворком, вам следует прочитать эту статью.

Давайте посмотрим на эти концепции с точки зрения продукта машинного обучения.

осуществимость

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

Несмотря на то, что оценить время по-прежнему сложно, мы все вместе научились довольно хорошо оценивать возможности программного обеспечения. Когда вы описываете проблему разработчику, он уже думает о технологиях и библиотеках. Возможно, вы думаете о предыдущих продуктах, в которых данная проблема была решена. Подобные модели мышления появятся со временем для машинного обучения.

Когда дело доходит до осуществимости, вы должны задать себе и своей команде следующие вопросы:

Какую проблему мы хотим решить?

Постановка проблемы необходима для решения любой проблемы, но тем более она необходима при работе с более значительной неопределенностью. Например, предположим, что наша идея состоит в том, чтобы обнаруживать дефектные продукты на производственной линии. Здесь важна степень детализации: насколько большое улучшение мы ищем в дефектных продуктах, отправляемых покупателю?

Есть ли у нас данные о проблеме? Если нет, можем ли мы получить данные о проблеме?

Машинное обучение — это все о данных. Это не всегда большие данные, но достаточно качественные данные о проблеме. Некоторые данные легко получить, например действия пользователя в вашем приложении. Вероятно, они уже где-то хранятся.

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

Есть ли в данных шаблоны, которые имеют смысл для алгоритма?

Сложность машинного обучения заключается в том, что специалисты по данным часто заранее проводят большую работу по оценке набора данных и экспериментам, чтобы увидеть, есть ли в данных шаблоны, которые может понять модель ML. В отличие от традиционного программного обеспечения, осуществимость трудно оценить, не закатывая рукава метафорически. Например, с вашим набором данных о маркированных продуктах — как дефектных, так и бездефектных — модель сможет различать их.

В традиционном программном обеспечении выполнимость может быть почти описана как бинарная (возможна или нет). Однако в машинном обучении осуществимость может быть более масштабной, что распространяется на то, что желательно.

Желательность

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

Насколько хорошо будет работать алгоритм и насколько хорошо он должен работать?

Этот вопрос связан как с осуществимостью, так и с желательностью решения. Опять же, нет простых ответов, прежде чем ученый данных приложит немного усилий.

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

Легко описать полностью автономное решение, но не всегда возможно построить его. Возможно, продукт, который вы реально сможете создать, — это просто компьютерный помощник человека. Полностью автономный автомобиль и автоматизированное рулевое управление совершенно разные по своей желательности. Было бы лучше рассмотреть момент, когда что-то становится желанным в вашем контексте. Это связано и со следующим вопросом.

Какой уровень контроля будет у пользователя? Доверяет ли пользователь вашему решению и видит ли ценность так же, как и вы?

Доверие — важная тема в ИИ, и на то есть веская причина. Модели машинного обучения могут быть черными ящиками для людей, которые их разрабатывают, так что представьте, что чувствует конечный пользователь. Важным аспектом, который следует учитывать, является то, сколько информации вам придется передать, чтобы убедить пользователя, и какой контроль над решениями вы предоставляете пользователю.

Например, в нашем примере с производственной линией вам нужно будет представить уверенность алгоритма в отношении каждого прогноза (т. е. этот продукт с вероятностью 70% будет неисправен)? Дадите ли вы руководителю производственной линии возможность регулировать уровень достоверности бракованного продукта?

Это упрощение конечно. Передача бразды правления алгоритмом пользователю может быть сложной для реализации и трудной для понимания пользователем.

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

Жизнеспособность

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

Вот еще несколько вопросов, связанных с ML, которые касаются жизнеспособности:

Будет ли ценность, созданная в долгосрочной перспективе, больше, чем краткосрочные затраты?

Развитие возможностей машинного обучения может быть смехотворно дорогостоящим. Учтите, что специалисты по обработке и анализу данных и инженеры по машинному обучению сегодня являются одними из самых востребованных талантов. Даже если они уже есть в вашей команде, есть много других инициатив, которые они могли бы взять на себя. Кроме того, дизайнеры и эксперты в предметной области, разбирающиеся в машинном обучении, встречаются еще реже. Качественные данные также могут быть дорогими, и обучающие модели тоже не бесплатны.

Нужно написать много кода и настроить инфраструктуру, начиная от сбора данных и заканчивая обслуживанием моделей. Кроме того, машинное обучение является новым для большинства, и все заинтересованные стороны требуют значительного объема обучения и управления изменениями.

Из-за требуемых затрат и опыта, возможно, всегда стоит начинать с вопроса, можно ли что-то решить с помощью экспертной системы (например, механизма правил), а не ИИ. И, во-вторых, спросите, как вы гарантируете, что ваша команда использует исследования и технологии, созданные другими до них. Эти два вопроса могут сэкономить вам и вашей компании немалые деньги.

Изменится ли проблема со временем? Можно ли расширить решение для других областей?

Два других аспекта могут существенно повлиять на жизнеспособность вашего ИИ-продукта. Во-первых, насколько динамичной является среда, в которой вы развертываете свое решение. Опять же, в нашем примере с производственной линией, будет ли часто меняться модель продукта? Если это так, стоимость сбора данных, обучения модели машинного обучения и выполнения других обновлений будет возрастать со временем только для поддержания жизнеспособности вашего решения. Эта проблема встречается чаще, чем вы думаете.

Другая сторона медали может заключаться в том, что ваше решение можно воспроизвести для решения других подобных задач, и вы сможете использовать большую часть инженерных разработок снова и снова. Например, вы могли изначально разработать решение для обнаружения неисправностей для одного продукта. Тем не менее, те же датчики могут быть установлены на других производственных линиях и могут быть собраны обучающие данные. Эти типы возможностей могут оправдать многие крупные авансовые инвестиции.

Связывание всего вместе

Среди продакт-менеджеров есть определенная наивность (но не только), когда речь идет о машинном обучении. Отношение варьируется от того, что ML полностью выходит за рамки возможного, до ML, решающего любую проблему с легкостью. Так что, естественно, истина где-то посередине.

Как показано в этой статье, осуществимость, желательность и жизнеспособность очень взаимосвязаны в продуктах ИИ, и раскрытие их взаимосвязей потребует более конкретных экспериментов и прототипирования, чем в традиционном программном обеспечении. В нем также подчеркивается, что специалисты по обработке и анализу данных, инженеры, менеджеры по продуктам и профильные эксперты должны работать вместе с самого начала.

Первоначально опубликовано на https://valohai.com.