MLOps وDevOps لأنظمة الذكاء الاصطناعي

MLOps: تلاقي DevOps مع تعلم الآلة

18 دقيقة الدرس 1 من 28

MLOps: تلاقي DevOps مع تعلم الآلة

لقد أمضيت الدروس الثمانية والأربعين الماضية في بناء الممارسات التي تجعل الأنظمة البرمجية جاهزة للإنتاج: خطوط CI/CD، وتنسيق الحاويات، وGitOps، ومكدسات الرؤية، وممارسات SRE، والوضعيات الأمنية. كل مبدأ استوعبته — انشر صغيرًا، وأتمت كل شيء، وقِس قبل وبعد، وامتلك حوادثك — لا يزال ينطبق هنا. لكن أنظمة تعلم الآلة تفرض مجموعة من المتطلبات الإضافية التي لم تُصمَّم أدوات DevOps التقليدية للتعامل معها.

MLOps هو الانضباط التشغيلي الذي يمتد بـDevOps ليشمل دورة حياة نماذج تعلم الآلة بالكامل: استيعاب البيانات، وهندسة الميزات، وتتبع التجارب، وتدريب النماذج، والتقييم، والنشر، والمراقبة المستمرة. في الشركات الكبرى (Google وMeta وAmazon وUber)، تبني فرق مخصصة لمنصات التعلم الآلي — تضم من 10 إلى 50 مهندسًا — وتشغّل بنية تحتية داخلية لـMLOps تعتمد عليها منظمات علم البيانات وهندسة التعلم الآلي. فهم سبب وجود هذه البنية التحتية — وما الذي سينهار بدونها — هو أساس هذه الدورة التعليمية.

كيف تختلف أنظمة التعلم الآلي عن البرمجيات التقليدية

النظام التقليدي يملك علاقة محددة بين الكود والسلوك: عدّل الكود، يتغير السلوك، أرسله، وتحقق منه. يُدخل نظام تعلم الآلة عنصرًا ثالثًا حاملًا للحِمل — البيانات — وهو عنصر أصعب بكثير في الإصدار والاختبار والحوكمة.

تتجلى الاختلافات في أربعة مجالات لا تملك خطوط DevOps إجابة أصيلة عنها:

تبعيات البيانات: يُحدَّد سلوك النموذج ليس فقط بالكود بل بمجموعة بيانات التدريب. كودبيسان متطابقان مدرَّبان على بيانات مختلفة ينتجان نموذجين مختلفين تمامًا. "مصدر الحقيقة" يشمل الآن عشرات التيرابايتات من البيانات المنظمة وغير المنظمة، وتعريفات خطوط الأنابيب الصاعدة، ومنطق تحويل الميزات، وعقود المخطط بين الفرق. خطأ في خط أنابيب الميزات قد يُفسد النموذج بصمت لأشهر قبل أن يلاحظه أحد.
تجارب لا نشرات: يفتح مهندسو البرمجيات طلب سحب ويدمجون تغييرًا. يُجري مهندسو التعلم الآلي مئات أو آلاف تجارب التدريب — يغيّرون المعلمات الفائقة والمعماريات ومجموعات الميزات ودوال الخسارة — ويختارون أفضل نتيجة. بدون تتبع منهجي، لا يمكنك إعادة إنتاج نتيجة من الأسبوع الماضي، أو شرح سبب اختيار النموذج الذي ذهب للإنتاج، أو تدقيق قرار تنظيمي. هذه هي مشكلة تتبع التجارب.
عدم الحتمية: جولتا تدريب بنفس الكود ونفس البيانات على نفس العتاد قد تنتجان نموذجين بدقة مختلفة قياسيًا، بسبب التهيئة العشوائية للأوزان، ونوى GPU غير الحتمية، وفروق العمليات الحسابية ذات الفاصلة العائمة عبر أجيال العتاد. "يعمل على جهازي" اكتسب معنىً جديدًا كليًا حين يكون المخرج تنسورًا يحوي 7 مليارات وزن.
انجراف النموذج: البرمجيات المنشورة لا تتدهور من تلقاء نفسها. النموذج المنشور في يناير سيفقد دقته تدريجيًا إذا تحوّل توزيع المدخلات الحقيقية عن توزيع بيانات التدريب. نموذج كشف الاحتيال المدرَّب على أنماط معاملات 2023 سيبدأ في تفويت تقنيات احتيال 2024 الجديدة في غضون أسابيع. هذا هو انجراف المفهوم — وليس له مقابل في العمليات البرمجية التقليدية. لا يوجد تنبيه يُطلق تلقائيًا؛ عليك بناء المراقبة بنفسك.

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

