เพิ่มประสิทธิภาพการพัฒนา Machine Learning ด้วย Feature Store

โดย จอห์น โธมัส

ในUFCนักสู้จะเตรียมพร้อมสำหรับเวลาของพวกเขาในแปดเหลี่ยมด้วยสูตรการฝึกฝนที่เข้มข้น ไฟต์เตอร์และทีมของพวกเขาจะใช้เวลาหลายเดือนในการวิเคราะห์สไตล์ของคู่ต่อสู้เพื่อหาจุดอ่อนที่ใช้ประโยชน์ได้ ปรับแต่งร่างกายและเทคนิคอย่างละเอียดเพื่อนำเสนอคู่ต่อสู้ที่ดีที่สุด

นักวิทยาศาสตร์ข้อมูลที่ Endeavourซึ่งเป็นองค์กรแม่ของ UFC เข้าใกล้การคาดการณ์ของแมชชีนเลิร์นนิงด้วยความตั้งใจไม่น้อย ในขณะที่นักสู้ยอมลดกล้องลง ข้อมูลที่เกี่ยวข้องกับแฟน ๆ ที่ชมการต่อสู้ก็ได้รับการวิเคราะห์อย่างวิจารณ์เช่นกัน การแข่งขันเพื่อดึงดูดและรักษาผู้ชมนั้นดุเดือด ลูกค้าต้องการประสบการณ์ที่น่าดึงดูดซึ่งทำให้พวกเขาติดใจ และ Endeavour ได้กลายเป็นผู้นำที่เพิ่มขึ้นในการใช้ประโยชน์จากการเรียนรู้ของเครื่องและความเชี่ยวชาญด้านดิจิทัลเพื่อรับมือกับความท้าทาย ด้านล่างนี้เราจะเจาะลึกลงไปในงานของ Endeavour ในการเพิ่มข้อมูลเชิงลึกของผู้ชมให้สูงสุดด้วยการใช้ฟีเจอร์สโตร์ในการพัฒนาแมชชีนเลิร์นนิงที่คล่องตัวที่ UFC

นักวิทยาศาสตร์ด้านข้อมูลหลายคนที่อ่านข้อความนี้ทราบดีว่างานส่วนใหญ่ในการสร้างโมเดลแมชชีนเลิร์นนิงมาจากการสร้างฟีเจอร์ คุณลักษณะ (เช่น ตัวทำนายหรือแอตทริบิวต์) เช่น ลักษณะรวม (เช่น วันนับจากการซื้อครั้งล่าสุดหรือประเทศที่ลูกค้าพำนัก) เป็นส่วนสำคัญของโมเดลแมชชีนเลิร์นนิงเชิงคาดการณ์ เพื่อให้แบบจำลองคาดการณ์ได้อย่างแม่นยำ จำเป็นต้องมีคุณลักษณะคุณภาพสูงที่สามารถอธิบายการเปลี่ยนแปลงที่เพียงพอในผลลัพธ์ (กล่าวอีกนัยหนึ่ง กำหนดว่าการคาดการณ์ของคุณอยู่ในหมวดหมู่ใด) แต่ด้วยการดำเนินการแมชชีนเลิร์นนิงที่ปรับขนาดได้ เราอาจพบว่ามันท้าทายหรือซ้ำซากในการดูแลรักษาระบบนิเวศ ML นอกจากนี้ ทีมของคุณอาจเสี่ยงต่อความไม่สอดคล้องกันของคำจำกัดความในโค้ดเบสของคุณโดยทำแบบเดิมซ้ำแล้วซ้ำอีก Endeavour ได้แก้ปัญหานี้ผ่านFeature Storeซึ่งกำหนดมาตรฐานและรวมศูนย์ฟีเจอร์ต่างๆ เพื่อให้แน่ใจว่ามีความสม่ำเสมอ ค้นพบได้ และนำมาใช้ซ้ำได้

