วิธีคิด Problem Framing สำหรับโปรเจ็ค ML แบบฉบับ Google

Google เปิดตัวคอร์สเรียนใหม่ Problem Framing สำหรับโปรเจ็ค Machine Learning (ML) คอร์สสั้นๆใช้เวลาเรียนประมาณ 45 นาที พอเรียนจบ เราจะสามารถทำสามอย่างนี้ได้เลย

1. วิเคราะห์ปัญหาดูว่า ML เหมาะสมที่จะแก้ปัญหานั้นได้มั้ย
2. วิธีการคิดและตีกรอบปัญหา ML
3. เข้าใจพื้นฐานวิธีการเลือกโมเดล และการวัดผลโมเดลด้วย success metrics

✅ ส่วนตัวแอดคิดว่า problem framing เป็นทักษะที่สำคัญมากเลย โดยเฉพาะ business users ที่อยากเอา ML มาใช้แก้โจทย์ทางธุรกิจ จะได้คุยกับทีม engineer ได้ง่ายขึ้นด้วยครับ

บทความนี้แอดเขียนสรุปเนื้อหาของคอร์สนี้มาให้อ่านกันแล้วครับ ลุยเลย 😊

Table of Contents

What is Problem Framing

ทีม Google Tensorflow ให้คำนิยามคำว่า “Problem Framing” [PF] คือการวิเคราะห์ว่า machine learning เป็นทางเลือกที่ดี เหมาะสมกับปัญหาที่เราเจอตรงหน้าหรือเปล่า

PF เป็นขั้นตอนสำคัญก่อนเริ่มการทำโปรเจ็ค ML ดูเรื่อง technical feasibility กำหนดเป้าหมายและวิธีการวัดผล success criteria

Problem Framing teaches you how to determine if machine learning (ML) is a good approach for a problem and explains how to outline an ML solution

Google

การทำ problem framing จะแบ่งออกเป็น 2 ขั้นตอน

1. Understanding – วิเคราะห์ว่า ML คือ solution ที่เหมาะสมกับปัญหานั้นๆหรือเปล่า
2. Framing – ตีโจทย์ให้อยู่ในรูปแบบที่ ML สามารถแก้ไขได้

ถ้าพร้อมแล้วมาเริ่มกันที่ step แรกกันเลยครับ

Understand The Problem

Google แนะนำ 3 ขั้นตอนในการทำความเข้าใจปัญหา

1. ตั้งเป้าหมาย สิ่งที่เราอยากรู้ (อยากได้คำตอบ)
2. มี use cases ที่ชัดเจนสำหรับ ML
3. เช็คว่ามีข้อมูลเพียงพอที่จะเทรนโมเดลหรือเปล่า

Goal => What am I trying to accomplish? ตัวอย่างเช่น โจทย์ของ mail app คือหา spam ส่วน streaming app คือการแนะนำ series หรือเพลงที่เหมาะกับ users คนนั้นๆ

Clear Use Cases for ML

หลายคนคิดว่า ML คือทางออกสำหรับทุกอย่างแต่จริงๆ ML ยังค่อนข้างจำกัดมากๆในแง่ของ use cases บางปัญหาแค่ใช้ non-ML solutions ง่ายๆก็แก้ได้เหมือนกัน

ก่อนจะตัดสินใจใช้ ML ให้ลองถามคำถามสองข้อเกี่ยวกับ Quality และ Cost/ Maintenance

• Quality – การใช้ ML จะดีกว่า solutions ที่เราทำอยู่ตอนนี้มากหรือน้อยเพียงใด?
• Cost and Maintenance – คุ้มค่าที่จะลงทุนจริงๆหรือเปล่า? ต้องจ้าง ML engineers เพิ่มมากี่คน และการดูแลรักษาโมเดลใน production จะทำกันยังไง (Google ใช้คำว่า long-term maintenance)

✅ เราใช้ non-ML solutions เป็น benchmark เพื่อดูว่า ML จะเหมาะสมกับปัญหานั้นหรือเปล่า cost-benefit analysis เปรียบเทียบ cost vs. benefit เพื่อหา optimized ML solution

