Платформенная агентная модель производственного кластера

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

Фоновое фото баннера статьи: Pavel Danilyuk

В данной публикации мы описываем прототип и исследуем оркестровку нескольких агентных моделей связанных друг с другом роботизированных фабрик (представленных каждая своей моделью) с применением универсальной платформы данных – добиваясь симуляции наблюдаемых и прогнозных свойств группы фабрик (производственного кластера). В прототипе были задействованы программный комплекс NetLogo для агентных моделей фабрик (с моделью «Robotic Factory» [1] в качестве основы) и платформа данных InterSystems IRIS для оркестровки NetLogo и сквозной симуляции системы «фабрики-кластер».

Author: Sergey Lukyanchikov, Sales Engineer at InterSystems

What is Distributed Artificial Intelligence (DAI)?

Attempts to find a “bullet-proof” definition have not produced result: it seems like the term is slightly “ahead of time”. Still, we can analyze semantically the term itself – deriving that distributed artificial intelligence is the same AI (see our effort to suggest an “applied” definition) though partitioned across several computers that are not clustered together (neither data-wise, nor via applications, not by providing access to particular computers in principle). I.e., ideally, distributed artificial intelligence should be arranged in such a way that none of the computers participating in that “distribution” have direct access to data nor applications of another computer: the only alternative becomes transmission of data samples and executable scripts via “transparent” messaging. Any deviations from that ideal should lead to an advent of “partially distributed artificial intelligence” – an example being distributed data with a central application server. Or its inverse. One way or the other, we obtain as a result a set of “federated” models (i.e., either models trained each on their own data sources, or each trained by their own algorithms, or “both at once”).

Distributed AI scenarios “for the masses”

We will not be discussing edge computations, confidential data operators, scattered mobile searches, or similar fascinating yet not the most consciously and wide-applied (not at this moment) scenarios. We will be much “closer to life” if, for instance, we consider the following scenario (its detailed demo can and should be watched here): a company runs a production-level AI/ML solution, the quality of its functioning is being systematically checked by an external data scientist (i.e., an expert that is not an employee of the company). For a number of reasons, the company cannot grant the data scientist access to the solution but it can send him a sample of records from a required table following a schedule or a particular event (for example, termination of a training session for one or several models by the solution). With that we assume, that the data scientist owns some version of the AI/ML mechanisms already integrated in the production-level solution that the company is running – and it is likely that they are being developed, improved, and adapted to concrete use cases of that concrete company, by the data scientist himself. Deployment of those mechanisms into the running solution, monitoring of their functioning, and other lifecycle aspects are being handled by a data engineer (the company employee).

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

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

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

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

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

Challenges of real-time AI/ML computations

• A “high-load” customer portal is integrated with an online recommendation system. The plan is to reconfigure promo campaigns at the level of the entire retail network (we will assume that instead of a “flat” promo campaign master there will be used a “segment-tactic” matrix). What will happen to the recommender mechanisms? What will happen to data feeds and updates into the recommender mechanisms (the volume of input data having increased 25000 times)? What will happen to recommendation rule generation setup (the need to reduce 1000 times the recommendation rule filtering threshold due to a thousandfold increase of the volume and “assortment” of the rules generated)?
• An equipment health monitoring system uses “manual” data sample feeds. Now it is connected to a SCADA system that transmits thousands of process parameter readings each second. What will happen to the monitoring system (will it be able to handle equipment health monitoring on a second-by-second basis)? What will happen once the input data receives a new bloc of several hundreds of columns with data sensor readings recently implemented in the SCADA system (will it be necessary, and for how long, to shut down the monitoring system to integrate the new sensor data in the analysis)?
• A complex of AI/ML mechanisms (recommendation, monitoring, forecasting) depend on each other’s results. How many man-hours will it take every month to adapt those AI/ML mechanisms’ functioning to changes in the input data? What is the overall “delay” in supporting business decision making by the AI/ML mechanisms (the refresh frequency of supporting information against the feed frequency of new input data)?

Вызовы AI/ML-вычислений реального времени

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

Fixing the terminology

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