By Sai Geetha, en ekspert på Big Data Engineering og Data Science.

De Rendezvous arkitektur foreslått av Ted Dunning og Ellen Friedman i sin bok om Maskinlæringslogistikk var en fantastisk løsning jeg fant for et spesifikt arkitektonisk problem jeg jobbet med. Jeg var på utkikk etter et utprøvd designmønster eller arkitektonisk mønster som hjelper meg å kjøre Challenger- og Champion-modeller sammen på en vedlikeholdbar og støttebar måte. Rendezvous-arkitekturen var betydelig mer nyttig i big data-verdenen fordi du har å gjøre med tunge data og store rørledninger.

Muligheten til å kjøre Challenger- og Champion-modeller sammen på alle data er et veldig genuint behov i maskinlæring, der modellytelsen kan drive over tid og hvor du vil fortsette å forbedre ytelsen til modellene dine til noe bedre alltid.

Så før jeg går dypere inn i denne arkitekturen, vil jeg gjerne klargjøre noe av sjargongen jeg har brukt ovenfor. Hva er en Champion-modell? Hva er en Challenger-modell? Hva er modelldrift, og hvorfor oppstår det? Deretter kan vi se på selve rendezvous-arkitekturen og problemene den løser.

Modell Drift

Når du har satt modellen din i produksjon, er det en feil å anta at den alltid vil fungere bra. Faktisk sies det - "I det øyeblikket du setter en modell i produksjon, begynner den å bli nedverdigende». (Merk, oftest 'ytelse' i ML brukes til å bety statistisk ytelse - det være seg nøyaktighet, presisjon, gjenkalling, sensitivitet, spesifisitet eller hva den aktuelle metrikken er for ditt bruk).

Hvorfor skjer dette? Modellen er trent på noen tidligere data. Den fungerer utmerket for alle data med de samme egenskapene. Men etter hvert som tiden går, kan de faktiske datakarakteristikkene fortsette å endre seg, og modellen er ikke klar over disse endringene i det hele tatt. Dette forårsaker modelldrift, dvs. forringelse av modellens ytelse.

Du trente for eksempel en modell til å oppdage spam-e-post versus ham-post. Modellen yter godt når den brukes. Over tid fortsetter spamtypene å endre seg, og derfor faller nøyaktigheten av spådommen. Dette kalles modell drift.

Modellavdriften kan skje på grunn av en konseptdrift eller en datadrift. Jeg går ikke inn på disse i dag, så det er nok for oss å forstå at ytelsen til en modell ikke forblir konstant. Derfor må vi kontinuerlig overvåke ytelsen til en modell. Oftest er det best å omskolere modellen med ferskere data oftere eller sannsynligvis basert på et terskelnivå i ytelsesdegradering.

Noen ganger vil selv omskolering av modellen ikke forbedre ytelsen ytterligere. Dette vil innebære at du kanskje må forstå endringene i egenskapene til problemet og gå gjennom hele prosessen med dataanalyse, funksjonsoppretting og modellbygging med mer passende modeller.

Denne syklusen kan forkortes hvis du kan jobbe med Challenger-modeller selv mens vi har én modell i produksjon for øyeblikket. Dette er en kontinuerlig forbedringsprosess for maskinlæring og er svært nødvendig.

Champion-Challenger-modeller

Vanligvis kalles modellen i produksjon Champion modell. Og enhver annen modell som ser ut til å fungere bra i de mindre forsøkene dine og er klar for produksjon, er en Challenger modell. Disse Challenger-modellene har blitt foreslått fordi vi antar at det er en sjanse for at de yter bedre enn Champion-modellen. Men hvordan beviser vi det?

En Champion-modell kjører vanligvis på alle innkommende data for å gi spådommene. Men på hvilke data kjører Challenger-modellen?

Challenger-modellene kan testes på to måter. Det ideelle tilfellet ville være å kjøre Challenger-modellen parallelt med Champion-modellen på alle data og sammenligne resultatene. Dette vil virkelig bevise at Challenger-modellen kan prestere bedre eller ikke. Dette virker imidlertid uoverkommelig, spesielt i big data-verdenen, og derfor blir Challenger alltid utprøvd på en undergruppe av innkommende data. Når det ser ut til å fungere bra, rulles det gradvis ut til mer og mer data, nesten som alfa-beta-testing.

Som du kanskje er klar over, i alfabeta-testing sendes en liten prosentandel av brukere eller innkommende data, i dette tilfellet, gjennom en ny test- eller Challenger-pipeline, og resten går gjennom den originale Champion-pipelinen. Denne typen alfa-beta-testing er bra for noen applikasjoner, men tydeligvis ikke veldig imponerende i verden av maskinlæring. Du sammenligner ikke modellene på de samme dataene og kan derfor sjelden si med sikkerhet at den ene er bedre enn den andre for hele dataen. Det kan være overraskelser på lur når du ruller den ut for alle data, og modelldriften kan starte raskere enn forventet.

