Iekšpusē ByteDance Monolītā: Dzinējs, kas nodrošina gudrākus un ātrākus satura plūsmas

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∗, Fudan University Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) ABSTRAKT Tikai mērojamu un reāllaika ieteikumu sistēmas izveide ir būtiska daudziem uzņēmumiem, ko virza uz laiku jutīga klientu atsauksme, piemēram, īso video rangu vai tiešsaistes reklāmas. Neskatoties uz visuresošu ražošanas mēroga dziļās apmācības sistēmu, piemēram, Ten-sorFlow vai PyTorch, pieņemšanu, šīs vispārējās sistēmas dažādu iemeslu dēļ neatbilst uzņēmējdarbības prasībām ieteikumu scenārijos: no vienas puses, sistēmu pielāgošana, pamatojoties uz statiskiem parametriem un blīviem aprēķiniem ieteikumiem ar dinamiskiem un reti izmantotiem līdzekļiem, kaitē modeļa kvalitātei; no otras puses, šādas sistēmas ir izstrādātas ar pilnīgi atdalītu partiju apmācības stadiju un apkalpošanas stadiju, neļaujot modelim reāllaikā mijiedarboties ar klientu atsauksmēm. Šīs problēmas lika mums pārvērtēt tradicionālās pieejas un izpētīt radikāli atšķirīgas dizaina izvēles. Šajā rakstā mēs iepazīstinām ar 1, sistēmu, kas paredzēta tiešsaistes apmācībai. Mūsu dizains ir balstīts uz mūsu lietojumprogrammu darba slodžu un ražošanas vides novērojumiem, kas atspoguļo ievērojamu atšķirību no citām ieteikumu sistēmām. Mūsu ieguldījumi ir daudzveidīgi: pirmkārt, mēs izveidojām bezkonflikta iegulto tabulu ar optimizācijām, piemēram, izdzēšamiem iegultiem elementiem un frekvenču filtrēšanu, lai samazinātu tās atmiņas nospiedumu; otrkārt, mēs nodrošinām ražošanai gatavu tiešsaistes apmācības arhitektūru ar augstu kļūdu noturību; visbeidzot, mēs pierādījām, ka sistēmas uzticamību var apmainīt pret reāllaika apmācību. Monolith ir veiksmīgi ieviests BytePlus Recommend2 produktā. Monolith 1 IEVADS Pēdējā desmitgadē ir vērojams uz ieteikumu tehnikām balstītu uzņēmumu uzplaukums. Lai nodrošinātu labāku klientu pieredzi, katram individuālajam lietotājam nodrošinot personalizētu saturu kā reāllaika atbildi, ir kopīgs mērķis šīm biznesa lietojumprogrammām. Lai to panāktu, informācija no lietotāja jaunākās mijiedarbības bieži tiek izmantota kā galvenais ieguldījums modeļa apmācībā, jo tā vislabāk attēlo lietotāja portretu un paredz lietotāja intereses un turpmāko rīcību. Dziļā apmācība ir dominējusi ieteikumu modeļos [ , , , , , ], jo milzīgs lietotāju datu apjoms ir dabiski piemērots masveidīgi uz datiem balstītiem neironu modeļiem. Tomēr centieni izmantot dziļās apmācības jaudu industriālā līmeņa ieteikumu sistēmās pastāvīgi saskaras ar problēmām, kas rodas no reālās pasaules lietotāju uzvedības datu unikālajām īpašībām. Šie dati divos aspektos krasi atšķiras no datiem, ko izmanto parastajās dziļās apmācības problēmās, piemēram, valodu modelēšanā vai datoru redzēšanā: 5 6 10 12 20 21 (1) Lielākoties līdzekļi ir reti, kategoriski un dinamiski mainīgi; (2) Apmācības datu pamatā esošā izplatība ir nestacionāra, pazīstama kā koncepta novirze . Šādas atšķirības ir radījušas unikālus izaicinājumus pētniekiem un inženieriem, kas strādā pie ieteikumu sistēmām. 1.1 Retums un dinamika Ieteikumu dati lielākoties satur retus kategoriskus līdzekļus, daži no kuriem parādās ar zemu biežumu. Izplatītā prakse, tos kartējot uz augstdimensionālu iegultu telpu, radīs virkni problēmu: • Atšķirībā no valodu modeļiem, kur vārdu gabalu skaits ir ierobežots, lietotāju un rangu vienumu skaits ir par vairākām kārtām lielāks. Šāda milzīga iegulto tabula reti spētu ietilpt vienas resursdatora atmiņā; • Vēl sliktāk, iegulto tabulas izmēram paredzams, ka laika gaitā pieaugs, pieņemot jaunus lietotājus un vienumus, savukārt sistēmas, piemēram, [ , ], izmanto fiksēta izmēra blīvus mainīgos, lai attēlotu iegulto tabulu. 1 17 Praksē daudzas sistēmas izmanto zemas sadursmes jaucējšķirstu [ , ] kā līdzekli atmiņas nospieduma samazināšanai un ID pieauguma atļaušanai. Tas balstās uz pārmērīgi ideālistisku pieņēmumu, ka ID iegultajā tabulā ir vienmērīgi sadalīti pēc biežuma un sadursmes nav kaitīgas modeļa kvalitātei. Diemžēl tas reti notiek reālās pasaules ieteikumu sistēmā, kur neliela lietotāju vai vienumu grupa ir ievērojami biežāk sastopama. Ar iegultās tabulas izmēra organisko pieaugumu sadursmes iespējas pieaug un noved pie modeļa kvalitātes pasliktināšanās 3 6 . Tāpēc ražošanas mēroga ieteikumu sistēmām ir dabiska prasība spēt uztvert pēc iespējas vairāk līdzekļu savos parametros, kā arī spēt elastīgi pielāgot lietotāju un vienumu skaitu, ko tās cenšas uzskaitīt. 1.2 Nestacionāra izplatība Vizuālie un lingvistiskie modeļi gandrīz nemaz neveidojas gadsimtu laika skalā, savukārt tas pats lietotājs, kurš interesējas par vienu tēmu, var mainīt savu entuziasmu katru nākamo minūti. Tā rezultātā lietotāja datu pamatā esošā izplatība ir nestacionāra, parādība, ko parasti dēvē par koncepta novirzi . Intuitīvi, informācija no nesenākas vēstures var efektīvāk palīdzēt prognozēt lietotāja uzvedības izmaiņas. Lai mazinātu koncepta novirzes ietekmi, apkalpojošie modeļi ir jāatjaunina ar jaunām lietotāju atsauksmēm pēc iespējas tuvāk reāllaikam, lai atspoguļotu lietotāja jaunākās intereses. Ņemot vērā šīs atšķirības un novērojot problēmas, kas rodas mūsu ražošanā, mēs izstrādājām , liela mēroga ieteikumu sistēmu, lai risinātu šīs sāpes. Mēs veicām plašus eksperimentus, lai pārbaudītu un iterētu mūsu dizainu ražošanas vidē. Monolith spēj Monolith (1) Nodrošināt pilnu izteiksmes spēku retiem līdzekļiem, izstrādājot bezkonflikta jaucējšķirstu un dinamiskas līdzekļu izslēgšanas mehānismu; (2) Reāllaikā atgriezt apkalpošanas atsauksmes apmācībai ar tiešsaistes apmācību. Šo arhitektūras spēju stiprināts Monolith konsekventi pārsniedz sistēmas, kas izmanto jaucējšķirstu trikus ar sadursmēm, ar aptuveni līdzīgu atmiņas izmantošanu un sasniedz vismodernāko tiešsaistes apkalpošanas AUC, pārmērīgi neapgrūtinot mūsu serveru aprēķinu jaudu. Pārējā raksta daļa ir organizēta šādi. Vispirms mēs detalizēti aprakstām dizaina detaļas par to, kā Monolith risina esošos izaicinājumus ar bezkonfliktu jaucējšķirstu un reāllaika apmācību 2. sadaļā. Eksperimenti un rezultāti tiks sniegti 3. sadaļā, kopā ar ražošanā pārbaudītiem secinājumiem un dažām diskusijām par kompromisiem starp laika jutīgumu, uzticamību un modeļa kvalitāti. 4. sadaļa apkopo saistīto darbu un salīdzina tos ar Monolith. 5. sadaļa apkopo šo darbu. 2 DIZains Monolith vispārējā arhitektūra parasti seko TensorFlow izplatītā Darbinieka- arametru ervera iestatījumam (2. attēls). Darbinieka-PS arhitektūrā mašīnām ir piešķirtas dažādas lomas; Darbinieku mašīnas ir atbildīgas par grafika definēto aprēķinu veikšanu, un PS mašīnas glabā parametrus un atjaunina tos atbilstoši Darbinieku aprēķinātajiem gradientiem. P S Ieteikumu modeļos parametri tiek iedalīti divās grupās: blīvie un reti. Blīvie parametri ir svars/mainīgie dziļā neironu tīklā, un reti parametri attiecas uz iegultajām tabulām, kas atbilst reti izmantotiem līdzekļiem. Mūsu dizainā gan blīvie, gan reti parametri ir daļa no TensorFlow grafika un tiek glabāti parametru serveros. Līdzīgi kā TensorFlow mainīgajiem blīvajiem parametriem, mēs izstrādājām virkni ļoti efektīvu, bezkonfliktu un elastīgu HashTable operāciju reti izmantotiem parametriem. Kā papildinājums TensorFlow ierobežojumam, kas rodas no apmācības un izvadīšanas atdalīšanas, Monolith elastīgi mērogojama tiešsaistes apmācība ir izstrādāta, lai efektīvi sinhronizētu parametrus no apmācības PS uz tiešsaistes apkalpošanas PS īsos intervālos, ar modeļa robustuma garantiju, ko nodrošina kļūdu noturības mehānisms. 2.1 Jaucējšķirsts Pirmais princips mūsu reti izmantoto parametru attēlojuma dizainā ir izvairīties no informācijas no dažādiem ID sabraukšanas vienā fiksēta izmēra iegultumā. Dinamiski mainīgas izmēra iegultās tabulas simulēšana ar gatavu TensorFlow mainīgo neizbēgami noved pie ID sadursmes, kas pasliktinās, parādoties jauniem ID un pieaugot tabulai. Tāpēc, nevis balstoties uz mainīgo, mēs izstrādājām jaunu atslēgu-vērtību HashTable mūsu reti izmantotiem parametriem. Mūsu HashTable izmanto Cuckoo Hashmap [ ] pamatā, kas atbalsta jaunu atslēgu ievietošanu, nesaduroties ar esošajām. Cuckoo Hashing nodrošina sliktākajā gadījumā 𝑂 (1) laika sarežģītību meklēšanai un dzēšanai, un paredzamo amortizēto 𝑂 (1) laiku ievietošanai. Kā parādīts 3. attēlā, tas uztur divas tabulas 𝑇0, 𝑇1 ar dažādām jaucējšķiršanas funkcijām ℎ0 (𝑥), ℎ1 (𝑥), un elements tiks glabāts vienā no tām. Mēģinot ievietot elementu 16 𝐴 𝑇0, tas vispirms mēģina novietot 𝐴 pie ℎ0 (𝐴); ja ℎ0 (𝐴) aizņemts ar citu elementu 𝐵, tas izstumj 𝐵 no 𝑇0 un mēģina ievietot 𝐵 𝑇1 ar tādu pašu loģiku. Šis process tiks atkārtots, līdz visi elementi stabilizēsies, vai notiks pārmērīga jaucējšķiršana, kad ievietošana nonāk ciklā. Atmiņas nospieduma samazināšana ir arī svarīgs apsvērums mūsu dizainā. Vienkārša pieeja katra jaunā ID ievietošanai HashTable ātri izsmels atmiņu. Novērojumi par reāliem ražošanas modeļiem noved pie diviem secinājumiem: (1) ID, kas parādās tikai dažas reizes, maz iespaido modeļa kvalitāti. Svarīgs novērojums ir tas, ka ID ir sadalīti garajā astē, kur populāri ID var parādīties miljoniem reižu, savukārt nepopulārie parādās ne vairāk kā desmit reizes. Biežumu trūkuma dēļ šiem reti sastopamiem ID atbilstošie iegultņi ir nepietiekami apmācīti, un modelis nespēs veikt labu aprēķinu, pamatojoties uz tiem. Galu galā šie ID, visticamāk, neietekmēs rezultātu, tāpēc modeļa kvalitāte necietīs no šo ID ar zemu sastopamību noņemšanas; (2) Veci ID no attālas vēstures reti sniedz ieguldījumu pašreizējam modelim, jo daudzi no tiem nekad netiek apmeklēti. Tas varētu notikt tāpēc, ka lietotājs vairs nav aktīvs vai īsziņu video ir novecojis. Šo ID ieguldījumu glabāšana nepalīdz modelim nekādā veidā, bet gan veltīgi iztērē mūsu PS atmiņu. Pamatojoties uz šiem novērojumiem, mēs izstrādājām vairākas līdzekļu ID filtrēšanas heuristikas efektīvākai HashTable atmiņas izmantošanas realizācijai: (1) ID tiek filtrēti pirms to pievienošanas iegultajām tabulām. Mums ir divas filtrēšanas metodes: vispirms mēs filtrējam pēc to sastopamības pirms to ievietošanas kā atslēgas, kur sastopamības slieksnis ir regulējams hiperparametrs, kas atšķiras katram modelim; Papildus mēs izmantojam probabilistisku filtru, kas palīdz vēl vairāk samazināt atmiņas izmantošanu; ![#4. attēls: Straumēšanas programma. Informācijas atgriezeniskās saites cilpa no [Lietotājs → Modeļa serveris → Apmācības darbinieks → Modeļa serveris → Lietotājs] aizņems ilgu laiku, izmantojot Batch Training ceļu, savukārt Online Training aizvērs cilpu ātrāk.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID tiek laika gaitā atzīmēti un iestatīti uz izbeigšanos pēc iepriekš noteikta laika perioda neaktivitātes. Izbeigšanās laiks ir arī regulējams katrai iegultajai tabulai, lai ļautu atšķirt līdzekļus ar atšķirīgu jutīgumu pret vēsturisko informāciju. Mūsu realizācijā HashTable ir ieviesta kā TensorFlow resursu operācija. Līdzīgi kā mainīgajam, meklēšanas un atjaunināšanas operācijas ir ieviestas kā natīvas TensorFlow operācijas, lai atvieglotu integrāciju un uzlabotu savietojamību. 2.2 Tiešsaistes apmācība Monolith sistēmā apmācība tiek sadalīta divos posmos (1. attēls): (1) Partiju apmācības posms. Šis posms darbojas kā parasta TensorFlow apmācības cilpa: katrā apmācības solī apmācības darbinieks nolasa vienu mini-partiju apmācības piemēru no krātuves, pieprasa parametrus no PS, aprēķina priekšējo un atpakaļējo pāreju un visbeidzot nosūta atjauninātos parametrus uz apmācības PS. Nedaudz atšķirībā no citiem parastiem dziļās apmācības uzdevumiem, mēs apmācām savu datu kopumu tikai vienu reizi. Partiju apmācība ir noderīga vēsturisko datu apmācībai, kad mēs mainām savu modeļa arhitektūru un atkārtoti apmācām modeli; (2) Tiešsaistes apmācības posms. Pēc modeļa izvietošanas tiešsaistes apkalpošanai apmācība neaptur, bet pāriet uz tiešsaistes apmācības posmu. Tā vietā, lai lasītu mini-partiju piemērus no krātuves, apmācības darbinieks patērē reāllaika datus lidojumā un atjaunina apmācības PS. Apmācības PS periodiski sinhronizē savus parametrus ar apkalpošanas PS, kas nekavējoties stāsies spēkā lietotāja pusē. Tas ļauj mūsu modelim reāllaikā interaktīvi pielāgoties atbilstoši lietotāja atsauksmēm. Monolith ir veidota ar spēju nemanāmi pārslēgties starp partiju apmācību un tiešsaistes apmācību. To nodrošina mūsu straumēšanas programmas dizains, kā parādīts 4. attēlā. 2.2.1 Straumēšanas programma. Mūsu dizainā mēs izmantojam vienu Kafka [ ] rindu, lai reģistrētu lietotāju darbības (piemēram, noklikšķināt uz vienuma vai patīk vienumam utt.) un citu Kafka rindu līdzekļiem. Programmas kodols ir Flink [ ] straumēšanas uzdevums tiešsaistes līdzekļu savienotājam. Tiešsaistes savienotājs savieno līdzekļus ar etiķetēm no lietotāju darbībām un rada apmācības piemērus, kas pēc tam tiek ierakstīti Kafka rindā. Apmācības piemēru rindu patērē gan tiešsaistes apmācība, gan partiju apmācība: 13 4 Tiešsaistes apmācībai apmācības darbinieks tieši lasa datus no Kafka rindas; Partiju apmācībai datu izgāšanas darbs vispirms izgāzīs datus HDFS [ ]; Pēc tam, kad dati HDFS uzkrāsies noteiktā daudzumā, apmācības darbinieks ielādēs datus no HDFS un veiks partiju apmācību. 18 Atjauninātie parametri apmācības PS tiks nosūtīti uz apkalpošanas PS atbilstoši parametru sinhronizācijas grafikam. Reālās pasaules lietojumprogrammās lietotāju darbību žurnāls un līdzekļi tiek straumēti tiešsaistes savienotājā (5. attēls) bez laika secības garantijas. Tāpēc mēs izmantojam unikālu atslēgu katram pieprasījumam, lai lietotāja darbība un līdzekļi varētu pareizi savienoties. 2.2.2 Tiešsaistes savienotājs. Arī lietotāja darbību aizkave var būt problēma. Piemēram, lietotājs var aizņemt dažas dienas, pirms viņi izlemj iegādāties vienumu, kas viņiem tika parādīts pirms dienām. Tas ir izaicinājums savienotājam, jo, ja visi līdzekļi tiek glabāti kešatmiņā, tie vienkārši neiederas atmiņā. Mūsu sistēmā tiek izmantota diska atslēgu-vērtību krātuve, lai uzglabātu līdzekļus, kas tiek turēti pārāk ilgu laiku. Kad ienāk lietotāja darbību žurnāls, tas vispirms meklē atmiņas kešatmiņā, un pēc tam meklē atslēgu-vērtību krātuvi, ja kešatmiņa ir tukša. Vēl viena problēma, kas rodas reālās pasaules lietojumprogrammās, ir tāda, ka negatīvo un pozitīvo piemēru sadalījums ir ļoti nevienmērīgs, kur pirmo skaits var būt par vairākām kārtām augstāks nekā pēdējo. Lai novērstu pozitīvo piemēru pārsvaru no negatīvajiem, parastā stratēģija ir negatīvā izlase. Tas noteikti mainīs apmācītā modeļa pamatā esošo sadalījumu, pielāgojot to augstākai pozitīvu prognožu varbūtībai. Kā līdzeklis, mēs izmantojam log odds korekciju [ ] apkalpošanas laikā, nodrošinot, ka tiešsaistes modelis ir neobjektīvs sākotnējā sadalījuma novērtētājs. 19 Tiešsaistes apmācības laikā Monolith apmācības klasteris turpina saņemt datus no tiešsaistes apkalpošanas moduļa un atjaunina parametrus apmācības PS. Svarīgs solis, lai tiešsaistes apkalpošanas PS varētu gūt labumu no šiem jaunajiem apmācītajiem parametriem, ir atjaunināto modeļa parametru sinhronizācija. Ražošanas vidē mēs saskaramies ar vairākiem izaicinājumiem: 2.2.3 Parametru sinhronizācija. Modeļiem tiešsaistes apmācības PS nedrīkst pārtraukt apkalpošanu atjaunināšanas laikā. Mūsu modeļi ražošanā parasti ir vairāku terabaitu izmērā, un rezultātā visu parametru nomaiņa prasa laiku. Tas būtu nepieļaujami apturēt tiešsaistes PS modeļa apkalpošanu atjaunināšanas procesa laikā, un atjauninājumi ir jāveic lidojumā; Pilnībā vairāku terabaitu modeļa pārsūtīšana no apmācības PS uz tiešsaistes apkalpošanas PS radītu milzīgu spiedienu gan tīkla joslas platumam, gan PS atmiņai, jo tas prasa dubultu modeļa izmēru atmiņā, lai pieņemtu ienākošo modeli. Lai tiešsaistes apmācība mērogotos līdz mūsu uzņēmējdarbības scenārija izmēram, mēs izstrādājām Monolith inkrementālu, lidojuma, periodisku parametru sinhronizācijas mehānismu, pamatojoties uz vairākām ievērojamām mūsu modeļu īpašībām: (1) Retie parametri dominē ieteikumu modeļu izmērā; (2) Ņemot vērā īsu laika logu, tikai neliela daļa ID tiek apmācīti un to iegultņi atjaunināti; (3) Blīvie mainīgie pārvietojas daudz lēnāk nekā reti izmantotie iegultņi. Tas ir tāpēc, ka momentānu optimizētājos blīvo mainīgo momentānas uzkrāšanās palielina milzīgs ieteikumu apmācības datu apjoms, savukārt tikai daži reti izmantotie iegultņi saņem atjauninājumus vienā datu partijā. (1) un (2) ļauj mums izmantot retu atjauninājumu visiem līdzekļu ID. Monolith mēs uzturam skarto atslēgu jaucējškopu, kas attēlo ID, kuru iegultņi tiek apmācīti kopš pēdējās parametru sinhronizācijas. Mēs nosūtam retu parametru apakškopu, kuru atslēgas ir skarto atslēgu kopā ar minūtes līmeņa laika intervālu no apmācības PS uz tiešsaistes apkalpošanas PS. Šī relatīvi nelielā inkrementālo parametru atjauninājumu pakete ir viegla tīkla pārraidei un neradīs asu atmiņas pieaugumu sinhronizācijas laikā. Mēs arī izmantojam (3), lai vēl vairāk samazinātu tīkla I/O un atmiņas izmantošanu, iestatot agresīvāku sinhronizācijas grafiku reti izmantotiem parametriem, savukārt blīvie parametri tiek atjaunināti retāk. Tas var radīt situāciju, kurā apkalpotie blīvie parametri ir salīdzinoši novecojuša versija salīdzinumā ar reto daļu. Tomēr šāda neatbilstība ir pieļaujama, jo (3) minētais iemesls, ka nav novērota acīmredzama zaudējuma. 2.3 Kļūdu noturība Kā ražošanas sistēmai Monolith ir izstrādāta ar spēju atjaunot PS, ja tā sabrūk. Izplatīta kļūdu noturības izvēle ir periodiski uzņemt modeļa stāvokli un atjaunot to no jaunākā momentuzņēmuma, kad tiek konstatēta PS kļūme. Momentuzņēmumu biežuma izvēlei ir divas galvenās ietekmes: (1) Modeļa kvalitāte. Intuitīvi, modeļa kvalitāte mazāk cieš no nesenās vēstures zaudējuma, palielinoties momentuzņēmumu biežumam. (2) Aprēķinu pārslodze. Vairāku terabaitu modeļa momentuzņēmumu uzņemšana nav bez maksas. Tas rada lielas atmiņas kopijas un diska I/O. Kā kompromiss starp modeļa kvalitāti un aprēķinu pārslodzi, Monolith uzņem momentuzņēmumu no visiem apmācības PS katru dienu. Lai gan PS zaudēs vienas dienas atjauninājumus PS kļūmes gadījumā, mūsu eksperimentos mēs atklājām, ka veiktspējas pasliktināšanās ir pieļaujama. Mēs analizēsim PS uzticamības ietekmi nākamajā sadaļā. 3 NOVĒRTĒJUMS Lai labāk izprastu mūsu piedāvātā dizaina sniegtās priekšrocības un kompromisus, mēs veicām vairākus eksperimentus ražošanas mērogā un A/B testus ar tiešraides apkalpošanas datpl