ฟีเจอร์ต่างๆ อาจใช้เวลานานในการพัฒนา ขึ้นอยู่กับความซับซ้อนของการคำนวณ คุณสามารถใช้เวลาหลายสัปดาห์ในการรวบรวมข้อมูลดิบที่มีอยู่ให้อยู่ในรูปแบบที่ย่อยได้ซึ่งเหมาะสมกับโมเดลของคุณ คุณลักษณะบางอย่างอาจพบได้ทั่วไปในหลายกรณีการใช้งาน เช่น การขายตั๋วตลอดชีพหรืออุปกรณ์สตรีมมิ่งที่ใช้บ่อยที่สุด เป็นต้น ซึ่งสามารถคาดการณ์ได้สำหรับทั้งรูปแบบการทำธุรกรรมและพฤติกรรมการท่องเว็บ หากนักวิทยาศาสตร์ข้อมูลหลายคนทำงานกับแบบจำลองโดยใช้แหล่งข้อมูลเดียวกัน ปัญหาต่างๆ เช่น ความไม่สอดคล้องกันของคำจำกัดความอาจเกิดขึ้นเมื่อคุณลักษณะเดียวกันถูกสร้างขึ้นหลายครั้งสำหรับฟังก์ชันวัตถุประสงค์ที่แตกต่างกัน (เช่น คำถามเชิงคาดการณ์ที่คุณต้องการได้รับคำตอบ) ความพยายามด้านวิศวกรรมข้อมูลสามารถปรับปรุงได้โดยใช้ฮับทั่วไปของคุณสมบัติที่สามารถใช้กับไคลเอนต์หลายเครื่องและหลายรุ่น

เข้าสู่ที่เก็บคุณสมบัติ

ที่เก็บคุณลักษณะเป็นที่เก็บโค้ดทั่วไปที่ผู้มีส่วนร่วมหลายคนสามารถกำหนดคุณลักษณะสำหรับการพัฒนาแบบจำลองได้

ในที่จัดเก็บคุณลักษณะ คุณสามารถมีสคีมาที่ประกอบด้วยตารางคุณลักษณะหลายตาราง โดยแต่ละตารางจะแสดงภาพรวมของตัวระบุทั่วไปที่คุณกำลังพยายามคาดคะเน เราสามารถแนะนำตัวอย่างการใช้งานที่ทำกับEndeavour StreamingEndeavour Streaming นำเทคโนโลยีชั้นนำและความเชี่ยวชาญด้านสื่อดิจิทัลมาสู่โลกแห่งการสตรีมและมอบความสามารถในการวิเคราะห์ที่หลากหลายสำหรับยักษ์ใหญ่ด้านสตรีมมิงกีฬา ด้วยไคลเอนต์แต่ละราย (หมายถึงพันธมิตรทางธุรกิจของ Endeavour ในการสตรีมเนื้อหาของพวกเขา) Endeavour Streaming จะรวบรวมข้อมูลเกี่ยวกับการสตรีมและพฤติกรรมการทำธุรกรรมอย่างมีประสิทธิภาพ ซึ่งจะช่วยเพิ่มประสบการณ์ของลูกค้าได้ จากนั้นนักวิทยาศาสตร์ด้านข้อมูลในทีมของเราจะใช้สตรีมข้อมูลดิบเหล่านี้เพื่อให้การคาดการณ์ของแมชชีนเลิร์นนิงสำหรับลูกค้า หากคุณกำลังใช้แมชชีนเลิร์นนิงสำหรับแหล่งข้อมูลเกี่ยวกับข้อมูลการสตรีมวิดีโอ คุณอาจมีรายละเอียดต่อไปนี้ ตัวอย่างเช่น

ฟังก์ชั่นวัตถุประสงค์ที่เป็นไปได้:

• Churn — โอกาสที่ลูกค้าจะยกเลิกการสมัครสมาชิกของพวกเขาคืออะไร?
• การซื้อซ้ำแบบจ่ายต่อการดู -โอกาสที่ลูกค้าที่ซื้อสิทธิ์ใช้งานแบบจ่ายต่อการดูจะซื้ออีกครั้งคืออะไร
• การมีส่วนร่วมซ้ำของลูกค้า - ความน่าจะเป็นที่ลูกค้ามีแนวโน้มที่จะสตรีมเนื้อหาเฉพาะเจาะจงคือเท่าใด

ตารางที่ 1:ตัวอย่างสตรีมข้อมูลดิบของผู้ชมสำหรับ UFC

