InterSystems IRIS er en universel AI/ML-platform i realtid

Forfatter: Sergey Lukyanchikov, rådgivende ingeniør hos InterSystems

Real-time AI/ML computing opkald

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

• Den indlæste køberportal er forbundet med et online anbefalingssystem. Der vil være en omstrukturering af kampagner på tværs af detailnetværket (for eksempel vil der nu blive brugt en "segment-taktik"-matrix i stedet for en "flad" linje af kampagner). Hvad sker der med anbefalingsmotorer? Hvad sker der med indsendelse og opdatering af data til anbefalingsmotoren (mængden af ​​inputdata er steget med 25000 gange)? Hvad sker der med udviklingen af ​​anbefalinger (behovet for at reducere filtreringstærsklen for anbefalingsregler med tusind gange på grund af en tusind gange stigning i deres antal og "rækkevidde")?
• Der er et system til overvågning af sandsynligheden for, at der opstår fejl i udstyrskomponenter. Et automatiseret proceskontrolsystem blev forbundet til overvågningssystemet, der transmitterede tusindvis af teknologiske procesparametre hvert sekund. Hvad sker der med overvågningssystemet, der tidligere arbejdede på "manuelle prøver" (er det i stand til at give sekund for sekund sandsynlighedsovervågning)? Hvad vil der ske, hvis en ny blok på flere hundrede kolonner vises i inputdataene med aflæsninger fra sensorer, der for nylig er tilføjet processtyringssystemet (vil det være nødvendigt og hvor længe skal man stoppe overvågningssystemet for at inkludere data fra nye sensorer i analysen )?
• Der er skabt et sæt AI/ML-mekanismer (anbefaling, overvågning, prognoser), der bruger resultaterne af hinandens arbejde. Hvor mange mandetimer kræves der hver måned for at tilpasse driften af ​​dette kompleks til ændringer i inputdata? Hvad er den generelle "opbremsning", når den understøttes af ledelsens beslutningskompleks (hyppigheden af ​​forekomsten af ​​ny understøttende information i den i forhold til hyppigheden af ​​forekomsten af ​​nye inputdata)?

Sammenfattende disse og mange andre eksempler er vi nået til formuleringen af ​​de udfordringer, der opstår, når vi går over til brugen af ​​maskinlæring og kunstig intelligens-mekanismer i realtid:

• Er vi tilfredse med hastigheden af ​​skabelse og tilpasning (til den skiftende situation) af AI/ML-udviklinger i vores virksomhed?
• Hvor meget understøtter de AI/ML-løsninger, vi bruger, forretningsstyring i realtid?
• Er de AI/ML-løsninger, vi bruger, i stand til selvstændigt (uden udviklere) at tilpasse sig ændringer i data og forretningsledelsespraksis?

Vores artikel er et grundigt overblik over mulighederne i InterSystems IRIS-platformen med hensyn til universel support til udrulning af AI/ML-mekanismer, samling (integration) af AI/ML-løsninger og træning (testning) af AI/ML-løsninger på intensive datastrømme. Vi vil se på markedsundersøgelser, casestudier af AI/ML-løsninger og konceptuelle aspekter af det, vi kalder en real-time AI/ML-platform i denne artikel.

Hvad vi ved fra undersøgelser: realtidsapplikationer

Fund undersøgelseudført blandt næsten 800 it-professionelle i 2019 af Lightbend, taler for sig selv:

Figur 1 Førende forbrugere af realtidsdata

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

"... Tendenser i populariteten af ​​værktøjer til at integrere datastrømme og samtidig understøtte computing i containere giver et synergistisk svar på markedets anmodning om et mere lydhørt, rationelt, dynamisk forslag til effektive løsninger. Streaming af data overfører information hurtigere end traditionelle pakkedata. Hertil kommer muligheden for hurtigt at anvende beregningsmetoder, såsom for eksempel AI/ML-baserede anbefalinger, hvilket skaber konkurrencefordele gennem øget kundetilfredshed. Kapløbet om smidighed påvirker også alle roller i DevOps-paradigmet - hvilket gør applikationsudvikling og -implementering mere effektiv. … Otte hundrede og fire it-professionelle gav information om brugen af ​​datastrømme i deres organisationer. Respondenterne var overvejende placeret i vestlige lande (41 % i Europa og 37 % i Nordamerika) og var næsten ligeligt fordelt mellem små, mellemstore og store virksomheder. ...

... Kunstig intelligens er ikke hype. XNUMX procent af dem, der allerede bruger datastrømsbehandling i produktivitets-AI/ML-applikationer bekræfter, at deres brug af AI/ML vil opleve den største vækst i det næste år (sammenlignet med andre applikationer).

• Ifølge flertallet af respondenterne vil brugen af ​​datastrømme i AI/ML-scenarier opleve den største vækst i det næste år.
• Applikationer i AI/ML vil vokse ikke kun på grund af relativt nye typer scenarier, men også på grund af traditionelle scenarier, hvor realtidsdata i stigende grad bruges.
• Ud over AI/ML er niveauet af entusiasme blandt brugere af IoT-datapipelines imponerende - 48% af dem, der allerede har integreret IoT-data, siger, at scenarieimplementering på disse data vil se en betydelig stigning i den nærmeste fremtid. ..."

