تعلم الآلة الصناعية: 10 مبادئ تصميم

تعلم الآلة الصناعية: 10 مبادئ تصميم



في الوقت الحاضر ، يتم إنشاء خدمات وتطبيقات وبرامج مهمة أخرى جديدة كل يوم تتيح لك إنشاء أشياء لا تصدق: من برامج التحكم في صاروخ SpaceX إلى التفاعل مع غلاية في الغرفة المجاورة عبر هاتف ذكي.



وفي بعض الأحيان ، يدرك كل مبرمج مبتدئ ، سواء كان شركة ناشئة شغوفة أو شركة Full Stack عادية أو عالم بيانات ، عاجلاً أم آجلاً أن هناك قواعد معينة للبرمجة وإنشاء البرامج التي تبسط الحياة بشكل كبير.



في هذه المقالة ، سأصف بإيجاز 10 مبادئ لكيفية برمجة التعلم الآلي الصناعي بحيث يمكن دمجه بسهولة في تطبيق / خدمة ، بناءً على منهجية التطبيق المكونة من 12 عاملاً التي اقترحها فريق Heroku.... مبادرتي هي زيادة الوعي بهذه التقنية ، والتي يمكن أن تساعد العديد من المطورين والأفراد من علوم البيانات.



هذه المقالة هي مقدمة لسلسلة من المقالات حول التعلم الآلي الصناعي. في نفوسهم ، سأستمر في الحديث عن كيفية صنع نموذج وتشغيله في الإنتاج ، وإنشاء واجهة برمجة تطبيقات له ، بالإضافة إلى أمثلة من مختلف المجالات والشركات التي قامت بتضمين ML في أنظمتها.



المبدأ الأول: قاعدة رمز واحدة



بعض المبرمجين في المراحل المبكرة ، بدافع الكسل لمعرفة ذلك (أو لسبب ما) ينسون Git. ينسون إما من الكلمة على الإطلاق ، أي أنهم يرمون الملفات لبعضهم البعض في محرك الأقراص / فقط يرمون النص / يرسلون الحمائم ، أو لا يفكرون في سير العمل ، ويلتزمون كل منهم بفرعهم الخاص ، ثم إلى السيد.



يقول هذا المبدأ: أن يكون لديك قاعدة بيانات واحدة والعديد من عمليات النشر.



يمكن استخدام Git في كل من الإنتاج والبحث والتطوير (R & D) ، حيث يتم استخدامه بشكل أقل.



على سبيل المثال ، في مرحلة البحث والتطوير ، يمكنك ترك التزامات بأساليب ونماذج معالجة بيانات مختلفة ، من أجل اختيار أفضلها ومواصلة العمل معها بسهولة.



ثانيًا ، هذا شيء لا يمكن الاستغناء عنه في الإنتاج - ستحتاج إلى النظر باستمرار في كيفية تغيير الكود الخاص بك ومعرفة النموذج الذي أعطى أفضل النتائج ، وما الرمز الذي يعمل في النهاية وما حدث ، بسبب ما توقف عن العمل أو بدأ في الإصدار نتائج غير صحيحة. هذا ما يرتكبه!



وأيضًا يمكنك إنشاء حزمة من مشروعك عن طريق وضعها ، على سبيل المثال ، على Gemfury ، ثم استيراد وظائف منها ببساطة لمشاريع أخرى ، حتى لا يتم إعادة كتابتها 1000 مرة ، ولكن المزيد عن ذلك لاحقًا.



المبدأ الثاني: إعلان وعزل التبعيات بوضوح



لكل مشروع مكتبات مختلفة تقوم باستيرادها من الخارج لتطبيقها في مكان ما. سواء كانت مكتبات Python ، أو مكتبات لغات أخرى ذات أغراض مختلفة ، أو أدوات نظام - مهمتك هي:





وبالتالي ، سيتمكن المطورون الذين سينضمون إلى فريقك في المستقبل من التعرف سريعًا على المكتبات وإصداراتها المستخدمة في مشروعك ، كما ستتمكن من التحكم في الإصدارات والمكتبات نفسها التي تم تثبيتها لمشروع معين ، مما سيساعدك على تجنب عدم توافق المكتبات أو إصداراتها.



لا يحتاج تطبيقك أيضًا إلى الاعتماد على أدوات النظام التي قد تكون مثبتة على نظام تشغيل معين. يجب أيضًا الإعلان عن هذه الأدوات في بيان التبعيات. يعد هذا ضروريًا لتجنب المواقف التي لا يتطابق فيها إصدار الأدوات (بالإضافة إلى توفرها) مع أدوات النظام لنظام تشغيل معين.



وبالتالي ، حتى إذا كان من الممكن استخدام curl على جميع أجهزة الكمبيوتر تقريبًا ، فلا يزال يتعين عليك التصريح عنه في التبعيات ، لأنه عند الترحيل إلى نظام أساسي آخر ، قد لا يكون موجودًا أو لن يكون الإصدار هو الإصدار الذي تحتاجه في الأصل.



على سبيل المثال ، قد تبدو متطلباتك .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


المبدأ الثالث: التكوينات



لقد سمع الكثير من القصص التي قام فيها العديد من رجال التطوير عن طريق الخطأ بتحميل التعليمات البرمجية إلى GitHub في مستودعات مفتوحة مع كلمات مرور ومفاتيح أخرى من AWS ، والاستيقاظ في اليوم التالي لديون بقيمة 6000 دولار ، أو حتى مع كل 50000 دولار.







بالطبع ، هذه الحالات متطرفة ، لكنها كاشفة للغاية. إذا قمت بتخزين بيانات الاعتماد الخاصة بك أو غيرها من البيانات المطلوبة للتكوين داخل الكود ، فأنت ترتكب خطأ ، وأعتقد أنه لا يستحق شرح السبب.



بديل لذلك هو تخزين التكوينات في متغيرات البيئة. يمكنك قراءة المزيد عن متغيرات البيئة هنا .



أمثلة على البيانات التي يتم تخزينها عادة في متغيرات البيئة:



  • أسماء المجال
  • عنوان URL لواجهة برمجة التطبيقات / معرّف الموارد المنتظم
  • المفاتيح العامة والخاصة
  • جهات الاتصال (البريد ، الهواتف ، إلخ.)


بهذه الطريقة ، لن تضطر إلى تغيير الكود باستمرار إذا تغيرت متغيرات التكوين الخاصة بك. سيوفر لك هذا الوقت والجهد والمال.



على سبيل المثال ، إذا كنت تستخدم Kaggle API لإجراء اختبارات (على سبيل المثال ، يمكنك تنزيل النموذج وتشغيله من خلاله لاختبار أن النموذج يعمل جيدًا عند بدء التشغيل) ، فيجب تخزين المفاتيح الخاصة من Kaggle ، مثل KAGGLE_USERNAME و KAGGLE_KEY ، في متغيرات البيئة.



المبدأ 4: خدمات الطرف الثالث



الفكرة هنا هي تصميم البرنامج بحيث لا يوجد تمييز بين الموارد المحلية وموارد الطرف الثالث من حيث الكود. على سبيل المثال ، يمكنك توصيل كل من MySQL المحلي وطرف ثالث. الشيء نفسه ينطبق على واجهات برمجة التطبيقات المختلفة مثل خرائط Google أو Twitter API.



لتعطيل خدمة جهة خارجية أو توصيل خدمة أخرى ، تحتاج فقط إلى تغيير المفاتيح في التكوين في متغيرات البيئة ، والتي تحدثت عنها في الفقرة أعلاه.



لذلك ، على سبيل المثال ، بدلاً من تحديد كل مرة المسار إلى الملفات التي تحتوي على مجموعات بيانات داخل الكود ، فمن الأفضل استخدام مكتبة pathlib والإعلان عن المسار إلى مجموعات البيانات في config.py ، بحيث بغض النظر عن الخدمة التي تستخدمها (على سبيل المثال ، CircleCI) ، فإن البرنامج تمكنت من العثور على المسار إلى مجموعات البيانات ، مع مراعاة هيكل نظام الملفات الجديد في الخدمة الجديدة.



