InterSystems IRIS – en universel AI ML-platform i realtid

Forfatter: Sergey Lukyanchikov, ingeniørkonsulent hos InterSystems

Udfordringer ved AI/ML-beregninger i realtid

Lad os starte med eksempler fra Data Science-praksis hos InterSystems:

• Den 'belastede' kundeportal er tilsluttet et online anbefalingssystem. Der skal foretages en omstrukturering af kampagnerne i detailkæden (lad os sige, i stedet for en 'flad' række kampagner vil der nu anvendes en 'segment-taktik' matrix). Hvad sker der med anbefalingsmekanismerne? Hvad sker der med indlevering og opdatering af data til anbefalingsmekanismen (volumen af inddata er steget 25000 gange)? Hvad sker der med genereringen af anbefalinger (behovet for tusindfoldig reduktion af tærsklen for filtrering af anbefalingsregler på grund af den tusindfoldige stigning i deres antal og 'sortiment')?
• Der er et system til overvågning af sandsynligheden for udvikling af fejl i udstyrskomponenter. Overvågningssystemet er blevet tilsluttet et automatiseret kontrolsystem (ACS), der sender tusindvis af parametre fra produktionsprocessen hvert sekund. Hvad sker der med overvågningssystemet, som tidligere arbejdede med 'manuelle stikprøver' (kan det sikre overvågning af sandsynligheden hvert sekund)? Hvad vil der ske, hvis der i inddataene dukker en ny blok op med flere hundrede kolonner med målinger fra sensorer, der for nylig er blevet tilføjet til ACS (vil det kræve, og hvor længe skal overvågningssystemet stoppes for at inkludere data fra de nye sensorer i analysen)?
• Et komplekst AI/ML-system er blevet oprettet (anbefalende, overvågende, prognosering), der bruger resultaterne af hinandens arbejde. Hvor mange mandetimer kræves der månedligt for at tilpasse dette system til ændringer i inddataene? Hvad er den samlede 'nedsættelse' ved at støtte systemet til ledelsesmæssige beslutninger (hyppigheden af ny støtteinformation i forhold til hyppigheden af nye inddata)?

Sammenfattende disse og mange andre eksempler, vi er kommet frem til formuleringerne af de udfordringer, der opstår ved overgang til anvendelsen af maskinlærings- og kunstig intelligens-mekanismer i realtid:

• Er vi tilfredse med hastigheden af oprettelsen og tilpasningen (til de skiftende forhold) af AI/ML-udviklinger i vores virksomhed?
• Hvor godt understøtter de AI/ML-løsninger, vi bruger, virksomhedsledelse i realtid?
• Er de AI/ML-løsninger, vi bruger, i stand til autonomt (uden udviklere) at tilpasse sig ændringer i data og ledelsespraksis?

Vores artikel er en grundig gennemgang af mulighederne i InterSystems IRIS-platformen med hensyn til universel understøttelse af implementeringen af AI/ML-mekanismer, integrationen af AI/ML-løsninger og træningen (testningen) af AI/ML-løsninger på intensive datastreams. Vi vil se på markedsundersøgelser, praktiske eksempler på AI/ML-løsninger samt de konceptuelle aspekter, som vi i denne artikel kalder realtids AI/ML-platform.

Hvad er kendt fra undersøgelser: applikationer i realtid

Resultater en undersøgelse, foretaget blandt omkring 800 IT-professionelle i 2019 af Lightbend, taler for sig selv:

Figur 1: Ledende brugere af realtidsdata

Lad os citere vigtige segmenter af rapporten om resultaterne af denne undersøgelse i vores oversættelse:

«… Tendenserne for populariteten af værktøjer til integration af datastreams og samtidig støtte til beregninger i containere giver et synergisk svar på markedets efterspørgsel efter hurtigere, mere rationelle og dynamiske tilbud om effektive løsninger. Datastreams muliggør hurtigere transmission af information end traditionelle batchdata. Dertil kommer muligheden for hurtig anvendelse af beregningsmetoder, såsom AI/ML-baserede anbefalinger, hvilket skaber konkurrencefordele gennem øget tilfredshed blandt kunderne. Kapløbet om hastighed påvirker også alle roller i DevOps-paradigmet – hvilket øger effektiviteten i udviklingen og implementeringen af applikationer. … Åtte hundrede og fire IT-specialister gav oplysninger om brugen af datastreams i deres organisationer. Respondenterne var hovedsageligt fra vestlige lande (41 % i Europa og 37 % i Nordamerika) og var næsten jævnt fordelt mellem små, mellemstore og store virksomheder. …

Kunstig intelligens er ikke bare et buzzword. Femoghalvtreds procent af dem, der allerede anvender datastreaming i produktive AI/ML-applikationer, bekræfter, at deres anvendelse i AI/ML vil få den største vækst i det kommende år (sammenlignet med andre applikationer).

