Continuous Integration (CI)

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

آلية عمل مسار CI#

عندما يدفع مطور فرعًا أو يفتح طلب سحب، تبدأ خدمة CI مثل GitHub Actions أو GitLab CI/CD أو Jenkins عامل تشغيل جديدًا، وتستنسخ الشيفرة وتثبت الاعتماديات وتشغّل سلسلة من المهام: أدوات فحص الشيفرة ومُدققات الأنواع واختبارات الوحدات واختبارات التكامل وبناء الحزم أو صور الحاويات. تبلغ كل مهمة طلب السحب بحالتها، ويمكن لقواعد حماية الفروع حظر الدمج إلى أن تنجح كل الفحوص المطلوبة. وغالبًا ما تكرر المسارات الاختبارات نفسها عبر مصفوفة من أنظمة التشغيل وإصدارات Python، ثم تعيد تشغيل المجموعة الكاملة على الفرع الرئيسي بعد كل دمج. السرعة جزء من هذه الممارسة: فقد حددت البرمجة القصوى عند بيك هدفًا يتمثل في عشر دقائق لبناء النظام بأكمله وتشغيل كل اختبار، لأن البناء الأبطأ يقلل من عدد مرات تشغيله.

CI لتعلم الآلة#

تضيف مشاريع تعلم الآلة فحوصًا خاصة بها. تؤكد اختبارات البيانات أن بيانات التدريب الجديدة تطابق مخطط البيانات المتوقع، وأن تحليل كل ملف تسميات ينجح، وألا تظهر أي صورة في تقسيمي التدريب والتحقق معًا، الأمر الذي قد يؤدي إلى تسرّب البيانات. يُدرّب اختبار تمهيدي النموذج لمدة حقبة واحدة على مجموعة بيانات صغيرة جدًا، بهدف اكتشاف أخطاء الأبعاد والأعطال في غضون دقائق. تثبّت الاختبارات التي تقارن مخرجات النموذج البذور العشوائية وتسمح بهوامش تفاوت عددية صغيرة، لأن نوى GPU وترتيب تحميل البيانات قد يغيّران نتائج الحسابات بالفاصلة العائمة من تشغيل إلى آخر. تقيّم بوابة الجودة النموذج على مجموعة تحقق ثابتة، وتفشل عملية البناء إذا انخفض مقياس مثل متوسط الدقة المتوسطة (mAP) عن حد أدنى؛ وتتحقق اختبارات التصدير من أن إصدارات النموذج بصيغتي ONNX أو TensorRT لا تزال تُحمّل وتُحرز درجات مماثلة لدرجات النموذج الأصلي. يستغرق التدريب الكامل وقتًا طويلًا، وبيئات التشغيل التي تعتمد على GPU باهظة التكلفة، لذا تشغّل الفرق عادةً الفحوص السريعة مع كل طلب سحب، وتترك إعادة التدريب الكامل ونشر النموذج لعمليات التشغيل المجدولة أو عمليات التشغيل على الفرع الرئيسي؛ وتتيح أدوات إدارة الإصدارات مثل DVC لكل مهمة جلب إصدار مجموعة البيانات المحدد الذي تحتاج إليه.

يعمل وضع قياس الأداء في Ultralytics YOLO كبوابة من هذا النوع: فعندما يُضبط verbose على قيمة عائمة مثل 0.216، يرفع خطأً إذا فشل التصدير أو لم يتجاوز mAP_50-95 لأي تنسيق مُصدّر ذلك الحد الأدنى، ويستخدمه CI الخاص بمستودع Ultralytics لاختبار عمليات تصدير YOLO26 على عمال تشغيل Linux وmacOS وARM. ويجمع سير عمل GitHub Actions مبسط اختبارات الوحدات مع تلك البوابة:

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v6
        with:
          python-version: "3.13"
      - run: pip install ultralytics pytest
      - run: pytest tests/
      # Fail if the ONNX export breaks or its mAP50-95 is not above the 0.216 floor
      - run: yolo benchmark model=yolo26n.pt format=onnx imgsz=160 verbose=0.216

يشغّل كل طلب سحب وكل عملية دفع إلى main المهمة على عامل تشغيل Ubuntu جديد. ويحوّل فشل اختبار وحدة أو انخفاض درجة نموذج ONNX عن الحد الأدنى أو مساواتها له على مجموعة البيانات الصغيرة COCO8 نتيجة الفحص إلى اللون الأحمر قبل إمكان دمج التغيير.

CI في مقابل CD وMLOps والتدريب المستمر#

• التسليم المستمر (CD): يأخذ عمليات البناء التي اجتازت CI ويبقيها جاهزة للإصدار، وغالبًا ما ينشرها تلقائيًا في بيئة تجريبية. أما النشر المستمر، فيتجاوز ذلك خطوةً أخرى، إذ يرسل كل تغيير ناجح إلى بيئة الإنتاج.
• MLOps: مجال أوسع يجمع بين CI وCD وتحديد إصدارات البيانات ونشر النماذج ومراقبتها وإعادة تدريبها عبر دورة حياة تعلم الآلة.
• التدريب المستمر (CT): يعيد تدريب النموذج وينشره تلقائيًا عند وصول بيانات جديدة أو اكتشاف المراقبة انحرافًا. وتضع مستويات نضج MLOps من Google إعادة التدريب الآلية في المستوى 1، وCI/CD الآلي لمسار التدريب نفسه في المستوى 2.