InterSystems IRIS er en universell sanntids AI/ML-plattform

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

Sanntids AI/ML Computing Challenges

La oss starte med eksempler fra erfaringene fra datavitenskapspraksis hos InterSystems:

• Den "lastede" kjøperportalen er koblet til et online anbefalingssystem. Restrukturering av kampanjer i skalaen til detaljhandelsnettverket kommer (for eksempel, i stedet for en "flat" linje med kampanjer, vil nå matrisen "segment-taktikk" bli brukt). Hva skjer med anbefalere? Hva skjer med innsending og oppdatering av data til anbefalingsmekanismen (volumet av inndata har økt med 25000 XNUMX ganger)? Hva skjer med utviklingen av anbefalinger (behovet for en tusen ganger reduksjon i filtreringsterskelen for anbefalingsregler på grunn av en tusen ganger økning i antall og "rekkevidde")?
• Det er et system for å overvåke sannsynligheten for utvikling av defekter i utstyrsnoder. Et prosesskontrollsystem ble koblet til overvåkingssystemet, som sendte tusenvis av prosessparametere hvert sekund. Hva skjer med overvåkingssystemet som tidligere jobbet med "manuelle prøver" (er det i stand til å gi andre til sekund sannsynlighetsovervåking)? Hva vil skje hvis en ny blokk med flere hundre kolonner vises i inngangsdataene med avlesningene av sensorer som nylig er lagt til prosesskontrollsystemet (om og hvor lenge vil det være nødvendig å stoppe overvåkingssystemet for å inkludere data fra nye sensorer i analyse)?
• Et sett med AI/ML-mekanismer (anbefalende, overvåking, prediktive) er laget ved å bruke resultatene av hverandres arbeid. Hvor mange dugnadstimer kreves månedlig for å tilpasse driften av dette komplekset til endringer i inndataene? Hva er den generelle "nedgangen" som støttes av beslutningskomplekset (hyppighet for forekomst av ny støtteinformasjon i det i forhold til hyppigheten av forekomst av nye inputdata)?

Ved å oppsummere disse og mange andre eksempler kom vi til formuleringen av utfordringene som oppstår når vi går over til bruk av maskinlæring og sanntids kunstig intelligensmekanismer:

• Er vi fornøyd med hastigheten på opprettelse og tilpasning (til den endrede situasjonen) av AI/ML-utviklingen i selskapet vårt?
• I hvilken grad støtter AI/ML-løsningene vi bruker virksomhetsstyring i sanntid?
• Er AI/ML-løsningene vi bruker i stand til å uavhengig (uten utviklere) tilpasse seg endringer i data og forretningsledelsespraksis?

Artikkelen vår er en detaljert oversikt over egenskapene til InterSystems IRIS-plattformen når det gjelder universell støtte for distribusjon av AI/ML-mekanismer, montering (integrasjon) av AI/ML-løsninger og opplæring (testing) av AI/ML-løsninger på intensive data flyter. Vi vil gå til markedsundersøkelser, casestudier av AI/ML-løsninger og konseptuelle aspekter av det vi omtaler som en sanntids AI/ML-plattform i denne artikkelen.

Det vi vet fra undersøkelser: sanntidsapplikasjoner

Funn undersøkelsenutført blant rundt 800 IT-fagfolk i 2019 av Lightbend taler for seg selv:

Figur 1 Ledende forbrukere av sanntidsdata

La oss sitere fragmentene av rapporten om resultatene av denne undersøkelsen som er viktige for oss i vår oversettelse:

"...Trender i populariteten til dataflytintegrasjonsverktøy og samtidig støtte for containerisert databehandling gir et synergistisk svar på markedets etterspørsel etter et mer effektivt, rasjonelt, dynamisk forslag til effektive løsninger. Datastrømmer gjør at informasjon kan overføres raskere enn tradisjonelle pakkedata. I tillegg kommer muligheten til raskt å anvende beregningsmetoder, som AI/ML-baserte anbefalinger, for å skape konkurransefortrinn gjennom økt kundetilfredshet. Kappløpet om smidighet påvirker også alle roller i DevOps-paradigmet – noe som gjør applikasjonsutvikling og distribusjon mer effektiv. … Åtte hundre og fire IT-fagfolk ga informasjon om bruken av dataflyt i organisasjonene deres. Respondentene var hovedsakelig lokalisert i vestlige land (41 % i Europa og 37 % i Nord-Amerika) og var nesten jevnt fordelt mellom små, mellomstore og store selskaper. …

… Kunstig intelligens er ikke hype. XNUMX prosent av de som allerede bruker dataflytbehandling i produktive AI/ML-applikasjoner bekrefter at deres bruk i AI/ML vil se de største gevinstene neste år (sammenlignet med andre applikasjoner).

• Ifølge flertallet av respondentene vil bruken av datastrømmer i AI/ML-scenarier få den største økningen det neste året.
• Applikasjoner innen AI/ML vil vokse ikke bare gjennom relativt nye typer scenarier, men også gjennom tradisjonelle scenarier, der sanntidsdata blir stadig mer brukt.
• I tillegg til AI/ML er entusiasmenivået blant brukere av IoT-datapipelines imponerende – 48 % av de som allerede har integrert IoT-data sier at implementeringen av scenarier på disse dataene vil få en betydelig økning i nær fremtid. … »