Data

ถ้าอยากจะได้โมเดลที่มีคุณภาพดี ทำนายได้แม่น โมเดลของเราจำเป็นต้องมี features (หรือตัวแปรต้น) ที่มีพลังในการทำนาย i..e predictive power

Google เสนอว่า data ที่ดีต้องมีลักษณะต่อไปนี้ (ตรงนี้แนะนำให้อ่านบทเรียนของ Google เพิ่มนะครับ เวลาแอดแปลจะมี lost in translation นิดหน่อย 😐)

• Abundant – ยิ่งมากยิ่งดี
• Consistent and reliable – มีความต่อเนื่องและน่าเชื่อถือ
• Trusted – รู้แหล่งที่มาของข้อมูล
• Available – ข้อมูลอยู่ใน format ที่ถูกต้องตอนโมเดลทำ prediction
• Correct – ข้อมูลมี label ถูกต้อง
• Representative – ข้อมูลที่เหมาะสมกับปัญหา

ถ้าเราหาข้อมูลในรูปแบบที่เราต้องการไม่ได้ มีโอกาสสูงมากที่โมเดลจะพัง ไปไม่รอดถึง production (เอาจริงคือน่าจะตายตั้งแต่ตอน training/ testing แล้ว เช่น ปัญหา underfitting)

✅ อธิบายเพิ่มเติมเรื่อง Predictive Power คือการที่ตัวแปร features มีค่า correlation สูงๆกับตัวแปร label ที่โมเดลเราต้องการทำนาย

ทุกวันนี้เราสามารถใช้ automated algorithms เพื่อช่วยหา features ให้เราได้ด้วย เช่น

• Pearson correlation
• Adjusted mutual information (AMI)
• Shapley value

Predictions vs. Actions

พอเราเทรนโมเดลเสร็จแล้ว ต้องทำยังไงต่อ? เราต้องเปลี่ยนผลลัพธ์ของ model ให้เป็น action ที่ตอบโจทย์ users

Your product should take action from the model’s output

Google

ในทาง business คือการเปลี่ยน model output เป็น business outcome เช่น โมเดล product recommendation เราทำนายแม่นยำขึ้น accuracy +5% ผู้ใช้งานได้สินค้าและบริการตรงใจยิ่งขึ้น ส่งผลให้รายได้บริษัทโตขึ้น +200K

OK! ก่อนจะไปกันต่อ มาลองดู check list สิ่งที่เราต้องมีกันก่อน

✅ โจทย์ ML ชัดเจน ✅ มี Data พร้อมใช้งาน ✅ เป็นการลงทุนที่คุ้มค่า

Frame an ML Problem

ถ้า check list เราผ่านหมด ก็เข้าสู่ขั้นตอนที่สองกันได้เลยคือการทำ Framing แบ่งเป็น 3 ขั้นตอนย่อยๆ

1. กำหนดผลลัพธ์ และเป้าหมายของการสร้างโมเดล
2. รู้ว่า model output ที่ได้จะออกมาเป็นอะไร
3. กำหนด success metrics เป็นตัวชี้วัดความสำเร็จ

Define The Ideal Outcome

Ideal outcome คือสิ่งที่ business/ users อยากได้ ส่วน model’s goal คือสิ่งที่โมเดลต้องทำให้สำเร็จ การเชื่อมสองอย่างนี้เข้าด้วยกันจะช่วยให้งานของทีมเรามีความหมายทันที

Choose The Right Kind of Model

ประเภทโมเดลที่เราเลือกใช้ขึ้นอยู่กับ context และ constraints ของปัญหา ในคอร์สเรียน Google จะโฟกัสที่ supervised learning หรือโมเดลที่เน้นการทำนายค่าเป็นหลัก

• Classification ทำนาย category หรือ class เช่น A, B, C
• Regression ทำนาย numeric value หรือ number บนช่วงหนึ่งๆ (a number line)

