การเรียนรู้เครื่องจักรอุตสาหกรรม: หลักการออกแบบ 10 ประการ

การเรียนรู้เครื่องจักรอุตสาหกรรม: หลักการออกแบบ 10 ประการ

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

และบางครั้งโปรแกรมเมอร์มือใหม่ทุกคน ไม่ว่าเขาจะเป็นสตาร์ทอัพที่กระตือรือร้นหรือ Full Stack หรือ Data Scientist ธรรมดา ไม่ช้าก็เร็วก็ตระหนักว่ามีกฎเกณฑ์บางประการสำหรับการเขียนโปรแกรมและการสร้างซอฟต์แวร์ที่ทำให้ชีวิตง่ายขึ้นอย่างมาก

ในบทความนี้ ผมจะอธิบายโดยย่อ 10 หลักการของวิธีการเขียนโปรแกรมการเรียนรู้ของเครื่องทางอุตสาหกรรม เพื่อให้สามารถรวมเข้ากับแอปพลิเคชัน/บริการได้อย่างง่ายดาย โดยอิงตามวิธีการของแอป 12 ปัจจัย แนะนำโดยทีมงาน Heroku. ความคิดริเริ่มของฉันคือการเพิ่มความตระหนักในเทคนิคนี้ ซึ่งสามารถช่วยนักพัฒนาและบุคลากรด้านวิทยาศาสตร์ข้อมูลจำนวนมากได้

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

หลักการที่ 1: ฐานรหัสเดียว

โปรแกรมเมอร์บางคนในช่วงแรกๆ ด้วยความเกียจคร้านที่จะคิดออก (หรือด้วยเหตุผลบางอย่างของพวกเขาเอง) ลืม Git ไปได้เลย พวกเขาอาจลืมคำนี้โดยสิ้นเชิง กล่าวคือ พวกเขาโยนไฟล์ให้กันในไดรฟ์/แค่ส่งข้อความ/ส่งโดยนกพิราบ หรือไม่ก็ไม่คิดผ่านขั้นตอนการทำงานของพวกเขา และส่งต่อแต่ละไฟล์ไปยังสาขาของตนเอง จากนั้นไปที่ ผู้เชี่ยวชาญ.

หลักการนี้ระบุว่า: มีฐานรหัสเดียวและการปรับใช้หลายรายการ

Git สามารถใช้ได้ทั้งในด้านการผลิตและการวิจัยและพัฒนา (R&D) ซึ่งไม่ค่อยมีการใช้บ่อยนัก

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

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

คุณยังสามารถสร้างแพ็คเกจของโปรเจ็กต์ของคุณ โดยวางไว้บน Gemfury จากนั้นนำเข้าฟังก์ชันจากโปรเจ็กต์นั้นสำหรับโปรเจ็กต์อื่น ๆ เพื่อไม่ให้เขียนใหม่ 1000 ครั้ง แต่จะทำมากกว่านี้ในภายหลัง

หลักการที่ 2: ประกาศอย่างชัดเจนและแยกการพึ่งพา

แต่ละโปรเจ็กต์มีไลบรารีที่แตกต่างกันซึ่งคุณนำเข้าจากภายนอกเพื่อนำไปใช้ที่ไหนสักแห่ง ไม่ว่าจะเป็นไลบรารี Python หรือไลบรารีของภาษาอื่นเพื่อวัตถุประสงค์ต่าง ๆ หรือเครื่องมือระบบ - งานของคุณคือ:

• ประกาศการขึ้นต่อกันอย่างชัดเจน นั่นคือไฟล์ที่จะมีไลบรารี เครื่องมือ และเวอร์ชันทั้งหมดที่ใช้ในโปรเจ็กต์ของคุณและที่ต้องติดตั้ง (เช่น ใน Python ซึ่งสามารถทำได้โดยใช้ Pipfile หรือ Requirements.txt ลิงค์ที่ช่วยให้เข้าใจได้ดี: realpython.com/pipenv-guide)
• แยกการพึ่งพาเฉพาะสำหรับโปรแกรมของคุณในระหว่างการพัฒนา คุณไม่ต้องการเปลี่ยนเวอร์ชันอย่างต่อเนื่องและติดตั้งใหม่ เช่น Tensorflow ใช่ไหม

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

