Forfattar: Serhij Luk'janÄikov, ingeniĂžrkonsulent for InterSystems
Utfordringar med AI/ML-realtidsberegningar
La oss starte med eksempler fra erfaringer med Data Science-praksis i InterSystems:
- Den «belasta» kundeporalen er kopla til eit online anbefalingssystem. Det er planlagt omstrukturering av kampanjer i den butikkjeden (til dÞmes, i staden for ei «flat» rekkje av kampanjer, vil det no bli brukt ei matrise av «segment-strategi»). Kva skjer med anbefalingsmekanismane? Kva skjer med innlevering og oppdatering av data i anbefalingsmekanismen (volumet av inngangsdata har auka med 25000 ganger)? Kva skjer med generering av anbefalingar (behovet for tusenfalt reduksjon av terskelen for filtrering av anbefalingsregler pÄ grunn av tusenfoldig auke i deira tal og «utval»)?
- Det er ein overvÄkningssystem for sannsynlighet for utvikling av feil i utstyrselement. Det ble knyttet til et sentralisert styringssystem (ASUTP), som overfÞrer tusenvis av prosessparametre hvert sekund. Kva skjer med overvÄkningssystemet som tidlegare arbeidde med «manuelle utval» (er det i stand til Ä sÞrge for overvÄking av sannsynlighet hvert sekund)? Kva vil skje dersom det kjem ei ny blokk i inngangsdataene med hundrevis av kolonner med sensoravlesingar, som nettopp er lagt til i ASUTP (vil det vere nÞdvendig og kor lenge vil overvÄkningssystemet mÄ stansast for Ä inkludere dataanalysen frÄ dei nye sensorane)?
- Det er oppretta eit kompleks av AI/ML-mekanismar (anbefalande, overvÄkande, prognostiske), som nyttar resultata frÄ kvarandre. Kor mange mennesketimar er det behov for kvar mÄnad for Ä tilpasse dette komplekset til endringar i inngangsdataene? Kva er den totale «forsinkinga» ved Ä stÞtte komplekset for Ä ta styringsavgjerder (frekvensen av ny stÞttande informasjon i forhold til frekvensen av nye inngangsdata)?
Samanfattande desse og mange andre eksempel har vi kome til formuleringar av desse utfordringane som oppstÄr nÄr me gÄr over til bruk av maskinlÊrings- og kunstig intelligensmekanismar i sanntid:
- Er vi nÞgde med hastigheita av oppretting og tilpasning (til den skiftande situasjonen) av AI/ML-lÞysingar i vÄr bedrift?
- Hvor godt stÞtter AI/ML-lÞsningene vÄre sanntid forretningsledelse?
- Er AI/ML-lÞsningene vÄre i stand til Ä tilpasse seg endringer i data og forretningspraksis uten utviklere?
Artikkelen vÄr er en grundig gjennomgang av mulighetene til InterSystems IRIS-plattformen for universell stÞtte til implementering av AI/ML-mekanismer, integrering av AI/ML-lÞsninger og opplÊring/testing av AI/ML-lÞsninger pÄ intensive datastreams. Vi vil se pÄ markedsundersÞkelser, praktiske eksempler pÄ AI/ML-lÞsninger og de konseptuelle aspektene av hva vi kaller en AI/ML-plattform for sanntid i denne artikkelen.
Hva vi lĂŠrte fra undersĂžkelser: sanntidsapplikasjoner
Resultater , utfĂžrt blant omtrent 800 IT-fagfolk i 2019 av Lightbend, taler for seg selv:

Figur 1 Ledende forbrukere av sanntidsdata
La oss sitere viktige utdrag fra rapporten om resultatene av denne undersÞkelsen i vÄr oversettelse:
«⊠Tendensene i populariteten til verktĂžy for datastream-integrasjon og samtidig stĂžtte for beregninger i containere gir en synergistisk respons pĂ„ forespĂžrselen fra markedet om en mer operativ, rasjonell, dynamisk tilnĂŠrming til effektive lĂžsninger. Datastreams tillater raskere informasjonsformidling enn tradisjonelle batch-data. I tillegg kommer muligheten for Ă„ bruke beregningsmetoder raskt, som AI/ML-baserte anbefalinger, som skaper konkurransefortrinn gjennom Ăžkt kundetilfredshet. LĂžpet etter hastighet pĂ„virker ogsĂ„ alle roller i DevOps-paradigmet â det Ăžker utviklings- og distribusjonseffektiviteten for applikasjoner. ⊠à tte hundre og fire IT-spesialister ga informasjon om bruken av datastreams i organisasjonene deres. Respondentene var hovedsakelig fra vestlige land (41 % i Europa og 37 % i Nord-Amerika) og var praktisk talt jevnt fordelt mellom smĂ„, mellomstore og store selskaper. âŠ
Kunstig intelligens er ikke bare hype. FemtiÄtte prosent av de som allerede bruker datastreaming i produktive AI/ML-applikasjoner bekrefter at bruken i AI/ML vil oppnÄ den stÞrste veksten det kommende Äret (sammenlignet med andre applikasjoner).
- IfÞlge flertallet av de spurte vil bruken av datastreaming i AI/ML-scenarier oppnÄ den stÞrste veksten det kommende Äret.
- Bruken i AI/ML vil vokse ikke bare pÄ grunn av relativt nye typer scenarier, men ogsÄ pÄ grunn av tradisjonelle scenarier, der sanntidsdata brukes stadig mer intensivt.
- I tillegg til AI/ML er entusiasmen blant brukerne av IoT-datastreaming imponerende â 48 % av de som allerede har integrert IoT-data, hevder at implementeringen av scenarier basert pĂ„ disse dataene vil oppnĂ„ betydelig vekst i nĂŠr fremtid. ⊠»
Denne ganske interessante undersĂžkelsen viser at oppfatningen av maskinlĂŠring og kunstig intelligens som toppbrukere av datastreaming er allerede «pĂ„ vei». Men et ikke mindre viktig observasjon er oppfatningen av AI/ML i sanntid gjennom linsen av DevOps: her kan vi allerede begynne Ă„ snakke om transformasjonen fra den dominerende kulturen av âengangs AI/ML med fullt tilgjengelige datamengderâ.
Konseptet av en AI/ML-plattform for sanntid
Et typisk anvendelsesomrÄde for AI/ML i sanntid er styring av teknologiske prosesser i produksjon. La oss formulere konseptet for en AI/ML-plattform for sanntid basert pÄ dette eksemplet og de tidligere betraktningene.
Bruken av kunstig intelligens og maskinlĂŠring i styring av teknologiske prosesser har en rekke sĂŠregenheter:
- Data om tilstanden til den teknologiske prosessen kommer inn intensivt: med hĂžy frekvens og over et bredt spekter av parametere (opp til titusenvis av parametere sendt per sekund fra automatiserte systemer).
- Data om identifikasjon av feil, for ikke Ä nevne data om deres utvikling, er derimot knappe og uregelmessige, preget av utilstrekkelig typisering av feilene og deres tidslokalisering (ofte presentert pÄ papirdokumenter).
- Fra et praktisk perspektiv er det kun «aktualitetsvinduet» for de opprinnelige dataene som er tilgjengelig for trening og anvendelse av modeller, som reflekterer dynamikken i den teknologiske prosessen over et rimelig glidende intervall, som avsluttes med de siste innleste verdiene av prosessparametrene.
Disse egenskapene tvinger oss, i tillegg til Ă„ motta og grunnleggende behandle den intensive «bredbĂ„ndsinngangssignalet» fra den teknologiske prosessen i sanntid, ogsĂ„ Ă„ utfĂžre (parallelt) anvendelse, trening og kvalitetskontroll av resultatene fra AI/ML-modellene â ogsĂ„ i sanntid. Det «bilde» som modellene vĂ„re «ser» i det glidende aktualitetsvinduet, endres kontinuerlig â og sammen med det endres ogsĂ„ kvaliteten pĂ„ resultatene fra AI/ML-modellene som er trent pĂ„ ett av «bildene» i fortiden. Ved forverring av kvaliteten pĂ„ resultatene fra AI/ML-modellene (for eksempel: klassifiseringsfeilverdien «alarm-norm» har kommet utenfor de grensene vi har definert) bĂžr det automatisk starte en ny trening av modellene pĂ„ et mer aktuelt «bilde» â og tidspunktene for innsettelse av ny trening av modellene mĂ„ ta hensyn til bĂ„de varigheten av selve treningen og dynamikken i forverringen av kvaliteten pĂ„ arbeidet til den nĂ„vĂŠrende versjonen av modellene (siden de nĂ„vĂŠrende versjonene av modellene fortsetter Ă„ bli brukt, mens modellene trenes, og fĂžr deres «nytrente» versjoner er dannet).
InterSystems IRIS har kjernemuligheter for Ă„ stĂžtte drift av AI/ML-lĂžsninger for styring av teknologiske prosesser i sanntid. Disse mulighetene kan deles inn i tre hovedgrupper:
- Kontinuerlig utrulling (Continuous Deployment/Delivery, CD) av nye eller tilpassede eksisterende AI/ML-mekanismer inn i et produktivt lÞsning som opererer i sanntid pÄ plattformen InterSystems IRIS.
- Kontinuerlig integrasjon (Continuous Integration, CI) av inngÄende datastreamer fra den teknologiske prosessen, datakÞer for anvendelse/trening/kvalitetskontroll av AI/ML-mekanismer og data/kode/kontrollinteraksjoner med miljÞer for matematisk modellering, som orkestreres i sanntid av plattformen InterSystems IRIS.
- Kontinuerlig (selv-)lÊring (Continuous Training, CT) av AI/ML-mekanismer, som utfÞres i matematiske simuleringsmiljÞer ved hjelp av data, kode og styringseffekter («traff beslutninger»), overfÞrt av InterSystems IRIS-plattformen.
Klassifiseringen av plattformmuligheter i forhold til maskinlÊring og kunstig intelligens er ikke tilfeldig. La oss sitere metodologien fra Google, som danner den konseptuelle basen for denne klassifiseringen, i vÄr oversettelse:
«⊠Den populÊre DevOps-konsepten i dag dekker utvikling og drift av storskalainformasjonsystemer. Fordelene ved Ä implementere dette konseptet er reduksjon av varigheten av utviklingssykluser, akselerasjon av distribusjonene, fleksibilitet i utgivelsesplanlegging. For Ä oppnÄ disse fordelene forutsetter DevOps implementering av minst to praksiser:
- Continuous Integration (CI)
- Continuous Delivery (CD)
Disse praksisene gjelder ogsĂ„ for AI/ML-plattformer â for Ă„ sikre en pĂ„litelig og effektiv bygging av produktive AI/ML-lĂžsninger.
AI/ML-plattformer skiller seg fra andre informasjonssystemer i fĂžlgende aspekter:
- Teamets kompetanse: NÄr man lager en AI/ML-lÞsning, inkluderer teamet vanligvis dataforskere eller akademiske eksperter innen datavitenskap, som utfÞrer dataanalyse, utvikling og testing av modeller. Disse teammedlemmene trenger ikke nÞdvendigvis Ä vÊre profesjonelle utviklere av produktiv programvarekode.
- Utvikling: AI/ML-mekanismer er eksperimentelle av natur. For Ä lÞse oppgaven pÄ den mest effektive mÄten, er det nÞdvendig Ä prÞve ulike kombinasjoner av inngangsvariabler, algoritmer, modelleringsmetoder og modellparametere. Kompleksiteten ved slik prÞving ligger i sporingen av «hva som fungerte/ikke fungerte», sikring av reproduksjon av episoder, generalisering av utviklingen for gjentatte implementeringer.
- Testing: testing av AI/ML-mekanismer krever et bredere spekter av tester enn de fleste andre utviklinger. I tillegg til standard modul- og integrasjonstester, testes datavaliditet og kvaliteten pÄ resultatene av modellens anvendelse pÄ trenings- og kontrollprÞver.
- Utrulling: Utrulling av AI/ML-lĂžsninger handler ikke bare om prediktive tjenester som bruker en en gang opplĂŠrt modell. AI/ML-lĂžsninger er bygget rundt flertrinns pipeline som utfĂžrer automatisert opplĂŠring og anvendelse av modeller. Utrulling av slike pipeliner innebĂŠrer automatisering av komplekse handlinger som tradisjonelt utfĂžres manuelt av dataforskere for Ă„ kunne trene og teste modeller.
- Produktivitet: AI/ML-mekanismer kan mangle ytelse ikke bare pÄ grunn av ineffektiv programmering, men ogsÄ pÄ grunn av den stadig skiftende naturen til inngangsdataene. Med andre ord kan ytelsen til AI/ML-mekanismer degraderes pÄ grunn av et bredere spekter av Ärsaker enn det som gjelder for vanlig utvikling. Dette fÞrer til behovet for overvÄking (i sanntid) av ytelsen til vÄre AI/ML-mekanismer, samt utsendelse av varsler eller utelukkelse av resultater hvis ytelsesindikatorene ikke mÞter forventningene.
AI/ML-plattformer ligner andre informasjonssystemer ved at de begge krever kontinuerlig kodeintegrasjon med versjonskontroll, modulĂŠr testing, integrasjonstesting og kontinuerlig utrulling av utvikling. Imidlertid er det noen viktige forskjeller med AI/ML:
- CI (Continuous Integration, kontinuerlig integrasjon) er ikke lenger begrenset til testing og validering av koden til utrullede komponenter â det inkluderer ogsĂ„ testing og validering av data og AI/ML-modeller.
- CD (Continuous Delivery/Deployment, kontinuerlig utrulling) handler ikke bare om Ă„ skrive og gi ut pakker eller tjenester, men innebĂŠrer en plattform for komposisjon, opplĂŠring og anvendelse av AI/ML-lĂžsninger.
- CT (Continuous Training, kontinuerlig opplĂŠring) â et nytt element [forf. merknad: et nytt element i forhold til den tradisjonelle DevOps-konseptet, der CT vanligvis er Continuous Testing], som er karakteristisk for AI/ML-plattformer, ansvarlig for autonom hĂ„ndtering av mekanismene for opplĂŠring og anvendelse av AI/ML-modeller. ...
Vi kan konstatere at maskinlÊring og kunstig intelligens som arbeider med sanntidsdata, krever et bredere sett av verktÞy og kompetanser (fra utvikling av kode til orkestrering av matematiske modeller), tettere integrasjon mellom alle funksjonelle og faglige omrÄder, samt en mer effektiv organisering av menneskelige og maskinelle ressurser.
Sanntidsscenario: gjenkjenning av utviklingen av defekter i nĂŠringspumper
NÄr vi fortsetter Ä bruke omrÄdet for styring av teknologiske prosesser som eksempel, vurderer vi en konkret oppgave (som allerede er nevnt tidligere): det er nÞdvendig Ä sikre sanntidsovervÄking av utviklingen av defekter i pumpene basert pÄ strÞmmen av parameterverdier for teknologiske prosesser og rapporter fra reparasjonspersonell om avdekkede defekter.

Figur 2 Formulering av oppgaven for overvÄking av utviklingen av defekter
En spesiell egenskap ved de fleste oppgaver stilt pÄ denne mÄten i praksis er at regelmessigheten og hastigheten med hvilke data (DCS) mottas, mÄ vurderes i lys av episodisk og uregelmessig oppstÄelse (og registrering) av defekter av ulike typer. Med andre ord: data fra DCS kommer med en sekunds frekvens nÞyaktige, mens defekter blir registrert med kjemisk blyant med dato i en felles notatbok i verkstedet (for eksempel: «12.01 - lekkasje i toppen fra den 3. lageret»).
Dermed kan vi supplere formuleringen av oppgaven med denne viktige restriksjonen: «merket» pĂ„ defekten av en bestemt type har vi bare Ă©n (dvs. eksempel pĂ„ en defekt av en spesifikk type er representert av data fra DCS pĂ„ en bestemt dato â og flere eksempler pĂ„ nettopp denne typen defekt har vi ikke). Denne restriksjonen tar oss umiddelbart utenfor rammen av klassisk maskinlĂŠring (supervised learning) som krever mange «merker».

Figur 3 Presisering av oppgaven for overvÄking av utviklingen av defekter
Kan vi pÄ en eller annen mÄte «duplikere» den eneste «merket» vi har tilgjengelig? Ja, vi kan det. Den nÄvÊrende tilstanden til pumpen kjennetegnes av graden av likhet med registrerte feil. Selv uten Ä bruke kvantitative metoder, bare ved Ä observere data fra overvÄkningssystemet, kan vi allerede hente ut mye informasjon ved visuell vurdering av dataene.

Figur 4 Dynamikken til pumpens tilstand i sammenheng med «merking» av en bestemt feiltype
Men visuell vurdering (i hvert fall for nÄ) er ikke den mest passende generatoren for «merking» i vÄrt raskt skiftende scenario. Vi skal vurdere likheten mellom pumpens nÄvÊrende tilstand og registrerte feil ved hjelp av statistisk testing.

Figur 5 Bruk av statistisk test pÄ dataene i sammenheng med «merking» av en bestemt feiltype
Den statistiske testen bestemmer sannsynligheten for at dataposter med verdier av prosessparametere i «datastream-pakken» fra overvÄkningssystemet ligner pÄ oppfÞringene for «merking» av en bestemt feiltype. Den beregnede sannsynligheten (indeks for statistisk likhet) konverteres til en verdi mellom 0 og 1, og blir en «merking» for maskinlÊring i hver enkelt oppfÞring i den undersÞkende pakken. Det vil si, etter at den nyankomne pakken med pumpens tilstand er behandlet med statistisk testen, fÄr vi muligheten til (a) Ä legge denne pakken til treningsdatasettet for AI/ML-modellen og (b) kontrollere kvaliteten pÄ den nÄvÊrende versjonen av modellen nÄr den brukes pÄ denne pakken.

Figur 6 Bruk av maskinlÊringsmodellen pÄ dataene i sammenheng med «merking» av en bestemt feiltype
I et av vĂ„re tidligere Vi viser og forklarer hvordan InterSystems IRIS-plattformen gjĂžr det mulig Ă„ realisere enhver AI/ML-mekanisme som kontinuerlig kjĂžrende forretningsprosesser, som overvĂ„ker nĂžyaktigheten av simuleringsresultatene og tilpasser modellens parametere. NĂ„r vi implementerer prototypene av vĂ„rt scenario med pumpene, bruker vi all funksjonaliteten til InterSystems IRIS som ble presentert i lĂžpet av webinaret â ved Ă„ implementere i prosessanalysatoren, ikke klassisk supervised learning, men snarere reinforcement learning, som automatisk styrer utvalget for modelltrening. I treningssettet plasseres poster der «konsensusdeteksjon» oppstĂ„r etter anvendelse av bĂ„de den statistiske testen og den nĂ„vĂŠrende versjonen av modellen â det vil si at bĂ„de den statistiske testen (etter transformeringen av likhet-indeksen til 0 eller 1) og modellen gir resultat 1 pĂ„ slike poster. Ved ny modelltrening, under valideringen (den nyutdannede modellen brukes pĂ„ sitt eget treningssett, med forhĂ„ndsbruk av den statistiske testen), fjernes poster som «ikke beholdt» resultat 1 etter behandling med den statistiske testen (pĂ„ grunn av konstant tilstedevĂŠrelse av poster fra den opprinnelige «merkelappen» avfeilen) fra treningssettet, og den nye modellen lĂŠrer pĂ„ «feilmerkelappen» pluss pĂ„ de «beholdte» postene fra strĂžmmen.

Figur 7 Robotisering av AI/ML-beregninger i InterSystems IRIS
Dersom det skulle oppstÄ et behov for en slags «andre mening» om kvaliteten pÄ detekteringen som oppnÄs ved lokale beregninger i InterSystems IRIS, opprettes det en prosess-rÄdgiver for Ä utfÞre trening-anvendelsesser pÄ et kontrolldatasett ved hjelp av skytjenester (for eksempel Microsoft Azure, Amazon Web Services, Google Cloud Platform osv.):

Figur 8 «Andre mening» fra Microsoft Azure under orkestrering av InterSystems IRIS
Prototypen av vĂ„rt scenario i InterSystems IRIS er utfĂžrt som et agentbasert system av analytiske prosesser som interagerer med utstyr (pumpen), matematiske modelleringsmiljĂžer (Python, R og Julia), og sikrer selvopplĂŠring av alle involverte AI/ML-mekanismer â pĂ„ sanntidsdata.

Figur 9 Hovedfunksjonaliteten til AI/ML-lĂžsningen for sanntid i InterSystems IRIS
Det praktiske resultatet av arbeidet med prototypen vÄr:
- Detektert defektmĂžnster av modellen (12. januar):

- Detektert utviklende defekt av modellen, som ikke var inkludert i prĂžven (11. september; selve defekten ble konstatert av reparasjonslaget fĂžrst etter to dager â 13. september):

Simulering pÄ ekte data som inneholder flere episoder av den samme defekten viste at lÞsningen vÄr, implementert pÄ InterSystems IRIS-plattformen, gjÞr det mulig Ä avslÞre utviklingen av defekter av denne typen flere dager fÞr reparasjonslaget oppdager dem.
InterSystems IRIS â en universell plattform for AI/ML-beregninger i sanntid.
InterSystems IRIS-plattformen forenkler utviklingen, distribusjonen og driften av lÞsninger basert pÄ sanntidsdata. InterSystems IRIS kan samtidig utfÞre transaksjons- og analytisk databehandling; stÞtte synkroniserte datavisninger i samsvar med flere modeller (inkludert relasjons-, hierarkiske, objekt- og dokumentmodeller); vÊre en integrasjonsplattform for et bredt spekter av datakilder og individuelle applikasjoner; og gi avansert sanntidsanalyse pÄ strukturerte og ustrukturerte data. InterSystems IRIS tilbyr ogsÄ mekanismer for Ä anvende eksternt analytiske verktÞy og gjÞr det mulig Ä kombinere skybasert og lokal serverplassering fleksibelt.
Applikasjoner bygget pÄ InterSystems IRIS-plattformen er implementert i ulike bransjer, og hjelper selskaper med Ä oppnÄ betydelig Þkonomisk effekt bÄde strategisk og operasjonelt, fremmer beslutningsinformasjon og fjerner 'gap' mellom hendelse, analyse og handling.

Figur 10 Arkitektur av InterSystems IRIS i konteksten av AI/ML i sanntid.
I likhet med det forrige diagrammet, kombinerer diagrammet nedenfor det nye 'koordinatsystemet' (CD/CI/CT) med informasjonsflytskjemaet mellom plattformens arbeidskomponenter. Visualiseringen starter med makromekanismen CD og fortsetter med makromekanismene CI og CT.

Figur 11 Informasjonsflytskjema mellom AI/ML-elementene pÄ InterSystems IRIS-plattformen.
Essensen av CD-mekanismen i InterSystems IRIS: Brukere av plattformen (utviklere av AI-/ML-lĂžsninger) tilpasser eksisterende og/eller lager nye AI-/ML-utviklinger ved hjelp av en spesialisert programkode-editor for AI-/ML-mekanismer: Jupyter (fullt navn: Jupyter Notebook; for enkelhets skyld refereres noen ganger til dokumentene som er laget i denne editoren pĂ„ kort). I Jupyter har utvikleren muligheten til Ă„ skrive, feilsĂžke og bekrefte funksjonaliteten (inkludert bruk av grafikk) av en spesifikk AI-/ML-utvikling fĂžr den blir implementert («distribuert») i InterSystems IRIS. Det er tydelig at den nye utviklingen som skapes pĂ„ denne mĂ„ten, bare vil fĂ„ grunnleggende feilsĂžking (blant annet fordi Jupyter ikke fungerer med sanntidsdatastreams) â dette er helt normalt, ettersom hovedresultatet av utviklingen i Jupyter blir en bekreftelse pĂ„ den teoretiske funksjonaliteten til den enkelte AI-/ML-mekanismen («viser forventet resultat pĂ„ dataprĂžven»). PĂ„ samme mĂ„te kan en allerede plassert mekanisme i plattformen (se de fĂžlgende makromekanismene) fĂžr feilretting i Jupyter kreve et «tilbakefall» til en «fĂžr-plattform» tilstand (som lesing av data fra filer, arbeid med data via xDBC i stedet for tabeller, direkte interaksjon med globale variabler â flerdimensjonale datamatriser i InterSystems IRIS â osv.).
Et viktig aspekt ved implementeringen av CD nettopp i InterSystems IRIS: Det er etablert en toveis integrasjon mellom plattformen og Jupyter, som gjÞr det mulig Ä overfÞre innhold til plattformen (og deretter behandle det i plattformen) pÄ sprÄkene Python, R og Julia (alle tre er programmeringssprÄk i de ledende open-source miljÞene for matematisk modellering). Dermed har utviklere av AI-/ML-innhold muligheten til Ä utfÞre «kontinuerlig distribusjon» av dette innholdet i plattformen, mens de arbeider i sin kjente Jupyter-editor, med de vanlige bibliotekene tilgjengelig i Python, R, Julia, og utfÞrer grunnleggende feilsÞking (ved behov) utenfor plattformen.
Vi gĂ„r videre til makromekanismen CI i InterSystems IRIS. Diagrammet viser makroprosessen av "realtidsroboten" (et kompleks av datastrukturer, forretningsprosesser og koden som orkestreres av dem, skrevet pĂ„ matrise-sprĂ„k og ObjectScript â det native utviklingssprĂ„ket til InterSystems IRIS). Oppgaven til denne makroprosessen er Ă„ opprettholde nĂždvendige datakĂžer for AI/ML-mekanismene (basert pĂ„ datastreams som overfĂžres til plattformen i sanntid), ta beslutninger om rekkefĂžlgen av bruk og "sortimentet" av AI/ML-mekanismer (de kalles ogsĂ„ "matematiske algoritmer", "modeller" osv. â kan ha ulike navn avhengig av spesifikasjonen av implementeringen og terminologiske preferanser), samt holde datastrukturene for analysen av resultatene av AI/ML-mekanismene (kubene, tabellene, flerdimensjonale datamasser osv. â for rapporter, dashbord, osv.) oppdatert.
Et viktig aspekt ved implementeringen av CI spesielt i InterSystems IRIS: mellom plattformen og miljĂžene for matematisk modellering er det etablert en toveis integrasjon, som gjĂžr det mulig Ă„ kjĂžre innhold plassert i plattformen pĂ„ sprĂ„kene Python, R og Julia i deres respektive miljĂžer og fĂ„ tilbake resultater av kjĂžringen. Denne integrasjonen er implementert bĂ„de i "terminalmodus" (dvs. AI/ML-innholdet formuleres som kode i ObjectScript som kaller pĂ„ matematiske miljĂžer), samt i "forretningsprosessmodus" (dvs. AI/ML-innholdet formuleres som en forretningsprosess ved hjelp av et grafisk redigeringsverktĂžy, noen ganger ved hjelp av Jupyter, eller ved hjelp av IDE â IRIS Studio, Eclipse, Visual Studio Code). Tilgjengeligheten av forretningsprosesser for redigering i Jupyter gjenspeiles ved hjelp av forbindelsen mellom IRIS pĂ„ CI-nivĂ„ og Jupyter pĂ„ CD-nivĂ„. En mer detaljert oversikt over integrasjonen med miljĂžene for matematisk modellering vil bli gitt senere. PĂ„ dette stadiet er det vĂ„r mening at det er alle grunnlag for Ă„ bekrefte at plattformen inneholder alle nĂždvendige verktĂžy for Ă„ implementere "kontinuerlig integrering" av AI/ML-utviklinger (som kommer fra "kontinuerlig distribusjon") i AI/ML-lĂžsninger i sanntid.
Og hovudmakromekanismen: CT. Uten det kan ikkje AI/ML-plattformer fungere (sjĂžlv om «sanntid» vil bli implementert gjennom CD/CI). Kjernen i CT er arbeidet til plattformen med «artefakter» for maskinlĂŠring og kunstig intelligens direkte i arbeidsĂžkter av matematiske modelleringsmiljĂžer: modeller, fordelingstabeller, vektormatriser, lag av nevrale nettverk, osv. Dette «arbeidet» bestĂ„r i dei fleste tilfeller av Ă„ lage nemnde artefakter i miljĂž (i tilfellet modeller, for eksempel, «opprettinga» bestĂ„r av Ă„ spesifisere modellen og deretter justere parameterverdiene â den sĂ„kalte «treninga» av modellen), anvendelsen deira (for modeller: beregning av «modellverdier» for mĂ„lvariablane â prognoser, kategorikrins, sannsynlighet for hendingar, osv.) og forbedring av allereie oppretta og brukte artefakter (for eksempel omdefinering av settet av inngangsvariabler for modellen basert pĂ„ resultata frĂ„ bruken â for Ă„ auke presisjonen i prognosene, som eit alternativ). Nokre av dei viktigaste punkta for Ă„ forstĂ„ rolla til CT er dens «abstraksjon» frĂ„ realitetane til CD og CI: CT vil implementere alle artefakter med utgangspunkt i den databehandlings- og matematiske spesifikasjonen av AI/ML-lĂžysinga innanfor moglegheitene som spesifikke miljĂž gir. Ansvar for «tilfĂžrsel av innganger» og «levering av resultater» vil ligge pĂ„ CD og CI.
En viktig aspekt av implementeringen av CT i InterSystems IRIS: ved Ă„ bruke den nevnte integrasjonen med matematiske modelleringsmiljĂžer, har plattformen muligheten til Ă„ hente ut de artefakter som oppstĂ„r i arbeidsĂžktene som kjĂžres under dens ledelse i matematiske miljĂžer, og (det viktigste) omdanne dem til plattformens dataobjekter. For eksempel kan en distribusjonstabell som nettopp er opprettet i en Python-Ăžkt (uten Ă„ stoppe Ăžkten i Python) overfĂžres til plattformen som en global (multidimensjonal datamatrise i InterSystems IRIS) â og brukes til beregninger i en annen AI/ML-mekanisme (implementert allerede pĂ„ sprĂ„k fra et annet miljĂž â for eksempel R) â eller som en virtuell tabell. Et annet eksempel: parallelt med «normalmodus» for modellens arbeid (i Python-Ăžkten) utfĂžres det pĂ„ dens inndata «auto-ML»: automatisk valg av optimale inndatavariabler og parameterverdier. Og sammen med «normal» trening fĂ„r den produktive modellen i sanntid ogsĂ„ «forslag til optimalisering» av sin spesifikasjon â der settet med inndatavariabler endres, parameterverdiene endres (ikke lenger som resultat av trening i Python, men som resultat av trening av en «alternativ» versjon av seg selv, for eksempel i H2O-stakken), noe som lar den totale AI/ML-lĂžsningen autonomt hĂ„ndtere uventede endringer i karakteren pĂ„ inndataene og de simulerte fenomenene.
La oss se nÊrmere pÄ plattformens AI/ML-funksjonalitet i InterSystems IRIS, med eksempelet av en faktisk eksisterende prototype.
I den nedenstĂ„ende diagram, til venstre pĂ„ slidshowet, vises en del af forretningsprocessen, der implementerer udfĂžrelsen af scripts i Python og R. I midten vises visuelle logs over udfĂžrelsen af nogle af disse scripts, henholdsvis i Python og R. Umiddelbart efter dem vises eksempler pĂ„ indhold pĂ„ begge sprog, der sendes til udfĂžrelse i de respektive miljĂžer. Til hĂžjre i slutningen vises visualiseringer baseret pĂ„ resultaterne af scriptudfĂžrelsen. Visualiseringerne pĂ„ toppen er lavet i IRIS Analytics (data hentet fra Python til InterSystems IRIS dataplatform og sendt til dashboardet ved hjĂŠlp af platformens vĂŠrktĂžjer), mens visualiseringerne nederst er lavet direkte i R arbejdssessionen og gemt som grafiske filer. Et vigtigt aspekt: det prĂŠsenterede fragment i prototypen er ansvarligt for trĂŠningen af modellen (klassificering af tilstandsdata for udstyr) baseret pĂ„ data, der strĂžmmer ind i realtid fra udstyrs-simulatoren, efter anmodning fra kvalitetsmonitoren, som observerer klassificeringen under anvendelsen af modellen. Implementeringen af AI/ML-lĂžsningen som et sĂŠt af interagerende processer (âagenterâ) vil blive diskuteret senere.