Fra denne ganske interessante undersøkelsen kan man se at oppfatningen av scenarier for maskinlæring og kunstig intelligens som ledere innen forbruk av datastrømmer allerede er "på vei". Men oppfatningen av sanntids AI / ML gjennom DevOps-optikk blir en like viktig observasjon: her kan vi allerede begynne å snakke om transformasjonen av den fortsatt dominerende kulturen "engangs AI / ML med et fullt tilgjengelig datasett".

Sanntids AI/ML-plattformkonsept

En typisk applikasjon for sanntids AI/ML er i produksjonsprosesskontroll. På sitt eksempel og under hensyntagen til tidligere refleksjoner, vil vi formulere konseptet med en sanntids AI / ML-plattform.
Bruken av kunstig intelligens og maskinlæring i prosesskontroll har en rekke funksjoner:

• Data om tilstanden til den teknologiske prosessen mottas intensivt: med høy frekvens og over et bredt spekter av parametere (opptil titusenvis av parameterverdier sendt per sekund fra prosesskontrollsystemet)
• Data om påvisning av defekter, for ikke å nevne data om deres utvikling, tvert imot, er knappe og uregelmessige, preget av utilstrekkelig typing av defekter og deres lokalisering i tid (ofte representert av poster på papir)
• Fra et praktisk synspunkt er bare "relevansvinduet" til de innledende dataene tilgjengelig for opplæring og bruk av modeller, som gjenspeiler dynamikken i den teknologiske prosessen for et rimelig glideintervall, og slutter med de siste leste verdiene til prosessparametrene

Disse funksjonene tvinger oss, i tillegg til å motta og grunnleggende sanntidsbehandling av intens "bredbåndsinngang" fra prosessen, til å utføre (parallelt) applikasjonen, opplæringen og kvalitetskontrollen av resultatene av arbeidet med AI / ML-modeller - også i sanntid. "Rammen" som våre modeller "ser" i det skyvevinduet av relevans er i konstant endring - og med den endres også kvaliteten på resultatene av arbeidet til AI / ML-modeller som er trent på en av "rammene" i fortiden. . Hvis kvaliteten på resultatene av arbeidet med AI / ML-modeller forringes (for eksempel: verdien av "alarm-norm"-klassifiseringsfeilen har gått utover grensene vi har definert), bør omskolering av modeller startes automatisk på en mer relevant "ramme" - og valget av øyeblikket for å starte omskolering av modeller bør ta hensyn til hvordan varigheten av selve treningen, samt dynamikken i forringelse av kvaliteten på den nåværende versjonen av modellene (siden de nåværende versjonene av modellene fortsetter å brukes mens modellene trenes, og til deres "nyopplærte" versjoner er generert).

InterSystems IRIS har nøkkelplattformfunksjoner for å muliggjøre sanntids AI/ML-løsninger for prosesskontroll. Disse mulighetene kan deles inn i tre hovedgrupper:

• Kontinuerlig distribusjon (Continuous Deployment / Delivery, CD) av nye eller tilpassede eksisterende AI / ML-mekanismer til en produktiv løsning som opererer i sanntid på InterSystems IRIS-plattformen
• Kontinuerlig integrasjon (CI) til en enkelt produktiv løsning av innkommende prosessdatastrømmer, datakøer for applikasjon / opplæring / kvalitetskontroll av AI / ML-mekanismer og data / kode / kontrollutveksling med matematiske modelleringsmiljøer, som er orkestrert i sanntid InterSystems IRIS-plattform
• Kontinuerlig (selv)læring (kontinuerlig opplæring, CT) av AI/ML-mekanismer utført i matematiske modelleringsmiljøer ved bruk av data, kode og kontrollhandlinger ("beslutninger tatt") overført av InterSystems IRIS-plattformen

Klassifiseringen av plattformevner i forhold til maskinlæring og kunstig intelligens i nettopp slike grupper er ikke tilfeldig. La oss sitere det metodiske utgivelse Google, som gir et konseptuelt grunnlag for denne klassifiseringen, i vår oversettelse:

«... DevOps-konseptet, som er populært i disse dager, dekker utvikling og drift av storskala informasjonssystemer. Fordelene med å implementere dette konseptet er reduksjonen i varigheten av utviklingssyklusene, akselerasjonen av utviklingsdistribusjon, fleksibiliteten til utgivelsesplanlegging. For å oppnå disse fordelene, innebærer DevOps implementering av minst to praksiser:

• Kontinuerlig integrasjon (CI)
• Kontinuerlig levering (CD)

Disse fremgangsmåtene gjelder også for AI/ML-plattformer for å sikre robuste og effektive bygg av produktive AI/ML-løsninger.

AI/ML-plattformer skiller seg fra andre informasjonssystemer på følgende aspekter:

