Inside ByteDance’s Monolith: The Engine Powering Smarter, Faster Content Feeds

```html អ្នកនិពន្ធ: 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) សេចក្តីសង្ខេប ការកសាងប្រព័ន្ធណែនាំដែលអាចបត់បែនបាន និងពេលវេលាគឺមានសារៈសំខាន់សម្រាប់អាជីវកម្មជាច្រើនដែលជំរុញដោយមតិកែលម្អរបស់អតិថិជនដែលទាក់ទងនឹងពេលវេលា ដូចជាការវាយតម្លៃវីដេអូខ្លី ឬការផ្សាយពាណិជ្ជតាមអ៊ិនធរណេត។ ទោះបីជាមានការទទួលយកយ៉ាងទូលំទូលាយនូវស៊ុមការងាររៀនសូត្រជ្រៅលំដាប់ផលិតកម្មដូចជា Ten-sorFlow ឬ PyTorch ក៏ដោយ ស៊ុមការងារទូទៅទាំងនេះមិនអាចបំពេញតម្រូវការអាជីវកម្មក្នុងស្ថានភាពណែនាំសម្រាប់ហេតុផលផ្សេងៗ៖ ម្យ៉ាងវិញទៀត ការកែតម្រូវប្រព័ន្ធដោយផ្អែកលើប៉ារ៉ាម៉ែត្រថេរ និងការគណនាដង់សម្រាប់ណែនាំជាមួយនឹងលក្ខណៈពិសេសដែលផ្លាស់ប្តូរ និងមិនច្បាស់លាស់គឺមានគ្រោះថ្នាក់ដល់គុណភាពនៃម៉ូដែល។ ម្យ៉ាងវិញទៀត ស៊ុមការងារបែបនេះត្រូវបានរចនាឡើងជាមួយនឹងដំណាក់កាលបណ្តុះបណ្តាលជាបាច់ និងដំណាក់កាលបម្រើដែលបំបែកទាំងស្រុង ដែលការពារម៉ូដែលពីការប្រាស្រ័យទាក់ទងជាមួយមតិកែលម្អរបស់អតិថិជនតាមពេលវេលាជាក់ស្តែង។ បញ្ហាទាំងនេះបាននាំឱ្យយើងពិនិត្យឡើងវិញនូវវិធីសាស្រ្តប្រពៃណី និងស្វែងរកជម្រើសរចនាដែលខុសគ្នាយ៉ាងខ្លាំង។ នៅក្នុងអត្ថបទនេះ យើងបង្ហាញ 1 ដែលជាប្រព័ន្ធដែលត្រូវបានបង្កើតឡើងសម្រាប់ការបណ្តុះបណ្តាលតាមអ៊ីនធឺណិត។ ការរចនារបស់យើងត្រូវបានជំរុញដោយការសង្កេតការងារកម្មវិធីរបស់យើង និងបរិស្ថានផលិតកម្ម ដែលឆ្លុះបញ្ចាំងពីការចាកចេញយ៉ាងខ្លាំងពីប្រព័ន្ធណែនាំផ្សេងទៀត។ ការរួមចំណែករបស់យើងមានច្រើនយ៉ាង៖ ទីមួយ យើងបានបង្កើតតារាងតួអក្សរដែលមិនមានការប៉ះទង្គិចគ្នាជាមួយនឹងការបង្កើនប្រសិទ្ធភាពដូចជាតួអក្សរដែលអាចផុតកំណត់ និងការត្រងប្រេកង់ដើម្បីកាត់បន្ថយទំហំអង្គចងចាំរបស់វា។ ទីពីរ យើងផ្តល់នូវស្ថាបត្យកម្មបណ្តុះបណ្តាលតាមអ៊ីនធឺណិតដែលត្រៀមរួចជាស្រេចផលិតកម្មជាមួយនឹងភាពធន់នឹងកំហុសខ្ពស់។ ជាចុងក្រោយ យើងបានพิสูจน์ថាភាពជឿជាក់នៃប្រព័ន្ធអាចត្រូវបានប្តូរយកសម្រាប់ការរៀនពេលវេលាជាក់ស្តែង។ Monolith ត្រូវបានដាក់បញ្ចូលដោយជោគជ័យនៅក្នុងផលិតផល BytePlus Recommend2។ Monolith 1 មូលដ្ឋាន មួយទសវត្សរ៍ចុងក្រោយនេះ បានឃើញការកើនឡើងនៃអាជីវកម្មដែលขับเคลื่อนដោយបច្ចេកទេសណែនាំ។ ក្នុងការស្វែងរកបទពិសោធន៍អតិថិជនកាន់តែប្រសើរ ការផ្តល់មាតិកាដែលបានប្ដូរតាមបំណងសម្រាប់អ្នកប្រើប្រាស់ម្នាក់ៗជាការឆ្លើយតបតាមពេលវេលាជាក់ស្តែង គឺជាគោលដៅទូទៅនៃកម្មវិធីអាជីវកម្មទាំងនេះ។ សម្រាប់បញ្ហានេះ ព័ត៌មានពីអន្តរកម្មចុងក្រោយបំផុតរបស់អ្នកប្រើប្រាស់តែងតែត្រូវបានប្រើជាការបញ្ចូលបឋមសម្រាប់ការបណ្តុះបណ្តាលម៉ូដែល ចាប់តាំងពីវានឹងបង្ហាញរូបភាពអ្នកប្រើប្រាស់ និងធ្វើការទស្សន៍ទាយពីចំណាប់អារម្មណ៍ និងឥរិយាបថអនាគតរបស់អ្នកប្រើប្រាស់បានល្អបំផុត។ ការរៀនសូត្រជ្រៅបានគ្របដណ្ដប់ម៉ូដែលណែនាំ [ , , , , , ] ដោយសារតែទិន្នន័យអ្នកប្រើប្រាស់មានចំនួនច្រើនគឺសមរម្យសម្រាប់ម៉ូដែលសរសៃប្រសាទដែលขับเคลื่อนដោយទិន្នន័យយ៉ាងច្រើន។ ទោះយ៉ាងណាក៏ដោយ ការខិតខំប្រឹងប្រែងដើម្បីប្រើប្រាស់ថាមពលនៃការរៀនសូត្រជ្រៅនៅក្នុងប្រព័ន្ធណែនាំលំដាប់ឧស្សាហកម្មតែងតែជួបប្រទះនឹងបញ្ហាដែលកើតចេញពីលក្ខណៈពិសេសនៃទិន្នន័យដែលទទួលបានពីឥរិយាបថអ្នកប្រើប្រាស់ពិតប្រាកដ។ ទិន្នន័យទាំងនេះខុសគ្នាខ្លាំងពីទិន្នន័យដែលប្រើក្នុងបញ្ហាសិក្ខាលោការៀនសូត្រជ្រៅបែបប្រពៃណីដូចជាការបង្កើតម៉ូដែលភាសា ឬការមើលឃើញកុំព្យូទ័រក្នុងពីរផ្នែក៖ 5 6 10 12 20 21 (1) លក្ខណៈពិសេសភាគច្រើនមិនច្បាស់លាស់ បែងចែក និងផ្លាស់ប្តូរថាមវន្ត; (2) ការចែកចាយមូលដ្ឋាននៃទិន្នន័យបណ្តុះបណ្តាលគឺមិនស្ថិតស្ថេរ ហៅថា Concept Drift [8]. ភាពខុសគ្នាបែបនេះបានបង្កើតបញ្ហាប្រឈមតែមួយគត់ដល់អ្នកស្រាវជ្រាវ និងវិស្វករដែលធ្វើការលើប្រព័ន្ធណែនាំ។ 1.1 ភាពមិនច្បាស់លាស់ និងថាមវន្ត ទិន្នន័យសម្រាប់ការណែនាំភាគច្រើនមានលក្ខណៈបែងចែកដែលមិនច្បាស់លាស់ ដែលខ្លះលេចឡើងដោយមានប្រេកង់ទាប។ ការអនុវត្តទូទៅនៃការបំប្លែងពួកវាទៅក្នុងកន្លែងតួអក្សរដែលមានវិមាត្រខ្ពស់នឹងនាំឱ្យមានបញ្ហាច្រើន៖ • ផ្ទុយទៅនឹងម៉ូដែលភាសាដែលចំនួនបំណែកពាក្យមានកំណត់ ចំនួនអ្នកប្រើប្រាស់ និងធាតុដែលបានដាក់ចំណាត់ថ្នាក់មានចំនួនច្រើនជាងរាប់លានដង។ តារាងតួអក្សរដ៏ធំសម្បើមបែបនេះនឹងពិបាកនឹងបញ្ចូលក្នុងអង្គចងចាំរបស់ម៉ាស៊ីនតែមួយ។ • អាក្រក់ជាងនេះទៅទៀត ទំហំនៃតារាងតួអក្សរត្រូវបានរំពឹងថានឹងកើនឡើងតាមពេលវេលា នៅពេលដែលអ្នកប្រើប្រាស់ និងធាតុថ្មីៗត្រូវបានទទួលយក ខណៈពេលដែលស៊ុមការងារដូចជា [ , ] ប្រើប្រាស់អថេរដង់ដែលមានទំហំថេរដើម្បីតំណាងឱ្យតារាងតួអក្សរ។ 1 17 តាមការពិត ប្រព័ន្ធជាច្រើនទទួលយកការតម្រៀបដែលមានការប៉ះទង្គិចតិច [ , ] ជាមធ្យោបាយកាត់បន្ថយទំហំអង្គចងចាំ និងអនុញ្ញាតឱ្យលេខសម្គាល់កើនឡើង។ នេះពឹងផ្អែកលើការសន្មត់ដែលលើសពីឧត្តមគតិ ដែលថាលេខសម្គាល់នៅក្នុងតារាងតួអក្សរត្រូវបានចែកចាយស្មើៗគ្នាលើប្រេកង់ ហើយការប៉ះទង្គិចមិនប៉ះពាល់ដល់គុណភាពនៃម៉ូដែលទេ។ ជាអកុសល នេះកម្រកើតមានណាស់សម្រាប់ប្រព័ន្ធណែនាំពិតប្រាកដ ដែលក្នុងនោះអ្នកប្រើប្រាស់ ឬធាតុមួយចំនួនតូចមានការកើតឡើងច្រើនយ៉ាងមានន័យ។ ជាមួយនឹងការកើនឡើងនៃទំហំតារាងតួអក្សរ ការកើតឡើងនៃការប៉ះទង្គិចគន្លឹះតម្រៀបកើនឡើង និងនាំឱ្យគុណភាពម៉ូដែលកាន់តែយ៉ាប់យ៉ឺន 3 6 [3]. ហេតុដូច្នេះហើយ វាជាតម្រូវការធម្មតាសម្រាប់ប្រព័ន្ធណែនាំលំដាប់ផលិតកម្មដែលមានសមត្ថភាពចាប់យកលក្ខណៈពិសេសជាច្រើនតាមដែលអាចធ្វើទៅបាននៅក្នុងប៉ារ៉ាម៉ែត្ររបស់វា ហើយក៏មានសមត្ថភាពក្នុងការកែតម្រូវចំនួនអ្នកប្រើប្រាស់ និងធាតុដែលវាកំពុងព្យាយាមរក្សាទុក។ 1.2 ការចែកចាយមិនស្ថិតស្ថេរ លំនាំដែលមើលឃើញ និងភាសាแทบមិនវិវឌ្ឍន៍ក្នុងរយៈពេលរាប់រយឆ្នាំ ខណៈពេលដែលអ្នកប្រើប្រាស់ម្នាក់ដែលមានចំណាប់អារម្មណ៍លើប្រធានបទមួយអាចផ្លាស់ប្តូរការសាទររបស់ពួកគេរៀងរាល់នាទីបន្ទាប់។ ជាលទ្ធផល ការចែកចាយមូលដ្ឋាននៃទិន្នន័យអ្នកប្រើប្រាស់គឺមិនស្ថិតស្ថេរ ដែលជាបាតុភូតដែលត្រូវបានគេសំដៅជាទូទៅថា Concept Drift [8]. តាមការយល់ដឹង ព័ត៌មានពីប្រវត្តិសាស្ត្រថ្មីៗនេះអាចរួមចំណែកកាន់តែមានប្រសិទ្ធភាពក្នុងការទស្សន៍ទាយការផ្លាស់ប្តូរឥរិយាបថរបស់អ្នកប្រើប្រាស់។ ដើម្បីកាត់បន្ថយផលប៉ះពាល់នៃ Concept Drift ម៉ូដែលបម្រើត្រូវតែត្រូវបានធ្វើបច្ចុប្បន្នភាពពីមតិកែលម្អអ្នកប្រើប្រាស់ថ្មីៗឱ្យជិតបំផុតតាមពេលវេលាជាក់ស្តែងតាមដែលអាចធ្វើទៅបាន ដើម្បីឆ្លុះបញ្ចាំងពីចំណាប់អារម្មណ៍ចុងក្រោយរបស់អ្នកប្រើប្រាស់។ ដោយពិចារណាលើភាពខុសគ្នានេះ និងដោយការសង្កេតលើបញ្ហាដែលកើតឡើងពីផលិតកម្មរបស់យើង យើងបានរចនា ដែលជាប្រព័ន្ធណែនាំខ្នាតធំដើម្បីដោះស្រាយបញ្ហាទាំងនេះ។ យើងបានធ្វើការពិសោធន៍យ៉ាងទូលំទូលាយដើម្បីផ្ទៀងផ្ទាត់ និងធ្វើបច្ចុប្បន្នភាពការរចនារបស់យើងនៅក្នុងបរិស្ថានផលិតកម្ម។ Monolith អាច Monolith (1) ផ្តល់ថាមពលបង្ហាញពេញលេញសម្រាប់លក្ខណៈពិសេសមិនច្បាស់លាស់ដោយការរចនាតារាងតម្រៀបដែលមិនមានការប៉ះទង្គិចគ្នា និងយន្តការដកលក្ខណៈពិសេសថាមវន្ត; (2) ជួយបង្វិលមតិកែលម្អការបម្រើទៅការបណ្តុះបណ្តាលតាមពេលវេលាជាក់ស្តែងជាមួយនឹងការបណ្តុះបណ្តាលតាមអ៊ីនធឺណិត។ ដោយមានសមត្ថភាពស្ថាបត្យកម្មទាំងនេះ Monolith តែងតែមានប្រសិទ្ធភាពជាងប្រព័ន្ធដែលប្រើបច្ចេកទេសតម្រៀបដែលមានការប៉ះទង្គិចគ្នាជាមួយនឹងការប្រើប្រាស់អង្គចងចាំប្រហាក់ប្រហែលគ្នា ហើយសម្រេចបាននូវ AUC បម្រើតាមអ៊ីនធឺណិតដ៏ទំនើបបំផុតដោយមិនធ្វើឱ្យថាមពលគណនារបស់ម៉ាស៊ីនបម្រើរបស់យើងមានបន្ទុកខ្លាំងពេក។ អត្ថបទដែលនៅសល់ត្រូវបានរៀបចំដូចខាងក្រោម។ យើងនឹងរៀបរាប់លម្អិតពីព័ត៌មានលម្អិតនៃការរចនាអំពីរបៀបដែល Monolith ដោះស្រាយបញ្ហាដែលមានស្រាប់ជាមួយនឹងតារាងតម្រៀបដែលមិនមានការប៉ះទង្គិចគ្នា និងការបណ្តុះបណ្តាលតាមពេលវេលាជាក់ស្តែងនៅក្នុងផ្នែកទី 2។ ការពិសោធន៍ និងលទ្ធផលនឹងត្រូវបានបង្ហាញនៅក្នុងផ្នែកទី 3 រួមជាមួយនឹងការសន្និដ្ឋានដែលបានធ្វើតេស្តផលិតកម្ម និងការពិភាកនាអំពីការប្តូរយកគ្នារវាងភាពប្រកាន់ពេលវេលា ភាពជឿជាក់ និងគុណភាពម៉ូដែល។ ផ្នែកទី 4 សង្ខេបការងារទាក់ទងគ្នា និងប្រៀបធៀបពួកវាជាមួយ Monolith។ ផ្នែកទី 5 បញ្ចប់ការងារនេះ។ 2 ការរចនា ស្ថាបត្យកម្មទូទៅរបស់ Monolith ធ្វើតាមការកំណត់ Worker- arameter erver របស់ TensorFlow ក្នុងលក្ខណៈចែកចាយ (រូបភាព នៅក្នុងស្ថាបត្យកម្ម Worker-PS ម៉ាស៊ីនត្រូវបានចាត់តាំងតួនាទីផ្សេងៗ។ ម៉ាស៊ីន Worker ទទួលខុសត្រូវក្នុងការអនុវត្តការគណនាដូចដែលបានកំណត់ដោយក្រាហ្វ ហើយម៉ាស៊ីន PS រក្សាទុកប៉ារ៉ាម៉ែត្រ និងធ្វើបច្ចុប្បន្នភាពពួកវាដោយអនុលោមតាមកត្តាដែលបានគណនាដោយ Workers។ P S 2). នៅក្នុងម៉ូដែលណែនាំ ប៉ារ៉ាម៉ែត្រត្រូវបានបែងចែកជាពីរក្រុម៖ ដង់ និងមិនច្បាស់លាស់។ ប៉ារ៉ាម៉ែត្រដង់គឺជាទម្ងន់/អថេរនៅក្នុងបណ្តាញសរសៃប្រសាទជ្រៅ ហើយប៉ារ៉ាម៉ែត្រមិនច្បាស់លាស់សំដៅលើតារាងតួអក្សរដែលត្រូវនឹងលក្ខណៈពិសេសមិនច្បាស់លាស់។ នៅក្នុងការរចនារបស់យើង ប៉ារ៉ាម៉ែត្រទាំងដង់ និងមិនច្បាស់លាស់គឺជាផ្នែកមួយនៃ TensorFlow Graph ហើយត្រូវបានរក្សាទុកនៅលើម៉ាស៊ីនបម្រើប៉ារ៉ាម៉ែត្រ។ ស្រដៀងគ្នាទៅនឹង TensorFlow's Variable សម្រាប់ប៉ារ៉ាម៉ែត្រដង់ យើងបានរចនាកំណត់នៃប្រតិបត្តិការ HashTable ដែលមានប្រសិទ្ធភាពខ្ពស់ គ្មានការប៉ះទង្គិច និងមានភាពបត់បែនសម្រាប់ប៉ារ៉ាម៉ែត្រមិនច្បាស់លាស់។ ជាការបំពេញបន្ថែមទៅនឹងដែនកំណត់របស់ Tensor-Flow ដែលកើតចេញពីការបំបែកការបណ្តុះបណ្តាល និងការអនុវត្ត Monolith របស់ការបណ្តុះបណ្តាលតាមអ៊ីនធឺណិតដែលបត់បែនតាមមាត្រដ្ឋានត្រូវបានរចនាឡើងដើម្បីធ្វើសមកាលកម្មប៉ារ៉ាម៉ែត្រពី Training-PS ទៅ Online Serving-PS ក្នុងចន្លោះពេលខ្លីៗ ប្រកបដោយការធានាភាពរឹងមាំនៃម៉ូដែលដោយយន្តការភាពធន់នឹងកំហុស។ 2.1 តារាងតម្រៀប គោលការណ៍ទីមួយក្នុងការរចនាតំណាងប៉ារ៉ាម៉ែត្រមិនច្បាស់លាស់របស់យើងគឺដើម្បីជៀសវាងការច្របាច់បញ្ចូលគ្នានូវព័ត៌មានពីលេខសម្គាល់ផ្សេងៗទៅក្នុងតួអក្សរដែលមានទំហំថេរតែមួយ។ ការធ្វើត្រាប់តាមតារាងតួអក្សរដែលមានទំហំថាមវន្តដោយប្រើ TensorFlow Variable ដែលមានស្រាប់នឹងនាំឱ្យមានការប៉ះទង្គិចលេខសម្គាល់ដោយជៀសមិនរួច ដែលកាន់តែអាក្រក់ទៅៗនៅពេលដែលលេខសម្គាល់ថ្មីចូលមកហើយតារាងកើនឡើង។ ហេតុដូច្នេះហើយ ជំនួសឱ្យការកសាងលើ Variable យើងបានបង្កើត HashTable គន្លឹះ-តម្លៃថ្មីសម្រាប់ប៉ារ៉ាម៉ែត្រមិនច្បាស់លាស់របស់យើង។ HashTable របស់យើងប្រើ Cuckoo Hashmap [ ] នៅពីក្រោយឆាក ដែលគាំទ្រការបញ្ចូលគន្លឹះថ្មីដោយមិនប៉ះទង្គិចគ្នាជាមួយនឹងអ្វីដែលមានស្រាប់។ Cuckoo Hashing សម្រេចបានភាពស្មុគស្មាញនៃពេលវេលាអាក្រក់បំផុតគឺ 𝑂 (1) សម្រាប់ការស្វែងរកនិងការលុប ហើយការបញ្ចូលដែលបានរំពឹងទុកគឺ 𝑂 (1) សម្រាប់ការបញ្ចូល។ ដូចដែលបានបង្ហាញក្នុងរូបភាព វារក្សាតារាងពីរ 𝑇0, 𝑇1 ជាមួយនឹងមុខងារតម្រៀបផ្សេងគ្នា ℎ0 (𝑥), ℎ1 (𝑥) ហើយធាតុមួយនឹងត្រូវបានរក្សាទុកក្នុងមួយក្នុងចំណោមពួកវា។ នៅពេលព្យាយាមបញ្ចូលធាតុ 16 3 𝐴 ទៅ 𝑇0 វាចាប់ផ្ដើមដោយដាក់ 𝐴 នៅ ℎ0 (𝐴); ប្រសិនបើ ℎ0 (𝐴) ត្រូវបានកាន់កាប់ដោយធាតុមួយទៀត 𝐵 វានឹងដក 𝐵 ចេញពី 𝑇0 ហើយព្យាយាមបញ្ចូល 𝐵 ទៅ 𝑇1 ជាមួយនឹង logic ដូចគ្នា។ ដំណើរការនេះនឹងត្រូវបានធ្វើឡើងវិញរហូតដល់ធាតុទាំងអស់មានស្ថិរភាព ឬការតម្រៀបឡើងវិញកើតឡើងនៅពេលដែលការបញ្ចូលជួបប្រទះវដ្តមួយ។ ការកាត់បន្ថយទំហំអង្គចងចាំក៏ជាកត្តាសំខាន់ក្នុងការរចនារបស់យើងដែរ។ វិធីសាស្រ្តសាមញ្ញក្នុងការបញ្ចូលលេខសម្គាល់ថ្មីនីមួយៗទៅក្នុង HashTable នឹងអស់អង្គចងចាំយ៉ាងឆាប់រហ័ស។ ការសង្កេតម៉ូដែលផលិតកម្មពិតប្រាកដនាំឱ្យមានការសន្និដ្ឋានពីរយ៉ាង៖ (1) លេខសម្គាល់ដែលលេចឡើងតែម្តងគត់ពីរបីដងមានការរួមចំណែកតិចតួចក្នុងការកែលម្អគុណភាពម៉ូដែល។ ការសង្កេតដ៏សំខាន់មួយគឺថាលេខសម្គាល់ត្រូវបានចែកចាយតាមរាងកន្ទុយ ដែលលេខសម្គាល់ពេញនិយមអាចកើតឡើងរាប់លានដង ខណៈពេលដែលអ្នកដែលមិនពេញនិយមលេចឡើងមិនលើសពីដប់ដង។ តួអក្សរដែលត្រូវគ្នាទៅនឹងលេខសម្គាល់មិនពេញនិយមទាំងនេះគឺ underfit ដោយសារតែខ្វះទិន្នន័យបណ្តុះបណ្តាល ហើយម៉ូដែលនឹងមិនអាចធ្វើការប៉ាន់ស្មានបានល្អដោយផ្អែកលើពួកវាបានទេ។ នៅទីបញ្ចប់ លេខសម្គាល់ទាំងនេះទំនងជាមិនប៉ះពាល់ដល់លទ្ធផលទេ ដូច្នេះគុណភាពម៉ូដែលនឹងមិនរងផលប៉ះពាល់ពីការដកលេខសម្គាល់ដែលមានប្រេកង់ទាបនេះទេ។ (2) លេខសម្គាល់ចាស់ពីប្រវត្តិសាស្រ្តឆ្ងាយកម្ររួមចំណែកដល់ម៉ូដែលបច្ចុប្បន្ន ដោយសារតែពួកវាមួយចំនួនមិនដែលត្រូវបានទស្សនាទេ។ នេះអាចបណ្តាលមកពីអ្នកប្រើប្រាស់ដែលលែងសកម្ម ឬវីដេអូខ្លីដែលហួសសម័យ។ ការរក្សាទុកតួអក្សរសម្រាប់លេខសម្គាល់ទាំងនេះមិនអាចជួយម៉ូដែលតាមមធ្យោបាយណាមួយក្រៅពីការជួយបូមអង្គចងចាំ PS របស់យើងដោយឥតប្រយោជន៍ទេ។ ដោយផ្អែកលើការសង្កេតទាំងនេះ យើងបានរចនា heuristics ត្រង ID លក្ខណៈពិសេសជាច្រើនសម្រាប់ការអនុវត្ត HashTable ដែលមានប្រសិទ្ធភាពអង្គចងចាំជាងនេះ៖ (1) លេខសម្គាល់ត្រូវបានត្រងមុនពេលដែលពួកគេត្រូវបានអនុញ្ញាតឱ្យចូលទៅក្នុងតារាងតួអក្សរ។ យើងមានវិធីសាស្រ្តត្រងពីរយ៉ាង៖ ដំបូងយើងត្រងតាមការកើតឡើងរបស់ពួកគេមុនពេលដែលពួកគេត្រូវបានបញ្ចូលជាគន្លឹះ ដែលកម្រិតនៃការកើតឡើងគឺជា hyperparameter ដែលអាចកែតម្រូវបានដែលប្រែប្រួលសម្រាប់ម៉ូដែលនីមួយៗ។ លើសពីនេះ យើងប្រើប្រាស់តម្រង probabilistic ដែលជួយកាត់បន្ថយការប្រើប្រាស់អង្គចងចាំបន្ថែមទៀត។ ![#Figure 4: Streaming Engine. រង្វង់មតិកែលម្អព័ត៌មានពី [User → Model Server → Training Worker → Model Server → User] នឹងចំណាយពេលយូរនៅពេលធ្វើតាមផ្លូវ Batch Training ខណៈពេលដែល Online Training នឹងបិទរង្វង់បានភ្លាមៗ។](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) លេខសម្គាល់ត្រូវបានកំណត់ពេលវេលា និងកំណត់ឱ្យផុតកំណត់បន្ទាប់ពីមិនត្រូវបានប្រើប្រាស់ក្នុងរយៈពេលដែលបានកំណត់។ ពេលវេលាផុតកំណត់ក៏អាចកែតម្រូវបានសម្រាប់តារាងតួអក្សរនីមួយៗ ដើម្បីអនុញ្ញាតឱ្យបែងចែកលក្ខណៈពិសេសជាមួយនឹងភាពប្រកាន់ពេលវេលាខុសៗគ្នា។ នៅក្នុងការអនុវត្តរបស់យើង HashTable ត្រូវបានអនុវត្តជាប្រតិបត្តិការធនធាន TensorFlow ។ ស្រដៀងគ្នាទៅនឹង Variable ការស្វែងរក និងការអាប់ដេតក៏ត្រូវបានអនុវត្តជាប្រតិបត្តិការ TensorFlow ដើមសម្រាប់ការរួមបញ្ចូលកាន់តែងាយស្រួល និងភាពឆបគ្នាដែលប្រសើរជាងមុន។ 2.2 ការបណ្តុះបណ្តាលតាមអ៊ីនធឺណិត នៅក្នុង Monolith ការបណ្តុះបណ្តាលត្រូវបានបែងចែកជាពីរដំណាក់កាល (រូបភាព 1): (1) ដំណាក់កាលបណ្តុះបណ្តាលជាបាច់។ ដំណាក់កាលនេះដំណើរការដូចជារង្វង់បណ្តុះបណ្តាល TensorFlow ធម្មតា៖ ក្នុងជំហានបណ្តុះបណ្តាលនីមួយៗ ម៉ាស៊ីនបណ្តុះបណ្តាលអានបាច់តូចនៃឧទាហរណ៍បណ្តុះបណ្តាលពីឃ្លាំង ស្នើសុំប៉ារ៉ាម៉ែត្រពី PS គណនាការឆ្លងកាត់ទៅមុខ និងថយក្រោយ ហើយទីបំផុតរុញប៉ារ៉ាម៉ែត្រដែលបានធ្វើបច្ចុប្បន្នភាពទៅ training PS ។ ខុសពីការងាររៀនសូត្រជ្រៅទូទៅបន្តិច យើងបណ្តុះបណ្តាលសំណុំទិន្នន័យរបស់យើងតែមួយដងប៉ុណ្ណោះ។ ការបណ្តុះបណ្តាលជាបាច់មានប្រយោជន៍សម្រាប់ការបណ្តុះបណ្តាលទិន្នន័យប្រវត្តិសាស្ត្រ នៅពេលដែលយើងកែប្រែស្ថាបត្យកម្មម៉ូដែលរបស់យើង និងបណ្តុះបណ្តាលម៉ូដែលឡើងវិញ; (2) ដំណាក់កាលបណ្តុះបណ្តាលតាមអ៊ីនធឺណិត។ បន្ទាប់ពីម៉ូដែលត្រូវបានដាក់ឱ្យដំណើរការ ការបណ្តុះបណ្តាលមិនឈប់ទេប៉ុន្តែចូលទៅក្នុងដំណាក់កាលបណ្តុះបណ្តាលតាមអ៊ីនធឺណិត។ ជំនួសឱ្យការអានឧទាហរណ៍បាច់តូចពីឃ្លាំង ម៉ាស៊ីនបណ្តុះបណ្តាលប្រើប្រាស់ទិន្នន័យពេលវេលាជាក់ស្តែងភ្លាមៗ ហើយធ្វើបច្ចុប្បន្នភាព training PS ។ Training PS ធ្វើសមកាលកម្មប៉ារ៉ាម៉ែត្ររបស់ខ្លួនជាទៀងទាត់ទៅ serving PS ដែលនឹងមានប្រសិទ្ធភាពនៅលើផ្នែកអ្នកប្រើប្រាស់ភ្លាមៗ។ នេះអនុញ្ញាតឱ្យម៉ូដែលរបស់យើងមានអន្តរកម្ម និងសម្របខ្លួនតាមមតិកែលម្អរបស់អ្នកប្រើប្រាស់តាមពេលវេលាជាក់ស្តែង។ Monolith ត្រូវបានកសាងឡើងជាមួយនឹងសមត្ថភាពក្នុងការផ្លាស់ប្តូររវាងការបណ្តុះបណ្តាលជាបាច់ និងការបណ្តុះបណ្តាលតាមអ៊ីនធឺណិតដោយគ្មានការរំខាន។ នេះត្រូវបានបើកដោយការរចនាស្នូលស្ទ្រីមរបស់យើងដូចដែលបានបង្ហាញដោយរូបភាព 2.2.1 Streaming Engine. 4. នៅក្នុងការរចនារបស់យើង យើងប្រើជួរ Kafka [ ] មួយដើម្បីកត់ត្រាសកម្មភាពរបស់អ្នកប្រើប្រាស់ (ឧ. ចុចលើធាតុ ឬចូលចិត្តធាតុ ។ល។) និងជួរ Kafka មួយទៀតសម្រាប់លក្ខណៈពិសេស។ នៅស្នូលនៃម៉ាស៊ីនគឺជាការងារស្ទ្រីម Flink [ ] សម្រាប់ Online Feature Joiner ។ Online Joiner បញ្ចូលលក្ខណៈពិសេសជាមួយស្លាកពីសកម្មភាពអ្នកប្រើប្រាស់ និងបង្កើតឧទាហរណ៍បណ្តុះបណ្តាល ដែលបន្ទាប់មកត្រូវបានសរសេរទៅជួរ Kafka ។ ជួរសម្រាប់ឧទាហរណ៍បណ្តុះបណ្តាលត្រូវបានប្រើប្រាស់ដោយទាំងការបណ្តុះបណ្តាលតាមអ៊ីនធឺណិត និងការបណ្តុះបណ្តាលជាបាច់៖ 13 4 សម្រាប់ការបណ្តុះបណ្តាលតាមអ៊ីនធឺណិត ម៉ាស៊ីនបណ្តុះបណ្តាលអានទិន្នន័យដោយផ្ទាល់ពីជួរ Kafka ។ សម្រាប់ការបណ្តុះបណ្តាលជាបាច់ ការងារទម្លាក់ទិន្នន័យនឹងទម្លាក់ទិន្នន័យទៅ HDFS [ ] មុន។ បន្ទាប់ពីទិន្នន័យនៅក្នុង HDFS ប្រមូលផ្តុំក្នុងបរិមាណជាក់លាក់ ម៉ាស៊ីនបណ្តុះបណ្តាលនឹងទាញទិន្នន័យពី HDFS ហើយអនុវត្តការបណ្តុះបណ្តាលជាបាច់។ 18 ប៉ារ៉ាម៉ែត្រដែលបានធ្វើបច្ចុប្បន្នភាពនៅក្នុង training PS នឹងត្រូវបានរុញទៅ serving PS ដោយអនុលោមតាមកាលវិភាគធ្វើសមកាលកម្មប៉ារ៉ាម៉ែត្រ។ នៅក្នុងកម្មវិធីពិត សកម្មភាពអ្នកប្រើប្រាស់ និងលក្ខណៈពិសេសត្រូវបានបញ្ជូនទៅ Online Joiner (រូបភាព ដោយមិនមានការធានាលើលំដាប់ពេលវេលាទេ។ ហេតុដូច្នេះហើយ យើងប្រើគន្លឹះតែមួយគត់សម្រាប់សំណើនីមួយៗ ដើម្បីឱ្យសកម្មភាពអ្នកប្រើប្រាស់ និងលក្ខណៈពិសេសអាចផ្គូផ្គងគ្នាបានត្រឹមត្រូវ។ 2.2.2 Online Joiner. 5) ការពន្យាពេលនៃសកម្មភាពអ្នកប្រើប្រាស់ក៏អាចជាបញ្ហាផងដែរ។ ឧទាហរណ៍ អ្នកប្រើប្រាស់អាចចំណាយពេលពីរបីថ្ងៃមុនពេលដែលពួកគេសម្រេចចិត្តទិញធាតុដែលពួកគេបានបង្ហាញកាលពីប៉ុន្មានថ្ងៃមុន។ នេះជាបញ្ហាប្រឈមសម្រាប់ joiner ដោយសារតែប្រសិនបើលក្ខណៈពិសេសទាំងអស់ត្រូវបានរក្សាទុកនៅក្នុងឃ្លាំងសម្ងាត់ វានឹងមិនសមនឹងអង្គចងចាំទេ។ នៅក្នុងប្រព័ន្ធរបស់យើង ឃ្លាំងរក្សាទុកគន្លឹះ-តម្លៃនៅលើឌីសត្រូវបានប្រើដើម្បីរក្សាទុកលក្ខណៈពិសេសដែលកំពុងរង់ចាំរយៈពេលយូរជាង។ នៅពេលដែលកំណត់ហេតុសកម្មភាពអ្នកប្រើប្រាស់មកដល់ វាដំបូងស្វែងរកឃ្លាំងសម្ងាត់ក្នុងអង្គចងចាំ បន្ទាប់មកស្វែងរកឃ្លាំងរក្សាទុកគន្លឹះ-តម្លៃ ប្រសិនបើឃ្លាំងសម្ងាត់បាត់។ បញ្ហាមួយទៀតដែលកើតឡើងក្នុងកម្មវិធីពិតគឺថាការចែកចាយឧទាហរណ៍អវិជ្ជមាននិងវិជ្ជមានគឺមិនស្មើគ្នាខ្លាំងទេ ដោយចំនួនអតីតអាចមានច្រើនជាងក្រោយរាប់លានដង។ ដើម្បីការពារឧទាហរណ៍វិជ្ជមានពីការត្រូវបានគ្របដណ្ដប់ដោយអវិជ្ជមាន ការជ្រើសរើសអវិជ្ជមានគឺជាយុទ្ធសាស្ត្រទូទៅ។ នេះនឹងផ្លាស់ប្តូរការចែកចាយមូលដ្ឋាននៃម៉ូដែលដែលបានបណ្តុះបណ្តាលដោយប្រាកដណាស់ ដោយកែតម្រូវវាឆ្ពោះទៅរកប្រូបាប៊ីលីតេខ្ពស់នៃការធ្វើការទស្សន៍ទាយជាវិជ្ជមាន។ ជាវិធានការជួសជុល យើងអនុវត្តការកែតម្រូវលទ្ធផលអវិជ្ជមាន [ ] ក្នុងអំឡុងពេលបម្រើ ដោយធ្វើឱ្យប្រាកដថាម៉ូដែលតាមអ៊ីនធឺណិតគឺជាអ្នកប៉ាន់ស្មានដែលមិនលំអៀងនៃការចែកចាយដើម។ 19 ក្នុងអំឡុងពេលបណ្តុះបណ្តាលតាមអ៊ីនធឺណិត Monolith training cluster បន្តទទួលទិន្នន័យពី module បម្រើតាមអ៊ីនធឺណិត និងធ្វើបច្ចុប្បន្នភាពប៉ារ៉ាម៉ែត្រនៅលើ training PS ។ ជំហានសំខាន់ក្នុងការអនុញ្ញាតឱ្យ serving PS តាមអ៊ីនធឺណិតទទួលបានប្រយោជន៍ពីប៉ារ៉ាម៉ែត្រដែលបានបណ្តុះបណ្តាលថ្មីទាំងនេះគឺជាការធ្វើសមកាលកម្មប៉ារ៉ាម៉ែត្រដែលបានធ្វើបច្ចុប្បន្នភាព។ នៅក្នុងបរិស្ថានផលិតកម្ម យើងជួបប្រទះនឹងបញ្ហាជាច្រើន៖ 2.2.3 Parameter Synchronization. ម៉ូដែលនៅលើ serving PS តាមអ៊ីនធឺណិតត្រូវតែមិនឈប់បម្រើក្នុងពេលធ្វើបច្ចុប្បន្នភាព។ ម៉ូដែលរបស់យើងនៅក្នុងផលិតកម្មជាធម្មតាមានទំហំជា terabytes ជាច្រើន ហើយជាលទ្ធផល ការជំនួសប៉ារ៉ាម៉ែត្រទាំងអស់ចំណាយពេលមួយរយៈ។ វានឹងមិនអាចទទួលយកបានក្នុងការបញ្ឈប់ serving PS ពីការបម្រើម៉ូដែលក្នុងអំឡុងពេលដំណើរការជំនួស ហើយការអាប់ដេតត្រូវតែធ្វើឡើងភ្លាមៗ។ ការផ្ទេរម៉ូដែល terabyte ជាច្រើនទាំងមូលពី training PS ទៅ serving PS តាមអ៊ីនធឺណិតនឹងបង្កើតសម្ពាធយ៉ាងខ្លាំងដល់ទាំង bandwidth បណ្តាញ និងអង្គចងចាំនៅលើ PS ដោយសារតែវាទាមទារទំហំម៉ូដែលទ្វេដងដើម្បីទទួលម៉ូដែលដែលទើបមកដល់។ ដើម្បីឱ្យការបណ្តុះបណ្តាលតាមអ៊ីនធឺណិតអាចកើនឡើងដល់ទំហំនៃស្ថានភាពអាជីវកម្មរបស់យើង យើងបានរចនាយន្តការធ្វើសមកាលកម្មប៉ារ៉ាម៉ែត្រតាមអ៊ីនធឺណិតជាប្រចាំដោយផ្អែកលើ