แอปพลิเคชันของคุณไม่ควรใช้เครื่องมือระบบที่อาจติดตั้งบนระบบปฏิบัติการเฉพาะ เครื่องมือเหล่านี้จะต้องได้รับการประกาศในรายการการขึ้นต่อกันด้วย นี่เป็นสิ่งจำเป็นเพื่อหลีกเลี่ยงสถานการณ์ที่เวอร์ชันของเครื่องมือ (รวมถึงความพร้อมใช้งาน) ไม่ตรงกับเครื่องมือระบบของระบบปฏิบัติการเฉพาะ

ดังนั้นแม้ว่าจะสามารถใช้ curl ในคอมพิวเตอร์เกือบทุกเครื่องได้ แต่คุณก็ยังควรประกาศให้เป็นไปตามการพึ่งพาเนื่องจากเมื่อย้ายไปยังแพลตฟอร์มอื่นอาจไม่อยู่ที่นั่นหรือเวอร์ชันจะไม่ใช่เวอร์ชันที่คุณต้องการในตอนแรก

ตัวอย่างเช่น needs.txt ของคุณอาจมีลักษณะดังนี้:

# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0

# testing requirements
pytest>=5.3.2,<6.0.0

# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0

# fetching datasets
kaggle>=1.5.6,<1.6.0

หลักการที่ 3: การกำหนดค่า

หลายคนเคยได้ยินเรื่องราวของนักพัฒนาซอฟต์แวร์หลายคนที่อัปโหลดโค้ดไปยัง GitHub ไปยังที่เก็บข้อมูลสาธารณะโดยไม่ได้ตั้งใจด้วยรหัสผ่านและคีย์อื่นๆ จาก AWS แล้วตื่นขึ้นมาในวันรุ่งขึ้นพร้อมกับหนี้จำนวน 6000 ดอลลาร์ หรือแม้แต่ 50000 ดอลลาร์

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

อีกทางเลือกหนึ่งคือการจัดเก็บการกำหนดค่าไว้ในตัวแปรสภาพแวดล้อม คุณสามารถอ่านเพิ่มเติมเกี่ยวกับตัวแปรสภาพแวดล้อมได้ ที่นี่.

ตัวอย่างของข้อมูลที่โดยทั่วไปจัดเก็บไว้ในตัวแปรสภาพแวดล้อม:

• ชื่อโดเมน
• URL API/URI
• กุญแจสาธารณะและกุญแจส่วนตัว
• ผู้ติดต่อ (เมล โทรศัพท์ ฯลฯ)

วิธีนี้จะทำให้คุณไม่ต้องเปลี่ยนโค้ดตลอดเวลาหากตัวแปรการกำหนดค่าของคุณเปลี่ยนแปลง สิ่งนี้จะช่วยคุณประหยัดเวลา แรง และเงิน

ตัวอย่างเช่น หากคุณใช้ Kaggle API เพื่อทำการทดสอบ (เช่น ดาวน์โหลดซอฟต์แวร์และรันโมเดลผ่านซอฟต์แวร์เพื่อทดสอบเมื่อรันว่าโมเดลทำงานได้ดี) ดังนั้นคีย์ส่วนตัวจาก Kaggle เช่น KAGGLE_USERNAME และ KAGGLE_KEY ก็ควรจะเป็น เก็บไว้ในตัวแปรสภาพแวดล้อม

หลักการที่ 4: บริการของบุคคลที่สาม

แนวคิดที่นี่คือการสร้างโปรแกรมในลักษณะที่ไม่มีความแตกต่างระหว่างทรัพยากรในท้องถิ่นและบุคคลที่สามในแง่ของโค้ด ตัวอย่างเช่น คุณสามารถเชื่อมต่อทั้ง MySQL ในเครื่องและของบุคคลที่สามได้ เช่นเดียวกับ API ต่างๆ เช่น Google Maps หรือ Twitter API

หากต้องการปิดใช้งานบริการของบุคคลที่สามหรือเชื่อมต่อกับบริการอื่น คุณเพียงแค่ต้องเปลี่ยนคีย์ในการกำหนดค่าในตัวแปรสภาพแวดล้อม ซึ่งฉันได้พูดถึงในย่อหน้าข้างต้น