En typisk alfa-beta pipeline vil se slik ut:

Dataene er delt mellom de to rørledningene basert på noen kriterier, som kategorien til et produkt. Denne datadelingen fortsetter å øke mot Challenger ettersom tilliten til ytelsen til Challenger-modellen vokser.

Fra en dataforskers perspektiv er ikke dette ideelt. Det ideelle vil være å kunne kjøre Challenger-modellen parallelt for alle dataene sammen med Champion-modellen. Som jeg sa tidligere, er dette veldig dyrt.

Tenk på det verste tilfellet. Hvis du vil at de skal kjøre parallelt, må du sette opp to datapipelines som går gjennom alle trinnene uavhengig av hverandre.

Det ville se slik ut:

Dette har enorme tekniske implikasjoner og dermed implikasjoner på tid til å markedsføre. Kostnaden for dette kan bli uoverkommelig over tid.

Noen av de viktigste implikasjonene er tiden og innsatsen i å bygge disse rørledningene om og om igjen uten å være sikker på om Challenger-modellen faktisk kommer til å fungere som forventet. CI/CD-prosessen, distribusjonene, overvåkingen, autentiseringsmekanismene osv. er noen få å nevne. I tillegg er den andre kostnaden rundt infrastrukturen som må tilrettelegges dobbelt.

Med tanke på om disse rørledningene er store datarørledninger, blir det desto mer betydningsfullt. Veldig snart skjønner du at dette ikke er en skalerbar modell. Vi må absolutt se hvordan vi kan bevege oss bort fra parallelle rørledninger eller til og med fra alfa-beta-testmetoden.

Som en konsekvens vil det beste scenarioet være når vi kan gjenbruke mye av datarørledningene. Tanken er å minimere mengden man må utvikle og distribuere igjen til produksjon. Dette vil også sikre optimalisering av infrastrukturbruken. Dette er en tankegang om hvordan du kan optimalisere.

Enda bedre ville være å kunne bare koble til Challenger-modellen, og resten av rørledningen spiller som om ingenting har endret seg. Ville ikke det vært fantastisk? Og det er dette som er muliggjort av Rendezvous arkitektur.

Rendezvous-arkitektur

Rendezvous-arkitekturen, som skrevet i boken, vippes mot ML med mindre data. Jeg har tilpasset den for å møte behovene til big data-verdenen og tilhørende rørledninger som vist i diagrammet nedenfor: (Referanser til boken og en annen artikkel er gitt nedenfor i referansedelen)

La meg nå forklare seksjon for seksjon av denne arkitekturen.

Del 1:

Dette består av standard datapipeline for mottak av innkommende data, rensing, klargjøring og oppretting av nødvendige funksjoner. Dette bør kun være én rørledning for hver modell som skal distribueres. De forberedte dataene skal ha et standardgrensesnitt som har alle funksjonene som kan kreves i det domenet, uavhengig av hvilken modell som er tilgjengelig. (Jeg forstår at dette ikke alltid er mulig og kan trenge justeringer stykkevis over tid. Men vi kan håndtere det stykket isolert når det er nødvendig.)

Del 2:

Dette er en meldingsinfrastruktur som Kafka som kommer inn ved å bringe inn følelsen av asynkronitet. Dataene som er forberedt som funksjoner, publiseres på meldingsbussen. Nå lytter hver modell til denne meldingsbussen og trigger av og kjører seg selv med de forberedte dataene. Denne meldingsbussen er det som muliggjør en plug-and-play-arkitektur her.

Del 3:

Dette er delen hvor alle modellene distribueres én etter én. En ny Challenger-modell kan distribueres og lages for å lytte til meldingsbussen, og når data strømmer inn, kan den kjøres. Et hvilket som helst antall modeller kan distribueres her og ikke bare én Challenger-modell! Infra-kravet er også bare for den ekstra modellen å kjøre. Verken pre-modell rørledningene eller post-modell rørledninger trenger å utvikles eller distribueres separat.

Som du kan se på figuren, kan du ha mange utfordrermodeller så lenge dataforskeren ser dem modne nok til å bli testet mot ekte data.

Det er også en spesiell modell som kalles lokkemodellen. For å sikre at hver av modellprosessene ikke belastes med utholdenhet, leses de forberedte dataene også av det som kalles en lokkemodell, hvis eneste jobb er å lese de forberedte dataene og fortsette. Dette hjelper til med revisjonsformål, sporing og feilsøking når det er nødvendig.

Del 4:

Alle disse modellene sender igjen sine spådommer eller skårer i en annen meldingsbuss, og bringer dermed ingen avhengighet mellom seg. Også, igjen, spiller dette en viktig rolle for å sikre pluggbarheten til en modell uten å forstyrre noe annet i rørledningen.