• Teamkompetanse: Når du bygger en AI/ML-løsning, inkluderer teamet vanligvis dataforskere eller dataforskere som utfører dataanalyse, modellutvikling og validering. Disse teammedlemmene er kanskje ikke profesjonelle utviklere av produktiv kode.
• Utvikling: AI/ML-mekanismer er eksperimentelle. For å løse problemet på en mest mulig effektiv måte kreves det å sortere gjennom ulike kombinasjoner av inngangsvariabler, algoritmer, modelleringsmetoder og modellparametere. Kompleksiteten i et slikt søk ligger i å spore "hva som fungerte / ikke fungerte", å sikre reproduserbarhet av episoder, og å generalisere utviklingen for gjentatte implementeringer.
• Testing: Testing av AI/ML-mekanismer krever et større utvalg av tester enn de fleste andre utviklinger. I tillegg til typiske enhetstester og integrasjonstester, testes validiteten til dataene og kvaliteten på resultatene ved bruk av modellen på trenings- og kontrollprøver.
• Utrulling: Utrulling av AI/ML-løsninger er ikke begrenset til prediktive tjenester som bruker en gang opplært modell. AI/ML-løsninger er bygget rundt flertrinns rørledninger som utfører automatisert opplæring og bruk av modeller. Utplassering av slike rørledninger innebærer å automatisere ikke-trivielle trinn som tradisjonelt utføres manuelt av dataforskere for å kunne trene og teste modeller.
• Produktiv: AI/ML-motorer kan mangle ytelse, ikke bare på grunn av ineffektiv programmering, men også på grunn av den stadig skiftende karakteren til inndataene. Med andre ord kan ytelsen til AI/ML-mekanismer forringes på grunn av et bredere spekter av årsaker enn ytelsen til konvensjonell utvikling. Dette resulterer i behovet for å overvåke (online) ytelsen til våre AI/ML-motorer, og sende varsler eller avvise resultater hvis ytelsen ikke lever opp til forventningene.

AI/ML-plattformer ligner på andre informasjonssystemer ved at begge krever kontinuerlig kodeintegrasjon med versjonskontroll, enhetstesting, integrasjonstesting, kontinuerlig utviklingsdistribusjon. Men når det gjelder AI/ML, er det noen viktige forskjeller:

• CI (Continuous Integration) er ikke lenger begrenset til å teste og validere koden til distribuerte komponenter – den inkluderer også testing og validering av data og AI/ML-modeller.
• CD (Continuous Delivery / Deployment, continuous deployment) er ikke begrenset til å skrive og frigi pakker eller tjenester, men innebærer en plattform for å komponere, lære og bruke AI/ML-løsninger.
• CT (Continuous Training, continuous learning) - et nytt element [ca. av forfatteren av artikkelen: et nytt element i forhold til det tradisjonelle konseptet med DevOps, der CT vanligvis er kontinuerlig testing], iboende i AI/ML-plattformer, ansvarlig for autonom styring av mekanismene for læring og anvendelse av AI/ML-modeller. ..."

Vi kan slå fast at maskinlæring og kunstig intelligens som arbeider med sanntidsdata krever et bredere sett med verktøy og kompetanse (fra kodeutvikling til orkestrering av matematiske modelleringsmiljøer), tettere integrasjon mellom alle funksjons- og fagområder, mer effektiv organisering av menneskelige og maskinressurser.

Sanntidsscenario: Gjenkjenne utviklingen av defekter i fôrpumper

Fortsett å bruke feltet prosesskontroll som et eksempel, vurder en spesifikk oppgave (allerede nevnt av oss helt i begynnelsen): det er nødvendig å gi sanntidsovervåking av utviklingen av defekter i pumper basert på flyten av prosessparametere og rapporter fra vedlikeholdspersonell om oppdagede mangler.

Figur 2 Formulering av oppgaven med å overvåke utviklingen av defekter

Det særegne ved flertallet av oppgavene som er satt på denne måten i praksis er at regelmessigheten og effektiviteten av datamottak (APCS) bør vurderes på bakgrunn av episodisk og uregelmessig forekomst (og registrering) av ulike typer feil. Med andre ord: dataene fra prosesskontrollsystemet kommer en gang i sekundet riktig-nøyaktig, og defekter registreres med en uutslettelig blyant med dato i den generelle notatboken på verkstedet (for eksempel: "12.01 - lekkasje inn i dekselet fra siden av det tredje lageret").

Dermed er det mulig å supplere formuleringen av problemet med følgende viktige begrensning: vi har bare én "etikett" på en defekt av en bestemt type (dvs. et eksempel på en defekt av en bestemt type er representert av data fra prosesskontrollsystem for en bestemt dato - og vi har ikke flere eksempler på en feil av denne typen). Denne begrensningen tar oss umiddelbart utenfor rekkevidden av klassisk maskinlæring (overvåket læring), som det burde være mange "etiketter" for.

Figur 3 Foredling av oppgaven med å overvåke utviklingen av feil

Kan vi på en eller annen måte "multiplicere" den eneste "etiketten" til vår disposisjon? Ja vi kan. Den nåværende tilstanden til pumpen er preget av graden av likhet med registrerte feil. Selv uten bruk av kvantitative metoder, på nivå med visuell persepsjon, observere dynamikken til dataverdiene som kommer fra prosesskontrollsystemet, kan du allerede lære mye:

Figur 4 Dynamikk til pumpens tilstand mot bakgrunnen av "merket" til en defekt av en gitt type

Men visuell persepsjon (i hvert fall foreløpig) er ikke den mest passende generatoren av "tags" i vårt raskt skiftende scenario. Vi vil evaluere likheten mellom den nåværende tilstanden til pumpen og de rapporterte defektene ved hjelp av en statistisk test.

Figur 5 Bruk av en statistisk test på innkommende data mot bakgrunnen av en "etikett" av en defekt

Den statistiske testen bestemmer sannsynligheten for at postene med verdiene til de teknologiske prosessparametrene i "flytpakken" mottatt fra prosesskontrollsystemet ligner på "etikett"-postene for en viss type defekt. Sannsynlighetsverdien beregnet som et resultat av å bruke en statistisk test (statistisk likhetsindeks) konverteres til en verdi på 0 eller 1, og blir en "etikett" for maskinlæring i hver spesifikk post i likhetspakken. Det vil si at etter å ha behandlet den nylig mottatte pakken med pumpestatusposter med en statistisk test, har vi muligheten til å (a) legge denne pakken til treningsprøven for å trene AI/ML-modellen og (b) overvåke kvaliteten på gjeldende versjon av modellen når den brukes på denne pakken.

Figur 6 Bruke en maskinlæringsmodell på innkommende data mot bakgrunnen av en "etikett" av en defekt

I en av våre tidligere webinarer vi viser og forklarer hvordan InterSystems IRIS-plattformen lar deg implementere enhver AI/ML-mekanisme i form av kontinuerlig utføring av forretningsprosesser som kontrollerer påliteligheten til simuleringsresultater og tilpasser modellparametere. Når vi implementerer prototypen av scenarioet vårt med pumper, bruker vi all InterSystems IRIS-funksjonalitet som ble presentert under webinaret - implementerer i analysatorprosessen som en del av løsningen vår, ikke klassisk overvåket læring, men heller forsterkende læring, som automatisk kontrollerer prøven for opplæring modeller. Registreringer plasseres i treningsutvalget der det oppstår en "deteksjonskonsensus" etter å ha brukt både den statistiske testen og den gjeldende versjonen av modellen - dvs. både den statistiske testen (etter transformasjonen av likhetsindeksen til 0 eller 1), og modell produserte et resultat på slike poster 1. Med en ny opplæring av modellen, under valideringen (den nylig trente modellen brukes på sin egen treningsprøve, med en foreløpig anvendelse av en statistisk test på den), postene som "gjorde ikke holde" resultatet 1 etter behandling av den statistiske testen (på grunn av den konstante tilstedeværelsen i treningen, blir prøven av poster fra den originale "etiketten" av defekten) fjernet fra treningsprøven, og den nye versjonen av modellen lærer fra "etiketten" til defekten pluss de "holdte" postene fra strømmen.

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

Hvis det er behov for en slags «second opinion» om kvaliteten på deteksjonen som oppnås ved lokal databehandling i InterSystems IRIS, opprettes en rådgiverprosess for å utføre opplæringsbrukende modeller på et kontrolldatasett ved bruk av skytjenester (for eksempel Microsoft Azure , Amazon Web Services , Google Cloud Platform osv.):

Figur 8 Second Opinion fra Microsoft Azure orkestrert av InterSystems IRIS

Prototypen av vårt scenario i InterSystems IRIS er laget i form av et agentbasert system av analytiske prosesser som samhandler med utstyrsobjektet (pumpen), matematiske modelleringsmiljøer (Python, R og Julia), og gir selvlæring av alle involverte AI/ML-mekanismer - på sanntidsdatastrømmer.

Figur 9 Hovedfunksjonalitet til sanntids AI/ML-løsning i InterSystems IRIS

Det praktiske resultatet av prototypen vår:

• Defektmønster gjenkjent av modellen (12. januar):

• En utviklingsfeil gjenkjent av modellen, som ikke var inkludert i prøven (11. september, selve defekten ble konstatert av reparasjonsteamet bare to dager senere - 13. september):

Simulering på reelle data som inneholder flere episoder av samme defekt viste at løsningen vår, implementert på InterSystems IRIS-plattformen, lar oss oppdage utviklingen av defekter av denne typen flere dager før de oppdages av reparasjonsteamet.

InterSystems IRIS - universell sanntids AI/ML databehandlingsplattform

InterSystems IRIS-plattformen forenkler utvikling, distribusjon og drift av sanntidsdataløsninger. InterSystems IRIS er i stand til å utføre transaksjons- og analytisk databehandling samtidig; opprettholde synkroniserte visninger av data i samsvar med flere modeller (inkludert relasjonelle, hierarkiske, objekt og dokument); fungere som en integrasjonsplattform for et bredt spekter av datakilder og individuelle applikasjoner; gi avansert sanntidsanalyse på strukturerte og ustrukturerte data. InterSystems IRIS tilbyr også mekanismer for bruk av eksterne analytiske verktøy, gir fleksibiliteten til å kombinere hosting i skyen og på lokale servere.