المبدأ الخامس: البناء والإصدار ووقت التشغيل



يجد العديد من العاملين في علوم البيانات أنه من المفيد تعلم مهارات كتابة البرامج. إذا أردنا أن يتعطل برنامجنا بأكبر قدر ممكن وأن يعمل بسلاسة لأطول فترة ممكنة ، فنحن بحاجة إلى تقسيم عملية إصدار الإصدار الجديد إلى 3 مراحل:



  1. . , . .
  2. — config, . .
  3. . .


يسمح مثل هذا النظام لإصدار إصدارات جديدة من نموذج أو خط الأنابيب بأكمله بتقسيم الأدوار بين المسؤولين والمطورين ، ويسمح بتتبع الإصدارات ويمنع التوقفات غير المرغوب فيها للبرنامج.



بالنسبة لمهمة الإصدار ، تم إنشاء العديد من الخدمات المختلفة التي يمكنك من خلالها كتابة عمليات لتشغيل نفسك في ملف .yml (على سبيل المثال ، في CircleCI هذا هو config.yml لدعم العملية نفسها). Wheely رائع في إنشاء حزم للمشاريع.



ستتمكن من إنشاء حزم بإصدارات مختلفة من نموذج التعلم الآلي الخاص بك ، ثم حزمها والرجوع إلى الحزم الضرورية وإصداراتها من أجل استخدام الوظائف التي كتبتها من هناك. سيساعدك هذا في إنشاء واجهة برمجة تطبيقات للنموذج الخاص بك ، ويمكن وضع الحزمة الخاصة بك على Gemfury على سبيل المثال.



المبدأ السادس: نقوم بتشغيل النموذج الخاص بك كعملية واحدة أو عدة عمليات



علاوة على ذلك ، يجب ألا يكون للعمليات بيانات مشتركة. بمعنى ، يجب أن توجد العمليات بشكل منفصل ، ويجب أن توجد جميع أنواع البيانات بشكل منفصل ، على سبيل المثال ، في خدمات الجهات الخارجية مثل MySQL أو غيرها ، اعتمادًا على ما تحتاجه.



أي أنه لا يستحق بالتأكيد تخزين البيانات داخل نظام الملفات الخاص بالعملية ، وإلا فقد يؤدي ذلك إلى مسح هذه البيانات في الإصدار التالي / تغيير التكوينات أو نقل النظام الذي يعمل عليه البرنامج.



ولكن هناك استثناء: بالنسبة لمشاريع التعلم الآلي ، يمكنك تخزين ذاكرة التخزين المؤقت للمكتبة بحيث لا تعيد تثبيتها في كل مرة تقوم فيها بتشغيل إصدار جديد ، إذا لم يتم إجراء مكتبات إضافية أو أي تغييرات في إصداراتها. وبالتالي ، ستقوم بتقصير وقت إطلاق نموذجك في الصناعة.



لتشغيل النموذج كعدة عمليات ، يمكنك إنشاء ملف .yml تشير فيه فقط إلى العمليات الضرورية وتسلسلها.



المبدأ السابع: إعادة التدوير



يجب أن تكون العمليات التي يتم إجراؤها على النموذج في التطبيق الخاص بك سهلة البدء والتوقف. وبالتالي ، سيسمح لك بنشر تغييرات التعليمات البرمجية وتغييرات التكوين بسرعة ومرونة وتوسيع نطاق ومنع الأعطال المحتملة لإصدار العمل.



وهذا يعني أن عمليتك مع النموذج يجب أن:



  • . ( , , ) . , — .
  • . , , , . DevOps , , (, , , , !)


المبدأ 8: النشر / التكامل المستمر



