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∗، جامعة فودان Yijie Zhu، Bytedance Inc. Peng Wu، Bytedance Inc. Ke Wang، Bytedance Inc. Youlong Cheng†، Bytedance Inc. (youlong.cheng@bytedance.com) ملخص: يعد بناء نظام توصية قابل للتطوير وفي الوقت الفعلي أمرًا حيويًا للعديد من الشركات التي تعتمد على ردود فعل العملاء الحساسة للوقت، مثل ترتيب مقاطع الفيديو القصيرة أو الإعلانات عبر الإنترنت. على الرغم من الاعتماد الواسع النطاق لأطر التعلم العميق على مستوى الإنتاج مثل TensorFlow أو PyTorch، إلا أن هذه الأطر للأغراض العامة لا تلبي متطلبات الأعمال في سيناريوهات التوصية لأسباب مختلفة: من ناحية، يؤدي تعديل الأنظمة بناءً على معلمات ثابتة وحسابات كثيفة للتوصية بميزات ديناميكية ومتفرقة إلى الإضرار بجودة النموذج؛ من ناحية أخرى، تم تصميم هذه الأطر مع فصل تام لمرحلة التدريب المجمّع ومرحلة الخدمة، مما يمنع النموذج من التفاعل مع ردود فعل العملاء في الوقت الفعلي. دفعتنا هذه المشكلات إلى إعادة فحص الأساليب التقليدية واستكشاف خيارات تصميم مختلفة جذريًا. في هذه الورقة، نقدم 1، وهو نظام مصمم خصيصًا للتدريب عبر الإنترنت. تم توجيه تصميمنا من خلال ملاحظات لأعباء عمل التطبيقات وبيئة الإنتاج لدينا، والتي تعكس ابتعادًا ملحوظًا عن أنظمة التوصية الأخرى. تساهم مساهماتنا متعددة: أولاً، قمنا بصياغة جدول تضمين خالٍ من التصادم مع تحسينات مثل تضمينات قابلة للانتهاء والتصفية المتكررة لتقليل بصمة الذاكرة الخاصة به؛ ثانيًا، نوفر بنية تدريب عبر الإنترنت جاهزة للإنتاج مع تحمل عالي للأخطاء؛ أخيرًا، أثبتنا أنه يمكن الموازنة بين موثوقية النظام والتعلم في الوقت الفعلي. تم تطبيق Monolith بنجاح في منتج BytePlus Recommend2. Monolith 1 مقدمة شهد العقد الماضي ازدهارًا في الأعمال التجارية التي تعتمد على تقنيات التوصية. سعيًا لتحسين تجربة العملاء، يعد تقديم محتوى مخصص لكل مستخدم على حدة كاستجابة في الوقت الفعلي هدفًا شائعًا لهذه التطبيقات التجارية. لتحقيق ذلك، غالبًا ما تُستخدم معلومات من أحدث تفاعل للمستخدم كمدخل أساسي لتدريب نموذج، حيث أنها تصور صورة المستخدم بشكل أفضل وتتنبأ باهتمامات المستخدم وسلوكياته المستقبلية. يهيمن التعلم العميق على نماذج التوصية [ ، ، ، ، ، ] نظرًا لأن الكم الهائل من بيانات المستخدم مناسب تمامًا للنماذج العصبية المعتمدة على البيانات على نطاق واسع. ومع ذلك، فإن الجهود المبذولة للاستفادة من قوة التعلم العميق في أنظمة التوصية على مستوى الصناعة تواجه باستمرار مشاكل تنشأ من الخصائص الفريدة للبيانات المشتقة من سلوك المستخدم في العالم الحقيقي. تختلف هذه البيانات اختلافًا كبيرًا عن تلك المستخدمة في مشاكل التعلم العميق التقليدية مثل نمذجة اللغة أو رؤية الكمبيوتر من جانبين: 5 6 10 12 20 21 (1) الميزات معظمها متفرقة، فئوية، ومتغيرة ديناميكيًا؛ (2) التوزيع الأساسي لبيانات التدريب غير ثابت، أي انحراف المفهوم [8]. لقد طرحت هذه الاختلافات تحديات فريدة للباحثين والمهندسين العاملين في أنظمة التوصية. 1.1 التشتت والديناميكية تحتوي بيانات التوصية في الغالب على ميزات فئوية متفرقة، يظهر بعضها بتردد منخفض. يؤدي الممارسة الشائعة لتعيينها إلى مساحة تضمين عالية الأبعاد إلى سلسلة من المشكلات: • على عكس نماذج اللغة حيث يكون عدد قطع الكلمات محدودًا، فإن عدد المستخدمين وعناصر التصنيف أكبر بعدة مرات. يصعب أن تتسع طاولة التضمين الضخمة هذه في ذاكرة مضيف واحد؛ • والأسوأ من ذلك، من المتوقع أن ينمو حجم جدول التضمين بمرور الوقت مع انضمام المزيد من المستخدمين والعناصر، بينما تستخدم أطر العمل مثل [ ، ] متغيرات كثيفة ثابتة الحجم لتمثيل جدول التضمين. 1 17 في الممارسة العملية، تتبنى العديد من الأنظمة التجزئة منخفضة التصادم [ ، ] كوسيلة لتقليل بصمة الذاكرة والسماح بنمو المعرفات. يعتمد هذا على افتراض مثالي للغاية بأن المعرفات في جدول التضمين موزعة بالتساوي في التردد، وأن التصادمات لا تضر بجودة النموذج. للأسف، نادرًا ما يكون هذا صحيحًا لنظام توصية في العالم الحقيقي، حيث يكون عدد قليل من المستخدمين أو العناصر لديهم عدد مرات ظهور أكبر بكثير. مع النمو العضوي لحجم جدول التضمين، تزداد فرص تصادم مفتاح التجزئة وتؤدي إلى تدهور جودة النموذج 3 6 [3]. لذلك، هناك طلب طبيعي لأنظمة التوصية على نطاق الإنتاج لتكون قادرة على التقاط أكبر عدد ممكن من الميزات في معالمها، وكذلك القدرة على تعديل عدد المستخدمين والعناصر التي تحاول الاحتفاظ بها بمرونة. 1.2 توزيع غير ثابت نادرًا ما تتطور الأنماط البصرية واللغوية على مدى قرون، بينما قد يتحول المستخدم المهتم بموضوع واحد إلى شغفه في الدقيقة التالية. نتيجة لذلك، فإن التوزيع الأساسي لبيانات المستخدم غير ثابت، وهي ظاهرة يشار إليها عادة باسم انحراف المفهوم [8]. من الناحية البديهية، يمكن للمعلومات من تاريخ أحدث أن تساهم بشكل فعال في التنبؤ بتغيير سلوك المستخدم. للتخفيف من تأثير انحراف المفهوم، تحتاج نماذج الخدمة إلى تحديثها من ردود فعل المستخدم الجديدة في أقرب وقت ممكن من الوقت الفعلي لتعكس أحدث اهتمام للمستخدم. في ضوء هذه الاختلافات وملاحظة المشكلات التي تنشأ من إنتاجنا، قمنا بتصميم ، وهو نظام توصية واسع النطاق لمعالجة نقاط الضعف هذه. أجرينا تجارب مكثفة للتحقق من تصميمنا وتكراره في بيئة الإنتاج. Monolith قادر على: Monolith (1) توفير قوة تعبيرية كاملة للميزات المتفرقة من خلال تصميم جدول تجزئة خالٍ من التصادم وآلية إخراج ميزات ديناميكية؛ (2) إرجاع حلقة خدمة ردود الفعل إلى التدريب في الوقت الفعلي مع التدريب عبر الإنترنت. بفضل هذه القدرات المعمارية، يتفوق Monolith باستمرار على الأنظمة التي تتبنى تقنيات التجزئة مع التصادمات باستخدام ذاكرة متشابهة تقريبًا، ويحقق أحدث تصنيف AUC للخدمة عبر الإنترنت دون إثقال كاهل قوة الحوسبة الخاصة بخوادمنا. تم تنظيم بقية الورقة على النحو التالي. نوضح أولاً تفاصيل التصميم لكيفية معالجة Monolith للتحديات الحالية باستخدام جدول تجزئة خالٍ من التصادم والتدريب في الوقت الفعلي في القسم 2. سيتم عرض التجارب والنتائج في القسم 3، جنبًا إلى جنب مع الاستنتاجات المختبرة في الإنتاج وبعض المناقشات حول المقايضات بين الحساسية للوقت والموثوقية وجودة النموذج. يلخص القسم 4 الأعمال ذات الصلة ويقارنها بـ Monolith. يختتم القسم 5 هذا العمل. 2 التصميم يتبع الهيكل العام لـ Monolith بشكل عام إعداد خادم المعلمات العامل الموزع الخاص بـ TensorFlow (الشكل في بنية عامل-خادم المعلمات، يتم تعيين أدوار مختلفة للأجهزة؛ تكون أجهزة العامل مسؤولة عن إجراء الحسابات كما هو محدد في الرسم البياني، وتخزن أجهزة خادم المعلمات المعلمات وتحدثها وفقًا للتدرجات التي يحسبها العاملون. 2). في نماذج التوصية، يتم تصنيف المعلمات إلى مجموعتين: كثيفة ومتفرقة. المعلمات الكثيفة هي الأوزان/المتغيرات في شبكة عصبية عميقة، وتشير المعلمات المتفرقة إلى جداول التضمين التي تتوافق مع الميزات المتفرقة. في تصميمنا، كل من المعلمات الكثيفة والمتفرقة جزء من رسم TensorFlow البياني، ويتم تخزينها على خوادم المعلمات. على غرار متغير TensorFlow للمعلمات الكثيفة، قمنا بتصميم مجموعة من عمليات جدول التجزئة عالية الكفاءة والخالية من التصادم والمرنة للمعلمات المتفرقة. كمكمل لقيود TensorFlow التي تنشأ من فصل التدريب والاستدلال، تم تصميم التدريب عبر الإنترنت قابل للتطوير بمرونة لـ Monolith لمزامنة المعلمات بكفاءة من التدريب-PS إلى الخدمة-PS في فترات زمنية قصيرة، مع ضمان متانة النموذج من خلال آلية تحمل الأخطاء. 2.1 جدول التجزئة المبدأ الأول في تصميمنا لتمثيل المعلمات المتفرقة هو تجنب تكديس المعلومات من المعرفات المختلفة في نفس التضمين الثابت الحجم. محاكاة جدول تضمين ديناميكي الحجم باستخدام متغير TensorFlow جاهز للاستخدام سيؤدي حتمًا إلى تصادم معرفات، والذي يتفاقم مع وصول معرفات جديدة ونمو الجدول. لذلك، بدلاً من البناء على المتغير، قمنا بتطوير جدول تجزئة جديد للمفتاح والقيمة لمعلماتنا المتفرقة. يستخدم جدول التجزئة الخاص بنا Cuckoo Hashmap [ ] في الخلفية، والذي يدعم إدراج مفاتيح جديدة دون الاصطدام مع المفاتيح الموجودة. يحقق Cuckoo Hashing تعقيدًا زمنيًا أسوأ في الحالة 𝑂 (1) لعمليات البحث والحذف، وتعقيدًا زمنيًا متوقعًا مستهلكًا 𝑂 (1) لعمليات الإدراج. كما هو موضح في الشكل ، فإنه يحتفظ بجدولين 𝑇0، 𝑇1 مع دالتين تجزئة مختلفتين ℎ0 (𝑥)، ℎ1 (𝑥)، وسيتم تخزين العنصر في أحدهما. عند محاولة إدراج عنصر 16 3 𝐴 في 𝑇0، فإنه يحاول أولاً وضع 𝐴 في ℎ0 (𝐴)؛ إذا كان ℎ0 (𝐴) مشغولاً بعنصر آخر 𝐵، فإنه سيخرج 𝐵 من 𝑇0 ويحاول إدراج 𝐵 في 𝑇1 بنفس المنطق. ستتكرر هذه العملية حتى تستقر جميع العناصر، أو يحدث إعادة تجزئة عند وصول الإدراج إلى دورة. يعد تقليل بصمة الذاكرة أيضًا اعتبارًا مهمًا في تصميمنا. قد يؤدي نهج بسيط لإدراج كل معرف جديد في جدول التجزئة إلى استنفاد الذاكرة بسرعة. أدت ملاحظات نماذج الإنتاج الحقيقية إلى استنتاجين: (1) المعرفات التي تظهر بضع مرات فقط لها مساهمة محدودة في تحسين جودة النموذج. ملاحظة مهمة هي أن المعرفات موزعة على شكل ذيل طويل، حيث قد تظهر المعرفات الشائعة ملايين المرات بينما يظهر غير الشائعين عشر مرات على الأكثر. التضمينات المقابلة لهذه المعرفات غير المتكررة تعاني من نقص التدريب بسبب نقص بيانات التدريب ولن يتمكن النموذج من إجراء تقدير جيد بناءً عليها. في نهاية المطاف، من غير المرجح أن تؤثر هذه المعرفات على النتيجة، لذلك لن تتأثر جودة النموذج بإزالة هذه المعرفات ذات الحالات المنخفضة؛ (2) المعرفات القديمة من تاريخ بعيد تساهم نادرًا في النموذج الحالي حيث أن العديد منها لم يتم زيارته أبدًا. قد يكون هذا بسبب مستخدم لم يعد نشطًا، أو مقطع فيديو قصير لم يعد محدثًا. تخزين التضمينات لهذه المعرفات لا يمكن أن يساعد النموذج بأي شكل من الأشكال سوى استنزاف ذاكرة خادم المعلمات لدينا دون جدوى. بناءً على هذه الملاحظات، قمنا بتصميم عدة استراتيجيات لتصفية معرفات الميزات لتنفيذ أكثر كفاءة في الذاكرة لجدول التجزئة: (1) يتم تصفية المعرفات قبل قبولها في جداول التضمين. لدينا طريقتان للتصفية: أولاً، نقوم بالتصفية حسب تكرارها قبل إدراجها كمفاتيح، حيث يكون عتبة التكرار معلمة فائقة قابلة للضبط تختلف لكل نموذج؛ بالإضافة إلى ذلك، نستخدم مرشحًا احتماليًا يساعد على تقليل استخدام الذاكرة بشكل أكبر؛ ![#Figure 4: Streaming Engine. حلقة التغذية الراجعة للمعلومات من [المستخدم → خادم النموذج → عامل التدريب → خادم النموذج → المستخدم] تستغرق وقتًا طويلاً عند اتباع مسار التدريب المجمع، بينما تقوم دورة التدريب عبر الإنترنت بإغلاق الحلقة على الفور.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) يتم تحديد وقت المعرفات وتعيينها لتنتهي صلاحيتها بعد فترة عدم نشاط محددة. وقت انتهاء الصلاحية قابل للضبط أيضًا لكل جدول تضمين للسماح بالتمييز بين الميزات ذات الحساسية المختلفة للمعلومات التاريخية. في تنفيذنا، يتم تنفيذ جدول التجزئة كعملية مورد TensorFlow. على غرار المتغير، يتم تنفيذ عمليات البحث والتحديث أيضًا كعمليات TensorFlow أصلية لسهولة التكامل والتوافق الأفضل. 2.2 التدريب عبر الإنترنت في Monolith، ينقسم التدريب إلى مرحلتين (الشكل 1): (1) مرحلة التدريب المجمّع. تعمل هذه المرحلة كحلقة تدريب TensorFlow عادية: في كل خطوة تدريب، يقرأ عامل التدريب دفعة مصغرة من أمثلة التدريب من المخزن، ويطلب المعلمات من PS، ويحسب تمريرة أمامية وخلفية، وأخيرًا يرسل المعلمات المحدثة إلى PS التدريب. يختلف قليلاً عن مهام التعلم العميق الشائعة الأخرى، حيث نقوم بتدريب مجموعة البيانات الخاصة بنا مرة واحدة فقط. التدريب المجمّع مفيد لتدريب البيانات التاريخية عندما نقوم بتعديل بنية النموذج الخاصة بنا وإعادة تدريب النموذج؛ (2) مرحلة التدريب عبر الإنترنت. بعد نشر النموذج للخدمة عبر الإنترنت، لا يتوقف التدريب بل يدخل مرحلة التدريب عبر الإنترنت. بدلاً من قراءة أمثلة الدفعات المصغرة من المخزن، يستهلك عامل التدريب بيانات في الوقت الفعلي أثناء التنقل ويحدث PS التدريب. يقوم PS التدريب بشكل دوري بمزامنة معلماته مع PS الخدمة، والتي ستدخل حيز التنفيذ على جانب المستخدم على الفور. هذا يتيح لنموذجنا التكيف التفاعلي وفقًا لردود فعل المستخدم في الوقت الفعلي. تم بناء Monolith بقدرة التبديل السلس بين التدريب المجمّع والتدريب عبر الإنترنت. يتم تمكين ذلك من خلال تصميمنا لمحرك التدفق كما هو موضح في الشكل 2.2.1 محرك التدفق. 4. في تصميمنا، نستخدم قائمة انتظار Kafka واحدة [ ] لتسجيل إجراءات المستخدمين (مثل النقر على عنصر أو الإعجاب بعنصر وما إلى ذلك) وقائمة انتظار Kafka أخرى للميزات. في قلب المحرك، توجد وظيفة تدفق Flink [ ] لربط الميزات عبر الإنترنت. يربط الـ joiner عبر الإنترنت الميزات بتسميات إجراءات المستخدم وينتج أمثلة تدريب، والتي يتم بعد ذلك كتابتها إلى قائمة انتظار Kafka. يتم استهلاك قائمة انتظار أمثلة التدريب من قبل كل من التدريب عبر الإنترنت والتدريب المجمّع: 13 4 للتدريب عبر الإنترنت، يقرأ عامل التدريب البيانات مباشرة من قائمة انتظار Kafka؛ للتدريب المجمّع، ستقوم وظيفة تفريغ البيانات أولاً بتفريغ البيانات إلى HDFS [ ]؛ بعد تراكم البيانات في HDFS بكمية معينة، سيسترجع عامل التدريب البيانات من HDFS ويجري تدريبًا مجمّعًا. 18 سيتم إرسال المعلمات المحدثة في PS التدريب إلى PS الخدمة وفقًا لجدول مزامنة المعلمات. في التطبيقات الواقعية، يتم بث سجل إجراءات المستخدم والميزات إلى الـ joiner عبر الإنترنت (الشكل دون ضمان ترتيب الوقت. لذلك نستخدم مفتاحًا فريدًا لكل طلب بحيث يمكن ربط إجراء المستخدم والميزات بشكل صحيح. 2.2.2 Online Joiner. 5) قد يكون تأخير إجراء المستخدم مشكلة أيضًا. على سبيل المثال، قد يستغرق المستخدم بضعة أيام قبل أن يقرر شراء عنصر تم عرضه عليه قبل أيام. هذا يمثل تحديًا للـ joiner لأنه إذا تم الاحتفاظ بجميع الميزات في الذاكرة المؤقتة، فلن تتناسب مع الذاكرة. في نظامنا، يتم استخدام مخزن مفتاح-قيمة على القرص لتخزين الميزات التي تنتظر لفترة زمنية معينة. عندما يصل سجل إجراء المستخدم، يبحث أولاً في الذاكرة المؤقتة في الذاكرة، ثم يبحث في مخزن المفتاح-القيمة في حالة عدم وجود ذاكرة مؤقتة. مشكلة أخرى تنشأ في التطبيقات الواقعية هي أن توزيع الأمثلة السالبة والموجبة غير متوازن للغاية، حيث يمكن أن يكون عدد الأول أكبر بعدة مرات من عدد الأخير. لمنع الأمثلة الإيجابية من أن تطغى عليها الأمثلة السلبية، فإن الاستراتيجية الشائعة هي أخذ عينات سلبية. سيغير هذا بالتأكيد التوزيع الأساسي للنموذج المدرب، مما يجعله يميل نحو احتمال أكبر لتوليد توقعات إيجابية. كعلاج، نطبق تصحيح اللوغاريتم للنسبة المئوية [ ] أثناء الخدمة، مما يضمن أن النموذج عبر الإنترنت هو مقدر غير متحيز للتوزيع الأصلي. 19 أثناء التدريب عبر الإنترنت، تستمر مجموعة تدريب Monolith في تلقي البيانات من وحدة الخدمة عبر الإنترنت وتحديث المعلمات على PS التدريب. تعد الخطوة الحاسمة لتمكين PS الخدمة عبر الإنترنت من الاستفادة من هذه المعلمات المدربة حديثًا هي مزامنة معلمات النموذج المحدثة. في بيئة الإنتاج، نواجه العديد من التحديات: 2.2.3 مزامنة المعلمات. يجب ألا تتوقف النماذج الموجودة على PS الخدمة عبر الإنترنت عن الخدمة عند التحديث. نماذجنا في الإنتاج كبيرة عادةً عدة تيرابايت، ونتيجة لذلك يستغرق استبدال جميع المعلمات بعض الوقت. سيكون من غير المقبول إيقاف PS عبر الإنترنت عن خدمة النموذج أثناء عملية الاستبدال، ويجب إجراء التحديثات أثناء التنقل؛ نقل نموذج بحجم عدة تيرابايت بأكمله من PS التدريب إلى PS الخدمة عبر الإنترنت سيشكل ضغطًا هائلاً على كل من عرض النطاق الترددي للشبكة والذاكرة على PS، حيث يتطلب ذاكرة مزدوجة الحجم لاستيعاب النموذج القادم الجديد. لجعل التدريب عبر الإنترنت قابلاً للتوسع ليناسب حجم سيناريو أعمالنا، قمنا بتصميم آلية مزامنة معلمات دورية متزايدة أثناء التنقل في Monolith بناءً على عدة خصائص ملحوظة لنماذجنا: (1) تهيمن المعلمات المتفرقة على حجم نماذج التوصية؛ (2) بالنظر إلى فترة زمنية قصيرة، يتم تدريب مجموعة فرعية صغيرة فقط من المعرفات وتحديث تضميناتها؛ (3) تتحرك المتغيرات الكثيفة ببطء أكبر من التضمينات المتفرقة. هذا بسبب أن تراكم الزخم لمعلمات الكثيفة يتم تضخيمه بسبب الحجم الهائل لبيانات تدريب التوصية في محسنات قائمة على الزخم، بينما تتلقى عدد قليل من التضمينات المتفرقة فقط تحديثات في دفعة بيانات واحدة. (1) و (2) يسمحان لنا باستغلال التحديثات المتفرقة عبر جميع معرفات الميزات. في Monolith، نحتفظ بمجموعة تجزئة من المفاتيح التي تم لمسها، والتي تمثل المعرفات التي تم تدريب تضميناتها منذ آخر مزامنة للمعلمات. نرسل مجموعة فرعية من المعلمات المتفرقة التي تكون مفاتيحها في مجموعة المفاتيح التي تم لمسها بفاصل زمني دقيقة من PS التدريب إلى PS الخدمة. هذه الحزمة الصغيرة نسبيًا من تحديث المعلمات المتزايدة خفيفة الوزن لنقل الشبكة ولن تسبب زيادة حادة في الذاكرة أثناء المزامنة. نحن نستغل أيضًا (3) لزيادة تقليل إدخال/إخراج الشبكة واستخدام الذاكرة عن طريق تعيين جدول مزامنة أكثر عدوانية للمعلمات المتفرقة، مع تحديث المعلمات الكثيفة بشكل أقل تكرارًا. يمكن أن يؤدي هذا بنا إلى وضع تكون فيه المعلمات الكثيفة التي نخدمها نسخة قديمة نسبيًا مقارنة بالجزء المتفرق. ومع ذلك، يمكن تحمل هذا التناقض بسبب السبب المذكور في (3) حيث لم يتم ملاحظة أي خسارة واضحة. 2.3 تحمل الأخطاء كنظام قيد الإنتاج، تم تصميم Monolith بقدرة على استعادة PS في حالة فشلها. الخيار الشائع لتحمل الأخطاء هو أخذ لقطة لحالة النموذج بشكل دوري، واستعادة من أحدث لقطة عند اكتشاف فشل PS. للتردد لقطة حالتين رئيسيتين: (1) جودة النموذج. من البديهي، تتأثر جودة النموذج بشكل أقل بفقدان التاريخ الأخير مع زيادة تردد اللقطة. (2) حمل الحوسبة. لا يأتي أخذ لقطة لنموذج بحجم تيرابايتات متعددة مجانًا. إنه يتكبد أجزاء كبيرة من نسخ الذاكرة وإدخال/إخراج القرص. كمقايضة بين جودة النموذج وحمل الحوسبة، يأخذ Monolith لقطة لجميع PS التدريب كل يوم. على الرغم من أن PS سيفقد يومًا واحدًا من التحديثات في حالة الفشل، فقد اكتشفنا أن تدهور الأداء يمكن تحمله من خلال تجاربنا. 3 التقييم للحصول على فهم أفضل للفوائد والمقايضات التي يوفرها تصميمنا المقترح، أجرينا العديد من التجارب على نطاق الإنتاج واختبارات A/B مع حركة مرور الخدمة الحية لتقييم والتحقق من Monolith من جوانب مختلفة. نهدف إلى الإجابة على الأسئلة التالية من خلال تجاربنا: (1) ما مدى استفادتنا من جدول تجزئة خالٍ من التصادم؟ (2) ما مدى أهمية التدريب عبر الإنترنت في الوقت الفعلي؟ (3) هل تصميم Monolith لمزامنة المعلمات قوي بما يكفي في سيناريو إنتاج واسع النطاق؟ في هذا القسم، نقدم أولاً إعداداتنا التجريبية ثم نناقش النتائج واستنتاجاتنا بالتفصيل. 3.1 إعداد التجربة كما هو موضح في القسم يتم تنفيذ جداول التضمين في Monolith كجداول تجزئة خالية من التصادم. لإثبات ضرورة تجنب التصادمات في جداول التضمين وقياس المكاسب من تطبيقنا الخالي من التصادم، أجرينا مجموعتين من التجارب على مجموعة بيانات Movielens وعلى مجموعة بيانات الإنتاج الداخلية الخاصة بنا على التوالي: 3.1.1 جدول التضمين. 2.1، (1) مجموعة بيانات ml-25m [ ]. هذه مجموعة بيانات عامة قياسية لتقييمات الأفلام، تحتوي على 25 مليون تقييم تشمل حوالي 162000 مستخدم و 62000 فيلم. MovieLens 11 • . التسميات الأصلية هي تقييمات من المعالجة المسبقة للتسميات 0.5 إلى 5.0، بينما في الإنتاج، فإن مهامنا هي في الغالب تلقي إشارات ثنائية من المستخدمين. لمحاكاة نماذج الإنتاج لدينا بشكل أفضل، نقوم بتحويل التسميات القياسية إلى تسميات ثنائية بمعاملة الدرجات ≥ 3.5 كعينات موجبة والباقي كعينات سالبة. • النموذج والمقاييس. قمنا بتنفيذ نموذج DeepFM القياسي [ ]، وهو نموذج معماري شائع الاستخدام لمشاكل التوصية. يتكون من مكون FM ومكون كثيف (الشكل 6). يتم تقييم التنبؤات بواسطة AUC [2] نظرًا لأنه القياس الرئيسي للنماذج الحقيقية. • تصادمات التضمين. تحتوي مجموعة البيانات هذه على ما يقرب من 160 ألف معرف مستخدم و 60 ألف معرف فيلم. للمقارنة مع الإصدار الخالي من التصادم من تنفيذ جدول التضمين، أجرينا مجموعة أخرى من التجارب حيث تم معالجة المعرفات مسبقًا باستخدام تجزئة MD5 ثم تعيينها إلى مساحة معرفات أصغر. نتيجة لذلك، سيشارك بعض المعرفات تضمينها مع الآخرين. يوضح الجدول 1 الإحصائيات التفصيلية لمعرفات المستخدم والأفلام قبل وبعد التجزئة. 9 (2) . مجموعة بيانات التوصية الداخلية أجرينا أيضًا تجارب على نموذج توصية في بيئة الإنتاج. يتبع هذا النموذج بشكل عام بنية متعددة الأبراج، حيث يكون كل برج مسؤولاً عن التعلم للتنبؤ بنوع متخصص من سلوك المستخدم. كل نموذج لديه حوالي 1000 جدول تضمين، وتوزيع حجم جداول التضمين غير متساوٍ جدًا؛ كانت مساحة المعرف الأصلية للتضمين 248. في خط الأساس الخاص بنا، طبقنا خدعة التجزئة عن طريق التفكيك للحد من حجم جدول التضمين. لتحديد ذلك بشكل أكثر تحديدًا، نستخدم جدولي تضمين أصغر بدلاً من جدول واحد ضخم لإنشاء تضمين فريد لكل معرف من خلال مزيج المتجهات: حيث 𝐸𝑟 ، 𝐸𝑞 هي التضمينات المقابلة لـ 𝐼𝐷𝑟 ، 𝐼𝐷𝑞. هذا يقلل فعليًا من أحجام جدول التضمين من 248 إلى 225؛ • هذا النموذج يخدم في الإنتاج الفعلي، ويتم قياس أداء هذه التجربة بواسطة AUC عبر الإنترنت مع حركة المرور الفعلية. أثناء التدريب عبر الإنترنت، نقوم بتحديث PS الخدمة عبر الإنترنت بأحدث مجموعة من المعلمات بفواصل زمنية دقيقة. قمنا بتصميم مجموعتين من التجارب للتحقق من جودة النموذج ومتانة النظام. 3.1.2 التدريب عبر الإنترنت. (1) . للتحقيق في ضرورة تردد التحديث بالدقيقة، أجرينا تجارب تزامن المعلمات من نموذج التدريب إلى نموذج التنبؤ بفواصل زمنية مختلفة. تردد التحديث مجموعة البيانات التي نستخدمها هي مجموعة بيانات Criteo Display Ads Challenge3، وهي مجموعة بيانات قياسية واسعة النطاق لنمذجة CTR. تحتوي على 7 أيام من البيانات المرتبة زمنيًا التي تسجل الميزات وإجراءات النقر. لهذه التجربة، نستخدم نموذج DeepFM القياسي كما هو موضح في [9] 6. لمحاكاة التدريب عبر الإنترنت، قمنا بالمعالجة المسبقة التالية لمجموعة البيانات. نأخذ 7 أيام من البيانات من مجموعة البيانات، ونقسمها إلى جزأين: 5 أيام من البيانات للتدريب المجمّع، ويومين للتدريب عبر الإنترنت. نقوم بتقسيم هذين اليومين من البيانات إلى 𝑁 مقاطع زمنيًا. يتم محاكاة التدريب عبر الإنترنت بواسطة الخوارزمية 1. على هذا النحو، نقوم بمحاكاة مزامنة المعلمات المدربة إلى PS الخدمة عبر الإنترنت بفاصل زمني تحدده عدد مقاطع البيانات. جربنا 𝑁 = 10، 50، 100، والتي تتوافق تقريبًا مع فاصل زمني للتحديث يبلغ 5 ساعات، وساعة واحدة، و 30 دقيقة. (2) . بالإضافة إلى ذلك، أجرينا تجربة حية مع حركة مرور الخدمة الفعلية لإظهار أهمية التدريب عبر الإنترنت في التطبيق الواقعي. تقارن هذه التجربة A/B بين التدريب عبر الإنترنت والتدريب المجمّع على أحد نماذج الإعلانات الخاصة بنا في الإنتاج. تجربة حية