Fra denne ret interessante undersøgelse er det klart, at opfattelsen af ​​scenarier for maskinlæring og kunstig intelligens som ledere i forbruget af datastrømme allerede er "på vej." Men en lige så vigtig observation er opfattelsen af ​​real-time AI/ML gennem linsen af ​​DevOps: her kan vi allerede begynde at tale om transformationen af ​​den stadig dominerende kultur af "engangs-AI/ML med et fuldt tilgængeligt datasæt."

Real-time AI/ML platform koncept

Et typisk anvendelsesområde for AI/ML i realtid er processtyring i fremstillingen. Ved at bruge hendes eksempel og tage højde for tidligere tanker, vil vi formulere konceptet med en real-time AI/ML platform.
Brugen af ​​kunstig intelligens og maskinlæring i processtyring har en række funktioner:

• Data om tilstanden af ​​den teknologiske proces modtages intensivt: med høj frekvens og for en bred vifte af parametre (op til titusindvis af parameterværdier transmitteret pr. sekund fra processtyringssystemet)
• Data om identifikation af defekter, for ikke at nævne data om deres udvikling, tværtimod, er sparsomme og uregelmæssige, karakteriseret ved utilstrækkelig typificering af defekter og deres lokalisering i tid (ofte repræsenteret ved papirregistreringer)
• Fra et praktisk synspunkt er kun et "relevansvindue" af kildedataene tilgængeligt til træning og anvendelse af modeller, der afspejler dynamikken i den teknologiske proces over et rimeligt glidende interval, der slutter med de sidste læste værdier af procesparametrene

Disse funktioner tvinger os, udover at modtage og grundlæggende behandling i realtid af det intensive "bredbåndsinputsignal" fra den teknologiske proces, til at udføre (parallelt) applikationen, træningen og kvalitetskontrollen af ​​resultaterne af AI/ ML-modeller - også i realtid. Den "ramme", som vores modeller "ser" i det glidende vindue af relevans, ændrer sig konstant - og med den ændres kvaliteten af ​​resultaterne af arbejdet med AI/ML-modeller, der er trænet på en af ​​"frames" tidligere. . Hvis kvaliteten af ​​resultaterne af arbejdet med AI/ML-modeller forringes (f.eks.: værdien af ​​"alarm-norm"-klassifikationsfejlen er gået ud over de grænser, vi har defineret), bør yderligere træning af modellerne automatisk lanceres på en mere aktuel "ramme" - og valget af tidspunkt for at lancere yderligere træning af modellerne bør tage højde for, hvordan varigheden af ​​selve træningen og dynamikken i forringelsen af ​​kvaliteten af ​​arbejdet i den nuværende version af modellerne (siden de nuværende versioner af modellerne fortsætter med at blive brugt, mens modellerne trænes, og indtil deres "nytrænede" versioner er dannet).

InterSystems IRIS har nøgleplatformskapaciteter til at muliggøre AI/ML-løsninger til processtyring i realtid. Disse kapaciteter kan opdeles i tre hovedgrupper:

• Kontinuerlig implementering (Continuous Deployment/Delivery, CD) af nye eller tilpassede eksisterende AI/ML-mekanismer til en produktiv løsning, der fungerer i realtid på InterSystems IRIS-platformen
• Kontinuerlig integration (CI) i en enkelt produktiv løsning af indkommende teknologiske procesdatastrømme, datakøer til applikation/træning/kvalitetskontrol af AI/ML-mekanismer og udveksling af data/kode/kontrolhandlinger med matematiske modelleringsmiljøer, orkestreret i realtid platform InterSystems IRIS
• Kontinuerlig (selv)træning (Continuous Training, CT) af AI/ML-mekanismer, udført i matematiske modelleringsmiljøer ved hjælp af data, kode og kontrolhandlinger ("beslutninger truffet") transmitteret af InterSystems IRIS-platformen

Klassificeringen af ​​platformskapaciteter i forhold til maskinlæring og kunstig intelligens i netop disse grupper er ikke tilfældig. Lad os citere det metodiske offentliggørelse Google, som giver et konceptuelt grundlag for denne klassificering, i vores oversættelse:

“... DevOps-konceptet, der er populært i disse dage, dækker udvikling og drift af store informationssystemer. Fordelene ved at implementere dette koncept er en reduktion i varigheden af ​​udviklingscyklusser, hurtigere implementering af udviklinger og fleksibilitet i udgivelsesplanlægning. For at opnå disse fordele involverer DevOps implementering af mindst to praksisser:

• Kontinuerlig integration (CI)
• Kontinuerlig levering (CD)

Denne praksis gælder også for AI/ML-platforme for at sikre pålidelig og effektiv samling af produktive AI/ML-løsninger.

AI/ML-platforme adskiller sig fra andre informationssystemer i følgende aspekter:

• Teamkompetencer: Når man laver en AI/ML-løsning, omfatter teamet normalt dataforskere eller "akademiske" eksperter inden for dataforskning, som udfører dataanalyse, udvikler og tester modeller. Disse teammedlemmer er muligvis ikke professionelle produktive kodeudviklere.
• Udvikling: AI/ML-motorer er af eksperimentelle natur. For at løse et problem på den mest effektive måde er det nødvendigt at gennemgå forskellige kombinationer af inputvariabler, algoritmer, modelleringsmetoder og modelparametre. Kompleksiteten af ​​en sådan søgning ligger i at spore "hvad der virkede/ikke virkede", at sikre reproducerbarhed af episoder, generalisering af udviklinger for gentagne implementeringer.
• Test: Test af AI/ML-motorer kræver en bredere række af test end de fleste andre udviklinger. Ud over standardenheds- og integrationstests testes datavaliditet og kvaliteten af ​​resultaterne ved at anvende modellen til trænings- og kontrolprøver.
• Implementering: Implementering af AI/ML-løsninger er ikke begrænset til prædiktive tjenester, der bruger en én gang trænet model. AI/ML-løsninger er bygget op omkring flertrinsrørledninger, der udfører automatiseret modeltræning og -applikation. Udrulning af sådanne pipelines involverer automatisering af ikke-trivielle handlinger, der traditionelt udføres manuelt af dataforskere for at kunne træne og teste modeller.
• Produktivitet: AI/ML-motorer kan mangle produktivitet, ikke kun på grund af ineffektiv programmering, men også på grund af den konstant skiftende karakter af inputdata. Med andre ord kan ydeevnen af ​​AI/ML-mekanismer forringes på grund af en bredere vifte af årsager end ydeevnen af ​​konventionel udvikling. Hvilket fører til behovet for at overvåge (online) ydeevnen af ​​vores AI/ML-motorer, samt sende advarsler eller afvise resultater, hvis præstationsindikatorer ikke lever op til forventningerne.

AI/ML-platforme ligner andre informationssystemer, idet begge kræver kontinuerlig kodeintegration med versionskontrol, enhedstest, integrationstest og kontinuerlig udviklingsimplementering. Men i tilfælde af AI/ML er der flere vigtige forskelle:

• CI (Continuous Integration) er ikke længere begrænset til at teste og validere koden for implementerede komponenter - det inkluderer også test og validering af data og AI/ML-modeller.
• CD (Continuous Delivery/Deployment, continuous deployment) er ikke begrænset til at skrive og frigive pakker eller tjenester, men indebærer en platform for sammensætning, træning og anvendelse af AI/ML-løsninger.
• CT (Continuous Training, continuous training) er et nyt element [ca. artiklens forfatter: et nyt element i forhold til det traditionelle koncept for DevOps, hvor CT som regel er Continuous Testing], iboende i AI/ML platforme, ansvarlig for den autonome styring 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 sæt værktøjer og kompetencer (fra kodeudvikling til orkestrering af matematiske modelleringsmiljøer), tættere integration mellem alle funktions- og fagområder, mere effektiv organisering af menneskelige og maskinressourcer.

Realtidsscenarie: genkendelse af udviklingen af ​​defekter i fødepumper

Fortsæt med at bruge proceskontrolområdet som et eksempel, overvej et specifikt problem (vi nævnte allerede i begyndelsen): vi er nødt til at levere realtidsovervågning af udviklingen af ​​defekter i pumper baseret på flowet af procesparameterværdier og rapporter fra reparationspersonale om identificerede defekter.

Figur 2 Problemformulering til overvågning af udviklingen af ​​defekter

