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∗, Sveučilište 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 sustava za preporuke u stvarnom vremenu ključna je za mnoga poduzeća koja se temelje na povratnim informacijama kupaca osjetljivim na vrijeme, poput rangiranja kratkih videozapisa ili internetskih oglasa. Unatoč sveprisutnom usvajanju okvira dubokog učenja na produkcijskoj razini poput Ten-sorFlow ili PyTorch, ti okviri opće namjene ne zadovoljavaju poslovne zahtjeve u scenarijima preporuka iz raznih razloga: s jedne strane, prilagođavanje sustava na temelju statičkih parametara i gustih izračuna za preporuku s dinamičkim i rijetkim značajkama štetno je za kvalitetu modela; s druge strane, takvi okviri dizajnirani su s potpuno odvojenom fazom batch treninga i fazom posluživanja, sprječavajući model da u stvarnom vremenu komunicira s povratnim informacijama kupaca. Ti problemi naveli su nas da ponovno razmotrimo tradicionalne pristupe i istražimo radikalno drugačije dizajnerske izbore. U ovom radu predstavljamo 1, sustav prilagođen za online trening. Naš dizajn vođen je opažanjima naših radnih opterećenja aplikacija i produkcijskog okruženja, što odražava znatno odstupanje od drugih sustava preporuka. Naši doprinosi su mnogostruki: prvo, izradili smo tablicu embeddinga bez kolizija s optimizacijama poput izbrisivih embeddinga i filtriranja frekvencija kako bismo smanjili njezin memorijski otisak; drugo, pružamo produkcijsku arhitekturu za online trening s visokom otpornošću na greške; konačno, dokazali smo da se pouzdanost sustava može žrtvovati za učenje u stvarnom vremenu. Monolith je uspješno implementiran u proizvod BytePlus Recommend2. Monolith 1 UVOD Prošlo desetljeće svjedočilo je procvatu poslovanja potpomognutih tehnikama preporuka. U potrazi za boljim korisničkim iskustvom, isporuka personaliziranog sadržaja za svakog pojedinačnog korisnika kao odgovor u stvarnom vremenu uobičajeni je cilj ovih poslovnih aplikacija. U tu svrhu, informacije iz najnovije interakcije korisnika često se koriste kao primarni ulaz za treniranje modela, jer bi najbolje prikazale profil korisnika i predvidjele korisnički interes i buduća ponašanja. Duboko učenje dominiralo je modelima preporuka [ , , , , , ] jer je golema količina korisničkih podataka prirodno prikladna za masovno podatkovno vođene neuralne modele. Međutim, napori da se iskoristi snaga dubokog učenja u industrijskim sustavima preporuka stalno se suočavaju s problemima koji proizlaze iz jedinstvenih karakteristika podataka izvedenih iz stvarnog ponašanja korisnika. Ovi podaci drastično se razlikuju od onih koji se koriste u konvencionalnim problemima dubokog učenja poput modeliranja jezika ili računalnog vida u dva aspekta: 5 6 10 12 20 21 (1) Značajke su uglavnom rijetke, kategoričke i dinamički se mijenjaju; (2) > Temeljna distribucija podataka za trening je nestacionarna, tj. Konceptualni pomak [8]. Takve razlike predstavljaju jedinstvene izazove za istraživače i inženjere koji rade na sustavima preporuka. 1.1 Rijetkost i dinamizam Podaci za preporuke uglavnom sadrže rijetke kategoričke značajke, od kojih se neke pojavljuju s niskom učestalošću. Uobičajena praksa mapiranja njih u visokodimenzionalni prostor embeddinga dovodi do niza problema: • Za razliku od jezičnih modela gdje je broj jezičnih dijelova ograničen, broj korisnika i stavki za rangiranje je redoslijedom veći. Takva ogromna tablica embeddinga teško bi stala u memoriju jednog hosta; • > Još gore, očekuje se da će se veličina tablice embeddinga povećavati tijekom vremena kako se dodaje više korisnika i stavki, dok okviri poput [ , ] koriste guste varijable fiksne veličine za predstavljanje tablice embeddinga. 1 17 U praksi, mnogi sustavi koriste hashiranje s niskim kolizijama [ , ] kao način smanjenja memorijskog otiska i dopuštanja rasta ID-ova. Ovo se oslanja na previše idealističku pretpostavku da su ID-ovi u tablici embeddinga ravnomjerno raspoređeni po učestalosti, a kolizije su bezopasne za kvalitetu modela. Nažalost, to je rijetko istinito za sustav preporuka iz stvarnog svijeta, gdje mala skupina korisnika ili stavki ima znatno više pojavljivanja. S organskim rastom veličine tablice embeddinga, šanse za koliziju hash ključeva se povećavaju i dovode do pogoršanja kvalitete modela 3 6 [3]. Stoga je prirodan zahtjev za sustave preporuka na produkcijskoj razini da imaju kapacitet obuhvatiti što više značajki u svojim parametrima, te također mogućnost elastičnog prilagođavanja broja korisnika i stavki koje pokušavaju evidentirati. 1.2 Nestacionarna distribucija Vizualni i jezični obrasci jedva se razvijaju u vremenskom mjerilu stoljeća, dok se isti korisnik zainteresiran za jednu temu može odmaknuti od svog entuzijazma svake sljedeće minute. Kao rezultat toga, temeljna distribucija korisničkih podataka je nestacionarna, fenomen koji se obično naziva Konceptualni pomak [8]. Intuitivno, informacije iz novije povijesti mogu učinkovitije doprinijeti predviđanju promjene u ponašanju korisnika. Kako bi se ublažio učinak konceptualnog pomaka, modeli posluživanja moraju se ažurirati iz novih povratnih informacija korisnika što je moguće bliže stvarnom vremenu kako bi odražavali najnoviji interes korisnika. S obzirom na ove razlike i na probleme koji proizlaze iz naše proizvodnje, dizajnirali smo , sustav velikog razmjera za preporuke za rješavanje ovih problema. Proveli smo opsežne eksperimente kako bismo provjerili i iterirali naš dizajn u produkcijskom okruženju. Monolith je sposoban Monolith (1) Pružiti punu izražajnu moć za rijetke značajke dizajnom hash tablice bez kolizija i mehanizmom za izbacivanje dinamičkih značajki; (2) Vratiti povratne informacije s posluživanja u trening u stvarnom vremenu uz online trening. Omogućen ovim arhitektonskim kapacitetima, Monolith dosljedno nadmašuje sustave koji koriste hash-trikove s kolizijama uz otprilike sličnu upotrebu memorije, te postiže najsuvremeniji online AUC bez preopterećenja računalne snage naših poslužitelja. Ostatak rada organiziran je kako slijedi. Prvo detaljno opisujemo kako Monolith rješava postojeće izazove pomoću hash tablice bez kolizija i treninga u stvarnom vremenu u Odjeljku 2. Eksperimenti i rezultati bit će predstavljeni u Odjeljku 3, zajedno sa zaključcima testiranim u proizvodnji i nekim raspravama o kompromisima između vremenske osjetljivosti, pouzdanosti i kvalitete modela. Odjeljak 4 sažima srodne radove i uspoređuje ih s Monolithom. Odjeljak 5 zaključuje ovaj rad. 2 DIZAJN Ukupna arhitektura Monolitha općenito slijedi TensorFlowovo distribuirano postavljanje Worker- arameter erver (Slika U arhitekturi Worker-PS, strojevima se dodjeljuju različite uloge; Worker strojevi odgovorni su za izvođenje izračuna definiranim grafom, a PS strojevi 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 neuralnoj mreži, a rijetki parametri odnose se na tablice embeddinga koje odgovaraju rijetkim značajkama. U našem dizajnu, i gusti i rijetki parametri dio su TensorFlow Grafa i pohranjeni su na poslužiteljima parametara. Slično TensorFlowovoj Varijabli za guste parametre, dizajnirali smo skup visoko učinkovitih, bezkolizijskih i fleksibilnih HashTable operacija za rijetke parametre. Kao dopuna ograničenjima Tensor-Flowa koja proizlaze iz odvajanja treninga i inferencije, Monolithov elastično skalabilni online trening dizajniran je za učinkovito sinkroniziranje parametara s trening-PS-a na online posluživanje-PS-a unutar kratkih intervala, uz jamstvo robusnosti modela osigurano mehanizmom otpornosti na greške. 2.1 Hash tablica Prvo načelo u našem dizajnu reprezentacije rijetkih parametara je izbjegavanje gužvanja informacija iz različitih ID-ova u isti embedding fiksne veličine. Simulacija dinamičke veličine tablice embeddinga s TensorFlow Varijablom izvan kutije neizbježno dovodi do kolizije ID-ova, koja se pogoršava kako dolaze novi ID-ovi i tablica raste. Stoga smo umjesto da se oslanjamo na Varijablu, razvili 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ćima. Cuckoo Hashing postiže vremensku složenost 𝑂(1) u najgorem slučaju za pretrage i brisanja, te očekivanu amortiziranu 𝑂(1) vremensku složenost za umetanja. Kao što je ilustrirano na slici , održava dvije tablice 𝑇0, 𝑇1 s različitim hash funkcijama ℎ0 (𝑥), ℎ1 (𝑥), a element bi bio pohranjen u jednoj od njih. Prilikom pokušaja umetanja elementa 16 3 𝐴 u 𝑇0, prvo pokušava postaviti 𝐴 na ℎ0 (𝐴); Ako je ℎ0 (𝐴) zauzet drugim elementom 𝐵, on bi izbacio 𝐵 iz 𝑇0 i pokušao umetnuti 𝐵 u 𝑇1 s istom logikom. Ovaj proces će se ponavljati dok se svi elementi ne stabiliziraju, ili se dogodi ponovno hashiranje kada umetanje naiđe na ciklus. Smanjenje memorijskog otiska također je važan razmatranje u našem dizajnu. Naivan pristup umetanja svakog novog ID-a u HashTable brzo će iscrpiti memoriju. Opažanja stvarnih produkcijskih modela vode do dva zaključka: (1) ID-ovi koji se pojavljuju samo nekoliko puta imaju ograničen doprinos poboljšanju kvalitete modela. Važno je opažanje da su ID-ovi distribuirani po dugom repu, gdje popularni ID-ovi mogu nastupiti milijune puta, dok se nepoulearni pojavljuju najviše deset puta. Embeddingi koji odgovaraju ovim rijetkim ID-ovima nedovoljno su trenirani zbog nedostatka podataka za trening i model neće moći donijeti dobru procjenu na temelju njih. Na kraju krajeva, ti ID-ovi vjerojatno neće utjecati na rezultat, tako da kvaliteta modela neće patiti od uklanjanja ovih ID-ova s niskom učestalošću; (2) > Zastarjeli ID-ovi iz udaljene povijesti rijetko doprinose trenutnom modelu jer ih se mnogi nikada ne posjeti. To bi moglo biti zbog korisnika koji više nije aktivan, ili kratkog videozapisa koji je zastario. Pohranjivanje embeddinga za ove ID-ove ne može pomoći modelu ni na koji način, osim da uzalud iscrpi našu PS memoriju. Na temelju ovih opažanja, dizajnirali smo nekoliko heuristika za filtriranje ID-ova značajki za učinkovitiju implementaciju HashTable-a: (1) ID-ovi se filtriraju prije nego što se prihvate u tablice embeddinga. Imamo dvije metode filtriranja: Prvo, filtriramo po njihovoj učestalosti prije nego što se umetnu kao ključevi, gdje je prag učestalosti podesivi hiperparametar koji varira za svaki model; Osim toga, koristimo probabilistički filter koji pomaže daljnje smanjenje upotrebe memorije; ![#Slika 4: Streaming Engine. Petlja povratnih informacija iz [Korisnik → Model Server → Training Worker → Model Server → Korisnik] trajala bi dugo ako bi slijedila Batch Training put, dok bi Online Training zatvorio petlju trenutačnije.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID-ovima se dodjeljuje vrijeme i postavljaju se da isteknu nakon što su neaktivni određeno razdoblje. Vrijeme isteka je također podesivo za svaku tablicu embeddinga kako bi se razlikovali značajke s različitom osjetljivošću na povijesne informacije. U našoj implementaciji, HashTable je implementirana kao TensorFlow resursna operacija. Slično Varijabli, pretrage i ažuriranja također su implementirani kao izvorne TensorFlow operacije za lakšu integraciju i bolju kompatibilnost. 2.2 Online trening U Monolithu, trening je podijeljen u dvije faze (Slika 1): (1) Faza batch treninga. Ova faza radi kao uobičajena TensorFlow trening petlja: U svakom koraku treninga, worker za trening čita jedan mini-batch primjera za trening iz pohrane, zahtijeva parametre od PS-a, izračunava prednji i stražnji prolaz, te 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 jedanput. Batch trening je koristan za treniranje povijesnih podataka kada modificiramo arhitekturu našeg modela i ponovno treniramo model; (2) Faza online treninga. Nakon što je model postavljen za online posluživanje, trening se ne zaustavlja, već ulazi u fazu online treninga. Umjesto čitanja mini-batch primjera iz pohrane, worker za trening obrađuje podatke u stvarnom vremenu "on-the-fly" i ažurira trening-PS. Trening-PS periodično sinkronizira svoje parametre s poslužujućim-PS-om, što će odmah stupiti na snagu na strani korisnika. Ovo omogućuje našem modelu da interaktivno prilagođava sebe prema povratnim informacijama korisnika u stvarnom vremenu. Monolith je izgrađen sa sposobnošću bešavnog prebacivanja između batch treninga i online treninga. To je omogućeno našim dizajnom streaming engine-a, kako je ilustrirano slikom 2.2.1 Streaming Engine. 4. U našem dizajnu, koristimo jednu Kafka [ ] red za logiranje akcija korisnika (npr. Klik na stavku ili lajkaj stavku itd.) i drugu Kafka red za značajke. U srcu engine-a je Flink [ ] streaming posao za online spajanje značajki. Online spojnik spaja značajke s oznakama iz korisničkih akcija i proizvodi primjere za trening, koji se zatim zapisuju u Kafka red. Red za primjere treninga konzumiraju i online trening i batch trening: 13 4 Za online trening, worker za trening izravno čita podatke iz Kafka reda; Za batch trening, posao ispuštanja podataka prvo ispušta podatke u HDFS [ ]; Nakon što se podaci u HDFS-u akumuliraju do određene količine, worker za trening dohvaća podatke iz HDFS-a i izvodi batch trening. 18 Ažurirani parametri u trening-PS-u bit će poslani poslužujućem-PS-u prema rasporedu sinkronizacije parametara. U aplikacijama iz stvarnog svijeta, log korisničkih akcija i značajke streamaju se u online spojnik (Slika bez jamstva vremenskog redoslijeda. Stoga koristimo jedinstveni ključ za svaki zahtjev kako bi se korisnička akcija i značajke mogle ispravno upariti. 2.2.2 Online Spojnik. 5) Zaostajanje korisničke akcije također može biti problem. Na primjer, korisnik može proći nekoliko dana prije nego što odluči kupiti stavku koja mu je prikazana prije nekoliko dana. Ovo je izazov za spojnik jer ako se sve značajke zadrže u cacheu, jednostavno neće stati u memoriju. U našem sustavu koristi se pohrana ključ-vrijednost na disku za pohranjivanje značajki koje čekaju dulje vremensko razdoblje. Kada stigne log korisničke akcije, prvo traži u cacheu u memoriji, a zatim traži u pohrani ključ-vrijednost u slučaju da cache nedostaje. Drugi problem koji se javlja u aplikacijama iz stvarnog svijeta je da je distribucija negativnih i pozitivnih primjera vrlo nejednaka, gdje broj prvih može biti red veličine veći od potonjih. Kako bi se spriječilo da pozitivni primjeri budu preplavljeni negativnim, uobičajena strategija je negativno uzorkovanje. Ovo bi svakako promijenilo temeljnu distribuciju treniranog modela, prilagođavajući ga većoj vjerojatnosti pozitivnih predviđanja. Kao lijek, primjenjujemo korekciju logaritma šansi [ ] tijekom posluživanja, osiguravajući da je online model nepristran estimator izvorne distribucije. 19 Tijekom online treninga, Monolith trening klaster nastavlja primati podatke iz online modula posluživanja i ažurira parametre na trening-PS-u. Ključni korak kako bi trening-PS mogao imati koristi od ovih novootkrivenih parametara je sinkronizacija ažuriranih parametara modela. U produkcijskom okruženju suočeni smo s nekoliko izazova: 2.2.3 Sinkronizacija parametara. Modeli na online poslužujućem-PS-u ne smiju prestati s posluživanjem prilikom ažuriranja. Naši modeli u proizvodnji obično su veličine nekoliko terabajta, te stoga zamjena svih parametara traje neko vrijeme. Bilo bi neprihvatljivo zaustaviti online-PS od posluživanja modela tijekom procesa zamjene, a ažuriranja se moraju vršiti "on-the-fly"; Prenošenje cjelokupnog modela od više terabajta s trening-PS-a na online poslužujući-PS stvorilo bi ogroman pritisak kako na propusnost mreže, tako i na memoriju na PS-u, jer zahtijeva dvostruku veličinu memorije za prihvaćanje novog modela. Kako bi se online trening skalirao na veličinu našeg poslovnog scenarija, dizajnirali smo inkrementalni mehanizam periodične sinkronizacije parametara "on-the-fly" u Monolithu, temeljen na nekoliko uočljivih karakteristika naših modela: (1) Rijetki parametri dominiraju veličinom modela preporuka; (2) > S obzirom na kratki vremenski prozor, samo se mali podskup ID-ova trenira i njihovi embeddingi ažuriraju; (3) > Guste varijable kreću se mnogo sporije od rijetkih embeddinga. To je zato što u optimizatorima temeljenim na zamahu, akumulacija zamaha za guste varijable pojačava ogromna veličina podataka za trening preporuka, dok samo nekoliko rijetkih embeddinga prima ažuriranja u jednoj grupi podataka. (1) i (2) nam omogućuju iskorištavanje rijetkih ažuriranja preko svih ID-ova značajki. U Monolithu održavamo hash set dodirnutih ključeva, koji predstavlja ID-ove čiji su embeddingi trenirani od posljednje sinkronizacije parametara. Šaljemo podskup rijetkih parametara čiji su ključevi u setu dodirnutih ključeva s vremenskim intervalom od minute od trening-PS-a do online poslužujućeg-PS-a. Ovaj relativno mali paket inkrementalnih ažuriranja parametara lagan je za prijenos putem mreže i neće uzrokovati oštar skok memorije tijekom sinkronizacije. Također iskorištavamo (3) kako bismo dodatno smanjili I/O mreže i upotrebu memorije postavljanjem agresivnijeg rasporeda sinkronizacije za rijetke parametre, dok guste parametre ažuriramo rjeđe. Ovo nam može dati situaciju gdje su gusti parametri koje poslužujemo relativno zastarjela verzija u usporedbi s rijetkim dijelom. Međutim, takva nedosljednost može se tolerirati zbog razloga navedenog u (3), jer nije primijećen nikakav vidljiv gubitak. 2.3 Otpornost na greške Kao sustav u proizvodnji, Monolith je dizajniran sa sposobnošć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 posljednjeg snimka kada se otkrije kvar PS-a. Izbor frekvencije snimanja ima dva glavna utjecaja: (1) Kvaliteta modela. Intuitivno, kvaliteta modela manje pati od gubitka nedavne povijesti s povećanom frekvencijom snimanja. (2) > Računalni overhead. Snimanje modela od više terabajta nije besplatno. To uzrokuje velike kopije memorije i I/O diska. Kao kompromis između kvalitete modela i računalnog overheada, Monolith snima sve trening PS-eve 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 učinak pouzdanosti PS-a u sljedećem odjeljku. 3 EVALUACIJA Za bolje razumijevanje prednosti i kompromisa koje donosi naš predloženi dizajn, proveli smo nekoliko eksperimenata na produkcijskoj razini i A/B testiranje sa stvarnim prometom kako bismo evaluirali i provjerili Monolith iz različitih aspekata. Cilj nam je odgovoriti na sljedeća pitanja našim eksperimentima: (1) > Koliko možemo profitirati od HashTable bez kolizija? (2) > Koliko je važan online trening u stvarnom vremenu? (3) > Je li Monolithov dizajn sinkronizacije parametara dovoljno robustan u velikom produkcijskom scenariju? U ovom odjeljku prvo predstavljamo naše eksperimentalne postavke, a zatim detaljno raspravljamo o rezultatima i našim nalazima. 3.1 Eksperimentalne postavke Kao što je opisano u Odjeljku tablice embeddinga u Monolithu implementirane su kao HashTables bez kolizija. Kako bismo dokazali nužnost izbjegavanja kolizija u tablicama embeddinga i kvantificirali dobitke od naše implementacije bez kolizija, proveli smo dvije grupe eksperimenata na skupu podataka Movielens i na našem internom produkcijskom skupu podataka: 3.1.1 Tablica Embeddinga. 2.1, (1) ml-25m skup podataka [ ]. Ovo je standardni javni skup podataka za ocjene filmova, koji sadrži 25 milijuna ocjena koje uključuju otprilike 162000 korisnika i 62000 filmova. MovieLens 11 • . Izvorne oznake su ocjene od Predobrada oznaka 0.5 do 5.0, dok u produkciji naši zadaci uglavnom primaju binarne signale od korisnika. Kako bismo bolje simulirali naše produkcijske modele, pretvaramo skalirane oznake u binarne tako da tretiramo ocjene ≥ 3.5 kao pozitivne uzorke, a ostatak kao negativne uzorke. • Model i metrike. Implementirali smo standardni DeepFM [9] model, često korištenu arhitekturu modela za probleme preporuka. Sastoji se od FM komponente i guste komponente (Slika 6). Predviđanja se evaluiraju pomoću AUC [2], budući da je to glavno mjerenje za stvarne modele. • Kolizije embeddinga. Ovaj skup podataka sadrži otprilike 160 tisuća korisničkih ID-ova i 60 tisuća filmskih ID-ova. Kako bismo usporedili s verzijom tablice embeddinga bez kolizija, proveli smo još jednu grupu eksperimenata gdje su ID-ovi predobrađeni MD5 hashiranjem, a zatim mapirani u manji ID prostor. Kao rezultat, neki ID-ovi će dijeliti svoj embedding s drugima. Tablica 1 prikazuje detaljne statistike korisničkih i filmskih ID-ova prije i nakon hashiranja. (2) . Interni skup podataka za preporuke Također smo proveli eksperimente na modelu preporuka u produkcijskom okruženju. Ovaj model općenito slijedi multi-tower arhitekturu, pri čemu je svaki toranj odgovoran za učenje predviđanja specifične vrste ponašanja korisnika. Svaki model ima oko 1000 tablica embeddinga, a distribucija veličine tablica embeddinga vrlo je nejednaka; Izvorni ID prostor tablice embeddinga bio je 248. U našem osnovnom modelu, primijenili smo hash trik dekompozicijom kako bismo smanjili veličinu tablice embeddinga. Točnije, koristimo dvije manje tablice embeddinga umjesto jedne ogromne kako bismo generirali jedinstveni embedding za svaki ID kombinacijom vektora: gdje su 𝐸𝑟 , 𝐸𝑞 embeddingi koji odgovaraju 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Ovo učinkovito smanjuje veličinu tablica embeddinga s 248 na 225; • Ovaj model se poslužuje u stvarnoj produkciji, a performanse ovog eksperimenta mjere se online AUC-om sa stvarnim prometom posluživanja. Tijekom online treninga, ažuriramo naše online poslužujuće PS-ove najnovijim skupom parametara s minutnim intervalima. Dizajnirali smo dvije grupe eksperimenata kako bismo provjerili kvalitetu modela i robusnost sustava. 3.1.2 Online Trening. (1) . Kako bismo istražili nužnost minutne frekvencije ažuriranja, proveli smo eksperimente koji sinkroniziraju parametre iz trening modela u model predviđanja s različitim intervalima. Frekvencija ažuriranja