ทำระบบแนะนำ (Recommender System) แบบง่ายๆ — Part2: Content-Based Filtering(CBF) Algorithm คืออะไร?

เลือกใช้วิธีให้เหมาะกับปัญหา!

ต่อจาก บทความ Part 1 ก่อนหน้า เพื่อให้ทุกคนเข้าใจได้ง่าย ผมขอตั้งโจทย์ขึ้นมาสักอัน แล้วเราจะพูดถึงการแก้ปัญหาสำหรับโจทย์นี้เท่านั้น เพราะถ้าพูดกว้างจัด เดี๋ยวเนื้อหาจะยาวไป

สมมติว่า เราได้งานพัฒนาเว็บไซต์ข่าวของสำนักข่าวหนึ่งมา โดยมี Requirement ดังนี้

1. ทุกวันๆ แอดมินจะเพิ่มข่าวใหม่เข้ามาในระบบมากกว่า 100 ข่าว/วัน
2. แต่ละข่าวจะมีหมวดหมู่ (Category), ป้ายชื่อ (Tag) กำกับด้วยเสมอเพื่อจัดกลุ่มข่าว และส่งผลดีต่อการทำ SEO เวลา Search กว้างๆด้วย
3. หลังจากแอดมินเพิ่มข่าวใหม่ในเว็บไซต์แล้ว แอดมินจะนำข่าวนั้นไปโพสต์บน Social Media อื่นๆ เช่น Facebook, Twitter เพราะมีข้อมูลว่าคนส่วนมากเข้ามาอ่านข่าวเพราะเห็นเพื่อน Like หรือ Share ข่าวที่แอดมินนำไปโพสต์บน Social Media มากกว่าจะเข้ามาหาข่าวอ่านเองในเว็บไซต์ของสำนักงานฯ
4. ดังนั้นในหน้าเนื้อหาข่าวแต่ละข่าว ลูกค้าอยากให้พออ่านข่าวจบ ต้องมีข่าวที่คล้ายๆกับข่าวที่กำลังอ่าน แสดงอยู่เพื่อดึงให้คนอ่านอยู่กับเว็บให้นานที่สุด โดยกดอ่านต่อไปเรื่อยๆ

User-Interface ของหน้าเนื้อหาข่าว ที่ลูกค้าอยากได้

จาก Requirement ข้างต้น เราจะต้องเลือก Algorithm มาทำระบบแนะนำ ซึ่งมีอยู่หลาย Algorithm ให้เลือกใช้ แต่ในที่นี้เราจะเลือก Content-Based Filtering มาใช้ เพราะเหมาะกับโจทย์นี้ และสามารถอธิบายให้ลูกค้าเข้าใจได้ง่าย

(ดังนั้นอย่าพึ่งไปไหนกันนะครับ สัญญาว่าไม่ยาก ใช้แค่ความรู้ Math ม.ต้นเท่านั้น 😃)

เริ่มเลยนะครับ แนวคิดของ Algorithm นี้ก็คือ ระบบจะแนะนำเนื้อหาที่มี ความเหมือน (Similarity) มากที่สุดเมื่อเทียบกับเนื้อหาหลักที่ user กำลังเสพอยู่ โดยอาจจะเลือกมาหลายๆอัน เรียงลำดับจากเหมือนมากไปหาน้อย

ระบบแนะนำ เลือกแนะนำบทความที่มีลักษณะ (Feature) คล้ายกับบทความหลักที่ User กำลังอ่านอยู่

คำถามถัดมาคือ แล้วไอ้เจ้า ความเหมือน (Similarity) ที่เราพูดถึงไปนี้ เราจะหาค่าของมันได้อย่างไร?

ก่อนจะตอบผมอยากให้ลองนึกถึงเหตุการณ์ต่างๆในชีวิตเราดูนะครับ เวลาเราบอกว่าอะไรคล้ายกัน เช่น

“ลูกชายหน้าเหมือนพ่อจัง” เพราะเราอาจจะเห็นความคล้ายกันของ คิ้ว ตา จมูก ปาก แก้ม ของสองพ่อลูก หรือ “อาหารจานนี้รสชาติเหมือนที่แม่ทำเลย” เพราะเราอาจจะรู้สึกว่า กลิ่น รสหวาน เค็ม เผ็ด เปรี้ยว ฯลฯ ของอาหารจานนี้คล้ายกับที่กินของแม่มาก่อน

