Unutar ByteDanceovog monolita: Motor koji pokreće pametnije, brže feedove sadržaja

```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 ključna je za mnoga preduzeća koja se oslanjaju na povratne informacije kupaca u realnom vremenu, kao što su rangiranje kratkih videozapisa ili online oglasi. Uprkos širokoj upotrebi sistema za duboko učenje u produkcijskom okruženju kao što su TensorFlow ili PyTorch, ovi opšti okviri ne zadovoljavaju poslovne zahteve u scenarijima preporuka iz različitih razloga: s jedne strane, prilagođavanje sistema statičkim parametrima i gustim proračunima za preporuke sa dinamičkim i retkim karakteristikama štetno je za kvalitet modela; s druge strane, ovakvi okviri su dizajnirani sa potpuno odvojenim fazama obuke u paketima i fazama posluživanja, što sprečava model da u realnom vremenu komunicira sa povratnim informacijama kupaca. Ovi problemi su nas naveli da ponovo ispitamo tradicionalne pristupe i istražimo radikalno drugačija dizajnerska rešenja. U ovom radu predstavljamo 1, sistem prilagođen online obuci. Naš dizajn je vođen zapažanjima naših radnih opterećenja i proizvodnog okruženja, što ukazuje na značajan odmak od drugih sistema preporuka. Naši doprinosi su mnogostruki: prvo, kreirali smo tabelu ugrađivanja bez kolizija sa optimizacijama kao što su ističuća ugrađivanja i filtriranje frekvencija kako bismo smanjili njenu memorijsku veličinu; drugo, pružamo arhitekturu za online obuku spremnu za produkciju sa visokom otpornošću na greške; konačno, dokazali smo da se pouzdanost sistema može žrtvovati radi učenja u realnom vremenu. Monolith je uspešno implementiran u proizvod BytePlus Recommend2. Monolith 1 UVOD Protekla decenija svjedočila je procvatu poslovanja zasnovanog na tehnikama preporuka. U težnji ka boljem korisničkom iskustvu, pružanje personalizovanog sadržaja za svakog pojedinačnog korisnika kao odgovor u realnom vremenu zajednički je cilj ovih poslovnih aplikacija. U tu svrhu, informacije iz najnovijih interakcija korisnika često se koriste kao primarni ulaz za obuku modela, jer bi one najbolje oslikale profil korisnika i napravile predikcije o interesima i budućem ponašanju 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 konstantno se suočavaju sa problemima koji proizlaze iz jedinstvenih karakteristika podataka dobijenih iz ponašanja korisnika u stvarnom svetu. Ovi podaci se drastično razlikuju od onih korišćenih u konvencionalnim problemima dubokog učenja, kao što su modeliranje jezika ili kompjuterski vid, u dva aspekta: 5 6 10 12 20 21 (1) Karakteristike su uglavnom retke, kategorijalne i dinamički se menjaju; (2) Osnovna distribucija podataka za obuku nije stacionarna, tj. Konceptni pomak [8]. Takve razlike predstavljaju jedinstvene izazove za istraživače i inženjere koji rade na sistemima preporuka. 1.1 Rijetkost i dinamika Podaci za preporuke uglavnom sadrže retke kategorijalne karakteristike, od kojih se neke pojavljuju sa niskom frekvencijom. Uobičajena praksa mapiranja njih u prostor visoke dimenzije ugrađivanja dovodi do niza problema: • Za razliku od modela jezika gde je broj delova reči ograničen, broj korisnika i stavki za rangiranje je nekoliko redova veličine veći. Ovakva ogromna tabela ugrađivanja jedva da stane u memoriju jednog hosta; • Što je još gore, očekuje se da veličina tabele ugrađivanja raste tokom vremena kako se dodaju novi korisnici i stavke, dok okviri kao što su [ , ] koriste fiksne guste promenljive za predstavljanje tabele ugrađivanja. 1 17 U praksi, mnogi sistemi usvajaju heširanje sa niskim brojem kolizija [ , ] kao način za smanjenje memorijskog otiska i omogućavanje rasta ID-ova. Ovo se oslanja na preterano idealističku pretpostavku da su ID-ovi u tabeli ugrađivanja ravnomerno raspoređeni po učestalosti, i da kolizije ne utiču štetno na kvalitet modela. Nažalost, ovo retko važi za sistem preporuka u stvarnom svetu, gde mala grupa korisnika ili stavki ima značajno više pojava. Sa organskim rastom veličine tabele ugrađivanja, šanse za heš koliziju se povećavaju i dovode do pogoršanja kvaliteta modela 3 6 [3]. Stoga je prirodan zahtev za sisteme preporuka u produkcijskom okruženju da imaju kapacitet da obuhvate što više karakteristika u svojim parametrima, a takođe i sposobnost da elastično prilagode broj korisnika i stavki koje vode evidenciju. 1.2 Nestacionarna distribucija Vizuelni i lingvistički obrasci se jedva razvijaju u vremenskoj skali vekova, dok korisnik zainteresovan za jednu temu može promeniti svoj žar svakog sledećeg minuta. Kao rezultat toga, osnovna distribucija korisničkih podataka nije stacionarna, fenomen koji se obično naziva Konceptni pomak [8]. Intuitivno, informacije iz novije istorije mogu efikasnije doprineti predikciji promene u ponašanju korisnika. Da bi se ublažio efekat konceptnog pomaka, modeli za posluživanje moraju se ažurirati na osnovu novih povratnih informacija korisnika što je moguće bliže realnom vremenu kako bi se odrazili najnoviji interesi korisnika. U svetlu ovih razlika i uočavajući probleme koji nastaju u našoj produkciji, dizajnirali smo , sistem velikih razmjera za preporuke za rješavanje ovih bolnih tačaka. Proveli smo opsežne eksperimente kako bismo verificirali i iterirali naš dizajn u proizvodnom okruženju. Monolith je sposoban za Monolith (1) Pružanje potpune izražajne snage za retke karakteristike dizajnom heš tabele bez kolizija i mehanizma za dinamičko izbacivanje karakteristika; (2) Vraćanje povratnih informacija iz servisa u obuku u realnom vremenu putem online obuke. Omogućeni ovim arhitektonskim kapacitetima, Monolith dosledno nadmašuje sisteme koji usvajaju heš trikove sa kolizijama uz približno sličnu upotrebu memorije i postiže vrhunske rezultate u online posluživanju AUC bez prekomernog opterećenja računarske snage naših servera. Ostatak rada je organizovan na sledeći način. Prvo ćemo detaljno opisati dizajn Monolith-a u cilju rešavanja postojećih izazova sa heš tabelom bez kolizija i obukom u realnom vremenu u Odjeljku 2. Eksperimenti i rezultati će biti predstavljeni u Odjeljku 3, zajedno sa zaključcima testiranim u produkciji i nekim razmatranjima o kompromisima između vremenske osetljivosti, pouzdanosti i kvaliteta modela. Odjeljak 4 sumira srodne radove i upoređuje ih sa Monolith-om. Odjeljak 5 zaključuje ovaj rad. 2 DIZAJN Ukupna arhitektura Monolith-a uglavnom prati TensorFlow-ov distribuirani Worker- arameter erver (Slika U Worker-PS arhitekturi, mašinama su dodijeljene različite uloge; radne mašine su odgovorne za obavljanje proračuna definisanih grafom, a PS mašine pohranjuju parametre i ažuriraju ih prema gradijentima koje izračunavaju radnici. P S 2). U modelima preporuka, parametri su podijeljeni u dva skupa: gusti i retki. Gusti parametri su težine/promjenljive u dubokoj neuronskoj mreži, a retki parametri se odnose na tabele ugrađivanja koje odgovaraju retkim karakteristikama. U našem dizajnu, i gusti i retki parametri su dio TensorFlow Grapha i pohranjeni su na serverskim parametrima. Slično TensorFlow Variable za guste parametre, dizajnirali smo skup visoko efikasnih, beskolizijskih i fleksibilnih HashTable operacija za retke parametre. Kao dopuna ograničenjima TensorFlow-a koja proizilaze iz odvajanja obuke i zaključivanja, online obuka Monolith-a koja se elastično skalira dizajnirana je za efikasnu sinhronizaciju parametara iz training-PS u online serving-PS u kratkim intervalima, sa garancijom robusnosti modela obezbeđenom mehanizmom tolerancije grešaka. 2.1 Heš tabela Prvi princip u našem dizajnu reprezentacije retkih parametara je izbegavanje gužvanja informacija iz različitih ID-ova u isto ugrađivanje fiksne veličine. Simulacija tabele ugrađivanja dinamičke veličine sa postojećim TensorFlow Variable-om neizbežno dovodi do ID kolizije, koja se pogoršava kako novi ID-ovi pristižu i tabela raste. Stoga smo, umesto da gradimo na Variable, razvili novu HashTable ključ-vrednost za naše retke parametre. Naša HashTable koristi Cuckoo Hashmap [ ] interno, koja podržava umetanje novih ključeva bez kolizija sa postojećim. Cuckoo Hashing postiže O(1) vremensku složenost u najgorem slučaju za pretrage i brisanja, i očekivanu amortizovanu O(1) vreme za umetanje. Kao što je ilustrovano na Slici , ona održava dve tabele T0, T1 sa različitim heš funkcijama h0(x), h1(x), i element bi bio pohranjen u jednoj od njih. Prilikom pokušaja umetanja elementa 16 3 A u T0, prvo pokušava da postavi A na h0(A); Ako je h0(A) zauzeto drugim elementom B, ono će izbaciti B iz T0 i pokušati da umetne B u T1 sa istom logikom. Ovaj proces će se ponavljati dok se svi elementi ne stabilizuju, ili se izvrši ponovno heširanje kada umetanje naiđe na ciklus. Smanjenje memorijskog otiska je takođe važan aspekt našeg dizajna. Naivan pristup umetanja svakog novog ID-a u HashTable brzo će iscrpiti memoriju. Posmatranja stvarnih proizvodnih 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 distribuirani po dugom repu, gde popularni ID-ovi mogu da se pojave milionima puta, dok se nepopularni pojavljuju najviše deset puta. Ugrađivanja koja odgovaraju ovim nečestim ID-ovima su nedovoljno obučena zbog nedostatka podataka za obuku i model neće moći da napravi dobru procenu na osnovu njih. Na kraju krajeva, ovi ID-ovi verovatno neće uticati na rezultat, tako da kvalitet modela neće patiti od uklanjanja ovih ID-ova sa niskom učestalošću; (2) Zastareli ID-ovi iz daleke prošlosti retko doprinose trenutnom modelu jer im se mnogi nikada ne pristupa. Ovo može biti zbog korisnika koji više nije aktivan, ili kratkog videa koji je zastareo. Pohranjivanje ugrađivanja 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 karakteristika za efikasniju implementaciju HashTable-a: (1) ID-ovi se filtriraju pre nego što se prihvate u tabele ugrađivanja. Imamo dve metode filtriranja: Prvo filtriramo po njihovoj učestalosti pre nego što se umetnu kao ključevi, gde je prag učestalosti podesiv hiperparametar koji varira za svaki model; Dodatno koristimo probabilistički filter koji pomaže u daljem smanjenju korišćenja memorije; ![#Slika 4: Streaming Engine. Petlja povratnih informacija iz [Korisnik → Model Server → Training Worker → Model Server → Korisnik] bi trajala dugo kada bi se koristio Batch Training put, dok bi Online Training zatvorio petlju odmah.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID-ovi su vremenski obeleženi i postavljeni da isteknu nakon perioda neaktivnosti. Vreme isteka je takođe podesivo za svaku tabelu ugrađivanja kako bi se omogućilo razlikovanje karakteristika sa različitom osetljivošću na istorijske informacije. U našoj implementaciji, HashTable je implementiran kao TensorFlow resursna operacija. Slično Variable, pretrage i ažuriranja su takođe implementirani kao nativne 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 obuke u paketima. Ova faza radi kao obična TensorFlow petlja obuke: U svakom koraku obuke, radnik za obuku čita mini-paket podataka za obuku iz skladišta, zahteva parametre od PS-a, vrši forward i backward prolaz, i konačno šalje ažurirane parametre trening PS-u. Nešto drugačije od ostalih uobičajenih zadataka dubokog učenja, mi treniramo naš skup podataka samo jednom. Batch obuka je korisna za obuku istorijskih podataka kada modifikujemo arhitekturu našeg modela i ponovo treniramo model; (2) Faza online obuke. Nakon što je model postavljen na online server, obuka se ne zaustavlja već ulazi u fazu online obuke. Umjesto čitanja mini-paketa podataka iz skladišta, radnik za obuku obrađuje podatke u realnom vremenu "on-the-fly" i ažurira trening PS. Trening PS periodično sinhronizuje svoje parametre sa serving PS-om, što odmah stupa na snagu na strani korisnika. Ovo omogućava našem modelu da interaktivno prilagođava sebe prema povratnim informacijama korisnika u realnom vremenu. Monolith je izgrađen sa mogućnošću bešavnog prebacivanja između batch obuke i online obuke. Ovo je omogućeno našim dizajnom streaming engine-a kako je ilustrovano slikom 2.2.1 Streaming Engine. 4. U našem dizajnu, koristimo jedan Kafka [ ] red za logovanje akcija korisnika (npr. Klik na stavku ili lajkanje stavke itd.) i drugi Kafka red za karakteristike. U srcu engine-a je Flink [ ] streaming job za online karakteristike Joiner. Online joiner spaja karakteristike sa etiketama iz korisničkih akcija i proizvodi primere za obuku, koji se zatim upisuju u Kafka red. Red za primere za obuku konzumiraju kako online obuka, tako i batch obuka: 13 4 Za online obuku, radnik za obuku direktno čita podatke iz Kafka reda; Za batch obuku, job 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 iz stvarnog sveta, logovi korisničkih akcija i karakteristike se strimuju u online joiner (Slika bez garancije redosleda. Stoga koristimo jedinstveni ključ za svaki zahtev tako da se korisnička akcija i karakteristike mogu ispravno upariti. 2.2.2 Online Joiner. 5) Kašnjenje korisničke akcije takođe može biti problem. Na primer, korisnik može provesti nekoliko dana pre nego što odluči da kupi artikal koji mu je predstavljen pre nekoliko dana. Ovo je izazov za joiner jer ako sve karakteristike ostanu u kešu, one jednostavno neće stati u memoriju. U našem sistemu, koristi se skladište ključ-vrednost na disku za pohranjivanje karakteristika koje čekaju duži vremenski period. Kada stigne log korisničke akcije, on prvo pretražuje in-memory keš, a zatim pretražuje skladište ključ-vrednost u slučaju nedostajućeg keša. Drugi problem koji se javlja u aplikacijama iz stvarnog sveta je da je distribucija negativnih i pozitivnih primera veoma neujednačena, pri čemu broj prvih može biti znatno veći od broja drugih. Da bi se sprečilo da pozitivni primeri budu preplavljeni negativnim, uobičajena strategija je uzorkovanje negativnih primera. Ovo bi svakako promenilo osnovnu distribuciju obučenog modela, prilagođavajući ga ka većoj verovatnoći pravljenja pozitivnih predikcija. Kao lek, primenjujemo log odds korekciju [ ] tokom posluživanja, osiguravajući da je online model nepristrasan procenitelj originalne distribucije. 19 Tokom online obuke, Monolith klaster za obuku nastavlja da prima podatke od online modula za posluživanje i ažurira parametre na trening PS-u. Ključni korak da bi online serving PS-ovi imali koristi od ovih novoo obučenih parametara je sinhronizacija ažuriranih parametara modela. U proizvodnom okruženju, suočavamo se sa nekoliko izazova: 2.2.3 Sinhronizacija parametara. Modeli na online serving PS-ovima ne smeju prestati sa radom prilikom ažuriranja. Naši modeli u proizvodnji su obično nekoliko terabajta veličine, i kao rezultat toga zamena svih parametara traje neko vreme. Bilo bi neprihvatljivo zaustaviti online PS od posluživanja modela tokom procesa zamene, i ažuriranja moraju biti vršena "on-the-fly"; Prenos modela od više terabajta u celosti sa trening PS-a na online serving PS-a bi stavio ogroman pritisak kako na propusnost mreže, tako i na memoriju na PS-u, jer zahteva udvostručenu veličinu memorije za prihvatanje 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 zasnovan na nekoliko primetnih karakteristika naših modela: (1) Retki parametri dominiraju veličinom modela preporuka; (2) U datom kratkom vremenskom periodu, samo mali podskup ID-ova se obučava i njihova ugrađivanja se ažuriraju; (3) Guste promenljive se kreću mnogo sporije od retkih ugrađivanja. Ovo je zato što se u optimizatorima zasnovanim na momentumu, akumulacija momenta za guste promenljive uvećava gigantskom veličinom podataka za obuku preporuka, dok samo nekoliko retkih ugrađivanja prima ažuriranja u jednoj mini-batchi podataka. (1) i (2) nam omogućavaju da iskoristimo retka ažuriranja preko svih ID-ova karakteristika. U Monolith-u, održavamo heš skup dodirnutih ključeva, koji predstavlja ID-ove čija su ugrađivanja obučena od poslednje sinhronizacije parametara. Šaljemo podskup retkih parametara čiji su ključevi u setu "touched-keys" sa vremenskim intervalom od minuta od trening PS-a do online serving PS-a. Ovaj relativno mali paket inkrementalnog ažuriranja parametara je lagan za prenos mrežom i neće izazvati oštar porast memorije tokom sinhronizacije. Takođe koristimo (3) za dalje smanjenje mrežnog I/O i upotrebe memorije postavljanjem agresivnijeg rasporeda sinhronizacije za retke parametre, dok ažuriramo guste parametre ređe. Ovo nas može dovesti do situacije gde su gusti parametri koje serviramo relativno zastarela verzija u poređenju sa retkim delom. Međutim, takva nekonzistentnost se može tolerisati zbog razloga pomenutog u (3), jer nije primećen nikakav primetan 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 detektuje kvar PS-a. Izbor učestalosti snimanja ima dva glavna uticaja: (1) Kvalitet modela. Intuitivno, kvalitet modela manje pati od gubitka nedavne istorije sa povećanom učestalošću snimanja. (2) Računarski režijski troškovi. Snimanje modela od više terabajta nije besplatno. Zahteva velike kopije memorije i disk I/O. Kao kompromis između kvaliteta modela i računarskih režijskih troškova, Monolith snima sve trening PS-ove svakodnevno. Iako će PS izgubiti jedan dan ažuriranja u slučaju kvara, otkrili smo da je degradacija performansi podnošljiva kroz naše eksperimente. Analiziraćemo efekat pouzdanosti PS-a u sledećem odeljku. 3 EVALUACIJA Radi boljeg razumevanja prednosti i kompromisa koje donosi naš predloženi dizajn, sproveli smo nekoliko eksperimenata u produkcijskom obimu i A/B testiranje sa uživo saobraćajem za posluživanje kako bismo Monolith evaluirali i verifikovali iz različitih aspekata. Cilj nam je da odgovorimo na sledeća pitanja našim eksperimentima: (1) Koliko možemo profitirati od HashTable-a bez kolizija? (2) Koliko je važna online obuka u realnom vremenu? (3) Da li je Monolithov dizajn sinhronizacije parametara dovoljno robustan u velikom proizvodnom scenariju? U ovom odeljku prvo predstavljamo naše eksperimentalne postavke, a zatim detaljno raspravljamo o rezultatima i našim nalazima. 3.1 Eksperimentalna postavka Kao što je opisano u Odjeljku tabele ugrađivanja u Monolith-u su implementirane kao heš tabele bez kolizija. Da bismo dokazali neophodnost izbegavanja kolizija u tabelama ugrađivanja i kvantifikovali dobitke od naše implementacije bez kolizija, sproveli smo dve 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 ocene filmova, koji sadrži 25 miliona ocena koje uključuju približno 162.000 korisnika i 62.000 filmova. MovieLens 11 • . Originalne etikete su ocene od Predobrada etiketa 0.5 do 5.0, dok su u produkciji naši zadaci uglavnom primanje binarnih signala od korisnika. Da bismo bolje simulirali naše produkcijske modele, pretvaramo skalirane etikete u binarne etikete tretirajući ocene ≥ 3.5 kao pozitivne uzorke, a ostatak kao negativne uzorke. • Model i metrike. Implementirali smo standardni DeepFM [9] model, često korišćen model arhitekture za probleme preporuka. Sastoji se od FM komponente i guste komponente (Slika 6). Predikcije se evaluiraju pomoću AUC [2] jer je to glavno merenje za realne modele. • Kolizije ugrađivanja. Ovaj skup podataka sadrži približno 160K korisničkih ID-ova i 60K ID-ova filmova. Da bismo uporedili sa implementacijom tabele ugrađivanja bez kolizija, sproveli smo još jednu grupu eksperimenata gde su ID-ovi predobrađeni MD5 heširanjem, a zatim mapirani u manji ID prostor. Kao rezultat, neki ID-ovi će deliti svoje ugrađivanje sa drugima. Tabela 1 prikazuje detaljne statistike korisničkih ID-ova i ID-ova filmova pre i posle heširanja. (2) . Interni skup podataka za preporuke Takođe smo sproveli eksperimente na modelu preporuka u proizvodnom okruženju. Ovaj model generalno prati višestambenu arhitekturu, gde je svaka stabljika odgovorna za učenje predikcije specifične vrste korisničkog ponašanja. Svaki model ima oko 1000 tabela ugrađivanja, a distribucija veličine tabela ugrađivanja je veoma neujednačena; Originalni ID prostor ugrađivanja bio je 248. U našem baznom modelu, primenili smo trik heširanja dekompozicijom kako bismo smanjili veličinu tabele ugrađivanja. Preciznije, koristimo dve manje tabele ugrađivanja umesto jedne gigantske da bismo generisali jedinstveni ugrađivanje za svaki ID kombinacijom vektora: gde su 𝐸𝑟 , 𝐸𝑞 ugrađivanja koja odgovaraju ID𝑟 , ID𝑞. Ovo efikasno smanjuje veličinu tabele ugrađivanja sa 248 na 225; • Ovaj model se servira u realnoj produkciji, a performanse ovog eksperimenta se mere online AUC sa stvarnim saobraćajem za serviranje. Tokom online obuke, ažuriramo naše online serving PS sa najnovijim skupom parametara sa intervalima od minuta. Dizajnirali smo dve grupe eksperimenata da bismo verifikovali kvalitet modela i robusnost sistema. 3.1.2 Online obuka. (1) . Da bismo istražili neophodnost učestalosti ažuriranja od minuta, sproveli smo eksperimente koji sinhronizuju parametre iz modela za obuku sa modelom za predikciju sa različitim intervalima. Učestalost ažuriranja