• Ifølge flertallet af de adspurgte vil anvendelsen af datastreaming i AI/ML-scenarier få den største vækst i det kommende år.
• Anvendelsen i AI/ML vil vokse ikke kun på grund af relativt nye typer scenarier, men også på grund af traditionelle scenarier, hvor realtidsdata anvendes mere og mere intensivt.
• Ud over AI/ML er entusiasmen blandt brugere af IoT-datapipelines imponerende — 48 % af dem, der allerede har integreret IoT-data, hævder, at implementeringen af scenarier baseret på disse data vil få en betydelig vækst i den nærmeste fremtid.

Denne interessante undersøgelse viser, at opfattelsen af maskinlærings- og kunstig intelligensscenarier som førende for datastreamingforbrug allerede er på vej. Men en ikke mindre vigtig observation er opfattelsen af AI/ML i realtid gennem DevOps’ optik: her kan man allerede begynde at tale om transformationen af den nuværende kultur med 'engangs-AI/ML med fuldt tilgængelige datasæt'.

Konceptet med en AI/ML-platform i realtid

Et af de typiske anvendelsesområder for AI/ML i realtid er styring af teknologiske processer i produktionen. På baggrund af dette eksempel og de tidligere overvejelser vil vi formulere konceptet for en AI/ML-platform i realtid.
Brugen af kunstig intelligens og maskinlæring i styring af teknologiske processer har en række særlige kendetegn:

• Data om tilstanden af den teknologiske proces strømmer ind med høj frekvens og et bredt spektre af parametre (op til titusinder af parametre, der sendes hvert sekund fra kontrolsystemet).
• Data om fejldetektion, for ikke at nævne data om deres udvikling, er derimod sparsomme og uregelmæssige, præget af utilstrækkelig kategorisering af fejl og deres tidsmæssige lokalisering (ofte præsenteret i papirform).
• Fra et praktisk synspunkt er der kun et "vinduet for relevans" af de oprindelige data til rådighed for træning og anvendelse af modeller, som afspejler dynamikken i den teknologiske proces over et rimeligt glidende interval, der slutter ved de seneste læste værdier af procesparametrene.

Disse særlige forhold får os til, udover modtagelse og grundlæggende behandling i realtid af det intensive "bredbåndsindstrømmende signal" fra den teknologiske proces, at udføre (parallelt) anvendelse, træning og kvalitetskontrol af resultaterne fra AI/ML-modellerne - også i realtid. Det "billede", som vores modeller "ser" i det glidende relevansvindue, ændrer sig konstant - og sammen med det ændrer kvaliteten af resultaterne fra AI/ML-modellerne, der er trænet på et af "billederne" i fortiden. Når kvaliteten af resultaterne fra AI/ML-modellerne forværres (for eksempel: klassifikationsfejlens værdi "alarm-norm" overstiger de grænser, vi har defineret), skal der automatisk startes en yderligere træning af modellerne på et mere relevant "billede" - og valget af tidspunkt for opstarten af den yderligere træning af modellerne skal tage hensyn til både varigheden af selve træningen og dynamikken i forværringen af kvaliteten af arbejdet fra den nuværende version af modellerne (da de nuværende versioner af modellerne fortsætter med at blive anvendt, mens modellerne trænes, og indtil deres "genuddannede" versioner er dannet).

InterSystems IRIS besidder nøgleplatformfunktioner til at sikre driften af AI/ML-løsninger ved styring af teknologiske processer i realtid. Disse funktioner kan opdeles i tre hovedgrupper:

• Kontinuerlig implementering (Continuous Deployment/Delivery, CD) af nye eller tilpassede eksisterende AI/ML-mekanismer i et produktionsløsning, der fungerer i realtid på InterSystems IRIS-platformen.
• Kontinuerlig integration (Continuous Integration, CI) af indstrømmende datastreams fra den teknologiske proces, datakøer til anvendelse/træning/kvalitetskontrol af AI/ML-mekanismer og data/code/control signals exchanges med matematiske modeleringsmiljøer, orchestrationen af hvilke sker i realtid på InterSystems IRIS-platformen.
• Kontinuerlig (selv-)læring (Continuous Training, CT) af AI/ML-mekanismer udført i matematiske modelleringsmiljøer, der bruger data, kode og styringsinput ("trufne beslutninger"), der overføres af InterSystems IRIS-platformen.

Klassificeringen af platformens muligheder i forhold til maskinlæring og kunstig intelligens er ikke tilfældig, men relateret til sådanne grupper. Lad os citere metodologien publicering fra Google, der danner den konceptuelle basis for denne klassificering, i vores oversættelse:

«… Den populære DevOps-koncept i dag dækker udviklingen og driften af store informationssystemer. Fordelene ved at implementere dette koncept inkluderer forkortelse af udviklingscykler, hurtigere udrulning af udviklinger og fleksibilitet i planlægning af udgivelser. For at opnå disse fordele kræver DevOps, at der implementeres mindst to praksisser:

• Continuous Integration (CI)
• Continuous Delivery (CD)

Disse praksisser er også anvendelige på AI/ML-platforme – med henblik på at sikre en pålidelig og effektiv opbygning af produktive AI/ML-løsninger.

AI/ML-platforme adskiller sig fra andre informationssystemer på følgende områder:

• Teamkompetencer: Når der skabes en AI/ML-løsning, inkluderer teamet normalt dataforskere eller eksperter "akademikere" inden for dataforskning, der udfører dataanalyse, udvikling og test af modeller. Disse teammedlemmer er muligvis ikke professionelle udviklere af produktiv kode.
• Udvikling: AI/ML-mekanismer er eksperimentelle af natur. For at løse en opgave mest effektivt kræves det at gennemgå forskellige kombinationer af inputvariabler, algoritmer, modelleringsmetoder og modelparametre. Kompleksiteten ved denne gennemgang ligger i sporing af "hvad der virkede/ikke virkede", sikring af reproducerbarhed af episoder og generalisering af udviklinger til gentagne implementeringer.
• Testning: Testning af AI/ML-mekanismer kræver et bredere udvalg af test end de fleste andre udviklinger. Udover standard modulære og integrationstests testes validiteten af data og kvaliteten af resultaterne af anvendelsen af modellen på trænings- og kontrolgrupper.
• Udrulning: Udrulning af AI/ML-løsninger handler ikke kun om prædiktive tjenester, der bruger en engangstrænet model. AI/ML-løsninger designes omkring flertrins pipelines, der udfører automatiseret træning og anvendelse af modeller. Udrulning af sådanne pipelines indebærer automatisering af ikke-trivielle handlinger, som traditionelt udføres manuelt af dataforskere for at kunne træne og teste modeller.
• Produktivitet: AI/ML-mekanismer kan mangle ydeevne ikke kun på grund af ineffektiv programmering, men også på grund af den konstant skiftende natur af de inddata, de arbejder med. Med andre ord kan ydeevnen af AI/ML-mekanismer degraderes af et bredere spektrum af årsager end ved almindelige udviklinger. Dette fører til nødvendigheden af at overvåge (i realtid) ydeevnen af vores AI/ML-mekanismer samt at sende advarsler eller forkaste resultater, hvis ydeevnen ikke lever op til forventningerne.

AI/ML-platforme er ligesom andre informationssystemer i den forstand, at begge kræver kontinuerlig integration af kode med versionskontrol, modulært testarbejde, integrationstest og kontinuerlig udrulning af udviklinger. Men i tilfælde af AI/ML er der flere vigtige forskelle:

• CI (Continuous Integration, kontinuerlig integration) er ikke længere begrænset til test og validering af koden i de udrulende komponenter - det omfatter også test og validering af data og AI/ML-modeller.
• CD (Continuous Delivery/Deployment, kontinuerlig udrulning) handler ikke kun om at skrive og frigive pakker eller tjenester, men indebærer en platform til komposition, træning og anvendelse af AI/ML-løsninger.
• CT (Continuous Training, kontinuerlig træning) - et nyt element [forfatterens note: et nyt element i forhold til den traditionelle DevOps-koncept, hvor CT typisk er Continuous Testing], som er karakteristisk for AI/ML-platforme, der er ansvarligt for autonom håndtering af mekanismerne til træning og anvendelse af AI/ML-modeller...

Vi kan konstatere, at maskinlæring og kunstig intelligens, der arbejder med realtidsdata, kræver et bredere udvalg af værktøjer og kompetencer (fra kodeudvikling til orkestrering af miljøer for matematisk modellering), en tættere integration mellem alle funktionelle og emnespecifikke områder, samt en mere effektiv organisering af menneskelige og maskinelle ressourcer.

Realtidsscenarie: genkendelse af defektudvikling i næringspumper

Når vi fortsætter med at bruge området for processtyring som eksempel, lad os se på en konkret opgave (som vi allerede har nævnt i starten): det er nødvendigt at sikre realtidsmonitorering af udviklingen af defekter i pumper baseret på strømmen af parameterværdier fra processtyringssystemet og reparationsteamets rapporter om identificerede defekter.

Figur 2 Formulering af opgaven for monitorering af defektudvikling

En af de vigtigste karakteristika ved de fleste af denne type opgaver i praksis er, at regelmæssigheden og hastigheden af dataindsamling (automatiseret processtyringssystem) skal betragtes i lyset af sporadisk og uregelmæssig forekomst (og registrering) af forskellige typer defekter. Med andre ord: data fra AP-systemet kommer korrekt i sekunder, mens defekter registreres med en kemisk blyant med datoen skrevet i en generel notesbog i værkstedet (f.eks.: "12.01 - lækage i kapslingen ved den 3. leje").

Dermed kan vi supplere formuleringen af opgaven med denne vigtige begrænsning: "mærket" for en specifik type defekt har vi kun ét (dvs. et eksempel på en defekt af en specifik type er repræsenteret af data fra AP-systemet på en konkret dato - og vi har ikke flere eksempler på netop den type defekt). Denne begrænsning bringer os straks uden for rammerne for klassisk maskinlæring (supervised learning), hvor "mærker" skal være mange.

Figur 3 Præcisering af opgaven for monitorering af defektudvikling