Figur 12 Interaktion med Python, R og Julia i InterSystems IRIS
Platformprocesserne (ogsĂ„ kaldet "forretningsprocesser", "analytiske processer", "pipelines" osv. â afhĂŠngig af konteksten) redigeres primĂŠrt i den grafiske forretningsproceseditor i selve platformen, sĂ„ledes at der samtidig skabes bĂ„de dens blokdiagram og den tilsvarende AI/ML-mekanisme (programkode). NĂ„r vi siger, at "der opnĂ„s en AI/ML-mekanisme", menes der oprindeligt hybriditet (inden for en enkelt proces): indholdet pĂ„ sprog for matematiske modeller lever side om side med indholdet pĂ„ SQL (inklusive udvidelser fra ), pĂ„ InterSystems ObjectScript, med andre stĂžttede sprĂ„k. Dessuten gir plattformsprosessen svĂŠrt brede muligheter for «tegning» i form av hierarkisk innlagte fragmenter (som vist i eksemplet i diagrammet nedenfor), noe som gjĂžr det mulig Ă„ organisere selv svĂŠrt kompleks innhold effektivt, uten Ă„ «falle ut» av det grafiske formatet (i «ikke-grafiske» metoder/kategorier/prosedyrer osv.). Det vil si at om nĂždvendig (og det forventes i de fleste prosjekter) kan absolutt alle AI/ML-lĂžsninger implementeres i et grafisk selvkommenterende format. Vi oppfordrer til Ă„ merke seg at i den sentrale delen av diagrammet nedenfor, som presenterer et hĂžyere «nivĂ„ av innbygging», er det synlig at i tillegg til selve arbeidet med Ă„ trene modellen (ved hjelp av Python og R), legges det ogsĂ„ til analyse av den sĂ„kalte ROC-kurven til den trente modellen, som lar oss visuelt (og beregningsmessig ogsĂ„) vurdere kvaliteten pĂ„ treningen â og denne analysen er implementert pĂ„ sprĂ„ket Julia (kjĂžres i henhold til det, i matmiljĂžet Julia).

