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

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

Martin Zinkevich

เอกสารนี้มีจุดประสงค์เพื่อช่วยเหลือผู้ที่มีความรู้พื้นฐานเกี่ยวกับคอมพิวเตอร์ จึงได้ประโยชน์จากแนวทางปฏิบัติแนะนำของ 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: อย่ากลัวการเปิดตัวผลิตภัณฑ์โดยไม่มีแมชชีนเลิร์นนิง

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

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

กฎข้อที่ 2: ขั้นแรก ออกแบบและใช้งานเมตริก

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

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

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

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

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

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

ML ระยะที่ 1: ไปป์ไลน์แรกของคุณ

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

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

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

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

การเลือกฟีเจอร์ที่เรียบง่ายทำให้มั่นใจได้มากขึ้นว่า

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

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

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

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

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

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

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

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

กฎข้อ 7: เปลี่ยนการเรียนรู้ให้เป็นฟีเจอร์ หรือจัดการสิ่งต่างๆ จากภายนอก

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

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

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

การตรวจสอบ

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

กฎข้อ 8: ศึกษาข้อกำหนดด้านความใหม่ของระบบ

ประสิทธิภาพจะลดลงเท่าใดหากคุณมีโมเดลที่มีอายุ 1 วันแล้ว 1 สัปดาห์ เก่า 1 / 4 ข้อมูลนี้จะช่วยให้คุณเข้าใจเกี่ยวกับการจัดลำดับความสำคัญ ในการตรวจสอบ หากคุณสูญเสียผลิตภัณฑ์ที่สำคัญ คุณภาพหากโมเดลไม่ได้รับการอัปเดต การมีวิศวกรเข้ามาดูเนื้อหาอย่างต่อเนื่องเป็นเวลา 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: การเริ่มต้นด้วยโมเดลที่ตีความได้จะทำให้แก้ไขข้อบกพร่องได้ง่ายขึ้น

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

กฎข้อ 18: สํารวจด้วยฟีเจอร์ของเนื้อหาที่ครอบคลุมบริบทต่างๆ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

กฎข้อ 24: วัดเดลต้าระหว่างรูปแบบ

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

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

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

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

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

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

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

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

สมาชิกบางคนในทีมของคุณจะเริ่มรู้สึกไม่พอใจกับคุณสมบัติของ ที่พวกเขาไม่ชอบ ซึ่งฟังก์ชันการสูญเสียผู้ใช้ที่มีอยู่จะไม่บันทึกไว้ ที่ ในขั้นตอนนี้ นักเรียนควรทำทุกวิถีทางเพื่อเปลี่ยนส่วนที่ยึดโยงให้เป็นเส้นทึบ ตัวเลข เช่น ถ้าเขาคิดว่ามี "แอป gag" มากเกินไป กำลังแสดง ใน 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 มกราคม คุณจะคาดหวังว่าประสิทธิภาพ ข้อมูลใหม่อาจไม่ดีนัก แต่ก็ไม่ควรแย่ลงอย่างสิ้นเชิง เนื่องจากอาจส่งผลกระทบในแต่ละวัน คุณจึงไม่สามารถคาดการณ์จำนวนคลิกโดยเฉลี่ย แต่พื้นที่ใต้เส้นโค้งซึ่งแสดง ให้คะแนนตัวอย่างเชิงบวกสูงกว่าคะแนนเชิงลบ ตัวอย่าง ควรจะอยู่ใกล้พอสมควร

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

กฎข้อ 40: ทำให้องค์ประกอบต่างๆ เรียบง่าย

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

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

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

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

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

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

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

ปัญหาก็คือวิดีโอธรรมดาๆ มักจะเอาชนะได้ยาก

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

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

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

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

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

เอกสารเกี่ยวกับแมชชีนเลิร์นนิงที่ Google รวมไปถึงเอกสารภายนอกมีอยู่มากมาย

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

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

ขอขอบคุณ David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine ตัล เชค, ทุชฮาร์ จันดรา, มุสตาฟา อิสเปีย, เจเรไมอาห์ ฮาร์มเซน, คอนสแตนติโนส คัทเซียส, เกล็น แอนเดอร์สัน, แดน ดัคเวิร์ธ, ชิเชอร์ เบอร์มิวัล, กัล เอลิแดน, ซูหลิน Wu, Jaihui Liu, Fernando Pereira และ Hrishikesh Aradhye สำหรับการแก้ไขหลายครั้ง คำแนะนำและตัวอย่างที่เป็นประโยชน์สำหรับเอกสารนี้ ขอขอบคุณ 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