Kan vi på en eller anden måde "reproducere" den eneste "mærkat", vi har til rådighed? Ja, det kan vi. Pumpens nuværende tilstand karakteriseres af graden af lighed med de registrerede defekter. Selv uden kvantitative metoder kan vi, på niveauet for visuel opfattelse, allerede hente meget information ved at observere dynamikken i dataene, der kommer fra ASUTP.

Figur 4 Dynamik i pumpens tilstand i forhold til "mærket" for defekten af den angivne type

Men visuel opfattelse (i det mindste indtil videre) er ikke den mest passende generator af "mærker" i vores hurtigt skiftende scenarie. Vi vil vurdere ligheden mellem pumpens nuværende tilstand og de registrerede defekter ved hjælp af en statistisk test.

Figur 5 Anvendelse af den statistiske test på de modtagne data i forhold til "mærket" for defekten

Den statistiske test bestemmer sandsynligheden for, at optegnelser med værdier af parametrene for den teknologiske proces i den modtagne "strøm-pakke" fra ASUTP ligner optegnelserne for "mærket" for en bestemt type defekt. Den sandsynlighed, der beregnes ved anvendelse af den statistiske test (index for statistisk lighed), omdannes til en værdi mellem 0 og 1, som bliver et "mærke" for maskinlæring i hver konkret optegnelse i den undersøgte pakke. Det vil sige, efter behandling af den nyankomne pakke med optegnelser om pumpens tilstand med den statistiske test, får vi muligheden for (a) at tilføje denne pakke til træningsdatagruppen til træning af AI/ML-modellen og (b) at udføre kvalitetskontrol af den nuværende version af modellen, når den anvendes på denne pakke.

Figur 6 Anvendelse af maskinlæringsmodellen på de modtagne data i forhold til "mærket" for defekten

I et af vores tidligere webinarer Vi viser og forklarer, hvordan InterSystems IRIS-platformen muliggør implementeringen af enhver AI/ML-mekanisme som kontinuerligt kørende forretningsprocesser, der kontrollerer pålideligheden af simuleringens resultater og tilpasser modellernes parametre. Ved implementeringen af prototypen til vores scenarie med pumper bruger vi alle de funktioner, der blev præsenteret under webinaret i InterSystems IRIS - idet vi integrerer i procesanalysatoren i vores løsning ikke klassisk supervised learning, men snarere reinforcement learning, som automatisk styrer udvælgelsen til modellernes træning. I udvælgelsen til træningen placeres de poster, hvor der opstår en "konsensus detektion" efter anvendelse af både den statistiske test og den aktuelle modelversion - det vil sige, at både den statistiske test (efter transformationen af lighedsin dex til 0 eller 1) og modellen har givet resultater 1 for disse poster. Ved ny træning af modellen, ved dens validering (den genuddannede model anvendes på sin egen træningsdata, efter den statistiske test er anvendt), fjernes de poster, der ikke "beholdt" resultatet 1 efter behandlingen med den statistiske test (på grund af den konstante tilstedeværelse af poster fra den oprindelige "fejlmærkning") fra træningsdataene, og den nye version af modellen lærer på "fejlmærkningen" plus på de "beholdte" poster fra strømmen.

Figur 7 Robotisering af AI/ML-beregninger i InterSystems IRIS

I tilfælde af, at der er behov for en form for "anden mening" om kvaliteten af detektion, der opnås ved lokale beregninger i InterSystems IRIS, oprettes der en proces-rådgiver til at udføre træning og anvendelse af modeller på et kontrol-datasæt ved hjælp af cloud-tjenester (f.eks. Microsoft Azure, Amazon Web Services, Google Cloud Platform osv.):

Figur 8 "Anden mening" fra Microsoft Azure under orkestreringen af InterSystems IRIS

Prototypen til vores scenarie i InterSystems IRIS er udformet som et agentbaseret system af analytiske processer, der interagerer med udstyr (pumpen), matematiske modelleringsmiljøer (Python, R og Julia) og muliggør selv-læring af alle involverede AI/ML-mekanismer - på realtidsdata streams.

Figur 9 Hovedfunktionaliteten i AI/ML-løsningen til realtid i InterSystems IRIS

Den praktiske resultater af vores prototype:

• Den defekt, der blev registreret af modellen (12. januar):

• Den voksende defekt, der ikke var inkluderet i prøven, registreret af modellen (11. september; selve defekten blev konstateret af reparationsteamet først to dage senere – 13. september):

Imitationen på reale data, der indeholdt flere episoder af den samme defekt, viste, at vores løsning, implementeret på InterSystems IRIS-platformen, muliggør identifikation af udviklingen af defekter af denne type flere dage før reparationsteamet opdager dem.

InterSystems IRIS – en universel platform til AI/ML-beregninger i realtid

InterSystems IRIS-platformen forenkler udviklingen, implementeringen og driften af realtidsdata-løsninger. InterSystems IRIS kan samtidig udføre transaktions- og analytisk databehandling; understøtte synkroniserede datavisninger i overensstemmelse med flere modeller (herunder relationelle, hierarkiske, objektorienterede og dokumentære); fungere som en integrationsplatform for et bredt spektrum af datakilder og individuelle applikationer; og levere avanceret realtidsanalyse på strukturerede og ustrukturerede data. InterSystems IRIS giver også mekanismer til at anvende eksterne analytiske værktøjer og muliggør fleksibel kombination af cloud- og lokal serverplacering.

