ทําตามงานต่อไปนี้เพื่อทำความเข้าใจปัญหา
- ระบุเป้าหมายของผลิตภัณฑ์ที่คุณกําลังพัฒนาหรือปรับโครงสร้าง
- พิจารณาว่าเป้าหมายจะบรรลุได้ดีที่สุดโดยใช้ ML แบบคาดการณ์, Generative AI หรือโซลูชันที่ไม่ใช่ ML
- ตรวจสอบว่าคุณมีข้อมูลที่จําเป็นในการฝึกโมเดลหากใช้แนวทาง ML เชิงคาดการณ์
ระบุเป้าหมาย
เริ่มต้นด้วยการระบุเป้าหมายของคุณโดยใช้คำที่ไม่เกี่ยวข้องกับ ML เป้าหมายคือคําตอบสําหรับคําถามที่ว่า "ฉันกําลังพยายามทําอะไรให้สําเร็จ"
ตารางต่อไปนี้ระบุเป้าหมายสําหรับแอปสมมติอย่างชัดเจน
แอปพลิเคชัน | เป้าหมาย |
---|---|
แอปสภาพอากาศ | คํานวณปริมาณน้ำฝนเป็นช่วง 6 ชั่วโมงสําหรับภูมิภาคทางภูมิศาสตร์ |
แอปแฟชั่น | สร้างการออกแบบเสื้อที่หลากหลาย |
แอปวิดีโอ | แนะนำวิดีโอที่มีประโยชน์ |
แอปอีเมล | ตรวจหาสแปม |
แอปการเงิน | สรุปข้อมูลทางการเงินจากแหล่งข่าวหลายแห่ง |
แอปแผนที่ | คำนวณเวลาเดินทาง |
แอปธนาคาร | ระบุธุรกรรมที่เป็นการฉ้อโกง |
แอปการรับประทานอาหาร | ระบุอาหารตามเมนูของร้านอาหาร |
แอปอีคอมเมิร์ซ | ตอบรีวิวด้วยคำตอบที่เป็นประโยชน์ |
กรณีการใช้งานที่ชัดเจนสําหรับ ML
บางคนมองว่า ML เป็นเครื่องมืออเนกประสงค์ที่ใช้งานได้กับทุกปัญหา แต่ความจริงแล้ว ML เป็นเครื่องมือเฉพาะทางที่เหมาะกับปัญหาบางอย่างเท่านั้น คุณไม่ต้องการนําโซลูชัน ML ที่ซับซ้อนมาใช้เมื่อโซลูชันที่ไม่ใช่ ML ที่ง่ายกว่าก็ทํางานได้
ระบบ ML แบ่งออกเป็น 2 หมวดหมู่ใหญ่ๆ ได้แก่ แมชชีนเลิร์นนิงแบบคาดการณ์ และ Generative AI ตารางต่อไปนี้แสดงลักษณะที่โดดเด่นของประเภทต่างๆ
อินพุต | เอาต์พุต | เทคนิคการฝึกอบรม | |
---|---|---|---|
ML เชิงคาดการณ์ |
ข้อความ รูปภาพ เสียง วิดีโอ ตัวเลข |
ทำการคาดการณ์ เช่น การจัดประเภทอีเมลว่าเป็นสแปมหรือไม่สแปม การคาดคะเนปริมาณน้ำฝนในวันพรุ่งนี้ หรือการคาดการณ์ราคาหุ้น โดยปกติแล้ว ผลลัพธ์สามารถตรวจสอบกับความเป็นจริงได้ | โดยทั่วไปจะใช้ข้อมูลจํานวนมากเพื่อฝึกโมเดลการเรียนรู้ภายใต้การควบคุม การเรียนรู้ที่ไม่มีการควบคุม หรือการเรียนรู้ด้วยการเพิ่มแรงเสริมเพื่อทํางานบางอย่าง |
Generative AI |
ข้อความ รูปภาพ เสียง วิดีโอ ตัวเลข |
สร้างเอาต์พุตตามความต้องการของผู้ใช้ เช่น การสรุปบทความ การสร้างคลิปเสียงหรือวิดีโอสั้น | โดยทั่วไปจะใช้ข้อมูลที่ไม่มีป้ายกำกับจำนวนมากเพื่อฝึกโมเดลภาษาขนาดใหญ่หรือเครื่องมือสร้างรูปภาพเพื่อเติมเต็มข้อมูลที่ขาดหายไป จากนั้นจึงนำไปใช้กับงานที่มีลักษณะเป็นงานเติมคำในช่องว่าง หรือจะปรับแต่งให้ละเอียดยิ่งขึ้นโดยการฝึกโมเดลด้วยข้อมูลที่ติดป้ายกำกับสำหรับงานบางอย่างที่เฉพาะเจาะจง เช่น การแยกประเภทก็ได้ |
หากต้องการยืนยันว่า ML เป็นแนวทางที่ถูกต้อง ให้ตรวจสอบก่อนว่าโซลูชันที่ไม่ใช่ ML ที่ใช้อยู่ได้รับการเพิ่มประสิทธิภาพแล้ว หากไม่ได้ติดตั้งใช้งานโซลูชันที่ไม่ใช่ ML ให้ลองแก้ปัญหาด้วยตนเองโดยใช้วิธีการแก้ปัญหาแบบเฮิวริสติก
โซลูชันที่ไม่ใช่ ML คือการเปรียบเทียบที่คุณจะใช้เพื่อพิจารณาว่า ML เป็น Use Case ที่เหมาะกับปัญหาของคุณหรือไม่ ลองพิจารณาคำถามต่อไปนี้เมื่อเปรียบเทียบแนวทางที่ไม่ใช่ ML กับแนวทาง ML
คุณภาพ คุณคิดว่าโซลูชัน ML จะมีประสิทธิภาพดีกว่ามากน้อยเพียงใด หากคุณคิดว่าโซลูชัน ML อาจเป็นเพียงการปรับปรุงเล็กน้อย แสดงว่าโซลูชันปัจจุบันอาจเหมาะที่สุดแล้ว
ต้นทุนและการบำรุงรักษา โซลูชัน ML มีค่าใช้จ่ายสูงเพียงใดทั้งในระยะสั้นและระยะยาว ในบางกรณี การใช้ ML อาจต้องใช้ทรัพยากรการประมวลผลและเวลามากกว่ามาก ลองพิจารณาคำถามต่อไปนี้
- โซลูชัน ML คุ้มค่ากับต้นทุนที่เพิ่มขึ้นไหม โปรดทราบว่าการปรับปรุงเล็กๆ น้อยๆ ในระบบขนาดใหญ่สามารถอธิบายต้นทุนและการบำรุงรักษาในการติดตั้งใช้งานโซลูชัน ML ได้อย่างง่ายดาย
- โซลูชันต้องมีการบำรุงรักษามากเพียงใด ในหลายกรณี การใช้งาน ML ต้องได้รับการบำรุงรักษาระยะยาวโดยเฉพาะ
- ผลิตภัณฑ์ของคุณมีทรัพยากรสนับสนุนการฝึกอบรมหรือจ้างผู้เชี่ยวชาญด้าน ML หรือไม่
ทดสอบความเข้าใจ
ML การคาดการณ์และข้อมูล
ข้อมูลคือแรงขับเคลื่อนของ ML แบบคาดการณ์ หากต้องการคาดการณ์ที่ดี คุณต้องมีข้อมูลที่มีฟีเจอร์ที่คาดการณ์ได้ ข้อมูลของคุณควรมีลักษณะต่อไปนี้
มีมาก ยิ่งมีตัวอย่างที่เกี่ยวข้องและมีประโยชน์ในชุดข้อมูลมากเท่าไร โมเดลก็จะยิ่งมีประสิทธิภาพมากขึ้นเท่านั้น
สอดคล้องกันและเชื่อถือได้ การมีข้อมูลที่รวบรวมอย่างสม่ำเสมอและเชื่อถือได้จะช่วยให้ได้โมเดลที่ดีขึ้น ตัวอย่างเช่น โมเดลสภาพอากาศที่อิงตาม ML จะได้รับประโยชน์จากข้อมูลที่รวบรวมมาหลายปีจากเครื่องมือที่เชื่อถือได้แบบเดียวกัน
เชื่อถือได้ ทำความเข้าใจว่าข้อมูลของคุณมาจากที่ใด ข้อมูลจะมาจากแหล่งที่มาที่เชื่อถือได้ซึ่งคุณควบคุม เช่น บันทึกจากผลิตภัณฑ์ หรือมาจากแหล่งที่มาที่คุณไม่มีข้อมูลเชิงลึกมากนัก เช่น เอาต์พุตจากระบบ ML อื่น
พร้อมใช้งาน ตรวจสอบว่าอินพุตทั้งหมดพร้อมใช้งานในเวลาการคาดการณ์ในรูปแบบที่ถูกต้อง หากรับค่าฟีเจอร์บางอย่างได้ยากเมื่อถึงเวลาทำนาย ให้ละเว้นฟีเจอร์เหล่านั้นจากชุดข้อมูล
ถูกต้อง ในชุดข้อมูลขนาดใหญ่ ป้ายกํากับบางรายการจะมีค่าที่ไม่ถูกต้องอยู่บ้าง แต่หากป้ายกํากับมากกว่า 1-2 เปอร์เซ็นต์ไม่ถูกต้อง โมเดลจะทําการคาดการณ์ได้ไม่ดี
ตัวแทน ชุดข้อมูลควรเป็นตัวแทนของชีวิตจริงมากที่สุด กล่าวคือ ชุดข้อมูลควรแสดงถึงเหตุการณ์ พฤติกรรมของผู้ใช้ และ/หรือปรากฏการณ์ในชีวิตจริงที่จำลองได้อย่างถูกต้อง การฝึกชุดข้อมูลที่ไม่ตรงตามความเป็นจริงอาจทําให้ประสิทธิภาพแย่ลงเมื่อระบบขอให้โมเดลทําการคาดการณ์ในชีวิตจริง
หากไม่สามารถรับข้อมูลที่จําเป็นในรูปแบบที่จําเป็นได้ โมเดลจะทําการคาดการณ์ได้ไม่ดี
ความสามารถในการคาดการณ์
ฟีเจอร์ในชุดข้อมูลควรมีความสามารถในการคาดการณ์เพื่อให้โมเดลทำการคาดการณ์ได้ดี ยิ่งฟีเจอร์หนึ่งๆ มีการเชื่อมโยงกับป้ายกำกับมากเท่าใด ก็ยิ่งมีแนวโน้มที่จะคาดการณ์ป้ายกำกับนั้น
ฟีเจอร์บางอย่างจะมีความแม่นยำในการคาดการณ์มากกว่าฟีเจอร์อื่นๆ เช่น ในชุดข้อมูลสภาพอากาศ ฟีเจอร์อย่าง cloud_coverage
, temperature
และ dew_point
จะพยากรณ์ฝนได้ดีกว่า moon_phase
หรือ day_of_week
สําหรับตัวอย่างแอปวิดีโอ คุณอาจตั้งสมมติฐานว่าฟีเจอร์ต่างๆ เช่น video_description
, length
และ views
อาจเป็นตัวบ่งชี้ที่ดีว่าผู้ใช้ต้องการดูวิดีโอใด
การพิจารณาว่าฟีเจอร์ใดมีความสามารถในการคาดการณ์อาจใช้เวลานาน คุณสามารถสำรวจความสามารถในการคาดการณ์ของฟีเจอร์ด้วยตนเองโดยการนําฟีเจอร์ออกและเพิ่มฟีเจอร์ขณะฝึกโมเดล คุณสามารถค้นหาความสามารถในการคาดการณ์ของฟีเจอร์โดยอัตโนมัติได้โดยใช้อัลกอริทึมต่างๆ เช่น Pearson correlation, Adjusted mutual information (AMI) และ Shapley value ซึ่งจะให้การประเมินเชิงตัวเลขสําหรับวิเคราะห์ความสามารถในการคาดการณ์ของฟีเจอร์
ทดสอบความเข้าใจ
ดูคําแนะนําเพิ่มเติมเกี่ยวกับการวิเคราะห์และเตรียมชุดข้อมูลได้ที่การเตรียมข้อมูลและการสร้างฟีเจอร์สําหรับแมชชีนเลิร์นนิง
การคาดการณ์เทียบกับการดำเนินการ
การคาดการณ์จะไร้ประโยชน์หากคุณไม่สามารถเปลี่ยนการคาดการณ์ให้กลายเป็นการดำเนินการที่เป็นประโยชน์ต่อผู้ใช้ กล่าวคือ ผลิตภัณฑ์ควรดําเนินการจากเอาต์พุตของโมเดล
เช่น โมเดลที่คาดการณ์ว่าผู้ใช้จะพบว่าวิดีโอมีประโยชน์หรือไม่ ควรส่งไปยังแอปที่แนะนำวิดีโอที่มีประโยชน์ โมเดลที่คาดการณ์ว่าฝนจะตกหรือไม่ควรส่งไปยังแอปพยากรณ์อากาศ
ทดสอบความเข้าใจ
พิจารณาจากสถานการณ์ต่อไปนี้ว่าการใช้ ML เป็นแนวทางแก้ปัญหาที่ดีที่สุดหรือไม่
ทีมวิศวกรในองค์กรขนาดใหญ่มีหน้าที่จัดการสายเรียกเข้า
เป้าหมาย: เพื่อแจ้งให้ผู้โทรทราบว่าจะต้องรอสายนานเท่าใดเมื่อพิจารณาจากปริมาณการโทรปัจจุบัน
ทางทีมยังไม่มีวิธีแก้ปัญหา แต่คิดว่าวิธีการแก้ปัญหาแบบเฮิวริสติกคือการหารจำนวนลูกค้าปัจจุบันที่รอสายด้วยจํานวนพนักงานที่รับสาย แล้วคูณด้วย 10 นาที อย่างไรก็ตาม ทีมทราบดีว่าลูกค้าบางรายได้รับการแก้ปัญหาภายใน 2 นาที ขณะที่ลูกค้ารายอื่นอาจใช้เวลาถึง 45 นาทีหรือนานกว่านั้น
การประเมินแบบเฮิวริสติกอาจให้ตัวเลขที่ไม่แม่นยำพอ โดยสามารถสร้างชุดข้อมูลที่มีคอลัมน์ต่อไปนี้ได้
number_of_callcenter_phones
, user_issue
,
time_to_resolve
, call_time
,
time_on_hold
time_on_hold