دورة حياة نظام التعلم الآلي — مُخطَّطة

دورة حياة التعلم الآلي ليست خط أنابيب بالمعنى التقليدي؛ بل هي حلقة بدورات تغذية راجعة يمكنها إعادة الضبط أو التفرع في أي مرحلة. فهم موضع كل فئة أدوات في هذه الحلقة هو شرط مسبق لبقية هذه الدورة التعليمية.

دورة حياة نظام التعلم الآلي: حلقة تغذية راجعة عبر ست مراحل، يُشغّل فيها اكتشاف الانجراف إعادة التدريب التلقائية.

البيانات: العنصر من الدرجة الأولى

في منظمة تعلم الآلة المنظمة، تُصدَّر البيانات وتُختبر وتُدار بنفس الصرامة المطبَّقة على الكود. الأدوات الأساسية هي مخزن الميزات (مستودع مركزي للميزات المحسوبة يمكن مشاركتها عبر النماذج وتقديمها بزمن استجابة منخفض) وخط أنابيب البيانات القابل لإعادة الإنتاج بالضبط. منصة Michelangelo من Uber — أقدم نظام MLOps داخلي واسع النطاق نُشر بالتفصيل — تُحدد "إدارة البيانات" باعتبارها الطبقة الأكثر عرضة للأخطاء. نمط الفشل الشائع: يُحسَب ميزة بشكل مختلف في التدريب (SQL دُفعي على البيانات التاريخية) عنه في الخدمة (كود تطبيق في الوقت الحقيقي)، مما يُنتج تباينًا توزيعيًا صامتًا يُعرف بـالانحراف بين التدريب والخدمة. هذا الأمر مسؤول عن نسبة كبيرة من حوادث تدهور النماذج في الشركات ذات النطاق الواسع.

# ضبط إصدارات البيانات بـDVC (التحكم في إصدار البيانات) — يعامل مجموعات البيانات كما يعامل Git الكود.
# تهيئة جانب مستودع Git الحالي:
pip install dvc dvc-s3

git init
dvc init

# تتبع مجموعة بيانات تدريب كبيرة مخزنة في S3:
dvc remote add -d myremote s3://my-ml-bucket/dvc-store
dvc add data/training_features.parquet
git add data/training_features.parquet.dvc .gitignore
git commit -m "track training features v1"
dvc push

# إعادة إنتاج الحالة الدقيقة لمجموعة البيانات على أي جهاز أو في CI:
dvc pull
# ملف .dvc مُودَع في Git — تمامًا كملف القفل.
# dvc pull يجلب النقطة الثنائية المحددة بالمحتوى من S3.

التجارب: الفجوة بين البحث والهندسة

كل مشروع تعلم آلة يتضمن فترة من التجريب: أي معمارية تُحقق أفضل أداء، وأي ميزات تهم، وما نظام التنظيم الذي يمنع الإفراط في التخصيص على مجموعة التحقق. هذا ضروري وصحي. نمط الفشل التشغيلي هو تشغيل هذا التجريب بشكل غير رسمي — دفاتر ملاحظات على حاسوب محلي، ومقاييس مطبوعة على stdout، وأوزان نماذج محفوظة في model_v3_final_FINAL.pkl. حين يحين وقت إعادة إنتاج التجربة التي أنتجت أفضل نموذج، لا تستطيع ذلك، لأن المعلمات الفائقة الدقيقة وإصدار البيانات والبذرة العشوائية وإصدارات المكتبات لم تُسجَّل قط.

أدوات تتبع التجارب — MLflow (مفتوح المصدر، ذاتي الاستضافة)، وWeights and Biases (SaaS مُدار)، وNeptune — تحل هذا بتسجيل كل معلمات جولة التدريب ومقاييسها وعناصرها وبيئتها تلقائيًا في قاعدة بيانات قابلة للاستعلام. المخرج هو إدخال في سجل النماذج يربط العنصر المنشور بالتجربة الدقيقة التي أنتجته.

# تتبع تجارب MLflow — توثيق بسيط في سكريبت تدريب:
import mlflow
import mlflow.sklearn
from sklearn.ensemble import GradientBoostingClassifier

mlflow.set_experiment("fraud-detection-v2")