Figur 13 Visuell komposisjonsmiljĂž for AI/ML-lĂžsninger i InterSystems IRIS
Som allerede nevnt, vil den innledende utviklingen og (i noen tilfeller) tilpasningen av allerede implementerte AI/ML-mekanismer pĂ„ plattformen bli/kanskje bli utfĂžrt utenfor plattformen i Jupyter-redigereren. I diagrammet nedenfor ser vi et eksempel pĂ„ tilpasning av eksisterende plattformprosess (den samme som i diagrammet ovenfor) â slik ser den delen ut i Jupyter som er ansvarlig for Ă„ trene modellen. Innholdet i Python-sprĂ„ket er tilgjengelig for redigering, debugging, samt utskrift av grafikk direkte i Jupyter. Endringer (om nĂždvendig) kan gjĂžres med Ăžyeblikkelig synkronisering til plattformprosessen, inkludert dens produksjonsversjon. Tilsvarende kan nytt innhold overfĂžres til plattformen (en ny plattformprosess opprettes automatisk).

Figur 14 Bruk av Jupyter Notebook for redigering av AI/ML-mekanismen i InterSystems IRIS
Plattformprosessens tilpasning kan utfÞres ikke bare i grafisk eller bÊrbar format, men ogsÄ i en «total» IDE (Integrated Development Environment) format. IDE-er som IRIS Studio (den native IRIS-studioen), Visual Studio Code (InterSystems IRIS-utvidelsen for VSCode) og Eclipse (Atelier-pluginen) fungerer som slike IDE-er. I en rekke tilfeller kan utviklerteamet bruke alle tre IDE-er samtidig. Diagrammet nedenfor viser et eksempel pÄ redigering av den samme prosessen i IRIS-studio, Visual Studio Code, og Eclipse. All innhold er tilgjengelig for redigering: bÄde Python/R/Julia/SQL, ObjectScript, og forretningsprosessen.

Figur 15 Utvikling av InterSystems IRIS forretningsprosess i forskjellige IDE-er
De verktĂžyene som beskriver og utfĂžrer forretningsprosesser i InterSystems IRIS pĂ„ sprĂ„ket Business Process Language (BPL) fortjener spesiell omtale. BPL gir muligheter for bruk av «klare integrasjonskomponenter» (activities) i forretningsprosessene â noe som gir fullstendig grunn til Ă„ pĂ„stĂ„ at InterSystems IRIS har implementert «kontinuerlig integrasjon». De klare forretningsprosesskomponentene (aktiviteter og relasjoner mellom dem) fungerer som en kraftig akselerator for utviklingen av AI/ML-lĂžsninger. Og ikke bare utvikling: takket vĂŠre aktivitetene og relasjonene mellom dem oppstĂ„r det et «autonomt ledelseslag» over de fragmenterte AI/ML-utviklingene og mekanismene, som kan ta beslutninger i henhold til situasjonen, i sanntid.

Figur 16 Klare forretningsprosesskomponenter for kontinuerlig integrasjon (CI) pÄ InterSystems IRIS-plattformen
Konseptet med agent-systemer (ogsÄ kjent som «multi-agent-systemer») har sterke posisjoner innen robotisering, og InterSystems IRIS-plattformen stÞtter det organisk gjennom konstruktet «produkt-prosess». I tillegg til de ubegrensede mulighetene for Ä «fylle» hver prosess med nÞdvendig funksjonalitet for den generelle lÞsningen, gir det Ä gi plattformprosessystemet egenskapen «agentlighet» muligheten til Ä lage effektive lÞsninger for svÊrt ustabile simulerte fenomener (atferd av sosiale/biosystemer, delvis observerbare teknologiske prosesser, osv.).

