การทดลองช่วยขับเคลื่อนโครงการไปสู่การอยู่รอด เป็นสมมติฐานที่ทดสอบได้และ เกิดขึ้นซ้ำได้ ขณะทำการทดสอบ เป้าหมายคือการปรับปรุงเพิ่มเติมอย่างต่อเนื่องด้วยการประเมินสถาปัตยกรรมโมเดลและฟีเจอร์ที่หลากหลาย ขณะทดสอบ คุณจะต้องทำสิ่งต่อไปนี้
พิจารณาประสิทธิภาพพื้นฐาน เริ่มต้นด้วยการสร้างเมตริกเกณฑ์พื้นฐาน เกณฑ์พื้นฐานทำหน้าที่เป็นแท่งวัดเพื่อเปรียบเทียบการทดสอบ
ในบางกรณี โซลูชันที่ไม่ใช่ ML ในปัจจุบันสามารถให้เมตริกพื้นฐานแรกได้ หากไม่มีโซลูชันในปัจจุบัน ให้สร้างโมเดล ML ที่มีสถาปัตยกรรมที่เรียบง่าย ฟีเจอร์ 2-3 รายการ และใช้เมตริกของโมเดลดังกล่าวเป็นเกณฑ์พื้นฐาน
ทำการเปลี่ยนแปลงเล็กๆ น้อยๆ รายการเดียว ทำการเปลี่ยนแปลงเล็กๆ น้อยๆ ทีละรายการเท่านั้น เช่น ไฮเปอร์พารามิเตอร์ สถาปัตยกรรม หรือฟีเจอร์ หากการเปลี่ยนแปลงช่วยปรับปรุงโมเดล เมตริกของรูปแบบนั้นจะกลายเป็นเกณฑ์พื้นฐานใหม่ที่จะใช้เปรียบเทียบการทดสอบในอนาคต
ต่อไปนี้คือตัวอย่างของการทดสอบที่ทำการเปลี่ยนแปลงเพียงเล็กน้อย
- มีฟีเจอร์ X
- ใช้การออก 0.5 ในเลเยอร์แรกที่ซ่อนอยู่
- ให้ใช้การเปลี่ยนรูปแบบบันทึกของฟีเจอร์ Y
- เปลี่ยนอัตราการเรียนรู้เป็น 0.001
บันทึกความคืบหน้าของการทดสอบ คุณน่าจะต้องทำการทดสอบหลายๆ อย่าง การทดสอบที่มีคุณภาพในการคาดการณ์ต่ำ (หรือเป็นกลาง) เมื่อเทียบกับเกณฑ์พื้นฐานจะยังคงมีประโยชน์ในการติดตาม เป็นสัญญาณที่บอกว่า วิธีใดไม่ได้ผล เนื่องจากความคืบหน้ามักไม่ใช่แบบเชิงเส้น คุณจึงควรแสดงให้เห็นว่าคุณกำลังแก้ปัญหาโดยไฮไลต์วิธีทั้งหมดที่พบว่าไม่ได้ผล นอกเหนือจากความคืบหน้าในการเพิ่มคุณภาพพื้นฐาน
เนื่องจากการฝึกเต็มรูปแบบแต่ละครั้งบนชุดข้อมูลของโลกแห่งความเป็นจริงอาจใช้เวลาหลายชั่วโมง (หรือหลายวัน) คุณจึงควรลองทำการทดสอบอิสระหลายรายการพร้อมกันเพื่อสำรวจพื้นที่อย่างรวดเร็ว ระหว่างที่ดำเนินการไปเรื่อยๆ คุณหวังจะเข้าใกล้ระดับคุณภาพที่จำเป็นสำหรับการผลิตมากขึ้นและใกล้ขึ้น
เสียงรบกวนในผลการทดสอบ
โปรดทราบว่าคุณอาจพบเสียงรบกวนในผลการทดสอบที่ไม่ได้มาจากการเปลี่ยนแปลงโมเดลหรือข้อมูล ซึ่งทำให้ยากที่จะพิจารณาว่าการเปลี่ยนแปลงที่คุณทำขึ้นนั้นได้ปรับปรุงโมเดลจริงหรือไม่ ตัวอย่างของสิ่งต่างๆ ที่อาจสร้างสัญญาณรบกวนในผลการทดสอบมีดังนี้
การสับเปลี่ยนข้อมูล: ลำดับการนำเสนอข้อมูลไปยังโมเดลอาจส่งผลต่อประสิทธิภาพของโมเดลได้
การเริ่มต้นตัวแปร: วิธีเริ่มต้นตัวแปรของโมเดลอาจส่งผลต่อประสิทธิภาพเช่นกัน
การทำงานพร้อมกันอะซิงโครนัส: หากโมเดลได้รับการฝึกโดยใช้การโหลดพร้อมกันแบบไม่พร้อมกัน ลำดับการอัปเดตส่วนต่างๆ ของโมเดลก็อาจส่งผลต่อประสิทธิภาพได้เช่นกัน
ชุดการประเมินขนาดเล็ก: หากชุดการประเมินเล็กเกินไป ชุดการประเมินอาจไม่ตรงกับประสิทธิภาพโดยรวมของโมเดล ซึ่งทำให้คุณภาพของโมเดลมีความแปรผันไม่เท่ากัน
การทำการทดสอบหลายครั้งจะช่วยยืนยันผลการทดสอบได้
ปรับแนวทางปฏิบัติในการทดสอบให้สอดคล้องกัน
ทีมของคุณควรมีความเข้าใจที่ชัดเจนว่า "การทดสอบ" คืออะไร โดยระบุแนวทางปฏิบัติและอาร์ติแฟกต์ คุณจะต้องมีเอกสารที่ระบุข้อมูลต่อไปนี้
อาร์ติแฟกต์ อาร์ติแฟกต์สำหรับการทดสอบคืออะไร ในกรณีส่วนใหญ่ การทดสอบเป็นสมมติฐานที่ทดสอบแล้วซ้ำได้ ซึ่งโดยทั่วไปจะบันทึกข้อมูลเมตา (เช่น ฟีเจอร์และไฮเปอร์พารามิเตอร์) ที่ระบุการเปลี่ยนแปลงระหว่างการทดสอบและผลกระทบต่อคุณภาพของโมเดล
แนวทางปฏิบัติในการเขียนโค้ด ทุกคนจะใช้สภาพแวดล้อมทดลองของตนเองไหม เป็นไปได้อย่างไร (หรือง่าย) ที่จะรวมงานของทุกคนไว้ในห้องสมุดที่ใช้ร่วมกัน
การทำซ้ำและการติดตาม มาตรฐานในการทำซ้ำ มีอะไรบ้าง เช่น ทีมควรใช้ไปป์ไลน์ข้อมูลและแนวทางปฏิบัติกำหนดเวอร์ชันเดียวกัน หรือแสดงเฉพาะพล็อต ระบบจะบันทึกข้อมูลการทดลองอย่างไร เช่น การค้นหา SQL หรือเป็นสแนปชอตโมเดล ระบบจะจัดเก็บบันทึกจากการทดสอบไว้ที่ใด ในเอกสาร สเปรดชีต หรือ CMS สำหรับการจัดการการทดสอบ
การคาดการณ์ไม่ถูกต้อง
ไม่มีแบบจำลองในโลกแห่งความเป็นจริงสมบูรณ์แบบ ระบบจะจัดการกับการคาดการณ์ที่ไม่ถูกต้องอย่างไร เริ่มคิดตั้งแต่เนิ่นๆ เกี่ยวกับวิธีรับมือกับปัญหา
กลยุทธ์แนวทางปฏิบัติแนะนำจะกระตุ้นให้ผู้ใช้ติดป้ายกำกับการคาดคะเนที่ไม่ถูกต้องได้อย่างถูกต้อง ตัวอย่างเช่น แอปอีเมลจะบันทึกอีเมลที่จัดประเภทไม่ถูกต้องโดยการบันทึกอีเมลที่ผู้ใช้ย้ายไปยังโฟลเดอร์จดหมายขยะและในทางกลับกัน คุณสามารถออกแบบลูปความคิดเห็นอัตโนมัติสำหรับการรวบรวมข้อมูลและการฝึกโมเดลซ้ำได้ด้วยการบันทึกป้ายกำกับข้อมูลจากการสังเกตการณ์โดยตรงจากผู้ใช้
โปรดทราบว่าแม้แบบสำรวจที่ฝัง UI จะบันทึกความคิดเห็นของผู้ใช้ แต่โดยปกติแล้ว ข้อมูลดังกล่าวจะเป็นข้อมูลเชิงคุณภาพและจะนำไปรวมกับข้อมูลการฝึกซ้ำไม่ได้
นำโซลูชันแบบต้นทางถึงปลายทางไปใช้
ขณะที่ทีมกำลังทดสอบโมเดลนี้ ควรเริ่มสร้างส่วนต่างๆ ของไปป์ไลน์ขั้นสุดท้าย (หากคุณมีทรัพยากรสำหรับดำเนินการดังกล่าว)
การสร้างกระบวนการต่างๆ ในไปป์ไลน์ เช่น การส่งผ่านข้อมูลและการฝึกโมเดลอีกครั้ง ช่วยให้ย้ายโมเดลสุดท้ายไปยังเวอร์ชันที่ใช้งานจริงได้ง่ายขึ้น ตัวอย่างเช่น การรับไปป์ไลน์แบบต้นทางถึงปลายทางสำหรับการส่งผ่านข้อมูลและการคาดการณ์การแสดงผลจะช่วยให้ทีมเริ่มผสานรวมโมเดลเข้ากับผลิตภัณฑ์และเริ่มต้นการทดสอบผู้ใช้ในระยะเริ่มต้นได้
การแก้ปัญหาโปรเจ็กต์ที่หยุดชะงัก
คุณอาจอยู่ในสถานการณ์ที่ความคืบหน้าของโปรเจ็กต์หยุดชะงัก บางทีทีมของคุณอาจเคยทำการทดสอบอย่างมีประสิทธิภาพแต่ยังไม่ประสบความสำเร็จในการปรับปรุงรูปแบบเป็นเวลาหลายสัปดาห์ คุณควรทำอย่างไร ตัวอย่างแนวทางที่เป็นไปได้มีดังนี้
เชิงกลยุทธ์ คุณอาจต้องจัดกรอบโจทย์ใหม่ หลังจากใช้เวลาในช่วงทดสอบแล้ว คุณน่าจะเข้าใจปัญหา ข้อมูล และวิธีแก้ปัญหาที่เป็นไปได้ได้ดีขึ้น หากมีความรู้ลึกซึ้งเกี่ยวกับโดเมน คุณก็อาจตีกรอบปัญหาได้แม่นยำขึ้น
ตัวอย่างเช่น ในตอนแรกคุณอาจต้องใช้การถดถอยเชิงเส้นเพื่อคาดการณ์ค่าตัวเลข น่าเสียดายที่ข้อมูลยังไม่ดีพอที่จะฝึก โมเดลการถดถอยเชิงเส้นที่ใช้งานได้ การวิเคราะห์เพิ่มเติมอาจเผยให้เห็นปัญหา ที่แก้ไขได้โดยการคาดการณ์ว่าตัวอย่างจะสูงกว่าหรือต่ำกว่าค่าหนึ่งๆ วิธีนี้จะช่วยให้คุณสามารถจัดเฟรมโจทย์ใหม่เป็นการจัดประเภทแบบไบนารี
อย่ายอมแพ้หากมีความคืบหน้าช้ากว่าที่คาดไว้ การปรับปรุงเพิ่มขึ้นเรื่อยๆ จึงอาจเป็นวิธีเดียวที่แก้ปัญหาได้ ตามที่แจ้งไปก่อนหน้านี้ คุณไม่ควรคาดหวังว่าจะมีความคืบหน้าเท่าเดิมในแต่ละสัปดาห์ บ่อยครั้ง การรับโมเดลที่พร้อมสำหรับเวอร์ชันที่ใช้งานจริงต้องใช้เวลามาก การปรับปรุงโมเดลอาจผิดปกติและคาดเดาไม่ได้ ช่วงของความคืบหน้าที่ช้าอาจตามมาด้วยการปรับปรุงอย่างฉับพลันหรือความคืบหน้าย้อนกลับก็ได้
ด้านเทคนิค ใช้เวลาในการวิเคราะห์และวิเคราะห์การคาดการณ์ที่ไม่ถูกต้อง ในบางกรณี คุณอาจพบปัญหาโดยการแยกการคาดการณ์ที่ไม่ถูกต้อง 2-3 รายการและวิเคราะห์พฤติกรรมของโมเดลในอินสแตนซ์เหล่านั้น เช่น คุณอาจแจ้งปัญหาเกี่ยวกับสถาปัตยกรรมหรือข้อมูล ในกรณีอื่นๆ การ เพิ่มข้อมูลอาจช่วยได้ คุณอาจได้รับสัญญาณที่ชัดเจนขึ้นซึ่งบ่งบอกว่าคุณกำลังมาถูกทางแล้ว หรืออาจมีเสียงรบกวนมากขึ้น ซึ่งบ่งบอกว่ามีปัญหาอื่นๆ อยู่ในแนวทาง
หากกำลังแก้ปัญหาที่ต้องใช้ชุดข้อมูลที่ติดป้ายกำกับโดยมนุษย์ การรับชุดข้อมูลที่ติดป้ายกำกับสำหรับการประเมินโมเดลอาจทำได้ยาก ค้นหาแหล่งข้อมูลเพื่อรับชุดข้อมูลที่คุณจำเป็นต้องใช้ในการประเมิน
อาจยังไม่มีวิธีแก้ปัญหา บอกเวลาว่าแนวทางใดควรหยุดลงหากไม่มีความคืบหน้าภายในกรอบเวลาดังกล่าว อย่างไรก็ตาม หากคุณมีข้อความที่เป็นปัญหาที่ชัดเจน คุณควรหาทางแก้ไข