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

Авторлар: Чжуоран Лю, Bytedance Inc. Леки Цзоу, Bytedance Inc. Сюань Цзоу, Bytedance Inc. Кайхуа Ван, Bytedance Inc. Бяо Чжан, Bytedance Inc. Да Тан, Bytedance Inc. Болин Чжу∗, Фудан университеті Ицзе Чжу, Bytedance Inc. Пенг Ву, Bytedance Inc. Ке Ван, Bytedance Inc. Юлонг Ченг†, Bytedance Inc. (youlong.cheng@bytedance.com) АННОТАЦИЯ Масштабты және нақты уақыттағы ұсыныс жүйесін құру уақытқа сезімтал тұтынушылардың кері байланысына негізделген көптеген бизнес үшін өте маңызды, мысалы, қысқа бейнелерді рейтингілеу немесе онлайн жарнама. Ten-sorFlow немесе PyTorch сияқты өндіріс масштабындағы терең оқыту фреймворктерінің кеңінен таралуына қарамастан, бұл жалпы мақсаттағы фреймворктер әртүрлі себептермен ұсыныс сценарийлерінде бизнес талаптарына сәйкес келмейді: бір жағынан, динамикалық және сирек кездесетін сипаттамалармен ұсыныс үшін статикалық параметрлер мен тығыз есептеулерге негізделген жүйелерді реттеу модель сапасына зиянды; екінші жағынан, мұндай фреймворктер пакеттік оқыту кезеңі мен қызмет көрсету кезеңін толығымен бөлу арқылы жасалған, бұл модельдің тұтынушылардың кері байланысымен нақты уақытта өзара әрекеттесуіне жол бермейді. Бұл мәселелер бізді дәстүрлі тәсілдерді қайта қарауға және түбегейлі басқа дизайн шешімдерін зерттеуге итермеледі. Бұл мақалада біз онлайн оқытуға арналған жүйе — 1 ұсынамыз. Біздің дизайнымыз басқа ұсыныс жүйелерінен айтарлықтай айырмашылығы бар қолданбалық жүктемелер мен өндірістік ортаны бақылауға негізделген. Біздің үлестеріміз көп қырлы: бірінші, біз сыйымдылықты азайту үшін expirable embedding және жиілік сүзгісі сияқты оңтайландырулармен қақтығыссыз embedding кестесін жасадық; екінші, біз жоғары отка төзімділікке ие, өндіріске дайын онлайн оқыту архитектурасын ұсынамыз; ақырғы, біз жүйенің сенімділігі нақты уақыттағы оқыту үшін саудаласуға болатынын дәлелдедік. Monolith BytePlus Recommend2 өнімінде сәтті енгізілді. Monolith 1 КІРІСПЕ Өткен онжылдықта ұсыныс әдістерімен жұмыс істейтін бизнес түрлерінің бумы болды. Жақсы тұтынушы тәжірибесіне қол жеткізу үшін, әрбір жеке пайдаланушыға дербес мазмұнды нақты уақытта жауап ретінде жеткізу - бұл бизнес қолданбаларының ортақ мақсаты. Осы мақсатта, пайдаланушының соңғы әрекеттерінен алынған ақпарат модельді оқыту үшін негізгі кіріс ретінде жиі қолданылады, өйткені ол пайдаланушының портретін ең жақсы бейнелейді және пайдаланушының қызығушылығы мен болашақ әрекеттері туралы болжамдар жасайды. Терең оқыту ұсыныс модельдерінде [ , , , , , ] басым болып келеді, өйткені пайдаланушы деректерінің үлкен көлемі массалық деректерге негізделген нейрондық модельдерге табиғи түрде сәйкес келеді. Алайда, салалық деңгейдегі ұсыныс жүйелерінде терең оқытудың күшін пайдалану жөніндегі күш-жігер өмірден алынған пайдаланушы мінез-құлқының ерекшеліктерінен туындаған мәселелерге үнемі кездесіп отырады. Бұл деректер тілдік модельдеу немесе компьютерлік көру сияқты дәстүрлі терең оқыту мәселелерінде қолданылатын деректерден екі аспекті бойынша айтарлықтай ерекшеленеді: 5 6 10 12 20 21 (1) Сипаттамалар көбінесе сирек, категориялық және динамикалық түрде өзгеретін болады; (2) Оқыту деректерінің іргелі таралуы стационар емес, яғни концепцияның ауытқуы . Мұндай айырмашылықтар ұсыныс жүйелерімен жұмыс істейтін зерттеушілер мен инженерлер үшін бірегей қиындықтар тудырды. 1.1 Сирек кездесу және динамика Ұсыныс деректері көбінесе сирек кездесетін категориялық сипаттамаларды қамтиды, олардың кейбіреулері аз жиілікпен пайда болады. Оларды жоғары өлшемді embedding кеңістігіне ауыстырудың жалпы тәжірибесі бірқатар мәселелерге әкелуі мүмкін: • Сөз бөлшектерінің саны шектеулі болатын тілдік модельдерден айырмашылығы, пайдаланушылар мен рейтингілеу элементтерінің саны әлдеқайда көп. Сондай үлкен embedding кестесі бір хост жадына сыймауы мүмкін; • Одан да жаманы, пайдаланушылар мен элементтер көбірек қосылған сайын embedding кестесінің өлшемі уақыт өте келе өседі деп күтілуде, ал [ , ] сияқты фреймворктер embedding кестесін көрсету үшін тұрақты өлшемді тығыз айнымалыларды пайдаланады. 1 17 Іс жүзінде көптеген жүйелер жадының сыйымдылығын азайту және ID-лердің өсуіне жол беру үшін аз қақтығыс хэширлеуді [ , ] қолданады. Бұл ID-лердің embedding кестесінде жиілік бойынша біркелкі таралатыны және қақтығыстардың модель сапасына зиянсыз болатыны туралы шамадан тыс идеалды болжамға негізделеді. Өкінішке орай, бұл нақты әлемдегі ұсыныс жүйесі үшін сирек кездеседі, мұнда пайдаланушылар мен элементтердің кішігірім тобы айтарлықтай көп кездеседі. Embedding кестесінің өлшемінің органикалық өсуімен, хэш кілтінің қақтығыс ықтималдығы артып, модель сапасының нашарлауына әкеледі 3 6 . Сондықтан өндіріс масштабындағы ұсыныс жүйелері үшін параметрлеріндегі мүмкіндігінше көп сипаттамаларды қамту және пайдаланушылар мен элементтер санын икемді түрде реттеу мүмкіндігіне ие болу табиғи талап болып табылады. 1.2 Стационар емес таралу Визуалды және тілдік үлгілер ғасырлар бойы дамымайды, ал бір тақырыпқа қызығатын пайдаланушы келесі минутта өз қызығушылығын өзгертуі мүмкін. Нәтижесінде, пайдаланушы деректерінің іргелі таралуы стационар емес, бұл құбылыс әдетте Концепциялық ауытқу деп аталады. Интуитивті түрде, жақында болған тарихтан алынған ақпарат пайдаланушының мінез-құлқындағы өзгерістерді болжауға тиімдірек үлес қоса алады. Концепциялық ауытқу әсерін азайту үшін, қызмет көрсететін модельдер пайдаланушының соңғы қызығушылығын көрсету үшін жаңа пайдаланушы кері байланысынан мүмкіндігінше нақты уақытта жаңартылуы керек. Осы айырмашылықтарды ескере отырып және өндірісімізде пайда болатын мәселелерді бақылай отырып, біз осы қиындықтарды шешуге арналған ауқымды ұсыныс жүйесі -ті жасадық. Біз өндірістік ортада дизайнымызды тексеру және қайталау үшін кең ауқымды эксперименттер жүргіздік. Monolith қабілетті: Monolith (1) Қақтығыссыз хэш кестесін және динамикалық сипаттамаларды жою тетігін жобалау арқылы сирек кездесетін сипаттамалар үшін толық экспрессивті күшті қамтамасыз ету; (2) Онлайн оқытумен нақты уақыттағы қызмет көрсету кері байланысын оқытуға қайтару. Осы архитектуралық мүмкіндіктермен қуатталған Monolith, хэш-трюктерді қолданатын жүйелерден шамамен ұқсас жадыны пайдалана отырып, айтарлықтай жақсы нәтиже көрсетеді және серверлеріміздің есептеу қуатын шамадан тыс жүктемей-ақ, жоғарыдағы заманауи онлайн AUC-ға қол жеткізеді. Мақаланың қалған бөлігі келесідей ұйымдастырылған. Алдымен біз Monolith-тың қақтығыссыз хэш кестесі және нақты уақыттағы оқыту арқылы қазіргі қиындықтарды қалай шешетіні туралы дизайн егжей-тегжейін 2-бөлімде келтіреміз. Эксперименттер мен нәтижелер 3-бөлімде, өндірісте сыналған қорытындылармен және уақытқа сезімталдық, сенімділік және модель сапасы арасындағы сауда-саттықтарды талқылаумен бірге ұсынылады. 4-бөлімде тиісті жұмыстар жинақталады және олар Monolith-пен салыстырылады. 5-бөлім бұл жұмысты қорытындылайды. 2 ДИЗАЙН Monolith-тың жалпы архитектурасы әдетте TensorFlow-тің таратылған Worker- arameter erver параметрлеріне сәйкес келеді (2-сурет). Worker-PS архитектурасында машиналарға әртүрлі рөлдер тағайындалады; Worker машиналары граф анықтағандай есептеулерді орындауға жауапты, ал PS машиналары параметрлерді сақтайды және Worker-лер есептеген градиенттерге сәйкес оларды жаңартады. P S Ұсыныс модельдерінде параметрлер екі жиынтыққа бөлінеді: тығыз және сирек. Тығыз параметрлер - бұл терең нейрондық желідегі салмақтар/айнымалылар, ал сирек параметрлер сирек кездесетін сипаттамаларға сәйкес келетін embedding кестелерін білдіреді. Біздің дизайнымызда тығыз және сирек параметрлер де TensorFlow Графының бөлігі болып табылады және параметр серверлерінде сақталады. Тығыз параметрлер үшін TensorFlow-тің Variable-мен ұқсас, біз сирек параметрлер үшін жоғары тиімді, қақтығыссыз және икемді HashTable операциялары жиынтығын жасадық. Оқыту мен инференс арасындағы айырмашылықтардан туындаған Tensor-Flow-тың шектеулеріне қосымша ретінде, Monolith-тың икемді түрде масштабталатын онлайн оқытуы, модельдің беріктігін қамтамасыз ететін отка төзімділік тетігі арқылы оқыту-PS-тен онлайн қызмет көрсету-PS-ке параметрлерді тиімді түрде синхрондауға арналған. 2.1 Хэш кестесі Сирек кездесетін параметр өкілділігін жобалауда бірінші принцип - әртүрлі ID-лерден ақпаратты бірдей тығыз embedding-ке тығып жіберуден аулақ болу. Сыйымдылығы бар TensorFlow Variable-мен динамикалық өлшемді embedding кестесін симуляциялау ID қақтығысына әкеледі, бұл жаңа ID-лер келгенде және кесте өскенде нашарлайды. Сондықтан Variable-ге негізделудің орнына, біз сирек кездесетін параметрлер үшін жаңа кілт-мәнді 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-лерге сәйкес келетін Embeddings, оқыту деректерінің жетіспеушілігінен толық оқытылмаған және модель оларға негізделген жақсы бағалау жасай алмайды. Қорытындылай келе, бұл ID-лер нәтижеге әсер етуі екіталай, сондықтан модель сапасы осы ID-лерді азайған кездесулерімен жоюдан зардап шекпейді; (2) Ескі тарихтан алынған ескі ID-лер ағымдағы модельге сирек жағдайда үлес қосады, өйткені олардың көпшілігі ешқашан бармайды. Бұл белсенді емес пайдаланушы немесе ескірген қысқа бейне болуы мүмкін. Осы ID-лер үшін embeddings сақтау модельге ешқандай көмектеспейді, тек біздің PS жадымызды босқа сарқудан басқа. Осы байқауларға негізделген, біз HashTable-дің жады тиімділігін арттыру үшін бірнеше сипаттама ID сүзгілеу эвристикаларын жасадық: (1) ID-лер embedding кестелеріне қабылданғанға дейін сүзгіден өткізіледі. Бізде екі сүзу әдісі бар: Бірінші, біз кілттер ретінде енгізілгенге дейін олардың кездесулері бойынша сүземіз, мұнда кездесулердің шегі әр модель үшін өзгеретін реттелетін гиперпараметр болып табылады; Сонымен қатар, біз жадыны одан әрі азайтуға көмектесетін ықтималдық сүзгіні пайдаланамыз; ![#Figure 4: Streaming Engine. Пайдаланушы → Модель сервері → Оқыту жұмысшысы → Модель сервері → Пайдаланушы] арасындағы ақпараттық кері байланыс циклі Пакеттік оқыту жолына түскенде ұзақ уақытты алады, ал Онлайн оқыту циклды тезірек жабады.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID-лер уақытпен белгіленіп, алдын-ала белгіленген уақыт кезеңі ішінде белсенді болмағаннан кейін жарамсыз деп белгіленеді. Әрбір embedding кестесі үшін жарамсыздық уақыты да реттелетін болады, бұл тарихи ақпаратқа сезімталдықтары әртүрлі сипаттамаларды ажыратуға мүмкіндік береді. Біздің жүзеге асыруымызда, HashTable TensorFlow ресурс операциясы ретінде жүзеге асырылады. Variable сияқты, іздеу және жаңартулар да жеңіл интеграция және жақсы үйлесімділік үшін 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-та қосымша, нақты уақыттағы, мезгіл-мезгіл параметрлерді синхрондау тетігін жасадық: (1) Сирек кездесетін параметрлер ұсыныс модельдерінің өлшемінде басым; (2) Қысқа уақыт терезесі берілгенде, тек ID-лердің кішігірім бөлігі ғана оқытылады және олардың embeddings жаңартылады; (3) Тығыз айнымалылар сирек кездесетін embedding-терге қарағанда әлдеқайда баяу қозғалады. Бұл моментке негізделген оптимизаторлардың себебінен, тығыз айнымалылар үшін моментті жинақтау ұсыныс оқыту деректерінің үлкен өлшемінен күшейеді, ал бір деректер пакетінде тек бірнеше сирек embedding-тер жаңартулар алады. (1) және (2) бізге барлық сипаттама ID-лері бойынша сирек жаңартуларды пайдалануға мүмкіндік береді. Monolith-та біз параметрлерді синхрондаудан кейін жаңартылған ID-лерді білдіретін, жанасқан кілттердің хэш жиынтығын сақтаймыз. Біз жаңартылған сирек параметрлердің кілттері тиісті кілттер жиынтығында болған жағдайда, оқыту PS-інен онлайн қызмет көрсету PS-іне минуттық уақыт аралығында жібереміз. Бұл салыстырмалы түрде кішігірім қосымша параметрлік жаңарту пакеті желілік тасымалдау үшін жеңіл және синхрондау кезінде жадының кенеттен өсуіне әкелмейді. Біз сондай-ақ (3) -ті пайдаланып, сирек параметрлер үшін анағұрлым белсенді синхрондау кестесін орнату арқылы желілік I/O және жадыны пайдалануды одан әрі азайтамыз, ал тығыз параметрлерді жиі емес түрде жаңартамыз. Бұл тығыз параметрлер сирек кездесетін бөлікке қарағанда салыстырмалы түрде ескірген нұсқа болып табылатын жағ