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

ผู้แต่ง: 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 . ความแตกต่างเหล่านี้ได้สร้างความท้าทายที่ไม่เหมือนใครให้กับนักวิจัยและวิศวกรที่ทำงานเกี่ยวกับระบบแนะนำ 1.1 ความเบาบางและความเปลี่ยนแปลง ข้อมูลสำหรับการแนะนำส่วนใหญ่ประกอบด้วยคุณลักษณะแบบหมวดหมู่เบาบาง บางส่วนปรากฏด้วยความถี่ต่ำ การแมปไปยังพื้นที่ฝังที่มีมิติสูงตามปกติจะก่อให้เกิดปัญหาหลายประการ: • ไม่เหมือนกับโมเดลภาษาที่มีจำนวนชิ้นคำจำกัด จำนวนผู้ใช้และรายการที่จะจัดอันดับมีจำนวนมากกว่าหลายเท่า ตารางฝังขนาดใหญ่มากนี้แทบจะใส่ในหน่วยความจำโฮสต์เดียวไม่ได้ • ที่แย่กว่านั้นคือ ขนาดของตารางฝังคาดว่าจะเพิ่มขึ้นเมื่อเวลาผ่านไป เนื่องจากมีผู้ใช้และรายการมากขึ้น ในขณะที่เฟรมเวิร์กเช่น [ , ] ใช้ตัวแปรหนาแน่นขนาดคงที่เพื่อแสดงตารางฝัง 1 17 ในทางปฏิบัติ ระบบจำนวนมากใช้การแฮชที่มีการชนกันต่ำ [ , ] เพื่อลดรอยเท้าหน่วยความจำและอนุญาตให้ ID เพิ่มขึ้น สิ่งนี้อาศัยข้อสมมติฐานที่สมบูรณ์แบบเกินไปว่า ID ในตารางฝังมีการกระจายความถี่สม่ำเสมอ และการชนกันไม่มีผลเสียต่อคุณภาพของโมเดล น่าเสียดายที่นี่แทบไม่เคยเกิดขึ้นจริงสำหรับระบบแนะนำในโลกแห่งความเป็นจริง ซึ่งผู้ใช้หรือรายการจำนวนเล็กน้อยมีการเกิดขึ้นซ้ำๆ มากกว่าอย่างมีนัยสำคัญ ด้วยการเติบโตตามธรรมชาติของขนาดตารางฝัง โอกาสในการชนกันของคีย์แฮชจะเพิ่มขึ้นและนำไปสู่การเสื่อมคุณภาพของโมเดล 3 6 . ดังนั้นจึงมีความต้องการตามธรรมชาติสำหรับระบบแนะนำระดับการผลิตที่จะมีความสามารถในการจับคุณลักษณะให้ได้มากที่สุดในพารามิเตอร์ และยังมีความสามารถในการปรับจำนวนผู้ใช้และรายการที่พยายามบันทึกแบบยืดหยุ่น 1.2 การกระจายที่ไม่คงที่ รูปแบบภาพและภาษาแทบไม่มีการพัฒนาในระยะเวลาหลายศตวรรษ ในขณะที่ผู้ใช้ที่สนใจหัวข้อหนึ่งอาจเปลี่ยนความกระตือรือร้นได้ทุกนาทีถัดไป เป็นผลให้การกระจายข้อมูลผู้ใช้พื้นฐานไม่คงที่ ซึ่งเป็นปรากฏการณ์ที่มักเรียกว่า Concept Drift . โดยสัญชาตญาณ ข้อมูลจากประวัติล่าสุดสามารถมีส่วนช่วยในการคาดการณ์การเปลี่ยนแปลงพฤติกรรมของผู้ใช้ได้อย่างมีประสิทธิภาพมากขึ้น เพื่อลดผลกระทบของ Concept Drift โมเดลการให้บริการจำเป็นต้องได้รับการอัปเดตจากผลตอบรับของผู้ใช้ใหม่ให้ใกล้เคียงกับเรียลไทม์ที่สุดเท่าที่จะเป็นไปได้ เพื่อสะท้อนถึงความสนใจล่าสุดของผู้ใช้ จากความแตกต่างเหล่านี้และการสังเกตปัญหาที่เกิดขึ้นจากการผลิตของเรา เราได้ออกแบบ ระบบขนาดใหญ่เพื่อแก้ไขปัญหาเหล่านี้ เราได้ทำการทดลองอย่างกว้างขวางเพื่อตรวจสอบและปรับปรุงการออกแบบของเราในสภาพแวดล้อมการผลิต Monolith สามารถ Monolith (1) ให้พลังการแสดงออกเต็มรูปแบบสำหรับคุณลักษณะเบาบางโดยการออกแบบตารางแฮชที่ไม่มีการชนกันและกลไกการลบคุณลักษณะแบบไดนามิก (2) วนลูปผลตอบรับการให้บริการกลับไปสู่การฝึกอบรมแบบเรียลไทม์ด้วยการฝึกอบรมออนไลน์ ด้วยความสามารถทางสถาปัตยกรรมเหล่านี้ Monolith จึงมีประสิทธิภาพเหนือกว่าระบบที่ใช้เทคนิคแฮชที่มีการชนกันอย่างสม่ำเสมอด้วยการใช้งานหน่วยความจำที่คล้ายคลึงกัน และได้รับ AUC การให้บริการออนไลน์ที่ล้ำสมัยโดยไม่ทำให้พลังการประมวลผลของเซิร์ฟเวอร์ของเราต้องแบกรับภาระมากเกินไป ส่วนที่เหลือของเอกสารจะจัดเรียงดังนี้ เราจะอธิบายรายละเอียดการออกแบบว่า Monolith จัดการกับความท้าทายที่มีอยู่ด้วยตารางแฮชที่ไม่มีการชนกันและการฝึกอบรมแบบเรียลไทม์ในส่วนที่ 2 การทดลองและผลลัพธ์จะนำเสนอในส่วนที่ 3 พร้อมกับข้อสรุปที่ผ่านการทดสอบในระดับการผลิตและการอภิปรายเกี่ยวกับการแลกเปลี่ยนระหว่างความไวต่อเวลา ความน่าเชื่อถือ และคุณภาพของโมเดล ส่วนที่ 4 จะสรุปงานที่เกี่ยวข้องและเปรียบเทียบกับ Monolith ส่วนที่ 5 จะสรุปงานนี้ 2 การออกแบบ สถาปัตยกรรมโดยรวมของ Monolith โดยทั่วไปจะตามการตั้งค่า Worker- arameter erverแบบกระจายของ TensorFlow (รูปที่ ในสถาปัตยกรรม Worker-PS เครื่องจักรจะได้รับมอบหมายบทบาทที่แตกต่างกัน เครื่อง Worker มีหน้าที่ทำการคำนวณตามที่กำหนดโดยกราฟ และเครื่อง PS จะจัดเก็บพารามิเตอร์และอัปเดตตาม Gradient ที่คำนวณโดย Worker P S 2). ในโมเดลการแนะนำ พารามิเตอร์จะถูกจัดหมวดหมู่เป็นสองชุด: แบบหนาแน่นและแบบเบาบาง พารามิเตอร์แบบหนาแน่นคือ weights/variables ในโครงข่ายประสาทเทียมเชิงลึก และพารามิเตอร์แบบเบาบางหมายถึงตารางฝังที่สอดคล้องกับคุณลักษณะเบาบาง ในการออกแบบของเรา พารามิเตอร์ทั้งแบบหนาแน่นและแบบเบาบางเป็นส่วนหนึ่งของ TensorFlow Graph และถูกจัดเก็บไว้ใน parameter servers เช่นเดียวกับ Variable ของ TensorFlow สำหรับพารามิเตอร์แบบหนาแน่น เราได้ออกแบบชุดการดำเนินการ HashTable ที่มีประสิทธิภาพสูง ไม่มีข้อผิดพลาด และยืดหยุ่นสำหรับพารามิเตอร์แบบเบาบาง เพื่อเสริมข้อจำกัดของ Tensor-Flow ที่เกิดจากการแยกการฝึกอบรมและการอนุมาน การฝึกอบรมออนไลน์ที่ปรับขนาดได้อย่างยืดหยุ่นของ Monolith ได้รับการออกแบบมาเพื่อซิงโครไนซ์พารามิเตอร์จาก Training-PS ไปยัง Online Serving-PS อย่างมีประสิทธิภาพภายในช่วงเวลาสั้นๆ โดยมีการรับประกันความทนทานของโมเดลโดยกลไกความทนทานต่อข้อผิดพลาด 2.1 ตารางแฮช หลักการแรกในการออกแบบการแสดงคุณลักษณะเบาบางของเราคือการหลีกเลี่ยงการยัดข้อมูลจาก ID ที่แตกต่างกันลงในฝังขนาดคงที่เดียวกัน การจำลองตารางฝังที่มีขนาดแบบไดนามิกด้วย TensorFlow Variable ที่พร้อมใช้งานจะนำไปสู่ข้อผิดพลาดของ ID อย่างหลีกเลี่ยงไม่ได้ ซึ่งจะทวีความรุนแรงขึ้นเมื่อ ID ใหม่เข้ามาและตารางเติบโต ดังนั้น แทนที่จะสร้างบน Variable เราได้พัฒนา HashTable แบบ key-value ใหม่สำหรับพารามิเตอร์เบาบางของเรา HashTable ของเราใช้ Cuckoo Hashmap [ ] เป็นหลัก ซึ่งรองรับการแทรกคีย์ใหม่โดยไม่มีการชนกับคีย์ที่มีอยู่ Cuckoo Hashing ให้ความซับซ้อนของเวลา 𝑂 (1) ในกรณีที่เลวร้ายที่สุดสำหรับการค้นหาและการลบ และ 𝑂 (1) ที่คาดหวังโดยเฉลี่ยสำหรับการแทรก ดังแสดงในรูปที่ มันเก็บตารางสองตาราง 𝑇0, 𝑇1 ด้วยฟังก์ชันแฮชที่แตกต่างกัน ℎ0 (𝑥), ℎ1 (𝑥) และองค์ประกอบจะถูกจัดเก็บไว้ในตารางใดตารางหนึ่ง เมื่อพยายามแทรกองค์ประกอบ 16 3 𝐴 ลงใน 𝑇0 จะพยายามวาง 𝐴 ที่ ℎ0 (𝐴) ก่อน หาก ℎ0 (𝐴) ถูกครอบครองโดยองค์ประกอบอื่น 𝐵 จะลบ 𝐵 ออกจาก 𝑇0 และพยายามแทรก 𝐵 ลงใน 𝑇1 ด้วยตรรกะเดียวกัน กระบวนการนี้จะดำเนินต่อไปจนกว่าองค์ประกอบทั้งหมดจะเสถียร หรือเกิดการ rehash เมื่อการแทรกเกิดวงจร การลดรอยเท้าหน่วยความจำก็เป็นข้อควรพิจารณาที่สำคัญในการออกแบบของเรา วิธีการง่ายๆ ในการแทรก ID ใหม่ทุกรายการลงใน HashTable จะทำให้หน่วยความจำหมดไปอย่างรวดเร็ว การสังเกตโมเดลการผลิตจริงนำไปสู่ข้อสรุปสองประการ: (1) ID ที่ปรากฏเพียงไม่กี่ครั้งมีส่วนช่วยในการปรับปรุงคุณภาพโมเดลน้อย ข้อสังเกตที่สำคัญคือ ID มีการกระจายแบบ long-tail ซึ่ง ID ที่ได้รับความนิยมอาจปรากฏหลายล้านครั้งในขณะที่ ID ที่ไม่เป็นที่นิยมปรากฏไม่เกินสิบครั้ง การฝังที่สอดคล้องกับ ID ที่ไม่บ่อยเหล่านี้จะ underfit เนื่องจากขาดข้อมูลการฝึกอบรมและโมเดลจะไม่สามารถทำการประมาณการที่ดีจากสิ่งเหล่านั้นได้ ท้ายที่สุด ID เหล่านี้ไม่น่าจะส่งผลต่อผลลัพธ์ ดังนั้นคุณภาพของโมเดลจะไม่ได้รับผลกระทบจากการลบ ID ที่มีจำนวนน้อยเหล่านี้; (2) ID ที่ล้าสมัยจากประวัติอันไกลโพ้นมีส่วนช่วยต่อโมเดลปัจจุบันน้อยมาก เนื่องจากหลายรายการไม่เคยถูกเข้าถึงเลย ซึ่งอาจเป็นเพราะผู้ใช้ไม่ใช้งานอีกต่อไป หรือวิดีโอสั้นล้าสมัย การจัดเก็บการฝังสำหรับ ID เหล่านี้ไม่สามารถช่วยโมเดลได้แต่อย่างใด นอกจากการสิ้นเปลืองหน่วยความจำ PS ของเราโดยเปล่าประโยชน์ จากข้อสังเกตเหล่านี้ เราได้ออกแบบฮิวริสติกการกรอง ID คุณลักษณะหลายอย่างสำหรับการใช้งาน HashTable ที่มีประสิทธิภาพหน่วยความจำมากขึ้น: (1) ID จะถูกกรองก่อนที่จะได้รับอนุญาตให้เข้าสู่ตารางฝัง เรามีวิธีการกรองสองวิธี: ก่อนอื่น เรากรองตามจำนวนการปรากฏก่อนที่จะแทรกเป็นคีย์ โดยที่เกณฑ์การปรากฏเป็นไฮเปอร์พารามิเตอร์ที่ปรับได้ซึ่งแตกต่างกันไปในแต่ละโมเดล นอกจากนี้ เรายังใช้ตัวกรองความน่าจะเป็นที่ช่วยลดการใช้หน่วยความจำได้อีก ![#Figure 4: Streaming Engine. วงจรป้อนกลับข้อมูลจาก [User → Model Server → Training Worker → Model Server → User] จะใช้เวลานานเมื่อใช้เส้นทางการฝึกอบรมแบบแบทช์ ในขณะที่การฝึกอบรมออนไลน์จะปิดวงจรได้ทันท่วงที](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID จะถูกตั้งเวลาและตั้งค่าให้หมดอายุหลังจากไม่มีการใช้งานเป็นระยะเวลาที่กำหนด เวลาหมดอายุยังสามารถปรับได้สำหรับแต่ละตารางฝังเพื่ออนุญาตให้แยกความแตกต่างของคุณลักษณะที่มีความไวต่อข้อมูลประวัติที่แตกต่างกัน ในการใช้งานของเรา HashTable ถูกนำไปใช้เป็นการดำเนินการทรัพยากรของ TensorFlow เช่นเดียวกับ Variable การค้นหาและการอัปเดตก็ถูกนำไปใช้เป็นการดำเนินการ TensorFlow แบบเนทีฟเพื่อให้รวมเข้ากันได้ง่ายขึ้นและเข้ากันได้ดีขึ้น 2.2 การฝึกอบรมออนไลน์ ใน Monolith การฝึกอบรมจะแบ่งออกเป็นสองขั้นตอน (รูปที่ 1): (1) ขั้นตอนการฝึกอบรมแบบแบทช์ ขั้นตอนนี้ทำงานเหมือนกับ TensorFlow training loop ทั่วไป: ในแต่ละขั้นตอนการฝึกอบรม worker การฝึกอบรมจะอ่าน mini-batch ของตัวอย่างการฝึกอบรมจากที่เก็บข้อมูล ขอพารามิเตอร์จาก PS คำนวณ forward pass และ backward pass และสุดท้ายจะส่งพารามิเตอร์ที่อัปเดตไปยัง Training PS แตกต่างจากงานการเรียนรู้เชิงลึกทั่วไปเล็กน้อย เราฝึกอบรมชุดข้อมูลของเราเพียงรอบเดียว การฝึกอบรมแบบแบทช์มีประโยชน์สำหรับการฝึกอบรมข้อมูลในอดีตเมื่อเราแก้ไขสถาปัตยกรรมโมเดลของเราและฝึกอบรมโมเดลใหม่ (2) ขั้นตอนการฝึกอบรมออนไลน์ หลังจากที่โมเดลถูกนำไปใช้ในการให้บริการออนไลน์ การฝึกอบรมจะไม่หยุด แต่จะเข้าสู่ขั้นตอนการฝึกอบรมออนไลน์ แทนที่จะอ่าน mini-batch examples จากที่เก็บข้อมูล worker การฝึกอบรมจะบริโภคข้อมูลแบบเรียลไทม์ทันทีและอัปเดต Training PS Training PS จะซิงโครไนซ์พารามิเตอร์ไปยัง Serving PS เป็นระยะๆ ซึ่งจะมีผลกับผู้ใช้ทันที สิ่งนี้ช่วยให้โมเดลของเราปรับตัวเข้ากับผลตอบรับของผู้ใช้แบบเรียลไทม์ได้ Monolith สร้างขึ้นด้วยความสามารถในการสลับระหว่างการฝึกอบรมแบบแบทช์และการฝึกอบรมออนไลน์ได้อย่างราบรื่น สิ่งนี้เป็นไปได้ด้วยการออกแบบ streaming engine ของเราดังที่แสดงในรูปที่ 2.2.1 Streaming Engine. 4. ในการออกแบบของเรา เราใช้คิว Kafka [ ] หนึ่งคิวเพื่อบันทึกการดำเนินการของผู้ใช้ (เช่น คลิกที่รายการหรือชอบรายการ ฯลฯ) และคิว Kafka อีกคิวสำหรับคุณลักษณะ หัวใจหลักของเอนจิ้นคือ Flink [ ] streaming job สำหรับ Online Feature Joiner Online Joiner จะรวมคุณลักษณะเข้ากับป้ายกำกับจากการดำเนินการของผู้ใช้และสร้างตัวอย่างการฝึกอบรม ซึ่งจะถูกเขียนลงในคิว Kafka คิวสำหรับตัวอย่างการฝึกอบรมจะถูกบริโภคโดยทั้งการฝึกอบรมออนไลน์และการฝึกอบรมแบบแบทช์: 13 4 สำหรับการฝึกอบรมออนไลน์ worker การฝึกอบรมจะอ่านข้อมูลโดยตรงจากคิว Kafka สำหรับการฝึกอบรมแบบแบทช์ งานดัมพ์ข้อมูลจะดัมพ์ข้อมูลไปยัง HDFS [ ] ก่อน หลังจากข้อมูลใน HDFS สะสมจำนวนหนึ่งแล้ว worker การฝึกอบรมจะดึงข้อมูลจาก HDFS และทำการฝึกอบรมแบบแบทช์ 18 พารามิเตอร์ที่อัปเดตใน Training PS จะถูกส่งไปยัง Serving PS ตามกำหนดการซิงโครไนซ์พารามิเตอร์ ในแอปพลิเคชันจริง บันทึกการดำเนินการของผู้ใช้และคุณลักษณะจะถูกสตรีมไปยัง Online Joiner (รูปที่ โดยไม่มีการรับประกันลำดับเวลา ดังนั้นเราจึงใช้คีย์ที่ไม่ซ้ำกันสำหรับแต่ละคำขอ เพื่อให้การดำเนินการของผู้ใช้และคุณลักษณะสามารถจับคู่กันได้อย่างถูกต้อง 2.2.2 Online Joiner. 5) ความล่าช้าของการดำเนินการของผู้ใช้อาจเป็นปัญหาได้เช่นกัน ตัวอย่างเช่น ผู้ใช้อาจใช้เวลาสองสามวันก่อนที่จะตัดสินใจซื้อสินค้าที่เคยเห็นเมื่อหลายวันก่อน นี่เป็นความท้าทายสำหรับ Joiner เพราะหากเก็บคุณลักษณะทั้งหมดไว้ในแคช ก็จะใส่ในหน่วยความจำไม่ได้ ในระบบของเรา มีการใช้ที่เก็บข้อมูล key-value บนดิสก์เพื่อจัดเก็บคุณลักษณะที่รอเป็นระยะเวลานาน เมื่อบันทึกการดำเนินการของผู้ใช้มาถึง มันจะค้นหาในแคชในหน่วยความจำก่อน แล้วจึงค้นหาในที่เก็บข้อมูล key-value หากแคชขาดหายไป อีกปัญหาหนึ่งที่เกิดขึ้นในแอปพลิเคชันจริงคือการกระจายตัวอย่างเชิงลบและเชิงบวกไม่สม่ำเสมออย่างมาก โดยจำนวนของอย่างแรกอาจสูงกว่าอย่างหลังหลายเท่า กลยุทธ์ทั่วไปคือการสุ่มตัวอย่างเชิงลบ เพื่อป้องกันตัวอย่างเชิงบวกจากการถูกตัวอย่างเชิงลบครอบงำ สิ่งนี้จะเปลี่ยนการกระจายพื้นฐานของโมเดลที่ฝึกอบรมไปสู่ความน่าจะเป็นที่สูงขึ้นในการสร้างการคาดการณ์เชิงบวกอย่างแน่นอน ในฐานะที่เป็นการแก้ไข เราใช้การแก้ไข log odds [ ] ในระหว่างการให้บริการ เพื่อให้แน่ใจว่าโมเดลออนไลน์เป็นตัวประมาณค่าที่ไม่เอนเอียงของการกระจายเดิม 19 ในระหว่างการฝึกอบรมออนไลน์ Monolith training cluster จะรับข้อมูลอย่างต่อเนื่องจากโมดูลการให้บริการออนไลน์และอัปเดตพารามิเตอร์บน Training PS ขั้นตอนสำคัญในการทำให้ Online Serving PS ได้รับประโยชน์จากพารามิเตอร์ที่เพิ่งฝึกฝนใหม่เหล่านี้คือการซิงโครไนซ์พารามิเตอร์โมเดลที่อัปเดต ในสภาพแวดล้อมการผลิต เราพบกับความท้าทายหลายประการ: 2.2.3 Parameter Synchronization. โมเดลบน Online Serving PS ต้องไม่หยุดให้บริการเมื่อทำการอัปเดต โมเดลของเราในการผลิตโดยทั่วไปมีขนาดหลายเทราไบต์ และเป็นผลให้การแทนที่พารามิเตอร์ทั้งหมดต้องใช้เวลาพอสมควร การหยุด Online PS จากการให้บริการโมเดลระหว่างกระบวนการแทนที่จะเป็นที่ยอมรับไม่ได้ และการอัปเดตจะต้องทำแบบทันที การถ่ายโอนโมเดลหลายเทราไบต์ทั้งหมดจาก Training PS ไปยัง Online Serving PS จะสร้างแรงกดดันอย่างมากต่อทั้งแบนด์วิดท์เครือข่ายและหน่วยความจำบน PS เนื่องจากต้องใช้หน่วยความจำขนาดโมเดลสองเท่าเพื่อรับโมเดลใหม่ที่กำลังจะมาถึง เพื่อให้การฝึกอบรมออนไลน์สามารถปรับขนาดให้เข้ากับขนาดของสถานการณ์ทางธุรกิจของเราได้ เราได้ออกแบบกลไกการซิงโครไนซ์พารามิเตอร์แบบเพิ่มหน่วยแบบทันทีเป็นระยะๆ ใน Monolith โดยอาศัยลักษณะที่สังเกตได้หลายประการของโมเดลของเรา: (1) พารามิเตอร์เบาบางมีสัดส่วนมากที่สุดต่อขนาดของโมเดลแนะนำ (2) เมื่อพิจารณาจากกรอบเวลาสั้นๆ มีเพียงส่วนย่อยของ ID เท่านั้นที่จะได้รับการฝึกอบรมและอัปเดตการฝัง (3) ตัวแปรแบบหนาแน่นเคลื่อนที่ช้ากว่าการฝังแบบเบาบางมาก นี่เป็นเพราะในตัวปรับให้เหมาะสมตามโมเมนตัม การสะสมโมเมนตัมสำหรับตัวแปรแบบหนาแน่นจะถูกขยายโดยขนาดที่มหาศาลของข้อมูลการฝึกอบรมการแนะนำ ในขณะที่การฝังแบบเบาบางเพียงไม่กี่รายการเท่านั้นที่จะได้รับการอัปเดตใน batch ข้อมูลเดียว (1) และ (2) ช่วยให้เราใช้ประโยชน์จากการอัปเดตแบบเบาบางในทุก ID คุณลักษณะ ใน Monolith เราเก็บชุดแฮชของคีย์ที่ถูกสัมผัส ซึ่งแสดงถึง ID ที่การฝังได้รับการฝึกอบรมตั้งแต่การซิงโครไนซ์พารามิเตอร์ครั้งล่าสุด เราผลักดันส่วนย่อยของพารามิเตอร์เบาบางซึ่งคีย์อยู่ในชุดคีย์ที่ถูกสัมผัสด้วยช่วงเวลาเป็นนาทีจาก Training PS ไปยัง Online Serving PS การอัปเดตพารามิเตอร์แบบเพิ่มหน่วยขนาดค่อนข้างเล็กนี้มีน้ำหนักเบาสำหรับการส่งข้อมูลเครือข่าย และจะไม่ทำให้เกิดการกระโดดของหน่วยความจำอย่างรุนแรงระหว่างการซิงโครไนซ์ เรายังใช้ประโยชน์จาก (3) เพื่อลด I/O เครือข่ายและการใช้หน่วยความจำเพิ่มเติมโดยการตั้งค่ากำหนดการซิงค์ที่ก้าวร้าวมากขึ้นสำหรับพารามิเตอร์เบาบาง ในขณะที่อัปเดตพารามิเตอร์แบบหนาแน่นน้อยลง สิ่งนี้อาจทำให้เราตกอยู่ในสถานการณ์ที่พารามิเตอร์แบบหนาแน่นที่เราให้บริการเป็นเวอร์ชันที่ค่อนข้างล้าสมัยเมื่อเทียบกับส่วนเบาบาง อย่างไรก็ตาม ความไม่สอดคล้องกันดังกล่าวสามารถยอมรับได้เนื่องจากเหตุผลที่กล่าวไว้ใน (3) เนื่องจากไม่พบการสูญเสียที่ชัดเจน 2.3 ความทนทานต่อข้อผิดพลาด ในฐานะที่เป็นระบบที่ใช้งานจริง Monolith ได้รับการออกแบบมาให้มีความสามารถในการกู้คืน PS ในกรณีที่เกิดข้อผิดพลาด ตัวเลือกทั่วไปสำหรับความทนทานต่อข้อผิดพลาดคือการสร้างสแนปชอตของสถานะโมเดลเป็นระยะๆ และกู้คืนจากสแนปชอตล่าสุดเมื่อตรวจพบข้อผิดพลาดของ PS ความถี่ในการสร้างสแนปชอตมีผลกระทบสองประการ: (1) คุณภาพของโมเดล โดยสัญชาตญาณ คุณภาพของโมเดลจะได้รับผลกระทบน้อยลงจากการสูญเสียประวัติล่าสุดด้วยความถี่ในการสร้างสแนปชอตที่เพิ่มขึ้น (2) ค่าใช้จ่ายในการคำนวณ การสร้างสแนปชอตโมเดลหลายเทราไบต์ไม่ใช่เรื่องฟรี มันก่อให้เกิดการคัดลอกหน่วยความจำจำนวนมากและ I/O ดิสก์ เพื่อแลกเปลี่ยนระหว่างคุณภาพโมเดลและค่าใช้จ่ายในการคำนวณ Monolith จะสร้างสแนปชอตของ Training PS ทั้งหมดทุกวัน แม้ว่า PS จะสูญเสียการอัปเดตหนึ่งวันในกรณีที่เกิดข้อผิดพลาด เราพบว่าการเสื่อมคุณภาพของโมเดลนั้นสามารถยอมรับได้ผ่านการทดลองของเรา เราจะวิเคราะห์ผลกระทบของความน่าเชื่อถือของ PS ในส่วนถัดไป 3 การประเมิน เพื่อให้เข้าใจถึงประโยชน์และข้อแลกเปลี่ยนที่เกิดจากการออกแบบที่เสนอของเราได้ดียิ่งขึ้น เราได้ทำการทดลองหลายครั้งในระดับการผลิตและทดสอบ A/B ด้วยการรับส่งข้อมูลแบบเรียลไทม์เพื่อประเมินและตรวจสอบ Monolith จากแง่มุมต่างๆ เราตั้งเป้าที่จะตอบคำถามต่อไปนี้ด้วยการทดลองของเรา: (1) เราจะได้รับประโยชน์จากการใช้ HashTable ที่ไม่มีการชนกันมากน้อยเพียงใด (2) การฝึกอบรมออนไลน์แบบเรียลไทม์มีความสำคัญเพียงใด (3) การออกแบบการซิงโครไนซ์พารามิเตอร์ของ Monolith นั้นทนทานเพียงพอในสถานการณ์การผลิตขนาดใหญ่หรือไม่ ในส่วนนี้ เราจะนำเสนอการตั้งค่าการทดลองของเราก่อน แล้วจึงหารือเกี่ยวกับผลลัพธ์และข้อค้นพบของเราโดยละเอียด 3.1 การตั้งค่าการทดลอง ดังที่อธิบายไว้ในส่วนที่ ตารางฝังใน Monolith ถูกนำไปใช้เป็น Collisionless HashTables เพื่อพิสูจน์ความจำเป็นในการหลีกเลี่ยงการชนกันในตารางฝังและเพื่อวัดผลกำไรจากการใช้งานแบบ Collisionless ของเรา เราได้ทำการทดลองสองกลุ่มบนชุดข้อมูล Movielens และบนชุดข้อมูลการผลิตภายในของเราตามลำดับ: 3.1.1 Embedding Table. 2.1 (1) ชุดข้อมูล ml-25m [ ] นี่เป็นชุดข้อมูลสาธารณะมาตรฐานสำหรับการให้คะแนนภาพยนตร์ ประกอบด้วยคะแนน 25 ล้านรายการ ซึ่งเกี่ยวข้องกับผู้ใช้ประมาณ 162,000 คน และภาพยนตร์ 62,000 เรื่อง MovieLens 11 • ป้ายกำกับดั้งเดิมคือคะแนนตั้งแต่ การประมวลผลล่วงหน้าของป้ายกำกับ 0.5 ถึง 5.0 ในขณะที่ในการผลิต งานของเราส่วนใหญ่คือการรับสัญญาณแบบไบนารีจากผู้ใช้ เพื่อจำลองโมเดลการผลิตของเราให้ดียิ่งขึ้น เราได้แปลงป้ายกำกับมาตราส่วนเป็นป้ายกำกับแบบไบนารี โดยถือว่าคะแนน ≥ 3.5 เป็นตัวอย่างเชิงบวก และที่เหลือเป็นตัวอย่างเชิงลบ • โมเดลและเมตริก เราได้นำโมเดล DeepFM มาตรฐานมาใช้ ซึ่งเป็นสถาปัตยกรรมโมเดลที่ใช้กันทั่วไปสำหรับปัญหาการแนะนำ ประกอบด้วยส่วนประกอบ FM และส่วนประกอบแบบหนาแน่น (รูปที่ 6) การคาดการณ์จะได้รับการประเมินโดย AUC เนื่องจากเป็นมาตรวัดหลักสำหรับโมเดลจริง • การชนกันของ Embedding ชุดข้อมูลนี้มี ID ผู้ใช้ประมาณ 160K และ ID ภาพยนตร์ 60K เพื่อเปรียบเทียบกับการใช้งานตารางฝังแบบ Collisionless เราได้ทำการทดลองอีกกลุ่มหนึ่งซึ่ง ID จะได้รับการประมวลผลล่วงหน้าด้วย MD5 hashing แล้วแมปไปยังพื้นที่ ID ที่เล็กลง เป็นผลให้ ID บางตัวจะใช้การฝังร่วมกับ ID อื่น ตารางที่ 1 แสดงสถิติโดยละเอียดของ ID ผู้ใช้และภาพยนตร์ก่อนและหลังการแฮช (2) . ชุดข้อมูลการแนะนำภายใน เรายังได้ทำการทดลองกับโมเดลการแนะนำในสภาพแวดล้อมการผลิต โมเดลนี้โดยทั่วไปจะตามสถาปัตยกรรมแบบ multi-tower โดยแต่ละ tower มีหน้าที่เรียนรู้เพื่อคาดการณ์พฤติกรรมผู้ใช้ประเภทพิเศษ แต่ละโมเดลมีตารางฝังประมาณ 1000 ตาราง และการกระจายขนาดของตารางฝังนั้นไม่สม่ำเสมอมาก พื้นที่ ID ดั้งเดิมของตารางฝังคือ 248 ใน baseline ของเรา เราใช้เทคนิค hashing โดยการแยกส่วนเพื่อควบคุมขนาดของตารางฝัง โดยเฉพาะอย่างยิ่ง เราใช้ตารางฝังขนาดเล็กสองตารางแทนที่จะเป็นตารางเดียวขนาดใหญ่เพื่อสร้างการฝังที่ไม่ซ้ำกันสำหรับแต่ละ ID โดยการรวมเวกเตอร์: โดยที่ 𝐸𝑟 , 𝐸𝑞 คือ embeddings ที่สอดคล้องกับ 𝐼𝐷𝑟 , 𝐼𝐷𝑞 สิ่งนี้ช่วยลดขนาดตารางฝังจาก 248 เป็น 225 ได้อย่างมีประสิทธิภาพ • โมเดลนี้กำลังให้บริการในการผลิตจริง และประสิทธิภาพของการทดลองนี้วัดโดย online AUC ด้วยการรับส่งข้อมูลการให้บริการจริง ในระหว่างการฝึกอบรมออนไลน์ เราอัปเดต PS การให้บริการออนไลน์ของเราด้วยชุดพารามิเตอร์ล่าสุดด้วยช่วงเวลาเป็นนาที เราได้ออกแบบการทดลองสองกลุ่มเพื่อยืนยันคุณภาพโมเดลและความทนทานของระบบ 3.1.2 Online Training. (1) เพื่อตรวจสอบความจำเป็นของความถี่ในการอัปเดตเป็นนาที เราได้ทำการทดลองที่ซิงโครไนซ์พารามิเตอร์จากโมเดลการฝึกอบรมไปยังโมเดลการคาดการณ์ด้วยช่วงเวลาที่แตกต่างกัน ความถี่ในการอัปเดต ชุดข้อมูลที่เราใช้คือ Criteo Display Ads Challenge dataset3 ซึ่งเป็นชุดข้อมูลมาตรฐานขนาดใหญ่สำหรับการเปรียบเทียบโมเดล CTR ประกอบด้วยข้อมูล 7 วันที่จัดเรียงตามลำดับเวลา บันทึกคุณลักษณะและการคลิก เพื่อการทดลองนี้ เราใช้โมเดล DeepFM มาตรฐานตามที่อธิบายไว้ใน </ 6.