Unutar ByteDanceovog monolita: Pokretačka snaga pametnijih, bržih sadržajnih feedova

```html Autori: Zhuoran Liu, Bytedance Inc. Leqi Zou, Bytedance Inc. Xuan Zou, Bytedance Inc. Caihua Wang, Bytedance Inc. Biao Zhang, Bytedance Inc. Da Tang, Bytedance Inc. Bolin Zhu∗, Univerzitet Fudan Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) SAŽETAK Izgradnja skalabilnog sistema za preporuke u realnom vremenu je vitalna za mnoga preduzeća vođena vremenski osjetljivim povratnim informacijama kupaca, kao što su rangiranje kratkih videozapisa ili online oglasi. Uprkos širokoj upotrebi produkcijskih okvira za duboko učenje kao što su TensorFlow ili PyTorch, ovi okviri opće namjene ne zadovoljavaju poslovne potrebe u scenarijima preporuka iz raznih razloga: s jedne strane, ugađanje sistema na osnovu statičkih parametara i gustih proračuna za preporuke s dinamičkim i rijetkim značajkama je štetno za kvalitet modela; s druge strane, takvi okviri su dizajnirani sa potpuno odvojenim fazama batch obuke i posluživanja, sprečavajući model da komunicira s povratnim informacijama kupaca u realnom vremenu. Ovi problemi su nas naveli da ponovo ispitamo tradicionalne pristupe i istražimo radikalno drugačije dizajnerske izbore. U ovom radu predstavljamo 1, sistem prilagođen za online obuku. Naš dizajn je vođen zapažanjima naših radnih opterećenja aplikacija i produkcijskog okruženja, što odražava značajan odmak od drugih sistema preporuka. Naši doprinosi su višestruki: prvo, izradili smo tablicu ugradnje bez kolizija s optimizacijama kao što su ugradnje koje ističu i filtriranje frekvencija kako bismo smanjili njen otisak u memoriji; drugo, nudimo produkcijsku arhitekturu za online obuku visoke otpornosti na greške; konačno, dokazali smo da se pouzdanost sistema može žrtvovati za učenje u realnom vremenu. Monolith je uspješno implementiran u proizvod BytePlus Recommend2. Monolith 1 UVOD Prošla decenija svjedočila je procvatu poslovanja zasnovanog na tehnikama preporuka. U potrazi za boljim korisničkim iskustvom, pružanje personaliziranog sadržaja za svakog pojedinačnog korisnika kao odgovor u realnom vremenu je uobičajeni cilj ovih poslovnih aplikacija. U tu svrhu, informacije iz posljednje interakcije korisnika često se koriste kao primarni ulaz za obuku modela, jer bi najbolje prikazivale profil korisnika i predviđale interes i buduća ponašanja korisnika. Duboko učenje dominira modelima preporuka [ , , , , , ] jer ogromna količina korisničkih podataka prirodno odgovara masovno vođenim neuronskim modelima. Međutim, napori da se iskoristi snaga dubokog učenja u sistemima preporuka industrijskog nivoa stalno se susreću s problemima koji proizlaze iz jedinstvenih karakteristika podataka izvedenih iz stvarnog korisničkog ponašanja. Ovi podaci se drastično razlikuju od onih korištenih u konvencionalnim problemima dubokog učenja kao što su jezičko modeliranje ili računarstvo vida u dva aspekta: 5 6 10 12 20 21 (1) Značajke su uglavnom rijetke, kategorijalne i dinamički se mijenjaju; (2) Osnovna distribucija podataka za obuku je nestacionarna, poznata i kao Concept Drift [8]. Takve razlike predstavljaju jedinstvene izazove za istraživače i inženjere koji rade na sistemima preporuka. 1.1 Rijetkost i dinamizam Podaci za preporuke uglavnom sadrže rijetke kategorijalne značajke, od kojih se neke pojavljuju s niskom frekvencijom. Uobičajena praksa mapiranja njih u visokodimenzionalni prostor ugradnje dovodi do niza problema: • Za razliku od jezičkih modela gdje je broj dijelova riječi ograničen, broj korisnika i stavki za rangiranje je nekoliko redova veličine veći. Takva ogromna tablica ugradnje teško bi stala u memoriju jednog hosta; • Još gore, očekuje se da će veličina tablice ugradnje rasti s vremenom kako se dodaju novi korisnici i stavke, dok okviri kao što su [ , ] koriste guste varijable fiksne veličine za predstavljanje tablice ugradnje. 1 17 U praksi, mnogi sistemi usvajaju hashiranje s niskom stopom kolizija [ , ] kao način za smanjenje memorijskog otiska i omogućavanje rasta ID-ova. Ovo se oslanja na previše idealističku pretpostavku da su ID-ovi u tablici ugradnje ravnomjerno raspoređeni po frekvenciji, te da su kolizije bezopasne za kvalitet modela. Nažalost, ovo je rijetko istinito za sistem preporuka u stvarnom svijetu, gdje mala grupa korisnika ili stavki ima značajno više pojava. S organskim rastom veličine tablice ugradnje, šanse za koliziju hash ključa se povećavaju i dovode do pogoršanja kvaliteta modela 3 6 [3]. Stoga je prirodan zahtjev za sisteme preporuka produkcijske veličine da imaju kapacitet za hvatanje što više značajki u svojim parametrima, kao i mogućnost elastičnog prilagođavanja broja korisnika i stavki koje pokušavaju evidentirati. 1.2 Nestacionarna distribucija Vizuelni i jezički obrasci se jedva razvijaju u vremenskoj skali od vekova, dok korisnik zainteresovan za jednu temu može promijeniti svoj žar svakog sljedećeg minuta. Kao rezultat toga, osnovna distribucija korisničkih podataka je nestacionarna, fenomen koji se obično naziva Concept Drift [8]. Intuitivno, informacije iz novije historije mogu efikasnije doprinijeti predviđanju promjene u ponašanju korisnika. Kako bi se ublažio efekat Concept Drift-a, modeli za posluživanje moraju se ažurirati novim povratnim informacijama korisnika što je moguće bliže realnom vremenu kako bi odražavali najnoviji interes korisnika. U svjetlu ovih razlika i zapažanja problema koji proizlaze iz naše produkcije, dizajnirali smo , sistem velikih razmjera za preporuke kako bismo riješili ove bolne tačke. Proveli smo opsežne eksperimente kako bismo provjerili i iterirali naš dizajn u produkcijskom okruženju. Monolith je u mogućnosti Monolith (1) Pružiti punu izražajnu moć za rijetke značajke dizajnom hash tablice bez kolizija i mehanizmom za dinamičko izbacivanje značajki; (2) Vratiti povratne informacije iz petlje do obuke u realnom vremenu uz online obuku. Osnažen ovim arhitektonskim kapacitetima, Monolith dosljedno nadmašuje sisteme koji usvajaju hash trikove s kolizijama uz približno sličnu upotrebu memorije, te postiže najsavremeniji online AUC bez preopterećenja serverske računarske snage. Ostatak rada je organizovan kako slijedi. Prvo ćemo detaljno opisati dizajn kako Monolith rješava postojeće izazove pomoću hash tablice bez kolizija i obuke u realnom vremenu u Odjeljku 2. Eksperimenti i rezultati će biti predstavljeni u Odjeljku 3, zajedno sa zaključcima testiranim u produkciji i nekim diskusijama o kompromisima između vremenske osjetljivosti, pouzdanosti i kvaliteta modela. Odjeljak 4 sumira srodne radove i upoređuje ih s Monolithom. Odjeljak 5 sumira ovaj rad. 2 DIZAJN Ukupna arhitektura Monolith-a generalno prati TensorFlow-ovo distribuirano podešavanje Worker- arameter erver (Slika U arhitekturi Worker-PS, mašinama su dodijeljene različite uloge; Worker mašine su odgovorne za obavljanje proračuna definiranih grafom, a PS mašine pohranjuju parametre i ažuriraju ih prema gradijentima koje izračunavaju Workers. P S 2). U modelima preporuka, parametri su kategorizirani u dva skupa: gusti i rijetki. Gusti parametri su težine/varijable u dubokoj neuronskoj mreži, a rijetki parametri se odnose na tablice ugradnje koje odgovaraju rijetkim značajkama. U našem dizajnu, i gusti i rijetki parametri su dio TensorFlow Grafa i pohranjeni su na serverskim parametrima. Slično TensorFlow-ovoj Varijabli za guste parametre, dizajnirali smo skup visoko efikasnih, ne-kolizionih i fleksibilnih HashTable operacija za rijetke parametre. Kao dopuna ograničenjima TensorFlow-a koja proizlaze iz odvajanja obuke i zaključivanja, Monolith-ova elastično skalabilna online obuka je dizajnirana da efikasno sinhronizuje parametre iz trening-PS na online serving-PS unutar kratkih intervala, sa garancijom robusnosti modela obezbeđenom mehanizmom otpornosti na greške. 2.1 Hash tabela Prvi princip u našem dizajnu reprezentacije rijetkih parametara je izbjegavanje gužvanja informacija iz različitih ID-ova u istu ugradnju fiksne veličine. Simulacija dinamičke veličine tablice ugradnje pomoću TensorFlow Varijable izvan kutije neizbježno dovodi do kolizije ID-ova, što se pogoršava kako novi ID-ovi pristižu i tablica raste. Stoga, umjesto da gradimo na Varijabli, razvili smo novu HashTable ključ-vrijednost za naše rijetke parametre. Naša HashTable koristi Cuckoo Hashmap [ ] ispod haube, koja podržava umetanje novih ključeva bez kolizija s postojećim. Cuckoo Hashing postiže najgori slučaj O(1) složenost vremena za pretraživanje i brisanje, te očekivanu amortizovanu O(1) vrijeme za umetanja. Kao što je prikazano na slici , održava dvije tablice T0, T1 s različitim funkcijama hashiranja h0(x), h1(x), a element bi bio pohranjen u jednoj od njih. Prilikom pokušaja umetanja elementa 16 3 A u T0, prvo pokušava postaviti A na h0(A); Ako je h0(A) zauzeto drugim elementom B, on bi izbacio B iz T0 i pokušao umetnuti B u T1 sa istom logikom. Ovaj proces će se ponavljati dok se svi elementi ne stabilizuju, ili se dogodi rehash kada umetanje naiđe na ciklus. Smanjenje memorijskog otiska je također važan faktor u našem dizajnu. Naivni pristup umetanja svakog novog ID-a u HashTable brzo će iscrpiti memoriju. Zapažanja stvarnih produkcijskih modela dovode do dva zaključka: (1) ID-ovi koji se pojavljuju samo nekoliko puta imaju ograničen doprinos poboljšanju kvaliteta modela. Važno zapažanje je da su ID-ovi raspoređeni po dugom repu, gdje popularni ID-ovi mogu nastati milijune puta, dok se nepopularni pojavljuju najviše deset puta. Ugradnje koje odgovaraju ovim rijetkim ID-ovima su nedovoljno obučene zbog nedostatka podataka za obuku, a model neće moći napraviti dobru procjenu na osnovu njih. Na kraju krajeva, ovi ID-ovi vjerovatno neće uticati na rezultat, tako da kvalitet modela neće patiti od uklanjanja ovih ID-ova s niskim pojavljivanjima; (2) Zastarjeli ID-ovi iz daleke prošlosti rijetko doprinose trenutnom modelu jer se mnogi od njih nikada ne posjete. Ovo bi moglo biti zbog korisnika koji više nije aktivan, ili kratkog videozapisa koji je zastario. Pohranjivanje ugradnji za ove ID-ove ne može pomoći modelu ni na koji način, osim da uzalud iscrpljuje našu PS memoriju. Na osnovu ovih zapažanja, dizajnirali smo nekoliko heuristika za filtriranje ID-ova značajki za efikasniju upotrebu memorije u implementaciji HashTable: (1) ID-ovi se filtriraju prije nego što se prihvate u tablice ugradnje. Imamo dvije metode filtriranja: Prvo filtriramo po njihovim pojavljivanjima prije nego što se umetnu kao ključevi, gdje je prag pojavljivanja podesivi hiperparametar koji varira za svaki model; Dodatno koristimo probabilistički filter koji pomaže u daljem smanjenju upotrebe memorije; ![#Slika 4: Streaming Engine. Petlja povratnih informacija informacija od [Korisnik → Model Server → Training Worker → Model Server → Korisnik] bi trajala dugo kada bi slijedila put Batch Training, dok bi Online Training zatvorio petlju trenutnije.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID-ovi se vremenski označavaju i postavljaju da istekne nakon perioda neaktivnosti definiranog vremenskog perioda. Vrijeme isteka je također podesivo za svaku tablicu ugradnje kako bi se omogućilo razlikovanje značajki s različitom osjetljivošću na historijske informacije. U našoj implementaciji, HashTable je implementirana kao TensorFlow resursna operacija. Slično Varijabli, pretraživanja i ažuriranja su također implementirana kao izvorne TensorFlow operacije za lakšu integraciju i bolju kompatibilnost. 2.2 Online obuka U Monolith-u, obuka je podijeljena u dvije faze (Slika 1): (1) Faza batch obuke. Ova faza radi kao obična TensorFlow petlja obuke: U svakom koraku obuke, radnik za obuku čita mini-batch podataka za obuku iz skladišta, zahtijeva parametre od PS-a, vrši proračun naprijed i nazad, te konačno šalje ažurirane parametre trening PS-u. Neznatno drugačije od ostalih uobičajenih zadataka dubokog učenja, mi treniramo naš skup podataka samo za jedan prolaz. Batch obuka je korisna za obuku historijskih podataka kada modificiramo arhitekturu našeg modela i ponovo treniramo model; (2) Faza online obuke. Nakon što je model raspoređen za online posluživanje, obuka se ne zaustavlja, već ulazi u fazu online obuke. Umjesto čitanja mini-batch primjera iz skladišta, radnik za obuku konzumira podatke u realnom vremenu "on-the-fly" i ažurira trening PS. Trening PS periodično sinhronizuje svoje parametre sa serving PS-om, što će odmah stupiti na snagu sa korisničke strane. Ovo omogućava našem modelu da interaktivno prilagođava sebe u skladu sa povratnim informacijama korisnika u realnom vremenu. Monolith je izgrađen sa mogućnošću besprekornog prebacivanja između batch i online obuke. Ovo omogućava naš dizajn streaming engine-a kako je ilustrovano slikom 2.2.1 Streaming Engine. 4. U našem dizajnu, koristimo jednu Kafka [ ] red za logovanje akcija korisnika (npr. Klik na stavku ili lajkanje stavke itd.) i drugi Kafka red za značajke. U srcu engine-a je Flink [ ] streaming posao za online "feature Joiner". Online "joiner" konkatenira značajke sa etiketama iz korisničkih akcija i proizvodi primjere za obuku, koji se zatim zapisuju u Kafka red. Red za primjere obuke konzumiraju i online i batch obuka: 13 4 Za online obuku, radnik za obuku direktno čita podatke iz Kafka reda; Za batch obuku, posao za ispuštanje podataka će prvo ispuštati podatke u HDFS [ ]; Nakon što se podaci u HDFS-u akumuliraju do određenog iznosa, radnik za obuku će preuzeti podatke iz HDFS-a i izvršiti batch obuku. 18 Ažurirani parametri u trening PS-u će biti poslati serving PS-u prema rasporedu sinhronizacije parametara. U aplikacijama u stvarnom svijetu, logovanje korisničkih akcija i značajke se strimuju u online joiner (Slika bez garancije redoslijeda. Stoga koristimo jedinstveni ključ za svaki zahtjev kako bismo mogli pravilno upariti korisničku akciju i značajke. 2.2.2 Online Joiner. 5) Kašnjenje korisničke akcije također može biti problem. Na primjer, korisnik može odvojiti nekoliko dana prije nego što odluči kupiti stavku koju mu je predstavljena prije nekoliko dana. Ovo je izazov za joiner jer ako se sve značajke zadrže u kešu, to se jednostavno neće uklopiti u memoriju. U našem sistemu, za pohranjivanje značajki koje čekaju duže vremensko razdoblje koristi se pohrana ključ-vrijednost na disku. Kada stigne log korisničke akcije, prvo se provjerava in-memory cache, a zatim se provjerava pohrana ključ-vrijednost u slučaju da keš nedostaje. Drugi problem koji se javlja u aplikacijama u stvarnom svijetu je da je distribucija negativnih i pozitivnih primjera vrlo neujednačena, pri čemu broj prvih može biti za nekoliko redova veličine veći od drugih. Da bi se spriječilo da pozitivni primjeri budu preplavljeni negativnim, uobičajena strategija je uzorkovanje negativnih. Ovo bi svakako promijenilo osnovnu distribuciju obučenog modela, prilagođavajući ga prema većoj vjerovatnoći donošenja pozitivnih predviđanja. Kao lijek, primjenjujemo korekciju log odds [ ] tokom posluživanja, osiguravajući da je online model nepristrasan procjenitelj originalne distribucije. 19 Tokom online obuke, Monolith trening klaster nastavlja primati podatke od online serving modula i ažurira parametre na trening PS-u. Ključni korak kako bi trening PS-a imao koristi od ovih novootkrivenih parametara je sinhronizacija ažuriranih parametara modela. U produkcijskom okruženju, suočavamo se sa nekoliko izazova: 2.2.3 Sinhronizacija parametara. Modeli na online serving PS-u ne smiju prestati sa posluživanjem prilikom ažuriranja. Naši modeli u produkciji su obično nekoliko terabajta veličine, i kao rezultat toga zamjena svih parametara traje neko vrijeme. Bilo bi neprihvatljivo zaustaviti online PS od posluživanja modela tokom procesa zamjene, a ažuriranja moraju biti vršena "on-the-fly"; Prenošenje cjelokupnog modela od nekoliko terabajta iz trening PS-a u online serving PS-a predstavljalo bi ogroman pritisak kako na propusnost mreže tako i na memoriju na PS-u, jer zahtijeva dvostruku veličinu modela memorije za prijem novopristiglog modela. Da bi se online obuka skalirala na veličinu našeg poslovnog scenarija, dizajnirali smo inkrementalni mehanizam periodične sinhronizacije parametara "on-the-fly" u Monolith-u na osnovu nekoliko primjetnih karakteristika naših modela: (1) Rijetki parametri dominiraju veličinom modela preporuka; (2) Uz dat kratki vremenski period, samo se mali podskup ID-ova trenira i njihove ugradnje ažuriraju; (3) Guste varijable se kreću mnogo sporije od rijetkih ugradnji. To je zato što u optimizatorima zasnovanim na momentu, akumulacija momenta za guste varijable je uvećana ogromnom veličinom podataka za obuku preporuka, dok samo nekoliko rijetkih ugradnji prima ažuriranja u jednoj podatkovnoj grupi. (1) i (2) nam omogućavaju da iskoristimo rijetka ažuriranja preko svih ID-ova značajki. U Monolith-u, održavamo hash set dodirnutih ključeva, koji predstavlja ID-ove čije su ugradnje trenirane od posljednje sinhronizacije parametara. Mi šaljemo podskup rijetkih parametara čiji su ključevi u skupu "touched-keys" s intervalom od minute od trening PS-a do online serving PS-a. Ovaj relativno mali paket inkrementalnog ažuriranja parametara je lagan za prijenos preko mreže i neće uzrokovati oštar skok memorije tokom sinhronizacije. Također koristimo (3) za daljnje smanjenje I/O mreže i potrošnje memorije postavljanjem agresivnijeg rasporeda sinhronizacije za rijetke parametre, dok rjeđe ažuriramo guste parametre. Ovo nam može dovesti do situacije gdje je gusti parametar koji serviramo relativno zastarjela verzija u poređenju sa rijetkim dijelom. Međutim, takva nekonzistentnost se može tolerisati iz razloga navedenog u (3) jer nije primijećen nikakav upadljiv gubitak. 2.3 Otpornost na greške Kao sistem u produkciji, Monolith je dizajniran sa mogućnošću oporavka PS-a u slučaju kvara. Uobičajeni izbor za otpornost na greške je periodično snimanje stanja modela i oporavak od najnovijeg snimka kada se otkrije kvar PS-a. Izbor učestalosti snimanja ima dva glavna uticaja: (1) Kvalitet modela. Intuitivno, kvalitet modela manje pati od gubitka nedavne historije sa povećanom učestalošću snimanja. (2) Računarski overhead. Snimanje modela od nekoliko terabajta nije besplatno. To podrazumijeva velike kopije memorije i I/O diska. Kao kompromis između kvaliteta modela i računarskog overhead-a, Monolith snima sve trening PS-ove svaki dan. Iako će PS izgubiti jedan dan ažuriranja u slučaju kvara, otkrivamo da je degradacija performansi podnošljiva kroz naše eksperimente. Analizirat ćemo efekat pouzdanosti PS-a u sljedećem odjeljku. 3 EVALUACIJA Radi boljeg razumijevanja prednosti i kompromisa koje donosi naš predloženi dizajn, proveli smo nekoliko eksperimenata u produkcijskoj skali i A/B test sa živim prometom za posluživanje kako bismo procijenili i provjerili Monolith sa različitih aspekata. Cilj nam je odgovoriti na sljedeća pitanja našim eksperimentima: (1) Koliko možemo profitirati od HashTabele bez kolizija? (2) Koliko je važna online obuka u realnom vremenu? (3) Da li je Monolith-ov dizajn sinhronizacije parametara dovoljno robustan u produkcijskom scenariju velikih razmjera? U ovom odjeljku prvo predstavljamo naše eksperimentalne postavke, a zatim detaljno raspravljamo o rezultatima i našim nalazima. 3.1 Eksperimentalni setup Kao što je opisano u Odjeljku embedding tabele u Monolith-u su implementirane kao HashTabele bez kolizija. Da bismo dokazali neophodnost izbjegavanja kolizija u embedding tabelama i kvantificirali dobitke od naše implementacije bez kolizija, proveli smo dvije grupe eksperimenata na Movielens skupu podataka i na našem internom produkcijskom skupu podataka: 3.1.1 Embedding Table. 2.1, (1) ml-25m skup podataka [ ]. Ovo je standardni javni skup podataka za ocjene filmova, koji sadrži 25 miliona ocjena koje uključuju približno 162.000 korisnika i 62.000 filmova. MovieLens 11 • . Originalne etikete su ocjene od Preprocesiranje etiketa 0.5 do 5.0, dok u produkciji naši zadaci uglavnom primaju binarne signale od korisnika. Da bismo bolje simulirali naše produkcijske modele, pretvaramo skalirane etikete u binarne tako što tretiramo ocjene ≥ 3.5 kao pozitivne uzorke, a ostatak kao negativne uzorke. • Model i metrike. Implementirali smo standardni DeepFM model [9], uobičajeno korišteni arhitekturni model za probleme preporuka. Sastoji se od FM komponente i guste komponente (Slika 6). Predviđanja se procjenjuju pomoću AUC [2] jer je to glavno mjerenje za stvarne modele. • Kolizije ugradnje. Ovaj skup podataka sadrži približno 160 hiljada ID-ova korisnika i 60 hiljada ID-ova filmova. Da bismo uporedili s verzijom implementacije tablice ugradnje bez kolizija, proveli smo još jednu grupu eksperimenata gdje su ID-ovi predobrađeni MD5 hashiranjem i zatim mapirani u manji prostor ID-ova. Kao rezultat, neki ID-ovi će dijeliti svoju ugradnju s drugima. Tabela 1 prikazuje detaljnu statistiku ID-ova korisnika i filmova prije i nakon hashiranja. (2) . Interni skup podataka za preporuke Također smo proveli eksperimente na modelu preporuka u produkcijskom okruženju. Ovaj model generalno prati multi-tower arhitekturu, pri čemu je svaki toranj odgovoran za učenje predviđanja specijalizirane vrste korisničkog ponašanja. Svaki model ima oko 1000 tablica ugradnje, a distribucija veličine tablica ugradnje je vrlo neujednačena; Originalni prostor ID-a za tablicu ugradnje bio je 248. U našem osnovnom rješenju, primijenili smo hash trik dekompozicijom kako bismo smanjili veličinu tablice ugradnje. Preciznije, koristimo dvije manje tablice ugradnje umjesto jedne ogromne kako bismo generirali jedinstvenu ugradnju za svaki ID kombinacijom vektora: gdje 𝐸𝑟 , 𝐸𝑞 su ugradnje koje odgovaraju 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Ovo efektivno smanjuje veličine tablica ugradnje sa 248 na 225; • Ovaj model se poslužuje u stvarnoj produkciji, a performanse ovog eksperimenta mjere se online AUC sa stvarnim prometom za posluživanje. Tokom online obuke, ažuriramo naše online serving PS sa najnovijim skupom parametara sa intervalima od minute. Dizajnirali smo dvije grupe eksperimenata kako bismo provjerili kvalitet modela i robusnost sistema. 3.1.2 Online obuka. (1) . Da bismo istražili neophodnost učestalosti ažuriranja od minute, proveli smo eksperimente koji sinhronizuju parametre iz modela za obuku sa modelom za predviđanje sa različitim intervalima. Učestalost ažuriranja