Et kendetegn ved de fleste opgaver, der stilles på denne måde i praksis, er, at regelmæssigheden og effektiviteten af ​​datamodtagelse (APCS) skal ses på baggrund af den episodiske og uregelmæssige forekomst (og registrering) af defekter af forskellige typer. Med andre ord: data fra processtyringssystemet ankommer én gang i sekundet, korrekte og nøjagtige, og noter om defekter laves med en kemikalieblyant, der angiver datoen i en generel notesbog på værkstedet (f.eks.: "12.01 – læk i omslaget" fra siden af ​​det 3. leje").

Vi kan således supplere formuleringen af ​​problemet med følgende vigtige begrænsning: vi har kun én "label" af en defekt af en bestemt type (dvs. et eksempel på en defekt af en bestemt type er repræsenteret af data fra processtyringen system på en bestemt dato - og vi har ikke flere eksempler på en defekt af netop denne type). Denne begrænsning bringer os straks ud over omfanget af klassisk maskinlæring (overvåget læring), som der burde være en masse "tags" for.

Figur 3 Afklaring af opgaven med at overvåge udviklingen af ​​defekter

Kan vi på en eller anden måde "formere" det eneste "tag" til vores rådighed? Ja vi kan. Pumpens nuværende tilstand er karakteriseret ved graden af ​​lighed med registrerede defekter. Selv uden brug af kvantitative metoder, på niveau med visuel opfattelse, ved at observere dynamikken i dataværdier, der kommer fra processtyringssystemet, kan du allerede lære meget:

Figur 4 Dynamik af pumpens tilstand på baggrund af et "mærke" af en defekt af en given type

Men visuel perception (i hvert fald for nu) er ikke den mest egnede generator af "tags" i vores hurtigt skiftende scenarie. Vi vil evaluere ligheden mellem den aktuelle pumpetilstand og de rapporterede defekter ved hjælp af en statistisk test.

Figur 5 Anvendelse af en statistisk test på indgående data på baggrund af en defekt "label"

En statistisk test bestemmer sandsynligheden for, at registreringerne med værdierne af de teknologiske procesparametre i "flow-pakken" modtaget fra processtyringssystemet svarer til registreringerne af "tag" af en defekt af en bestemt type. Sandsynlighedsværdien (statistisk lighedsindeks) beregnet som et resultat af anvendelse af en statistisk test konverteres til en værdi på 0 eller 1, og bliver til en "label" for maskinlæring i hver specifik post i den pakke, der undersøges for lighed. Det vil sige, at efter at have behandlet en nyligt modtaget pakke med pumpetilstandsregistreringer med en statistisk test, har vi mulighed for at (a) tilføje denne pakke til træningssættet til træning af AI/ML-modellen og (b) udføre kvalitetskontrol af aktuelle version af modellen, når du bruger den til denne pakke.

Figur 6 Anvendelse af en maskinlæringsmodel på indgående data på baggrund af en defekt "label"

I en af ​​vores tidligere webinarer Vi viser og forklarer, hvordan InterSystems IRIS-platformen giver dig mulighed for at implementere enhver AI/ML-mekanisme i form af kontinuerlig eksekvering af forretningsprocesser, der overvåger pålideligheden af ​​modelleringsresultater og tilpasser modelparametre. Når vi implementerer en prototype af vores scenarie med pumper, bruger vi al InterSystems IRIS-funktionalitet, der blev præsenteret under webinaret - implementerer i analysatorprocessen som en del af vores løsning, ikke klassisk overvåget læring, men snarere forstærkningslæring, som automatisk styrer udvælgelsen til træningsmodeller . Træningsprøven indeholder poster, hvorpå der opstår en "detektionskonsensus" efter anvendelse af både den statistiske test og den aktuelle version af modellen - dvs. både den statistiske test (efter transformation af lighedsindekset til 0 eller 1) og modellen producerede resultatet på sådanne registreringer 1. Under ny træning af modellen, under dens validering (den nyuddannede model anvendes på sin egen træningsprøve, med foreløbig anvendelse af en statistisk test på den), registreringer, der "ikke beholdt" resultat 1 efter behandling ved den statistiske test (på grund af den konstante tilstedeværelse i træningen en prøve af optegnelser fra den originale "label" af defekten), fjernes fra træningssættet, og en ny version af modellen lærer af "etiketten" af defekt plus de "beholdte" poster fra streamen.

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

Hvis der er behov for en slags "second opinion" om kvaliteten af ​​detektion opnået ved lokale beregninger i InterSystems IRIS, oprettes en rådgiverproces til at udføre træning og anvendelse af modeller på et kontroldatasæt ved hjælp af cloud-tjenester (f.eks. Microsoft Azure, Amazon Web Services, Google Cloud Platform osv.):

Figur 8 Second Opinion fra Microsoft Azure orkestreret af InterSystems IRIS

Prototypen af ​​vores scenarie i InterSystems IRIS er designet som et agentbaseret system af analytiske processer, der interagerer med et udstyrsobjekt (pumpe), matematiske modelleringsmiljøer (Python, R og Julia) og sikrer selvindlæring af alle involverede AI/ ML-mekanismer - på datastrømme i realtid.

Figur 9 Hovedfunktionalitet af realtids-AI/ML-løsningen i InterSystems IRIS

Det praktiske resultat af vores prototype:

• Prøve defekt genkendt af modellen (12. januar):

• En udviklingsdefekt genkendt af modellen, som ikke var inkluderet i prøven (11. september, selve defekten blev identificeret af reparationsteamet kun to dage senere, den 13. september):

Simulering på reelle data, der indeholder flere episoder af den samme defekt, viste, at vores løsning, implementeret på InterSystems IRIS-platformen, giver os mulighed for at identificere udviklingen af ​​defekter af denne type flere dage før de opdages af reparationsteamet.

InterSystems IRIS - en universel real-time AI/ML computerplatform

InterSystems IRIS-platformen forenkler udvikling, implementering og drift af realtidsdataløsninger. InterSystems IRIS er i stand til samtidigt at udføre transaktions- og analytisk databehandling; understøtte synkroniserede datavisninger i henhold til flere modeller (herunder relationelle, hierarkiske, objekter og dokumenter); fungere som en platform til at integrere en bred vifte af datakilder og individuelle applikationer; levere avancerede realtidsanalyser på strukturerede og ustrukturerede data. InterSystems IRIS leverer også mekanismer til brug af eksterne analytiske værktøjer og tillader fleksibel kombination af hosting i skyen og på lokale servere.

Applikationer bygget på InterSystems IRIS-platformen er blevet implementeret på tværs af en række brancher, der hjælper virksomheder med at realisere betydelige økonomiske fordele fra et strategisk og operationelt perspektiv, øget informeret beslutningstagning og bygge bro mellem begivenhed, analyse og handling.

Figur 10 InterSystems IRIS-arkitektur i sammenhæng med AI/ML i realtid

Ligesom det foregående diagram kombinerer diagrammet nedenfor det nye "koordinatsystem" (CD/CI/CT) med et diagram over informationsstrømmen mellem platformens arbejdselementer. Visualiseringen begynder med makromekanismens CD og fortsætter med makromekanismerne CI og CT.

Figur 11 Diagram over informationsstrømme mellem AI/ML-elementer i InterSystems IRIS-platformen

Essensen af ​​CD-mekanismen i InterSystems IRIS: platformbrugere (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 (fulde navn: Jupyter Notebook; for kortheds skyld kaldes dokumenter oprettet i denne editor også nogle gange). I Jupyter har en udvikler mulighed for at skrive, fejlsøge og verificere ydeevnen (herunder ved hjælp af grafik) af en specifik AI/ML-udvikling, før den placeres ("udrulles") i InterSystems IRIS. Det er klart, at en ny udvikling, der er oprettet på denne måde, kun vil modtage grundlæggende fejlfinding (da især Jupyter ikke arbejder med datastrømme i realtid) - dette er i tingenes rækkefølge, fordi hovedresultatet af udviklingen i Jupyter er bekræftelse af den grundlæggende funktionalitet af en separat AI/ML-mekanisme ("viser det forventede resultat på en dataprøve"). På samme måde kan en mekanisme, der allerede er placeret i platformen (se følgende makromekanismer) før fejlretning i Jupyter kræve en "rollback" til en "præ-platform"-form (læse data fra filer, arbejde med data gennem xDBC i stedet for tabeller, direkte interaktion med globaler - multidimensionelle dataarrays InterSystems IRIS – osv.).

Et vigtigt aspekt af CD-implementering i InterSystems IRIS: tovejsintegration er blevet implementeret mellem platformen og Jupyter, hvilket gør det muligt at overføre indhold i Python, R og Julia til platformen (og efterfølgende behandles i platformen) (alle tre programmerer sprog i de tilsvarende førende open source-sprog). matematiske kildemodelleringsmiljøer). Således har AI/ML-indholdsudviklere mulighed for at udføre "kontinuerlig udrulning" af dette indhold i platformen, arbejde i deres velkendte Jupyter-editor, med velkendte biblioteker tilgængelige i Python, R, Julia og udføre grundlæggende debugging (hvis nødvendigt) uden for platformen.

Lad os gå videre til CI-makromekanismen i InterSystems IRIS. Diagrammet viser makroprocessen af ​​"real-time robotizer" (et kompleks af datastrukturer, forretningsprocesser og kodefragmenter orkestreret af dem i matematiske sprog og ObjectScript - det oprindelige udviklingssprog i InterSystems IRIS). Opgaven med denne makroproces er at vedligeholde de datakøer, der er nødvendige for driften af ​​AI/ML-mekanismer (baseret på datastrømme transmitteret til platformen i realtid), træffe beslutninger om applikationssekvensen og "sortimentet" af AI/ ML-mekanismer (de er også "matematiske algoritmer", "modeller" osv. - kan kaldes forskelligt afhængigt af implementeringens specifikationer og terminologiske præferencer), holder datastrukturer ajour for at analysere resultaterne af arbejdet med AI/ ML-mekanismer (kuber, tabeller, multidimensionelle dataarrays osv.) osv. – til rapporter, dashboards osv.).

