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

Договариваемся о терминологии

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

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

Взаимодействие с окружением

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

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

Адаптивность и адаптируемость

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

Может ли аналитический процесс «перестроить себя» при изменении структуры окружения? Упростим вопрос: насколько просто перестроить аналитический процесс при изменении структуры окружения? Из наших наблюдений ответ выводится простой и грустный: в большинстве известных нам (не наших!) имплементаций переписывать придется, как минимум, аналитический процесс — а зачастую и содержащийся в нем ИИ. Возможно, не буквально от «входа до выхода» переписывать, но придется программированием что-то добавлять для обработки новых реалий, менять внутреннюю логику самого «моделеприменительного процесса» и т.п. И это может вылиться в запретительно затратное дело – особенно, если окружение меняется динамично.

Агентность: предел автономности?

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

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

Ставим задачу роботу

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

Figure 1 Постановка задачи на классификацию текстов по эмоциональной окраске (англ. sentiment analysis)

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

Данные для задач этого класса любезно собраны, обработаны и опубликованы Ю. Рубцовой.

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

Идем в мастерскую InterSystems

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

Начнем с агентности. Разместим в платформе четыре бизнес-процесса:

Figure 2 Конфигурация агентной системы бизнес-процессов с компонентом для взаимодействия с Python

GENERATOR («генератор») – по мере потребления файлов другими процессами, создает новые файлы с входными данными (размеченные – «позитивные» и «негативные» – твиты, и твиты с неопределенной эмоциональной окраской)
BUFFER («буферизатор») – по мере потребления записей другими процессами, читает новые записи из файлов, создаваемых генератором, и удаляет эти файлы после считывания записей
ANALYZER («анализатор») – потребляя записи из буфера неопределенных твитов, применяет к этим записям обученную сверточную нейросеть и помещает полученные записи с вычисленной «вероятностью позитива» в буфер монитора; потребляя записи из буферов позитивных и негативных твитов, выполняет обучение нейросети
MONITOR («монитор») – потребляя обработанные анализатором записи из собственного буфера, контролирует значения метрик ошибки классификации твитов нейронной сетью в ходе последнего обучения и подает сигнал анализатору о необходимости нового обучения нейросети

Можно схематично представить нашу агентную систему бизнес-процессов следующим образом:

Figure 3 Поток данных в рамках агентной системы

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

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

Figure 4 Обособление в аналитическом процессе-анализаторе основных функций ИИ — обучение (training) и применение (scoring) математических моделей

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

Figure 5 Распознавание процессом-монитором типа модели и применение соответствующих критериев оценки точности моделей

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

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

Figure 6 Процесс-анализатор в графическом редакторе с открытым меню добавления элементов управления

И, наконец, взаимодействие с окружением. Самым важным компонентом окружения, в нашем случае, будет среда математического моделирования Python. Для обеспечения взаимодействия со средами Python и R были созданы соответствующие функциональные расширения: Python Gateway и R Gateway. Ключевым функционалом обоих механизмов является возможность с помощью удобных интеграционных компонентов взаимодействовать с соответствующей средой. Мы уже видели компонент для взаимодействия с Python в конфигурации нашей агентной системы. Таким образом, бизнес-процессы, которые содержат ИИ, реализованный на Python, взаимодействуют с Python.
Например, процесс-анализатор содержит функции обучения и применения моделей, реализация одной из которых на Python в платформе InterSystems IRIS выглядит так:

Figure 7 Реализация на Python в платформе InterSystems IRIS функции обучения моделей в процессе-анализаторе

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

Наиболее часто применяемым видом взаимодействий в нашем примере является передача кода на исполнение в Python:

Figure 8 Код на Python, размещенный в процессе-анализаторе в InterSystems IRIS, отправляется на исполнение в среду Python

В некоторых взаимодействиях происходит возврат данных из контекста Python в контекст процесса InterSystems IRIS:

Figure 9 Визуальная трассировка сеанса работы процесса-анализатора с просмотром информации, возвращаемой Python в один из шагов процесса

Запускаем робота

Запустить робота прямо в этой статье? Почему бы и нет, вот запись нашего вебинара, в ходе которого (помимо ряда других интересных и связанных с роботизацией ИИ историй!) показана работа вышеописанного сценария. Поскольку время вебинара, к сожалению, ограниченно – а показать «полезную работу» нашего роботизированного сценария хочется как можно компактнее и нагляднее – мы поместили ниже более полный обзор результатов обучения моделей (7 последовательных циклов обучения вместо 3 в вебинаре):

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

Какие выводы хотелось бы сделать в завершение статьи:

InterSystems IRIS является мощной платформой для роботизации процессов, опирающихся на искусственный интеллект
Искусственный интеллект может быть реализован как во внешних средах (например, Python и R с их модулями, содержащими уже готовые к использованию алгоритмов), так и в самой платформе InterSystems IRIS (с использованием встроенных библиотек алгоритмов или путем написания алгоритмов на Python или R) – InterSystems IRIS обеспечивает взаимодействие со внешними средами ИИ, позволяя сочетать их возможности с собственным функционалом
InterSystems IRIS роботизирует ИИ с применением «трех А»: адаптируемых, адаптивных и агентных бизнес-процессов (они же аналитические процессы)
InterSystems IRIS работает с внешним ИИ (Python, R) через наборы специализированных взаимодействий: передача/возврат данных, передача кода на исполнение и т.п. В рамках одного аналитического процесса могут осуществляться взаимодействия с несколькими средами математического моделирования
InterSystems IRIS консолидирует в единой платформе входные и выходные данные моделей, выполняет историзацию и версионирование вычислений
Благодаря InterSystems IRIS искусственный интеллект может быть использован как в специализированных аналитических механизмах, так и встроен в OLTP- или интеграционные решения

Тем, кто прочитал статью и заинтересовался возможностями InterSystems IRIS как платформы для разработки или размещения механизмов искусственного интеллекта и машинного обучения, мы предлагаем обсудить возможные сценарии, представляющие интерес для вашего предприятия. Мы с готовностью проанализируем потребности вашего предприятия и совместно определим план действий; контактный адрес электронной почты нашей экспертной группы AI/ML – MLToolkit@intersystems.com.

Роботизация искусственного интеллекта на платформе InterSystems IRIS