By Sai Geetha, strokovnjak za inženiring velikih podatkov in podatkovno znanost.

O Rendezvous arhitektura predlagala Ted Dunning in Ellen Friedman v svoji knjigi o Logistika strojnega učenja je bila čudovita rešitev, ki sem jo našel za določen arhitekturni problem, na katerem sem delal. Iskal sem preizkušen in preizkušen oblikovalski vzorec ali arhitekturni vzorec, ki bi mi pomagal poganjati modela Challenger in Champion skupaj na način, ki ga je mogoče vzdrževati in podpirati. Arhitektura srečanja je bila bistveno bolj uporabna v svetu velikih podatkov, ker imate opravka s težkimi podatki in velikimi cevovodi.

Zmožnost skupnega izvajanja modelov Challenger in Champion na vseh podatkih je zelo resnična potreba pri strojnem učenju, kjer se lahko zmogljivost modela sčasoma zmanjša in kjer želite vedno izboljševati zmogljivost svojih modelov na nekaj boljšega.

Torej, preden se poglobim v to arhitekturo, bi rad razjasnil nekaj žargona, ki sem ga uporabil zgoraj. Kaj je model Champion? Kaj je model Challenger? Kaj je zamik modela in zakaj do njega pride? Nato si lahko ogledamo samo arhitekturo srečanja in probleme, ki jih rešuje.

Model Drift

Ko enkrat daste svoj model v proizvodnjo, je domneva, da bo vedno deloval dobro, napaka. Pravzaprav je rečeno - "V trenutku, ko daš model v proizvodnjo, se začne razgrajevati. "(Upoštevajte, najpogosteje 'performance' v ML se uporablja za označevanje statistične zmogljivosti - naj bo to natančnost, natančnost, priklic, občutljivost, specifičnost ali kar koli drugega, ki je ustrezna metrika za vaš primer uporabe).

Zakaj se to zgodi? Model se uri na nekaterih preteklih podatkih. Odlično se obnese za vse podatke z enakimi lastnostmi. Vendar pa se s časom lahko dejanske lastnosti podatkov spreminjajo, model pa se teh sprememb sploh ne zaveda. To povzroči zamik modela, tj. poslabšanje delovanja modela.

Na primer, usposobili ste model za zaznavanje neželene pošte v primerjavi z domačo pošto. Model se ob uporabi dobro obnese. Sčasoma se vrste vsiljene pošte spreminjajo, zato se zmanjša natančnost napovedi. To se imenuje model drift.

Do zamika modela bi lahko prišlo zaradi a koncept drift ali odmik podatkov. Danes se ne spuščam v te, zato bo dovolj, da razumemo, da zmogljivost modela ne ostane konstantna. Zato moramo stalno spremljati delovanje modela. Najpogosteje je najbolje, da model znova usposobite s svežimi podatki pogosteje ali verjetno na podlagi mejne ravni poslabšanja zmogljivosti.

Včasih tudi ponovno usposabljanje modela ne izboljša učinkovitosti. To bi pomenilo, da boste morda morali razumeti spremembe v značilnostih problema in iti skozi celoten proces analize podatkov, ustvarjanja funkcij in gradnje modela z ustreznejšimi modeli.

Ta cikel je mogoče skrajšati, če lahko delate z modeli Challenger, čeprav imamo trenutno en model v proizvodnji. To je proces nenehnega izboljševanja strojnega učenja in je zelo potreben.

Modeli Champion-Challenger

Običajno se model v proizvodnji imenuje Champion model. In vsak drug model, za katerega se zdi, da dobro deluje v vaših manjših poskusih in je pripravljen za proizvodnjo, je a Challenger model. Ti modeli Challenger so bili predlagani, ker domnevamo, da obstaja možnost, da delujejo bolje kot model Champion. Toda kako to dokažemo?

Model Champion običajno deluje na vseh vhodnih podatkih, da zagotovi napovedi. Toda na katerih podatkih deluje model Challenger?

Modele Challenger lahko preizkusite na dva načina. Idealen primer bi bil, če bi model Challenger izvajali vzporedno z modelom Champion na vseh podatkih in primerjali rezultate. To bi resnično dokazalo, da lahko model Challenger deluje bolje ali ne. Vendar se to zdi prepovedano, zlasti v svetu velikih podatkov, zato se Challenger vedno preizkusi na podmnožici vhodnih podatkov. Ko se zdi, da deluje dobro, se postopoma uvaja na vedno več podatkov, skoraj kot testiranje alfa-beta.

Kot morda veste, se pri alfa-beta testiranju majhen odstotek uporabnikov ali dohodnih podatkov v tem primeru pošlje skozi nov preskusni ali Challengerjev cevovod, ostali pa gredo skozi izvirni Championov cevovod. Tovrstno testiranje alfa-beta je dobro za nekatere aplikacije, vendar očitno ni zelo impresivno v svetu strojnega učenja. Ne primerjate modelov na istih podatkih, zato lahko le redko z gotovostjo trdite, da je eden boljši od drugega za celotne podatke. Ko ga uvedete za vse podatke, se lahko skrivajo presenečenja in premik modela se lahko začne prej, kot je bilo pričakovano.

