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

تتبع التجارب وسجلات النماذج

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

تتبع التجارب وسجلات النماذج

في شركات مثل Google وMeta وUber، قد يكون النموذج الوحيد في الإنتاج ناتجًا عن آلاف من عمليات التدريب — بمجموعات مختلفة من الميزات ومعدلات التعلم واستراتيجيات التنظيم وإعدادات الأجهزة. بدون تتبع منضبط، لا يمكنك الإجابة عن أبسط سؤال إنتاجي: لماذا يتصرف النموذج الموجود في الإنتاج بشكل مختلف عن النموذج الذي عرضه فريق علم البيانات الأسبوع الماضي؟ تتبع التجارب وسجلات النماذج هما نظام إدارة الإصدارات ومخزن الأدوات في تعلم الآلة، وهما الأساس الذي تبنى عليه كل ممارسة أخرى في MLOps.

ما الذي يُتتبع ولماذا

كل عملية تدريب تُنتج عدة فئات من المخرجات يجب التقاطها معًا لضمان إمكانية إعادة تشغيل التجربة:

المعاملات (Parameters) — المعاملات الفائقة التي تُمرَّر إلى مهمة التدريب كمعدل التعلم وحجم الدُفعة ومعاملات التنظيم وأعلام البنية المعمارية.
المقاييس (Metrics) — سلاسل زمنية للخسارة والدقة وF1 وAUC أو أي إشارات ذات صلة بالمجال، يتم تسجيلها على فترات خطوات قابلة للإعداد.
المخرجات (Artefacts) — الأوزان المُسلسَلة للنموذج وخطوط معالجة هندسة الميزات والمحللات الرمزية وتقارير التقييم التي يجب أن ترافق النموذج.
البيئة (Environment) — إصدار Python وإصدارات المكتبات وتجزئة التزام Git لشيفرة التدريب.
سلسلة البيانات (Data Lineage) — اسم مجموعة البيانات وإصدارها وتجزئتها لإثبات تدريب النموذج على لقطة محددة من مخزن الميزات.

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

MLflow: المعيار الفعلي

MLflow هو الحل مفتوح المصدر الأكثر انتشارًا في مجال التتبع، وتصميم واجهة برمجة تطبيقاته أثّر في كل بديل تجاري (Weights & Biases وNeptune وComet وVertex AI Experiments). فهم MLflow بعمق يعني أنك تستطيع التعامل مع أي منها. العناصر الأساسية هي:

خادم التتبع (Tracking Server) — يخزن البيانات الوصفية للتشغيلات والمقاييس في مخزن خلفي (SQLite محليًا، PostgreSQL أو MySQL في الإنتاج) والمخرجات في مخزن مخصص (S3 أو GCS أو Azure Blob أو وحدة NFS مثبتة).
التجارب (Experiments) — تجميعات منطقية للتشغيلات (واحدة لكل عائلة نماذج أو هدف عمل).
التشغيلات (Runs) — تنفيذ تدريب واحد بمعرف UUID فريد وطوابع زمنية للبدء والانتهاء وحالة.
سجل النماذج (Model Registry) — مدير دورة حياة يُرقّي مخرجات التشغيلات عبر مراحل مسمّاة: التجهيز، الإنتاج، الأرشفة.

# تثبيت MLflow وتشغيل خادم تتبع للإنتاج
pip install mlflow==2.13.0 psycopg2-binary boto3

# تشغيل خادم التتبع مدعومًا بـ PostgreSQL وS3
mlflow server \
  --backend-store-uri postgresql://mlflow:secret@postgres:5432/mlflow \
  --default-artifact-root s3://my-mlops-bucket/mlflow-artifacts \
  --host 0.0.0.0 \
  --port 5000 \
  --workers 4

# متغير البيئة لتوجيه شيفرة التدريب إلى الخادم
export MLFLOW_TRACKING_URI=http://mlflow.internal:5000

شغّل خادم التتبع خلف موازن أحمال داخلي — لا تعرّضه للعموم أبدًا. في Kubernetes، انشره كـ Deployment بنسختين على الأقل خلف خدمة ClusterIP مع NetworkPolicy مقيّدة. يجب أن يكون خادم Postgres على نفس الشبكة الافتراضية الخاصة مع بيانات اعتماد مخزّنة في سر مخصص.

قياس تشغيل التدريب

واجهة برمجة التطبيقات للعميل مصممة لتكون خفيفة. النمط المستخدم في قواعد شيفرة الإنتاج يفصل استدعاءات MLflow عن منطق التدريب الفعلي:

import mlflow
import mlflow.sklearn
from sklearn.ensemble import GradientBoostingClassifier
from sklearn.metrics import roc_auc_score

mlflow.set_tracking_uri("http://mlflow.internal:5000")
mlflow.set_experiment("fraud-detection-v2")

params = {
    "n_estimators": 400,
    "max_depth": 6,
    "learning_rate": 0.05,
    "subsample": 0.8,
}