Et vigtigt aspekt af CI-implementering i InterSystems IRIS: tovejsintegration er blevet implementeret mellem platformen og matematiske modelleringsmiljøer, hvilket giver dig mulighed for at eksekvere indhold hostet på platformen i Python, R og Julia i deres respektive miljøer og modtage eksekveringsresultaterne tilbage. Denne integration er implementeret både i "terminaltilstand" (dvs. AI/ML-indhold er formuleret som ObjectScript-kode, der foretager opkald til miljøet) og i "forretningsprocestilstand" (dvs. AI/ML-indhold er formuleret som en forretningsproces ved hjælp af en grafisk editor, eller nogle gange ved at bruge Jupyter, eller ved at bruge en IDE - IRIS Studio, Eclipse, Visual Studio Code). Tilgængeligheden af ​​forretningsprocesser til redigering i Jupyter afspejles gennem forbindelsen mellem IRIS på CI-niveau og Jupyter på CD-niveau. En mere detaljeret oversigt over integration med matematiske modelleringsmiljøer er givet nedenfor. På dette stadie er der efter vores mening al mulig grund til at sikre, at platformen har alle de nødvendige værktøjer til at implementere "kontinuerlig integration" af AI/ML-udviklinger (som kommer fra "kontinuerlig udrulning") til AI/ML-løsninger i realtid.

