ByteDance-тың Монолитінде: Ақылды, Жылдам Мазмұн Ленталарын Қамтамасыз ететін Қозғалтқыш

Авторлар: Чжуоран Лю, Bytedance Inc. Леки Зоу, Bytedance Inc. Сюань Зоу, Bytedance Inc. Цайхуа Ван, Bytedance Inc. Бяо Чжан, Bytedance Inc. Да Тан, Bytedance Inc. Болин Чжу∗, Fudan University Ицзе Чжу, Bytedance Inc. Пэн Ву, Bytedance Inc. Ке Ван, Bytedance Inc. Юлонг Ченг†, Bytedance Inc. (youlong.cheng@bytedance.com) АННОТАЦИЯ Құру масштабы мен нақты уақыт режимінде жұмыс істейтін ұсыныс жүйесі көптеген бизнес үшін өте маңызды, әсіресе уақытша клиенттерге кері байланыс беретін, мысалы, қысқа бейнелерді рейтингілеу немесе онлайн жарнамалар. TensorFlow немесе PyTorch сияқты өндірістік деңгейдегі терең оқыту фреймворктерінің кеңінен қолданылуына қарамастан, бұл жалпы мақсаттағы фреймворктер әртүрлі себептермен ұсыныс сценарийлерінде бизнес талаптарына сай келмейді: бір жағынан, динамикалық және сирек кездесетін ерекшеліктермен ұсыныс үшін статикалық параметрлер мен тығыз есептеулерге негізделген жүйелерді реттеу модель сапасына зиян келтіреді; екінші жағынан, мұндай фреймворктер партиялық оқыту кезеңі мен қызмет көрсету кезеңін толығымен бөлу арқылы жасалған, бұл модельдің клиенттерге кері байланыспен нақты уақытта өзара әрекеттесуіне жол бермейді. Бұл мәселелер бізді дәстүрлі тәсілдерді қайта қарастыруға және түбегейлі басқа дизайн таңдауларын зерттеуге итермеледі. Бұл мақалада біз онлайн оқытуға арналған жүйе болып табылатын 1 жүйесін ұсынамыз. Біздің дизайнымыз басқа ұсыныс жүйелерінен айтарлықтай айырмашылықты көрсететін қолданбалық жұмыс жүктемелеріміз бен өндірістік ортамызды бақылаудан туындаған. Біздің үлестеріміз көп: біріншіден, біз экспирациялық эмбеддингтер мен жиілік сүзгісі сияқты оңтайландыруларды қолданып, үлкен жадты азайту үшін қақтығыссыз эмбеддинг кестесін жасадық; екіншіден, біз жоғары отказоустойчивостьпен өндіріске дайын онлайн оқыту архитектурасын ұсынамыз; ақырында, жүйенің сенімділігін нақты уақыттағы оқыту үшін айырбастауға болатындығын дәлелдедік. Monolith BytePlus Recommend2 өнімінде сәтті жүзеге асырылды. Monolith 1 КІРІСПЕ Өткен онжылдықта ұсыныс әдістерімен жұмыс істейтін бизнес жандана түсті. Жақсы тұтынушы тәжірибесіне ұмтылыс, әрбір жеке пайдаланушыға жекелендірілген мазмұнды нақты уақытта жауап ретінде жеткізу - бұл бизнес қолданбаларының жалпы мақсаты. Осы мақсатта, пайдаланушының ең соңғы әрекеті туралы ақпарат әдетте модельді оқытудың негізгі кірісі ретінде қолданылады, себебі бұл пайдаланушының портретін ең жақсы сипаттайды және пайдаланушының қызығушылығы мен болашақ мінез-құлқын болжайды. Терең оқыту ұсыныс модельдеріне үстемдік етті [ , , , , , ], өйткені пайдаланушы деректерінің үлкен көлемі жаппай деректерге негізделген нейрондық модельдерге табиғи түрде сәйкес келеді. Алайда, өнеркәсіптік деңгейдегі ұсыныс жүйелерінде терең оқытудың күшін пайдалану әрекеттері әлемдегі пайдаланушы мінез-құлқынан алынған деректердің ерекше сипаттамаларынан туындаған мәселелерге үнемі тап болады. Бұл деректер дәстүрлі терең оқыту мәселелерінен, мысалы, тілдік модельдеу немесе компьютерлік көруден екі жағынан айтарлықтай ерекшеленеді: 5 6 10 12 20 21 (1) Ерекшеліктер негізінен сирек, категориялық және динамикалық түрде өзгеретін болып келеді; (2) Оқу деректерінің негізгі таралуы стационарлы емес, яғни conceito Drift . Мұндай айырмашылықтар ұсыныс жүйелерінде жұмыс істейтін зерттеушілер мен инженерлер үшін бірегей қиындықтар тудырды. 1.1 Сирек кездесу және динамика Ұсыныс үшін деректер негізінен сирек кездесетін категориялық ерекшеліктерді қамтиды, олардың кейбіреулері аз жиілікте кездеседі. Оларды жоғары өлшемді эмбеддинг кеңістігіне карталаудың жалпы тәжірибесі бірқатар мәселелерге әкелуі мүмкін: • Сөз бөлшектерінің саны шектеулі тілдік модельдерден айырмашылығы, пайдаланушылар мен рейтингтік элементтердің саны екі есе көп. Мұндай үлкен эмбеддинг кестесі жалғыз хост жадына сыймауы мүмкін; • Одан да нашар, пайдаланушылар мен элементтер көбірек қосылған сайын, эмбеддинг кестесінің мөлшері уақыт өте келе өсуі керек, ал [ , ] сияқты фреймворктер эмбеддинг кестесін тығыз айнымалылардың бекітілген мөлшерін қолданады. 1 17 Іс жүзінде, көптеген жүйелер жадты азайту және ID-лердің өсуіне мүмкіндік беру үшін қақтығыссыз хэширование [ , ] қолданылады. Бұл ID-лердің эмбеддинг кестесінде жиілік бойынша біркелкі таралатыны және қақтығыстардың модель сапасына зиянсыз екендігі туралы шамадан тыс идеалды болжамға негізделген. Алайда, бұл шынайы өмірдегі ұсыныс жүйесінде сирек кездеседі, мұнда пайдаланушылар немесе элементтердің кішігірім тобында айтарлықтай көп кездесулер болады. Эмбеддинг кестесінің мөлшерінің органикалық өсуімен, хэш кілтінің қақтығысу ықтималдығы артады және модель сапасының нашарлауына әкеледі 3 6 . Сондықтан өндірістік деңгейдегі ұсыныс жүйелері үшін параметрлердің мүмкіндігінше көп ерекшеліктерді қамту және пайдаланушылар мен элементтердің санын икемді түрде реттеу мүмкіндігі бар. 1.2 Стационарлы емес таралу Көріністік және тілдік үлгілер ғасырлар бойы дамымайды, ал бір тақырыпқа қызығатын пайдаланушы келесі минутта қызығушылығын өзгерте алады. Нәтижесінде, пайдаланушы деректерінің негізгі таралуы стационарлы емес, бұл феномен концепциялық ауытқу деп аталады. Интуитивті түрде, жақында болған тарих туралы ақпарат пайдаланушының мінез-құлқының өзгеруін болжауда тиімдірек үлес қоса алады. Концепциялық ауытқу әсерін азайту үшін, қызмет көрсету модельдері пайдаланушының соңғы қызығушылығын мүмкіндігінше нақты уақыт режимінде көрсету үшін жаңа клиенттерге кері байланыстан жаңартылуы керек. Осы айырмашылықтарды ескере отырып және біздің өндірісімізде туындаған мәселелерді бақылау негізінде, біз осы қиындықтарды шешуге арналған ірі масштабты ұсыныс жүйесі жүйесін жасадық. Біз өндірістік ортада өзіміздің дизайнымызды тексеру және жаңарту үшін кең ауқымды эксперименттер жүргіздік. Monolith қабілетті: Monolith (1) Қақтығыссыз хэш кестесін және динамикалық ерекшеліктерді жою механизмін жасау арқылы сирек кездесетін ерекшеліктер үшін толық экспрессивті күшті қамтамасыз ету; (2) Онлайн оқытумен нақты уақыт режимінде қызмет көрсету кері байланысын оқытуға қайтару. Осы архитектуралық мүмкіндіктермен қуатталған Monolith, қақтығыстары бар хэш-триктерді қолданатын жүйелерден шамамен ұқсас жадты пайдалану арқылы үнемі артықшылық береді және серверлеріміздің есептеу қуатын шамадан тыс жүктемей, заманауи онлайн қызмет көрсету AUC-ін жетеді. Қалған мақала келесідей ұйымдастырылған. Біріншіден, 2-бөлімде Monolith-тің қақтығыссыз хэш кестесі және нақты уақыттағы оқыту арқылы қазіргі қиындықтарды қалай шешетіндігі туралы дизайн егжей-тегжейін баяндаймыз. Эксперименттер мен нәтижелер 3-бөлімде, өндірісте тексерілген қорытындылармен және уақыт сезімталдығы, сенімділік және модель сапасы арасындағы сауда-саттықтар туралы кейбір талқылаулармен бірге ұсынылады. 4-бөлім тиісті жұмысты қорытындылайды және оларды Monolith-пен салыстырады. 5-бөлім осы жұмысты қорытындылайды. 2 ДИЗАЙН Monolith-тің жалпы архитектурасы, әдетте, TensorFlow-тің таратылған Worker- arameter erver орнатылымына (2-сурет) сәйкес келеді. Worker-PS архитектурасында машиналарға әртүрлі рөлдер беріледі; Worker машиналары граф анықтаған есептеулерді орындауға жауапты, ал PS машиналары параметрлерді сақтайды және оларды Workers есептеген градиенттерге сәйкес жаңартады. P S Ұсыныс модельдерінде параметрлер екі жиынтыққа бөлінеді: тығыз және сирек. Тығыз параметрлер - бұл терең нейрондық желідегі салмақтар/айнымалылар, ал сирек параметрлер сирек ерекшеліктерге сәйкес келетін эмбеддинг кестелеріне жатады. Біздің дизайнымызда тығыз және сирек параметрлер де TensorFlow Графтың бөлігі болып табылады және параметр серверлерінде сақталады. Тығыз параметрлер үшін TensorFlow-тің айнымалысына ұқсас, біз сирек параметрлер үшін жоғары тиімді, қақтығыссыз және икемді HashTable операциялары жиынтығын жасадық. TensorFlow-тің оқыту мен инференстің бөлінуінен туындаған шектеулеріне толықтыру ретінде, Monolith-тің икемді түрде масштабына болатын онлайн оқытуы, қысқа интервалдарда оқыту-PS-тен онлайн қызмет көрсету-PS-ке параметрлерді тиімді түрде синхрондауға арналған, отказоустойчивость механизмімен модельдің беріктігіне кепілдік береді. 2.1 Хэш кестесі Сирек параметрлерді өкілдік ету дизайнымыздың бірінші принципі - әртүрлі ID-лерден ақпаратты бірдей бекітілген мөлшердегі эмбеддингке тығып тастаудан аулақ болу. Сыртқы TensorFlow айнымалысымен динамикалық мөлшердегі эмбеддинг кестесін симуляциялау сөзсіз ID қақтығысына әкеледі, бұл жаңа ID-лер келгенде және кесте өскенде шиеленіседі. Сондықтан айнымалыны негізге алмастан, біз сирек параметрлер үшін жаңа кілт-мәнді HashTable-ді әзірледік. Біздің HashTable Cuckoo Hashmap [ ] пайдаланады, ол бар кілттермен қақтығыспай жаңа кілттерді қосуды қолдайды. Cuckoo Hashing іздеулер мен жоюлар үшін ең нашар жағдайда 𝑂 (1) уақыт күрделілігін, ал қосулар үшін күтілетін амортизацияланған 𝑂 (1) уақытты жетеді. 3-суретте көрсетілгендей, ол екі кесте 𝑇0, 𝑇1-ді әртүрлі хэш функциялары ℎ0 (𝑥), ℎ1 (𝑥) арқылы сақтайды, және элемент олардың біреуінде сақталады. 𝑇0-ге элемент 𝐴 енгізуге тырысқанда, ол алдымен 𝐴-ны ℎ0 (𝐴) орнына қоюға тырысады; Егер ℎ0 (𝐴) 𝐵 элементімен толтырылған болса, ол 𝐵-ны 𝑇0-ден шығарып, 𝐵-ны 𝑇1-ге сол логикамен енгізуге тырысады. Бұл процесс барлық элементтер тұрақталғанша немесе қосу циклға кіргенде қайта хэштеу орын алғанша қайталанады. 16 Жадты азайту да дизайнымыздың маңызды бөлігі болып табылады. Әрбір жаңа ID-ді HashTable-ге енгізудің қарапайым тәсілі жадты тез тауысады. Шынайы өндірістік модельдерді бақылау екі қорытындыға келді: (1) Бірнеше рет кездесетін ID-лер модель сапасын жақсартуға аз үлес қосады. Маңызды бақылау - ID-лер ұзын-құйрықты таратылған, мұнда танымал ID-лер миллиондаған рет кездесуі мүмкін, ал танымал емес ID-лер оннан аспайды. Осы сирек кездесетін ID-лерге сәйкес келетін эмбеддингтер, оқу деректерінің жетіспеушілігінен дұрыс оқылмайды және модель оларға негізделген жақсы бағалау жасай алмайды. Нәтижесінде, модель сирек кездесетін ID-лерді жоюдан зардап шекпейді; (2) Ескі тарихтан алынған ескі ID-лер қазіргі модельге сирек қолданылады, себебі олардың көпшілігі ешқашан қолданылмайды. Бұл белсенді емес пайдаланушының немесе ескірген қысқа бейненің салдарынан болуы мүмкін. Осы ID-лер үшін эмбеддингтерді сақтау модельге еш көмектеспейді, тек PS жадын босқа жұмсайды. Осы бақылаулар негізінде, біз HashTable-ді жадты тиімдірек жүзеге асыру үшін бірнеше ерекшелік ID сүзгісі эвристикасын жасадық: (1) ID-лер эмбеддинг кестелеріне енгізілместен бұрын сүзіледі. Бізде екі сүзгі әдісі бар: Біріншіден, олар кілттер ретінде енгізілмес бұрын кездесу жиілігі бойынша сүземіз, мұнда кездесулердің шекті мәні әр модель үшін әртүрлі болатын реттелетін гиперпараметр болып табылады; Сонымен қатар, біз жадты одан әрі азайтуға көмектесетін ықтималдық сүзгісін қолданамыз; ![#Figure 4: Streaming Engine. Пайдаланушы → Модель сервері → Оқыту жұмысшысы → Модель сервері → Пайдаланушы] арасындағы ақпараттық кері байланыс циклі партиялық оқыту жолын алғанда ұзақ уақытты алады, ал онлайн оқыту цикліні жылдамырақ жабады.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID-лер уақытпен белгіленіп, алдын ала белгіленген уақыт кезеңінде белсенді болмағаннан кейін жарамдылық мерзімі аяқталады. Жарамдылық мерзімі де әр эмбеддинг кестесі үшін реттелетін болып табылады, бұл тарихи ақпаратқа әртүрлі сезімталдыққа ие ерекшеліктерді ажыратуға мүмкіндік береді. Біздің жүзеге асыруымызда, HashTable TensorFlow ресурстық операциясы ретінде жүзеге асырылады. Айнымалыға ұқсас, іздеулер мен жаңартулар да оңай интеграция мен жақсы үйлесімділік үшін жергілікті TensorFlow операциялары ретінде жүзеге асырылады. 2.2 Онлайн оқыту Monolith-те оқыту екі кезеңге бөлінеді (1-сурет): (1) Партиялық оқыту кезеңі. Бұл кезең кәдімгі TensorFlow оқыту циклі сияқты жұмыс істейді: әрбір оқу қадамында, оқу жұмысшысы қоймадан оқу мысалдарын бір шағын партиямен оқиды, PS-тен параметрлерді сұрайды, алға және артқа өтуді есептейді, және ақыр соңында жаңартылған параметрлерді оқыту PS-іне жібереді. Біздің деректер жинағымызды бір рет қана оқытамыз. Партиялық оқыту, біз модель архитектурасын өзгерткенде және модельді қайта оқытқанда, тарихи деректерді оқыту үшін пайдалы; (2) Онлайн оқыту кезеңі. Модель онлайн қызмет көрсетуге орналастырылғаннан кейін, оқыту тоқтамайды, бірақ онлайн оқыту кезеңіне енеді. Қоймадан шағын партия мысалдарын оқудың орнына, оқыту жұмысшысы нақты уақыттағы деректерді ағымдағы күйде тұтынып, оқыту PS-ін жаңартады. Оқыту PS-і өзінің параметрлерін қызмет көрсету PS-іне мезгіл-мезгіл синхрондайды, бұл пайдаланушы жағында дереу әсер етеді. Бұл біздің модельге пайдаланушының кері байланысына сәйкес нақты уақыт режимінде бейімделуге мүмкіндік береді. Monolith партиялық оқыту мен онлайн оқыту арасында үздіксіз ауысу мүмкіндігімен салынған. Бұл 4-суретте көрсетілген ағындық қозғалтқыш дизайнымыздың арқасында мүмкін болады. 2.2.1 Ағындық қозғалтқыш. Біздің дизайнымызда, біз пайдаланушылардың әрекеттерін (мысалы, элементке басу немесе элементті ұнату және т.б.) тіркеу үшін бір Kafka [ ] тізбегін, ал ерекшеліктер үшін екінші Kafka тізбегін қолданамыз. Қозғалтқыштың негізі - онлайн ерекшеліктерді біріктіретін Flink [ ] ағындық жұмысы. Онлайн біріктіргіш пайдаланушы әрекеттерінен алынған ерекшеліктерді таңбалармен біріктіреді және оқу мысалдарын жасайды, олар содан кейін Kafka тізбегіне жазылады. Оқу мысалдарына арналған тізбек онлайн және партиялық оқытуды екеуін де тұтынады: 13 4 Онлайн оқыту үшін, оқыту жұмысшысы деректерді тікелей Kafka тізбегінен оқиды; Партиялық оқыту үшін, деректерді шығару жұмысы алдымен HDFS [ ] тастайды; HDFS-те деректер белгілі бір мөлшерге жиналғаннан кейін, оқыту жұмысшысы HDFS-тен деректерді алады және партиялық оқытуды жүзеге асырады. 18 Оқыту PS-індегі жаңартылған параметрлер параметрлерді синхрондау кестесіне сәйкес қызмет көрсету PS-іне жіберіледі. Шынайы өмірдегі қолданбаларда, пайдаланушы әрекеттерінің журналы мен ерекшеліктері онлайн біріктіргішке (5-сурет) уақыт ретімен ешқандай кепілсіз ағынмен келеді. Сондықтан біз әр сұрау үшін бірегей кілтті қолданамыз, сондықтан пайдаланушы әрекеті мен ерекшеліктерін дұрыс жұптастыруға болады. 2.2.2 Онлайн біріктіргіш. Пайдаланушы әрекетінің кідірісі де мәселе болуы мүмкін. Мысалы, пайдаланушы бірнеше күн бұрын көрген элементті сатып алуға шешім қабылдаудан бұрын бірнеше күн өткізуі мүмкін. Бұл біріктіргіш үшін қиындық тудырады, себебі егер барлық ерекшеліктер кэште сақталса, ол жадқа сыймайды. Біздің жүйемізде, белгілі бір уақыт кезеңінен асатын ерекшеліктерді сақтау үшін дискідегі кілт-мәнді сақтау орны қолданылады. Пайдаланушы әрекетінің журналы келгенде, ол алдымен жадтағы кэшті іздейді, содан кейін кэш жоқ болған жағдайда кілт-мәнді сақтау орнын іздейді. Шынайы өмірдегі қолданбаларда туындайтын тағы бір мәселе - теріс және оң мысалдардың таралуы өте тең емес, біріншісінің саны екіншісінен ондаған есе көп болуы мүмкін. Оң мысалдарды теріс мысалдар басып кетпеуі үшін, әдеттегі стратегия - теріс үлгілеуді жүзеге асыру. Бұл, сөзсіз, оқытылған модельдің негізгі таралуын өзгертеді, оны оң болжамдардың жоғары ықтималдығына қарай реттейді. Шығу ретінде, біз қызмет көрсету кезінде лог-оддтарды түзетуді [ ] қолданамыз, бұл онлайн модельдің бастапқы таралуының бейтарап бағалаушы екендігіне кепілдік береді. 19 Онлайн оқыту кезінде, Monolith оқыту кластері онлайн қызмет көрсету модулінен деректерді үздіксіз қабылдайды және оқыту PS-індегі параметрлерді жаңартады. Оқытылған жаңа параметрлерден онлайн қызмет көрсету PS-і пайдалану үшін маңызды қадам - жаңартылған модель параметрлерін синхрондау. Өндірістік ортада біз бірнеше қиындықтарға тап болдық: 2.2.3 Параметрлерді синхрондау. Онлайн қызмет көрсету PS-індегі модельдер жаңарту кезінде тоқтамауы керек. Біздің өндірістегі модельдер әдетте бірнеше терабайт өлшемді, сондықтан барлық параметрлерді ауыстыру біраз уақытты алады. Онлайн PS-ті жаңарту процесінде модельді қызмет көрсетуден тоқтату өте төзімсіз болады, ал жаңартулар нақты уақытта жүзеге асырылуы керек; Бірнеше терабайттық модельді толығымен оқыту PS-інен онлайн қызмет көрсету PS-іне тасымалдау PS-тегі желілік өткізу қабілеті мен жадыға үлкен қысым түсіреді, себебі бұл жаңа келген модельді қабылдау үшін модельдің екі еселенген өлшемін жады қажет етеді. Біздің бизнес сценарийіміздің мөлшеріне онлайн оқытуды масштабтау үшін, біз біздің модельдеріміздің бірнеше байқалатын сипаттамаларына негізделген Monolith-те жүйелі түрде параметрлерді incrementally, on-the-fly синхрондау механизмін жасадық: (1) Сирек параметрлер ұсыныс модельдерінің өлшемін басымдайды; (2) Қысқа уақыт терезесі берілгенде, тек ID-лердің кішігірім бөлігі ғана оқытылып, олардың эмбеддингтері жаңартылады; (3) Тығыз айнымалылар сирек эмбеддингтерден әлдеқайда баяу қозғалады. Бұл, моментке негізделген оптимизаторларда, тығыз айнымалыларға моментті жинақтау ұсыныс оқыту деректерінің үлкен мөлшерімен күшейтіледі, ал тек бірнеше сирек эмбеддингтер бір деректер партиясында жаңарту алады. (1) және (2) барлық ерекшелік ID-лері бойынша сирек жаңартуларды пайдалануға мүмкіндік береді. Monolith-те біз параметрлерді синхрондаудан кейін оқытылған ID-лерді көрсететін қозғалған кілттердің хэш жиынтығын сақтаймыз. Біз сирек параметрлердің кішігірім бөлігін, кілттері touched-keys жиынтығында болса, оқыту PS-інен онлайн қызмет көрсету PS-іне минуттық уақыт аралығымен жібереміз. Бұл салыстырмалы түрде кішігірім параметрлік жаңарту пакеті желілік беріліс үшін жеңіл және синхрондау кезінде жадының күрт өсуіне себеп болмайды. Біз сондай-ақ (3) арқылы сирек параметрлер үшін белсендірек синхрондау кестесін орнату арқылы желілік I/O және жадты тұтынуды одан әрі азайтамыз, ал тығыз параметрлерді сирек жаңартамыз. Бұл сияқты тығыз параметрлер сирек эмбеддинг бөлігімен салыстырғанда ескірген нұсқасы болып табылатын жағдайға әкелуі мүмкін. Алайда, мұндай үйлесімсіздік (3) себебінен төзімді болуы мүм