Applikasjoner bygget på InterSystems IRIS-plattformen har blitt distribuert på tvers av bransjer, og hjelper bedrifter med å oppnå betydelig økonomisk verdi fra et strategisk og operasjonelt perspektiv, forbedret beslutningstaking og tette gapet mellom hendelse, analyse og handling.

Figur 10 InterSystems IRIS-arkitektur i sammenheng med sanntids AI/ML

I likhet med forrige diagram, kombinerer diagrammet nedenfor det nye "koordinatsystemet" (CD/CI/CT) med informasjonsflyten mellom plattformarbeidselementer. Visualisering begynner med CD-makromekanismen og fortsetter med CI- og CT-makromekanismene.

Figur 11 Skjema for informasjonsflyt mellom AI/ML-elementer i InterSystems IRIS-plattformen

Essensen av CD-mekanismen i InterSystems IRIS: plattformbrukere (AI/ML-løsningsutviklere) tilpasser eksisterende og/eller skaper nye AI/ML-utviklinger ved å bruke en spesialisert AI/ML-mekanismekoderedigerer: Jupyter (fullt navn: Jupyter Notebook; også, For korthets skyld kalles dokumenter som er opprettet i denne editoren noen ganger). I Jupyter har en utvikler mulighet til å skrive, feilsøke og verifisere ytelsen (inkludert ved hjelp av grafikk) til en spesifikk AI/ML-utvikling før den vert («distribuert») i InterSystems IRIS. Det er klart at en ny utvikling opprettet på denne måten kun vil motta grunnleggende feilsøking (siden spesielt Jupyter ikke fungerer med sanntidsdatastrømmer) - dette er i rekkefølgen av tingene, fordi hovedresultatet av utviklingen i Jupyter er bekreftelse på den grunnleggende funksjonen til en separat AI / ML-mekanisme ("viser det forventede resultatet på dataprøven"). Tilsvarende kan en mekanisme som allerede er plassert i plattformen (se følgende makromekanismer) før feilsøking i Jupyter kreve en "rullback" til "pre-plattform"-skjemaet (lese data fra filer, arbeide med data gjennom xDBC i stedet for tabeller, direkte interaksjon med globaler - flerdimensjonale datamatriser InterSystems IRIS - etc.).

Et viktig aspekt ved CD-implementering i InterSystems IRIS er at toveis integrasjon er implementert mellom plattformen og Jupyter, som lar deg overføre til plattformen (og videre behandle i plattformen) innhold i Python, R og Julia (alle tre er programmeringsspråk i de tilsvarende ledende åpen kildekodemiljøene for matematisk modellering). Dermed har AI/ML-innholdsutviklere muligheten til å "kontinuerlig distribuere" dette innholdet til plattformen, ved å jobbe i deres velkjente Jupyter-editor, med kjente biblioteker tilgjengelig i Python, R, Julia, og utføre grunnleggende feilsøking (om nødvendig) utenfor plattformen .

La oss gå videre til makromekanismen til CI i InterSystems IRIS. Diagrammet viser makroprosessen til "sanntidsroboten" (et kompleks av datastrukturer, forretningsprosesser og kodefragmenter orkestrert av dem på språkene til matter og ObjectScript-språket - det opprinnelige utviklingsspråket til InterSystems IRIS). Oppgaven til denne makroprosessen er å opprettholde datakøene som er nødvendige for driften av AI / ML-mekanismer (basert på datastrømmer overført til plattformen i sanntid), ta beslutninger om applikasjonssekvensen og "rekkevidden" til AI / ML-mekanismer (de er også "matematiske algoritmer", "modeller", etc. - kan kalles annerledes avhengig av implementeringsspesifikasjonene og terminologiske preferanser), hold datastrukturer oppdatert for å analysere resultatene av arbeidet med AI / ML-mekanismer (kuber, tabeller, flerdimensjonale datamatriser, etc.) osv. - for rapporter, dashbord osv.).

Et viktig aspekt ved implementeringen av CI i InterSystems IRIS er at toveis integrasjon er implementert mellom plattformen og matematiske modelleringsmiljøer, som gjør det mulig å utføre innholdet som er vert på plattformen i Python, R og Julia i deres respektive miljøer med retur av utførelsesresultater . Denne integrasjonen er implementert i både "terminalmodus" (dvs. AI/ML-innhold er formulert som ObjectScript-kode som kaller mats) og "forretningsprosessmodus" (dvs. AI/ML-innhold er formulert som en forretningsprosess ved hjelp av en grafisk editor, eller noen ganger ved å bruke Jupyter, eller ved å bruke en IDE - IRIS Studio, Eclipse, Visual Studio Code). Redigerbarheten til forretningsprosesser i Jupyter reflekteres av forholdet mellom IRIS på CI-nivå og Jupyter på CD-nivå. En mer detaljert oversikt over integrasjon med matematiske modelleringsmiljøer er gitt nedenfor. På dette stadiet er det etter vår mening all grunn til å fikse tilstedeværelsen i plattformen av alle nødvendige verktøy for å implementere den "kontinuerlige integrasjonen" av AI / ML-utviklingen (som kommer fra "kontinuerlig distribusjon") til sanntids AI / ML løsninger.