ตัวอย่างเช่น แทนที่จะระบุเส้นทางไปยังไฟล์ที่มีชุดข้อมูลอยู่ภายในโค้ดในแต่ละครั้ง จะดีกว่าถ้าใช้ไลบรารี pathlib และประกาศเส้นทางไปยังชุดข้อมูลใน config.py ดังนั้นไม่ว่าคุณจะใช้บริการใด (สำหรับ เช่น CircleCI) โปรแกรมสามารถค้นหาเส้นทางไปยังชุดข้อมูลโดยคำนึงถึงโครงสร้างของระบบไฟล์ใหม่ในบริการใหม่

หลักการที่ 5 สร้าง ปล่อย รันไทม์

คนจำนวนมากใน Data Science พบว่าการพัฒนาทักษะการเขียนซอฟต์แวร์ของตนมีประโยชน์ หากเราต้องการให้โปรแกรมของเราแครชให้น้อยที่สุดเท่าที่จะเป็นไปได้และทำงานโดยไม่มีข้อผิดพลาดให้นานที่สุด เราจำเป็นต้องแบ่งกระบวนการออกเวอร์ชันใหม่ออกเป็น 3 ขั้นตอน:

1. เวที แอสเซมบลี. คุณแปลงโค้ดเปล่าของคุณด้วยทรัพยากรแต่ละรายการให้กลายเป็นแพ็คเกจที่เรียกว่าประกอบด้วยโค้ดและข้อมูลที่จำเป็นทั้งหมด แพ็คเกจนี้เรียกว่าแอสเซมบลี
2. เวที ปล่อย — ที่นี่เราเชื่อมต่อการกำหนดค่าของเรากับแอสเซมบลี โดยที่เราไม่สามารถปล่อยโปรแกรมของเราได้ ตอนนี้เป็นรุ่นที่พร้อมเปิดตัวอย่างสมบูรณ์
3. ถัดมาเป็นเวที สมหวัง. ที่นี่เราเผยแพร่แอปพลิเคชันโดยการรันกระบวนการที่จำเป็นจากการเปิดตัวของเรา

ระบบดังกล่าวสำหรับการเปิดตัวโมเดลเวอร์ชันใหม่หรือไปป์ไลน์ทั้งหมดช่วยให้คุณสามารถแยกบทบาทระหว่างผู้ดูแลระบบและนักพัฒนา ช่วยให้คุณสามารถติดตามเวอร์ชันและป้องกันการหยุดโปรแกรมโดยไม่พึงประสงค์

สำหรับงานรีลีส ได้มีการสร้างบริการต่างๆ มากมายซึ่งคุณสามารถเขียนกระบวนการเพื่อรันด้วยตัวเองในไฟล์ .yml (เช่น ใน CircleCI นี่คือ config.yml เพื่อรองรับกระบวนการนั้นเอง) Wheely เก่งในการสร้างแพ็คเกจสำหรับโปรเจ็กต์

คุณสามารถสร้างแพ็คเกจด้วยเวอร์ชันต่างๆ ของโมเดล Machine Learning ของคุณ จากนั้นจัดแพ็กเกจและอ้างอิงถึงแพ็คเกจที่จำเป็นและเวอร์ชันเพื่อใช้ฟังก์ชันที่คุณเขียนจากที่นั่น สิ่งนี้จะช่วยคุณสร้าง API สำหรับโมเดลของคุณ และแพคเกจของคุณสามารถโฮสต์บน Gemfury ได้ เป็นต้น

หลักการที่ 6 รันโมเดลของคุณเป็นกระบวนการตั้งแต่หนึ่งกระบวนการขึ้นไป

นอกจากนี้ กระบวนการไม่ควรมีข้อมูลร่วมกัน นั่นคือ กระบวนการจะต้องมีแยกกัน และข้อมูลทุกประเภทจะต้องมีแยกกัน เช่น ในบริการของบุคคลที่สาม เช่น MySQL หรืออื่นๆ ขึ้นอยู่กับสิ่งที่คุณต้องการ

นั่นคือมันไม่คุ้มที่จะจัดเก็บข้อมูลภายในระบบไฟล์กระบวนการมิฉะนั้นอาจนำไปสู่การล้างข้อมูลนี้ในระหว่างการเผยแพร่ / การเปลี่ยนแปลงการกำหนดค่าครั้งถัดไปหรือการถ่ายโอนระบบที่โปรแกรมทำงาน

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

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

หลักการที่ 7: การรีไซเคิลได้

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

นั่นคือกระบวนการของคุณกับโมเดลควร:

