ماذا تعني CI/CD للنماذج

يعني CI/CD أتمتة الخطوات بين كتابة التعليمات البرمجية وشحنها، بحيث يتحقّق جهاز من عملكم وينشره بدلًا من تنفيذ ذلك يدويًا. 🚀

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

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

يشحن CI/CD التقليدي التعليمات البرمجية. أما مسارات ML فتشحن أيضًا نموذجًا مدرّبًا والبيانات التي تعلّم منها، ولذلك أصبح لديكم ثلاثة أجزاء متغيّرة لتتبّعها بدلًا من جزء واحد.

تتحقّق اختبارات التطبيق من المنطق. أما CI الخاص بـ ML فيتحقّق أيضًا من جودة النموذج، ويسأل: هل حافظت الدقة على مستواها؟ وليس فقط: هل عملت التعليمات البرمجية دون تعطل؟

يستغرق بناء التعليمات البرمجية ثواني. أما تدريب نموذج فقد يستغرق دقائق أو ساعات، لذلك تدرّب مسارات ML غالبًا على عيّنة صغيرة في CI وعلى البيانات الكاملة عند الإصدار فقط.

لإعادة بناء أي نموذج بالطريقة نفسها تمامًا، يجب تثبيت إصدار التعليمات البرمجية وإصدار البيانات والبيئة. ويجعل CI/CD الخاص بـ ML تثبيت هذه العناصر الثلاثة تلقائيًا.

يكون الناتج في CI/CD الخاص بالتطبيق ملفًا ثنائيًا. أما المُنتج النهائي الأهم في ML فهو ملف النموذج المدرّب، الذي تحدّدون إصداره وتخزّنونه ثم تنشرونه لاحقًا.

يربط مسار ML مراحل واضحة: فحص نمط التعليمات البرمجية، وتشغيل الاختبارات، والتدريب، والتقييم، ثم بناء الصورة القابلة للنشر فقط.

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

من دون CI/CD، لا يصبح النموذج متاحًا إلا عندما يتذكّر أحدهم تشغيل البرامج النصية. أما معه، فتُجرى اختبارات لكل تغيير ويُشحن بالطريقة الآمنة نفسها في كل مرة.

ما العنصر الإضافي الذي يتتبّعه CI/CD الخاص بـ ML ولا يتتبّعه CI/CD التقليدي للتطبيقات؟

يختبر CI كل تغيير، ويشحنه CD، أما في ML فتضيفون النموذج وبياناته بوصفهما مُنتجين نهائيين متتبَّعين. وتجعل المشغّلات والمسارات المرحلية الإصدارات آمنة وقابلة للتكرار.