Applikationer bygget på InterSystems IRIS-platformen er implementeret i forskellige brancher og hjælper virksomheder med at opnå betydelige økonomiske fordele både strategisk og operationelt, forbedre beslutningstagningens informationsniveau og eliminere 'huller' mellem hændelse, analyse og handling.

Figur 10 InterSystems IRIS-arkitektur i kontekst af AI/ML i realtid

Som den tidligere diagram viser nedenstående diagram en ny 'koordinatsystem' (CD/CI/CT) sammen med informationsstrømmene mellem arbejdsmodulerne på platformen. Visualiseringen starter med makromekanismen CD og fortsætter med makromekanismerne CI og CT.

Figur 11 Diagram over informationsstrømme mellem AI/ML-elementerne på InterSystems IRIS-platformen

Kernen i CD-mekanismen i InterSystems IRIS: platformens brugere (udviklere af AI/ML-løsninger) tilpasser eksisterende og/eller skaber nye AI/ML-udviklinger ved hjælp af en specialiseret kodeeditor til AI/ML-mekanismer: Jupyter (det fulde navn: Jupyter Notebook; for korthedens skyld kaldes dokumenterne, der er blevet oprettet i denne editor, også nogle gange blot dokumenter). I Jupyter har udvikleren mulighed for at skrive, debugge og sikre sig, at en bestemt AI/ML-udvikling fungerer (herunder ved brug af grafik) før den implementeres (“udrulles”) i InterSystems IRIS. Det er forståeligt, at den nyudviklede applikation kun vil få grundlæggende fejlfinding (da Jupyter eksempelvis ikke arbejder med realtidsdatastrømme) – dette er helt normalt, da det vigtigste resultat af udviklingen i Jupyter bliver at bekræfte den principielle funktionsdygtighed af den enkelte AI/ML-mekanisme (“viser det forventede resultat på dataprøver”). På lignende måde kan en allerede placeret mekanisme i platformen (se de næste makromekanismer) før debugging i Jupyter kræve et “rollback” til en “præ-platform” version (læse data fra filer, arbejde med data via xDBC i stedet for tabeller, direkte interaktion med globale variabler – multidimensionale datamasser i InterSystems IRIS – osv.).

Et vigtigt aspekt ved implementeringen af CD specifikt i InterSystems IRIS: der er etableret en tovejsintegration mellem platformen og Jupyter, som muliggør overførsel til platformen (og senere behandling i platformen) af indhold på Python, R og Julia (alle tre er programmeringssprog i de førende open-source miljøer til matematisk modellering). Dermed har udviklere af AI/ML-indhold mulighed for at udføre “kontinuerlig implementering” af dette indhold i platformen, arbejde i deres kendte editor Jupyter med de kendte biblioteker tilgængelige i Python, R, Julia, og udføre grundlæggende debugging (om nødvendigt) udenfor platformen.

Lad os gå videre til makromekanismen for CI i InterSystems IRIS. Diagrammet viser makroprocessen for arbejdet med "real-time robotik" (et kompleks af datakonstruktioner, forretningsprocesser og de kodedele, som orkestreres, skrevet i matematikmiljøer og ObjectScript - det native udviklingssprog for InterSystems IRIS). Formålet med denne makroproces er at understøtte de nødvendige datakøer til drift af AI/ML-mekanismer (baseret på data streams, der transmitteres til platformen i realtid), træffe beslutninger om rækkefølgen af anvendelse og "udvalget" af AI/ML-mekanismer (de kan kaldes "matematiske algoritmer", "modeller" osv. - alt efter den specifikke implementering og terminologiske præferencer), og holde datakonstruktionerne ajour til analyse af resultaterne fra AI/ML-mekanismerne (cuber, tabeller, multidimensionale datasæt osv. - til rapporter, dashboards osv.).