• ลดเวลาเริ่มต้นให้เหลือน้อยที่สุด ตามหลักการแล้ว เวลาเริ่มต้น (จากช่วงเวลาที่ออกคำสั่งเริ่มต้นจนถึงช่วงเวลาที่กระบวนการเริ่มทำงาน) ควรจะไม่เกินสองสามวินาที การแคชไลบรารีตามที่อธิบายไว้ข้างต้นเป็นเทคนิคหนึ่งในการลดเวลาเริ่มต้น
• จบอย่างถูกต้อง นั่นคือการฟังบนพอร์ตบริการถูกระงับจริง ๆ และคำขอใหม่ที่ส่งไปยังพอร์ตนี้จะไม่ได้รับการประมวลผล ที่นี่คุณจะต้องตั้งค่าการสื่อสารที่ดีกับวิศวกร DevOps หรือทำความเข้าใจว่ามันทำงานอย่างไร (โดยเฉพาะอย่างยิ่งอย่างหลัง แต่ควรรักษาการสื่อสารไว้เสมอในทุกโครงการ!)

หลักการที่ 8: การปรับใช้/บูรณาการอย่างต่อเนื่อง

บริษัทหลายแห่งใช้การแยกระหว่างทีมพัฒนาแอปพลิเคชันและทีมปรับใช้ (ทำให้แอปพลิเคชันพร้อมใช้งานสำหรับผู้ใช้ปลายทาง) สิ่งนี้สามารถชะลอการพัฒนาซอฟต์แวร์และความคืบหน้าในการปรับปรุงได้อย่างมาก นอกจากนี้ยังทำลายวัฒนธรรม DevOps ที่ซึ่งการพัฒนาและการบูรณาการรวมเข้าด้วยกัน

ดังนั้นหลักการนี้ระบุว่าสภาพแวดล้อมการพัฒนาของคุณควรใกล้เคียงกับสภาพแวดล้อมการใช้งานจริงของคุณมากที่สุด

สิ่งนี้จะช่วยให้:

1. ลดเวลาการปลดปล่อยลงหลายสิบเท่า
2. ลดจำนวนข้อผิดพลาดเนื่องจากความไม่เข้ากันของโค้ด
3. นอกจากนี้ยังช่วยลดภาระงานของพนักงาน เนื่องจากขณะนี้นักพัฒนาและผู้ที่ใช้งานแอปพลิเคชันกลายเป็นทีมเดียวกันแล้ว

เครื่องมือที่ช่วยให้คุณทำงานได้ ได้แก่ CircleCI, Travis CI, GitLab CI และอื่นๆ

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

ลดความแตกต่าง!!!

หลักการที่ 9 บันทึกของคุณ

บันทึก (หรือ "บันทึก") คือเหตุการณ์ ซึ่งโดยปกติจะบันทึกในรูปแบบข้อความที่เกิดขึ้นภายในแอปพลิเคชัน (สตรีมเหตุการณ์) ตัวอย่างง่ายๆ: "2020-02-02 - ระดับระบบ - ชื่อกระบวนการ" ได้รับการออกแบบมาเพื่อให้นักพัฒนาสามารถเห็นอย่างแท้จริงว่าเกิดอะไรขึ้นเมื่อโปรแกรมกำลังทำงานอยู่ เขามองเห็นความก้าวหน้าของกระบวนการและเข้าใจว่าเป็นไปตามที่นักพัฒนาตั้งใจไว้หรือไม่

หลักการนี้ระบุว่าคุณไม่ควรจัดเก็บบันทึกของคุณไว้ในระบบไฟล์ของคุณ - คุณควรเพียง "ส่งออก" บันทึกเหล่านั้นไปที่หน้าจอ เช่น ทำสิ่งนี้กับเอาต์พุตมาตรฐานของระบบ และด้วยวิธีนี้จะสามารถตรวจสอบการไหลในเทอร์มินัลระหว่างการพัฒนาได้

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

หลักการที่ 10 ทดสอบ!

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

คุณสามารถสร้างการทดสอบได้โดยใช้ pytest และทดสอบโดยใช้ชุดข้อมูลขนาดเล็ก หากคุณมีงานการถดถอย/การจัดหมวดหมู่

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

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

ฉันจะพยายามใช้หลักการดีๆ ที่ใครๆ ก็สามารถแสดงความคิดเห็นไว้ในความคิดเห็นได้หากต้องการ

ที่มา: will.com