В этой статье я проведу вас через полный жизненный цикл продукта машинного обучения и опишу роль менеджера по продукту в нем. Я не слишком подробно определяю управление продуктами. Как PM продуктов AI-ML, нужно делать все, что делает PM, и, в дополнение к этому, заботиться о конкретных обязанностях, связанных с AI/ML, которые описаны в этой статье.

В статье также не рассматриваются различные применения ML. Предполагается, что проектный менеджер или бизнес-лидер идентифицировал приложение и хочет применить к нему машинное обучение. Я скорее подчеркну, что поиск «реальной» проблемы — одна из самых важных задач для PM в проекте машинного обучения.

Наконец, я стремился быть всеобъемлющим, но при этом доступным, чтобы читатели не сохраняли его в своей цифровой памяти и никогда не добирались до него. Следовательно, здесь не будут определены несколько основных элементов; достаточно быстрого поиска в Google или GPT. :)

Содержание:
1. Что такое управление продуктом
2. PM в ML/AI — будьте стратегическими
3. Обязанности PM в полном жизненном цикле ML
Определение объема → Данные → Моделирование → Проверка → Развертывание
4. Дополнительные комментарии
5. Инструменты и методы

Что такое управление продуктом?

Управление продуктом — обширная роль, и она существенно отличается от одной компании к другой. Недавно я прочитал прекрасную 600-страничную книгу по управлению продуктами под названием Священная семерка: навыки, необходимые для того, чтобы стать менеджером по управлению проектами мирового уровня, и я не могу уместить ее в этом документе. Тем не менее, изображение ниже от McKinsey очень хорошо обобщает то, что менеджеры по проектам делают ежедневно.

PM in AL-ML

Компании устремились в облако; теперь они бросятся на ИИ?

Компании, большие или малые, бросились к облачным вычислениям (или были перепроданы консалтинговыми компаниями), но более 50% компаний не могут извлечь выгоду. Цитата ниже является одной из причин, почему?

«Многие организации допустили ошибки во время пандемии с чрезмерно сложной инфраструктурой и без должного учета операционных последствий».
— Дэвид Линтикум, директор по облачным стратегиям, Deloitte Consulting LLP

Волна GPT означает, что будет безумный ажиотаж по внедрению ИИ, и хороший PM позаботится о том, чтобы их компания не повторила тех же ошибок.

Роль PM: Быть стратегическим

Компании, а также частные лица пытаются оседлать волну ИИ. Компании включают «AI» в свое доменное имя и описание продукта, а руководители используют слово «AI» или «ML» в обращениях к инвесторам, чтобы привлечь инвесторов. В этом нет ничего плохого для компании, если только вы не имеете никакого отношения к ИИ, и тогда FTC вас поймает ☹. Однако при разработке продукта продакт-менеджер должен быть более стратегическим и спросить себя, действительно ли ему нужен ИИ. Инвестирование в ИИ ради него может привести к потере ценности и ухудшению качества обслуживания клиентов.

PM в области искусственного интеллекта должен учитывать рентабельность инвестиций (ROI) и проводить анализ затрат и выгод, прежде чем приступать к проекту. Жизненный цикл продукта машинного обучения не так детерминирован, как традиционная разработка программного обеспечения; следовательно, он имеет более высокие риски, чем традиционная разработка программного продукта. Таким образом, к проектам ИИ следует привязывать более высокую ставку дисконта. Выполнение анализа затрат и результатов и расчет рентабельности инвестиций сложны, потому что все в проекте ИИ переплетено, и ваши первоначальные оценки, безусловно, будут ошибочными. Ссылки на отраслевые тематические исследования и результаты конкурентов могут быть полезными. Разработайте гипотезу, сделайте предположения и постройте модель. Определите показатели успеха и определите, как будет выглядеть успех.

Я немного изменил структуру от Google PM Джеймса Смита, чтобы определить, следует ли вам использовать AI/ML.

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

Возможности команды (Кто должен быть в команде?) — Структура команды