Og den vigtigste makromekanisme: CT. Uden den vil der ikke være nogen AI/ML-platform (selvom "realtid" vil blive implementeret via CD/CI). Essensen af ​​CT er platformens arbejde med "artefakter" af maskinlæring og kunstig intelligens direkte i arbejdssessioner i matematiske modelleringsmiljøer: modeller, distributionstabeller, matrixvektorer, lag af neurale netværk osv. Dette "arbejde" består i de fleste tilfælde af at skabe de nævnte artefakter i miljøer (i tilfælde af modeller, for eksempel, "skabelse" består i at indstille specifikationen for modellen og efterfølgende valg af værdierne for dens parametre - den såkaldte "træning" af modellen), deres anvendelse (for modeller: beregning ved hjælp af "model" værdier af målvariabler - prognoser, kategorimedlemskab, sandsynlighed for en begivenhed osv.) og forbedring af allerede oprettede og anvendte artefakter (f.eks. redefinering af et sæt modelinputvariabler baseret på resultaterne af anvendelsen - for at forbedre prognosenøjagtigheden, som en mulighed). Nøglepunktet i forståelsen af ​​CT's rolle er dens "abstraktion" fra virkeligheden af ​​CD og CI: CT vil implementere alle artefakter, med fokus på de beregningsmæssige og matematiske specifikationer af AI/ML-løsningen inden for de muligheder, der leveres af specifikke miljøer. Ansvaret for at "levere input" og "levere output" vil være CD og CIs ansvar.

Et vigtigt aspekt af implementeringen af ​​CT specifikt i InterSystems IRIS: ved at bruge integrationen med matematiske modelleringsmiljøer, der allerede er nævnt ovenfor, har platformen evnen til at udtrække netop disse artefakter fra arbejdssessioner, der kører under dens kontrol i matematiske miljøer og (vigtigst) vende dem til platformsdataobjekter. For eksempel kan en distributionstabel, der netop er blevet oprettet i en fungerende Python-session, (uden at stoppe Python-sessionen) overføres til platformen i form af for eksempel en global (et multidimensionelt InterSystems IRIS-dataarray) - og bruges til beregninger i en anden AI/ML-mekanisme (implementeret på sproget i et andet miljø - for eksempel i R) - eller en virtuel tabel. Et andet eksempel: parallelt med den "normale tilstand" af modellens drift (i Python-arbejdssessionen) udføres "auto-ML" på dens inputdata: automatisk valg af optimale inputvariabler og parameterværdier. Og sammen med den "almindelige" træning modtager en produktiv model i realtid også et "forslag til optimering" af sin specifikation - hvor sættet af inputvariabler ændres, parameterværdierne ændres (ikke længere som et resultat af træning i Python, men som et resultat af træning med en "alternativ" " version af sig selv, såsom H2O-stakken), hvilket giver den overordnede AI/ML-løsning mulighed for autonomt at klare uventede ændringer i arten af ​​de inputdata og fænomener, der modelleres .

Lad os stifte nærmere bekendtskab med platformens AI/ML-funktionalitet i InterSystems IRIS ved at bruge eksemplet på en prototype fra det virkelige liv.

I diagrammet nedenfor er der på venstre side af sliden en del af forretningsprocessen, der implementerer eksekveringen af ​​scripts i Python og R. I den centrale del er der visuelle logfiler over udførelsen af ​​nogle af disse scripts, hhv. i Python og R. Umiddelbart bag dem er eksempler på indhold på et og et andet sprog, overført til udførelse til de relevante miljøer. I slutningen til højre er visualiseringer baseret på resultaterne af scriptudførelse. Visualiseringerne øverst blev lavet på IRIS Analytics (data blev taget fra Python ind i InterSystems IRIS dataplatform og vist på et dashboard ved hjælp af platformen), nederst blev lavet direkte i R arbejdssessionen og output derfra til grafiske filer . Et vigtigt aspekt: ​​det præsenterede fragment i prototypen er ansvarlig for at træne modellen (klassificering af udstyrstilstande) på data modtaget i realtid fra udstyrssimulatorprocessen efter kommando fra klassificeringskvalitetsovervågningsprocessen observeret under anvendelsen af ​​modellen. Implementeringen af ​​en AI/ML-løsning i form af et sæt af interagerende processer ("agenter") vil blive diskuteret yderligere.

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

Platformprocesser (de er også "forretningsprocesser", "analytiske processer", "pipelines" osv. - afhængigt af konteksten) redigeres først og fremmest i den grafiske forretningsproceseditor i selve platformen, og i en sådan en måde, at både dets blokdiagram og den tilsvarende AI/ML-mekanisme (programkode) oprettes samtidigt. Når vi siger, at "der opnås en AI/ML-mekanisme", mener vi i første omgang hybriditet (inden for én proces): indhold på sprogene i matematiske modelleringsmiljøer støder op til indhold i SQL (inklusive udvidelser fra Integreret ML), i InterSystems ObjectScript, med andre understøttede sprog. Desuden giver platformsprocessen meget brede muligheder for "gengivelse" i form af hierarkisk indlejrede fragmenter (som det kan ses i eksemplet i diagrammet nedenfor), hvilket giver dig mulighed for effektivt at organisere selv meget komplekst indhold uden nogensinde at "falde ud" af det grafiske format (i "ikke-grafiske" formater). » metoder/klasser/procedurer osv.). Det vil sige, at hvis det er nødvendigt (og det forudses i de fleste projekter), kan absolut hele AI/ML-løsningen implementeres i et grafisk selvdokumenterende format. Bemærk venligst, at i den centrale del af nedenstående diagram, som repræsenterer et højere "niveau af rede", er det tydeligt, at der udover selve arbejdet med at træne modellen (ved hjælp af Python og R) er en analyse af den såkaldte ROC-kurven for den trænede model er tilføjet, hvilket gør det muligt visuelt (og også beregningsmæssigt) at evaluere kvaliteten af ​​træningen - og denne analyse implementeres på Julia-sproget (udføres derfor i det matematiske Julia-miljø).