Tipičen cevovod alfa-beta bi bil videti takole:

Podatki so razdeljeni med dva cevovoda na podlagi nekaterih meril, kot je kategorija izdelka. Ta delitev podatkov se še naprej povečuje proti Challengerju, ko narašča zaupanje v zmogljivost modela Challenger.

Z vidika podatkovnega znanstvenika to ni idealno. Idealno bi bilo, da bi lahko vzporedno izvajali model Challenger vse podatke skupaj z modelom Champion. Kot sem že rekel, je to zelo drago.

Razmislite o najslabšem možnem scenariju. Če želite, da tečejo vzporedno, morate nastaviti dva podatkovna cevovoda, ki potekata neodvisno skozi vse korake.

Izgledalo bi nekako takole:

To ima velike inženirske posledice in posledično čas do trženja. Stroški tega lahko sčasoma postanejo previsoki.

Nekaj ​​najpomembnejših posledic je čas in trud pri gradnji teh cevovodov znova in znova, ne da bi bili prepričani, ali bo model Challenger res deloval po pričakovanjih. Postopek CI/CD, uvedbe, nadzor, mehanizmi za preverjanje pristnosti itd., so le nekateri, ki jih je treba omeniti. Poleg tega je drugi strošek povezan z infrastrukturo, ki jo je treba dvojno zagotoviti.

Če upoštevamo, ali so ti cevovodi veliki podatkovni cevovodi, postane to še toliko bolj pomembno. Zelo kmalu ugotovite, da to ni razširljiv model. Vsekakor moramo videti, kako se lahko odmaknemo od vzporednih cevovodov ali celo od metode testiranja alfa-beta.

Posledično bi bil najboljši scenarij, ko bi lahko ponovno uporabili velik del podatkovnih cevovodov. Ideja je čim bolj zmanjšati količino, ki jo je treba razviti in ponovno uvesti v proizvodnjo. S tem bi zagotovili tudi optimizacijo uporabe infrastrukture. To je ena smer razmišljanja o tem, kako optimizirati.

Še bolje bi bilo, če bi lahko samo priključite model Challenger, in preostali del cevovoda igra, kot da se ni nič spremenilo. Ali ne bi bilo to fantastično? In to je tisto, kar omogoča Rendezvous arhitektura.

Rendezvous arhitektura

Arhitektura Rendezvous, kot piše v knjigi, je nagnjena k ML z manjšimi podatki. Prilagodil sem ga tako, da ustreza potrebam sveta velikih podatkov in povezanih cevovodov, kot je prikazano v spodnjem diagramu: (Sklici na knjigo in drug članek so navedeni spodaj v razdelku z referencami)

Naj zdaj razložim oddelek za odsekom te arhitekture.

Del 1:

To je sestavljeno iz standardnega podatkovnega cevovoda za sprejemanje dohodnih podatkov, njihovo čiščenje, pripravo in ustvarjanje zahtevanih funkcij. To bi moral biti samo en cevovod za vsak model, ki bo uveden. Pripravljeni podatki morajo vzdrževati standardni vmesnik, ki ima vse funkcije, ki so morda potrebne v tej domeni, ne glede na model, ki je na voljo. (Razumem, da to ni vedno mogoče in da bo morda treba postopoma prilagajati. Toda po potrebi se lahko s tem kosom ukvarjamo ločeno.)

Del 2:

To je infrastruktura za sporočanje, kot je Kafka, ki pride v poštev tako, da vnese občutek asinhronosti. Podatki, ki so pripravljeni kot značilnosti, so objavljeni na sporočilnem vodilu. Zdaj vsak model posluša to vodilo za sporočila in se sproži ter se izvede s pripravljenimi podatki. To vodilo za sporočila je tisto, kar tukaj omogoča arhitekturo plug-and-play.

Del 3:

To je del, kjer se vsi modeli uporabljajo enega za drugim. Nov model Challenger je mogoče razmestiti in pripraviti tako, da posluša vodilo za sporočila, in se lahko izvaja, ko podatki pritekajo noter. Tukaj je mogoče namestiti poljubno število modelov in ne samo enega modela Challenger! Poleg tega je infra zahteva samo za delovanje dodatnega modela. Niti cevovodov pred modelom niti cevovodov po modelu ni treba posebej razviti ali uvesti.

Kot lahko vidite na sliki, lahko imate veliko izzivalnih modelov, dokler podatkovni znanstvenik vidi, da so dovolj zreli za testiranje glede na resnične podatke.

Obstaja tudi poseben model, imenovan model vabe. Da bi zagotovili, da vsak modelni proces ni obremenjen z vztrajnostjo, pripravljene podatke bere tudi tako imenovani model za vabo, katerih edina naloga je prebrati pripravljene podatke in vztrajati. To pomaga pri revizijskih namenih, sledenju in odpravljanju napak, kadar je to potrebno.

Del 4:

Vsi ti modeli znova izpišejo svoje napovedi ali rezultate v drugo sporočilno vodilo, tako da med seboj ne pride do nobene odvisnosti. Tudi to igra pomembno vlogo pri zagotavljanju vklopljivosti modela, ne da bi pri tem motili kar koli drugega v cevovodu.