Некоторые компании пытаются нанять специалистов по данным или инженеров по машинному обучению, которые могут выявлять шаблоны, разрабатывать модели, развертывать их, подготавливать информационные панели и обновлять их. Это нереально. Однако то, что компании могут сделать, по крайней мере на начальном этапе, — это нанять подрядчиков. Недостаток заключения контракта заключается в потере ноу-хау при увольнении работника, но он может быть эффективным до того, как будет подтверждено экономическое обоснование. Или начните с одного специалиста по данным/инженера машинного обучения, и тогда вы быстро увидите, что потребность в инженерах-программистах и ​​специалистах по ИТ (операциям) будет расти намного быстрее, чем в специалистах по данным.

Жизненный цикл продукта AI/ML

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

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

Обзор

Определение проблемы и цели

Основная задача менеджера по продукту — определить проблему, которую решает команда. Хотя на первый взгляд это может показаться простым, продакт-менеджер должен стремиться определить/объяснить проблему с такой ясностью, чтобы, если формулировка проблемы была передана группе людей, каждый предложил аналогичное решение на высоком уровне. По сути, это определение проблемы становится движущей силой решения (решений). Именно здесь PM будет проводить большую часть своего времени. Как и в случае с любым другим проектом, проблема должна быть ориентирована на клиента (внутреннего/внешнего) и будет определена после обширных исследований и открытий клиентов.

Определите, что вы пытаетесь превзойти. — Установите контрольные показатели на основе результатов на уровне человека, текущих возможностей компании и отраслевой литературы. Развернули ли конкуренты AI/ML для решения аналогичной проблемы?

Почему система рекомендаций TikTok лучше, чем у Instagram и YouTube?

TikTok был разработан как приложение машинного обучения с первого дня, для IG были добавлены функции машинного обучения. Таким образом, TikTok был разработан для просмотра только одного видео за раз, тогда как в IG пользователь мог просматривать несколько изображений/видео одновременно. В TikTok легко измерить интерес и вовлеченность пользователей в видео, но не в IG. Вывод заключается в том, чтобы привлечь команды UX и ML к определению продукта, чтобы такие параметры можно было учитывать на ранней стадии.

Определите инфраструктуру развертывания грубого заказа.

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

Соответствие GDPR и CCPA также следует обсуждать на этапах создания прототипа. Добавление соответствия на этапе развертывания усложняет операции. Например, GDPR имеет право быть забытым. Это означает, что компания должна удалить пользовательские данные из ВСЕХ баз данных по запросу пользователя.

Предоставить доказательство концепции и производственных целей:

Цель POC – определить, является ли приложение работоспособным и стоит ли запускать его в производство. Не тратьте время на создание конвейера данных/модели или автоматизацию системы. Поощряйте свою команду быть щепетильной, работать в блокнотах (блокнот Jupyter и т. д.) и делать заметки, чтобы можно было воспроизвести результаты. Используйте как можно больше инструментов с открытым исходным кодом и комплексных управляемых сервисов, чтобы быстро развернуть модель. Для модели машинного обучения среднего варианта использования этого можно достичь за 3 спринта (4–6 недель).

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

Определите метрики «да» и «нет».
Сначала обсудите модель и зависимости данных, а также сценарии «что, если».

Цели производственного этапа. Поощряйте команду использовать сложные инструменты для автоматизации системы. Высокий уровень автоматизации CI/CD/CT/CM (непрерывная интеграция, доставка, тестирование и мониторинг) будет поддерживать актуальность моделей. Работа PM в производстве заключается в обеспечении того, чтобы улучшение показателей машинного обучения действительно приводило к улучшению бизнес-показателей.

Почему модели машинного обучения строятся, но не развертываются?

Этот вопрос частично вдохновил эту статью. Недавно я прочитал, что по оценкам Gartner, 85% построенных моделей машинного обучения никогда не развертываются. Я прошел несколько курсов, на которых за несколько недель научился создавать систему рекомендаций и модели классификации изображений, но могу ли я развернуть эти модели и сделать их сервисом для использования людьми? Не просто. Это заставило меня копнуть глубже, а затем пройти курс Machine Learning Operations (MLOPs).

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