Endeavour ใช้ประโยชน์จากฐานข้อมูล Snowflake เพื่อจัดเก็บข้อมูลของเรา และเราเพิ่มประสิทธิภาพสูงสุดโดยใช้แบบจำลอง DBT เพื่อจัดเก็บแบบสอบถามของการรวมข้อมูลที่เกี่ยวข้อง การใช้ DBT เราสามารถสร้างชุดข้อมูลการทดสอบและการอนุมานในระดับลูกค้า (ระบุโดย customer_EXID เพื่อตอบฟังก์ชันวัตถุประสงค์ในมือ

คุณลักษณะบางอย่างที่อาจได้มาจากชุดข้อมูลเหล่านี้:

• อุปกรณ์ที่ลูกค้าใช้
• นาทีที่ลูกค้ารับชม
• ประเทศผู้ชมโดยลูกค้า
• เนื้อหาที่ลูกค้าดู
• ดูเนื้อหาการ์ดหลักใบแรก

สิ่งนี้ "ได้ผล" ขั้นตอนการจัดการข้อมูลของข้อมูลผู้ชมสำหรับสองไคลเอ็นต์สามารถสร้างเฟรมข้อมูลสองเฟรม (การทดสอบและการอนุมาน) สำหรับแต่ละฟังก์ชันวัตถุประสงค์ (3) สิ่งนี้ทำให้เรามีโมเดลที่แตกต่างกันสิบสองแบบ โดยทั้งหมดมาจากแหล่งที่คล้ายคลึงกันและให้ผลลัพธ์ที่คล้ายคลึงกัน โปรดทราบว่าคุณลักษณะบางอย่างไม่ได้ถูกใช้ในทุกรุ่น ดังนั้นสิ่งนี้จึงถูกนำมาพิจารณาโดยเฉพาะในการสร้างแบบจำลองแต่ละรายการผ่าน DBT อย่างไรก็ตาม สิ่งนี้ไม่มีประสิทธิภาพด้วยเหตุผลบางประการ:

• Feature Definition Drift — เนื่องจากคุณสมบัติเดียวกันนี้ถูกสร้างขึ้นมาใหม่สำหรับแต่ละรุ่นเหล่านี้ จึงไม่มีกลไกใดๆ ที่จะทำให้คำจำกัดความของคุณสมบัตินั้นยังคงสอดคล้องกันในรุ่นต่างๆ
• การทำซ้ำ — เมื่อมีการแนะนำไคลเอนต์ใหม่ กระบวนการสร้างแบบจำลองที่แน่นอนเหล่านี้ขึ้นใหม่สำหรับลูกค้าเหล่านั้นจะต้องทำซ้ำ
• การบำรุงรักษาแบบจำลอง — เมื่อข้อมูลเปลี่ยนแปลงหรือความลึกใหม่ของตัวแปรเป้าหมายถูกเปิดเผยเมื่อเวลาผ่านไป การเปลี่ยนแปลงที่เล็กที่สุดจะต้องดำเนินการด้วยตนเองในแบบจำลองทั้งหมดทีละรายการ

ขณะนี้เราสามารถไกล่เกลี่ยข้อกังวลข้างต้นได้โดยการรวมศูนย์การพัฒนาฟีเจอร์ไว้ในที่เดียว ฟีเจอร์ทั้งหมดไม่ว่าจะใช้ในกรณีใด จะอยู่ในที่จัดเก็บฟีเจอร์ โมเดลหนึ่งสามารถ "ตรวจสอบ" คุณลักษณะใดๆ ที่พวกเขาชอบจากร้านค้าได้ง่ายๆ โดยเข้าร่วมกับตัวระบุระดับแถว (ลูกค้า) ความสวยงามของการออกแบบนี้ไม่ได้หยุดอยู่แค่นี้ ไคลเอนต์ใด ๆ ที่เพิ่มเข้ามาต่อจากนี้จะทำตามตรรกะของรุ่นก่อน ๆ ที่ผ่านเพื่อสร้างคุณสมบัติ เนื่องจากโครงสร้างข้อมูลดิบของผู้ชมที่เข้ามาในฐานข้อมูลนั้นเหมือนกัน หากเรามี "ไคลเอ็นต์ 3" ใหม่ เราก็สามารถใช้ตรรกะเดียวกันกับไคลเอ็นต์ที่มีอยู่และสร้างคุณลักษณะเดียวกันนี้สำหรับไคลเอนต์ 3 ได้โดยใช้เวลาค่อนข้างน้อย นอกจากนี้ยังช่วยให้เราสามารถสร้างแบบจำลอง (ทดสอบและอนุมาน) สำหรับลูกค้าใหม่เหล่านี้ได้อย่างรวดเร็ว

สิ่งนี้มีประโยชน์ด้วยเหตุผลหลายประการ:

• งานด้านการพัฒนาคุณสมบัติสามารถเข้าถึงได้ง่ายโดยนักวิทยาศาสตร์ข้อมูลคนอื่นๆ
• ขณะนี้การคำนวณคุณสมบัติเป็นแบบอัตโนมัติสำหรับทุกกรณีการใช้งาน
• ชุดข้อมูลการฝึกอบรมและการอนุมานมีลักษณะการทำงานที่สอดคล้องกัน
• การจำลองแบบจำลองตามกรณีการใช้งานต่างๆ สามารถปรับขยายได้อย่างรวดเร็ว

แม้ว่าข้อมูลที่ประมวลผลจากไคลเอนต์เฉพาะที่ให้บริการโดย Endeavour Streaming จะมีอยู่ในที่จัดเก็บคุณลักษณะเดียวกัน แต่ข้อมูลจะรวมเข้าด้วยกันในการพัฒนาโมเดลได้ง่ายๆ โดยการกรองที่จัดเก็บคุณลักษณะตามไคลเอ็นต์ ในตัวอย่าง UFC โมเดลแมชชีนเลิร์นนิงสามารถพัฒนาได้หลังจาก สร้างชุดการฝึก เฉพาะของ UFC แล้วเท่านั้น จึงรับประกันได้ว่าข้อมูลข้ามไคลเอ็นต์จะไม่รั่วไหล ความปลอดภัยของข้อมูลมีอยู่ในการออกแบบและพิสูจน์แล้วว่าเป็นข้อดีอีกข้อของฟีเจอร์สโตร์ที่ Endeavour Digital

เราต้องการทำให้ตารางทั้งหมดกลายเป็นการรวมระดับแถวทั่วไป และในกรณีการใช้งานสำหรับการทำงานกับ Endeavour Streaming เราใส่ใจที่จะต้มสิ่งต่างๆ ลงไปที่ระดับลูกค้า ซึ่งแสดงCUSTOMER_EXIDโดย การรวมเวลาเริ่มต้น/เวลาสิ้นสุดของผู้ชมจะมีประโยชน์มากและคู่ควรกับตารางคุณลักษณะในร้านของเรา

WITH minutes AS (
  SELECT 
    customer_exid, 
    DATEDIFF(
      'minute', session_start, session_end
    ) AS session_length, 
    DATE(session_start) AS session_date 
  FROM 
    viewership
) 
SELECT 
  customer_exid, 
  AVG(session_length) AS avg_session_length, 
  COUNT(DISTINCT session_date) AS distinct_days_active 
FROM 
  minutes 
GROUP BY 
  customer_exid

และในทางกลับกัน เราสามารถทำเช่นเดียวกันกับความรู้ของเราว่าพวกเขาใช้อุปกรณ์ใดในการสตรีม

SELECT 
  customer_exid, 
  MODE(device) AS most_used_device 
FROM 
  viewership 
GROUP BY 
  customer_exid

เนื่องจากสตรีมข้อมูลของ Endeavour Streaming มีความสอดคล้องกันในโครงสร้าง เราจึงสามารถใช้ตารางคุณลักษณะเหล่านี้ในการคำนวณคุณลักษณะเหล่านี้โดยอัตโนมัติเมื่อสร้างขึ้น

ด้วย Churn เราสามารถมีรายการของลูกค้าในอดีตบางส่วน (แสดงเป็นCUSTOMER_EXID) รวมทั้งตัวระบุด้วยว่าพวกเขาเลิกใช้งานหรือยกเลิกการสมัครหรือไม่ (พวกเขากำลังใช้งานอยู่)

ตารางที่ 4:ตารางสถานะการเลิกใช้งานของลูกค้า (churn_status)

เป้าหมายของเราในฟังก์ชันวัตถุประสงค์นี้คือการค้นหาตัวทำนายคุณภาพที่สามารถจำแนกสถานะของลูกค้าว่าใช้งานอยู่หรือหมดอายุได้ดีที่สุด แม้ว่าเวทมนตร์ส่วนนี้จะเกิดขึ้นในการเรียนรู้ของเครื่องจริง แต่เราต้องสร้างชุดข้อมูล แต่ข้อดีของฟีเจอร์สโตร์คือเราสามารถสร้างชุดข้อมูลเพื่อฝึกตามตารางที่เรามีอยู่แล้วได้อย่างรวดเร็ว เราไม่จำเป็นต้องสร้างแบบสอบถามที่ซับซ้อนเพื่อสร้างตารางนี้ แต่เราเพียงแค่ต้องรวมคุณสมบัติทั้งหมดที่เราต้องการเข้าด้วยกัน

SELECT 
  A.customer_exid, 
  A.status, 
  COALESCE(B.avg_session_length, 0) AS avg_session_length COALESCE(B.distinct_days_active, 0) AS distinct_days_active, 
  COALESCE(C.most_used_device, 'Invalid') AS most_used_device 
FROM 
  churn_status A 
  LEFT JOIN feature_minutes B ON A.customer_exid = B.customer_exid 
  LEFT JOIN feature_devices C ON A.customer_exid = C.customer_exid

อย่างที่คุณเห็น ตอนนี้เรามีชุดข้อมูลที่เราสามารถคาดการณ์statusได้โดยใช้คุณสมบัติทั้งหมดของฉันเป็นตัวทำนายที่CUSTOMER_EXID ระดับ นอกจากนี้ คุณยังอาจสังเกตเห็นสิ่งที่สำคัญที่นี่: ไม่ใช่ลูกค้าทั้งหมดที่จะปรากฏในตารางคุณลักษณะแต่ละตารางของคุณ ลูกค้าที่มีบัญชีแต่ไม่เคยดูเนื้อหาใด ๆ จะไม่ปรากฏในviewershipตารางหรือตารางคุณลักษณะใด ๆ ที่มาจากเนื้อหานั้น ด้วยเหตุนี้ คุณต้องการให้แน่ใจว่าคุณได้เพิ่มCOALESCE()การรวมส่วนใหญ่หรือทั้งหมดของคุณลงในบัญชีสำหรับค่า Null เหล่านี้

หากนักวิทยาศาสตร์ด้านข้อมูลรายอื่นต้องการทำนายความเป็นไปได้ที่ลูกค้าที่ซื้อสิทธิ์การใช้งานแบบจ่ายต่อการดูจะซื้ออีกครั้ง พวกเขาสามารถตรวจสอบคุณสมบัติที่สร้างขึ้นแล้วในกรณีการใช้งานการเลิกใช้งานสำหรับฟังก์ชันวัตถุประสงค์ของพวกเขา ซึ่งช่วยลดเวลาในการพัฒนาโมเดลได้อย่างมาก และรับประกันว่าคำจำกัดความของฟีเจอร์จะเหมือนกันในโมเดลต่างๆ นอกจากนี้ เมื่อถึงเวลาผลิตแบบจำลองของคุณ คุณสามารถดึงข้อมูลจากที่เก็บคุณลักษณะอีกครั้งเมื่อสร้างชุดการอนุมานของคุณ ในการใช้ฟีเจอร์สโตร์ คุณจะเพิ่มประสิทธิภาพการพัฒนาการฝึกอบรม ML และสร้างระบบนิเวศที่แข็งแกร่งสำหรับทีมวิทยาศาสตร์ข้อมูลของคุณเพื่อขับเคลื่อนทั้งอย่างมีประสิทธิภาพและประสิทธิผล

ต้องการสนทนาเพิ่มเติมเกี่ยวกับข้อมูลกับผู้เขียนหรือไม่ ติดต่อ John Thomas โดยตรงทางLinkedIn !