Og hovedmakromekanismen: CT. Uten den vil det ikke være noen AI / ML-plattform (selv om "sanntid" vil bli implementert gjennom CD / CI). Essensen av CT er plattformens arbeid med "artefakter" av maskinlæring og kunstig intelligens direkte i arbeidsøktene til matematiske modelleringsmiljøer: modeller, distribusjonstabeller, matrisevektorer, lag med nevrale nettverk, etc. Dette "arbeidet" består i de fleste tilfeller i å lage de nevnte artefaktene i miljøene (når det for eksempel gjelder modeller, består "skaping" av å angi spesifikasjonen til modellen og det påfølgende utvalget av verdiene til dens parametere - den såkalte "opplæringen" av modellen), deres anvendelse (for modeller: bruk dem til å beregne "modell"-verdier av målvariabler - prognoser, tilhørighet til en kategori, sannsynligheten for at en hendelse inntreffer, etc. ) og forbedre allerede opprettede og anvendte artefakter (for eksempel redefinere settet med modellinndatavariabler basert på resultatene av applikasjonen – for å øke prediksjonsnøyaktigheten, som et alternativ). Nøkkelpunktet for å forstå rollen til CT er dens "abstraksjon" fra realitetene til CD og CI: CT vil implementere alle artefakter, med fokus på de beregningsmessige og matematiske spesifikasjonene til AI/ML-løsningen innenfor egenskapene gitt av spesifikke miljøer . Ansvaret for å «levere inndata» og «levere resultater» vil være CD og CIs ansvar.

