แชร์ประสบการณ์เป็น Data Scientist 1 ปี ที่คอร์สออนไลน์ไม่ได้สอน

แชร์ประสบการณ์เป็น Data Scientist 1 ปี ที่คอร์สออนไลน์ไม่ได้สอน

สำหรับเพื่อนๆ นักการตลาดที่สนใจเรื่อง Data วันนี้ผมได้บทความหนึ่งที่ขออนุญาตผู้เขียนที่เป็น Data Scientist มาแบ่งปัน เรื่องของเรื่องคือเธอเล่าเรื่องการทำงานกับ Data จากประสบการณ์หนึ่งปีได้เข้าใจง่ายขนาดที่ผมอ่านเองยังรู้สึกประทับใจ แถมเธอยังใจดีให้ผมเอามาแบ่งปันให้เพื่อนๆ ได้อ่านกันด้วยครับ ถ้าพร้อมแล้วเรามาดูกันครับว่าการทำงานกับ Data อีกแง่มุมหนึ่งของ Data Scientist คนนี้เป็นอย่างไร คนที่ทำงานกับสาย Data จะได้รู้ได้เข้าใจว่างานของพวกเขาไม่ได้ง่าย เพราะกว่าที่นักการตลาดจะเล่นกับ Data ผ่าน Dashboard หรือ BI ง่ายๆ ได้นั้นมีขั้นตอนมากมายที่อยากให้คุณเข้าใจครับ

ประสบการณ์เป็น Data Scientist 1 ปี ที่คอร์สออนไลน์ไม่ได้สอน

ก่อนจะมาเป็น Data Scientist เรา(ผู้เขียนเจ้าของบทความ)ศึกษาด้วยตัวเอง เรียนคอร์สออนไลน์เป็นหลัก อ่าน blog ต่างๆ จนเริ่มเข้าใจพวก algorithm ต่างๆ และเขียนภาษา Python เพื่อจัดการกับข้อมูลกับสร้างโมเดล

ทว่าเมื่อได้สัมผัสกับงานจริง มีหลายอย่างมากที่ได้เรียนรู้นอกจากความรู้ในคอร์สออนไลน์ต่างๆ เลยแยกเป็นหัวข้อย่อยๆ ยาวหน่อย อ่านเพลินๆ กันนะคะ ^^

การใช้เวลาราวๆ 80% ของโปรเจ็คหมดไปกับการเตรียมข้อมูลเป็นเรื่องจริง!

ถ้าเราสังเกต public data ที่แจกฟรีให้ลองเอาไปเล่นหรือสร้างโมเดลกัน จะพบว่าจริงๆ มันคลีนมาพอสมควรเลย เช่น ข้อมูลถูกต้องตาม field, type ของข้อมูลเอาไปใช้ต่อได้เลย, มี feature ที่จำเป็น พร้อมเอาเข้าโมเดล, หรืออาจมี missing values ให้ลองไป impute กัน

https://sebastianraschka.com/images/blog/2015/principal_component_analysis_files/iris.png

แต่ในสถานการณ์จริง.. ต้องเริ่มตั้งแต่เลือกว่าโจทย์นี้เหมาะจะใช้ข้อมูลอะไรมาแก้, จะ extract feature อะไรจากข้อมูลดี, จัดการดึงข้อมูลจาก source เอง (แตกต่างกันไปตามแต่ละบริษัท), เอาข้อมูลจากหลายๆ ที่มา join กันเอง, ข้อมูลที่เก็บอาจมีผิดๆ ถูกๆ ปนกัน, duplicated row ที่ไม่แน่ใจว่ามี 2 records จริงๆ หรือเก็บข้อมูลมา double เพราะ timestamp ต่างกันนิดเดียว, format ของข้อมูลที่เก็บมาไม่เหมือนกัน เช่น ข้อมูลจาก iOS เก็บว่า hello แต่ Android เก็บว่า Hello บลาๆๆ

จึงเป็นสาเหตุว่าการเตรียมข้อมูลมันนานจริงๆ T^T

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

ชีวิตการทำงานจริงที่กว้างกว่าแค่การสร้างโมเดล

https://docs.microsoft.com/th-th/azure/machine-learning/team-data-science-process/lifecycle

ความท้าทายแรกคือโจทย์​ ซึ่งโจทย์อาจจะมาจากทีม business ที่มีปัญหาที่อยากแก้ หรือมาจากทีมที่คิดว่าทำแล้วมันจะช่วย improve บางอย่างให้ดีขึ้นได้ และเราเองจะต้องเป็นคนที่ define โจทย์ให้มีความเป็นไปได้ แก้ได้จริง

โดยเราจะได้ไปคุยกับคนให้โจทย์หรือปัญหามา เช่น สิ่งที่เค้าอยากได้จริงๆ คืออะไร เค้าอาจจะอยากได้ B แต่จริงๆ เราทำ B ตรงๆ ไม่ได้ แต่ทำ A แล้ว infer ไป B ได้ เป็นต้น

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