Derfra henter møteprosessen poengsummene og bestemmer hva som må gjøres, som beskrevet i del 5.

Del 5:

Det er her det nye konseptet med en Rendezvous prosess introduseres, som har to viktige delprosesser. Den ene umiddelbare delprosessen sørger for å strømme ut riktig utgang fra rørledningen for en forbruker blant de mange poengsummene den har mottatt, og den andre prosessen er å opprettholde utgangen fra alle modeller for videre sammenligning og analyse.

Så vi har oppnådd to ting her:

1. Det beste resultatet leveres til forbrukeren.
2. Alle dataene har gått gjennom alle modellene, og derfor er de fullstendig sammenlignbare under like omstendigheter på ytelsen.

Hvordan bestemmer den hvilken modells utdata som skal sendes ut? Dette kan være basert på flere kriterier, slik som at et delsett av data alltid skal være fra Challenger, og et annet delsett alltid skal være fra Champion. Dette er nesten som å oppnå alfa-beta-testingen. Fordelen her er imidlertid at selv om det høres ut som alfa-beta-testing for en forbruker, for dataforskeren, har alle data vært gjennom begge modellene, slik at de kan sammenligne de to utgangene og forstå hvilken som gir best ytelse.

Et annet kriterium kan være at produksjonen skal være basert på modellens ytelse. I dette tilfellet venter møteprosessen på at alle modellene skal fullføres og publiseres til meldingsbussen. Deretter søker den etter den beste ytelsesberegningen og sender den ut som resultat.

Ja, et annet kriterium kan være tid eller ventetid. Hvis vi for eksempel trenger å ha resultatet på mindre enn 5 sekunder, venter prosessen på alle resultatene fra modellene, opptil 5 sekunder, sammenligner bare disse og returnerer de beste dataene. Selv om en annen modell kommer tilbake i det sjette sekundet som kan ha prestert mye bedre, ignoreres den siden den ikke oppfyller latenskriteriene.

Men hvordan vet denne prosessen hva som er kriteriene som skal følges for hvilke data eller hvilken modell? Dette kan legges inn som en del av inndataene i meldingsbussen i del 2. Merk at Rendezvous-prosessen også lytter til disse meldingene og får vite hva de skal gjøre med utgangen som tilsvarer en inngang. Det kan være andre smarte måter også, men dette er en av måtene som er foreslått.

konklusjonen

Ved å introdusere asynkronitet gjennom meldingsbusser, har et nivå av frakobling blitt introdusert, noe som bringer inn muligheten til å plug-and-play-modeller inn i en ellers stiv datapipeline.

Ved å introdusere rendezvous-prosessen ble muligheten til å velge mellom ulike modellutganger, vedvare dem, sammenligne dem alle introdusert. Og med dette ser det nå ikke ut til å være en uhyggelig oppgave å introdusere eller støtte et hvilket som helst antall nye modeller for samme datasett.

Oppsummering

Rendezvous-arkitekturen gir stor fleksibilitet på ulike nivåer.

1. En rekke kriterier kan brukes til å bestemme hvilken poengsum, utgang eller prediksjon som kan sendes ut av prediksjonsprosessen. Disse kriteriene kan være latensbaserte, modellytelsesbaserte eller enkle tidsbaserte.
2. Det gir muligheten til å definere og endre disse kriteriene dynamisk gjennom rendezvous-prosessen. Du kan ta det til et annet nivå ved å introdusere en regelmotor her.
3. Det gir muligheten til å få alle dataene til å gå gjennom alle rørledningene eller velge bare en delmengde for å gå gjennom mange rørledninger. For eksempel, hvis du har dagligvare- og generelle merchandising-produkter som du anslår, kan dagligvarer gå gjennom sine egne Champion- og Challenger-modeller, mens generelle varer, som vanligvis er trege selgere, kan ha sine egne pipelines.
4. Det gir også muligheten til å kjøre mange modeller om gangen uten å omutvikle eller omdistribuere en stor del av en big data-pipeline. Foruten innsats og tidsbesparelser, er også infrastrukturkostnadene optimalisert.

Referanser

1. Maskinlæringslogistikk av Ted Dunning; Ellen Friedman - 3. kapittel om "The Rendezvous Architecture for Machine Learning"
2. En artikkel på motdatascience.com"Rendezvous-arkitektur for datavitenskap i produksjon” av Jan Teichmann

original. Ompostet med tillatelse.

Bio: Sai Geetha (@saigeethamn) er en arkitekt med erfaring i å lage strategiske veikart og innovere basert på bedriftens behov og ledende teknologier. En Big Data-spesialist med kunnskap om datavitenskap som kan bygge bro mellom de to verdenene og bringe suksess til ethvert stort datainitiativ i bedriften din.

Relatert:

• Farvel Big Data. Hei, Massive Data!
• Den ultimate guiden til modellomskolering
• Den skjulte risikoen ved AI og Big Data