กฎของแมชชีนเลิร์นนิง

แนวทางปฏิบัติแนะนำสำหรับวิศวกรรม ML

มาร์ติน ซินเควิช

เอกสารนี้จัดทำขึ้นเพื่อช่วยให้ผู้ที่มีความรู้พื้นฐานเกี่ยวกับแมชชีนเลิร์นนิงได้รับประโยชน์จากแนวทางปฏิบัติแนะนำของ Google ในแมชชีนเลิร์นนิง โดยนำเสนอรูปแบบสำหรับแมชชีนเลิร์นนิง คล้ายกับคู่มือสไตล์ C++ ของ Google และคำแนะนำยอดนิยมอื่นๆ สำหรับการเขียนโปรแกรมเชิงปฏิบัติ หากคุณเคยเข้าร่วมชั้นเรียนเกี่ยวกับแมชชีนเลิร์นนิง หรือสร้างหรือทำงานบนโมเดลแมชชีนเลิร์นนิง คุณก็มีภูมิหลังที่จำเป็นในการอ่านเอกสารนี้แล้ว

Martin Zinkevich แนะนำกฎ 10 ข้อที่เขาชื่นชอบเกี่ยวกับแมชชีนเลิร์นนิง อ่านต่อเพื่อเรียนรู้กฎทั้ง 43 ข้อ

คำศัพท์

คำศัพท์ต่อไปนี้จะปรากฏซ้ำๆ ในการพูดคุยเรื่องแมชชีนเลิร์นนิงที่มีประสิทธิภาพ

• อินสแตนซ์: สิ่งที่คุณต้องการคาดการณ์ เช่น อินสแตนซ์นี้อาจเป็นหน้าเว็บที่คุณต้องการจัดประเภทเป็น "เกี่ยวกับแมว" หรือ "ไม่เกี่ยวกับแมว"
• ป้ายกำกับ: คำตอบสำหรับงานคาดคะเนที่เป็นคำตอบที่สร้างจากระบบแมชชีนเลิร์นนิงหรือคำตอบที่ถูกต้องในข้อมูลการฝึก เช่น ป้ายกำกับของหน้าเว็บอาจเป็น "เกี่ยวกับแมว"
• ฟีเจอร์: พร็อพเพอร์ตี้ของอินสแตนซ์ที่ใช้ในงานการคาดการณ์ ตัวอย่างเช่น หน้าเว็บอาจมีฟีเจอร์ "มีคำว่า 'แมว'"
• คอลัมน์ฟีเจอร์: ชุดของฟีเจอร์ที่เกี่ยวข้อง เช่น ชุดประเทศที่เป็นไปได้ทั้งหมดที่ผู้ใช้อาจอาศัยอยู่ ตัวอย่างอาจมีคุณลักษณะ อย่างน้อย 1 รายการในคอลัมน์คุณลักษณะ "คอลัมน์ฟีเจอร์" คือคำศัพท์เฉพาะของ Google คอลัมน์ฟีเจอร์จะเรียกว่า "เนมสเปซ" ในระบบของ VW (ที่ Yahoo/Microsoft) หรือช่อง
• ตัวอย่าง: อินสแตนซ์ (ที่มีฟีเจอร์) และป้ายกำกับ
• โมเดล: การแสดงทางสถิติของงานการคาดคะเน คุณฝึกโมเดลกับตัวอย่าง แล้วใช้โมเดลในการคาดการณ์
• เมตริก: ตัวเลขที่คุณสนใจ อาจเพิ่มประสิทธิภาพโดยตรงหรือไม่ก็ได้
• วัตถุประสงค์: เมตริกที่อัลกอริทึมพยายามเพิ่มประสิทธิภาพ
• ไปป์ไลน์: โครงสร้างพื้นฐานรอบอัลกอริทึมแมชชีนเลิร์นนิง รวมถึงการรวบรวมข้อมูลจากส่วนหน้า การนำเข้าสู่ไฟล์ข้อมูลการฝึก การฝึกโมเดลอย่างน้อย 1 รายการ และการส่งออกโมเดลไปยังเวอร์ชันที่ใช้งานจริง
• อัตราการคลิกผ่าน เปอร์เซ็นต์ของผู้เข้าชมหน้าเว็บที่คลิกลิงก์ในโฆษณา

ภาพรวม

วิธีสร้างผลิตภัณฑ์ที่ยอดเยี่ยม

แมชชีนเลิร์นนิงแบบที่คุณเป็นวิศวกรที่ยอดเยี่ยม ไม่ใช่ผู้เชี่ยวชาญแมชชีนเลิร์นนิงที่ดียิ่งกว่าที่คุณไม่ใช่

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

1. ตรวจสอบว่าไปป์ไลน์เป็นเส้นตรงตั้งแต่ต้นจนจบ
2. เริ่มต้นโดยมีวัตถุประสงค์ที่สมเหตุสมผล
3. เพิ่มฟีเจอร์ทั่วไปได้ง่ายๆ
4. ตรวจดูว่าไปป์ไลน์นั้นมั่นคงดี

วิธีนี้จะทำงานได้ดี เป็นเวลานาน แยกออกจากวิธีการนี้ก็ต่อเมื่อไม่มีเคล็ดลับ ง่ายๆ ที่จะทำให้คุณได้ไกลกว่านี้ การเพิ่มความซับซ้อนจะทำให้การเผยแพร่ในอนาคตช้าลง

เมื่อใช้เคล็ดลับง่ายๆ หมดแล้ว แมชชีนเลิร์นนิงที่ล้ำสมัยอาจเป็นในอนาคตของคุณ โปรดดูในส่วนเกี่ยวกับโปรเจ็กต์แมชชีนเลิร์นนิงระยะที่ 3

เอกสารนี้มีการจัดเรียงตามดังต่อไปนี้:

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

ก่อนแมชชีนเลิร์นนิง

กฎข้อ 1: อย่ากลัวที่จะเปิดตัวผลิตภัณฑ์โดยไม่ใช้แมชชีนเลิร์นนิง

แมชชีนเลิร์นนิงเป็นสิ่งที่ดีก็จริง แต่ก็ต้องใช้ข้อมูลด้วย ในทางทฤษฎี คุณอาจนำข้อมูลจากปัญหาอื่นมาปรับแต่งโมเดลสำหรับผลิตภัณฑ์ใหม่ แต่วิธีนี้อาจทำให้heuristicsพื้นฐานทำงานได้ไม่ดีนัก ถ้าคุณคิดว่าแมชชีนเลิร์นนิงจะช่วยเพิ่มประสิทธิภาพ 100% การเรียนรู้ของการเรียนรู้จะช่วยให้คุณไปถึงจุดนั้นได้ 50%

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