หลังได้โมเดลเราก็ควร offline evaluation ให้ได้ หมายถึงการทำให้แน่ใจว่าถ้าปล่อยโมเดลขึ้น production ไป จะไม่มีอะไรมาเซอร์ไพรซ์เรา ฮ่าๆ

บางทีก็มีการไปเก็บ feedback จากผู้ทดลอง ดูว่าผลของโมเดลเราเป็นยังไง แล้วเอามาปรับปรุงโมเดลให้ดีขึ้น บางทีก็ได้ insight ดีๆ จากการไปนั่งคุยเล่นๆ กับคนอื่นนะ แฮร่ๆ

สร้างโมเดลเสร็จ != จบงาน (ทำ A/B Testing กัน)

ทีแรกก็คิดว่าได้โมเดลดีๆ แม่นๆ ก็ส่งต่อ จบงานปิดโปรเจ็คได้เลย บูมมมม คิดผิดค่ะ ฮ่าๆ

จริงๆ แล้วการวัดผล (evaluation) ก็สำคัญไม่แพ้ตอนสร้างโมเดล โดยเฉพาะการวัดผลบน production ว่าถ้าเอาโมเดลที่เราสร้างไปใช้จริงๆ แล้วจะเป็นยังไง ดีขึ้นกว่าตอนไม่ใช้หรือเปล่า แน่ใจได้ยังไงว่าดีขึ้นเพราะโมเดล หรือเพราะบังเอิญเป็นช่วง high season พอดี หรือการปล่อยโมเดลไป จะ improve ส่วนนึง แต่กระทบส่วนอื่นให้แย่ลงมั้ย

https://www.addictionmarketing.com/blog/ab-testing/importance-ab-testing-addiction-treatment-market/

จึงเป็นที่มาของการทำ A/B Testing ที่จะทดลองใช้โมเดลกับผู้ใช้กลุ่มนึงก่อนที่จะปล่อยใช้กับทั้งระบบ (ตอนทำ A/B Testing อาจไม่ได้ลงมือทำเอง แต่ก็ควรติดตามผลโมเดลของเราเนอะ)

Performance ของโค้ดที่เขียน

อย่างนึงที่สำคัญหลังจากการสร้างโมเดล ก็คือการส่งมอบโมเดลที่เราสร้าง ไปให้คน deploy หรือเอาไปทำเป็น service ใช้ในระบบต่อ และสิ่งนั้นก็ไม่ใช่อะไร นอกจากโค้ดของเรานั่นเอง ฮ่าๆ

การเขียนโค้ดได้ กับ เขียนโค้ดเป็น มันแตกต่างกัน

ตัวเราน่าจะคาบๆ กึ่งๆ ระหว่าง ได้ กับ เป็น นะ ฮ่าาา~ เพราะบางครั้งก็จะโดนบ่นว่า โค้ดนี้ refactor ให้ performance ดีขึ้นได้นะ รันเร็วขึ้น เขียนสั้นลง ใช้ built-in function จะเร็วกว่า กินเมมน้อยกว่า บลาๆๆ

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

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

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

บางงานไม่จำเป็นต้องใช้โมเดล หรือใช้ algortithm โหดๆ ก็ได้

ทีแรกก็ไม่เข้าใจ ทำไมล่ะ ใช้โมเดลโหดๆ ผลแม่นๆ ไว้ก่อนไม่ดีหรอ

สิ่งสำคัญมันคืออย่างงี้ เราจะมอง 2–3 แกน คือ แรงและระยะเวลาที่ใช้ทำ ผลลัพธ์ที่ได้ และความยาก-ง่ายในการเอาไปใช้จริง

การลงแรงและเวลาไปกับการทำโมเดลที่เทพมากๆ ได้ผลลัพธ์ดีกว่าโมเดลทั่วๆ ไประดับนึง มันคุ้มหรือเปล่า ยกตัวอย่างเช่น ถ้าเราใช้เวลา 1 เดือนทำโมเดล A มาได้ ใช้ features ยากๆ เยอะ ทำให้ตอนเอาไป deploy ลำบาก computation นานหลายวิ สุดท้ายอาจเอาไปใช้จริงไม่ได้ หรือใช้เวลา deploy นาน

สมมติเมื่อ deploy สำเร็จ และทดลองเอาไปใช้จริงบน production ปรากฎว่าผลมันไม่ดีเหมือนที่คาดไว้ หรือไม่เหมือนตอน offline evaluation ดังนั้นโมเดล A นี้จึงไม่ได้ปล่อยใช้จริง ก็จะเท่ากับเราเสียเวลาไปเปล่าๆ..