Et vigtigt aspekt ved implementeringen af CI specifikt i InterSystems IRIS er den bidirektionale integration mellem platformen og matematiske modelleringsmiljøer, som muliggør udførelse af indhold placeret på platformen på sprog som Python, R og Julia i deres respektive miljøer med modtagelse af resultater tilbage. Denne integration realiseres både i "terminaltilstand" (dvs. AI/ML-indhold formuleres som kode i ObjectScript, der kalder matematikmiljøer) og i "forretningsproces-tilstand" (dvs. AI/ML-indhold formuleres som en forretningsproces ved hjælp af en grafisk editor, eller nogle gange ved hjælp af Jupyter, eller ved hjælp af IDE'er – IRIS Studio, Eclipse, Visual Studio Code). Tilgængeligheden af forretningsprocesser til redigering i Jupyter afspejles gennem forbindelsen mellem IRIS på CI-niveauet og Jupyter på CD-niveauet. En mere detaljeret gennemgang af integrationen med matematiske modelleringsmiljøer vil blive præsenteret senere. På dette stadium mener vi, at der er god grund til at fastslå, at platformen indeholder alle nødvendige værktøjer til implementering af "continous integration" for AI/ML-udviklinger (der stammer fra "continous deployment") i AI/ML-løsninger i realtid.

Og den centrale makromekanisme: CT. Uden den kan AI/ML-platforme ikke fungere (selv om "real-time" vil blive implementeret gennem CD/CI). Essensen af CT er platformens arbejde med "artefakter" fra maskinlæring og kunstig intelligens direkte i arbejds-sessioner inden for matematiske modelleringsmiljøer: modeller, fordelings-tabeller, vektorer-matricer, lag af neurale netværk osv. Dette "arbejde" består i de fleste tilfælde i at skabe de nævnte artefakter i disse miljøer (i tilfælde af modeller, for eksempel består "skabelsen" af at definere modelspecifikationer og derefter finde værdier for dens parametre - den såkaldte "træning" af modellen), deres anvendelse (for modeller: beregning af "model"-værdier af de målvariabler - forudsigelser, tilhørsforhold til en kategori, sandsynligheden for en hændelse osv.) og forbedring af allerede skabte og anvendte artefakter (for eksempel omdefinering af sæt af inddata til modellen baseret på anvendelsens resultater - med det formål at øge forudsigelsesnøjagtigheden, som en mulighed). Et centralt punkt i forståelsen af CT's rolle er dens "abstraktion" fra realiteterne omkring CD og CI: CT vil implementere alle artefakter med fokus på den beregnings- og matematiske specifik for AI/ML-løsningen inden for rammerne af de muligheder, der tilbydes af de specifikke miljøer. Ansvarligheden for "forsyning af inddata" og "levering af resultater" vil hvile på CD og CI.

En vigtig aspekt ved implementeringen af CT specifikt i InterSystems IRIS: ved at benytte den tidligere nævnte integration med miljøer til matematisk modellering, har platformen mulighed for at udtrække de relevante artefakter fra arbejdssessioner, der kører under dens kontrol i matematiske miljøer, og (vigtigst af alt) omdanne dem til platformens dat objekter. For eksempel kan en distributions tabel, der lige er blevet oprettet i en arbejdssession i Python, overføres til platformen i form af et globalt array (multidimensionelt dataarray i InterSystems IRIS) – uden at stoppe Python-sessionen – og bruges til beregninger i et andet AI/ML-mekanisme (implementeret i et andet sprog – for eksempel R) – eller en virtuel tabel. Et andet eksempel: parallelt med den

Lad os tage et mere detaljeret kig på platformens AI/ML-funktionalitet i InterSystems IRIS, ved at se på et reelt eksisterende prototype.

I diagrammet nedenfor, til venstre på slide, vises en del af forretningsprocessen, der implementerer udførelsen af scripts i Python og R. I midten er de visuelle logs for udførelsen af nogle af disse scripts, henholdsvis i Python og R. Lige efter dem er der eksempler på indhold på begge sprog, der er sendt til udførelse i de respektive miljøer. Til højre i bunden er visualiseringer baseret på resultaterne af scriptudførelserne. Visualiseringerne øverst er lavet i IRIS Analytics (data trækkes fra Python ind i InterSystems IRIS dataplatform og vises på dashboardet ved hjælp af platformens værktøjer), og de nederste er lavet direkte i R arbejds-sessionen og gemt som grafiske filer. En vigtig aspekt: det præsenterede fragment i prototypen er ansvarligt for træningen af modellen (klassificering af udstyrstilstande) ved hjælp af data, der strømmer i realtid fra udstyrsimulatorprocessen, baseret på kommandoen fra kvalitetsmonitoreringsprocessen, observeret under anvendelsen af modellen. Implementeringen af AI/ML-løsningen i form af et sæt interagerende processer ('agenter') vil blive diskuteret senere.

Figur 12 Interaktion med Python, R og Julia i InterSystems IRIS

Platformprocesser (også kaldet 'forretningsprocesser', 'analytiske processer', 'pipelines' osv. – afhængigt af konteksten) kan primært redigeres i den grafiske editor for forretningsprocesser i platformen, på en måde der samtidigt skaber både diagrammet og den tilhørende AI/ML-mekanisme (programkode). Når vi taler om, at 'der opnås en AI/ML-mekanisme', henviser vi til hybridity (inden for den samme proces): indhold på matematiske modelleringssprog sameksisterer med indhold på SQL (inklusive udvidelser fra IntegratedML), i InterSystems ObjectScript, med andre understøttede sprog. Desuden giver platformprocessen meget brede muligheder for 'tegning' i form af hierarkisk indlejrede fragmenter (som vist i eksemplet i nedenstående diagram), hvilket giver mulighed for effektiv organisering af selv meget komplekst indhold, uden at det 'falder ud' af det grafiske format (i 'ikke-grafiske' metoder / klasser / procedurer osv.). Det vil sige, at hvis nødvendigt (og det ses i de fleste projekter) kan hele AI / ML-løsningen implementeres i et grafisk selv-dokumenterende format. Vi bemærker, at i den centrale del af nedenstående diagram, hvor et højere 'niveau af indlejring' præsenteres, er det klart, at ud over selve arbejdet med at træne modellen (ved hjælp af Python og R) tilføjes analysen af den såkaldte ROC-kurve for den trænede model, hvilket gør det muligt at evaluere kvaliteten af træningen visuelt (og også beregningsmæssigt) – og denne analyse er implementeret i Julia (køres således i Julia-miljøet).

Figur 13 Visuel miljø til komposition af AI / ML-løsninger i InterSystems IRIS

Som nævnt tidligere, vil den indledende udvikling og (i visse tilfælde) tilpasning af allerede implementerede AI / ML-mekanismer på platformen blive / kan blive udført uden for platformen i Jupyter-editoren. I diagrammet nedenfor ser vi et eksempel på tilpasning af den eksisterende platformproces (den samme som ovenfor) – dette er, hvordan den del, der håndterer modeltræningen, ser ud i Jupyter. Indholdet er tilgængeligt på Python-sproget til redigering, debug og udskrift af grafik direkte i Jupyter. Ændringer (om nødvendigt) kan foretages med øjeblikkelig synkronisering til platformprocessen, inklusive dens produktionsversion. På samme måde kan nyt indhold overføres til platformen (et nyt platformproces genereres automatisk).

Figur 14 Anvendelse af Jupyter Notebook til redigering af AI / ML-mekanisme i platformen InterSystems IRIS

Tilpasning af platformens proces kan udføres ikke kun i grafisk eller bærbar format – men også i et "total" IDE-format (Integrated Development Environment). De IDE'er, der fungerer som sådanne, er IRIS Studio (den native IRIS-studio), Visual Studio Code (InterSystems IRIS-udvidelse til VSCode) og Eclipse (Atelier-plugin). I visse tilfælde er det muligt for udviklerteamet at bruge alle tre IDE'er samtidigt. Diagrammet nedenfor viser et eksempel på redigering af den samme proces i IRIS-studio, Visual Studio Code og Eclipse. Alt indhold er tilgængeligt til redigering: både Python/R/Julia/SQL, ObjectScript og forretningsprocessen.

Figur 15 Udvikling af InterSystems IRIS forretningsproces i forskellige IDE'er

Det er værd at nævne de værktøjer til beskrivelse og udførelse af InterSystems IRIS forretningsprocesser på Business Process Language (BPL). BPL gør det muligt at anvende "færdige integrationskomponenter" (aktiviteter) i forretningsprocesserne – hvilket faktisk giver fuld grund til at påstå, at der er implementeret "kontinuerlig integration" i InterSystems IRIS. Færdige komponenter i forretningsprocessen (aktiviteter og forbindelser mellem dem) fungerer som en kraftfuld accelerator for opbygningen af AI/ML-løsninger. Og ikke kun til opbygning: Takket være aktiviteterne og forbindelserne mellem dem opstår der et "autonomt ledelseslag" over adskilte AI/ML-udviklinger og mekanismer, som er i stand til at træffe beslutninger i henhold til situationen, i realtid.

Figur 16 Færdige komponenter til forretningsprocesser for kontinuerlig integration (CI) på InterSystems IRIS platformen

Konceptet om agent systemer (også kaldet "multi-agent systemer") har stærke positioner inden for robotisering, og InterSystems IRIS platformen understøtter det organisk gennem konstruktionen "produkt-proces". Udover de ubegrænsede muligheder for at "fylde" hver proces med den nødvendige funktionalitet for den samlede løsning, gør det at give systemet forretningsprocesser egenskaben "agentur" det muligt at skabe effektive løsninger for yderst ustabile modellerede fænomener (adfærd af sociale/biologiske systemer, delvist observerbare teknologiske processer osv.).

Figur 16 Drift af AI/ML-løsning som et agent system af forretningsprocesser i InterSystems IRIS

Vi fortsætter vores gennemgang af InterSystems IRIS med en beskrivelse af, hvordan platformen anvendes til at løse hele klasser af realtidsopgaver (en ret detaljeret introduktion til nogle af de bedste praksisser for platformbaseret AI/ML på InterSystems IRIS finder sted i et af vores tidligere indlæg). webinarer).