تستخدم العديد من الشركات الفصل بين فرق تطوير التطبيق والنشر (مما يجعل التطبيق متاحًا للمستخدمين النهائيين). يمكن أن يؤدي هذا إلى إبطاء تطوير البرامج بشكل كبير والتقدم نحو تحسينها. كما أنه يفسد ثقافة DevOps ، حيث يتم الجمع بين التنمية والتكامل تقريبًا.



لذلك ، ينص هذا المبدأ على أن بيئة التطوير الخاصة بك يجب أن تكون قريبة قدر الإمكان من بيئة الإنتاج لديك.



وهذا سيسمح:



  1. تقليل وقت الإطلاق عشرة أضعاف
  2. قلل عدد الأخطاء بسبب عدم توافق الكود.
  3. كما أنه يقلل العبء على الموظفين ، لأن المطورين والأشخاص الذين ينشرون التطبيق هم الآن فريق واحد.


الأدوات التي تسمح لك بالعمل مع هذه هي CircleCI و Travis CI و GitLab CI وغيرها.



يمكنك إجراء إضافات إلى النموذج بسرعة وتحديثه وتشغيله على الفور ، بينما سيكون من السهل ، في حالة الفشل ، العودة بسرعة كبيرة إلى إصدار العمل دون أن يلاحظه المستخدم النهائي. يمكن القيام بذلك بسرعة وسهولة خاصة إذا كانت لديك اختبارات جيدة.



تقليل الاختلافات !!!



المبدأ 9. سجلاتك



السجلات (أو "السجلات") هي أحداث مسجلة ، عادة بتنسيق نصي ، تحدث داخل التطبيق (دفق الأحداث). مثال بسيط: "2020-02-02 - مستوى النظام - اسم العملية". تم تصميمها بحيث يتمكن المطور من رؤية ما يحدث عند تشغيل البرنامج. إنه يرى تقدم العمليات ، ويفهم ما إذا كان هو كما أراد المطور نفسه.



ينص هذا المبدأ على أنه لا يجب عليك تخزين سجلاتك داخل نظام الملفات الخاص بك - فأنت تحتاج فقط إلى "عرضها" ، على سبيل المثال ، القيام بذلك في الإخراج القياسي للنظام stdout. وبهذه الطريقة ، يمكن مراقبة التدفق في الجهاز أثناء التطوير.



هل هذا يعني أنك لست بحاجة إلى حفظ السجلات على الإطلاق؟ بالطبع لا. كل ما في الأمر أن تطبيقك لا يجب أن يفعل ذلك - اتركه لخدمات الجهات الخارجية. يمكن للتطبيق الخاص بك فقط إعادة توجيه السجلات إلى ملف معين أو محطة طرفية للعرض المباشر ، أو إعادة توجيهها إلى نظام تخزين للأغراض العامة (مثل Hadoop). يجب ألا يخزن تطبيقك نفسه السجلات أو يتفاعل معها.



المبدأ 10. الاختبار!



بالنسبة لتعلم الآلة الصناعية ، تعد هذه المرحلة مهمة للغاية ، حيث تحتاج إلى فهم أن النموذج يعمل بشكل صحيح ويعطيك ما تريد.



يمكن إنشاء الاختبارات باستخدام pytest ، واختبارها باستخدام مجموعة بيانات صغيرة إذا كانت لديك مهمة انحدار / تصنيف.



لا تنس أن تضع نفس البذرة لنماذج التعلم العميق بحيث لا ينتج عنها نتائج مختلفة باستمرار.



كان هذا وصفًا موجزًا ​​لـ 10 مبادئ ، وبالطبع من الصعب استخدامها دون محاولة ورؤية كيفية عملها ، لذا فإن هذه المقالة هي مجرد مقدمة لسلسلة من المقالات الشيقة التي سأكشف فيها عن كيفية إنشاء نماذج تعلم الآلة الصناعية. كيفية دمجها في الأنظمة ، وكيف يمكن لهذه المبادئ أن تجعل الحياة أسهل لنا جميعًا.



سأحاول أيضًا استخدام مبادئ رائعة يمكن لأي شخص تركها في التعليقات إذا أراد ذلك.



All Articles