В своем знаменитом выступлении Искусственный интеллект - это новое электричество Эндрю Нг заявил:

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

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

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

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

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

Причина, по которой это не сработало, заключалась в том, что большинство этих организаций полагались на центральную мобильную команду, которая отвечала за внедрение собственных мобильных функций. В состав продуктовых команд входили инженеры по бэкэнду, веб-интерфейсу и DevOps, которые могли независимо реализовать продукт для Интернета. А когда дело дошло до мобильных устройств, продуктовым группам нужно было занести свои требования в список невыполненных задач центральной мобильной группы. Перед началом внедрения мобильной команде пришлось расставить приоритеты вместе с другими требованиями, исходящими от других продуктовых групп. Это узкое место привело к тому, что мобильные функции стали последней частью продукта, выпущенного для пользователей, и «сначала мобильные» остались только термином.

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

Лучший подход

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

Хотя продукты машинного обучения должны создаваться в продуктовых группах, центральная группа данных по-прежнему необходима, однако ее роль должна заключаться в создании инфраструктуры данных всей организации и обеспечении поддержки группам продуктов. Создание озера данных, внедрение ELT или ETL, а также обеспечение доступности данных для остальной части организации - основные задачи центральной группы данных. LinkedIn, например, пошла еще дальше, предоставив рынок функций, целую цепочку инструментов и инфраструктуру, позволяющую другим командам заниматься ИИ: Демократизация ИИ.

Как туда добраться

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

  • Интеграция специалистов по обработке данных в функциональные группы:. Это хороший вариант, когда команде нужно работать над низкоуровневым машинным обучением с глубоким пониманием алгоритмов. Приятным побочным эффектом этой опции является то, что специалисты по обработке данных могут распространять свои знания в команде путем парного программирования с другими инженерами и обучения их (я бы сказал, что обучение не только модели может быть интересной задачей для специалиста по данным :)). Большой проблемой этого варианта является сохранение интеграции специалистов по данным в команду и предотвращение создания команды внутри команды. Кроме того, такая организация работы команды, чтобы у всех было много важных дел, может стать проблемой для менеджеров по продукту в команде.
  • Подготовка инженеров-программистов для машинного обучения. Многие инженеры-программисты заинтересованы в изучении и применении машинного обучения в своей повседневной работе. По этой теме доступно множество высококачественных и недорогих онлайн-классов. Задача инженерного менеджмента здесь - дать инженерам время и доверие для достижения этой цели. Этот вариант также является отличным шансом дать инженерам организации путь развития.
  • Использование готовых сервисов. Многие крупные игроки, такие как Amazon, Microsoft и Google, предлагают готовые услуги ИИ, которые можно применять для улучшения продуктов с помощью функций ИИ. К этой категории относятся такие услуги, как распознавание изображений / текста / речи и рекомендации. Хотя эти услуги не обеспечивают гибкости низкоуровневого машинного обучения, они могут быть самым быстрым способом для продуктовой группы реализовать первые функции ИИ в своем продукте. Также на этапе прототипирования и подтверждения концепции эти услуги очень помогают.

Резюме

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

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

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

Примечание 2. В своем Пособии по преобразованию ИИ Эндрю Нг выступает за создание функций ИИ в центральной команде. Эндрю - лучший учитель, у которого я учусь, но в этом я явно не согласен с ним.

Примечание 3. Поскольку машинное обучение в настоящее время является наиболее распространенной формой ИИ, в этой статье я использую оба термина одинаково.