Рубрики
IRIS Продукты и технологии

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

Автор: Сергей Лукьянчиков, инженер-консультант InterSystems

Что такое распределенный искусственный интеллект?

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

Сценарии распределенного ИИ «для масс»

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

Пример размещения на платформе InterSystems IRIS продуктивного AI/ML-решения, автономно работающего с потоком данных, поступающих с оборудования, нами приводился в этой статье. Это же решение фигурирует и в демонстрации, ссылка на которую приведена абзацем выше. Самостоятельно создать прототип решения на платформе InterSystems IRIS можно с помощью материалов (бесплатных и без ограничения срока работы) нашего портала-репозитория Convergent Analytics (см. разделы Links to Required Downloads и Root Resources).

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

Рисунок 1 Формулировка сценария распределенного ИИ

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

Как конкретный сценарий распределенного ИИ работает на платформе InterSystems IRIS

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

Главным «агрегатом» бизнес-процесса-передатчика данных является while-цикл (реализован при помощи визуального редактора бизнес-процессов, использующего интерпретируемую платформой InterSystems IRIS нотацию BPL), обеспечивающий систематическую передачу обучающего набора данных внешнему дата-саентисту. Внутри этого «агрегата» реализованы следующие действия (см. диаграмму, пропуская действия по обеспечению согласованности данных):

Рисунок 2 Основной фрагмент «подающего» бизнес-процесса

(а) Load Analyzer – загрузка в бизнес-процесс текущего набора записей из таблицы обучающих наборов данных и формирование на его основе в рабочей сессии Python датафрейма. Действие типа call (вызов), запускает SQL-запрос к СУБД InterSystems IRIS и вызов интерфейса среды Python для передачи ей результата SQL-запроса для формирования датафрейма;

(б) Analyzer 2 Azure – еще одно действие-call, запускает вызов интерфейса среды Python для передачи ей набора инструкций Azure ML SDK for Python для формирования в Azure необходимой инфраструктуры и размещения в эту инфраструктуру данных из датафрейма, сформированного в предыдущем действии;

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

Рисунок 3 «Прибытие» обучающего набора данных в Azure ML

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


Рисунок 4 Завершающий фрагмент «подающего» бизнес-процесса

(в) Resource Cleanup – запускает вызов интерфейса среды Python для передачи ей набора инструкций Azure ML SDK for Python для удаления из Azure созданной в предыдущем действии вычислительной инфраструктуры.

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

Рассмотрим, как устроен бизнес-процесс-приемник: он не требует while-цикла, как бизнес-процесс-передатчик (входящий в семейство процессов автономно работающего AI/ML-решения на предприятии), но в него входит ряд действий, связанных с обучением в Azure ML и в IntegratedML (функционал для применения фреймворков авто-ML в InterSystems IRIS) альтернативных моделей и извлечением результатов этого обучения в InterSystems IRIS (платформа InterSystems IRIS установлена локально у дата-саентиста):

Рисунок 5 «Принимающий» бизнес-процесс

(а) Import Python Modules – запускает вызов интерфейса среды Python для передачи ей команд загрузки необходимых для дальнейших действий модулей Python;

(б) Set AUDITOR Parameters – запускает вызов интерфейса среды Python для передачи ей команд присвоения значений по умолчанию переменным, необходимым для дальнейших действий;

(в) Audit with Azure ML – (про вызов интерфейса среды Python больше не упоминаем) передача Azure ML «задания на аудит»;

(г) Interpret Azure ML – получение в локальную рабочую сессию Python данных, помещенных в Azure ML бизнес-процессом-передатчиком, вместе с результатами «аудита» в Azure ML (а также создание визуализации результатов «аудита» в рабочей сессии Python);

(д) Stream to IRIS – извлечение данных, помещенных в Azure ML бизнес-процессом-передатчиком, вместе с результатами «аудита» в Azure ML, из рабочей сессии Python в переменную бизнес-процесса IRIS;

(е) Populate IRIS – запись данных, помещенных в Azure ML бизнес-процессом-передатчиком, вместе с результатами «аудита» в Azure ML, из переменной бизнес-процесса IRIS в таблицу IRIS;

(ж) Audit with IntegratedML – «аудит» данных, полученных из Azure ML вместе с результатами «аудита» в Azure ML, и записанных в IRIS в предыдущем действии, с помощью функционала IntegratedML (в данном конкретном случае он управляет фреймворком авто-ML H2O);

(з) Query to Python – передача в рабочую сессию Python данных и результатов «аудита» с помощью IntegratedML;

(и) Interpret IntegratedML – создание в рабочей сессии Python визуализации результатов «аудита» с помощью IntegratedML;

(к) Resource Cleanup – удаление из Azure созданной в предыдущих действиях вычислительной инфраструктуры.

Рисунок 6 Визуализация результатов «аудита» в Azure ML

Рисунок 7 Визуализация результатов «аудита» в Integrated ML

Как в общем случае реализуется распределенный ИИ на платформе InterSystems IRIS

Платформа InterSystems IRIS позволяет применить три основных подхода к реализации распределенного ИИ:

  • Прямой обмен ИИ-артефактами при их локальной и централизованной обработке по правилам и алгоритмам, определяемым пользователем самостоятельно
  • Обработка ИИ-артефактов делегируется специализированным фреймворкам (например: TensorFlow, PyTorch), оркестровка обмена и вспомогательные действия настраиваются на локальных и центральной инстанции InterSystems IRIS пользователем самостоятельно
  • И обмен ИИ-артефактами, и их обработка выполняются посредством облачных провайдеров (Azure, AWS, GCP), локальные и центральная инстанции InterSystems IRIS выполняют лишь передачу исходных данных облачному провайдеру и получение от него обратно конечного результата

  • Рисунок 8 Основные подходы к реализации распределенного ИИ на платформе InterSystems IRIS

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

    Теоретические и прикладные элементы, из которых прямо на наших глазах сегодня формируется дисциплина «распределенный искусственный интеллект», пока не обрели «канонического вида», что создает немалый потенциал для инноваций при практической реализации. Наша команда экспертов внимательно следит за эволюцией распределенного ИИ как дисциплины и создает акселераторы для его реализации на платформе InterSystems IRIS. Мы будем рады поделиться нашими наработками и помочь всем тем, кого заинтересовала данная тематика, приступить к прототипированию механизмов распределенного ИИ.

    Контактный адрес электронной почты нашей экспертной группы AI/ML – MLToolkit@intersystems.com.

    Оригинал статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *