รู้ประสิทธิภาพ Recommendation ได้อย่างไร?

Recommendation System Metrics
- หากต้องการสร้าง ระบบ Recommender ที่ดีนั้น คำว่า “ดี” จะถูกวัดได้อย่างไร?
- ระบบ Recommender นั้น แตกต่างจาก Machine Learning Models อื่น ๆ นั่นคือ ความไม่แน่นอนของการวัดผล (Uncertainties of Measuring)
- ในร้านขายผลไม้ขนาดใหญ่ โดยต้องให้คำแนะนำ ผลไม้ 3 ชนิด แก่ลูกค้าทุกคน
และ เมื่อสร้าง Recommender Model แล้ว เราจะทราบถึงประสิทธิภาพของมัน ได้อย่างไร? การวัดประสิทธิภาพในหลาย ๆ Models ซึ่งโดยทั่วไปแบ่งได้ 2 ประเภท
- Classification (เช่น เป็นธุรกรรมที่ Fraud หรือไม่?) เป็น “การทำนายผลแบบไม่ต่อเนื่อง (เป็น Class)” การวัดประสิทธิภาพทำโดยใช้ Confusion Matrix, Precision, Recall, Area Under Curve (AUC), F1 score
- Regression (เช่น ลูกค้าจะใช้จ่ายเท่าไหร่?) เป็น “การทำนายผลแบบต่อเนื่อง” การวัดประสิทธิภาพ ทำโดยใช้ตัวชี้วัด เช่น R-squared, Chi-square, Mean Squared Error (MSE) และ Mean Absolute Error (MAE)
แต่ Recommender จะมีความท้าทายอื่น ๆ อีก เช่น
1. ลำดับของการแนะนำ
ความท้าทายอันหนึ่ง ของ Recommender คือ “ลำดับการแนะนำ” สมมติว่า ระบบแนะนำผลไม้ ให้กับ Alice อันดับ 1 ส้ม และ อันดับ 2 แอปเปิ้ล หากว่า Alice ชอบแอปเปิ้ล มากกว่า ส้ม Recommender ก็ควรถูกปรับปรุงเพิ่มเติม แต่ถ้าลำดับความชอบของ Alice ไม่สำคัญ Recommender ก็น่าจะดีแล้ว
ตารางที่ 1 แนะนำผลไม้ 3 ชนิดให้ Alice เปรียบเทียบ Actual และ Recommended
ลำดับความชอบ | Alice ชอบ | สิ่งที่ Recommended |
---|---|---|
1 | 🍎 | 🍊 |
2 | 🍌 | 🍎 |
3 | 🍊 | 🍌 |
ระบบทำนายผลไม้ที่ Alice ชอบ 3 อย่างได้ถูกต้อง แต่เรียงลำดับผิด ควรได้คะแนนเต็มหรือไม่?
2. แนะนำกี่รายการ
- หากจำกัดตัวเลือก 3 รายการ และยากที่จะตัดสินใจเลือก 3 รายการนั้น การเพิ่มรายการแนะนำ ที่มีความเกี่ยวข้องน้อยกว่า เรียกว่า “Marginal Relevance”
- จำนวนรายการที่เหมาะสม ควรพิจารณาสิ่งที่เกิดขึ้นในทางปฏิบัติ เช่น ผลการค้นหาเว็บของ Google ซึ่งจะให้ผลลัพธ์ทุกอย่าง แต่ในทางปฏิบัติมีการแสดงรายการ ในหน้าแรกจำนวนมาก จนมีคนบอกไว้ว่า
“สถานที่ ที่จะซ่อนศพคนตายได้ดีที่สุด คือ หน้าสองของ Google”

- มีหลายวิธี ในการเลือกว่า จำนวนกี่รายการดีที่สุด (Optimization)
- กรณี ร้านผลไม้ เราเลือก 3 ชนิด ต่อ ลูกค้าหนึ่งราย เป้าหมายในการวัด คือ รายการแนะนำที่เกี่ยวข้องมากที่สุด ในลำดับที่ดีที่สุด ควรได้ Score ที่ดีกว่า (Score สำหรับการทำนายที่ถูกต้องใกล้กับ อันดับแรก ๆ ต้อง “มากกว่า” อันดับสุดท้าย)