I kølvandet på det forrige diagram er her et mere detaljeret diagram over agentsystemet. Diagrammet viser den samme prototype, og alle fire agentprocesser er skematisk viser forholdet mellem dem: GENERATOR – håndterer oprettelsen af data fra udstyrsensorer, BUFFER – styrer data-køerne, ANALYZER – udfører selve maskinlæring, MONITOR – overvåger kvaliteten af maskinlæring og signalerer behovet for genuddannelse af modellen.

Figur 17 Kompositionen af AI/ML-løsningen i form af et agentsystem af forretningsprocesser i InterSystems IRIS.

Diagrammet nedenfor illustrerer den autonome funktion af en anden robotprototype (genkendelse af følelsesmæssig tone i tekster) i en periode. I toppen – udviklingen af læringskvalitetsmålingen (kvaliteten stiger), i bunden – dynamikken i anvendelseskvalitetsmålingen og fakta om genuddannelse (røde striber). Som det fremgår, har løsningen effektivt og autonomt lært, og den fungerer på det krævede kvalitetsniveau (kvalitetsværdierne falder ikke under 80%).

Figur 18 Kontinuerlig (selv-)læring (CT) på InterSystems IRIS-platformen.

Vi har også nævnt "auto-ML" tidligere, men i diagrammet nedenfor vises anvendelsen af denne funktionalitet detaljeret ved hjælp af endnu et prototypeeksempel. Den grafiske skitse af forretningsprocessen viser aktiviteten, der initierer modelleringen i H2O-stakken, samt resultaterne af denne modellering (den tydelige dominans af den opnåede model over de "håndlavede" modeller ifølge den sammenlignende diagram af ROC-kurver, samt automatiseret identificering af de "mest indflydelsesrige variabler" fra de tilgængelige data i det oprindelige datasæt). Et vigtigt punkt her er den tid og ekspertise, der spares ved brug af "auto-ML": det, som vores platformproces gør på et halvt minut (finde og træne den optimale model), kan tage en ekspert fra en uge til en måned.

