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