โปรเจค Machine Learning ส่วนใหญ่มักจะเริ่มต้นจากใน Jupyter Notebook ต่อจากนั้นจะเป็นยังไง? เรามาศึกษากันครับ
Jupyter Notebook คืออะไร?
Jupyter Notebook คือเครื่องมือที่ Data Scientist ใช้วิเคราะห์ Data และสร้างโมเดล Machine Learning โค้ดที่เขียนใน Jupyter Notebook จะถูกแบ่งออกเป็นช่องๆ ซึ่งแต่ละช่องอาจจะไม่ได้ Execute จากบนลงล่างเสมอไป จึงทำให้สามารถสร้าง Prototype และทดลองได้อย่างรวดเร็ว ผู้ใช้งานสามารถเขียน Documentation กำกับโค้ดหรือสร้าง Visualization เพื่อไว้ทำ Report ให้ฝั่ง Business เอาไปใช้งานต่อได้อีกด้วย
การที่ Jupyter Notebook ไม่ต้อง Execute จากบนลงล่างนั้นทำให้เหมาะกับการสร้าง Machine Learning Pipeline เพราะบางขั้นตอนอาจใช้เวลานาน เช่น ในกรณีที่เราอยากโหลดข้อมูลครั้งเดียวและทดลองหลายๆโมเดล
ในบางครั้งผลลัพธ์จาก Jupyter Notebook ก็ถือว่าเพียงพอแล้วในการนำไปใช้งานต่อ เพราะเราอาจจะแค่ต้องการหา Insight หรือ Report ต่างๆ แต่หากในกรณีที่เราต้องนำโมเดลไปต่อกับ Product อื่นๆ หรือเปิดให้คนทั่วไปใช้ล่ะ? เราต้องทำอย่างไรต่อ?
การนำโค้ดไปใช้งานจริงหรือเอาขึ้นโปรดักชันควรทำตามขั้นตอนมาตรฐานของ Software Engineering ซึ่งรวมไปถึงการสร้าง CICD Pipeline เพื่อให้งานส่งออกไปได้ด้วยความรวดเร็ว การออกแบบระบบของเราให้มีประสิทธิภาพ การนำโค้ดไปทำ Version Control และใช้ Automated Testing เพื่อที่ใครก็สามารถแก้โค้ดได้โดยไม่ทำให้ Codebase พัง งานพวกนี้อาจจะฟังดูเยอะ แต่คุ้มค่าอย่างแน่นอนครับ
เท่าที่ผมรู้ วิธีหลักๆที่จะนำโมเดลของเราไปต่อกับกับบริการอื่น (Service) ตอนนี้มีอยู่ด้วยกัน 2 วิธี วิธีแรกคือนำไปต่อกับ Data Pipeline อาจจะเป็น ETL หรือ Streaming Pipeline ก็ได้ และอีกวิธีคือนำไปทำเป็น API ให้คนสามารถเรียกใช้ผ่านอินเทอร์เน็ต
วิธีที่ 1: Data Pipelines
จุดประสงค์ของ Data Pipeline คือการอ่านข้อมูลเพื่อนำมาประมวลและเขียนกลับลงแหล่งข้อมูลสักที่ โดยส่วนมากจะโดน Trigger เป็นช่วงและส่งข้อมูลไปเป็น Batch ข้อมูลที่รับมาจะเป็นข้อมูลจากไหนก็ได้ ตั้งแต่ AWS S3, On-prem Webserver, NoSQL หรือ SQL เป็นต้น ขั้นตอนประมวลผลอาจจะใช้ ML Model ไป Predict ผลหรืออาจจะเป็น Logic แก้ Missing Fields ก็ได้ ผลจากการประมวลข้อมูลนี้จะถูกนำเอาไปใช้ต่อ Streaming Pipeline ซึ่งจะคล้ายกับ Batch Pipeline เว้นแต่ว่าทุกอย่างทำแบบเรียลไทม์เมื่อมีข้อมูลเข้าระบบครับ
การเลือกข้อมูลเพื่อมานำมา Train ก็สำคัญไม่น้อยไปกว่าการเลือกโมเดล ในบางกรณีฟีเจอร์ที่เลือกมาอาจจะไม่สามารถนำไปใช้ได้ด้วยทั้งเหตุผลทางด้าน Technical และ Non-Technical เช่น ผู้ใช้งานอาจไม่อนุญาตให้นำข้อมูลไปใช้ หรือบางฟีเจอร์อาจต้องใช้ Processing Power มากเกิน เมื่อฟีเจอร์มีการเปลี่ยน เราจึงจำเป็นที่จะต้องทำการทดสอบโมเดลใหม่ แน่นอนว่าถ้าเรารู้ว่าฟีเจอร์ไหนใช้ไม่ได้ตั้งแต่ต้นก็จะไม่เจอปัญหานี้
ทุกวันนี้มี Data ผลิตออกมาเพิ่มมากขึ้นเรื่อยๆ มากเกินกว่าที่จะเก็บอยู่ในคอมหรือ Server เครื่องเดียวได้ จึงเป็นเหตุผลว่าทำไม Distributed Computing และ Distributed Storage กลายเป็นที่นิยมในหลายบริษัท แต่ก็มีข้อเสียอยู่บ้างครับตรงที่ Distributed Framework ค่อนข้างมีความซับซ้อนกว่า
Apache Spark เป็น Framework ที่สร้างมาเพื่อรองรับ Machine Learning Workflow โดยจะมี Implementation ของ ML Algorithms, Feature Processing Tools, Model Persistence และตัวช่วยอื่นๆรวมอยู่ด้วย Flow ของการสร้างโมเดลจึงอาจจะเริ่มที่ Spark เลยก็ได้ หรืออาจจะย้ายมาจาก Pandas/Sklearn ครับ
วิธีที่ 2: Web Service
การนำโมเดลไปเปิดให้ใช้ผ่าน Rest API จะทำให้เหล่านักพัฒนาสามารถเข้าถึงโมเดลผ่านอินเทอร์เน็ตได้ ความท้าทายของการสร้าง Service จะคล้ายกับการสร้าง Web Service แบบอื่น โดยเริ่มจากการนำ Web Framework แบบ Flask ไปครอบ พร้อมกับ Package ด้วย Docker ซึ่งส่วนนี้จะทำให้การ Deploy เป็นเรื่องง่ายขึ้น
Machine Learning Model ส่วนมากจะใช้ Processing Power เยอะหน่อย ทำให้ Non-Functional Requirement เป็นเรื่องที่มองข้ามไม่ได้ การ Cache ผลของโมเดล หรือการนำ GPU มาใช้จะทำให้รองรับโหลดได้มากขึ้นครับ
Then What?
หลังจากที่ Deploy ไปแล้วก็ต้องมีการมอนิเตอร์ทั้งระบบ รวมไปถึง Performance ของโมเดล เนื่องจากโมเดล Machine Learning ทายผลอิง Data Distribution ที่มีการเปลี่ยนแปลงไปตามเวลา
เมื่อ Performance ลด ก็ต้องมีการอัพเดตโมเดล หรือใช้โมเดลเดิมแต่กับข้อมูลใหม่ วิธีอัพเดตโมเดลอาจจะทำเป็นแบบ Deploy ใหม่เองหรือแบบอัตโนมัติทุกเดือน ไม่ว่าจะด้วยวิธีไหน การออกแบบ Architecture ตั้งแต่ต้นเพื่อช่วยรองรับจะทำให้การอัพเดตโมเดลนั้นง่ายและปลอดภัย
แล้วจะมั่นใจได้ไงว่าโมเดลใหม่จะมีผลที่ดีขึ้น? การทำ Back-Testing ไม่ได้หมายความว่าโมเดลจะดีกว่าอันเก่าแต่อย่างใด นำมาสู่การทำ A/B Testing เราจะวัดผลของโมเดลด้วยการแบ่ง Load บน Production ให้เข้าต่างโมเดลและใช้สถิติคำนวณดูว่าตัวใหม่ดีกว่าจริงหรือไม่
Developer ส่วนใหญ่ใช้ Git เพื่อ Version Control โค้ดและไว้ใช้ทำงานร่วมกับผู้อื่น แต่การ Version Control โมเดลของเรานั้นก็สำคัญไม่แพ้กัน ซึ่งรวมไปถึงโค้ดที่เอาไว้ใช้ Train และ Predict ข้อมูลที่เอาไว้ใส่ในโมเดลด้วย
ทีนี้ทุกคนก็คงจะรู้จัก Jupyter Notebook และกระบวนการทำโปรเจค Machine Learning ได้ดีขึ้น หากคุณผู้อ่านมีข้อสงสัยใดๆ สามารถคอมเม้นต์กันเข้ามาได้เลยครับ