Et viktig aspekt ved CT-implementering i InterSystems IRIS: ved å bruke integrasjonen med matematiske modelleringsmiljøer som allerede er nevnt ovenfor, har plattformen muligheten til å trekke ut de samme artefaktene fra arbeidsøkter som kjører under dens kontroll i miljøene og (viktigst) gjøre dem om til plattformer dataobjekter. For eksempel kan en distribusjonstabell som nettopp er opprettet i en fungerende Python-sesjon (uten å stoppe økten i Python) overføres til plattformen i form av for eksempel en global (flerdimensjonal InterSystems IRIS-dataarray) - og brukes for beregninger i en annen AI / ML-mekanisme (allerede implementert på språket til et annet miljø - for eksempel i R) - eller en virtuell tabell. Et annet eksempel: parallelt med "normalmodus" for modelloperasjonen (i Python-arbeidsøkten), utføres "auto-ML" på inngangsdataene: automatisk valg av optimale inngangsvariabler og parameterverdier. Og sammen med den "vanlige" treningen, mottar den produktive modellen i sanntid også et "optimeringsforslag" for spesifikasjonen - der settet med inngangsvariabler endres, parameterverdiene endres (ikke som et resultat av trening i Python , men som et resultat av å trene en "alternativ versjon av seg selv, for eksempel i H2O-stabelen), slik at den overordnede AI/ML-løsningen autonomt kan håndtere uforutsette endringer i naturen til inngangsdataene og fenomenene som modelleres.

La oss bli mer detaljert kjent med plattformens AI / ML-funksjonalitet til InterSystems IRIS, ved å bruke eksemplet på en virkelig prototype.

I diagrammet under, på venstre side av lysbildet, er det en del av forretningsprosessen som implementerer behandlingen av skript i Python og R. I den sentrale delen er det visuelle logger for utførelse av noen av disse skriptene, henholdsvis i Python og R. Rett bak dem er eksempler på innhold på ett og et annet språk, sendt inn for utførelse i de aktuelle miljøene. På slutten til høyre er visualiseringer basert på resultatene av skriptutførelse. Visualiseringene øverst er laget på IRIS Analytics (dataene hentes fra Python til InterSystems IRIS dataplattform og vises på dashbordet ved hjelp av plattformen), nederst lages de rett i R-arbeidsøkten og sendes ut derfra til grafiske filer. Et viktig aspekt: ​​det presenterte fragmentet i prototypen er ansvarlig for å trene modellen (klassifisering av utstyrstilstander) på data som kommer i sanntid fra prosess-simulatoren til utstyret, på kommando fra prosessmonitoren for kvaliteten på klassifiseringen observert under bruken av modellen. Implementeringen av en AI/ML-løsning som et sett av interagerende prosesser ("agenter") vil bli diskutert videre.

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

Plattformprosesser (de er også «forretningsprosesser», «analytiske prosesser», «pipelines» osv. - avhengig av kontekst), redigeres primært i en grafisk forretningsprosesseditor i selve plattformen, og på en slik måte at både blokkdiagrammet og den tilsvarende AI/ML-mekanismen (programkode) opprettes samtidig. Når vi snakker om det faktum at "en AI / ML-mekanisme oppnås", mener vi i utgangspunktet hybriditet (innenfor samme prosess): innhold på språk i matematiske modelleringsmiljøer er ved siden av innhold i SQL (inkludert utvidelser fra Integrert ML), i InterSystems ObjectScript, med andre støttede språk. Dessuten gir plattformprosessen svært brede muligheter for å "tegne" i form av hierarkisk nestede fragmenter (som kan sees i eksempelet i diagrammet nedenfor), som lar deg effektivt organisere selv svært komplekst innhold uten å "falle ut" av det grafiske formatet hvor som helst (i "ikke-grafiske" metoder/klasser/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. Vær oppmerksom på at i den sentrale delen av diagrammet nedenfor, som viser et høyere "hekkenivå", kan du se at i tillegg til selve arbeidet med å trene modellen (ved hjelp av Python og R), en analyse av den såkalte ROC kurven til den trente modellen er lagt til, som lar visuelt (og beregningsmessig også) evaluere kvaliteten på trening - og denne analysen er implementert på Julia-språket (den utføres henholdsvis i Julia-miljøet).

Figur 13 Visuelt miljø for å komponere AI/ML-løsninger i InterSystems IRIS

Som nevnt tidligere, vil/kan den første utviklingen og (i noen tilfeller) tilpasning av AI/ML-mekanismer som allerede er implementert i plattformen gjøres utenfor plattformen i Jupyter-editoren. I diagrammet under ser vi et eksempel på tilpasning av en eksisterende plattformprosess (samme som i diagrammet over) – slik ser fragmentet som er ansvarlig for opplæring av modellen ut i Jupyter. Python-innhold er tilgjengelig for redigering, feilsøking, grafikkutgang direkte i Jupyter. Endringer (om nødvendig) kan gjøres med umiddelbar synkronisering til plattformprosessen, inkludert produksjonsversjonen. På samme måte kan nytt innhold overføres til plattformen (en ny plattformprosess genereres automatisk).

Figur 14 Bruke Jupyter Notebook til å redigere AI/ML-motor i InterSystems IRIS-plattform

Tilpasning av plattformprosessen kan utføres ikke bare i et grafisk eller bærbart format, men også i det "totale" IDE-formatet (Integrated Development Environment). Disse IDE-ene er IRIS Studio (native IRIS-studio), Visual Studio Code (InterSystems IRIS-utvidelse for VSCode) og Eclipse (Atelier-plugin). I noen tilfeller er det mulig for utviklingsteamet å bruke alle tre IDE-ene samtidig. Diagrammet nedenfor viser et eksempel på redigering av samme prosess i IRIS studio, i Visual Studio Code og i Eclipse. Absolutt alt innhold er tilgjengelig for redigering: Python / R / Julia / SQL, og ObjectScript, og en forretningsprosess.

Figur 15 Utvikling av InterSystems IRIS forretningsprosess i ulike IDEer

InterSystems IRIS forretningsprosessbeskrivelse og utførelsesverktøy i Business Process Language (BPL) fortjener spesiell omtale. BPL gjør det mulig å bruke "ferdige integrasjonskomponenter" (aktiviteter) i forretningsprosesser - noe som faktisk gir full grunn til å hevde at "kontinuerlig integrasjon" er implementert i InterSystems IRIS. Ferdige forretningsprosesskomponenter (aktiviteter og koblinger mellom dem) er den kraftigste akseleratoren for å sette sammen en AI/ML-løsning. Og ikke bare forsamlinger: takket være aktivitetene og forbindelsene mellom dem, over forskjellige AI / ML-utviklinger og mekanismer, dukker det opp et "autonomt ledelseslag" som er i stand til å ta beslutninger i henhold til situasjonen, i sanntid.

Figur 16 Ferdige forretningsprosesskomponenter for kontinuerlig integrasjon (CI) på InterSystems IRIS-plattformen

Konseptet med agentsystemer (de er også "multi-agent-systemer") har en sterk posisjon innen robotikk, og InterSystems IRIS-plattformen støtter det organisk gjennom "produkt-prosess"-konstruksjonen. I tillegg til ubegrensede muligheter for å "fylle" hver prosess med funksjonaliteten som er nødvendig for den totale løsningen, gir systemet med plattformprosesser egenskapen "byrå" det mulig å lage effektive løsninger for ekstremt ustabile simulerte fenomener (oppførsel til sosiale/biosystemer). , delvis observerbare teknologiske prosesser, etc.).

Figur 16 Drift av AI/ML-løsning som et forretningsprosessagentsystem i InterSystems IRIS

Vi fortsetter vår gjennomgang av InterSystems IRIS med en historie om bruken av plattformen for å løse hele klasser av sanntidsproblemer (en ganske detaljert bekjentskap med noen av de beste praksisene for plattform AI / ML på InterSystems IRIS forekommer i en av våre tidligere webinarer).

I jakten på det forrige diagrammet, nedenfor er et mer detaljert diagram over agentsystemet. Diagrammet viser samme prototype, alle fire agentprosesser er synlige, relasjonene mellom dem er skjematisk tegnet: GENERATOR - håndterer opprettelsen av data av utstyrssensorer, BUFFER - administrerer datakøer, ANALYSER - utfører maskinlæring selv, MONITOR - kontrollerer kvalitet på maskinlæring og gir et signal om at modellen må omskoleres.

Figur 17 Sammensetning av en AI/ML-løsning som et forretningsprosessagentsystem i InterSystems IRIS

Diagrammet nedenfor illustrerer den autonome funksjonen til en annen robotprototype (emosjonell tekstgjenkjenning) i noen tid. I den øvre delen - utviklingen av modelllæringskvalitetsindikatoren (kvaliteten vokser), i den nedre delen - dynamikken til modellapplikasjonskvalitetsindikatoren og fakta om gjentatt trening (røde søyler). Som du kan se, har løsningen lært seg selv effektivt og autonomt, og fungerer på et gitt kvalitetsnivå (verdiene til kvalitetsindikatoren faller ikke under 80%).

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

Vi nevnte også "auto-ML" tidligere, men diagrammet nedenfor viser bruken av denne funksjonaliteten i detalj ved å bruke en annen prototype som eksempel. Det grafiske diagrammet av forretningsprosessfragmentet viser aktiviteten som starter simuleringen i H2O-stabelen, viser resultatene av denne simuleringen (åpenbar dominans av den resulterende modellen over de "menneskeskapte" modellene, i henhold til det komparative diagrammet over ROC-kurver , samt automatisert identifikasjon av de "mest innflytelsesrike variablene" fra tilgjengelig i original datasett). Det viktige poenget her er sparing av tid og ekspertressurser, som oppnås gjennom "auto-ML": det plattformprosessen vår gjør på et halvt minutt (finne og trene den optimale modellen), kan en ekspert ta fra en uke til en måned.

Figur 19 Auto-ML-integrasjon i AI/ML-løsning basert på InterSystems IRIS-plattform

Diagrammet nedenfor "slår ned klimakset" litt, men dette er en god måte å fullføre historien om klassene av sanntidsproblemer som løses: vi minner deg om at med alle mulighetene til InterSystems IRIS-plattformen, opplæringsmodeller under dens kontroll er ikke obligatorisk. Plattformen kan eksternt få en såkalt PMML-modellspesifikasjon trent i et verktøy som ikke er kontrollert av plattformen – og anvende denne modellen i sanntid fra det øyeblikket den importeres PMML spesifikasjoner. Samtidig er det viktig å ta hensyn til at ikke alle AI/ML-artefakter kan reduseres til en PMML-spesifikasjon, selv om de fleste av de vanligste artefaktene tillater dette. Dermed har InterSystems IRIS-plattformen en "open loop" og betyr ikke "plattformslaveri" for brukerne.

Figur 20 Auto-ML-integrasjon i AI/ML-løsning basert på InterSystems IRIS-plattform

Vi lister opp de ekstra plattformfordelene til InterSystems IRIS (for klarhet, i forhold til prosesskontroll), som er av stor betydning for automatisering av kunstig intelligens og maskinlæring i sanntid:

• Avanserte integreringsverktøy med alle datakilder og forbrukere (PCS/SCADA, utstyr, MRO, ERP, etc.)
• Innebygd multi-modell DBMS for høyytelses transaksjonsanalytisk behandling (Hybrid Transaction/Analytical Processing, HTAP) av alle mengder prosessdata
• Utviklingsverktøy for kontinuerlig distribusjon av sanntids AI/ML beslutningsmotorer basert på Python, R, Julia
• Adaptive forretningsprosesser for kontinuerlig integrasjon og (selv)læringsmekanismer for sanntids AI/ML-løsninger
• Innebygde Business Intelligence-verktøy for visualisering av prosessdata og AI/ML-løsningsresultater
• API-administrasjon å levere resultatene av AI/ML-løsningen til prosesskontrollsystemer/SCADA, informasjons- og analysesystemer, sende varsler, etc.

AI/ML-løsninger basert på InterSystems IRIS-plattformen passer lett inn i den eksisterende IT-infrastrukturen. InterSystems IRIS-plattformen gir høy pålitelighet av AI/ML-løsninger gjennom støtte for feiltolerante og katastrofetolerante konfigurasjoner og fleksibel distribusjon i virtuelle miljøer, på fysiske servere, i private og offentlige skyer, Docker-containere.

Dermed er InterSystems IRIS en universell sanntids AI/ML-databehandlingsplattform. Universaliteten til plattformen vår bekreftes i praksis av fraværet av de facto-begrensninger på kompleksiteten til implementerte beregninger, muligheten til InterSystems IRIS til å kombinere (i sanntid) behandlingen av scenarier fra et bredt spekter av bransjer, og den eksepsjonelle tilpasningsevnen av alle funksjoner og mekanismer på plattformen til spesifikke brukerbehov.

Figur 21 InterSystems IRIS - Universal Real-time AI/ML Computing Platform

For en mer innholdsrik interaksjon med de av våre lesere som er interessert i materialet som presenteres her, anbefaler vi at du ikke begrenser deg til å lese det og fortsetter dialogen "live". Vi vil gjerne gi støtte med formulering av sanntids AI / ML-scenarier i forhold til spesifikasjonene til din bedrift, utføre felles prototyping på InterSystems IRIS-plattformen, lage og implementere et veikart for å introdusere kunstig intelligens og maskinlæring inn i produksjons- og styringsprosessene dine. Kontakt-e-postadressen til vår AI/ML-ekspertgruppe er [e-postbeskyttet].

Kilde: www.habr.com