Figur 13 Visuelt miljø for sammensætning af AI/ML-løsninger i InterSystems IRIS

Som tidligere nævnt vil/kan den indledende udvikling og (i nogle tilfælde) tilpasning af AI/ML-mekanismer, der allerede er implementeret i platformen, ske uden for platformen i Jupyter-editoren. I diagrammet nedenfor ser vi et eksempel på tilpasning af en eksisterende platformsproces (det samme som i diagrammet ovenfor) - sådan ser det fragment ud, der er ansvarlig for træning af modellen, i Jupyter. Python-indhold er tilgængeligt til redigering, fejlretning og grafikoutput direkte i Jupyter. Ændringer (om nødvendigt) kan foretages med øjeblikkelig synkronisering i platformsprocessen, inklusive dens produktive version. Nyt indhold kan overføres til platformen på lignende måde (en ny platformsproces genereres automatisk).

Figur 14 Brug af Jupyter Notebook til at redigere AI/ML-motoren i InterSystems IRIS-platformen

Tilpasning af en platformsproces kan udføres ikke kun i et grafisk eller bærbart format - men også i det "totale" IDE-format (Integrated Development Environment). Disse IDE'er er IRIS Studio (native IRIS studio), Visual Studio Code (InterSystems IRIS udvidelse til VSCode) og Eclipse (Atelier plugin). I nogle tilfælde er det muligt for et udviklingsteam at bruge alle tre IDE'er samtidigt. Diagrammet nedenfor viser et eksempel på redigering af den samme proces i IRIS studio, i Visual Studio Code og i Eclipse. Absolut alt indhold er tilgængeligt til redigering: Python/R/Julia/SQL, ObjectScript og forretningsproces.

Figur 15 Udvikling af InterSystems IRIS-forretningsprocessen i forskellige IDE'er

Værktøjerne til at beskrive og udføre InterSystems IRIS forretningsprocesser i Business Process Language (BPL) fortjener særlig omtale. BPL gør det muligt at bruge "færdige integrationskomponenter" (aktiviteter) i forretningsprocesser - hvilket faktisk giver al mulig grund til at sige, at "kontinuerlig integration" er implementeret i InterSystems IRIS. Færdiglavede forretningsproceskomponenter (aktiviteter og forbindelser mellem dem) er en kraftfuld accelerator til at samle en AI/ML-løsning. Og ikke kun forsamlinger: Takket være aktiviteterne og forbindelserne mellem dem over forskellige AI/ML-udviklinger og -mekanismer opstår et "autonomt ledelseslag", der er i stand til at træffe beslutninger i henhold til situationen i realtid.

Figur 16 Færdige forretningsproceskomponenter til kontinuerlig integration (CI) på InterSystems IRIS-platformen

Konceptet med agentsystemer (også kendt som "multi-agent-systemer") har en stærk position inden for robotisering, og InterSystems IRIS-platformen understøtter det organisk gennem "produkt-proces"-konstruktionen. Ud over de ubegrænsede muligheder for at "fylde" hver proces med den funktionalitet, der er nødvendig for den overordnede løsning, giver systemet af platformsprocesser egenskaben "agentur" dig mulighed for at skabe effektive løsninger til ekstremt ustabile simulerede fænomener (adfærd af social/ biosystemer, delvist observerbare teknologiske processer osv.).

Figur 16 Drift af en AI/ML-løsning som et agentbaseret forretningsprocessystem i InterSystems IRIS

Vi fortsætter vores gennemgang af InterSystems IRIS med en historie om den anvendte brug af platformen til at løse hele klasser af realtidsproblemer (en ret detaljeret introduktion til nogle af de bedste praksisser for platform AI/ML på InterSystems IRIS kan findes i en af vores tidligere webinarer).

Hot i hælene på det forrige diagram, nedenfor er et mere detaljeret diagram over agentsystemet. Diagrammet viser den samme prototype, alle fire agentprocesser er synlige, relationerne mellem dem er skematisk tegnet: GENERATOR - behandler oprettelsen af ​​data af udstyrssensorer, BUFFER - styrer datakøer, ANALYSER - udfører selv maskinlæring, MONITOR - overvåger kvalitet af machine learning og afgiver et signal om behovet for at genoptræne modellen.