แต่สมมติ ถ้าเราลองใช้โมเดลง่ายๆ อย่างโมเดล B ที่ใช้เวลาทำเพียง 1 อาทิตย์ deploy ง่ายกว่า เอาไปทดลองใช้จริงได้เร็วกว่า เห็นผลเร็ว จะทำให้เราตัดสินใจต่อได้ว่าจะลงแรงพัฒนาโมเดลให้ซับซ้อนขึ้นและได้ผลดีกว่าอย่างโมเดล Aมั้ย เป็นต้น

ทั้งนี้ก็ขึ้นกับหลายอย่างนะ เช่น ระบบที่จะเอาไป integrate ด้วยเป็นยังไง, ความซับซ้อนของโมเดล (ปกติเราไม่ได้ deploy โมเดลเอง เลยไม่มีความรู้ส่วนนี้มากนัก.. งืออ..)

การสื่อสารเป็นสิ่งสำคัญ เราทำงานคนเดียวไม่ได้

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

ยกตัวอย่าง บ่อยครั้งที่เรามี meeting ที่ต้องอธิบาย progress ของงานที่ทำ ซึ่งอาจต้อง report ให้ทีม business ที่ไม่ได้มีความรู้ด้าน Data Science รู้และเข้าใจว่าเราทำอะไรถึงไหนแล้ว ผลเป็นยังไง ทำไมมันถึงดีหรือไม่ดี ติดอะไรมั้ย สิ่งที่ทำไม่ได้เพราะอะไร ถ้าเราอธิบายได้ มันจะดีกว่าการบอกเพียง ‘อันนี้ทำไม่ได้นะ’ และเค้าอาจจะช่วยเราหาทางออกได้ด้วย domain knowledge ของเค้าอีกด้วย

ดังนั้น การอธิบายเรื่องที่เข้าใจยากให้เข้าใจง่ายก็เป็นสกิลที่น่ามีติดตัวไว้น้า

เวลาว่างก็ไปศึกษาเพิ่มอีก

ช่วงแรกๆ ที่ทำงาน เรารู้สึกว่ามันมีสิ่งที่ต้องเรียนรู้เยอะมาก เช่น อยากกลับไปทวนทฤษฎีให้แม่นขึ้น, เลือก algorithm ยังไงให้เหมาะสม, นอกเวลางานก็นั่งคิดว่าจะทำยังไงกับโจทย์นี้ดี อยากรู้ว่าคนอื่นแก้โจทย์แบบนี้ยังไง, ซื้อหนังสือมาอ่าน บลาๆๆ

ทว่าพอถึงจุดนึงก็เริ่ม burn out เริ่มรู้สึกว่าสมองเราอยู่กับสิ่งเดียวทั้งวันทั้งคืน หลายๆ วันหลายๆ เดือนมันก็เริ่มล้า จนช่วงนึง นอกจากเวลางานแล้วก็รู้สึกไม่อยากแตะอะไรพวกนี้เลยก็มี

เราเลยคิดว่าจริงๆ มันควรมีสมดุล ให้สมองได้พักบ้าง ไปทำอย่างอื่นบ้าง เช่น ไปเรียนภาษาที่สนใจ ไปติดซีรี่ย์บ้าง ทำอาหารกินเอง ดูแลตัวเอง ไปออกกำลังกาย หรือจะเขียน blog แชร์สิ่งที่เราอยากแชร์ก็ได้นะ~

และนี่ก็คือเรื่องราวที่ Data Scientist คนหนึ่งเขียนแชร์ได้น่าสนใจบน Medium ของเธอ จนผมอดไม่ได้ที่จะต้องไปขออนุญาตเธอนำมาแชร์ให้เพื่อนๆ นักการตลาดที่สนใจด้าน Data ได้อ่านเพื่อเข้าใจว่าคนทำ Data นั้นต้องทำอะไรบ้าง กว่าจะมาให้นักการตลาดอย่างเราได้ใช้งานต่อครับ

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

เจ้าของบทความ

Data Scientist จาก Wongnai และ แอดมินเพจ Noob Learning แหล่งรวมคนสนใจเกี่ยวกับ data และชื่นชอบการเรียนรู้ไปด้วยกัน

อ่านบทความที่เกี่ยวกับ Data Driven ต่อ > https://www.everydaymarketing.co/tag/data-driven/

Nattapon Muangtum

Nattapon Muangtum

เจ้าของเพจการตลาดวันละตอน / อาจารย์พิเศษวิชา Data-Driven Communication / ผู้เขียนหนังสือการตลาดแบบรู้ใจ Personalized Marketing, การตลาดแบบฉลาดใช้ดาต้า Data-Driven Marketing และ Data Thinking / เป็นที่ปรึกษาด้าน Marketing และ Data-Driven ให้กับบริษัทบางแห่งและหน่วยงานบางที่

ใส่ความเห็น

อีเมลของคุณจะไม่แสดงให้คนอื่นเห็น ช่องข้อมูลจำเป็นถูกทำเครื่องหมาย *