with mlflow.start_run():
    params = {"n_estimators": 200, "max_depth": 5, "learning_rate": 0.05}
    mlflow.log_params(params)

    model = GradientBoostingClassifier(**params)
    model.fit(X_train, y_train)

    auc = roc_auc_score(y_val, model.predict_proba(X_val)[:, 1])
    mlflow.log_metric("val_auc", auc)

    # تسجيل عنصر النموذج مع مخطط المدخلات والمخرجات
    mlflow.sklearn.log_model(model, "model",
        registered_model_name="fraud-detection")

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

الانجراف: التدهور الصامت

هذا هو القلق الذي لا يملك DevOps التقليدي مقابلًا له. بعد نشر النموذج، يستمر العالم في التغيير. انجراف البيانات (يُسمى أيضًا تحوّل التغاير) يعني أن التوزيع الإحصائي للميزات المدخلة قد تحوّل — نموذج التوصية المدرَّب قبل إعادة تصميم المنتج الكبرى يرى مدخلات لم يُدرَّب عليها قط. انجراف المفهوم يعني أن العلاقة بين المدخلات والمخرج الصحيح قد تغيّرت — نموذج التنبؤ بالإلغاء المدرَّب في 2023 قد لا يعكس أنماط سلوك المستخدم الحالية بعد الآن.

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

في Google، يُحدد ورقة بنية التعلم الآلي "تعلم الآلة: بطاقة الائتمان عالية الفائدة للدين التقني" (Sculley وآخرون، 2015) مراقبة الانجراف باعتبارها من أقل المجالات استثمارًا في أنظمة التعلم الآلي. الرؤية الجوهرية في الورقة: تتراكم أنظمة التعلم الآلي الدين التقني بطرق غير مرئية في مراجعة الكود التقليدية. الدفاع الوحيد هو التوثيق التشغيلي.

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

مستويات نضج MLOps

تُعرّف ورقة MLOps من Google ثلاثة مستويات نضج، ومعرفة موقعك تُحدد أي استثمارات في الأدوات تستحق التطبيق أولًا:

المستوى 0 — العملية اليدوية: يُدرّب علماء البيانات النماذج في دفاتر الملاحظات ويُسلّمون العناصر لفرق العمليات التي تنشرها كثنائيات ثابتة. إعادة التدريب تحدث بشكل تفاعلي، أشهرًا بعد ملاحظة الانجراف. غالبية الشركات التي تشغّل التعلم الآلي في الإنتاج موجودة هنا.
المستوى 1 — أتمتة خط أنابيب التعلم الآلي: التدريب خط أنابيب معلمي يعمل تلقائيًا عند وصول بيانات جديدة. تتبع التجارب موجود. مخزن الميزات وسجل النماذج متاحان. تُعاد تدريب النماذج وفق جدول زمني أو عند بدء الانجراف.
المستوى 2 — CI/CD لخطوط أنابيب التعلم الآلي: خط أنابيب التدريب نفسه مُراجَع كوديًا ومُختبَر بالوحدات ومنشور عبر نظام CI/CD. إضافة ميزة جديدة أو تغيير معمارية النموذج يُشغّل تشغيلًا كاملًا لخط الأنابيب الآلي يشمل بوابات التقييم والطرح المُدرَّج. هذا هو المعيار في Google وUber وAirbnb لأنظمة التعلم الآلي الحرجة لديها.

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

الربط بمكدس DevOps الموجود

MLOps ليس بديلًا عن DevOps — بل هو طبقة فوقه. مجموعة Kubernetes التي تشغّلها هي مستوى الحوسبة لوظائف التدريب (عبر Kubeflow أو Argo Workflows) ولخدمة النماذج (عبر KServe). مكدس الرؤية Prometheus وGrafana الذي تُشغّله يراقب زمن الاستجابة والإنتاجية لخدمة النماذج. سير عمل GitOps الذي تستخدمه لنشرات التطبيقات ينطبق بالتساوي على تعريفات خطوط أنابيب التعلم الآلي المخزنة كود. ممارسات الأمان وإدارة الأسرار التي أرسيتها تحمي بيانات اعتماد الوصول لبيانات التدريب وتوقيع عناصر النماذج.

الدروس التسعة التالية في هذه الدورة تتعمق في كل مرحلة من مراحل دورة الحياة: خطوط أنابيب البيانات والميزات، وتتبع التجارب، وبنية تحتية لتدريب GPU، وCI/CD للنماذج، وأنماط الخدمة، ومراقبة الإنتاج، وعمليات LLM، وحوكمة التكلفة، ومشروع تصميم منصة تعلم الآلة. كل درس يبني على مكوّن واحد من مخطط دورة الحياة أعلاه — ويبني على البنية التحتية لـDevOps التي تعرف كيف تشغّلها بالفعل.