Od tam postopek srečanja pobere rezultate in se odloči, kaj je treba narediti, kot je opisano v 5. delu.

Del 5:

Tukaj je nov koncept a Postopek srečanja uvede se, ki ima dva pomembna podprocesa. En neposredni podproces poskrbi za pretakanje pravilnega izhoda iz cevovoda za potrošnika med številnimi ocenami, ki jih je prejel, drugi proces pa je ohranjanje izhoda iz vseh modelov za nadaljnjo primerjavo in analizo.

Tu smo torej dosegli dve stvari:

1. Potrošniku je zagotovljen najboljši učinek.
2. Vsi podatki so šli skozi vse modele, zato so popolnoma primerljivi v podobnih okoliščinah glede njihove uspešnosti.

Kako se odloči, kateri izhod modela naj se pošlje? To lahko temelji na več merilih, na primer podnabor podatkov mora biti vedno iz Challengerja, drugi podnabor pa vedno iz Championa. To je skoraj tako, kot če bi dosegli testiranje alfa-beta. Vendar pa je prednost tukaj v tem, da čeprav se za potrošnika sliši kot alfa-beta testiranje, so za podatkovnega znanstvenika vsi podatki prešli skozi oba modela, tako da lahko primerja oba izhoda in razume, kateri je boljši.

Drugo merilo bi lahko bilo, da mora rezultat temeljiti na zmogljivosti modela. V tem primeru postopek srečanja čaka, da se vsi modeli dokončajo in objavijo v sporočilnem vodilu. Nato poišče najboljšo metriko uspešnosti in jo pošlje kot rezultat.

Da, drugo merilo je lahko čas ali zakasnitev. Če moramo imeti rezultat v recimo manj kot 5 sekundah, proces počaka na vse rezultate iz modelov do 5 sekund, primerja le te in vrne najboljše podatke. Čeprav se v 6. sekundi vrne drug model, ki je morda deloval veliko bolje, se to ne upošteva, ker ne izpolnjuje meril zakasnitve.

Toda kako ta proces ve, katera merila je treba upoštevati za katere podatke ali kateri model? To lahko vstavite kot del vhodnih podatkov v vodilo za sporočila v 2. delu. Upoštevajte, da proces Rendezvous prav tako posluša ta sporočila in spoznava, kaj storiti z izhodom, ki ustreza vhodu. Obstajajo lahko tudi drugi pametni načini, vendar je to eden od predlaganih načinov.

zaključek

Z uvedbo asinhronosti prek vodil za sporočila je bila uvedena stopnja ločevanja, ki omogoča vstavljanje modelov plug-and-play v sicer tog cevovod podatkov.

Z uvedbo postopka srečanja je bila uvedena možnost izbire med različnimi rezultati modela, njihovega vztrajanja, primerjave. In s tem se zdaj ne zdi herkulska naloga uvesti ali podpreti poljubnega števila novih modelov za isti niz podatkov.

Povzetek

Rendezvous arhitektura daje veliko prilagodljivost na različnih ravneh.

1. Za odločanje, kateri rezultat, izhod ali napoved je mogoče poslati iz postopka napovedovanja, je mogoče uporabiti različne kriterije. Ta merila bi lahko temeljila na zakasnitvi, na zmogljivosti modela ali preprosto na času.
2. Omogoča dinamično določanje in spreminjanje teh kriterijev skozi proces srečanja. Lahko ga dvignete na drugo raven, tako da tukaj uvedete mehanizem pravil.
3. Zagotavlja možnost, da gredo vsi podatki skozi vse cevovode ali izberete samo podmnožico, ki bo šla skozi številne cevovode. Na primer, če imate živila in izdelke splošnega trgovanja, za katere napovedujete, lahko živila gredo skozi lastna modela Champion in Challenger, medtem ko ima lahko splošno blago, ki se običajno počasi prodaja, lastne cevovode.
4. Zagotavlja tudi možnost izvajanja več modelov hkrati brez ponovnega razvoja ali ponovne razmestitve velikega dela cevovoda velikih podatkov. Poleg prihranka truda in časa so optimizirani tudi stroški infrastrukture.

Reference

1. Logistika strojnega učenja avtor Ted Dunning; Ellen Friedman – 3. poglavje o "Arhitekturi srečanja za strojno učenje"
2. Članek o protidatacience.com"Arhitektura Rendezvous za podatkovno znanost v proizvodnji” Jana Teichmanna

prvotni. Poročeno z dovoljenjem.

Bio: Sai Geetha (@saigeethamn) je arhitekt z izkušnjami pri ustvarjanju strateških načrtov in inovacijah na podlagi potreb podjetja in vodilnih tehnologij. Specialist za velike podatke z znanjem podatkovne znanosti, ki lahko premosti vrzel med obema svetovoma in prinese uspeh kateri koli veliki podatkovni pobudi v vašem podjetju.

Povezano:

• Zbogom veliki podatki. Pozdravljeni, Massive Data!
• Najboljši vodnik za preusposabljanje modelov
• Skrito tveganje umetne inteligence in velikih podatkov