Agile AI / Machine Learning на предприятии - это миф. Это сдерживается бюрократией и сложными ограничениями, связанными с безопасностью и облачностью. Вот несколько практических шагов, чтобы превратить миф в реальность.

Отсутствие гибкости AI / ML на предприятии ведет к провальным проектам и упущенным возможностям.

Сегодня «гибкий» искусственный интеллект / машинное обучение (AI / ML) на предприятии в значительной степени является мифом и имеет мало общего с построением модели. Скорее, гибкость корпоративного ИИ / машинного обучения ограничивается бюрократическими процессами сбора данных, сложными потребностями в безопасности, незрелыми практиками безопасности облачных вычислений и громоздкими процессами управления ИИ / машинным обучением.

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

Я несколько лет помогал крупным банкам ускорить внедрение искусственного интеллекта / машинного обучения и связанных с ним технологий. В этой статье я расскажу об основных проблемах и препятствиях на пути гибкого ИИ / МО на предприятии, с которыми я столкнулся, а затем предложу несколько извлеченных уроков и некоторые практические шаги, которые станут отправной точкой для превращения мифа об Agile AI / ML в реальность.

Agile на предприятии уже сложна

Agile, вероятно, является наиболее распространенным подходом к реализации ИТ-проектов, но, несмотря на этот успех, послужной список Agile весьма неоднороден. Одно исследование показало, что британские компании потратили около 37 миллиардов фунтов стерлингов на провальные проекты Agile IT в течение 12 месяцев. Согласно недавнему опросу консалтинговой фирмы 6Point6, Agile сталкивается со скрытым кризисом: каждый восьмой (12%) Agile-проект терпит неудачу полностью.

И «ситуация хуже в США, где процент неудач выше, а проекты Agile ИТ длятся дольше и дороже… ИТ-директора Великобритании и США сейчас оценивают, что почти треть (32%) проектов Agile в той или иной степени терпят неудачу. ”

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

AI / ML добавляет новые сложности, препятствующие гибкости

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

  • Бюрократические процессы сбора данных: данные являются источником жизненной силы ИИ / машинного обучения, но большинство предприятий несут значительные задержки для получения необходимых данных, в основном из-за бюрократических процессов, необходимых для извлечения данных из устаревших систем, в которых подавляющее большинство предприятий данные управляются.
  • Специалистам по данным требуются данные «в открытом доступе». Независимо от того, считаются ли они личными (данные клиентов) или конфиденциальными (финансовые данные), или что-то среднее между ними, большая часть того, что требуется специалисту по данным, считается конфиденциальной и является требуется «в открытом виде», что вызывает необходимость в дополнительных мерах безопасности для поддержания уровня безопасности предприятия.
  • Незрелые практики облачной безопасности: AI / ML требует высокопроизводительного оборудования (графических процессоров и т. д.), которое недоступно на предприятии, что вынуждает многие предприятия рассматривать возможность использования облака для своих проектов AI / ML; Хотя методы обеспечения безопасности облачных вычислений в настоящее время развиваются во многих предприятиях, к сожалению, методы обеспечения безопасности данных в облаке еще недостаточно развиты почти на всех предприятиях.
  • Обременительные процессы управления ИИ / МО. Необходимость воспроизводимости, отслеживаемости и проверяемости моделей вынуждает предприятия переходить на гораздо более строгий и дисциплинированный жизненный цикл модели ИИ / МО. К сожалению, многие предприятия обременены практиками корпоративного управления, которые не адаптированы для удовлетворения потребностей AI / ML; Это усугубляется в строго регулируемых отраслях (финансовые услуги, здравоохранение, правительство и т. Д.), Где законы и постановления накладывают дополнительные ограничения на конфиденциальность данных и требуют сохранения артефактов.

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

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

Проблема №1: бюрократические процессы сбора данных

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

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

Что еще хуже, Accenture обнаружила, что проекты почти в половине всех компаний также имеют проблемы с качеством данных, а более чем у трети недостаточно данных для обучения, пригодных для использования. Проблемы с качеством данных бывают разных видов: от отсутствующих или неверных значений до проблем ссылочной целостности. Фактически, исследования и личный опыт показали, что обычно 50–80% усилий проекта AI / ML тратится на инженерные данные для поддержки работы специалистов по данным.

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

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

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

