Brenda ByteDance: Motori që fuqizon feed-et e përmbajtjes më inteligjente dhe më të shpejta

```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 i Fudanit 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ë udhëhequra nga reagime të klientëve të ndjeshëm ndaj kohës, të tilla si renditja e videove të shkurtra ose reklamat online. Pavarësisht adoptimit të gjerë të kornizave të thella të mësimit në shkallë prodhimi si Ten-sorFlow ose PyTorch, këto korniza të qëllimeve të përgjithshme nuk 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 veçori dinamike dhe të rralla është i dëmshëm për cilësinë e modelit; nga ana tjetër, korniza të tilla janë projektuar me fazën e trajnimit me grup dhe fazën e shërbimit të ndara plotësisht, duke parandaluar që modeli të interaktë me reagimet e klientëve në kohë reale. Këto çështje na shtynë 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 trajnim në internet. 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 krijuam një tabelë të pathyeshmërisë së embedding-ut me optimizime të tilla si embedding-je të shfarrosur dhe filtrimi i frekuencës për të reduktuar gjurmën e saj të memories; së dyti, ne ofrojmë një arkitekturë trajnimi në internet të gatshme për prodhim me tolerancë të lartë ndaj gabimeve; më në fund, ne provuam se besueshmëria e sistemit mund të komproesohet për mësim në kohë reale. Monolith ka qenë i suksesshëm në produktin BytePlus Recommend2. Monolith 1 HYRJE Dekada e kaluar ka dëshmuar një bum të bizneseve të fuqizuara nga teknikat e rekomandimit. Në kërkim të një përvoje më të mirë për klientët, ofrimi i përmbajtjes së personalizuar për çdo përdorues individual si një përgjigje në kohë reale është një qëllim i zakonshëm i këtyre aplikacioneve biznesi. Për këtë qëllim, informacioni nga ndërveprimi më i fundit i një përdoruesi shpesh përdoret 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 sasija e madhe e të dhënave të përdoruesve i përshtatet natyrshëm modeleve neurale të drejtuara nga të dhënat 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ë dalin nga karakteristikat unike të të dhënave të rrjedhura nga sjellja e përdoruesve në botën reale. Këto të dhëna janë drastikisht të ndryshme 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) Veçoritë janë kryesisht të rralla, kategorike dhe dinamikisht ndryshuese; (2) Shpërndarja themelore e të dhënave të trajnimit është jo-stacionare, e njohur si Drift Koncepti [8]. Diferenca të tilla kanë paraqitur sfida unike për studiuesit dhe inxhinierët që punojnë në sistemet e rekomandimit. 1.1 Rrallësi dhe Dinamizëm Të dhënat për rekomandimin kryesisht përmbajnë veçori të rralla kategorike, disa prej të cilave shfaqen me frekuencë të ulët. Praktika e zakonshme e hartimit të tyre në një hapësirë embedding me dimension të lartë do të çojë në një seri problemesh: • Në ndryshim nga modelet e gjuhës ku numri i copëzave të fjalëve është i kufizuar, numri i përdoruesve dhe artikujve të renditur është disa herë më i madh. Një tabelë kaq e madhe embedding vështirë se mund të përshtatet në memorien e një makine të vetme; • Akoma më keq, pritet që madhësia e tabelës së embedding-ut të rritet me kalimin e kohës ndërsa 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 embedding-ut. 1 17 Në praktikë, shumë sisteme adoptojnë përzierjen me kolizion të ulët [ , ] si një mënyrë për të reduktuar gjurmën e memories 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 embedding-ut janë të shpërndara në mënyrë të barabartë në frekuencë, dhe kolizionet janë të padëmshme për cilësinë e modelit. Fatkeqësisht, 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ë mëdha. Me rritjen organike të madhësisë së tabelës së embedding-ut, shanset e kolizionit të çelësave të përzierjes rriten dhe çojnë në përkeqësimin e cilësisë së modelit 3 6 [3]. Prandaj, është një kërkesë natyrale për sistemet e rekomandimit në shkallë prodhimi të kenë aftësinë për të kapur sa më shumë veçori në parametrat e tyre, dhe gjithashtu të kenë aftësinë për të rregulluar elasticisht numrin e përdoruesve dhe artikujve që përpiqen të mbajnë evidencë. 1.2 Shpërndarje 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ë. Si rezultat, shpërndarja themelore e të dhënave të përdoruesit është jo-stacionare, një fenomen i referuar zakonisht si Drift Koncepti [8]. Intuitivisht, informacioni nga një histori më e 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 Drift Konceptit, modelet e shërbimit duhet të përditësohen nga reagimet e reja të përdoruesve sa më afër kohës reale që të jetë e mundur për të pasqyruar interesin më të fundit të një përdoruesi. Duke marrë parasysh këto dallime dhe duke vëzhguar problemet që dalin nga prodhimi ynë, ne dizajnuam , një sistem rekomandimi në shkallë të gjerë për t'iu adresuar këtyre pikave të forta. Ne bëmë eksperimente të gjera për të verifikuar dhe përmirësuar dizajnin tonë në mjedisin e prodhimit. Monolith është në gjendje të: Monolith (1) Ofron fuqi të plotë shprehëse për veçoritë e rralla duke projektuar një tabelë përzierjeje pa kolizion dhe një mekanizëm dinamik për shfarosjen e veçorive; (2) Lidh reagimet e shërbimit përsëri në trajnim në kohë reale me trajnim në internet. I fuqizuar nga këto kapacitete arkitektonike, Monolith performon vazhdimisht më mirë se sistemet që adoptojnë marifete përzierjeje me kolizione me përdorim të ngjashëm të memories, dhe arrin performancën më të lartë në kohë reale të shërbimit AUC pa ngarkuar tepër fuqinë llogaritëse të serverëve tanë. Pjesa tjetër e artikullit është organizuar si më poshtë. Ne së pari elaborojmë detajet e dizajnit se si Monolith trajton sfidat ekzistuese me tabelën përzierjeje pa kolizion dhe trajnimin në kohë reale në Seksionin 2. Eksperimentet dhe rezultatet do të prezantohen në Seksionin 3, së bashku me përfundimet e 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 Në një arkitekturë Worker-PS, makinat caktohen me 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. Arkitektura e përgjithshme e Monolith përgjithësisht ndjek cilësimin e Worker- arameter erver të TensorFlow-it të shpërndarë (Figurë P S 2). Në modelet e rekomandimit, parametrat kategorizohen në dy grupe: të dendura dhe të rralla. Parametrat e dendur janë peshat/variablat në një rrjet nervor të thellë, dhe parametrat e rrallë i referohen tabelave të embedding-ut që korrespondojnë me veçoritë 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-it për parametrat e dendur, ne dizajnuam një grup të operacioneve të HashTable shumë-efikase, pa kolizion dhe fleksibël për parametrat e rrallë. Si një plotësim për kufizimin e Tensor-Flow-it që lind nga ndarja e trajnimit dhe inferencës, trajnimi në internet i shkallëzueshëm elasticisht i Monolith është projektuar për të sinkronizuar në mënyrë efikase parametrat nga trajnimi-PS te shërbimi online-PS brenda intervaleve të shkurtra, me garanci të qëndrueshmërisë së modelit të siguruar nga mekanizmi i tolerancës ndaj gabimeve. 2.1 Tabelë Përzierjeje Një parim i parë në dizajnin tonë të përfaqësimit të parametrave të rrallë është të shmangim grumbullimin e informacionit nga ID të ndryshme në të njëjtin embedding me madhësi fikse. Simulimi i një tabelë embedding me madhësi dinamike me një Variabël TensorFlow jashtë kutisë do të çojë në mënyrë të pashmangshme në kolizionin e ID-ve, i cili përkeqësohet ndërsa mbërrijnë ID të reja dhe tabela rritet. Prandaj, në vend që të mbështetemi te Variable, ne zhvilluam një HashTable të re çelës-vlerë për parametrat tanë të rrallë. HashTable jonë përdor Cuckoo Hashmap [ ] nën sipërfaqe, e cila mbështet futurjen 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) mesatare të pritur për futurje. Siç ilustrohet në Figurën ajo ruan dy tabela 𝑇0, 𝑇1 me funksione të ndryshme përzierjeje ℎ0(𝑥), ℎ1(𝑥), dhe një element do të ruhet në njërën prej tyre. Kur përpiqeni të futuroni 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ë heqë 𝐵 nga 𝑇0 dhe do të përpiqet të futë 𝐵 në 𝑇1 me të njëjtin logjikë. Ky proces do të përsëritet derisa të gjithë elementët të stabilizohen, ose të ndodhë ri-përzierja kur futurja has në një cikël. Reduktimi i gjurmës së memories është gjithashtu një konsideratë e rëndësishme në dizajnin tonë. Një qasje e thjeshtë për futurjen e çdo ID të re në HashTable do të shterojë memorien shpejt. Vëzhgimet e modeleve reale të prodhimit çojnë 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ë paraqiten miliona herë ndërsa ato jo popullore shfaqen jo më shumë se dhjetë herë. Embedding-ët që korrespondojnë me këto ID të rralla janë të nën-perfektuar 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ë ditës këto ID nuk kanë gjasa të ndikojnë rezultatin, 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 embedding-ëve për këto ID nuk mund të ndihmojë modelin në asnjë mënyrë, përveçse të shterrë memorien tonë PS më kot. Bazuar në këto vëzhgime, ne dizajnuam disa heuristika për filtrimin e ID-ve të veçorive për një implementim më efikas të memories të HashTable: (1) ID-të filtrohen para se të pranohen në tabelat e embedding-ut. Ne kemi dy metoda filtrimi: Së pari, ne filtrojmë sipas paraqitjeve të tyre para se të futen si çelësa, ku kufiri i paraqitjeve është një hiperparametër i rregullueshëm që ndryshon për çdo 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ë memories; ![#Figure 4: Streaming Engine. Cikli informativ i reagimeve nga [Përdoruesi → Server Modeli → Punëtor Trajnimi → Server Modeli → Përdoruesi] do të zgjaste shumë kohë kur ndjek rrugën e Trajnimit me Grup, ndërsa Trajnimi në Internet do të mbyllë ciklin më menjëherë.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID-të janë të kohëzuara dhe caktohen të skadojnë pasi të jenë joaktive për një periudhë të caktuar kohore. Koha e skadimit është gjithashtu e rregullueshme për çdo tabelë embedding për të lejuar dallimin e veçorive me ndjeshmëri të ndryshme ndaj informacionit historik. Në implementimin tonë, HashTable implementohet si një operacion burimor i Tensor-Flow. Ngjashëm me Variablin, kërkimet dhe përditësimet gjithashtu implementohen si operacione native të TensorFlow për integrim më të lehtë dhe kompatibilitet më të mirë. 2.2 Trajnimi në Internet Në Monolith, trajnimi ndahet në dy faza (Figurë 1): (1) Faza e trajnimit me grup. Kjo fazë funksionon si një cikël i zakonshëm trajnimi Tensor-Flow: Në çdo hap trajnimi, një punëtor trajnimi lexon një grup të vogël shembujsh trajnimi nga ruajtja, kërkon parametra nga PS, kryen një kalim përpara dhe prapa, dhe më në fund dërgon parametrat e përditësuar te PS trajnimi. Pak ndryshe nga detyrat e tjera të zakonshme të mësimit të thellë, ne trajnojmë grupin tonë të të dhënave vetëm për një kalim. Trajnimi me grup është i dobishëm për trajnimin e të dhënave historike kur modifikojmë arkitekturën e modelit tonë dhe rimarrim modelin; (2) Faza e trajnimit në internet. Pas vendosjes së një modeli për shërbim në internet, trajnimi nuk ndalet por hyn në fazën e trajnimit në internet. Në vend që të lexojë shembuj të grupeve të vogla nga ruajtja, një punëtor trajnimi konsumon të dhëna reale në kohë reale dhe përditëson PS trajnimi. PS trajnimi sinkronizon periodikisht parametrat e tij me PS shërbimit, të cilat do të hyjnë në fuqi te përdoruesi menjëherë. Kjo i mundëson modelit tonë të adaptohet interaktivisht sipas reagimeve të përdoruesit në kohë reale. Monolith është ndërtuar me aftësinë për të kaluar pa probleme midis trajnimit me grup dhe trajnimit në internet. Kjo mundësohet nga dizajni ynë i motorit streaming siç ilustrohet nga Figurë 2.2.1 Motori Streaming. 4. Në dizajnin tonë, ne përdorim një radhë Kafka [ ] për të regjistruar veprimet e përdoruesve (P.sh., Kliko një artikull ose Pëlqe një artikull etj.) dhe një tjetër radhë Kafka për veçoritë. Në qendër të motorit është një punë streaming Flink [ ] për bashkimin e veçorive në internet. Bashkimi në internet bashkon veçoritë me shenjat 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 në internet ashtu edhe nga ai me grup: 13 4 Për trajnimin në internet, punëtori trajnimi lexon të dhëna drejtpërdrejt nga radha Kafka; Për trajnimin me grup, një punë hedhëse të dhënash së pari do të hedhë të dhënat në HDFS [ ]; Pas akumulimit të një sasie të caktuar të të dhënave në HDFS, punëtori trajnimi do të marrë të dhëna nga HDFS dhe do të kryejë trajnim me grup. 18 Parametrat e përditësuar në PS trajnimi do të dërgohen te PS shërbimit sipas planit të sinkronizimit të parametrave. Në aplikacionet e botës reale, ditarët e veprimeve të përdoruesve dhe veçoritë transmetohen në bashkuesin në internet (Figurë 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 veçoritë të mund të çiftëzohen saktë. 2.2.2 Bashkues në Internet. 5) Vonesa e veprimit të përdoruesit gjithashtu mund të jetë 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 veçoritë mbahen në memorie, ajo thjesht nuk do të përshtatet në memorie. Në sistemin tonë, përdoret një ruajtje çelës-vlerë në disk për të ruajtur veçoritë që presin për një periudhë më të gjatë kohore. Kur mbërrin një ditar veprimesh përdoruesi, ai së pari kërkon memorien në memorie, dhe pastaj kërkon ruajtjen çelës-vlerë në rast mungese në memorie. Një tjetër problem që lind në aplikacionet e botës 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 i të dytëve. Për të parandaluar mbizotërimin e shembujve pozitivë 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 atë 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 në internet është një vlerësues i paanshëm i shpërndarjes origjinale. 19 Gjatë trajnimit në internet, klasteri i trajnimit Monolith vazhdon të marrë të dhëna nga moduli i shërbimit në internet dhe përditëson parametrat në PS trajnimi. Një hap vendimtar për të lejuar PS shërbimit në internet të përfitojë nga këta parametra të trajnuar së fundmi ë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ërbimit në internet nuk duhet të 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 në internet nga shërbimi i modelit gjatë procesit të zëvendësimit, dhe përditësimet duhet të bëhen në kohë reale; Transferimi i një modeli me shumë terabajtë në tërësi nga PS trajnimi te PS shërbimit në internet do të krijonte presion të madh si për brezin e rrjetit ashtu edhe për memorien në PS, pasi kërkon madhësi dyfish të modelit të memories për të pranuar modelin e ri që mbërrin. Për qëllim të shkallëzimit të trajnimit në internet në madhësinë e skenarit tonë të biznesit, ne dizajnuam një mekanizëm inkremental sinkronizimi paramëresh periodik në kohë reale në Monolith bazuar në disa karakteristika të dukshme të modeleve tona: (1) Parametrat e rrallë dominojnë madhësinë e modeleve të rekomandimit; (2) Duke marrë parasysh një periudhë të shkurtër kohore, vetëm një nëngrup i vogël i ID-ve trajtohet dhe embedding-ët e tyre përditësohen; (3) Variablat e dendur lëvizin shumë më ngadalë se embedding-ët e rrallë. Kjo ndodh 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 të rekomandimit, ndërsa vetëm disa embedding të rrallë 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 veçorive. Në Monolith, ne mbajmë një grup të përzierjes të çelësave të prekur, duke përfaqësuar ID-të të cilave embedding-ët u trajnuan që nga sinkronizimi i fundit i parametrave. Ne dërgojmë nëngrupin e parametrave të rrallë, çelësat e të cilëve janë në grupin e çelësave të prekur me një interval kohor prej minutash nga PS trajnimi te PS shërbimit në internet. Ky grup relativisht i vogël i përditësimit inkremental të parametrave është i lehtë për transmetim rrjeti dhe nuk do të shkaktojë një rritje të mprehtë të memories gjatë sinkronizimit. Ne gjithashtu shfrytëzojmë (3) për të reduktuar më tej hyrjen/daljen e rrjetit dhe përdorimin e memories 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 japë një situatë ku parametrat e dendur që shërbejmë janë një version relativisht i vjetëruar krahasuar me pjesën e rrallë. Megjithatë, një moskoordinim i tillë mund të tolerohet për arsye të përmendura në (3) pasi nuk është vënë re asnjë humbje e dukshme. 2.3 Toleranca ndaj Gabimeve Si një sistem në prodhim, Monolith është projektuar me aftësinë për të rikuperuar një PS në rast dështimi. Një zgjedhje e zakonshme për tolerancën ndaj gabimeve është të krijohet një pamje e gjendjes së një modeli periodikisht, dhe të rikuperohet nga pamja 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. Krijimi i pamjes së një