ByteDance-ийн Monolith: Ухаалаг, хурдан контент дамжуулах хөдөлгүүр

Зохиогчид: Жуоран Лю, Bytedance Inc. Леки Зоу, Bytedance Inc. Сюань Зоу, Bytedance Inc. Цайхуа Ван, Bytedance Inc. Бяо Чжан, Bytedance Inc. Да Тан, Bytedance Inc. Болин Жу*, Фудангийн их сургууль Ижи Чжу, Bytedance Inc. Пенг Ву, Bytedance Inc. Ке Ван, Bytedance Inc. Яулонг Ченг†, Bytedance Inc. (youlong.cheng@bytedance.com) Хураангуй Бизнесийн цаг хугацаанд мэдрэмтгий харилцагчийн санал хүсэлтэд тулгуурласан, тухайлбал богино видео зэрэглэл эсвэл онлайн зар сурталчилгаа зэрэг бизнесийн хувьд бодит цаг хугацаанд ажиллах боломжтой, өргөн цар хүрээтэй зөвлөмжийн системийг бий болгох нь чухал ач холбогдолтой юм. TensorFlow эсвэл PyTorch зэрэг үйлдвэрлэлийн цар хүрээтэй гүнзгийрүүлсэн сургалтын фреймворкийг өргөнөөр ашиглаж байгаа хэдий ч, эдгээр ерөнхий зориулалтын фреймворкууд нь янз бүрийн шалтгааны улмаас зөвлөмжийн нөхцөл байдалд бизнесийн хэрэгцээг хангаж чадахгүй байна: нэг талаас, динамик ба сийрэг шинж чанаруудаар зөвлөмж хийхэд тогтмол параметр ба нягт тооцоолол бүхий системийг тохируулах нь загвар чанарт хортой юм; нөгөө талаас, ийм фреймворкууд нь багц сургалтын үе шат ба үйлчилгээний үе шатыг бүрэн тусад нь зохион бүтээсэн тул загварыг бодит цаг хугацаанд харилцагчийн санал хүсэлттэй харьцах боломжийг хязгаарладаг. Эдгээр асуудлууд нь биднийг уламжлалт аргуудыг дахин авч үзэхэд хүргэсэн бөгөөд үндсээр өөр өөр дизайны сонголтыг судлах хэрэгтэй болсон. Энэхүү өгүүлэлд бид онлайнаар сургах зориулалттай 1 системийг танилцуулж байна. Манай дизайныг бусад зөвлөмжийн системээс эрс ялгаатай байдлыг харуулсан, бидний програм хангамжийн ачаалал болон үйлдвэрлэлийн орчны ажиглалтаар удирдсан. Бидний хувь нэмэр нь олон талт: эхлээд бид expirable embedding болон frequency filtering зэрэг оновчлолуудтай collisionless embedding table-ийг бүтээж, түүний санах ойн хэмжээг багасгасан; хоёрдугаарт, бид өндөр fault-tolerance бүхий үйлдвэрлэлийн бэлэн байдалтай онлайн сургалтын архитектурыг бий болгосон; эцэст нь, бид системийн найдвартай байдлыг бодит цаг хугацааны сургалтын төлөө солилцож болохыг баталсан. Monolith нь BytePlus Recommend2 бүтээгдэхүүнд амжилттай нэвтэрсэн. Monolith 1 ТАНИЛЦУУЛГА Өнгөрсөн арван жилд зөвлөмжийн технологид суурилсан бизнесийн эрчимтэй хөгжил ажиглагдсан. Хэрэглэгчдэд илүү сайн туршлага өгөх зорилгоор, хувийн агуулгыг тус бүрчлэн бодит цаг хугацаанд хариу өгөх нь эдгээр бизнесийн програмуудын нийтлэг зорилго юм. Үүний тулд, хэрэглэгчийн хамгийн сүүлийн үеийн харилцан үйлчлэлийн мэдээлэл нь загварыг сургах үндсэн оролт болгон ашиглагддаг, учир нь энэ нь хэрэглэгчийн дүр төрхийг хамгийн сайн дүрслэн харуулж, хэрэглэгчийн сонирхол болон ирээдүйн зан үйлийг таамаглах боломжтой байдаг. Гүнзгийрүүлсэн сургалт нь зөвлөмжийн загваруудыг ноёрхож байгаа бөгөөд хэрэглэгчийн асар их хэмжээний өгөгдөл нь масс-медиа-хөтлөгддөг нейрон загварт тохиромжтой юм. Гэсэн хэдий ч, үйлдвэрлэлийн түвшний зөвлөмжийн системд гүнзгийрүүлсэн сургалтын хүчийг ашиглах оролдлогууд нь бодит ертөнцийн хэрэглэгчийн зан үйлд суурилсан өгөгдлийн өвөрмөц шинж чанараас үүдэлтэй асуудлуудтай тулгардаг. Эдгээр өгөгдлүүд нь хэлний загварчлал эсвэл компьютерийн зүйн зэрэг уламжлалт гүнзгийрүүлсэн сургалтын асуудлуудаас хоёр талаас нь үндсээр ялгаатай: (1) Шинж чанарууд нь ихэвчлэн сийрэг, ангилалттай, динамикаар өөрчлөгддөг; (2) Сургалтын өгөгдлийн үндсэн тархалт нь тогтворгүй, өөрөөр хэлбэл, Concept Drift юм. Ийм ялгаа нь зөвлөмжийн систем дээр ажилладаг судлаачид болон инженерүүдэд өвөрмөц сорилтуудыг бий болгосон. 1.1 Сийрэгшил ба динамик байдал Зөвлөмжийн өгөгдөл нь ихэвчлэн сийрэг ангилалттай шинж чанаруудыг агуулдаг, зарим нь бага давтамжтай гарч ирдэг. Тэдгээрийг өндөр хэмжээст embedding орон зайд гаргах нийтлэг практик нь хэд хэдэн асуудлыг үүсгэдэг: • Хэлний загваруудаас ялгаатай нь үгийн тоо хязгаарлагдмал байдаг бол хэрэглэгч ба зэрэглэлд орох зүйлсийн тоо нь хэд дахин их байдаг. Ийм асар их embedding хүснэгт нь нэг хостын санах ойд багтах боломжгүй юм; • Илүү муу нь, илүү олон хэрэглэгч болон зүйлсийг элсүүлэх тусам embedding хүснэгтийн хэмжээ цаг хугацаа өнгөрөх тусам өсөх төлөвтэй байдаг бол зэрэг фреймворкууд нь embedding хүснэгтийг төлөөлөхийн тулд тогтмол хэмжээтэй нягт хувьсагчийг ашигладаг. Практикт, олон систем нь санах ойн хэмжээг багасгах, ID-г өсгөх боломжийг олгох зорилгоор бага collision hashing ашигладаг. Энэ нь embedding хүснэгтэд байгаа ID-ууд нь давтамжаараа жигд тархсан, collision нь загвар чанарт хоргүй гэсэн хэтэрхий өрөөсгөл төсөөлөлд тулгуурладаг. Харамсалтай нь, энэ нь бодит ертөнцийн зөвлөмжийн системийн хувьд ховор тохиолддог, энд цөөн тооны хэрэглэгч эсвэл зүйлс нь илүү их давтамжтай байдаг. Embedding хүснэгтийн хэмжээний байгалийн өсөлттэй хамт, hash key collision-ийн боломж нэмэгдэж, загвар чанарын доройтол үүсгэдэг. Тиймээс үйлдвэрлэлийн цар хүрээтэй зөвлөмжийн системүүд нь өөрийн параметртэй аль болох олон шинж чанарыг авах чадвартай байх, мөн өөртөө хадгалж буй хэрэглэгчид ба зүйлсийн тоог уян хатан тохируулах чадвартай байх байгалийн шаардлагатай юм. 1.2 Тогтворгүй тархалт Харагдах болон хэлний загварууд нь мянган жилийн хугацаанд бараг хөгждөггүй байхад, нэг сэдвээр сонирхолтой байдаг хэрэглэгч хэдхэн минутын дараа өөрсдийн эрч хүчээ өөрчилж болно. Үүний үр дүнд, хэрэглэгчийн өгөгдлийн үндсэн тархалт нь тогтворгүй байдаг, энэ үзэгдэл нь ихэвчлэн Concept Drift гэж нэрлэгддэг. Интуитив байдлаар, илүү ойрын түүхэн дэх мэдээлэл нь хэрэглэгчийн зан үйлийн өөрчлөлтийг таамаглахад илүү үр дүнтэй хувь нэмэр оруулж болно. Concept Drift-ийн нөлөөллийг бууруулахын тулд, үйлчилгээний загварууд нь хэрэглэгчийн хамгийн сүүлийн үеийн сонирхлыг тусгахын тулд аль болох бодит цаг хугацаанд ойрхон байх шинэ хэрэглэгчийн санал хүсэлтээс шинэчлэгдэх шаардлагатай. Эдгээр ялгааг анхаарч, манай үйлдвэрлэлээс үүдэлтэй асуудлуудыг ажигласны үндсэн дээр, бид эдгээр бэрхшээлийг шийдвэрлэхийн тулд том хэмжээний зөвлөмжийн систем болох -ийг зохион бүтээсэн. Бид үйлдвэрлэлийн орчинд өөрсдийн дизайныг баталгаажуулах, дахин давтахын тулд өргөн хүрээний туршилтуудыг хийсэн. Monolith нь дараах зүйлийг хийж чадна: Monolith (1) Collisionless hash table болон динамик шинж чанарыг хасах механизмыг зохион бүтээснээр сийрэг шинж чанаруудад бүрэн илэрхийлэх чадварыг өгөх; (2) Онлайн сургалтаар бодит цаг хугацаанд үйлчилгээний санал хүсэлтийг сургалтанд буцаан оруулах. Эдгээр архитектурын чадавхуудыг ашиглан, Monolith нь collision-тай hash-trick ашигладаг системүүдээс ойролцоогоор ижил санах ойн хэрэглээтэй байсан ч тогтвортой байдлаар давуу талыг олж авсан бөгөөд манай серверүүдийн тооцоолох чадварт хэт их ачаалал өгөлгүйгээр шилдэг онлайн үйлчилгээний AUC-г олж авсан. Өгүүллийн үлдсэн хэсэг нь дараах байдлаар зохион байгуулагдсан. Бид эхлээд 2-р хэсэгт Monolith нь collisionless hash table болон realtime training-ээр одоогийн сорилтуудыг хэрхэн шийдвэрлэдэг тухай дизайны дэлгэрэнгүйг тайлбарласан. 3-р хэсэгт туршилт ба үр дүнг танилцуулсан бөгөөд үйлдвэрлэлийн туршилтаар батлагдсан дүгнэлт болон цаг хугацаанд мэдрэмтгий байдал, найдвартай байдал болон загвар чанарын хоорондох худалдаа хийх тухай зарим хэлэлцүүлгийг оруулсан. 4-р хэсэг нь холбогдох ажлуудыг тоймлон харуулж, Monolith-тай харьцуулсан. 5-р хэсэг нь энэхүү ажлыг дүгнэсэн. 2 ЗОХИОН БАЙГУУЛАЛТ Monolith-ийн ерөнхий архитектур нь TensorFlow-ийн хуваагдсан Ажилтан- араметр ервер тохиргоог (Зураг 2) ерөнхийдөө дагаж мөрддөг. Ажилтан-PS архитектурт, машинууд өөр өөр үүрэг гүйцэтгэдэг; Ажилтан машинууд нь графикийн дагуу тодорхойлогдсон тооцоог гүйцэтгэх үүрэгтэй, харин PS машинууд нь параметрийг хадгалж, Ажилтнуудаас тооцоолсон градиентуудын дагуу тэдгээрийг шинэчилдэг. П С Зөвлөмжийн загваруудад, параметрүүд нь хоёр багцад хуваагддаг: нягт ба сийрэг. Нягт параметрүүд нь гүнзгийрүүлсэн нейрон сүлжээний жин/хувьсагч байдаг, харин сийрэг параметрүүд нь сийрэг шинж чанарт харгалзах embedding хүснэгтийг хэлнэ. Манай дизайнд, нягт болон сийрэг параметрүүд нь TensorFlow Графикийн хэсэг бөгөөд параметр серверүүд дээр хадгалагддаг. Нягт параметрүүдийн TensorFlow хувьсагчтай адилаар, бид сийрэг параметруудын хувьд маш үр дүнтэй, collisionless, болон уян хатан HashTable үйлдлийг зохион бүтээсэн. Сургалт ба оношлогооны хоорондох ялгаатай байдлаас үүдэлтэй TensorFlow-ийн хязгаарлалтыг нөхөх зорилгоор, Monolith-ийн уян хатан байдлаар өргөжих боломжтой онлайн сургалт нь fault tolerance механизмээр баталгаажсан загвар найдвартай байдлыг хангаж, богино интервалтайгаар сургалтын-PS-ээс үйлчилгээний-PS-рүү параметрийг үр дүнтэй синхрончлох зорилготой. 2.1 Hash Table Сийрэг параметрүүдийг төлөөлөх манай дизайны анхны зарчим бол өөр өөр ID-уудын мэдээллийг нэг тогтмол хэмжээтэй embedding рүү бөөгнөрүүлэхээс зайлсхийх явдал юм. Гаднаас авсан TensorFlow хувьсагч ашиглан динамик хэмжээтэй embedding хүснэгтийг симуляци хийх нь зайлшгүй ID collision-д хүргэдэг, энэ нь шинэ ID-ууд ирэх болон хүснэгт өсөхөд улам хүндэрдэг. Тиймээс хувьсагчийг суурь болгохоос илүү, бид сийрэг параметруудын хувьд шинэ түлхүүр-утгатай HashTable-ийг боловсруулсан. Манай HashTable нь Cuckoo Hashmap -ийг ашигладаг бөгөөд энэ нь шинэ түлхүүрүүдийг одоо байгаа түлхүүрүүдтэй collision үүсгэхгүйгээр оруулах боломжийг олгодог. Cuckoo Hashing нь lookup болон delete-д хамгийн муу тохиолдолд 𝑂 (1) цаг хугацааны тодорхойлолтыг, харин insertion-д дундаж 𝑂 (1) цаг хугацааны тодорхойлолтыг олж авдаг. Зураг 3-т харуулсан шиг, энэ нь өөр өөр hash функцууд ℎ0 (𝑥), ℎ1 (𝑥) бүхий хоёр хүснэгтийг 𝑇0, 𝑇1 хадгалдаг бөгөөд элемент нь тэдгээрийн аль нэгэнд нь хадгалагдана. Элемент 𝐴-г 𝑇0 руу оруулахыг оролдох үед, энэ нь эхлээд 𝐴-г ℎ0 (𝐴) байрлуулахыг оролддог; Хэрэв ℎ0 (𝐴) нь өөр элемент 𝐵-ээр эзлэгдсэн бол, энэ нь 𝐵-г 𝑇0-оос хасаад мөн адил логикийг ашиглан 𝐵-г 𝑇1 руу оруулахыг оролддог. Энэ процесс нь бүх элементүүд тогтворжих эсвэл insertion нь мөчлөгт орох үед rehash хийгдэх хүртэл давтагдана. Санах ойн хэмжээг багасгах нь манай дизайнд бас чухал хүчин зүйл юм. Шинийг таньж авсан ID-г HashTable руу оруулах энгийн арга нь санах ойн хурдан шавхагдахад хүргэнэ. Бодит үйлдвэрлэлийн загваруудын ажиглалт нь хоёр дүгнэлтэд хүргэсэн: (1) Хэдхэн удаа гарч ирдэг ID-ууд нь загвар чанарыг сайжруулахад бага хувь нэмэр оруулдаг. Чухал ажиглалт нь ID-ууд нь урт сүүлтэй байдаг, энд алдартай ID-ууд нь сая сая удаа гарч ирдэг бол алдартай бус ID-ууд нь арав хүртэл удаа л гарч ирдэг. Эдгээр бага давтамжтай ID-уудад харгалзах Embeddings нь сургалтын өгөгдөл дутагдсанаас болон загвар нь тэдгээрт суурилсан сайн тооцоолол хийх чадваргүй байдгаас болон шалтгаалдаг. Эцсийн эцэст эдгээр ID-ууд нь үр дүнд нөлөөлөх магадлал багатай тул, энэ ID-уудын алдагдал нь загвар чанарт нөлөөлөхгүй; (2) Хол зайны түүхэн дэх хуучирсан ID-ууд нь тэдгээрийн ихэнх нь хэзээ ч зочилоогүй байдаг тул одоогийн загварт хувь нэмэр оруулах нь ховор байдаг. Энэ нь идэвхгүй болсон хэрэглэгч эсвэл хуучирсан богино видео зэрэг шалтгаанаас болж болно. Эдгээр ID-уудын embedding-г хадгалах нь манай PS санах ойг дэмий шавхахаас өөрөөр загварт ямар ч тус болохгүй. Эдгээр ажиглалтуудаас үндэслэн, бид HashTable-ийг илүү санах ойтой үр дүнтэй хэрэгжүүлэхийн тулд хэд хэдэн шинж чанарын ID шүүлтүүрийн heuristic-ийг зохион бүтээсэн: (1) ID-ууд нь embedding хүснэгт рүү элсүүлэхээс өмнө шүүгддэг. Бид хоёр шүүх аргыг хэрэглэдэг: Эхлээд бид тэдгээрийг түлхүүр болгон оруулахаас өмнө давтамжаар нь шүүдэг, энд давтамжийн босго нь загвар бүр дээр өөр өөр байдаг өөрчлөгдөх боломжтой гиперпараметр юм; Нэмж дурдахад бид санах ойн хэрэглээг цаашид бууруулахад тусалдаг магадлалт шүүлтүүрийг ашигладаг; ![#Зураг 4: Урсгал дамжуулах хөдөлгүүр. [Хэрэглэгч → Загвар Сервер → Сургалтын Ажилтан → Загвар Сервер → Хэрэглэгч] мэдээллийн санал хүсэлтийн мөчлөг нь Багц Сургалтын замыг туулахад их цаг зарцуулдаг бол Онлайн Сургалт нь мөчлөгийг илүү хурдан хаадаг.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID-ууд нь цаг хугацаагаар тэмдэглэгдэн, урьдчилан тодорхойлсон хугацааны турш идэвхгүй болсны дараа хугацаа нь дуусдаг. Хугацааны дуусгах цаг нь мөн тус бүр embedding хүснэгт дээр өөрчлөгдөх боломжтой бөгөөд түүхэн мэдээлэлд өөр өөр мэдрэмтгий байдалтай шинж чанаруудыг ялгах боломжийг олгодог. Бидний хэрэгжүүлэлтэнд, HashTable нь TensorFlow нөөцийн үйлдлэл болгон хийгдсэн. Хувьсагчтай адилаар, lookup болон update-үүд нь илүү хялбар нэгтгэл болон илүү сайн нийцтэй байдлыг хангахын тулд уугуул TensorFlow үйлдлэл болгон хийгдсэн. 2.2 Онлайн сургалт Monolith-д, сургалт нь хоёр үе шаттайгаар хуваагддаг (Зураг 1): (1) Багц сургалтын үе шат. Энэ үе шат нь ердийн TensorFlow сургалтын мөчлөг шиг ажилладаг: Сургалтын алхам бүрд, нэг сургалтын ажилтан нь хадгалалтаас нэг мини-багц сургалтын жишээг уншиж, PS-ээс параметрийг хүсэж, урд болон хойд дамжуулалтыг тооцоолж, эцэст нь шинэчлэгдсэн параметрийг сургалтын PS-рүү илгээнэ. Ихэнх гүнзгийрүүлсэн сургалтын ажлуудаас бага зэрэг ялгаатай нь, бид зөвхөн нэг удаагийн дамжуулалтаар манай өгөгдлийг сургадаг. Багц сургалт нь загвар архитектурыг өөрчилж, загварыг дахин сургах үед түүхэн өгөгдлийг сургахэд ашигтай; (2) Онлайн сургалтын үе шат. Загвар нь онлайн үйлчилгээнд байршуулсны дараа, сургалт зогсохгүй, онлайн сургалтын үе шат руу орно. Хадгалалтаас мини-багц жишээг уншихын оронд, нэг сургалтын ажилтан нь бодит цаг хугацааны өгөгдлийг онгоцонд хэрэглэж, сургалтын PS-ийг шинэчилдэг. Сургалтын PS нь хугацаатайгаар өөрийн параметрийг үйлчилгээний PS-рүү синхрончилдог бөгөөд энэ нь хэрэглэгчийн талд шууд нөлөөлнө. Энэ нь манай загварыг бодит цаг хугацаанд хэрэглэгчийн санал хүсэлтийн дагуу интерактив байдлаар зохицох боломжийг олгодог. Monolith нь багц сургалт болон онлайн сургалтын хооронд жигд шилжих чадвартай байхаар бүтээгдсэн. Энэ нь бидний урсгал дамжуулах хөдөлгүүрийн дизайн (Зураг 4-т үзүүлэв) -аар боломжтой болсон. 2.2.1 Урсгал дамжуулах хөдөлгүүр. Бидний дизайнд, бид хэрэглэгчдийн үйлдлийн (Жишээлбэл, зүйлийг дарж эсвэл дуртай зүйлээ таалагдсан гэх мэт) болон шинж чанаруудыг тэмдэглэх нэг Kafka queue-г ашигладаг. Хөдөлгүүрийн гол нь онлайн шинж чанар хамтад нь оруулах Flink урсгал дамжуулах ажил юм. Онлайн joiner нь шинж чанарыг хэрэглэгчийн үйлдлүүдийн шошготой нийлүүлж, сургалтын жишээг гаргадаг бөгөөд энэ нь дараа нь Kafka queue руу бичигддэг. Сургалтын жишээнүүдийн queue нь онлайн сургалт болон багц сургалт аль алинд нь хэрэглэгддэг: Онлайн сургалтын хувьд, сургалтын ажилтан нь Kafka queue-с шууд өгөгдлийг уншдаг; Багц сургалтын хувьд, өгөгдөл дамжуулах ажил нь эхлээд HDFS руу өгөгдлийг дамжуулдаг; HDFS-д тодорхой хэмжээний өгөгдөл хуримтлагдсаны дараа, сургалтын ажилтан нь HDFS-ээс өгөгдлийг авч, багц сургалтыг гүйцэтгэнэ. Сургалтын PS-ийн шинэчлэгдсэн параметрууд нь параметр синхрончлолын хуваарийн дагуу үйлчилгээний PS-рүү илгээгдэнэ. Бодит ертөнцийн програмуудад, хэрэглэгчийн үйлдлийн лог болон шинж чанарууд нь онлайн joiner (Зураг 5)-т цаг хугацааны дараалалгүйгээр дамжуулагддаг. Тиймээс бид хэрэглэгчийн үйлдэл болон шинж чанарыг зөв хослуулахын тулд өгөгдөл бүрт өвөрмөц түлхүүрийг ашигладаг. 2.2.2 Онлайн Joiner. Хэрэглэгчийн үйлдэл хоцрох нь бас нэг асуудал байж болно. Жишээлбэл, хэрэглэгч хэд хоногийн өмнө үзсэн зүйлийг худалдаж авахаар шийдэхээсээ өмнө хэд хоног зарцуулж болно. Энэ нь joiner-т хэцүү бөгөөд хэрэв бүх шинж чанар нь санах ойд хадгалагдвал, энэ нь санах ойд багтахгүй. Манай системд, он-диск түлхүүр-утга хадгалах нь тодорхой хугацаанаас илүү хүлээж буй шинж чанаруудыг хадгалахад ашиглагддаг. Хэрэглэгчийн үйлдэл лог ирэхэд, энэ нь эхлээд санах ой дахь кэшийг хайдаг, дараа нь кэш байхгүй тохиолдолд түлхүүр-утгын хадгалалтыг хайдаг. Бодит ертөнцийн програмуудад үүсэх өөр нэг асуудал бол сөрөг болон эерэг жишээнүүдийн тархалт нь маш их тэнцвэргүй байдаг, энд эхнийх нь сүүлийнхээс хэд дахин их байж болно. Эерэг жишээнүүдийг сөрөг жишээнүүдээс давамгайлахаас урьдчилан сэргийлэхийн тулд, нийтлэг стратеги бол сөрөг дээжийг авах явдал юм. Энэ нь мэдээжийн хэрэг сургагдсан загварын үндсэн тархалтыг өөрчилж, эерэг таамаглалын илүү өндөр магадлал руу чиглүүлнэ. Үүний тулд, бид үйлчилгээний үеэр log odds correction -ийг ашигладаг, ингэснээр онлайн загвар нь анхны тархалтын unbiased estimator байхыг баталгаажуулдаг. Онлайн сургалтын үеэр, Monolith сургалтын кластер нь онлайн үйлчилгээний модулээс өгөгдлийг тасралтгүй хүлээн авч, сургалтын PS дээр параметрүүдийг шинэчилдэг. Эдгээр шинээр сургагдсан параметруудаас онлайн үйлчилгээний PS-ийг ашиг тус авахуулахын тулд зайлшгүй шаардлагатай алхам бол шинэчлэгдсэн загвар параметруудын синхрончлол юм. Үйлдвэрлэлийн орчинд, бид хэд хэдэн сорилтуудтай тулгарсан: 2.2.3 Параметр Синхрончлол. Он