Создание структуры возможностей для предоставления решений AI/ML в сложных и строго регулируемых средах.

ИИ (особенно приложения для машинного обучения и глубокого обучения) быстро превращается из новинки в необходимость для организаций в условиях жесткой конкуренции и меняющихся ожиданий клиентов. В то же время, с экспоненциальным ростом в глобальном BoK Data Science, активным сообществом разработчиков открытого исходного кода, пиком популярности грамотности данных и смещением акцента на расширенную аналитику самообслуживания (например, визуальную инженерию данных, AutoML), бизнес-решение производители могут легко использовать, чтобы ответить на соответствующие вопросы, модели теперь стали утилитой. Теперь основное внимание уделяется воспроизводимому и простому способу производства решений с поддержкой ML/DL, обеспечивая при этом соблюдение нормативных и управленческих требований, а также после запуска отслеживая и поддерживая их, а также развивая их на основе отзывов и производительности.

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

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

Препятствия для внедрения ОД

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

Возможно, вы уже читали несколько статей на похожие темы: «Почему ML терпит неудачу» или «Почему проекты не продвигаются дальше POC» и так далее. Большинство таких статей пишут консультанты (думаю, MBB, большая пятерка) или поставщики платформ ИИ, которые затем продвигают свои продукты или услуги как панацею, или DS/MLE/технари, которые рассказывают о проблемах с данными, моделях и т. д. Тем не менее, это мнение непредвзятого практика, поэтому читайте дальше, если вы являетесь руководителем продукта или менеджером по решениям и хотите получить более широкий контекст о препятствиях, с которыми вы можете столкнуться.

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

  • Коммерческая ценность/экономическое обоснование не были четко определены и согласованы в начале POC

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

  • Заинтересованные стороны в организации не получают согласия

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

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

  • Контекстная осуществимость варианта использования не оценивается

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

  1. Доступность данных в требуемой форме и формате и в достаточном объеме, наличие необходимых алгоритмов/жизнеспособных реализаций требуемых методов машинного обучения, существующий стек технологий и инфра+технологическая стратегия, не поддерживающая данные
  2. Возможность аудита, требования к использованию AI/ML для конкретных стран, воспроизводимость, одобрение регулирующих органов для развертывания
  3. Конфиденциальность данных, локализация данных, трансграничные запросы данных, локальное и облачное хранилище данных
  • Проблемы масштабного развертывания не совсем понятны

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

Тем не менее, многие важные аспекты работающей, обслуживающей модели не учитываются или делаются предположения на этапе POC: конвейер данных, конвейер ML CI/CD, техническая производительность и мониторинг модели, отзывы пользователей, постоянное улучшение модели, канареечное тестирование, лидер/претендент. развертывание модели, UX и представление результатов модели, правила страны и условия развертывания в процессе/платформе/экспертизе, требования IAM, требования к вычислениям и пропускной способности данных и т. д. Развертывание продукта ML/DL в среде реального обслуживания — это совершенно другая игра с мячом, и обещая нереальные сроки старшему руководству. без учета этих аспектов — быстрый путь к провалу.

  • Ответственный ИИ и модельный риск, не заложенный в жизненный цикл разработки

По мере того, как ML/DL становится массовым явлением и используется для автоматизации решений, оказывающих реальное влияние на клиентов, регулирующие органы начинают издавать руководства и предписывать настройку внутренних политик, процедур и средств контроля для ответственного использования. MAS, HKMA, ECB находятся на переднем крае здесь. Банки также требуют оценки риска модели в случае использования моделей ML/DL в расчетах капитала, расчетах PD/LGD и т. д.

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

Однако, учитывая, что большинство продуктов быстро масштабируются из POC, управляемых технически ориентированными командами, такие аспекты, как компромисс между сложностью модели и производительностью (нам действительно нужно использовать эту ИНС?), управление версиями и архивация (данные и обученная модель), документация, предвзятость данных обнаружение и обработка, подотчетность и право собственности и т. д. отходят на второй план. Есть причина, по которой банки до сих пор используют логистическую регрессию или GLM для большинства рег. расчеты сегодня: результаты имеют высокую объяснимость, веса признаков легко найти и задокументировать. Конечные пользователи и владельцы моделей также могут уверенно подписывать/принимать модели. Не так для ML/DL. Поскольку эти аспекты несколько неоднозначны, требуется сильный менеджер по продукту, чтобы интерпретировать их с точки зрения требований к решению и воздействия.

  • Непонимание необходимости в новой структуре

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

  • Наука о данных!=разработка приложений

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

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

  1. Основное внимание уделяется платформе/технологии, а не показателям ценности бизнеса, например. увеличение доходов, измеримая эффективность процессов, снижение операционных рисков, экономическая эффективность
  2. Проекты ML/DL обрабатываются как традиционные проекты программного обеспечения, т.е. требования идут от бизнеса-›представитель малого и среднего бизнеса-›менеджер проекта-›(в некоторых случаях) BA-›MLE, специалисты по данным и команды разработчиков приложений. SME, BA — это универсалы, которые «модернизируются» из обычных программных проектов.

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

Как MLOps (частично) отвечает на вызов

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

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

• Практика сотрудничества и общения между специалистами по данным, бизнесом и DevOps. Поощряет бизнес-операции, управляемые данными.

•Повышает автоматизацию и повышает качество производственного машинного обучения.

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

Наблюдается всплеск интереса к MLOps, о чем свидетельствует увеличение количества статей, написанных на эту тему (например, Forbes и PwC для этой платформы) для решений от Microsoft Azure, Datarobot, Dataiku, MLFlow, Converge.ai и смещение интереса от инструментов разработки моделей к комплексным решениям, которые облегчают прием и сохранение данных (например, хранилище данных), инженерию данных, разработку и хранение функций, разработку моделей, репозиторий моделей, развертывание, регистрацию и управление версиями, мониторинг и управление модели. Есть даже новый курс по MLOps от Эндрю Нг на Coursera.

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

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