Этот твит от 2018 года говорит сам за себя. Однако с тех пор было разработано множество инструментов для решения этой проблемы. В последнем разделе статьи есть рисунок инструментов, которые будут использоваться на разных этапах проекта ML. Кроме того, при развертывании система никогда не бывает просто одной моделью; несколько моделей взаимодействуют друг с другом и с другими частями системы/микросервисов, увеличивая сложность системы. Кроме того, в большинстве компаний существует большая стена между специалистами по обработке и анализу данных и инженерами-программистами, и продакт-менеджерам приходится работать над ее преодолением.

Настройка культуры

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

Данные

PM должен участвовать в полном жизненном цикле данных проекта ML и задавать следующие вопросы.

Что делать, если данные недоступны?

■ Можете ли вы собирать оперативные данные о своем бизнесе?
■ Сканировать веб-страницы для получения данных? Форумы, на которых клиенты обсуждают ваши продукты и продукты конкурентов?
■ Открытые источники данных Gov, Kaggle, Google, Amazon и т. д.
■ Данные о покупках у кого-то вроде Neilson.
■ Синтезируйте достоверные данные, прочесывая данные из нескольких источников.

Разработка функций:

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

Используйте подход, ориентированный на данные, а не на модель.

«Разумный алгоритм с хорошими данными часто превосходит отличную модель с не очень хорошими данными», — Эндрю Нг.

«Ни одно другое действие в жизненном цикле машинного обучения не дает более высокой отдачи от инвестиций, чем улучшение данных, к которым у модели есть доступ».—Гойек.

Сосредоточьтесь на надежных данных, которые
■ охватывают все важные пограничные случаи,
■ обеспечивают отсутствие перекосов и предвзятости
■ последовательность в ярлыках
■ создают система/процесс, чтобы обеспечить своевременную обратную связь от производственных данных по данным и концептуальным дрейфам.

Вопросы для обсуждения с техническим руководителем или техническим руководителем:
■ Инфраструктура отслеживания данных: происхождение и происхождение данных.
■ Соблюдение GDPR, CCPA и других законов о конфиденциальности.
▬ Право на забвение — Запрос на удаление пользовательских данных из ВСЕХ наборов данных и копий.
▬ Право на ратификацию — Правки/исправления во всех наборах данных.
▬ Право на доступ к собственным данным пользователя.
▬ Прочие права GDPR.
■ Обсуждение необходимых мер безопасности.

Разработка модели

После того, как цели и источник данных четко определены, PM отступает и позволяет группе инженеров работать над разработкой модели для разработки вариантов. Обеспечьте сотрудничество между учеными по данным (или инженерами по машинному обучению), инженерами по данным и инженерами по ИТ/программному обеспечению на начальных этапах проекта. Это обеспечит создание инфраструктуры ввода (данных) и вывода (модели) вместе с разработкой модели. Я говорю по своему опыту инженера, инженеры любят создавать и развертывать причудливые штуки, а PM должен привносить дисциплину и сосредоточенность, чтобы система не перестраивалась. Здесь премьер-министр устанавливает приоритеты.

Одним из непреложных требований команды инженеров является воспроизводимость результатов, и для этого потребуются командные усилия. PM должен будет преодолеть разрыв между Data-Scientist и Software Engineers. Это также потребует новых процессов. В разработке программного обеспечения существует стандартная практика отслеживания кода, но для ML, наряду с кодом, инженерная группа должна отслеживать эксперименты, что потребует отслеживания комбинаций кода, модели, данных (используемых для этого эксперимента), гиперпараметры и связанные с ними результаты. Существуют такие инструменты, как Neptune.ai, разработанные специально для отслеживания экспериментов машинного обучения.

Отслеживание кода → Отслеживание модели → Отслеживание данных → Отслеживание гиперпараметров → Результат отслеживания

