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

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

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

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

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

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

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

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

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

กฎข้อที่ 3: เลือกแมชชีนเลิร์นนิงแทนการใช้การหาค่าประมาณเชิงประสบการณ์ที่ซับซ้อน

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

ML ระยะที่ 1: ไปป์ไลน์แรก

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

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

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

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

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

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

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

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

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

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

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

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

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

กฎข้อที่ 7: เปลี่ยนการประเมินแบบเฮuristic เป็นฟีเจอร์ หรือจัดการจากภายนอก

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

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

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

การตรวจสอบ

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

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

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

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

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

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

กฎข้อที่ 10: ระวังความล้มเหลวแบบเงียบๆ

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

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

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

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

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

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

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

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

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

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

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

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

หลีกเลี่ยงการประมาณผลที่เกิดจากปัจจัยภายนอกในช่วงแรก

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

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

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

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

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

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

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

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

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

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

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

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

ML ระยะที่ 2: Feature Engineering

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

กฎข้อ 27: ลองหาปริมาณของลักษณะการทำงานที่ไม่พึงประสงค์ที่สังเกตได้

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

กฎ #28: โปรดทราบว่าลักษณะการทํางานในระยะสั้นที่เหมือนกันไม่ได้หมายความว่าลักษณะการทํางานในระยะยาวจะเหมือนกัน

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

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

ความคลาดเคลื่อนระหว่างการฝึกและการให้บริการ

ความเบี่ยงเบนระหว่างช่วงการฝึกกับช่วงแสดงโฆษณาคือความแตกต่างระหว่างประสิทธิภาพระหว่างช่วงการฝึกกับช่วงแสดงโฆษณา ความเบี่ยงเบนนี้อาจเกิดจากสาเหตุต่อไปนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

กฎข้อที่ 35: ระวังความเอนเอียงที่มีอยู่แล้วในปัญหาการจัดอันดับ

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

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

กฎ #36: หลีกเลี่ยงการใช้ลูปความคิดเห็นกับฟีเจอร์ตำแหน่ง

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

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

กฎข้อ 37: วัดความคลาดเคลื่อนระหว่างการฝึกและการให้บริการ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

กฎข้อ 40: แต่งตัวให้เรียบง่าย

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ขอขอบคุณ

ขอขอบคุณ David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira และ Hrishikesh Aradhye สำหรับการแก้ไข คำแนะนำ และตัวอย่างที่เป็นประโยชน์มากมายในเอกสารนี้ และขอขอบคุณ Kristen Lefevre, Suddha Basu และ Chris Berg ที่ช่วยในเวอร์ชันก่อนหน้า ความผิดพลาด การละเว้น หรือความคิดเห็นที่ (อุ๊ย) ไม่เป็นที่นิยมทั้งหมดเป็นความคิดเห็นของฉันเอง

ภาคผนวก

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

ภาพรวมของ YouTube

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

ภาพรวมของ Google Play

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

ภาพรวมของ Google Plus

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