Структурные элементы разработки ИИ

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

McKensey разместила очень примечательный insight на эту тему - McKensey. Executive’s guide to developing AI at scale.

https://www.mckinsey.com/business-functions/mckinsey-analytics/our-insights/executives-guide-to-developing-ai-at-scale#intro

Ниже приводится пересказ/перевод данного материала. При этом вся графика - по ссылке. Ниже только тексты.

Технологические комплексы

Среда разработки ИА включает в себя следующие технологические комплексы:

• Лабораторная среда разработки ИА.
• Продуктивная система.
• MLOps - подход к разработке ИА в части систем машинного обучения (ML - Machine Learning).

Лабораторная среда

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

Продуктивная система

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

MLOps

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

Подробнее об этом компоненте можно почитать тут - https://habr.com/ru/company/vtb/blog/508012/

=================================

Рассмотрим подробнее данные компоненты 

=================================

Описание лабораборной среды

Лабораторная среда может быть описана следующиеми подсистемами и процессами:

• Сбор данных.
• Разработка моделей.
• Ролевая модель.

Сбор данных

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

Для организации сбора данных нужно определиться со следующим:

• Исходные, внутренние или внешние системы, с извлекаемыми данными.
• Интерфейсы прикладного программирования (API) для извлечения данных как посредники, обеспечивающие взаимодействие приложений. Примеры - REST API, gPRC, GraphQL.
• Пакетные задания, позволящие или пополнять данные по мере появления новых данных, или порционно обрабатывающие большие объемы данных. 
• Конвейерная обработка данных как последовательность ("оркестровка") шагов обработки данных в автоматизированном режиме.
• "Озеро" данных как централизованное хранилище корпоративных данных в неструктированных форматах. Озера данных позволяют объединять данные из разных источников, чтобы затем создавать на основе этих данных аналитические наборы данных. Озера данных имеют практически неограниченную емкость хранения, что позволяет хранить генерируемые данные, даже если они сразу не применимы в аналитике.
• Каталоги данных как структуры хранения метаданных о том, какие элементы данных существуют, как они связаны, каковы типы и характеристики данных.

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

Разработка моделей состоит из следующих процессов:

• Построение моделей. В процессе построения модели инженеры данных выбирают алгоритмы и методы, которые соответствуют решаемой задаче. Например, это могут быть методы регрессионного анализа, классификационные алгоритмы, методы построения нейронных сетей. Тут же продумываются пользовательские интерфейсы.
• Обучение моделей. Как правило, модели обучаются с использованием программных фреймворков и библиотек. Для прогнозирования требуется обученная модель машинного обучения.
• Тестирование модели. Оценка производительности обученной модели. Обучающие данные обычно делятся в соотношении 60:20:20: обучение 60%, тестирование - 20%, валидация - 20%. Тестирование помогает понять, насколько точно модель будет работать в реальном мире.
• Развертывание модели (deploy) для производственного использования. Стабильные, повторяемые механизмы развертывания позволяют предприятиям гибко и непрерывно обновлять модели после обучения моделей на новых наборах данных.

Технологические компоненты среды разработки моделей состоят в следующем:

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

Роли в рамках лабораторной среды

• Собственник продукта (представитель заказчика)
• Специалист по данным (Data scientist)
• Инженер данных
• Бизнес-консультант
• Дизайнер пользовательских интерфейсов и взаимодействия пользователя с продуктом
• Delivery manager - Менеджер отвечающий за доставку продукта клиенту

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

• Представляет интересы клиента.
• Контактирует с любыми внешними заинтересованными сторонами.
• Анализирует и определяет приоритеты для краткосрочных и среднесрочных целей.
• Привлекает дополнительные ресурсы (например, разработчиков, тестировщиков)по мере необходимости.

Обязанности специалиста по данным (Data scientist)

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

Обязанности инженера данных

• Определяет доступные источники данных и определяет основные исходные системы для загрузки и обработки.
• Разрабатывает "конвейеры" перемещения данных для упрощения и автоматизации работы с данными.
• Определяет архитектуру данных (хранилища данных, слои данных).
• Сотрудничает с специалистами по обработке данных.

Обязанности бизнес-консультанта (Translator)

• Действует как интерфейс между бизнесом-пользователями и техническими специалистами.
• Помогает заказчику продукта найти компромисс между бизнес-требованиями и технической сложностью продукта.
• Готовит интеграционные материалы и презентации.

Обязанности дизайнера пользовательских интерфейсов и взаимодействия пользователя с продуктом

• Сосредоточен на взаимодействии между конечными пользователями.
• Разрабатывает интерфейсы элементы управления пользовательским интерфейсом.

Обязанности Delivery manager - Менеджера отвечающий за доставку продукта клиенту.

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

Продуктивная система

Продуктивная система может быть описана следующими подсистемами:

Интеграция аналитических выводов в практику

Интеграция аналитических выводов в практику

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

Подсистема базируется на следующих технологиях:

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

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

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

Роли в рамках продуктивной системы

• Владелец продукта
• Инженер по машинному обучению
• Инженер MLOps
• Архитекторы облака или инфраструктуры
• Руководитель отдела управления облаком
• Программисты
• Специалисты по обеспечению качества и автоматизации тестирования
• Специалисты в предметной области

Обязанности владельца проекта:

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

Обязанности инженера по машинному обучению

• Оптимизирует модели машинного обучения для повышения производительности и масштабируемости.
• Внедряет модели машинного обучения в производственную среду.
• Автоматизирует конвейеры машинного обучения.

Обязанности инженера MLOps

• Автоматизирует базовую технологическую инфраструктуру.
• Разрабатывает конвейеры непрерывной интеграции (CI) и непрерывного развертывания (CD).

Обязанности архитекторов облака или инфраструктуры

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

Обязанности руководителя отдела управления облаком

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

MLOps

Характеризуется набором способов работы

Hardening

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

Непрерывная интеграция Continuous integaration

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

Непрерывная поставка Continuous delivery

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

Отслеживание проблем и ошибок

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

Логирование

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

Мониторинг

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


McKensey. Executive’s guide to developing AI at scale

https://www.mckinsey.com/business-functions/mckinsey-analytics/our-insights/executives-guide-to-developing-ai-at-scale#intro