ทําความเข้าใจปัญหา

เพื่อทำความเข้าใจปัญหา ให้ดำเนินการดังต่อไปนี้:

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

ระบุเป้าหมาย

มาเริ่มกล่าวเป้าหมายด้วยคำที่ไม่ใช่ ML ก่อน เป้าหมายคือคำตอบสำหรับคำถาม ที่ว่า "ฉันพยายามทำอะไรอยู่"

ตารางต่อไปนี้ระบุเป้าหมายสำหรับแอปสมมติอย่างชัดเจน

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

ล้าง Use Case สำหรับ ML

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

ระบบ ML แบ่งได้เป็น 2 หมวดหมู่กว้างๆ ได้แก่ ML ตามการคาดการณ์และ generative AI ตารางต่อไปนี้แสดงลักษณะเฉพาะที่กำหนด

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

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

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

  • คุณภาพ คุณคิดว่าโซลูชัน ML จะดีกว่ามากแค่ไหน หากคุณคิดว่าโซลูชัน ML อาจเป็นเพียงการปรับปรุงเล็กๆ น้อยๆ อาจชี้ให้เห็นว่าโซลูชันปัจจุบันเป็นโซลูชันที่ดีที่สุด

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

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

ทำความเข้าใจ

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

ML และข้อมูลตามการคาดการณ์

ข้อมูลคือพลังขับเคลื่อนของ ML แบบคาดการณ์ หากต้องการสร้างการคาดการณ์ที่ดี คุณต้องมีข้อมูลที่มีฟีเจอร์ซึ่งใช้การคาดการณ์ได้ ข้อมูลของคุณควรมีลักษณะดังต่อไปนี้

  • มากมาย ยิ่งตัวอย่างที่เกี่ยวข้องและเป็นประโยชน์ในชุดข้อมูลมากเท่าไร โมเดลของคุณก็ยิ่งดีขึ้นเท่านั้น

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

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

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

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

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

หากคุณไม่สามารถรับข้อมูลที่คุณต้องการในรูปแบบที่กำหนด โมเดลของคุณจะทำการคาดการณ์ได้ไม่ดี

พลังการคาดการณ์

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

บางฟีเจอร์จะใช้คาดการณ์ได้มากกว่าฟีเจอร์อื่น เช่น ในชุดข้อมูลสภาพอากาศ ฟีเจอร์ต่างๆ เช่น cloud_coverage, temperature และ dew_point จะเป็นตัวคาดการณ์ปริมาณฝนที่ดีกว่า moon_phase หรือ day_of_week สำหรับตัวอย่างของแอปวิดีโอ คุณสามารถตั้งสมมติฐานว่าฟีเจอร์อย่าง video_description, length และ views อาจเป็นตัวคาดการณ์ที่ดีสำหรับวิดีโอที่ผู้ใช้ต้องการรับชมได้

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

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

ทำความเข้าใจ

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

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

การคาดการณ์กับการดำเนินการ

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

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

ทำความเข้าใจ

จากสถานการณ์ต่อไปนี้ ให้พิจารณาว่าการใช้ ML เป็นวิธีที่ดีที่สุดในการแก้ปัญหาหรือไม่

ทีมวิศวกรขององค์กรขนาดใหญ่มีหน้าที่รับผิดชอบในการจัดการสายเรียกเข้า

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

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

การเรียนรู้ของผู้เรียนอาจไม่ได้นับว่าได้จำนวนที่แม่นยำมากพอ โดยจะสร้างชุดข้อมูลด้วยคอลัมน์ต่อไปนี้ number_of_callcenter_phones, user_issue, time_to_resolve, call_time, time_on_hold ได้

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