Score Metrics
ตารางที่ 2 แนะนำผลไม้ 3 ชนิดให้ลูกค้า 3 คน เปรียบเทียบ Actual และ Recommended
ลำดับความชอบ | Alice ชอบ | สิ่งที่ Recommended | Bob ชอบ | สิ่งที่ Recommended | Carol ชอบ | สิ่งที่ Recommended |
---|---|---|---|---|---|---|
1 | 🍎 | 🍊 (T) | 🍓 | 🍇 (T) | 🍍 | 🍋 (F) |
2 | 🍌 | 🍎 (T) | 🍋 | 🍌 (F) | 🍎 | 🍍 (T) |
3 | 🍊 | 🍌 (T) | 🍇 | 🍍 (F) | 🍇 | 🍎 (T) |
Note T = True (ทำนายถูก), F = False (ทำนายผิด)
จากตาราง สามารถคำนวณ Score ได้อย่างไร? มี Metrics ที่ต่างกัน ดังนี้
Jaccard Index
- ตัวชี้วัด “การซ้อนทับ (Overlap)” ที่ง่ายที่สุด คือ Jaccard Index โดยเปรียบเทียบ 2 ชุด ระหว่าง “Recommended” และ “Actual” มีสูตร คือ
$$J(A,B) = \frac{|A \cap B |}{| A \cup B |}$$
- หากทั้ง 2 ชุด “มีรายการที่เหมือนกันมาก” คะแนนจะใกล้ 1
- หากทั้ง 2 ชุด “ไม่มีรายการที่เหมือนกันเลย” คะแนนจะเป็น 0
- เช่น คะแนนของ Carol คือ 0.5 เพราะมีผลไม้ 2 ชนิด ที่เหมือนกัน ระหว่างชุด “Recommended” และ “Actual” แล้วหารด้วย 4 (จำนวนผลไม้ที่ไม่ซ้ำกันทั้งหมด)
- แต่ Jaccard Index จะไม่คำนึงถึงลำดับ ดังนั้น จึงมีตัวชี้วัดอีกอันหนึ่ง คือ “Mean Average Precision (MAP)”
ตัวอย่างของ Carol (จากตารางที่ 2)
ลำดับความชอบ | Carol ชอบ | สิ่งที่ Recommended |
---|---|---|
1 | 🍍 | 🍋 (F) |
2 | 🍎 | 🍍 (T) |
3 | 🍇 | 🍎 (T) |
Mean Average Precision@k เขียนย่อ MAP@k
- MAP@k - การวัดความแม่นยำเฉลี่ยของ k รายการ (เป็นวิธีการแบบไม่สมมาตร “Asymmetric approach”) และ พิจารณาลำดับของรายการที่ Recommended มีความสำคัญ คะแนนความแม่นยำจะถูกคำนวณซ้ำไปเรื่อยๆ ตามลำดับรายการที่ Recommended ไว้
- ในตัวอย่าง เราให้คำแนะนำ 3 อย่าง สำหรับ Carol : 1. มะนาว 2. สับปะรด และ 3. แอปเปิ้ล
- คำแนะนำแรก ผิด : เนื่องจาก มะนาว ไม่อยู่ในรายการโปรด 3 อันดับ ดังนั้น คะแนนที่ได้ คือ ศูนย์
- เมื่อคำนวณที่ 2 รายการที่เลือก : มะนาว - ผิด, สับปะรด - ถูก ได้คะแนนความแม่นยำ 1/2
- เมื่อคำนวณทั้ง 3 รายการที่เลือก : ความแม่นยำคือ 2/3 (ทายถูก 2 จาก 3 ครั้ง)
- ดังนั้น จะได้คะแนนเฉลี่ย 0.39
- การจัดลำดับ จะมีความสำคัญ เนื่องจากคะแนนความแม่นยำสูงในอันดับแรก ๆ จะได้ Score ที่มากกว่า
ตารางที่ 3 การคำนวณ Score Metrics และคะแนนเฉลี่ย
ลำดับความชอบ | Alice ชอบ | สิ่งที่ Recommended | Bob ชอบ | สิ่งที่ Recommended | Carol ชอบ | สิ่งที่ Recommended |
---|---|---|---|---|---|---|
1 | 🍎 | 🍊 (T) | 🍓 | 🍇 (T) | 🍍 | 🍋 (F) |
2 | 🍌 | 🍎 (T) | 🍋 | 🍌 (F) | 🍎 | 🍍 (T) |
3 | 🍊 | 🍌 (T) | 🍇 | 🍍 (F) | 🍇 | 🍎 (T) |
MAP@3 | 1 | 0.33 | 0.39 | |||
Jaccard | 1 | 0.2 | 0.5 |
คะแนนเฉลี่ย
$$ \textrm{MAP@3} = \frac{1+0.33+0.39}{3} = 0.574$$
$$ \textrm{Jaccard} = \frac{1+0.2+0.5}{3} = 0.566$$
ตัวชี้วัดอื่น ๆ
- โดยทั่วไป MAP@k จะลดลงเมื่อ k มากขึ้น มีตัวชี้วัดอื่น ๆ เช่น Mean Average Recall@k ซึ่งเพิ่มขึ้น เมื่อ k มากขึ้น และ Mean Average F1@k ซึ่งมีค่าสูงสุดที่ค่ากลางของ k
- สามารถตัดสินได้ว่า “ลำดับ” มีความสำคัญ ทั้งในรายการ “Actual” และ ”Recommended” ซึ่งจะนำไปสู่การให้ Score เพิ่มเติม เพื่อให้ได้ความชอบของลูกค้า ตามลำดับที่ดีที่สุด ตัวอย่างเช่น Normalized Discounted Cumulative Gain (NDCG) เป็นวิธีให้ Score ของรายการที่เรียงลำดับอันหนึ่ง สามารถร่วมกับตัวชี้วัดการให้คะแนนอื่น ๆ (และยังนิยมใช้ สำหรับการจัดอันดับการค้นหาเว็บ)

