เมื่อพูดถึงการปรับใช้ AI ผู้นำด้าน IT มักหนีไม่พ้นความท้าทายที่เกี่ยวพันกับกฎการกำกับดูแล, การทำให้เป็นประชาธิปไตย, ความปลอดภัย, และความรวดเร็ว

ขั้นตอนสำคัญที่สุดที่ผู้นำด้าน IT สามารถนำไปใช้ เพื่อช่วยให้บริษัทประสบความสำเร็จในนวัตกรรม AI ตั้งแต่การสเกลพุชไปยังการผลิต ต่อเนื่องไปจนถึงการคงไว้ซึ่งสถาปัยกรรมอันเรียบง่าย และสุดท้ายคือการสร้างกลยุทธิ์ MLOps ที่มั่นคง

Scale Push ในงานการผลิต

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

ผู้นำทางธุรกิจมองว่าการปรับใช้ระบบใหม่อย่างรวดเร็วในการผลิตนั้นเป็นกุญแจสำคัญที่ใช้เพิ่มมูลค่าธุรกิจได้อย่างสูงสุด แต่สิ่งนี้จะเกิดขึ้นได้ก็ต่อเมื่อการปรับใช้นั้นเป็นไปอย่างราบรื่นและมีความเสี่ยงต่ำ แนวคิดในการ Integration และ Delivery อย่างต่อเนื่อง (CI/CD) ใช้ได้กับ Software Engineering แบบดั้งเดิม และคงประสิทธิภาพการใช้งานได้ดีเช่นกัน เมื่อนำมาใช้กับ Data Science, Machine Learning , และ AI Systems

หลังจากที่ประสบความสำเร็จในการพัฒนาโมเดล Data Scientist ควรพุชโค้ด, Metadata, และเอกสารประกอบไปยังที่จัดเก็บส่วนกลาง แล้วจึงทริกเกอร์ CI/CD pipeline ตัวอย่างไปป์ไลน์ดังกล่าวอาจประกอบด้วย :

  • สร้างโมเดล
    • สร้างองค์ประกอบโมเดล (Model Artifacts)
    • ส่งองค์ประกอบไปเก็บไว้ยังคลังระยะยาว
    • รันการตรวจสอบเบื้อต้น (Smoke Tests/Sanity Checks)
    • สร้างรายงานที่เป็นธรรมและอธิบายได้
  • ปรับใช้กับสภาพแวดล้อมการทดสอบ
    • รันการทดสอบเพื่อตรวจสอบประสิทธิภาพของ ML และประสิทธิภาพการประมวลผล
    • ทำการทดสอบแบบแมนนวล
  • ปรับใช้กับสภาพแวดล้อมการผลิต
    • ปรับใช้โมเดลในรูปแบบ Canary
    • ปรับใช้โมเดลอย่างเต็มรูปแบบ

มีหลายสถานการณ์ที่มีความเป็นไปได้ ขึ้นอยู่กับแอพพลิเคชั่น, ความเสี่ยงที่ระบบควรได้รับการป้องกัน, และแนวทางที่องค์กรเลือกใช้ดำเนินงาน โดยทั่วไปแล้วแนวทางแบบค่อยเป็นค่อยไปในการสร้าง CI/CD Pipeline คือทางเลือกที่เหมาะสม ยกตัวอย่างเช่น เวิร์กโฟลว์เรียบๆ หรือใช้งานได้ง่ายดายที่ทีมสามารถใช้ซ้ำได้บ่อยครั้งย่อมดีกว่าการเริ่มต้นด้วยโครงสร้างพื้นฐานอันยุ่งยากซับซ้อน

โปรเจคเริ่มต้นนั้นไม่ได้มีการใช้งานโครงสร้างของยักษ์ใหญ่ด้านเทคโนโลยีใดๆ และอาจยากที่จะคาดการณ์ถึงความท้าทายในการปรับใช้ที่ต้องเผชิญล่วงหน้า ทั้งนี้เครื่องมือพื้นฐานและแนวทางปฏิบัติที่เหมาะสมก็ยังมีให้ใช้ได้อยู่ แต่มันไม่มีรูปแบบสำเร็จใดที่จะสามารถปรับใช้ได้กับ CI/CD หมดทุกแขนง ดังนั้นทางที่ดีที่สุดก็คือเริ่มจากเวิร์กโฟลว์ CI/CD ที่เรียบง่าย (แต่เปี่ยมไปด้วยฟังก์ชั่นการใช้งาน) และค่อยๆ เพิ่มขั้นตอนรายละเอียดต่างๆ ไปตามทาง ที่ซึ่งบททดสอบคุณภาพและการสเกลจะปรากฎขึ้นเรื่อยๆ ตามมา

คงไว้ซึ่งสถาปัยกรรมอันเรียบง่าย