Figur 19 Integration af "auto-ML" i AI/ML-løsningen på InterSystems IRIS-platformen

Diagrammet nedenfor ”slipper lidt af spændingen”, men det er en god måde at afslutte fortællingen om klasser af realtidsopgaver: vi minder om, at på trods af alle mulighederne på InterSystems IRIS-platformen, er det ikke obligatorisk at træne modeller under dens kontrol. Platformen kan modtage en såkaldt PMML-specifikation af en model, der er trænet i et værktøj, der ikke er under platformens kontrol – og anvende denne model i realtid fra det øjeblik den importeres. PMML-specifikationer. Det er vigtigt at bemærke, at langt fra alle AI/ML-artefakter kan reduceres til en PMML-specifikation, selvom de fleste af de mest udbredte artefakter kan gøre dette. På den måde har InterSystems IRIS-platformen en "åben ramme" og betyder ikke "platformslaveri" for brugerne.

Figur 20 Integration af "auto-ML" i AI/ML-løsningen på InterSystems IRIS-platformen

Lad os opliste de ekstra platformfordele ved InterSystems IRIS (for tydelighedens skyld, i forhold til styring af teknologiske processer), som er vigtige ved automatisering af kunstig intelligens og realtids maskinlæring:

• Avancerede integrationsmidler med enhver datakilde og -modtager (ACS/SCADA, udstyr, vedligeholdelse, ERP osv.)
• Indbygget multimodal DBMS til højtydende hybrid transaktions-/analytisk behandling (Hybrid Transaction/Analytical Processing, HTAP) af enhver datamængde fra teknologiske processer
• Udviklingsværktøjer til kontinuerlig implementering af AI/ML-mekanismer til realtidsløsninger baseret på Python, R, Julia
• Adaptive forretningsprocesser til kontinuerlig integration og (selv-)læring af AI/ML-løsninger i realtid
• Indbyggede Business Intelligence-værktøjer til visualisering af data fra teknologiske processer og resultaterne fra AI/ML-løsningen
• API-styring til levering af resultaterne fra AI/ML-løsningen til SCADA/ASUTP, informations- og analyssystemer, udsendelse af notifikationer osv.

AI/ML-løsninger på InterSystems IRIS-platformen integreres nemt i eksisterende IT-infrastruktur. InterSystems IRIS-platformen sikrer høj pålidelighed af AI/ML-løsninger ved at støtte fejltolerante og katastrofesikre konfigurationer samt fleksibel implementering i virtuelle miljøer, på fysiske servere, i private og offentlige skyer samt Docker-containere.

Dermed er InterSystems IRIS en alsidig platform for realtids AI/ML-beregninger. Platformens alsidighed bekræftes praktisk ved fraværet af de facto begrænsninger i kompleksiteten af implementerede beregninger, samt InterSystems IRIS's evne til at kombinere (i realtid) behandlingen af scenarier fra de mest forskellige brancher og den exceptionelle tilpasningsevne af platformens funktioner og mekanismer til specifikke brugerbehov.

Figur 21 InterSystems IRIS — alsidig platform for realtids AI/ML-beregninger

For mere konkret interaktion med dem af vores læsere, der er interesserede i det præsenterede materiale, anbefaler vi ikke kun at begrænse sig til at læse det, men også at fortsætte dialogen "i live". Vi er udsat for at yde støtte i formuleringen af AI/ML realtids scenerier, tilpasset din virksomheds specifikheder, udføre fælles prototyping på InterSystems IRIS-platformen, udvikle og implementere en praktisk køreplan for implementering af kunstig intelligens og maskinlæring i dine produktions- og ledelsesprocesser. Kontaktadresse for vores AI/ML ekspertgruppe – MLToolkit@intersystems.com.

Kilde: habr.com