กฎข้อ 2: ขั้นตอนแรก ออกแบบและปรับใช้เมตริก

ก่อนจะแก้ไขสิ่งที่ระบบแมชชีนเลิร์นนิงจะดำเนินการอย่างเป็นทางการ ให้ติดตามมากที่สุดเท่าที่ทำได้ในระบบปัจจุบันของคุณ เนื่องจากเหตุผลต่อไปนี้

1. ซึ่งจะง่ายกว่าการขออนุญาตจากผู้ใช้ของระบบตั้งแต่เนิ่นๆ
2. หากคุณคิดว่ามีบางอย่างเป็นปัญหาในอนาคต เราขอแนะนำให้ดูข้อมูลประวัติตอนนี้
3. หากคุณออกแบบระบบโดยคำนึงถึงการใช้เครื่องมือเมตริกเป็นหลัก สิ่งต่างๆ จะดีขึ้นสำหรับคุณในอนาคต โดยเฉพาะอย่างยิ่ง คุณคงไม่อยากคิดว่าตัวเองกำลังยุ่งเหยิง ในบันทึกเพื่อนำมาใช้กับเมตริกของคุณ
4. คุณจะเห็นสิ่งที่เปลี่ยนแปลงและสิ่งที่คงเดิม เช่น สมมติว่าคุณต้องการเพิ่มประสิทธิภาพผู้ใช้ที่ใช้งานอยู่ใน 1 วันโดยตรง อย่างไรก็ตาม ในระหว่างที่มีการปรับเปลี่ยนระบบในช่วงแรก คุณอาจสังเกตเห็นว่าการเปลี่ยนแปลงประสบการณ์ของผู้ใช้อย่างเห็นได้ชัดไม่ได้เปลี่ยนแปลงเมตริกนี้อย่างเห็นได้ชัด

ทีม Google Plus จะวัดผลต่อการอ่าน แชร์ต่ออ่าน บวก 1 ครั้งต่อการอ่าน ความคิดเห็น/การอ่าน ความคิดเห็นต่อผู้ใช้ การแชร์ต่อของผู้ใช้ เป็นต้น ซึ่งทีมจะนำไปใช้ในการคำนวณประโยชน์ของโพสต์ขณะแสดง นอกจากนี้ โปรดทราบว่าเฟรมเวิร์กการทดสอบซึ่งคุณสามารถจัดกลุ่มผู้ใช้ลงในที่เก็บข้อมูลและสถิติรวมตามการทดสอบมีความสำคัญ ดูกฎข้อที่ 12

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

กฎข้อ 3: เลือกแมชชีนเลิร์นนิงแทนการเรียนรู้ที่ซับซ้อน

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

ML Phase I: ไปป์ไลน์แรกของคุณ

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

กฎข้อ 4: ทำให้รูปแบบแรกเรียบง่ายเสมอและใช้โครงสร้างพื้นฐานที่เหมาะสม

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

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

การเลือกฟีเจอร์พื้นฐานช่วยให้มั่นใจได้ว่า

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

เมื่อคุณมีระบบที่สามารถดำเนินการ 3 สิ่งนี้ได้อย่างน่าเชื่อถือ คุณก็ทำงานส่วนใหญ่ไป โมเดลแบบง่ายจะแสดงเมตริกพื้นฐานและลักษณะการทำงานของเกณฑ์พื้นฐานซึ่งใช้เพื่อทดสอบโมเดลที่ซับซ้อนยิ่งขึ้นได้ บางทีมตั้งเป้าไปที่การเปิดตัวครั้งแรกแบบ "เป็นกลาง" ซึ่งเป็นการเปิดตัวครั้งแรกที่ลดลำดับความสำคัญของแมชชีนเลิร์นนิงที่ได้รับอย่างชัดเจน เพื่อหลีกเลี่ยงการเสียสมาธิ

กฎข้อ 5: ทดสอบโครงสร้างพื้นฐานอย่างอิสระจากแมชชีนเลิร์นนิง

ต้องแน่ใจว่าโครงสร้างพื้นฐานสามารถทดสอบได้และห่อหุ้มส่วนการเรียนรู้ของระบบเพื่อให้ทดสอบทุกอย่างรอบตัวได้ กล่าวอย่างเจาะจงคือ

