Brenda ByteDance: Motori që mundëson kanalet më inteligjente dhe më të shpejta të përmbajtjes

```html Autorë: 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∗, Universiteti Fudan Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) ABSTRAKT Ndërtimi i një sistemi rekomandimi të shkallëzueshëm dhe në kohë reale është jetik për shumë biznese të drejtuara nga reagime të klientëve të ndjeshëm ndaj kohës, të tilla si renditja e videove të shkurtra ose reklamave online. Pavarësisht adoptimit të gjithëpranishëm të kornizave të mësimit të thellë në shkallë prodhimi si Ten-sorFlow ose PyTorch, këto korniza me qëllim të përgjithshëm nuk i plotësojnë kërkesat e biznesit në skenarët e rekomandimit për arsye të ndryshme: nga njëra anë, rregullimi i sistemeve bazuar në parametra statikë dhe llogaritje të dendura për rekomandim me tipare dinamike dhe të rralla është dëmshëm për cilësinë e modelit; nga ana tjetër, korniza të tilla janë projektuar me fazën e trajnimit në grup dhe fazën e shërbimit të ndara plotësisht, duke e penguar modelin të bashkëveprojë me reagimet e klientëve në kohë reale. Këto çështje na çuan të rivlerësojmë qasjet tradicionale dhe të eksplorojmë zgjedhje dizajni radikalisht të ndryshme. Në këtë artikull, ne prezantojmë 1, një sistem i përshtatur për trajnime online. Dizajni ynë është drejtuar nga vëzhgimet e ngarkesave tona të aplikacioneve dhe mjedisit të prodhimit që pasqyrojnë një largim të shënuar nga sistemet e tjera të rekomandimit. Kontributet tona janë të shumta: së pari, ne kemi krijuar një tabelë të personalizuar pa kolizione me optimizime të tilla si personalizime të përkohshme dhe filtrimi i frekuencës për të zvogëluar gjurmën e saj të kujtesës; së dyti, ne ofrojmë një arkitekturë trajnimi online të gatshme për prodhim me tolerancë të lartë ndaj gabimeve; më në fund, ne provuam se besueshmëria e sistemit mund të sakrifikohet për të mësuar në kohë reale. Monolith ka qenë i suksesshëm në produktin BytePlus Recommend2. Monolith 1 HYRJE Dekada e kaluar dëshmoi një bum biznesesh të fuqizuara nga teknikat e rekomandimit. Në kërkim të një përvoje më të mirë të klientit, ofrimi i përmbajtjes së personalizuar për çdo përdorues individual si një reagim në kohë reale është një qëllim i përbashkët i këtyre aplikacioneve të biznesit. Për këtë qëllim, informacioni nga ndërveprimi më i fundit i një përdoruesi përdoret shpesh si hyrja kryesore për trajnimin e një modeli, pasi ai do të përshkruante më së miri portretin e një përdoruesi dhe do të bënte parashikime të interesit dhe sjelljeve të ardhshme të përdoruesit. Mësimi i thellë ka dominuar modelet e rekomandimit [ , , , , , ] pasi sasia e madhe e të dhënave të përdoruesve i përshtatet natyrshëm modeleve neurale të drejtuara nga të dhëna masive. Megjithatë, përpjekjet për të shfrytëzuar fuqinë e mësimit të thellë në sistemet e rekomandimit në nivel industrial vazhdimisht hasen me probleme që rrjedhin nga karakteristikat unike të të dhënave të derivuara nga sjellja reale e përdoruesit. Këto të dhëna ndryshojnë në mënyrë drastike nga ato të përdorura në problemet konvencionale të mësimit të thellë si modelimi i gjuhës ose vizioni kompjuterik në dy aspekte: 5 6 10 12 20 21 (1) Tiparet janë kryesisht të rralla, kategorike dhe ndryshojnë në mënyrë dinamike; (2) Shpërndarja themelore e të dhënave të trajnimit nuk është stacionare, e njohur si Concept Drift [8]. Dallime të tilla kanë paraqitur sfida unike për studiuesit dhe inxhinierët që punojnë në sistemet e rekomandimit. 1.1 Rrallësia dhe Dinamika Të dhënat për rekomandim përmbajnë kryesisht tipare kategorike të rralla, disa prej të cilave shfaqen me frekuencë të ulët. Praktika e zakonshme e hartëzimit të tyre në një hapësirë të personalizuar me dimension të lartë do të krijojë një seri problemesh: • Ndryshe nga modelet gjuhësore ku numri i pjesëve të fjalëve është i kufizuar, numri i përdoruesve dhe artikujve për renditje është disa magnitude më i madh. Një tabelë kaq e madhe personalizimi vështirë se mund të futet në kujtesën e një hosti të vetëm; • Më keq akoma, pritet që madhësia e tabelës së personalizuar të rritet me kalimin e kohës pasi pranohen më shumë përdorues dhe artikuj, ndërsa kornizat si [ , ] përdorin variabla të dendur me madhësi fikse për të paraqitur tabelën e personalizuar. 1 17 Në praktikë, shumë sisteme adoptojnë hashing me kolizion të ulët [ , ] si një mënyrë për të reduktuar gjurmën e kujtesës dhe për të lejuar rritjen e ID-ve. Kjo mbështetet në një supozim tepër idealist se ID-të në tabelën e personalizuar janë të shpërndara në mënyrë të barabartë në frekuencë, dhe kolizionet janë të padëmshme për cilësinë e modelit. Për fat të keq, kjo rrallëherë është e vërtetë për një sistem rekomandimi në botën reale, ku një grup i vogël përdoruesish ose artikujsh kanë paraqitje dukshëm më të shumta. Me rritjen organike të madhësisë së tabelës së personalizuar, rastet e kolizionit të çelësave të hash-it rriten dhe çojnë në përkeqësimin e cilësisë së modelit 3 6 [3]. Prandaj, është një kërkesë natyrore për sistemet e rekomandimit në shkallë prodhimi të kenë kapacitetin për të kapur sa më shumë tipare në parametrat e saj, dhe gjithashtu të kenë aftësinë për të rregulluar në mënyrë elastike numrin e përdoruesve dhe artikujve që përpiqen të mbajnë. 1.2 Shpërndarja Jo-stacionare Modelet vizuale dhe gjuhësore mezi zhvillohen në një shkallë kohore shekullore, ndërsa i njëjti përdorues i interesuar për një temë mund të ndryshojë entuziazmin e tij çdo minutë të ardhshme. Si rezultat, shpërndarja themelore e të dhënave të përdoruesit nuk është stacionare, një fenomen i njohur zakonisht si Concept Drift [8]. Intuitivisht, informacioni nga një histori më e kohëve të fundit mund të kontribuojë më në mënyrë efektive në parashikimin e ndryshimit në sjelljen e një përdoruesi. Për të zbutur efektin e Concept Drift, modelet e shërbimit duhet të përditësohen nga reagimet e reja të përdoruesve sa më afër kohës reale të jetë e mundur për të pasqyruar interesin më të fundit të një përdoruesi. Duke pasur parasysh këto dallime dhe duke vëzhguar problemet që lindin nga prodhimi ynë, ne dizenjuam , një sistem rekomandimi në shkallë të gjerë për të adresuar këto probleme. Ne bëmë eksperimente të gjera për të verifikuar dhe përsosur dizajnin tonë në mjedisin e prodhimit. Monolith është në gjendje të: Monolith (1) Ofroni fuqi të plotë shprehëse për tiparet e rralla duke dizajnuar një tabelë hash pa kolizione dhe një mekanizëm dinamik të largimit të tipareve; (2) Kthejeni reagimin e shërbimit në trajnim në kohë reale me trajnim online. I fuqizuar nga këto kapacitete arkitektonike, Monolith performon në mënyrë të qëndrueshme më mirë se sistemet që adoptojnë metoda hash me kolizione me përdorim të kujtesës përafërsisht të ngjashëm, dhe arrin AUC të shërbimit online të nivelit më të lartë pa ngarkuar tepër fuqinë llogaritëse të serverëve tanë. Pjesa tjetër e artikullit është organizuar si më poshtë. Ne fillimisht elaborojmë detajet e dizajnit se si Monolith trajton sfidat ekzistuese me tabelë hash pa kolizione dhe trajnim në kohë reale në Seksionin 2. Eksperimentet dhe rezultatet do të paraqiten në Seksionin 3, së bashku me përfundime të testuara në prodhim dhe disa diskutime mbi kompromiset midis ndjeshmërisë ndaj kohës, besueshmërisë dhe cilësisë së modelit. Seksioni 4 përmbledh punën e lidhur dhe i krahason ato me Monolith. Seksioni 5 përfundon këtë punë. 2 DIZAJN Arkitektura e përgjithshme e Monolith ndjek në përgjithësi cilësimin Worker- arameter erver të TensorFlow të shpërndarë (Figura Në një arkitekturë Worker-PS, makinat i caktohen role të ndryshme; makinat Worker janë përgjegjëse për kryerjen e llogaritjeve siç përcaktohet nga grafiku, dhe makinat PS ruajnë parametrat dhe i përditësojnë ato sipas gradienteve të llogaritura nga Worker-ët. P S 2). Në modelet e rekomandimit, parametrat kategorizohen në dy grupe: të dendur dhe të rrallë. Parametrat e dendur janë peshat/variablat në një rrjet nervor të thellë, dhe parametrat e rrallë i referohen tabelave të personalizuara që korrespondojnë me tiparet e rralla. Në dizajnin tonë, si parametrat e dendur ashtu edhe ata të rrallë janë pjesë e Grafikut TensorFlow dhe ruhen në serverët e parametrave. Ngjashëm me Variablin e TensorFlow për parametrat e dendur, ne dizenjuam një grup operacionesh HashTable shumë efikase, pa kolizione dhe fleksibile për parametrat e rrallë. Si një plotësim i kufizimit të Tensor-Flow që lind nga ndarja e trajnimit dhe inferencës, trajnimi online elastikisht i shkallëzueshëm i Monolith është dizajnuar për të sinkronizuar në mënyrë efikase parametrat nga training-PS në online serving-PS brenda intervaleve të shkurtra, me garancinë e qëndrueshmërisë së modelit të siguruar nga mekanizmi i tolerancës ndaj gabimeve. 2.1 Tabelë Hash Një parim i parë në dizajnin tonë të përfaqësimit të parametrave të rrallë është të shmangim ngjitjen e informacionit nga ID-të e ndryshme në të njëjtin personalizim me madhësi fikse. Simulimi i një tabelë personalizimi me madhësi dinamike me një Variabël TensorFlow jashtë kutisë në mënyrë të pashmangshme çon në kolizion ID, i cili përkeqësohet ndërsa mbërrijnë ID të reja dhe tabela rritet. Prandaj, në vend që të mbështetemi te Variabli, ne zhvilluam një tabelë të re kërkimi-vlerë HashTable për parametrat tanë të rrallë. HashTable jonë përdor Cuckoo Hashmap [ ] nën sipërfaqe, e cila mbështet futjen e çelësave të rinj pa u kolizionuar me ato ekzistuese. Cuckoo Hashing arrin kompleksitet kohor 𝑂 (1) në rastin më të keq për kërkime dhe fshirje, dhe 𝑂 (1) mesatar të pritur për futje. Siç ilustrohet në Figurën , ajo ruan dy tabela 𝑇0, 𝑇1 me funksione hash të ndryshme ℎ0 (𝑥), ℎ1 (𝑥), dhe një element do të ruhet në njërën prej tyre. Kur përpiqemi të fusim një element 16 3 𝐴 në 𝑇0, ai përpiqet së pari ta vendosë 𝐴 te ℎ0 (𝐴); Nëse ℎ0 (𝐴) është e zënë nga një element tjetër 𝐵, ai do të largojë 𝐵 nga 𝑇0 dhe do të përpiqet të fusë 𝐵 në 𝑇1 me të njëjtin logjikë. Ky proces do të përsëritet derisa të gjithë elementët të stabilizohen, ose ndodh ripërshtatja kur futja bie në një cikël. Reduktimi i gjurmës së kujtesës është gjithashtu një konsideratë e rëndësishme në dizajnin tonë. Një qasje naive për të futur çdo ID të re në HashTable do të shterë kujtesën shpejt. Vëzhgimi i modeleve reale të prodhimit çon në dy përfundime: (1) ID-të që shfaqen vetëm disa herë kanë kontribut të kufizuar në përmirësimin e cilësisë së modelit. Një vëzhgim i rëndësishëm është se ID-të janë të shpërndara në bisht të gjatë, ku ID-të popullore mund të shfaqen miliona herë ndërsa ato jo-popullore shfaqen jo më shumë se dhjetë herë. Personalizimet që korrespondojnë me këto ID jo-frequentë janë të nën-trajtuara për shkak të mungesës së të dhënave të trajnimit dhe modeli nuk do të jetë në gjendje të bëjë një vlerësim të mirë bazuar në to. Në fund të fundit, këto ID nuk kanë gjasa të ndikojnë në rezultat, kështu që cilësia e modelit nuk do të vuajë nga heqja e këtyre ID-ve me paraqitje të ulëta; (2) ID-të e vjetruara nga një histori e largët rrallë kontribuojnë në modelin aktual pasi shumë prej tyre nuk vizitohen kurrë. Kjo mund të jetë për shkak të një përdoruesi që nuk është më aktiv, ose një videoje të shkurtër që është jashtë datës. Ruajtja e personalizimeve për këto ID nuk mund të ndihmojë modelin në asnjë mënyrë, përveçse të harxhojë kot kujtesën tonë PS. Bazuar në këto vëzhgime, ne dizenjuam disa heuristika filtrimi të ID-ve të tipareve për një zbatim më efikas të kujtesës së HashTable: (1) ID-të filtrohen para se të pranohen në tabelat e personalizuar. Ne kemi dy metoda filtrimi: Së pari, ne filtrojmë sipas paraqitjeve të tyre para se të futen si çelësa, ku pragut të paraqitjeve është një hiperparameter i rregullueshëm që ndryshon për secilin model; Për më tepër, ne përdorim një filtër probabilistik që ndihmon në reduktimin e mëtejshëm të përdorimit të kujtesës; ![#Figura 4: Engine Streaming. Cikli i reagimeve të informacionit nga [Përdoruesi → Model Server → Training Worker → Model Server → Përdoruesi] do të kalojë shumë kohë kur ndjek rrugën Batch Training, ndërsa Online Training do të mbyllë ciklin më menjëherë.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID-të marrin kohë dhe vendosen të skadojnë pasi të jenë joaktive për një periudhë të caktuar kohe. Koha e skadimit është gjithashtu e rregullueshme për çdo tabelë personalizimi për të lejuar dallimin e tipareve me ndjeshmëri të ndryshme ndaj informacionit historik. Në zbatimin tonë, HashTable është implementuar si një operacion burimi TensorFlow. Ngjashëm me Variablin, kërkimet dhe përditësimet gjithashtu zbatohen si operacione native TensorFlow për integrim më të lehtë dhe përputhshmëri më të mirë. 2.2 Trajnimi Online Në Monolith, trajnimi ndahet në dy faza (Figura 1): (1) Faza e trajnimit në grup. Kjo fazë funksionon si një cikël i zakonshëm trajnimi TensorFlow: Në çdo hap trajnimi, një punëtor trajnimi lexon një mini-grup shembujsh trajnimi nga ruajtja, kërkon parametra nga PS, llogarit një pas-vëzhgim dhe një pas-mbrapa, dhe përfundimisht dërgon parametra të përditësuar në PS të trajnimit. Pak më ndryshe nga detyrat e tjera të zakonshme të mësimit të thellë, ne trajnojmë datasetin tonë vetëm për një kalim. Trajnimi në grup është i dobishëm për trajnimin e të dhënave historike kur modifikojmë arkitekturën e modelit tonë dhe ripërsërisim modelin; (2) Faza e trajnimit online. Pas vendosjes së një modeli për shërbim online, trajnimi nuk ndalet por hyn në fazën e trajnimit online. Në vend që të lexojë shembuj mini-grup nga ruajtja, një punëtor trajnimi konsumon të dhëna në kohë reale në fluturim dhe përditëson PS të trajnimit. PS trajnimi periodikisht sinkronizon parametrat e tij me PS shërbimit, të cilat do të hyjnë në fuqi në anën e përdoruesit menjëherë. Kjo mundëson që modeli ynë të përshtatet interaktivisht sipas reagimeve të përdoruesit në kohë reale. Monolith është ndërtuar me aftësinë për të kaluar pa probleme midis trajnimit në grup dhe trajnimit online. Kjo mundësohet nga dizajni ynë i engine streaming siç ilustrohet nga Figura 2.2.1 Engine Streaming. 4. Në dizajnin tonë, ne përdorim një radhë Kafka [ ] për të regjistruar veprimet e përdoruesve (p.sh. Klikoni mbi një artikull ose pëlqeni një artikull etj.) dhe një radhë tjetër Kafka për tiparet. Në zemër të engine është një punë streaming Flink [ ] për bashkimin online të tipareve. Bashkuesi online bashkon tiparet me etiketat nga veprimet e përdoruesve dhe prodhon shembuj trajnimi, të cilët më pas shkruhen në një radhë Kafka. Radha për shembujt e trajnimit konsumohet si nga trajnimi online ashtu edhe nga ai në grup: 13 4 Për trajnimin online, punëtori trajnimi lexon të dhëna direkt nga radha Kafka; Për trajnimin në grup, një punë shkarkimi të dhënash së pari do të shkarkojë të dhëna në HDFS [ ]; Pasi të mblidhen të dhënat në HDFS në një sasi të caktuar, punëtori trajnimi do të marrë të dhëna nga HDFS dhe do të kryejë trajnim në grup. 18 Parametrat e përditësuar në PS të trajnimit do të dërgohen në PS shërbimit sipas planit të sinkronizimit të parametrave. Në aplikacionet reale, regjistri i veprimeve të përdoruesve dhe tiparet transmetohen në bashkuesin online (Figura pa garanci në rendin kohor. Prandaj, ne përdorim një çelës unik për çdo kërkesë në mënyrë që veprimi i përdoruesit dhe tiparet të mund të çiftëzohen saktë. 2.2.2 Bashkues Online. 5) Vonesa e veprimit të përdoruesit gjithashtu mund të jetë një problem. Për shembull, një përdorues mund të marrë disa ditë para se të vendosë të blejë një artikull që i është paraqitur ditë më parë. Kjo është një sfidë për bashkuesin sepse nëse të gjitha tiparet mbahen në cache, ato thjesht nuk do të futen në kujtesë. Në sistemin tonë, përdoret një ruajtje çelës-vlerë në disk për të ruajtur tiparet që presin për një periudhë më të gjatë kohe. Kur mbërrin një regjistër veprimi i përdoruesit, ai së pari kërkon në cache-in në memorie, dhe më pas kërkon në ruajtjen çelës-vlerë në rast mungese cache. Një problem tjetër që lind në aplikacionet reale është se shpërndarja e shembujve negativë dhe pozitivë është shumë e pabarabartë, ku numri i të parëve mund të jetë magnitude më i lartë se të dytët. Për të parandaluar që shembujt pozitivë të mposhten nga ata negativë, një strategji e zakonshme është të bëhet kampionimi negativ. Kjo sigurisht do të ndryshojë shpërndarjen themelore të modelit të trajnuar, duke e rregulluar drejt një probabiliteti më të lartë për të bërë parashikime pozitive. Si një zgjidhje, ne aplikojmë korrigjimin e log-odds [ ] gjatë shërbimit, duke u siguruar që modeli online të jetë një estimator paanshmëri i shpërndarjes origjinale. 19 Gjatë trajnimit online, klasteri i trajnimit Monolith vazhdon të marrë të dhëna nga moduli i shërbimit online dhe përditëson parametrat në PS të trajnimit. Një hap thelbësor për të mundësuar PS shërbimin online të përfitojë nga këta parametra të trajnuar rishtazi është sinkronizimi i parametrave të përditësuar të modelit. Në mjedisin e prodhimit, ne hasim disa sfida: 2.2.3 Sinkronizimi i Parametrave. Modelet në PS shërbimin online duhet të mos ndalojnë së shërbyeri gjatë përditësimit. Modelet tona në prodhim zakonisht janë disa terabajtë në madhësi, dhe si rezultat, zëvendësimi i të gjithë parametrave merr kohë. Do të ishte e patolerueshme të ndalohej një PS online nga shërbimi i modelit gjatë procesit të zëvendësimit, dhe përditësimet duhet të bëhen në fluturim; Transferimi i një modeli multi-terabajt të tërë nga PS trajnimi në PS shërbimin online do të krijojë presion të madh si për gjerësinë e brezit të rrjetit ashtu edhe për kujtesën në PS, pasi kërkon madhësi të dyfishtë të modelit të kujtesës për të pranuar modelin e ri që mbërrin. Për qëllim që trajnimi online të shkallëzohet në madhësinë e skenarit tonë të biznesit, ne dizenjuam një mekanizëm inkremental periodik të sinkronizimit të parametrave në fluturim në Monolith bazuar në disa karakteristika të dukshme të modeleve tona: (1) Parametrat e rrallë dominojnë madhësinë e modeleve të rekomandimit; (2) Duke pasur parasysh një dritare të shkurtër kohore, vetëm një nëngrup i vogël i ID-ve trajtohet dhe personalizimet e tyre përditësohen; (3) Variablat e dendur lëvizin shumë më ngadalë se personalizimet e rralla. Kjo është sepse në optimizuesit bazuar në moment, akumulimi i momentit për variablat e dendur zmadhohet nga madhësia gjigante e të dhënave të trajnimit, ndërsa vetëm disa personalizime të rralla marrin përditësime në një grup të vetëm të dhënash. (1) dhe (2) na lejojnë të shfrytëzojmë përditësimet e rralla në të gjitha ID-të e tipareve. Në Monolith, ne mbajmë një grup hash të çelësave të prekur, duke përfaqësuar ID-të, personalizimet e të cilave janë trajtuar që nga sinkronizimi i fundit i parametrave. Ne dërgojmë nëngrupin e parametrave të rrallë, çelësat e të cilëve janë në setin e çelësave të prekur, me një interval kohor të minutës nga PS trajnimi te PS shërbimit. Ky grup relativisht i vogël i përditësimit inkremental të parametrave është i lehtë për transmetim në rrjet dhe nuk do të shkaktojë një pikë të mprehtë kujtese gjatë sinkronizimit. Ne gjithashtu shfrytëzojmë (3) për të reduktuar më tej I/O-në e rrjetit dhe përdorimin e kujtesës duke vendosur një plan më agresiv sinkronizimi për parametrat e rrallë, ndërsa përditësojmë parametrat e dendur më pak shpesh. Kjo mund të na sjellë një situatë ku parametrat e dendur që ne shërbejmë janë një version relativisht i vjetëruar në krahasim me pjesën e rrallë. Megjithatë, një paqëndrueshmëri e tillë mund të tolerohet për arsye të përmendura në (3), pasi nuk është vërejtur ndonjë humbje e dukshme. 2.3 Toleranca ndaj Gabimeve Si një sistem në prodhim, Monolith është dizajnuar me aftësinë për të rikuperuar një PS në rast se ai dështon. Një zgjedhje e zakonshme për tolerancën ndaj gabimeve është të bësh një pamje të gjendjes së një modeli periodikisht, dhe të rikuperosh nga pamja më e fundit kur zbulohet dështimi i PS. Zgjedhja e frekuencës së pamjes ka dy ndikime kryesore: (1) Cilësia e modelit. Intuitivisht, cilësia e modelit vuan më pak nga humbja e historisë së fundit me rritjen e frekuencës së pamjes. (2) Kosto llogaritëse. Marrja e një pamjeje të një modeli multi-terabajt nuk është falas. Ajo shkakton pjesë të mëdha të kopjimit të kujtesës dhe I/O-së së diskut. Si një kompromis mid