The Data Science — Hierarchy of Needs: เรื่องง่ายๆ ที่หลายคนไม่เคยรู้
สิ่งที่กวนใจผมตลอดเวลาก็คือ (ผู้บริหาร)หลายองค์กรนั้น ชอบบอกว่า อยากได้ AI
แต่เมื่อถามว่า อยากเอา AI ไปทำอะไรนั้น กลับไม่มีคำตอบที่ชัดเจน คิดแค่ว่า ถ้ามี AI แล้ว จะทำให้ธุรกิจผลิกผันแบบหน้ามือเป็นหลังมือ กดปุ่มเดียว AI ช่วยคิดกลยุทธ์มาให้เลยว่าต้องทำอะไร (พี่จ๋าาา พี่ไปดูหนังเรื่องอะไรมา) แล้วองค์กรเหล่านี้ ก็ไปให้ Recruiter (ทั้งในบริษัท และ Head Hunter ผู้ซึ่งไม่รู้เหนือรู้ใต้) ไปกวาดต้อนคนมาให้ เพื่อดำรงตำแหน่งอันทรงเกียรติสูงสุดยิ่ง นั่นก็คือ Data Scientist
[เคยมี Head Hunter โทรติดต่อเข้ามา เพื่ออยากให้ผมไปสัมภาษณ์งานกับบริษัทแห่งหนึ่ง เลยถาม Head Hunter ไปว่า ตำแหน่งนี้เค้าให้ทำอะไร Head Hunter ก็เลยถามกลับว่า นั่นน่ะสิ ตำแหน่งนี้ทำอะไรเหรอ -..-? ]
ระหว่างนั่งดู Youtube ไปเรื่อยๆ ก็เจอ VDO หนึ่งที่พยายามอธิบายเรื่อง Data Science (https://www.youtube.com/watch?v=xC-c7E5PK0Y&t=337s) แล้วรู้สึกว่าน่าสนใจและมีประโยชน์มาก เลยจะเอามาเล่าให้ฟังว่า Hierarchy of Needs ใน Data Science คืออะไร แล้วแต่ละองค์กรควรเริ่มต้นอย่างไรบ้าง
Hierarchy of Needs ใน Data Science
รูปนี้ ได้มาจากบทความที่เขียนไว้ใน hackernoon.com https://hackernoon.com/the-ai-hierarchy-of-needs-18f111fcc007 ผู้เขียนบอกว่า เค้าได้เรียนรู้เรื่องนี้จาก Shopify (ผมพยายามหาต้นฉบับแล้ว ยังหาไม่เจอ ใครทราบ ฝากแชร์ด้วยครับ) เพื่อบอกลำดับชั้นความต้องการของ Data Science โดยใครก็ตามที่อยากจะเริ่มสร้างความแข็งแกร่งทางด้าน Data ให้กับองค์กร ก็ควรเริ่มจากล่างขึ้นบน ดังนี้
1. Collect: เริ่มต้นจากการเก็บข้อมูลก่อนเลยครับ ไม่ใช่แค่เก็บแค่ transaction data ที่เกิดขึ้นเท่านั้นนะครับ เพราะอันนั้นเป็นแค่เพียง financial data แต่ยังมี non-financial data อีกมากมาย ที่ท้ายที่สุดจะกลับมาเป็น signal หรือ ตัวช่วยทำนายพวก financial transactions ให้เรา เช่น พวก web click หรือ ข้อมูลที่ลูกค้า interact กับเรา ถ้าเราเป็น digital business ก็จะมีข้อมูลมากมายให้เก็บผ่าน website ซึ่งเราก็สามารถใช้พวก Google Analytics มาช่วยในการ track ข้อมูลเหล่านี้ (คนในวงการก็จะพูดกันว่าติด tag ก็คือ การเอา code ไปติด tag ตามหน้าเว็บ ตามปุ่มต่างๆ ให้มีการเก็บข้อมูลกันครับ)
นอกจากนี้ ก็ยังต้องมีการเก็บข้อมูลพวก การราคาที่ปรับเปลี่ยนไปแต่ละวัน จำนวน inventory หรือ promotion หลายบริษัทเลยที่ไม่สามารถบอกได้ว่า transaction เป็นการซื้อที่เกิดจาก promotion หรือไม่ ดังนั้น ควรเริ่มตั้งสติกับการเก็บข้อมูลก่อนครับ
2. Move/Store: เมื่อมี data แล้ว ก็อย่าปล่อยให้ท่วมขังเป็นน้ำเน่า เราก็ต้องมีการขนถ่ายน้ำดีไปเก็บไว้ในทะเลสาปศักดิ์สิทธิ์ของเรา หรือ Data Lake การลำเลียงขนถ่าย หรือการสร้าง data pipeline นั้น เป็นสิ่งที่เราต้องให้ความสำคัญอย่างมากครับ เพราะจะเป็นรากฐานที่มั่นคงของระบบการวิเคราะห์ข้อมูล (ลองนึกถึงว่า จังหวะที่ธุรกิจกำลังอยู่ในช่วงหัวเลี้ยวหัวต่อ แล้วต้องรอข้อมูลอีกซัก 3 วัน ถึงจะตอบได้ว่าเกิดอะไรขึ้นสิครับ ฝันร้ายของผู้บริหารหลายคนเลยแหละ)
ณ จุดนี้ เราต้องการทีมงาน data engineering ที่แข็งแกร่ง มาช่วยในการสร้าง data pipeline ซึ่งเป็นระบบที่รวบรวม กวาดข้อมูลจากทุกแหล่ง ทุกระบบให้ไหล เข้าสู่ระบบวิเคราะห์ข้อมูลของเราได้อย่างมีประสิทธิภาพ หรือ ข้อมูลเข้ามาไม่ช้าไป เข้ามาครบถ้วน เข้ามาแล้วนำไปใช้ได้ (ลองตั้งคำถามกับบริษัทตัวเองง่ายๆ ก็ได้ครับ ว่า ทุกวันนี้ ข้อมูลที่ไหลเข้าสู่ระบบวิเคราะห์ข้อมูลนั้น มี time gap เท่าไหร่ ถ้า ข้อมูลคุณ update ช้ากว่า 1 วันนี่ ก็ไม่ไหวแล้วครับ) การสร้าง data pipeline ไม่ใช่เรื่องง่ายๆ ที่จะเอาใครมาทำก็ได้นะครับ ถ้าคนที่ไม่เข้าใจ nature ของการทำงานกับ data แล้ว คุยแล้วอยากจะร้องไห้
[ไหนๆ ก็ไหนๆ ขอเมาท์หน่อยแล้วกัน เคยคุยกับ CTO ท่านหนึ่ง เค้าก็บอกว่า นี่ไง ก็สร้างระบบทำ data pipeline ง่ายๆ เขียนโปรแกรมแปปเดียวก็เสร็จแล้ว พอผมทักว่า แล้วระบบจะจัดการยังไง ถ้าฐานข้อมูลต้นทางมีการเปลี่ยนแปลงโครงสร้าง เค้าก็บอกว่าง่ายมาก ระบบนี้จะเก่งฉลาดมาก สามารถตรวจเจอได้ว่าโครงสร้างตารางเปลี่ยนหรือไม่ ผมก็ขี้เกียจจะเถียง ผ่านไปหลายปี ระบบที่ว่านี่ จะล่มตลอดเวลา เมื่อโครงสร้างตารางเปลี่ยนแปลง ต้องบอกว่า ระบบมันตรวจง่ายมากว่า โครงสร้างตารางเหมือนเดิมหรือไม่ แต่การจัดการ pipeline เมื่อโครงสร้างตารางเปลี่ยนแปลงนั้นไม่ง่ายเลยครับ]
3. Explore/Transform: ขั้นตอนนี้ ก็เป็นอีกขั้นตอนที่ใช้พลังงานมากเหลือเกิน เป็นขั้นตอนที่เราต้องมาสำรวจดูว่า ข้อมูลของเราดีร้ายอย่างไร เอาไปใช้ได้ไหม ต้องเอามาผสมควบรวมกับฐานข้อมูลอื่นอย่างไร มีความผิดปกติอย่างไร ต้องทำความสะอาดข้อมูลไหม ต้องนำมาคำนวณหรือเปล่า ต้องนำมาจัด format ใหม่ไหม เช่น เพศของลูกค้าในฐานข้อมูลจะเก็บเป็น 0 และ 1 ก็ต้องมาเปลี่ยนเป็น Male และ Female เป็นต้น หรือ ถ้าให้ลูกค้ากรอกชื่อจังหวัดเข้ามาเอง อันนี้ก็เตรียมฝันร้ายได้เลย เคยทำโปรเจคนึง พบว่า แค่ กรุงเทพมหานคร นี่ก็เขียนกันไปได้สามสิบกว่าแบบเลยครับ อันนี่ เจ็บปวดสุด ก็น่าจะเป็น เบอร์โทรศัพท์ กรอกกันเข้ามาหลากหลายรูปแบบมากครับ เกลียดใคร ให้ส่งคอลัมภ์นี้ให้เค้าไป clean เลยครับ
นอกจากนี้ ก็ยังมีข้อมูลที่ดูเหมือนจะผิด แต่จริงๆ ไม่ผิด เช่น มีลูกค้าที่เข้ามาใช้บริการมากผิดปกติ เช่น ปกติลูกค้าควรจะมาซื้อมากสุด ก็ 2–3 ครั้งต่อวัน แต่มีลูกค้าบางคนมาซื้อมากถึง 10 ครั้งต่อวัน อันนี้ให้ลองไปเจาะดูต่อเลยครับ ว่าเป็นพวก Fraud หรือเปล่า จากประสบการณ์ คือ พวก extremely heavy usage นี่ โดยมากจะเป็น Fraud แทบทั้งนั้นเลยครับ
ความยากของการทำ data preparation ก็คือ ธุรกิจส่วนมากจะมี Business Rules ที่ซับซ้อนซ่อนอยู่ เป็นสิ่งที่คนหน้างานเข้าใจ แต่คนที่ทำ data ซึ่งแทบไม่มีโอกาสเห็นกระบวนการหน้างานเลยไม่เข้าใจ เช่น โปรโมชันสินค้าจัดเฉพาะช่วงปีใหม่เท่านั้น แต่ก็ยังมี transaction ขายที่เกี่ยวข้องกับโปรโมชันนี้หลังปีใหม่อยู่ พอไปถาม Sales เค้าก็จะบอกว่า พอดียอดไม่ดี เลยโทรไปให้ลูกค้าบางคนช่วยอุดหนุนเพิ่ม (ก็จบง่ายๆ แบบนี้แหละ เวลาเจอข้อมูลประหลาดๆ) หรือ บางระบบไม่สามารถทำคืนสินค้ารายชิ้นได้ ต้องยกเลิกทั้งบิล แล้วทำบิลใหม่ ทำให้ดูเหมือนมีการคืนสินค้าเยอะ ทั้งที่จริงๆ แล้ว ไม่ได้คืนทั้งหมด (แค่มันกรอกไม่ได้จ้า)
ในโลกใบนี้ น้อยบริษัทเหลือเกินที่จะมีคนทำ Document เกี่ยวกับ Business Rules เหล่านี้ (ไม่ต้องบ่นถึงพวก Data Dictionary นะครับ อันนั้นถึงจะไม่มี แต่ก็ยัง Reversed Engineering ออกมาได้) ต้องไปนั่งถามคนทำงานหน้างาน Explore ข้อมูลแล้ว ก็ต้องไป Verify กับคนที่กรอกข้อมูล หรือ คนที่ทำงานในกระบวนการนั้น
[เคยทำงานให้กับที่หนึ่งครับ เราก็พยายาม mapping transaction ในฐานข้อมูลทั้งหมด ซึ่งนั่งไล่ถามกันนี่ ก็ใช้เวลาอยู่หลายอาทิตย์ พอเอามา run กับ data ทั้งฐาน สรุปว่า mapping ได้แค่ 95% ส่วน 5% ที่เหลือนั้น เป็นความลับสวรรค์มากครับ ไม่มีใครในบริษัทรู้เลยว่า คืออะไร]
4. Aggregate/Label: ข้อมูลในฐานข้อมูลวิเคราะห์ (ไม่ว่าจะเป็น data lake หรือ data warehouse หรือพวก analytics table ต่างๆ เดี๋ยวรายละเอียดว่าพวกนี้คืออะไร จะมาเล่าให้ฟังครั้งหน้าๆ ครับ) นั้น บางทีก็จะมีความละเอียดของข้อมูลไม่ตรงกับ unit of analysis (ใครทำพวก data analytics คำนี้สำคัญมากครับ ไม่รู้ไม่ได้นะ ใครไม่รู้ มันก็คือ ระดับความละเอียดของข้อมูลที่เรากำลังวิเคราะห์ เช่น วิเคราะห์ระดับลูกค้า หรือ วิเคราะห์ระดับ transaction) จึงทำให้ต้องมีการ aggregate data คือ เหมือนการรวบตึง ให้อยู่ในระดับความละเอียดที่เราต้องการ ใครที่ไม่แม่นเรื่อง data modelling ก็จะพินาศกันตรงนี้ได้ง่ายๆ เอาข้อมูลคนละระดับความละเอียดมาผสมกัน จนข้อมูลซ้ำซ้อนกันก็มี
ความยากของการ aggregate ก็คือ การเลือกตัวแทนที่เที่ยงธรรม ลองคิดง่ายๆ ว่า ถ้าผมอยากวิเคราะห์ลูกค้าหนึ่งคน แล้วลูกค้ามีพฤติกรรมมากมายมหาศาล มี transaction เป็นร้อยเป็นพัน แต่เราต้องการรวบตึงให้เหลือแค่ 1 row หรือ 1 record เท่านั้น เราจะใช้การคำนวณแบบใดในการ aggregate ดี จะ sum total หรือ จะ average เช่น บางคนก็ใช้วิธี average ว่า ลูกค้าซื้อเยอะ ซื้อน้อยขนาดไหน แต่ดันไป average ตั้งแต่ transaction แรกที่ลูกค้าซื้อเมื่อ 10 ปีที่แล้ว จนถึง transaction ปัจจุบัน ถ้าผมเป็นลูกค้าจนๆ ในอดีต แต่ตอนนี้ รวยมากแล้ว ความจนในอดีตของผม ก็จะมาหลอกหลอน บั่นทอนความรวยปัจจุบันของผมให้ลดลงไป เวลาวิเคราะห์ก็จะไม่เห็นความรวยปัจจุบันของผมเท่าที่ควร
[หลายคนเลยที่เอะอะ ก็ใช้ total sum มาเป็นวิธีการคำนวณในการทำ aggregation ซึ่งผมมองว่า total sum นี่ มันมีความไม่ชัดเจนในตัวเองอย่างมาก เนื่องจากมันผสมเข้าไปด้วยปัจจัยหลายอย่าง เช่น ยอดรวมของการซื้อของลูกค้าที่เยอะนั้น มันอาจจะมาจากลูกค้ามาบ่อย หรือ ลูกค้าซื้อของแพง การใช้ยอดรวม จึงเป็นอะไรที่กำกวมมาก ขอให้ทุกคนมีสติเยอะๆ เวลาทำพวก aggregation นะครับ]
อีกปัญหาหนึ่ง คือ การ Label Data หรือ บอกว่า Data อันนี้ คืออะไร เช่น ถ้าเราอยากจะวิเคราะห์พวก unstructured data เช่น พวกข้อความ หรือ รูปภาพ ถ้าอยากบอกได้ว่า ข้อความนี้ ลูกค้าชม หรือ ตำหนิ ก็ต้องมีการ Label หรือ บอกไปว่า ข้อความนี้ ชม ข้อความนี้ ตำหนิ (ในกรณีที่อยากสร้างโมเดลมาทำนายเองนะครับ ถ้าไปใช้โมเดลสำเร็จรูป หรือไป copy model ชาวบ้าน ก็ไม่ต้องวุ่นวาย) หรือ อยากบอกได้ว่า รูปนี้ เป็นรูปลูกค้า ยิ้ม หรือ หน้าบึ้ง ถ้าอยากจะสร้างโมเดลทำนาย ก็จะต้องมีชุดข้อมูลที่บอกได้ว่า รูปไหน รูปยิ้ม รูปไหน รูปหน้าบึ้ง พวก structured data ก็ยากไม่แพ้กันครับ เช่น อยากสร้าง Churn Model หรือ อยากทำนายว่า ลูกค้าคนไหนจะหยุดซื้อ ถ้าความสัมพันธ์ของลูกค้ากับธุรกิจ เป็นแบบ Non-contractual Relationship หรือ ไม่มีสัญญาที่มากำหนดความสัมพันธ์กันอย่างชัดเจน มันก็จะยากมากที่จะบอกว่า ลูกค้าได้หยุดความสัมพันธ์กับเราไปหรือยัง เราจะใช้เกณฑ์ไหน เพื่อบอก(หรือเดา)ได้ว่า ลูกค้าได้หยุดซื้อกับเราไปแน่แท้แล้ว เมื่อกำหนดเกณฑ์แล้ว ก็ต้องมา run data เพื่อ label ไปว่า ลูกค้าคนไหน หยุดซื้อ หรือ ยังไม่หยุดซื้อ
5. Learn/Optimize: มีใครไต่ภูเขามาถึงจุดนี้ได้ไหมเอ่ย หรือ กระโดดข้ามมาเลยบ้างครับ ถ้าเราสร้างฐาน 4 ขั้นที่แข็งแรง การทำงานในชั้นนี้ จะเป็นไปอย่างง่ายดาย สบาย ราบรื่น ถ้าจะทำด้านนี้ โดยรากฐานทั้ง 4 ขั้น ยังไม่แข็งแรงนัก ก็คงทำได้ครับ แต่อาจจะไม่ราบรื่นนัก มันจะทำด้วยความเหนื่อยล้า ใช้พลังมาก และไม่มีประสิทธิภาพเท่าที่ควร
ผมเชื่อว่า มีหลายองค์กรก็วิ่งมาถึงจุดนี้ได้แล้ว แต่ความยากของการทำพวก predictive model หรือ AI ทั้งหลายแหล่ ไม่ใช่แค่ จะมีข้อมูลพร้อม หรือ มีระบบพร้อม ก็จะประสบความสำเร็จ การเสกโมเดลมา สมัยนี้ ไม่ใช่เรื่องยากแล้วครับ แต่การเอาโมเดลไปเป็นส่วนหนึ่งของการทำธุรกิจนั้น ต้องการความเข้าใจทั้งจากผู้บริหาร และฝั่งธุรกิจด้วย
ถ้า ผู้บริหาร หรือ ทีม Business ยังเข้าใจว่า Analytics หรือ AI มันเก่งฉลาดคิดแทนนักกลยุทธ์ได้ ก็ ยิ้มแห้ง เลยครับ (เคยเจอบริษัทที่อยากได้ ผลจาก analytics แบบ ว้าวๆ แต่บริษัทตัวเองก็ไม่ได้มีการเก็บ data ไหมครับ :D ) หรือ อีกแบบที่เจอ คือ Analytics หรือ AI ก็ดีนะ แต่เราก็ชอบการทำ mass marketing หว่านแหเอาทุกสิ่งอย่างที่เฉียดเข้ามาใกล้เรา หรือ เด็ดกว่านั้น คือ เราไม่ต้องทำ Analytics ก็ได้ เราก็ขายๆ ไป ตั้งราคาไป เดี๋ยวเค้าก็มาซื้อกัน (สาธุ)
ถ้าอยากจะเป็น data-driven business หรือ data-informed business หรือให้เก๋ขึ้นไปอีก ก็คือ data-centric business leadership ขององค์กรต้องเข้าใจวิธีการนำ data ไปใช ้และเข้าใจข้อจำกัดของพวก analytics ด้วย รวมถึงให้ความสำคัญกับการเปลี่ยนพฤติกรรมของคนในองค์กรให้หันเข้าหาข้อเท็จจริง ที่ปรากฎอยู่ใน data ไม่ใช่เชื่อไปเองว่า ยอดขายขึ้นหรือลงเพราะปัจจัยที่เกิดจากการมโน