Вопросы для обсуждения с техническим руководителем:
■ как мы измеряем производительность двух моделей помимо учета точности
■ непрерывная интеграция и непрерывная доставка
■ непрерывная Тестирование
■ Тестирование модели на фрагментах данных, представляющих все варианты использования
■ Этапы MLOps (уровни 0, 1 и 2)
■ Инфраструктура отслеживания данных и экспериментов
■ Возможность повторного использования моделей и модульная конструкция
■ Использование управляемых служб

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

Проверка продукта:

Менеджер по продукту проверяет результаты различных моделей машинного обучения с помощью A/B-тестирования. A/B-тестирование является мощным инструментом, но для тестирования нескольких моделей следует использовать более продвинутые методы тестирования, такие как Многорукий бандит и Контекстный бандит. Менеджеры по продуктам должны работать с ИТ-менеджерами для разработки системы, в которой можно тестировать несколько моделей, поскольку производительность модели на тестовых данных будет значительно отличаться от реальных реальных данных. В этом блоге Netflix описывает метод, который они использовали для ускоренного тестирования сотен моделей рекомендаций.

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

Преобразуйте метрики модели в бизнес-метрики:

PM переводит улучшения в показателях модели в бизнес-показатели и постоянно наблюдает за этим соотношением. Например, 10-процентное повышение CTR (Click Through Rate) может привести к 100-процентному повышению рентабельности инвестиций в маркетинговую деятельность. Точно так же 10-процентное улучшение рекомендации продукта может означать привлечение большего трафика к этому поставщику. Из-за эффекта маховика другие поставщики со временем выпадают из системы (нежелательный результат). PM должен иметь целостное представление о системе и принимать решения для достижения положительных результатов в бизнесе.

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

Глубокое понимание показателей ML, таких как Precision, Recall, AUC, оценка F1 и т. д., является обязательным. Эти метрики не будут здесь определяться, но я бы посоветовал начинающим менеджерам по машинному обучению углубиться в метрики до уровня, на котором они смогут интуитивно понять, какая метрика применима к проблеме. Запуск регрессии (y для нескольких независимых переменных x) занимает несколько минут, но анализ (чтобы понять историю, которую рассказывают данные, может занять несколько часов). Внимание к деталям имеет первостепенное значение; дополнительное внимание к выбросам избавит вас от головной боли позже.

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

Развертывание

  • Работайте с отделом маркетинга, чтобы предоставить ИТ-отделу оценку роста/трафика/запросов пользователей. ChatGPT вырос до 1 миллиона пользователей всего за пять дней. Хотя это здорово для компании, это имеет свою цену. Предоставление оценок роста запросов ИТ-команде и работа с ними позволит обеспечить экономичное и эффективное масштабирование.
  • PM также должен работать с инженерами-программистами, чтобы определить автоматические триггеры в системе для смещения данных и концепций.
  • Определите, когда и как будет выполняться повторное обучение модели. Автоматическое переобучение модели не рекомендуется; триггеры должны быть настроены на оповещение о появлении новых данных и определений концепций.
  • PM должен работать с юридическими командами, чтобы модели соответствовали нормативным требованиям юрисдикции.
  • Защитите пользовательские данные от атак: работайте с командой разработчиков модели, чтобы защититься от атак злоумышленников. Злоумышленники могут обмануть модель, чтобы получить нежелательные результаты, украсть обученную модель и, что еще хуже, воссоздать обучающие данные, просто используя модели и их результаты.

Для такой крупной компании, как Airbnb, которая разрабатывает свои инструменты, большинству компаний, не входящих в гипермасштабные компании, лучше использовать управляемые услуги или инструменты с открытым исходным кодом. MLOps — это расширение DevOps, которое стандартизировано, но ключевое отличие заключается в неизвестных значениях в MLOps. Я повторяюсь, но почти все повторяется, что делает его сложным.

Обмен сообщениями с вашим пользователем

Модели не идеальны; в некоторых случаях, даже с точностью всего 60–70%, их развертывание все же может иметь смысл с точки зрения бизнеса. Но задача состоит в том, чтобы обратиться к своим клиентам и сформировать у них правильные ожидания. По мере развития человеческого поведения люди помнят неудачи. Ваша модель может давать ложные или бессмысленные результаты только в одном случае из десяти, но люди будут чаще обсуждать этот сбой. Именно так работают люди, поэтому от PM и PMM требуется тяжелая работа, чтобы пользователи понимали ограничения службы.