ไอ้เจ้า “คิ้ว ตา จมูก ปาก แก้ม” และ “กลิ่น รสหวาน เค็ม เผ็ด เปรี้ยว ฯลฯ” พวกนี้คือสิ่งที่เรียกว่าคุณลักษณะ (Feature) ที่เราเอาไว้ใช้แยกความเหมือน-ต่างของแต่ละอย่าง

ซึ่งในที่นี้ผมกำหนดให้ feature ของแต่ละข่าวประกอบด้วย Category และ Tag ของข่าว เมื่อระบบมี m Category มี n Tag จะได้ feature vector ของข่าว A หน้าตาประมาณนี้

feature vector ของข่าว A โดยตำแหน่งที่เป็นเลข 1 คือมีค่านั้น 0 คือไม่มีค่านั้น

ดังนั้นเราจะหาค่าความเหมือนของข่าว A เทียบกับข่าว B ได้จากการเอา feature vector ของแต่ละข่าวมาเปรียบเทียบกัน โดยการหา Cosine Similarity

เมื่อ A และ B คือ feature vector ของข่าว A และ ข่าว B

โดยค่าที่ได้ออกมาจะมีค่าตั้งแต่ 0(ไม่เหมือนเลย) ถึง 1(เหมือนเป๊ะ)

ถ้าเราอยากรู้ว่าข่าวในระบบทั้งหมดข่าวไหนเหมือน A ที่สุด? สิ่งที่เราต้องทำก็คือต้องนำ A ไปหา Cosine Similarity กับข่าวอื่นๆเหมือนที่ทำกับ B แล้วจัดลำดับเรียงตามค่า Similarity

และเพื่อให้ตอนคนเข้ามาโหลดหน้าข่าว A แล้วมีข่าวที่เหมือนกับ A แสดงอย่างรวดเร็วทันใจ เราจึงต้องหาค่าความเหมือนของข่าว A เมื่อเทียบกับข่าวอื่นไว้ก่อนตั้งแต่ตอนแอดมินเพิ่มข่าว A ในระบบ(ไม่ได้คำนวณทุกครั้งที่ถูกเรียก) ซึ่งเราเรียกกระบวนการนี้สั้นๆว่าการทำ Index

ผลสรุปนี้ช่วยย้ำสิ่งที่ผมเคยพูดแล้วในตอนต้นของบทความว่า งานที่ Developer ต้องทำเพิ่มเพื่อ Requirement ข้อ 4 คือ

1. คำนวณหาค่า Similarity ทุกครั้งที่มีการ Create/Update/Delete ข่าว เพราะต้องจัดลำดับใหม่ เมื่อมีการเพิ่มข่าวใหม่เข้ามา เมื่อแก้ไข Tag หรือ Category ของข่าวหรือลบบางข่าวออก
2. ออกแบบ/พัฒนาวิธีการจัดเก็บและเรียกใช้งาน Index (ค่า Similarity) ของข่าวทั้งหมด เพื่อให้สามารถเรียกใช้ได้อย่างรวดเร็ว

ref. https://link.springer.com/article/10.1007/s11042-013-1761-9

ซึ่งกระบวนการตรงนี้จะใช้เวลาพอสมควรเลยครับ และ Developer ที่ทำต้องมีความเข้าใจใน Algorithm นี้และรู้เรื่อง Data Structure ด้วยถึงจะทำระบบออกมาให้ Scale ได้ และรองรับจำนวนข่าวหลักหมื่นถึงแสนได้!!! …ฟังดูแล้วจะแพงเกินงบ SME หรือเปล่า? จะทำยังไงให้ต้นทุนตรงนี้ถูกลง? โปรดติดตามตอนต่อไปฮะ 😽😽

หากคุณอ่านบทความแล้ว สนใจอยากให้ทีมเข้าไปช่วยให้คำปรึกษา หา solution ด้านเทคโนโลยีให้กับธุรกิจของคุณ สามารถติดต่อเราได้ที่ www.foxbith.com