1. ทดสอบการดึงข้อมูลลงในอัลกอริทึม ตรวจสอบว่าคอลัมน์ฟีเจอร์ที่ควรเติมข้อมูล ตรวจสอบอินพุตอัลกอริทึมการฝึกด้วยตนเองหากความเป็นส่วนตัวเอื้ออำนวย หากเป็นไปได้ ให้ตรวจสอบสถิติในไปป์ไลน์เทียบกับสถิติสำหรับข้อมูลเดียวกันที่ประมวลผลจากที่อื่น
2. ทดสอบการนำโมเดลออกจากอัลกอริทึมการฝึก ตรวจสอบว่าโมเดลในสภาพแวดล้อมการฝึกให้คะแนนเท่ากับโมเดลในสภาพแวดล้อมการแสดงโฆษณา (ดูกฎ #37)

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

กฎข้อ 6: โปรดระวังข้อมูลที่ตกหล่นเมื่อคัดลอกไปป์ไลน์

บ่อยครั้งที่เราสร้างไปป์ไลน์โดยการคัดลอกไปป์ไลน์ที่มีอยู่ (เช่น การเขียนโปรแกรมลัทธิสินค้า) และไปป์ไลน์แบบเก่าปล่อยข้อมูลที่เราต้องการสำหรับไปป์ไลน์ใหม่ เช่น ไปป์ไลน์สำหรับ Google Plus เรื่อง "กำลังฮอต" จะนำโพสต์เก่าๆ (เนื่องจากพยายามจัดอันดับโพสต์ใหม่) มีการคัดลอกไปป์ไลน์นี้เพื่อใช้กับสตรีม Google Plus ซึ่งโพสต์เก่าๆ ยังคงมีความสำคัญ แต่ไปป์ไลน์ยังคงนำโพสต์เก่าออกไป อีกรูปแบบหนึ่งที่ใช้บ่อยคือการบันทึกเฉพาะข้อมูลที่ผู้ใช้เห็น ดังนั้น ข้อมูลนี้จึงไร้ประโยชน์หากเราต้องการประมาณว่าเพราะเหตุใดผู้ใช้จึงไม่เห็นโพสต์ใดโพสต์หนึ่ง เพราะตัวอย่างเชิงลบทั้งหมดถูกลบออกไป ก็เกิดปัญหาที่คล้ายกันใน Play ขณะทำงานใน Play Apps Home มีการสร้างไปป์ไลน์ใหม่พร้อมตัวอย่างจากหน้า Landing Page ของ Play Games โดยไม่มีฟีเจอร์ที่จะชี้แจงที่มาของตัวอย่างแต่ละรายการ

กฎข้อ 7: เปลี่ยนการศึกษาสำนึกเป็นฟีเจอร์หรือจัดการจากภายนอก

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

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

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

Monitoring

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

กฎข้อ 8: รู้ข้อกำหนดเกี่ยวกับความใหม่ของระบบ

ประสิทธิภาพจะลดลงเท่าใดหากคุณมีโมเดลที่มีอายุ 1 วัน 1 สัปดาห์ ดีไหม อายุ 14 ปีแล้วนะ ข้อมูลนี้จะช่วยให้คุณเข้าใจลำดับความสำคัญของการตรวจสอบ หากคุณสูญเสียคุณภาพของผลิตภัณฑ์ที่สำคัญหากโมเดลไม่ได้รับการอัปเดตเป็นเวลา 1 วัน ก็ควรมีวิศวกรติดตามดูโมเดลอย่างต่อเนื่อง ระบบการแสดงโฆษณาส่วนใหญ่มีโฆษณาใหม่ให้จัดการทุกวัน และต้องอัปเดตทุกวัน ตัวอย่างเช่น หากไม่อัปเดตโมเดล ML สำหรับ Google Play Search อาจส่งผลในแง่ลบภายในเวลาไม่ถึง 1 เดือน สิ่งที่กำลังมาแรงใน Google Plus บางรุ่นจะไม่มีตัวระบุโพสต์ในโมเดล ทำให้ส่งออกโมเดลเหล่านี้ได้ไม่บ่อยนัก โมเดลอื่นๆ ที่มีตัวระบุโพสต์จะได้รับการอัปเดตบ่อยกว่า นอกจากนี้ โปรดสังเกตว่าความใหม่อาจเปลี่ยนแปลงเมื่อเวลาผ่านไป โดยเฉพาะเมื่อมีการเพิ่มหรือนำคอลัมน์ฟีเจอร์ออกจากโมเดล

กฎข้อที่ 9: ตรวจหาปัญหาก่อนส่งออกโมเดล

ระบบแมชชีนเลิร์นนิงจำนวนมากมีระยะที่คุณส่งออกโมเดลไปยังการแสดงผลได้ หากโมเดลที่ส่งออกมีปัญหา นั่นเป็นปัญหาที่แสดงต่อผู้ใช้

โปรดตรวจสอบความถูกต้องก่อนส่งออกโมเดล โดยเฉพาะอย่างยิ่ง ให้ตรวจสอบว่าประสิทธิภาพของโมเดลมีความสมเหตุสมผลเมื่อข้อมูลถูกระงับ หรือหากยังมีข้อกังวลเกี่ยวกับข้อมูล โปรดอย่าส่งออกโมเดล หลายๆ ทีมที่ติดตั้งใช้งานโมเดลอย่างต่อเนื่องจะตรวจสอบพื้นที่ใต้เส้นโค้ง ROC (หรือ AUC) ก่อนส่งออก ปัญหาเกี่ยวกับโมเดลที่ไม่ได้ส่งออกจำเป็นต้องมีการแจ้งเตือนทางอีเมล แต่สำหรับโมเดลที่แสดงต่อผู้ใช้อาจต้องมีหน้าเว็บ ดังนั้นจึงควรรอและแน่ใจก่อน ว่าจะส่งผลกระทบต่อผู้ใช้

กฎข้อ 10: ตรวจหาข้อผิดพลาดที่ไม่มีเสียง

ปัญหานี้เกิดขึ้นกับระบบแมชชีนเลิร์นนิงมากกว่าระบบประเภทอื่นๆ สมมติว่าไม่มีการอัปเดตตารางหนึ่งๆ ที่จะผนวกไว้อีกต่อไป ระบบแมชชีนเลิร์นนิงจะปรับตามสถานการณ์ และการใช้งานจะดีขึ้นเรื่อยๆ ทีละน้อย บางครั้งคุณเห็นตารางที่ล้าสมัยแล้วหลายเดือน และการปรับปรุงง่ายๆ ช่วยปรับปรุงประสิทธิภาพได้มากกว่าการเปิดตัวอื่นๆ ในไตรมาสนั้น! การครอบคลุมของฟีเจอร์อาจมีการเปลี่ยนแปลงเนื่องจากการติดตั้งใช้งาน เช่น ระบบสามารถป้อนข้อมูลคอลัมน์ฟีเจอร์ในตัวอย่าง 90% แล้วก็มีตัวอย่างลดลงเหลือ 60% กะทันหัน ครั้งหนึ่ง Play เคยมีตารางที่ไม่มีการอัปเดตมาเป็นเวลา 6 เดือน และการรีเฟรชตารางเพียงอย่างเดียวช่วยเพิ่มอัตราการติดตั้งได้ 2% หากคุณติดตามสถิติของข้อมูล รวมถึงตรวจสอบข้อมูลด้วยตนเองเป็นครั้งคราว คุณจะลดความล้มเหลวเหล่านี้ได้

กฎ #11: ระบุเจ้าของคอลัมน์ฟีเจอร์และเอกสารประกอบ

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

วัตถุประสงค์ข้อแรก

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

กฎข้อ 12: อย่าคิดมากว่าวัตถุประสงค์ใดที่คุณเลือกเพิ่มประสิทธิภาพโดยตรง

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

ดังนั้น อย่าคิดมากจนเกินไปที่จะหาสมดุลให้กับเมตริกต่างๆ ในเมื่อคุณสามารถเพิ่มเมตริกทั้งหมดได้ง่ายๆ อย่าใช้กฎนี้มากเกินไป อย่าสับสนระหว่างวัตถุประสงค์กับประสิทธิภาพสูงสุดของระบบ (ดูกฎข้อที่ 39) และหากพบว่าตนเองเพิ่มเมตริกที่เพิ่มประสิทธิภาพโดยตรงแล้ว แต่ตัดสินใจไม่เปิดใช้ คุณอาจต้องแก้ไขตามจุดประสงค์บางอย่าง

กฎข้อ 13: เลือกเมตริกที่เรียบง่าย สังเกตได้ และระบุที่มาได้สำหรับวัตถุประสงค์แรกของคุณ

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

สิ่งที่ง่ายที่สุดในการจำลองคือพฤติกรรมของผู้ใช้ที่สังเกตได้โดยตรงและเป็นผลมาจากการทำงานของระบบ ดังนี้

• ผู้ใช้คลิกลิงก์การจัดอันดับนี้หรือไม่
• มีการดาวน์โหลดวัตถุอันดับนี้ไหม
• มีการส่งต่อ/ตอบกลับ/ส่งอีเมลออบเจ็กต์การจัดอันดับนี้ไหม
• มีการจัดประเภทวัตถุนี้ไหม
• วัตถุที่แสดงนี้ถูกทำเครื่องหมายว่าเป็นสแปม/สื่อลามก/ไม่เหมาะสมหรือไม่

หลีกเลี่ยงการประมาณผลกระทบทางอ้อมในตอนแรก โดยทำดังนี้

• ผู้ใช้เข้าชมในวันถัดไปหรือไม่
• ผู้ใช้เข้าชมเว็บไซต์นานเท่าใด
• ผู้ใช้ที่ใช้งานอยู่รายวันคือเท่าใด

ผลลัพธ์ทางอ้อมสร้างเมตริกที่ยอดเยี่ยม และสามารถใช้ระหว่างการทดสอบ A/B และระหว่างการตัดสินใจเปิดตัว

สุดท้าย อย่าพยายามให้แมชชีนเลิร์นนิงคำนวณสิ่งต่อไปนี้

• ผู้ใช้พึงพอใจกับการใช้ผลิตภัณฑ์ไหม
• ผู้ใช้พึงพอใจกับประสบการณ์ไหม
• ผลิตภัณฑ์ช่วยปรับปรุงคุณภาพชีวิตโดยรวมของผู้ใช้หรือไม่
• การเปลี่ยนแปลงนี้จะส่งผลต่อประสิทธิภาพโดยรวมของบริษัทอย่างไร

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

กฎข้อ 14: การเริ่มต้นด้วยโมเดลที่ตีความได้จะทำให้แก้ไขข้อบกพร่องได้ง่ายขึ้น

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

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

โมเดลที่เรียบง่ายจะทำให้จัดการกับลูปความคิดเห็นได้ง่ายขึ้น (ดูกฎข้อที่ 36) บ่อยครั้งเราใช้การคาดการณ์ความน่าจะเป็นเหล่านี้เพื่อตัดสินใจ เช่น จัดอันดับโพสต์ในการลดมูลค่าที่คาดไว้ (เช่น ความน่าจะเป็นของการคลิก/ดาวน์โหลด/ฯลฯ) แต่อย่าลืมว่าเมื่อถึงเวลาที่ควรเลือกรูปแบบที่จะใช้ การตัดสินใจมีความสำคัญมากกว่าแนวโน้มของข้อมูลที่จะได้รับรูปแบบนั้นๆ (ดูกฎข้อที่ 27)

กฎ #15: แยกการกรองสแปมและการจัดอันดับคุณภาพในชั้นนโยบาย

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

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

ML ระยะที่ 2: วิศวกรรมฟีเจอร์

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

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

กฎข้อที่ 16: วางแผนเปิดตัวและทำซ้ำ

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

• คุณกำลังพบกับฟีเจอร์ใหม่
• คุณกำลังปรับรูปแบบให้เป็นมาตรฐานและรวมฟีเจอร์เก่าๆ ในรูปแบบใหม่เข้าด้วยกัน
• คุณกำลังปรับแต่งวัตถุประสงค์

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

กฎข้อ 17: เริ่มต้นจากฟีเจอร์ที่สังเกตได้โดยตรงและการรายงาน แทนที่จะเป็นฟีเจอร์ที่เรียนรู้

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

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

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

กฎข้อที่ 18: สำรวจเนื้อหาต่างๆ ที่อธิบายบริบทต่างๆ อย่างทั่วถึง

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

กฎข้อ 19: ใช้ฟีเจอร์ที่เฉพาะเจาะจงมากๆ เมื่อทำได้

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

กฎข้อที่ 20: รวมและแก้ไขสถานที่ที่มีอยู่เพื่อสร้างฟีเจอร์ใหม่ในรูปแบบที่มนุษย์เข้าใจได้

คุณสามารถรวมและแก้ไขสถานที่ได้หลายวิธี ระบบแมชชีนเลิร์นนิง เช่น TensorFlow ช่วยให้คุณประมวลผลข้อมูลล่วงหน้าผ่านการเปลี่ยนรูปแบบได้ วิธีที่เป็นมาตรฐานสูงสุด 2 วิธีคือ "การพิจารณาอย่างรอบคอบ" และ "การกากบาท"

การเลือกปฏิบัติประกอบด้วยการนำฟีเจอร์อย่างต่อเนื่องและสร้างฟีเจอร์ที่โดดเด่นมากมายจากฟีเจอร์ดังกล่าว พิจารณาฟีเจอร์ที่ต่อเนื่อง เช่น อายุ คุณอาจสร้างฟีเจอร์ที่ 1 รายการเมื่ออายุน้อยกว่า 18 ปี และอีกฟีเจอร์หนึ่งได้คือ 1 รายการเมื่ออายุอยู่ระหว่าง 18 ถึง 35 ปี เป็นต้น อย่าคิดมากกับขอบเขตของฮิสโตแกรมเหล่านี้ ควอนไทล์พื้นฐานจะให้ผลกระทบส่วนใหญ่แก่คุณ

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

เครื่องหมายกากบาทที่สร้างคอลัมน์ฟีเจอร์ขนาดใหญ่มากอาจมากเกินไป ตัวอย่างเช่น สมมติว่าคุณกำลังค้นหา และคุณมีคอลัมน์ฟีเจอร์ที่มีคำในข้อความค้นหา และคุณมีคอลัมน์ฟีเจอร์พร้อมด้วยคำในเอกสาร คุณรวมเมนูเหล่านี้กับเครื่องหมายกากบาทได้ แต่จะต้องใช้ฟีเจอร์ต่างๆ เป็นจำนวนมาก (ดูกฎข้อที่ 21)

เมื่อใช้ข้อความจะมีทางเลือก 2 ทางด้วยกัน สิ่งที่สุ่มเสี่ยงที่สุดคือ ผลิตภัณฑ์ Dot ดอทผลิตภัณฑ์ในรูปแบบที่ง่ายที่สุดจะนับจำนวนคำที่มีร่วมกันระหว่างข้อความค้นหาและเอกสาร จากนั้น คุณลักษณะ อาจถูกพิจารณาอย่างรอบคอบ อีกวิธีการหนึ่งคือสี่แยก นั่นคือเราจะมีฟีเจอร์หนึ่งก็ต่อเมื่อมีคำว่า "ม้าแคระ" อยู่ในทั้งเอกสารและคำค้นหา ส่วนอีกฟีเจอร์หนึ่งจะปรากฏก็ต่อเมื่อคำว่า "the" อยู่ในทั้งเอกสารและคำค้นหาเท่านั้น

กฎ #21: จำนวนน้ำหนักของจุดสนใจที่คุณสามารถเรียนรู้ได้ในรูปแบบเชิงเส้นจะเป็นสัดส่วนโดยประมาณกับปริมาณข้อมูลที่คุณมี

มีผลลัพธ์ของทฤษฎีการเรียนรู้ทางสถิติที่น่าสนใจเกี่ยวกับระดับความซับซ้อนที่เหมาะสมสำหรับโมเดล แต่กฎข้อนี้เป็นเพียงสิ่งที่คุณจำเป็นต้องทราบ ผมเคยมีการสนทนาที่ผู้คนสงสัยในสิ่งที่สามารถเรียนรู้ได้จากตัวอย่าง 1,000 อย่าง หรือคุณอาจต้องการยกตัวอย่างมากกว่า 1 ล้านตัวอย่างเลย เนื่องจากพวกเขาติดอยู่กับวิธีการเรียนรู้อย่างใดอย่างหนึ่ง กุญแจสำคัญคือการปรับขนาดการเรียนรู้ตามขนาดของข้อมูล

1. หากคุณกำลังทำงานในระบบการจัดอันดับการค้นหา และมีคำต่างๆ หลายล้านคำในเอกสารและข้อความค้นหา และคุณมีตัวอย่างที่ติดป้ายกำกับไว้ 1,000 ตัวอย่าง คุณควรใช้ผลิตภัณฑ์จุดระหว่างคุณลักษณะเอกสาร และการค้นหา TF-IDF และคุณลักษณะอื่นๆ ที่มนุษย์สร้างขึ้นอย่างหนักอีกครึ่งหนึ่ง ตัวอย่าง 1, 000 รายการ ฟีเจอร์หลายสิบรายการ
2. หากคุณมีตัวอย่างเป็นล้านตัวอย่าง ให้ผสานคอลัมน์ฟีเจอร์เอกสารและคำค้นหาเข้าด้วยกัน โดยใช้การกำหนดกฎอาจทำการเลือกฟีเจอร์ได้ คุณจะได้รับฟีเจอร์หลายล้านรายการ แต่เมื่อคุณทำอย่างสม่ำเสมอ คุณก็จะมีฟีเจอร์ต่างๆ น้อยลง ตัวอย่าง 10 ล้านตัวอย่าง หรืออาจจะ 100, 000 ฟีเจอร์
3. หากคุณมีตัวอย่างหลายพันล้านตัวอย่างหรือหลายแสนตัวอย่าง คุณสามารถข้ามคอลัมน์ฟีเจอร์กับโทเค็นเอกสารและการค้นหาได้โดยใช้การเลือกและการกำหนดฟีเจอร์ คุณจะมีตัวอย่าง 1, 000 ล้านรายการ และ 10 ล้านฟีเจอร์ ทฤษฎีการเรียนรู้เชิงสถิติมักจะไม่มีขอบเขตจำกัด แต่ให้แนวทางที่ดีสำหรับจุดเริ่มต้น

สุดท้าย ให้ใช้กฎข้อที่ 28 เพื่อเลือกฟีเจอร์ที่จะใช้

กฎข้อ 22: ล้างข้อมูลฟีเจอร์ที่คุณไม่ได้ใช้แล้ว

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

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

ในขณะเดียวกัน บางฟีเจอร์อาจแย่งน้ำหนักไปได้มาก ตัวอย่างเช่น หากคุณมีฟีเจอร์ที่ครอบคลุมข้อมูลเพียง 1% แต่ตัวอย่างที่มีฟีเจอร์ดังกล่าว 90% เป็นบวก เราก็จะเพิ่มฟีเจอร์นั้นเข้ามาที่ยอดเยี่ยม

การวิเคราะห์ระบบจากมนุษย์

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

กฎข้อที่ 23: คุณไม่ใช่ผู้ใช้ปลายทางทั่วไป

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

มีเหตุผลสองประการ อย่างแรกคือคุณอยู่ใกล้โค้ดมากเกินไป คุณอาจกำลังมองหาแง่มุมเฉพาะของโพสต์ หรือคุณแสดงตัวมากเกินไป (เช่น อคติยืนยัน) ประการที่สองคือ เวลาของคุณมีค่ามากเกินไป ลองนึกถึงต้นทุนของวิศวกร 9 คนในการประชุม 1 ชั่วโมง และลองนึกถึงจำนวนค่ายเพลงที่ทำสัญญาจ้างซื้อบนแพลตฟอร์มการรวบรวมข้อมูลจากมวลชน

หากคุณต้องการความคิดเห็นจากผู้ใช้จริงๆ ให้ใช้วิธีการประสบการณ์ของผู้ใช้ สร้างลักษณะตัวตนของผู้ใช้ (มีคำอธิบาย 1 รายการอยู่ใน Bill Buxton Sketching User Experiences) ในช่วงต้นของกระบวนการและทำการทดสอบความสามารถในการใช้งาน (มีคำอธิบาย 1 รายการอยู่ใน Don’t Make Me Think ของ Steve Krug) ในภายหลัง ลักษณะตัวตนของผู้ใช้ เกี่ยวข้องกับการสร้างผู้ใช้สมมติ ตัวอย่างเช่น ถ้าทีมของคุณเป็นผู้ชายทุกคน การออกแบบลักษณะตัวตนของผู้ใช้เพศหญิงอายุ 35 ปี (ประกอบไปด้วยฟีเจอร์ของผู้ใช้ครบถ้วน) และดูผลลัพธ์ที่สร้างขึ้นแทนผลลัพธ์ 10 รายการสำหรับผู้ชายอายุ 25-40 ปี การเปิดโอกาสให้ผู้ใช้ดูปฏิกิริยาของตนกับเว็บไซต์ของคุณ (ในเครื่องหรือจากระยะไกล) ในการทดสอบความสามารถในการใช้งานยังช่วยให้คุณเห็นมุมมองใหม่ๆ ได้เช่นกัน

กฎ #24: วัดเดลต้าระหว่างโมเดล

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

กฎข้อ 25: เมื่อเลือกรูปแบบ ประสิทธิภาพในทางประโยชน์จะมีอำนาจเหนือการคาดการณ์

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

กฎ #26: มองหารูปแบบของข้อผิดพลาดที่วัดได้ แล้วสร้างฟีเจอร์ใหม่

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

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

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

กฎข้อที่ 27: พยายามระบุพฤติกรรมที่ไม่พึงประสงค์ที่สังเกตได้

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

กฎ #28: โปรดทราบว่าพฤติกรรมระยะสั้นที่เหมือนกันไม่ได้หมายถึงพฤติกรรมระยะยาวที่เหมือนกัน

ลองนึกภาพว่าคุณมีระบบใหม่ที่ตรวจสอบ doc_id และexact_query ทุกรายการ จากนั้นจะคำนวณความน่าจะเป็นของการคลิกสำหรับเอกสารทุกฉบับสำหรับทุกคำค้นหา คุณพบว่าลักษณะการทำงานของวิธีนี้แทบจะเหมือนกันกับระบบปัจจุบันของคุณทั้งในแบบคู่ขนานและการทดสอบ A/B ด้วยเหตุนี้ คุณจึงเปิดตัวฟีเจอร์นี้ด้วยความเรียบง่าย แต่คุณจะสังเกตเห็นว่าไม่มีแอปใหม่ที่แสดง เหตุผล เนื่องจากระบบของคุณแสดงเอกสารตามประวัติของการค้นหานั้นเท่านั้น จึงไม่มีวิธีที่จะเรียนรู้ได้ว่าควรแสดงเอกสารใหม่

วิธีเดียวที่จะทำความเข้าใจว่าระบบดังกล่าวจะทำงานได้ดีเพียงใดในระยะยาวคือ ระบบจะฝึกเฉพาะข้อมูลที่ได้มาเมื่อโมเดลเผยแพร่เท่านั้น เรื่องนี้ยากมาก

เบ้ขณะฝึก

ความคลาดเคลื่อนระหว่างการฝึกแสดงคือความแตกต่างระหว่างประสิทธิภาพในระหว่างการฝึกกับประสิทธิภาพระหว่างการแสดงผล ซึ่งอาจเกิดจากสาเหตุต่อไปนี้

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

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

กฎข้อที่ 29: วิธีที่ดีที่สุดในการตรวจสอบให้แน่ใจว่าคุณฝึกทำงานเหมือนกับคุณให้บริการ คือการบันทึกชุดของคุณลักษณะที่ใช้ในเวลาที่แสดง แล้วเชื่อมต่อคุณลักษณะเหล่านี้ไปยังบันทึกเพื่อใช้ในขณะฝึก

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

กฎข้อ 30: ข้อมูลตัวอย่างน้ำหนักความสำคัญ อย่าทิ้งข้อมูลเหล่านั้นโดยเจตนา

เมื่อมีข้อมูลมากเกินไป คุณอาจต้องใช้ไฟล์ 1-12 และละเว้นไฟล์ 13-99 มีข้อผิดพลาดเกิดขึ้น แม้ว่าข้อมูลที่ไม่เคยแสดงต่อผู้ใช้อาจหายไปได้ แต่การถ่วงน้ำหนักความสำคัญจะเป็นทางเลือกที่ดีที่สุดสำหรับส่วนที่เหลือ การให้น้ำหนักความสำคัญหมายความว่า หากคุณตัดสินใจที่จะสุ่มตัวอย่างตัวอย่าง X ที่มีความน่าจะเป็น 30% ให้ถ่วงน้ำหนักตัวอย่างเป็น 10/3 เมื่อมีการถ่วงน้ำหนักความสำคัญ พร็อพเพอร์ตี้การปรับเทียบทั้งหมดที่กล่าวถึงในกฎข้อที่ 14 จะยังคงถูกระงับอยู่

กฎข้อ 31: ระวังหากคุณรวมข้อมูลจากตารางในเวลาที่ฝึกและแสดงผล ข้อมูลในตารางอาจเปลี่ยนแปลงได้

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

กฎข้อ 32: ใช้รหัสซ้ำระหว่างไปป์ไลน์การฝึกและไปป์ไลน์การแสดงโฆษณาเมื่อเป็นไปได้

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

กฎ #33: หากคุณสร้างแบบจำลองตามข้อมูลจนถึงวันที่ 5 มกราคม ให้ทดสอบโมเดลกับข้อมูลตั้งแต่วันที่ 6 มกราคมเป็นต้นไป

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

กฎ #34: ในการจำแนกประเภทไบนารีสำหรับการกรอง (เช่น การตรวจจับสแปมหรือการระบุอีเมลที่น่าสนใจ) ให้คำนึงถึงประสิทธิภาพเพียงเล็กน้อยในระยะสั้นเพื่อให้ได้ข้อมูลที่สะอาดตา

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

แต่วิธีนี้ทำให้เกิดอคติจากการสุ่มตัวอย่าง คุณสามารถรวบรวมข้อมูลที่น้อยลงได้หากคุณติดป้ายกำกับ 1% ของการเข้าชมทั้งหมดเป็น "ระงับ" และส่งตัวอย่างที่ยกมาทั้งหมดไปให้ผู้ใช้ ตอนนี้ตัวกรองบล็อกตัวอย่างเชิงลบอย่างน้อย 74% ตัวอย่างที่ยกมาเหล่านี้จะกลายเป็นข้อมูลการฝึกอบรมของคุณได้

โปรดทราบว่าหากตัวกรองของคุณบล็อกตัวอย่างเชิงลบอย่างน้อย 95% วิธีการนี้จะได้ผลน้อยลง อย่างไรก็ตาม หากคุณต้องการวัดประสิทธิภาพในการแสดงผล ก็สามารถสร้างตัวอย่างในระดับที่เท่ากันยิ่งขึ้นได้ (เช่น 0.1% หรือ 0.001%) ตัวอย่าง 10,000 รายการก็เพียงพอที่จะประเมินประสิทธิภาพได้ค่อนข้างแม่นยำ

กฎข้อ 35: ระวังปัญหาการจัดอันดับที่บิดเบือนตามปกติ

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

1. กำหนดรูปแบบที่สูงกว่าให้กับฟีเจอร์ที่ครอบคลุมคำค้นหามากกว่า มากกว่าฟีเจอร์ที่เปิดใช้สำหรับคำค้นหาเพียงรายการเดียว ด้วยวิธีนี้ โมเดลจะให้ความสำคัญกับฟีเจอร์ที่เจาะจงสำหรับคำค้นหา 1 หรือ 2-3 รายการมากกว่าฟีเจอร์ที่ทำให้คำค้นหาทั้งหมดเป็นแบบทั่วไป วิธีนี้จะช่วยป้องกันไม่ให้ผลการค้นหายอดนิยมจำนวนมากรั่วไหลไปสู่คำค้นหาที่ไม่เกี่ยวข้อง โปรดทราบว่าวิธีนี้ตรงข้ามกับคําแนะนําทั่วไปเกี่ยวกับการทำให้คอลัมน์ฟีเจอร์มีความสม่ำเสมอมากขึ้นซึ่งมีค่าที่ไม่ซ้ำกัน
2. อนุญาตเฉพาะฟีเจอร์ที่มีน้ำหนักเป็นบวก ดังนั้น ฟีเจอร์ที่ดีใดๆ จะดีกว่า ฟีเจอร์ที่ "ไม่รู้จัก"
3. ไม่มีฟีเจอร์สำหรับเอกสารเท่านั้น นี่คือเวอร์ชันที่ 1 สุดโต่ง ตัวอย่างเช่น แม้ว่าแอปที่กำหนดจะเป็นการดาวน์โหลดยอดนิยมไม่ว่าคำค้นหาจะเป็นอะไร แต่คุณก็ไม่ต้องการให้แสดงแอปนั้นทุกที่ การไม่ได้ให้คุณลักษณะเฉพาะเอกสาร ทำให้การทำงานเป็นเรื่องง่าย สาเหตุที่คุณไม่ต้องการแสดงแอปที่เจาะจง ในทุกๆ ที่นั้นเกี่ยวข้องกับความสำคัญของ การทำให้แอปที่ต้องการทั้งหมดเข้าถึงได้ เช่น หากมีคนค้นหาคำว่า "แอปดูนก" ผู้ใช้อาจดาวน์โหลด "นกโกรธ" แต่นั่นไม่ใช่สิ่งที่ตั้งใจ การแสดงแอปเช่นนี้อาจช่วยเพิ่มอัตราการดาวน์โหลดได้ แต่ท้ายที่สุดก็อาจทำให้ความต้องการของผู้ใช้ไม่เป็นที่น่าพอใจ

กฎข้อที่ 36: หลีกเลี่ยงการวนซ้ำฟีดแบ็กพร้อมกับฟีเจอร์ระบุตำแหน่ง

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

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

กฎข้อ 37: วัดความเบ้ของการฝึก/การแสดงผล

มีหลายสาเหตุที่อาจทำให้ภาพบิดเบี้ยวในภาพรวมส่วนใหญ่ นอกจากนี้ คุณยังสามารถแบ่งข้อมูลออกเป็นหลายๆ ส่วน ดังนี้

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

ML ระยะที่ 3: การเติบโตที่ล่าช้า การปรับแต่งการเพิ่มประสิทธิภาพ และรูปแบบที่ซับซ้อน

จะมีสัญญาณบางอย่างที่บ่งชี้ว่าเฟสที่ 2 ใกล้จะสิ้นสุดลงแล้ว ก่อนอื่น รายได้ต่อเดือนของคุณจะเริ่มลดลง คุณจะเริ่มพบการเปรียบเทียบระหว่างเมตริกต่างๆ โดยคุณจะเห็นผลลัพธ์ที่เพิ่มขึ้นและบางส่วนลดลงในการทดสอบบางรายการ และนี่คือจุดที่น่าสนใจ และเนื่องจากผลลัพธ์ที่ได้นั้นยากขึ้น แมชชีนเลิร์นนิงจึงต้องซับซ้อนมากขึ้น ข้อควรระวัง: ส่วนนี้มีกฎระดับท้องฟ้ามากกว่าส่วนก่อนหน้านี้ เราได้เห็นหลายทีมผ่านช่วงเวลาแห่งความสุข ของแมชชีนเลิร์นนิงในระยะที่ 1 และระยะที่ 2 เมื่อถึงระยะที่ 3 แล้ว ทีมจะต้องค้นหาเส้นทางของตนเอง

กฎข้อที่ 38: อย่าเสียเวลากับคุณลักษณะใหม่ ถ้าวัตถุประสงค์ที่ไม่สอดคล้องกลายเป็นปัญหา

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

กฎ #39: การตัดสินใจเปิดตัวเป็นเครื่องชี้วัดเป้าหมายผลิตภัณฑ์ในระยะยาว

ขวัญใจมีไอเดียเกี่ยวกับการลดการสูญเสียรายได้จากการคาดการณ์การติดตั้ง เธอได้เพิ่มคุณลักษณะ การสูญเสียระบบโลจิสติกส์ลดลง เมื่อทำการทดสอบจริง เธอพบว่าอัตราการติดตั้งเพิ่มขึ้น แต่เมื่อเธอไปร่วมงานประชุมรีวิวการเปิดตัว มีคนชี้ว่าจำนวนผู้ใช้ที่ใช้งานอยู่รายวันลดลง 5% ทีมงานจึงตัดสินใจที่จะไม่เปิดตัวโมเดลดังกล่าว อลิสารู้สึกผิดหวัง แต่ตอนนี้พบว่าการตัดสินใจเปิดตัวขึ้นอยู่กับเกณฑ์หลายเกณฑ์ แต่มีเพียงบางเกณฑ์เท่านั้นที่เพิ่มประสิทธิภาพได้โดยตรงโดยใช้ ML

ความจริงก็คือโลกความเป็นจริงไม่ใช่คุกใต้ดินและมังกร ไม่มี "คะแนน" ที่ชี้ให้เห็นถึงประโยชน์ของผลิตภัณฑ์ได้ ทีมจึงต้องใช้สถิติที่รวบรวมได้เพื่อพยายามคาดการณ์อย่างมีประสิทธิภาพว่าระบบจะดีแค่ไหนในอนาคต พวกเขาต้องให้ความสำคัญกับการมีส่วนร่วม, ผู้ใช้ที่ใช้งานอยู่ 1 วัน (DAU), DAU 30 คน, รายได้ และผลตอบแทนจากการลงทุนของผู้ลงโฆษณา เมตริกเหล่านี้ที่วัดผลได้ในการทดสอบ A/B ในตัวเธอนั้นเป็นเพียงภาพแทนเป้าหมายระยะยาวที่มากกว่าเท่านั้น ได้แก่ ความพึงพอใจผู้ใช้ การเพิ่มจำนวนผู้ใช้ ความพึงพอใจของพาร์ทเนอร์ และผลกำไร ซึ่งแม้แต่น้อย คุณอาจพิจารณาใช้พร็อกซีสำหรับการมีผลิตภัณฑ์ที่มีประโยชน์และมีคุณภาพสูง และบริษัทที่จะเติบโตได้อีก 5 ปีนับจากนี้

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

เวอร์ชันทดลอง	ผู้เข้าใช้งานรายวัน	รายได้/วัน
ก	1 ล้าน	$4 ล้าน
B	2 ล้าน	$2 ล้าน

หากระบบปัจจุบันเป็น A ทีมก็ไม่น่าจะเปลี่ยนไปใช้ B หากระบบปัจจุบันเป็น B ทีมก็ไม่น่าจะเปลี่ยนไปใช้ A ดูเหมือนว่าจะขัดแย้งกับพฤติกรรมที่เป็นเหตุเป็นผล อย่างไรก็ตาม การคาดคะเนการเปลี่ยนแปลงเมตริกอาจขยายผลหรือไม่เลื่อนออกไป จึงมีความเสี่ยงมากที่จะเกี่ยวข้องกับการเปลี่ยนแปลงดังกล่าว เมตริกแต่ละรายการจะครอบคลุมความเสี่ยงบางอย่างที่ทีมมีข้อกังวล

ยิ่งไปกว่านั้น ไม่มีเมตริกใดที่ครอบคลุมถึงข้อกังวลสำคัญของทีมที่ว่า "อีก 5 ปีข้างหน้าผลิตภัณฑ์ของฉัน อีก 5 ปีจะอยู่ที่ไหน"

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

กฎข้อ 40: ทำให้ส่วนประกอบต่างๆ เรียบง่ายเสมอ

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

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

กฎข้อ 41: เมื่อกราฟประสิทธิภาพลดลง ให้มองหาแหล่งข้อมูลใหม่เชิงคุณภาพมาเพิ่มแทนการปรับสัญญาณที่มีอยู่

คุณได้เพิ่มข้อมูลประชากรบางอย่างเกี่ยวกับผู้ใช้แล้ว คุณเพิ่มข้อมูลบางส่วน เกี่ยวกับคำในเอกสาร คุณได้สำรวจเทมเพลตและปรับแต่ง ให้สม่ำเสมอแล้ว คุณไม่เห็นการเปิดตัวที่มีการปรับปรุง เกิน 1% ในเมตริกหลักในช่วง 2-3 ไตรมาส ควรทำอย่างไรต่อไปดี

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

กฎข้อ 42: อย่าคาดหวังว่าความหลากหลาย การปรับเปลี่ยนในแบบของผู้ใช้ หรือความเกี่ยวข้องจะสัมพันธ์กับความนิยมในแบบที่คุณคิด

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

ปัญหาคือคนธรรมดามักจะเอาชนะได้ยาก

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

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

กฎข้อที่ 43: เพื่อนของคุณมักมีลักษณะเหมือนกันในผลิตภัณฑ์ต่างๆ ไม่น่าจะสนใจเรื่องเดียวกับคุณ

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

งานที่เกี่ยวข้อง

เอกสารเกี่ยวกับแมชชีนเลิร์นนิงที่ Google ตลอดจนเอกสารภายนอกก็มีมากมาย

• หลักสูตรเร่งรัดเกี่ยวกับแมชชีนเลิร์นนิง: บทนำเกี่ยวกับแมชชีนเลิร์นนิงที่ประยุกต์ใช้
• แมชชีนเลิร์นนิง: แนวทางความน่าจะเป็นโดย Kevin Murphy เพื่อสร้างความเข้าใจเกี่ยวกับสาขาแมชชีนเลิร์นนิง
• การวิเคราะห์ข้อมูลที่ดี: แนวทางวิทยาศาสตร์ข้อมูลในการพิจารณาเกี่ยวกับชุดข้อมูล
• การเรียนรู้เชิงลึกโดย Ian Goodfellow และคณะ สำหรับการเรียนรู้โมเดลที่ไม่ใช่เชิงเส้น
• เอกสารของ Google เกี่ยวกับหนี้ทางเทคนิคซึ่งมีคำแนะนำทั่วไปอยู่มากมาย
• เอกสารประกอบของ Tensorflow

กิตติกรรมประกาศ

ขอขอบคุณ David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Gonstantinos ขอขอบคุณ Kristen Lefevre, Suddha Basu และ Chris Berg ที่ให้ความช่วยเหลือในเวอร์ชันก่อนหน้านี้ ข้อผิดพลาด การละเลย หรือ (อ้าปากค้าง) ความคิดเห็นที่แปลกออกไปคือผมเอง

ภาคผนวก

เอกสารนี้มีการอ้างอิงผลิตภัณฑ์ต่างๆ ของ Google เพื่อให้บริบทเพิ่มเติม เราได้อธิบายสั้นๆ เกี่ยวกับตัวอย่างที่พบบ่อยที่สุดด้านล่าง

ภาพรวมของ YouTube

YouTube คือบริการสตรีมวิดีโอ ทั้งทีมแนะนำให้รับชมของ YouTube และหน้าแรกของ YouTube ใช้โมเดล ML ในการจัดอันดับวิดีโอแนะนำ "ดูอะไรต่อดี" จะแนะนำวิดีโอให้รับชมหลังจากวิดีโอที่กำลังเล่นอยู่ ขณะที่ "หน้าแรก" จะแนะนำวิดีโอให้ผู้ใช้ที่เรียกดูหน้าแรก

ภาพรวมของ Google Play

Google Play มีโมเดลมากมายที่ช่วยแก้ปัญหาต่างๆ ได้ แอป Play Search, คำแนะนำที่ปรับเปลี่ยนในแบบของคุณในหน้าแรกของ Play และแอป "ผู้ใช้ที่ยังติดตั้ง" ต่างก็ใช้แมชชีนเลิร์นนิง

ภาพรวมของ Google Plus

Google Plus ใช้แมชชีนเลิร์นนิงในสถานการณ์ต่างๆ เช่น การจัดอันดับโพสต์ใน "สตรีม" ของโพสต์ที่ผู้ใช้เห็น การจัดอันดับโพสต์ "กำลังฮอต" (โพสต์ที่ได้รับความนิยมอย่างมากในขณะนี้) การจัดอันดับบุคคลที่คุณรู้จัก เป็นต้น Google Plus ได้ปิดบัญชีส่วนตัวทั้งหมดในปี 2019 และแทนที่ด้วย Google Currents สำหรับบัญชีธุรกิจในวันที่ 6 กรกฎาคม 2020