การเปรียบเทียบพื้นฐาน (Baseline Comparison)
- ใน Metrics ที่เรามี จะเป็นเพียงค่าตัวเลข แต่ ในการวัดประสิทธิภาพ จำเป็นต้องสร้าง Model พื้นฐาน (Baseline) เพื่อการเปรียบเทียบ เช่น เราสามารถเลือกแนะนำผลไม้ 3 ชนิด ที่ได้รับความนิยมสูงสุด สำหรับทุกคน : กล้วย แอปเปิ้ล และ สตรอเบอร์รี่
- หากใช้ Score “ผลไม้ยอดนิยม” เป็น Model พื้นฐาน มันอาจมีประสิทธิภาพสูงกว่า Model ที่ซับซ้อน (ที่เราสร้าง) แต่ต้องไม่ลืมว่า “Model พื้นฐาน” นี้ จะขาดความหลากหลายเนื่องจากมีเพียง ผลไม้แค่ 3 ชนิดเท่านั้น ซึ่งผลไม้อื่นจะไม่ถูกแนะนำ
- ข้อเสียอื่น ๆ เกี่ยวกับการใช้ Model พื้นฐาน ในทางปฏิบัติ คือ “Banana problem” เกิดขึ้นเมื่อรายการบางอย่าง ลูกค้าจะซื้ออยู่แล้ว โดยไม่คำนึงถึงการได้รับการแนะนำ โดยเฉพาะรายการที่ได้รับความนิยมมากๆ มันควรถูกซ่อนไว้
- Recommender ที่มีประสิทธิภาพ ควรมีองค์ประกอบคำติชม ทำให้ลูกค้าพบกับรายการแนะนำใหม่ ที่ยังไม่เคยเจอ
- เป็นเรื่องยากที่จะทำ Recommender แบบ Off-line เนื่องจากพฤติกรรมของลูกค้า ไม่สามารถประเมินในชุดข้อมูลแบบ Static ได้ (ควรเป็น Online หรือ ชุดข้อมูลแบบ Dynamic)
ตารางที่ 4 ตัวอย่าง Baseline (ผลไม้ยอดนิยม: กล้วย แอปเปิ้ล สตรอว์เบอร์รี)
ลำดับความชอบ | Alice ชอบ | สิ่งที่ Recommended | Bob ชอบ | สิ่งที่ Recommended | Carol ชอบ | สิ่งที่ Recommended |
---|---|---|---|---|---|---|
1 | 🍎 | 🍌 (T) | 🍓 | 🍌 (F) | 🍍 | 🍌 (F) |
2 | 🍌 | 🍎 (T) | 🍋 | 🍎 (F) | 🍎 | 🍎 (T) |
3 | 🍊 | 🍓 (F) | 🍇 | 🍓 (T) | 🍇 | 🍓 (T) |
MAP@3 | 0.67 | 0.11 | 0.39 | |||
Jaccard | 0.5 | 0.2 | 0.5 |
คะแนนเฉลี่ย
$$ \textrm{MAP@3} = \frac{0.67+0.11+0.39}{3} = 0.39$$
$$ \textrm{Jaccard} = \frac{0.5+0.2+0.5}{3} = 0.39$$
การแบ่ง Train / Test
- ต้องแน่ใจว่าลูกค้าแต่ละราย มีข้อมูลเพียงพอ เช่น ถ้า Alice, Bob และ Carol ซื้อผลไม้ 6 ชิ้น เราสามารถใช้ 3 ชุด สำหรับ Train และ อีก 3 ชุด สำหรับ Test
$$\textrm{Train :} 🍓 🍇 🍋 $$
$$\textrm{Test :} 🍎 🍌 🍊 $$
- ในการแบ่ง Train / Test มีข้อควรพิจารณาเพิ่มเติม เช่น
- การละเลยเรื่อง Causality : เป็นไปได้ว่ารายการที่ใช้ในชุดข้อมูล Train ถูกซื้อทีหลังชุดข้อมูล Test (เว้นแต่ว่า เราจะกำหนดการตัดเวลา)
- อาจต้องตัดข้อมูลลูกค้าที่มีประวัติการซื้อน้อย จากข้อมูล Train (เพราะอาจจะ bias เมื่อเทียบกับกลุ่มลูกค้าที่ซื้อบ่อย)
- กรณี Train model สำหรับของที่ซื้อไม่บ่อย เช่น บ้าน หรือ รถยนต์ อาจขึ้นอยู่กับข้อมูล Profile ของลูกค้า (แหล่งข้อมูลภายนอก)
- เราต้องตัดสินใจว่าอะไร ที่เกี่ยวข้องกับ โจทย์ / สถานการณ์ ของเรา
******
ข้อมูลอ้างอิง - https://www.kdnuggets.com/2020/02/comparing-apples-oranges-bananas.html