Figur 16 Drift av AI/ML-lĂžsning som et agent-system for forretningsprosesser i InterSystems IRIS
Vi fortsetter vÄr gjennomgang av InterSystems IRIS med en diskusjon om den praktiske bruken av plattformen for Ä lÞse hele klasser av sanntidsoppgaver (en ganske detaljert introduksjon til noen av de beste praksisene for plattformbasert AI/ML pÄ InterSystems IRIS finnes i en av vÄre tidligere artikler. ).
I kjĂžlvannet av den forrige diagrammet fĂžlger en mer detaljert oversikt over agentsystemet. Diagrammet viser den samme prototypen, og alle fire agentprosessene er skjematisk tegnet, med relasjonene mellom dem: GENERATOR â som hĂ„ndterer datagenerering fra utstyrs sensorer, BUFFER â som administrerer datakĂžer, ANALYZER â som utfĂžrer selve maskinlĂŠringen, MONITOR â som overvĂ„ker kvaliteten pĂ„ maskinlĂŠringen og gir signal om behovet for gjenopplĂŠring av modellen.

Figur 17 Komposisjon av AI/ML-lĂžsningen som et agentsystem for forretningsprosesser i InterSystems IRIS
I diagrammet nedenfor er det illustrert den autonome funksjonen til en annen robotprototyp (gjenkjenning av den emosjonelle tonen i tekster) over en viss tidsperiode. Ăverst vises utviklingen av kvaliteten pĂ„ modellens lĂŠring (kvaliteten Ăžker), nederst er dynamikken i kvaliteten pĂ„ modellens anvendelse og fakta om gjenopplĂŠring (rĂžde striper). Som det fremgĂ„r, har lĂžsningen effektivt og autonomt lĂŠrt seg selv, og fungerer pĂ„ et angitt kvalitetsnivĂ„ (kvalitetsmĂ„let faller ikke under 80 %).

Figur 18 Kontinuerlig (selv-)lÊring (CT) pÄ InterSystems IRIS-plattformen
Vi har ogsÄ nevnt «auto-ML» tidligere, men pÄ diagrammet nedenfor vises bruken av denne funksjonen i detalj, med et annet prototypeeksempel. I det grafiske diagrammet av forretningsprosessfragmentet vises aktiviteten som initierer modelleringen i H2O-stakken, samt resultatene av denne modelleringen (den klare dominansen av den oppnÄdde modellen over «hÄndlagde» modeller, ifÞlge den sammenlignende ROC-kurven, samt automatisert identifisering av «de mest innflytelsesrike variablene» fra de tilgjengelige i den opprinnelige datamengden). Et viktig poeng her er tids- og ekspertressursbesparelsen som oppnÄs gjennom «auto-ML»: det som vÄr plattformprosess oppnÄr pÄ et halvt minutt (Ä finne og trene den optimale modellen), kan ta en ekspert fra en uke til en mÄned.

Figur 19 Integrasjon av «auto-ML» i AI/ML-lÞsningen pÄ InterSystems IRIS-plattformen
Diagrammet under forstyrrer litt klimakset, men det er et godt alternativ for Ă„ avslutte fortellingen om klassene av oppgaver som kan lĂžses i sanntid: vi minner om at til tross for alle mulighetene til InterSystems IRIS-plattformen, er det ikke obligatorisk Ă„ trene modeller under dens ledelse. Plattformen kan motta en sĂ„kalt PMML-spesifikasjon for en modell som er trent i et verktĂžy som ikke er under plattformens kontroll â og bruke denne modellen i sanntid fra Ăžyeblikket den importeres. . Det er viktig Ă„ merke seg at langt fra alle AI/ML-artifakter kan reduseres til PMML-spesifikasjoner, selv om de fleste av de vanligste artifaktene lar seg gjĂžre. Dermed har InterSystems IRIS-plattformen en «Äpen kontur» og betyr ikke «plattformslaveri» for brukerne.

Figur 20 Integrasjon av «auto-ML» i AI/ML-lÞsningen pÄ InterSystems IRIS-plattformen
La oss liste opp flere plattformfordeler ved InterSystems IRIS (for klarhet, relatert til styring av teknologiske prosesser), som er svĂŠrt viktige ved automatisering av kunstig intelligens og maskinlĂŠring i sanntid:
- Avanserte integrasjonsverktĂžy med alle kilder og forbrukere av data (DCS/SCADA, utstyr, vedlikehold, ERP osv.)
- Innebygd for high-performance hybrid transaction/analytical processing (HTAP) of any volume of technological process data
- Development tools for continuous deployment of AI/ML real-time solutions based on Python, R, Julia
- Adaptive business processes for continuous integration and (self-)learning of AI/ML real-time solutions
- Embedded Business Intelligence tools for data visualization of technological processes and results of AI/ML solutions
- to deliver the results of AI/ML solutions to automated control systems/SCADA, information-analytical systems, alert distributions, etc.
AI/ML solutions on the InterSystems IRIS platform easily integrate into existing IT infrastructures. The InterSystems IRIS platform ensures high reliability for AI/ML solutions by supporting fault-tolerant and disaster-resistant configurations and flexible deployment in virtual environments, physical servers, private and public clouds, and Docker containers.
Thus, InterSystems IRIS is a universal platform for real-time AI/ML computing. The versatility of our platform is practically confirmed by the absence of de facto limits on the complexity of implementable computations, with InterSystems IRIS able to concurrently (in real-time) process scenarios from various industries, and its exceptional adaptability to any functions and mechanisms of the platform to meet specific user needs.

Figure 21 InterSystems IRIS â a universal platform for real-time AI/ML computing
For a more substantive interaction with those among our readers who are interested in the material presented here, we recommend not to limit yourself to just reading it and to continue the dialogue in person. We are ready to assist in formulating real-time AI/ML scenarios specific to your company, conduct joint prototyping on the InterSystems IRIS platform, and create and implement a roadmap for integrating artificial intelligence and machine learning into your production and management processes. The contact email address of our AI/ML expert group is .
Kilde: habr.com