ในพาร์ทเรียนนี้ Google ยกตัวอย่าง case study การทำ caching videos ที่กำลังได้รับความนิยม โดยเราจะ cache วีดีโอที่คนดูเยอะๆ เพื่อที่เราจะได้ serve contents ได้เร็ว

✅ สำหรับปัญหา caching – Google แนะนำว่า regression เป็นตัวเลือกที่ดีที่สุด i.e. best choice เพราะ treshold มีความ dynamic เปลี่ยนได้ตลอดตามพฤติกรรมคนดู เช่น

• ถ้า video views > 50 ให้ใช้ expensive cache
• ถ้า video views อยู่ระหว่าง [30, 50] ให้ใช้ cheap cache
• ถ้า video views < 30 ไม่ต้องทำการ cache ใดๆ

แต่ถ้าปัญหาเป็นแบบ fixed thresholds เปลี่ยนไปใช้ classification model จะดีกว่า

Identify The Model’s Output

Google อธิบาย subtypes ของโมเดล classification/ regression ไว้ดังนี้

• Classification
  • Binary
  • Multiclass
    • Single-label
    • Multi-label
• Regression
  • Unidimensional
  • Multidimensional เช่น การทำนาย longitude/ latitude

✅ บางครั้งค่าที่เราต้องการทำนายจริงๆไม่มีอยู่ใน dataset เราต้องหา Proxy Labels มาใช้แทน เหมือนเป็นตัวแทนที่ใกล้เคียงที่สุด ที่เราจะหาได้ในเวลานั้น

ตัวอย่างเช่น ถ้า streaming app ของเราต้องการแนะนำวีดีโอที่มีประโยชน์ให้กับ users แต่ในข้อมูลของเราไม่มีคอลัมน์ userful_to_user ค่า proxy labels ที่เราหยิบมาใช้ได้อาจจะเป็นคอลัมน์ liked หรือ shared แทน

แต่เราต้องใช้ proxy labels อย่างระมัดระวัง เพราะมันไม่ได้วัดค่าที่เราต้องการตรงๆ และอาจสร้าง bias บางอย่างให้กับโมเดลของเรา เช่น โมเดลที่ทำนาย liked เยอะเกินไปจนกลายเป็น clickbait

Define The Success Metrics

Google อธิบายว่า success metrics แตกต่างจาก model’s evaluation metrics เช่น accuracy, precision, recall, f1-score หรือ AUC

Google แนะนำให้เราตั้ง success metrics แบบสูงๆไปเลย i.e. high ambitions เป้าหมายของโมเดลเราคือการเข้าใกล้ goals ที่ตั้งไว้เรื่อยๆ

What’s important is your model’s capacity to move closer—or exceed—the definition of success

Google

โมเดลเราอาจจะมีค่า evaluation metrics ที่ดูไม่ค่อยดี แต่ถ้ามันลด gap ระหว่างปัจจุบันกับเป้าหมายของเราได้ ก็ถือว่าเป็นโมเดลที่ดีเพราะมี progress เข้าสู่ ambition ที่ตั้งไว้

มาลองดูตัวอย่างสอง apps ด้านล่าง weather/ streaming app

🌞 Weather App

• Success – Users กดใช้ฟีเจอร์ใหม่ของเรามากขึ้นกว่าเดิม 50%
• Failure – Users กดใช้ฟีเจอร์ไม่ต่างจากเดิมเลย

📺 Streaming App

• Success – Users ใช้เวลาบนเว็บไซต์เรานานขึ้น 20%
• Failure – Users ใช้เวลาบนเว็บไซต์เราไม่ต่างจากเดิมเลย

หลังจากเราได้ success/ failure metrics แล้ว เราต้องคิดต่อว่าเราจะวัดผลโมเดลเราบ่อยแค่ไหน เช่น ทุกๆ 7 วัน, 14 วัน, 28 วัน ถ้าเรื่องนั้นสำคัญมากกับเรา อาจจะต้องวัดมันถี่หน่อย