with mlflow.start_run(run_name="gbm-baseline-2025-06-11") as run:
    # تسجيل المعاملات
    mlflow.log_params(params)

    # تسجيل إصدار البيانات لضمان إعادة الإنتاج
    mlflow.set_tag("dataset_version", "fraud-features-v3.2.1")
    mlflow.set_tag("git_sha", "a1b2c3d")

    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)

    # تسجيل النموذج مع توقيع صريح (مخطط الإدخال/الإخراج)
    signature = mlflow.models.infer_signature(X_train, model.predict(X_train))
    mlflow.sklearn.log_model(
        model,
        artifact_path="model",
        signature=signature,
        registered_model_name="fraud-detection",   # تسجيل تلقائي في السجل
    )

    print(f"Run ID: {run.info.run_id}  AUC: {auc:.4f}")

تقوم وسيطة registered_model_name بعملين في آنٍ واحد: تسجيل مخرج النموذج ضمن التشغيل، وإنشاء أو تحديث إدخال نموذج مُسجَّل في سجل النماذج بإصدار جديد يشير إلى نفس المخرج. يبدأ إصدار النموذج في مرحلة None.

سجّل دائمًا signature صريحًا وinput_example في log_model. يصبح التوقيع العقدَ الذي تتحقق منه طبقة الخدمة. المثال تستخدمه واجهة التشغيل المدمجة في MLflow وكذلك مهام CI الجانبية التي تتحقق من الانجراف في المخطط.

سجل النماذج: سير عمل الترقية

سجل النماذج هو المكان الذي تتحول فيه مخرجات التشغيل الخام إلى كيان خاضع للحوكمة وقابل للنشر. سلّم الترقية القياسية في فرق MLOps المؤسسية هو:

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

تُنفَّذ الترقية عبر عميل MLflow أو REST API، مما يجعلها قابلة للأتمتة من خط أنابيب CI:

from mlflow import MlflowClient

client = MlflowClient("http://mlflow.internal:5000")

# نقل الإصدار المُسجَّل حديثًا إلى Staging
client.transition_model_version_stage(
    name="fraud-detection",
    version="42",
    stage="Staging",
    archive_existing_versions=False,
)

# بعد اجتياز بوابة CI، ترقية إلى الإنتاج وأرشفة الإصدار القديم
client.transition_model_version_stage(
    name="fraud-detection",
    version="42",
    stage="Production",
    archive_existing_versions=True,
)

# إضافة تعليق موافقة قابل للتدقيق
client.update_model_version(
    name="fraud-detection",
    version="42",
    description="Approved by @alice 2025-06-11. AUC 0.9712 vs 0.9680 baseline. Shadow run clean.",
)

خطأ إنتاجي شائع: استخدام archive_existing_versions=True عند الترقية مريح لكنه خطر في الفرق سريعة الوتيرة — إذ يُؤرشف كل إصدار في تلك المرحلة، بما في ذلك الإصدارات التي تعمل في وضع canary أو shadow. في الفرق التي تستخدم خدمة متعددة المتغيرات، اضبطها على False وأدِر الأرشفة صراحةً عبر سكريبت إدارة الإصدار.

مقارنة التشغيلات وتطبيق بوابات الجودة

قيمة التتبع لا تتحقق إلا عندما تُحرّك قرارات آلية. مهمة CI نموذجية في خط أنابيب GitHub Actions أو Argo Workflows ستقوم بما يلي:

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

تحلّ هذه البوابة الآلية محل مراجعة "تبدو جيدة" غير الرسمية التي تتسبب في التراجعات في الإنتاج.

توسيع نطاق خادم التتبع

في المنظمات التي تُشغّل عشرات الآلاف من مهام التدريب يوميًا، يصبح خادم MLflow الفردي عنق زجاجة. أنماط الإنتاج الشائعة هي: التوسع الأفقي خلف موازن أحمال بدون جلسات لاصقة، نسخ القراءة لخادم Postgres لخدمة استعلامات واجهة المستخدم، ومسارات رفع المخرجات المستقلة التي تتجاوز خادم التتبع وتكتب مباشرة إلى S3 باستخدام عناوين URL موقّعة مسبقًا.

طبّق سياسة الاحتفاظ بالبيانات على التشغيلات. خادم Postgres الذي يتراكم فيه عدد خطوات المقاييس بلا حدود سينمو إلى مئات الغيغابايت في غضون أشهر. استخدم mlflow gc على جدول cron، وأرشف التشغيلات المكتملة التي تتجاوز 90 يومًا. وسّم التشغيلات بـ ttl=30d حتى تتمكن سكريبتات الاحتفاظ الآلية من تمييز تشغيلات التجارب العابرة عن مرشحي النماذج المُرقَّين.

البدائل: متى تختار شيئًا آخر

MLflow ليس الأداة المناسبة دائمًا. استخدم Weights & Biases عندما يعتمد الفريق بشكل كبير على التعلم العميق ويحتاج إلى تصورات منحنى الخسارة في الوقت الفعلي مع لوحات معلومات استخدام GPU. استخدم Vertex AI Experiments أو SageMaker Experiments عندما يكون كل بنية التدريب مُدارة من مزود السحابة. استخدم DVC عندما يكون الاهتمام الأساسي هو إصدار البيانات وخط الأنابيب بتكامل Git بدلاً من تتبع المقاييس. في الممارسة العملية، تجمع معظم المنصات الكبيرة بين MLflow للحوكمة وDVC لسلسلة البيانات.