Figur 17 Sammensætning af en AI/ML-løsning i form af et agentbaseret forretningsprocessystem i InterSystems IRIS

Diagrammet nedenfor illustrerer den autonome funktion af en anden robotprototype (genkendelse af den følelsesmæssige farvning af tekster) i nogen tid. I den øverste del er udviklingen af ​​kvalitetsindikatoren for modeltræning (kvaliteten vokser), i den nederste del er dynamikken i kvalitetsindikatoren for modelanvendelse og fakta om gentagen træning (røde striber). Som du kan se, har løsningen lært sig selv effektivt og selvstændigt og fungerer på et givet kvalitetsniveau (kvalitetsscoreværdier falder ikke under 80%).

Figur 18 Kontinuerlig (selv)træning (CT) på InterSystems IRIS-platformen

Vi nævnte også "auto-ML" tidligere, men diagrammet nedenfor viser brugen af ​​denne funktionalitet i detaljer ved hjælp af eksemplet på en anden prototype. Det grafiske diagram af et fragment af en forretningsproces viser den aktivitet, der udløser modelleringen i H2O-stakken, viser resultaterne af denne modellering (den resulterende models klare dominans over "menneskeskabte" modeller, ifølge det sammenlignende diagram af ROC-kurver, samt den automatiserede identifikation af de "mest indflydelsesrige variabler", der er tilgængelige i det originale datasæt). En vigtig pointe her er besparelsen af ​​tid og ekspertressourcer, der opnås gennem "auto-ML": Hvad vores platformsproces gør på et halvt minut (at 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 en AI/ML-løsning på InterSystems IRIS-platformen

Diagrammet nedenfor går lidt glip af pointen, men det er en god måde at afslutte historien om de klasser af realtidsproblemer, der løses: vi minder dig om, at med alle mulighederne i InterSystems IRIS-platformen er træningsmodeller under dens kontrol. ikke obligatorisk. Platformen kan udefra modtage den såkaldte PMML-specifikation af modellen, trænet i et værktøj, der ikke er under kontrol af platformen - og anvende denne model i realtid fra det øjeblik, den importeres PMML specifikationer. Det er vigtigt at tage højde for, at ikke alle AI/ML-artefakter kan reduceres til en PMML-specifikation, selvom de fleste af de mest almindelige artefakter tillader dette. InterSystems IRIS-platformen er således "open loop" og betyder ikke "platformslaveri" for brugerne.

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

Lad os liste de yderligere platformsfordele ved InterSystems IRIS (for klarhedens skyld i forhold til processtyring), som er af stor betydning i automatiseringen af ​​kunstig intelligens og maskinlæring i realtid:

• Udviklede integrationsværktøjer med alle datakilder og forbrugere (proceskontrolsystem/SCADA, udstyr, MRO, ERP osv.)
• Indbygget multi-model DBMS til højtydende transaktions- og analytisk behandling (Hybrid Transaction/Analytical Processing, HTAP) af enhver mængde teknologiske procesdata
• Udviklingsværktøjer til kontinuerlig implementering af AI/ML-motorer til realtidsløsninger baseret på Python, R, Julia
• Adaptive forretningsprocesser til kontinuerlig integration og (selv)læring af AI/ML-løsningsmotorer i realtid
• Indbyggede Business Intelligence-værktøjer til visualisering af procesdata og resultaterne af en AI/ML-løsning
• API-styring til levering af resultaterne af AI/ML-løsningen til processtyringssystemer/SCADA, informations- og analysesystemer, afsendelse af alarmer mv.

AI/ML-løsninger på InterSystems IRIS-platformen passer nemt ind i den eksisterende it-infrastruktur. InterSystems IRIS-platformen sikrer høj pålidelighed af AI/ML-løsninger ved at understøtte fejltolerante og katastrofetolerante konfigurationer og fleksibel implementering i virtuelle miljøer, på fysiske servere, i private og offentlige skyer og Docker-containere.

InterSystems IRIS er således en universel real-time AI/ML computerplatform. Vores platforms universalitet bekræftes i praksis af fraværet af de facto begrænsninger på kompleksiteten af ​​implementerede beregninger, InterSystems IRIS's evne til at kombinere (i realtid) behandling af scenarier fra en lang række forskellige industrier og den exceptionelle tilpasningsevne af enhver platforms funktioner og mekanismer til brugernes specifikke behov.

Figur 21 InterSystems IRIS - en universel AI/ML-computerplatform i realtid

For en mere indholdsrig interaktion med de af vores læsere, der er interesserede i det materiale, der præsenteres her, anbefaler vi, at du ikke begrænser dig til at læse det og fortsætter dialogen "live". Vi yder gerne support med formulering af real-time AI/ML scenarier i forhold til din virksomheds detaljer, udfører fælles prototyping på InterSystems IRIS platformen, formulerer og implementerer i praksis en køreplan for introduktion af kunstig intelligens og maskinlæring ind i dine produktions- og ledelsesprocesser. Vores AI/ML-ekspertteam Kontakt-e-mail – [e-mail beskyttet].

Kilde: www.habr.com