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

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

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

Martin Zinkevich

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

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

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

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

กฎข้อที่ 3: เลือกแมชชีนเลิร์นนิงเพื่อศึกษาวิธีการที่ซับซ้อน

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

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

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

กฎข้อที่ 4: ใช้โมเดลแรกที่ไม่ซับซ้อนและใช้โครงสร้างพื้นฐานที่เหมาะสม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Monitoring

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

กฎข้อที่ 8: ทราบถึงความใหม่ของระบบ

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

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

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

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

กฎข้อที่ 10: ตรวจสอบความล้มเหลวในการปิดเสียง

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

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

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

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

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

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

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

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

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

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

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

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

หลีกเลี่ยงการประมาณทางอ้อมทางอ้อมในตอนแรก

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

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

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

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

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

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

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

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

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

กฎข้อที่ 15: แยกการกรองสแปมและการจัดอันดับคุณภาพในเลเยอร์นโยบาย

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

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

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

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

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

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

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

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

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

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

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

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

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

กฎข้อที่ 18: สํารวจโดยใช้ฟีเจอร์ของเนื้อหาทั่วไปในบริบทต่างๆ

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

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

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

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

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

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

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

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

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

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

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

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

ในตอนท้าย ให้ใช้กฎ #28 เพื่อเลือกฟีเจอร์ที่จะใช้

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

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

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

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

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

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

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

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

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

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

กฎข้อที่ 24: วัดเดลต้าระหว่างโมเดล

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

กฎข้อที่ 25: เมื่อเลือกโมเดล ประสิทธิภาพที่แท้จริงจะใช้กําลังการคาดคะเน

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

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

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

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

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

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

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

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

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

กฎข้อที่ 36: หลีกเลี่ยงการวนซ้ําความคิดเห็นด้วยฟีเจอร์ที่เป็นตําแหน่ง

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

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

กฎข้อที่ 37: วัดการฝึก/การเอียง

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

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

ML ระยะที่ 3: การเติบโตที่ช้า การปรับเกณฑ์การค้นหา และรูปแบบที่ซับซ้อน

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

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

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

กฎข้อที่ 39: การตัดสินใจเปิดตัวเป็นพร็อกซีสําหรับเป้าหมายผลิตภัณฑ์ในระยะยาว

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

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

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

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

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

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

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

กฎข้อที่ 40: จัดเรียงประโยคที่เรียบง่าย

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

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

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

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

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

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

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

แต่ปัญหาก็คือ แอปเหล่านี้มีแนวโน้มที่จะทําได้ยาก

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

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

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

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

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

ข้อความแสดงการยอมรับ

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

ภาคผนวก

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

ภาพรวมของ YouTube

YouTube เป็นบริการสตรีมมิงวิดีโอ ทั้งทีมหน้าแนะนําให้รับชมของ YouTube และหน้าแรกของ YouTube ใช้โมเดลแมชชีนเลิร์นนิงเพื่อสร้างอันดับวิดีโอแนะนํา "แนะนําให้รับชม" จะแนะนําวิดีโอให้ดูหลังจากวิดีโอที่กําลังเล่นอยู่ ขณะที่หน้าแรกจะแนะนําวิดีโอแก่ผู้ใช้ที่เรียกดูหน้าแรก

ภาพรวมของ Google Play

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

ภาพรวมของ Google Plus

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