Советы, которые помогут:
■ Тщательно продумайте, как вы представляете результаты, чтобы завоевать доверие пользователей.
■ Предоставьте легко читаемые заявления об отказе от ответственности,
■ Обеспечьте доверие уровни или диапазон в результатах,
■ По возможности показывайте 3 основные рекомендации/результаты вместо 1 основного
■ Предоставьте пояснения, в одной строке укажите основные функции, использованные для вывода.
Эти элементы будут иметь большое значение для завоевания доверия пользователей.

Модели потерпят неудачу, будьте готовы к этому моменту

Продукты машинного обучения в производстве или тестировании выйдут из строя и создадут негативный PR или кризисный момент; именно здесь PM должен быть готов изящно справиться с кризисным моментом. Мягкие навыки здесь имеют решающее значение. Открытость с вашими клиентами с самого начала сделает преодоление таких эпизодов менее болезненным.

Дополнительные комментарии

Два типа продуктов ИИ
1. Инструменты ИИ
2. Разработка продуктов с использованием возможностей ИИ.

Если вы проектный менеджер, разрабатывающий инструмент искусственного интеллекта, например, магазин функций для AWS Sage maker, вам необходимо знать технические детали. Тщательно изучив рабочий процесс, вы сможете определять пробелы, выявлять болевые точки клиентов и предлагать решения. Однако предположим, что ваш продукт использует возможности ИИ для повышения его ценности для клиентов; затем необходимо знать возможности различных API, доступных на рынке и в разработке.

Будьте в курсе достижений и ограничений.

Недавно я прошел строгий курс Предпринимательство в области программного обеспечения, который одновременно преподают три легендарных профессора (Грег Готтесман, доктор медицинских наук и соучредитель PSL, Эд Лазовска — профессор, а также почетный заведующий кафедрой Билла и Мелинды Гейтс и Орен Эциони — серийный предприниматель). , генеральный директор Института искусственного интеллекта Аллена). В этом классе учащиеся бизнес-школы объединяются со студентами CS и школы дизайна, чтобы разработать идею и решение в течение десяти недель. Многие команды разрабатывали умопомрачительные продукты AI/ML в течение 5–6 недель (первые четыре недели ушли на придумывание идей). Такие продукты, как услуги перевода подкастов по запросу, включая перевод эмоций! Не умаляя удивительных способностей студентов UW CS, я узнал, что, используя существующие API, можно за короткое время разрабатывать отличные продукты AI/ML. Менеджеры по проектам могут изобретать способы решения проблем клиентов, используя доступные API. Знание технической осуществимости высокого уровня может привести ко многим идеям. Кроме того, хотя скорость разработки важна, модульность не менее важна. Необходима разработка решений, позволяющих легко заменить один набор API новым, более эффективным API. Через несколько недель после того, как OpenAI выпустила свой API GPT 3.5, Notion использовала их и развернула на платформе. Они должны иметь возможность легко переключаться, скажем, на Google Bard API, если со временем это окажется более эффективным и точным.

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

Зная, что ChatGPT обучался на данных до сентября 2021 года, вы поймете, что его нельзя использовать в вашем приложении-агрегаторе новостей.

Недавно я прошел специализацию на Coursera: Инженерия машинного обучения для производства (MLOps) от DeepLearning.AI (компания знаменитого Эндрю Нг). Ниже представлена ​​визуализация методов, терминологии и инструментов, которые я изучил в ходе курса.

Жизненный цикл машинного обучения: инструменты, методы и терминология — (конечно, не исчерпывающий)

Спасибо, что прочитали это. Надеюсь, вам понравилось и вы нашли, что потратили на это время. Если вы хотите обсудить со мной какие-либо аспекты, пожалуйста, свяжитесь со мной в Linkedin.

Спасибо,
Ишан Шах, инженер и MBA
Linkedin.