เมื่อพูดถึงสถาปัยกรรมที่ช่วยซัพพอร์ตระบบปฏิบัติการ AI เรื่องจะเริ่มซับซ้อนขึ้นมาอย่างรวดเร็ว บางครั้งเรื่องทั้งหมดก็เป็นผลลัพธ์จากระบบดั้งเดิม - ในองค์กรที่มีโครงสร้างอันซับซ้อนและประวัติที่ยาวนาน มักเป็นเรื่องยากที่เราจะเริ่มสร้างจากการนับหนึ่งใหม่ตั้งแต่ต้น และระบบเก่าๆ เหล่านั้นก็อาจมีความยุ่งเหยิงอยู่แล้วตั้งแต่ยังไม่เริ่มก็ได้ แน่นอนว่าการพัฒนาแพลตฟอร์ม AI ที่ดีที่สุดนั้นจะไม่ใช่เรื่องยากหากว่าเราเริ่มสร้างมันจากหน้าโล่งๆ!

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

ในปัจจุบัน หลายๆ บริษัทในสหรัฐอเมริกาไม่ได้สร้างระบบขึ้นเอง แต่ใช้การทำงานร่วมกับที่ปรึกษาเพื่อรับการช่วยเหลือสนับสนุน ไม่ว่าจะใช้วิธีไหนก็ตามใจความสำคัญยังคงเหมือนเดิม คือ การคงไว้ซึ่งสถาปัตยกรรมอันเรียบง่าย เพื่อให้ในเวลาที่ไม่ว่าเทคโนโลยีจะเสื่อมถอยหรือเติบโต การสลับไปมาจะลื่นไหลสำหรับทั้งทีม IT และตัวธุรกิจที่พวกเขาสนับสนุน

สร้างกลยุทธิ์ MLOps ที่มั่นคง

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

แม้ว่า MLOps มักจะถูกรวมเข้ากับการกำกับดูแลข้อมูล หรือ AI Governance ทั้ง 2 อย่างนี้มีความแตกต่างกันอยู่ ขณะที่การกำกับดูแล (แนวทางปฏิบัติและกระบวนการที่ช่วยรับรองการจัดการสินทรัพย์ข้อมูลภายในองค์กร) เป็นของผู้จัดการฝ่าย IT และทีม แต่ทุกคนในองค์กร - รวมถึงทีม IT - ล้วนมีบทบาทที่ต้องทำใน MLOps (การกำหนดมาตรฐานและปรับปรุงประสิทธิภาพการจัดการวงจรชีวิตของแมชชีนเลิร์นนิ่ง)

MLOps ไม่ได้มีความสำคัญแค่ช่วยลดความเสี่ยงของโมเดลแมชชีนเลิร์นนิ่งในการผลิตเพียงเท่านั้น (แม้ว่านั่นจะเป็นอีกเหตุผลหนึ่งที่เราควรพัฒนาระบบ MLOps) แต่ยังเป็นองค์ประกอบสำคัญในการปรับใช้ความสามารถของแมชชีนเลิร์นนิ่งอย่างเข้มข้น เพื่อจะได้รับประโยชน์จากการประหยัดจากขนาด (Economies Of Scale) ที่สอดคล้องกัน การเปลี่ยนจากโมเดลหนึ่งหรือจำนวนเล็กน้อยไปสู่โมเดลหลักสิบ, หลักร้อย หรือหลักพัน ที่จะส่งผลดีต่อธุรกิจนั้นต้องการระเบียบวินัยของ MLOps

แนวทางปฏิบัติ MLOps ที่ดีจะช่วยเสริมประสิทธิภาพทีมดังต่อไปนี้ :

  • ติดตามการกำหนดเวอร์ชั่น โดยเฉพาะอย่างยิ่งกับการทดลองในขั้นตอนการออกแบบ
  • ทำความเข้าใจหากโมเดลที่ได้รับการฝึกฝนใหม่มีประสิทธิภาพกว่าเวอร์ชั่นเก่า (และส่งเสริมโมเดลสู่การผลิตที่มีประสิทธิภาพมากกว่า)
  • ตรวจสอบให้แน่ใจ (ตามระยะเวลาที่กำหนด - รายวัน,รายเดือน และอื่นๆเป็นต้น) ว่าประสิทธิภาพของโมเดลไม่ได้ลดลงในการผลิต

สำหรับผู้จัดการ IT และลูกทีม, MLOps จำเป็นต้องทำการ Integrated เข้าสู่กลยุทธิ์ DevOps ขนาดใหญ่ขององค์กร เพื่อเชื่อมต่อช่องว่างระหว่าง CI/CD ดั้งเดิม และแมชชีนเลิร์นนิ่งสมัยใหม่ ซึ่งนั่นหมายถึงระบบที่เป็นส่วนเสริมพื้นฐาน และระบบที่ช่วยให้ทีม DevOps สามารถทำให้แมชชีนเลิร์นนิ่งเป็นไปโดยอัตโนมัติได้เช่นเดียวกับที่สามารถทำให้การทดสอบระบบดั้งเดิมเป็นแบบอัตโนมัติได้เหมือนกัน

ข้อมูลเพิ่มเติมเกี่ยวกับ MLOps หรือ Dataiku แพลตฟอร์มชั้นนำของโลกสำหรับ Everyday AI เพื่อจัดระบบการใช้ข้อมูล เพื่อผลลัพธ์ทางธุรกิจที่ยอดเยี่ยม คลิก