Google แนะนำว่าเวลาที่วิเคราะห์ failure metrics ลองพยายามหาเหตุผลว่าทำไมโมเดลถึงพัง เช่น โมเดลที่แนะนำ videos ที่ users อยากจะกดดู อาจจะเริ่มแนะนำ clickbait titles

สรุปพาร์ทนี้แอดได้มุมมองใหม่หลายอย่างเลย เราทำโมเดลไม่ใช่เพื่อ high evalutation metrics แต่เป็นการปิดช่องว่างของสิ่งที่เราทำได้ในปัจจุบันกับ ambitions ของเรา เฉียบ!

Implement A Model

Google แนะนำว่าเราควรจะเริ่มแบบง่ายๆ start simple เวลาจะสร้างโมเดล

• ออกแบบ data pipeline สำหรับโมเดลเวอร์ชันแรกที่ง่ายที่สุดก่อน
• แล้วค่อยๆ iterate ทำให้โมเดลของเราดีขึ้นเรื่อยๆ (ซับซ้อนขึ้น แม่นยำขึ้น)

✅ ข้อดีของ simple model คือเราใช้มันเป็น baseline และเป็นตัว benchmark ว่า complex model นั้นคุ้มค่าที่จะทำหรือเปล่า? ทุกการตัดสินใจของเราคือการ tradeoff cost vs. benefit

หลักการของ ML คือถ้าโมเดลเก่งขึ้น (more complex) มักจะมีต้นทุนอื่นๆสูงขึ้นด้วย เช่น เวลาในการเทรนนานขึ้น เงินที่ต้องใช้มากขึ้น cost อาจจะไม่คุ้มกับ performance gain ที่ได้กลับมา

Pre-Trained vs. Own Model

อีกหนึ่งเรื่องที่เราต้องตัดสินใจคือการใช้ pre-trained models หรือจะเขียนโค้ดสร้าง custom ML model ของตัวเอง หลายๆงานเราสามารถประยุกต์ใช้ pre-trained หรือ transfer learning เพื่อพัฒนา ML solution ที่ใช้งานจริงได้เลย

Monitoring

ขั้นตอนการ deploy model ในฝั่ง ML/AI จะใช้หลักการของ MLOps

ในพาร์ทนี้จะเน้นเรื่อง operation เป็นหลัก ทีม MLOps จะค่อย monitor ระบบและโครงสร้างพื้นฐานที่โมเดลของเราทำงานอยู่

MLOps = continuous delivery and automation pipelines in machine learning

Google

แล้วเราต้อง monitor อะไรบ้าง Google แนะนำในคอร์สนี้ว่าต้องพิจารณา 3 เรื่อง

• Model deployment ถ้าโมเดลใหม่ทำงานได้แย่กว่าเดิม ให้หยุดการ deploy หรือ rollback กลับไปเวอร์ชันก่อนหน้า
• Training-serving skew ตรวจสอบข้อมูลและผลทำนายว่าอยู่ใน range ที่รับได้หรือเปล่า
• Inference server ดูว่า server ยังทำงานได้ถูกต้องหรือเปล่า ส่งค่า prediction ออกมาได้มั้ย

---

จบแล้วสำหรับคอร์ส Introduction to ML Problem Framing หวังว่าเพื่อนๆจะได้ความรู้พื้นฐานเกี่ยวกับการสร้างโปรเจ็ค ML ไว้ใช้ในอนาคตนะครับ เพียงสองขั้นตอนง่ายๆ!

• Understanding the problem
• Framing an ML problem

ส่วนตัวแอดว่าคอร์สนี้ดีมากๆเลย มีหลายเรื่องที่เรานำไปปรับใช้ได้จริง เต็ม 10/10 ไม่หัก ⭐

Note – Google แชร์แหล่งเรียนรู้อื่นๆเกี่ยวกับ problem framing ในพาร์ท summary and next steps มีแบบฝึกหัดให้ลองเขียน problem statement และวิธีการคิด ML solution