Во-первых, владелец данных определяется как лицо / роль, которым разрешен доступ к данным. Благодаря этому мы можем определить, кто и, возможно, как принимает решения о доступе и авторизации в отношении данных, которые нам нужно получить.

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

Решение: создайте базовый каталог данных. Оба вышеупомянутых атрибута владельца данных и структуры данных могут быть полезны для других проектов и считаются имеющими непреходящую ценность. У моих клиентов мы сохраняли эту информацию в «каталоге данных».

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

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

Проблема № 2: Специалисты по обработке данных требуют данных «в открытом виде»

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

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

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

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

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

Проблема № 3: Незрелые практики облачной безопасности

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

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

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

Решение. Установите базовые политики хранения данных. На эту тему написаны книги, но несколько основных политик, которые я считаю не подлежащими обсуждению, включают: (а) установить четко определенный периметр безопасности, (б) Утечка данных может отсутствовать в периметре безопасности или за его пределами, (c) все хранилища данных и обмен данными зашифрованы, причем ключи, а также процессы ротации ключей принадлежат предприятию, (d) доступ к области хранения регулируется ролями механизм управления доступом на основе доступа (RBAC), который интегрируется с определением роли корпоративной группы пользователей (например, Enterprise AD или LDAP)

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

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

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

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

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

Что касается AI / ML, шаблоны, касающиеся извлечения, обогащения и агрегации данных, особенно полезны. Еще большей эффективности можно добиться, если будет выбран «платформенный» подход, при котором общие компоненты и сквозные задачи, реализующие эти шаблоны, становятся доступными для разработчиков и инженеров.

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

Проблема # 4: громоздкие процессы управления AI / ML

К сожалению, сегодня часто можно увидеть, что корпоративные ИТ управляют процессом доставки AI / ML так же, как и традиционная доставка приложений. Это приводит к тому, что жизненный цикл AI / ML обременен теми же бюрократическими процессами, ручными операциями и передачей обслуживания, которые усложняют жизненный цикл регулярной доставки приложений.

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

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

Например, управление рисками моделей предъявляет строгие требования к аналитическим процессам, чтобы модели AI / ML работали должным образом. В США это решается посредством таких нормативных актов, как SR 11–7, а в Канаде - Руководства по управлению модельными рисками в масштабах всего предприятия (E-23). Однако многие другие отрасли, от здравоохранения и биотехнологий до государственной безопасности, имеют аналогичные нормативные потребности. Управление AI / ML стимулирует возможности, необходимые для удовлетворения этой потребности в отслеживаемости моделей.

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

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

Управление AI / ML дает стимул и механизмы для создания воспроизводимых и повторяемых результатов моделирования. Для удовлетворения этих уникальных потребностей в управлении ИИ / МО необходимы новые методы и инструменты.

Решение: внедрение инструментов управления моделями для оптимизации и автоматизации ключевых процессов управления AI / ML. Основой современного управления AI / ML является возможность фиксировать показатели и метаданные модели AI / ML по всей модели. жизненный цикл. Мои клиенты обычно начинают с основ - весь исходный код модели и версии, поддерживаемые с помощью инструмента управления исходным кодом (например, GitHub или GitLab), позволяют специалистам по обработке данных сотрудничать для быстрой разработки моделей, а также для обеспечения того, чтобы «книга рекордов» для модель всегда хорошо зарекомендовала себя.

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

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

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

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

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

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

Гибкость корпоративного ИИ / машинного обучения можно превратить из мифов в реальность

Я начал с предположения, что «гибкий» искусственный интеллект / машинное обучение (AI / ML) на предприятии в значительной степени является мифом. Я убежден, что по мере того, как предприятия начинают свой путь AI / ML, они столкнутся с теми же препятствиями, которые я указал в этой статье: гибкость корпоративного AI / ML ограничена бюрократическими процессами сбора данных, сложными потребностями в безопасности, незрелыми практиками безопасности облачных вычислений.

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