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

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

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

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

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

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

المبدأ 1: قاعدة كود واحدة

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

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

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

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

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

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

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

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

  • أعلن بوضوح عن التبعيات، أي الملف الذي سيحتوي على جميع المكتبات والأدوات وإصداراتها المستخدمة في مشروعك والتي يجب تثبيتها (على سبيل المثال، في Python يمكن القيام بذلك باستخدام Pipfile أو require.txt. الرابط الذي يتيح فهم جيد: realpython.com/pipenv-guide)
  • عزل التبعيات خصيصًا لبرنامجك أثناء التطوير. ألا ترغب في تغيير الإصدارات باستمرار وإعادة تثبيت Tensorflow على سبيل المثال؟

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

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

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

على سبيل المثال، قد يبدو ملف require.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 دولار.

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

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

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

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

  • أسماء النطاقات
  • عناوين URL لواجهة برمجة التطبيقات/عناوين URI
  • المفاتيح العامة والخاصة
  • جهات الاتصال (البريد والهواتف وما إلى ذلك)

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

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

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

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

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

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

المبدأ 5. البناء والإصدار ووقت التشغيل

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

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

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

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

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

المبدأ 6. قم بتشغيل النموذج الخاص بك كعملية واحدة أو أكثر

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

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

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

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

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

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

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

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

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

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

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

وهذا سيسمح:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

المصدر: www.habr.com

إضافة تعليق