{"id":4541,"date":"2021-04-04T06:35:28","date_gmt":"2021-04-04T06:35:28","guid":{"rendered":"https:\/\/www.aiproblog.com\/index.php\/2021\/04\/04\/distributed-artificial-intelligence-with-intersystems-iris\/"},"modified":"2021-04-04T06:35:28","modified_gmt":"2021-04-04T06:35:28","slug":"distributed-artificial-intelligence-with-intersystems-iris","status":"publish","type":"post","link":"https:\/\/www.aiproblog.com\/index.php\/2021\/04\/04\/distributed-artificial-intelligence-with-intersystems-iris\/","title":{"rendered":"Distributed Artificial Intelligence with InterSystems IRIS"},"content":{"rendered":"

Author: Sergey Lukyanchikov<\/p>\n

\n

<\/a><\/strong><\/p>\n

What is Distributed Artificial Intelligence (DAI)?<\/strong><\/p>\n

Attempts to find a \u201cbullet-proof\u201d definition have not produced result: it seems like the term is slightly \u201cahead of time\u201d. Still, we can analyze semantically the term itself \u2013 deriving that distributed artificial intelligence is the same AI (see our effort<\/a> to suggest an \u201capplied\u201d 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 \u201cdistribution\u201d have direct access to data nor applications of another computer: the only alternative becomes transmission of data samples and executable scripts via \u201ctransparent\u201d messaging. Any deviations from that ideal should lead to an advent of \u201cpartially distributed artificial intelligence\u201d \u2013 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 \u201cfederated\u201d models (i.e., either models trained each on their own data sources, or each trained by their own algorithms, or \u201cboth at once\u201d).<\/p>\n

Distributed AI scenarios \u201cfor the masses\u201d<\/strong><\/p>\n

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 \u201ccloser to life\u201d if, for instance, we consider the following scenario (its detailed demo can and should be watched here<\/a>): 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 \u2013 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).<\/p>\n

An example of deployment of a production-level AI\/ML solution on InterSystems IRIS platform that works autonomously with a flow of data coming from equipment, was provided by us in this article<\/a>. The same solution runs in the demo under the link provided in the above paragraph. You can build your own solution prototype on InterSystems IRIS using the content (free with no time limit) in our repo \u00a0Convergent Analytics<\/a> (visit sections Links to Required Downloads<\/a> and Root Resources<\/a>).<\/p>\n

Which \u201cdegree of distribution\u201d of AI do we get via such scenario? In our opinion, in this scenario we are rather close to the ideal because the data scientist is \u201ccut from\u201d both the data (just a limited sample is transmitted \u2013 although crucial as of a point in time) and the algorithms of the company (data scientist\u2019s own \u201cspecimens\u201d are never in 100% sync with the \u201clive\u201d mechanisms deployed and running as part of the real-time production-level solution), he has no access at all to the company IT infrastructure. Therefore, the data scientist\u2019s role resolves to a partial replay on his local computational resources of an episode of the company production-level AI\/ML solution functioning, getting an estimate of the quality of that functioning at an acceptable confidence level \u2013 and returning a feedback to the company (formulated, in our concrete scenario, as \u201caudit\u201d results plus, maybe, an improved version of this or that AI\/ML mechanism involved in the company solution).<\/p>\n

<\/a><\/p>\n

Figure 1 Distributed AI scenario formulation<\/em><\/p>\n

We know that feedback may not necessarily need to be formulated and transmitted during an AI artifact exchange by humans, this follows from publications about modern instruments and already existing experience around implementations of distributed AI. However, the strength of InterSystems IRIS platform is that it allows equally efficiently to develop and launch both \u201chybrid\u201d (a tandem of a human and a machine) and fully automated AI use cases \u2013 so we will continue our analysis based on the above \u201chybrid\u201d example, while leaving a possibility for the reader to elaborate on its full automation on their own.<\/p>\n

How a concrete distributed AI scenario runs on InterSystems IRIS platform<\/strong><\/p>\n

<\/a>The intro<\/a><\/a>\u00a0to our video with the scenario demo that is mentioned in the above section of this article gives a general overview of InterSystems IRIS as real-time AI\/ML platform and explains its support of DevOps macromechanisms. In the demo, the \u201ccompany-side\u201d business process that handles regular transmission of training datasets to the external data scientist, is not covered explicitly \u2013 so we will start from a short coverage of that business process and its steps.<\/p>\n

A major \u201cengine\u201d of the sender business processes is the while-loop (implemented using InterSystems IRIS visual business process composer that is based on the BPL<\/a> notation interpreted by the platform), responsible for a systematic sending of training datasets to the external data scientist. The following actions are executed inside that \u201cengine\u201d (see the diagram, skip data consistency actions):<\/p>\n

<\/a><\/p>\n

Figure 2 Main part of the \u201csender\u201d business process<\/em><\/p>\n

(a) Load Analyzer \u2013 loads the current set of records from the training dataset table into the business process and forms a dataframe in the Python session based on it. The call-action triggers an SQL query to InterSystems IRIS DBMS and a call to Python interface to transfer the SQL result to it so that the dataframe is formed;<\/p>\n

(b) Analyzer 2 Azure \u2013 another call-action, triggers a call to Python interface to transfer it a set of Azure ML SDK for Python instructions to build required infrastructure in Azure and to deploy over that infrastructure the dataframe data formed in the previous action;<\/p>\n

As a result of the above business process actions executed, we obtain a stored object (a .csv file) in Azure containing an export of the recent dataset used for model training by the production-level solution at the company:<\/p>\n

<\/a><\/p>\n

Figure 3 \u201cArrival\u201d of the training dataset to Azure ML<\/em><\/p>\n

With that, the main part of the sender business process is over, but we need to execute one more action keeping in mind that any computation resources that we create in Azure ML are billable (see the diagram, skip data consistency actions):<\/p>\n

<\/a><\/p>\n

Figure 4 Final part of the \u201csender\u201d business process<\/em><\/p>\n

(c) Resource Cleanup \u2013 triggers a call to Python interface to transfer it a set of Azure ML SDK for Python instructions to remove from Azure the computational infrastructure built in the previous action.<\/p>\n

The data required for the data scientist has been transmitted (the dataset is now in Azure), so we can proceed with launching the \u201cexternal\u201d business process that would access the dataset, run at least one alternative model training (algorithmically, an alternative model is distinct from the model running as part of the production-level solution), and return to the data scientist the resulting model quality metrics plus visualizations permitting to formulate \u201caudit findings\u201d about the company production-level solution functioning efficiency.<\/p>\n

Let us now take a look at the receiver business process: unlike its sender counterpart (runs among the other business processes comprising the autonomous AI\/ML solution at the company), it does not require a while-loop, but it contains instead a sequence of actions related to training of alternative models in Azure ML and in IntegratedML (the accelerator for use of auto-ML frameworks from within InterSystems IRIS), and extracting the training results into InterSystems IRIS (the platform is also considered installed locally at the data scientist\u2019s):<\/p>\n

<\/a><\/p>\n

Figure 5 \u201cReceiver\u201d business process<\/em><\/p>\n

(a) Import Python Modules \u2013 triggers a call to Python interface to transfer it a set of instructions to import Python modules that are required for further actions;<\/p>\n

(b) Set AUDITOR Parameters \u2013 triggers a call to Python interface to transfer it a set of instructions to assign default values to the variables required for further actions;<\/p>\n

(c) Audit with Azure ML \u2013 (we will be skipping any further reference to Python interface triggering) hands \u201caudit assignment\u201d to Azure ML;<\/p>\n

(d) Interpret Azure ML \u2013 gets the data transmitted to Azure ML by the sender business process, into the local Python session together with the \u201caudit\u201d results by Azure ML (also, creates a visualization of the \u201caudit\u201d results in the Python session);<\/p>\n

(e) Stream to IRIS \u2013 extracts the data transmitted to Azure ML by the sender business process, together with the \u201caudit\u201d results by Azure ML, from the local Python session into a business process variable in IRIS;<\/p>\n

(f) Populate IRIS \u2013 writes the data transmitted to Azure ML by the sender business process, together with the \u201caudit\u201d results by Azure ML, from the business process variable in IRIS to a table in IRIS;<\/p>\n

(g) Audit with IntegratedML \u2013 \u201caudits\u201d the data received from Azure ML, together with the \u201caudit\u201d results by Azure ML, written into IRIS in the previous action, using IntegratedML accelerator (in this particular case it handles H2O auto-ML framework);<\/p>\n

(h) Query to Python \u2013 transfers the data and the \u201caudit\u201d results by IntegratedML into the Python session;<\/p>\n

(i) Interpret IntegratedML \u2013 in the Python session, creates a visualization of the \u201caudit\u201d results by IntegratedML;<\/p>\n

(j) Resource Cleanup \u2013 deletes from Azure the computational infrastructure created in the previous actions.<\/p>\n

<\/a><\/p>\n

Figure 6 Visualization of Azure ML \u201caudit\u201d results<\/em><\/p>\n

<\/a><\/p>\n

Figure 7 Visualization of IntegratedML \u201caudit\u201d results<\/em><\/p>\n

How distributed AI is implemented in general on InterSystems IRIS platform<\/strong><\/p>\n

InterSystems IRIS platform distinguishes among three fundamental approaches to distributed AI implementation:<\/p>\n