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

مراقبة النماذج في الإنتاج

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

مراقبة النماذج في الإنتاج

أنت تدير بالفعل مجموعة أدوات مراقبة ناضجة: Prometheus يجمع مقاييس البنية التحتية، وLoki يُجمِّع السجلات، وTempo يتتبع الطلبات من البداية للنهاية، ولوحات تحكم SLO تُنبِّه الفريق عند ارتفاع معدلات الخطأ. هذه الأدوات ضرورية لكنها غير كافية لأنظمة تعلم الآلة. يمكن لنموذج مُنشَر أن يتدهور بصمت لأسابيع — يقدم تنبؤات خاطئة بثقة عالية — بينما جميع مقاييس البنية التحتية تبدو سليمة تماماً. CPU والذاكرة وزمن الاستجابة ومعدل الأخطاء تبدو طبيعية لأن النموذج يُجيب؛ إلا أن إجاباته غير صحيحة. هذا هو التحدي التشغيلي المحوري في تعلم الآلة الإنتاجي: النموذج هو الخطأ، ومراقبتك الحالية لا تستطيع اكتشافه.

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

انجراف البيانات: حين يتغير العالم

يتعلم النموذج دالةً من توزيع التدريب. فور بدء اختلاف المدخلات الواقعية عن ذلك التوزيع، يُطلب من النموذج الاستقراء خارج نطاق ما تعلمه — وسلوكه يصبح غير محدد. هذا هو انجراف البيانات، المعروف أيضاً بـالانزياح المتغاير: توزيع خصائص المدخلات P(X) يتغير دون تغيير مقابل في عملية توليد التسميات P(Y|X).

على نطاق الشركات الكبرى، يُكشَف عن انجراف البيانات بمقارنة الخصائص الإحصائية لنافذة مرجعية (عادةً مجموعة التدريب أو التحقق) بنافذة الاستدلال المباشر (الساعات القليلة أو الـ24 ساعة الأخيرة من حركة المرور). المقاييس الرئيسية التي يجب تتبعها لكل خاصية هي:

الخصائص المستمرة: مؤشر استقرار المجتمع (PSI)، اختبار كولموغوروف-سميرنوف، مسافة واسرشتاين، انزياح المتوسط والانحراف المعياري.
الخصائص الفئوية: اختبار كاي تربيع، تباعد جنسن-شانون على توزيع تكرارات الفئات، الكشف عن فئات جديدة لم تُرَ وقت التدريب.
متعدد المتغيرات: الحد الأقصى للتباعد المتوسط (MMD) أو كاشف انجراف مُتعلَّم — مصنِّف مُدرَّب للتمييز بين العينات المرجعية والمباشرة. إن نجح بدقة عالية، فالانجراف موجود.

الفكرة الأساسية — عتبات PSI المعيارية: PSI أقل من 0.1 انجراف لا يُذكر، 0.1–0.2 يستوجب التحقيق، وفوق 0.2 انجراف كبير يجب أن يُطلق سير عمل إعادة التدريب. نشأت هذه العتبات في تقييم الائتمان (حيث ابتُكر PSI) لكنها تُستخدم على نطاق واسع عبر مجالات تعلم الآلة. استخدمها نقطة انطلاق ثم اضبطها وفق حساسية نموذجك الملحوظة.

تُبنى الأدوات التشغيلية للكشف عن الانجراف حول مكتبات مفتوحة المصدر كـEvidently AI (تُنشئ تقارير انجراف بتنسيق HTML/JSON من DataFrames) وNannyML (يتضمن تقدير الأداء دون تسميات) ومنصات مُدارة مثل Arize AI وWhylogs وAWS SageMaker Model Monitor. في نشر Kubernetes، تُشغِّل عادةً CronJob منفصلة تقرأ سجلات الاستدلال من مخزن الخصائص أو موضوع Kafka، وتحسب إحصاءات الانجراف وتدفعها إلى Prometheus كمقاييس مخصصة تستهلكها لوحات Grafana.

# evidently_drift_job.py — تُشغَّل كـ CronJob في Kubernetes كل ساعة
# تقرأ سجلات الاستدلال للساعة الأخيرة، وتحسب الانجراف مقارنةً ببيانات مرجعية.

import pandas as pd
from evidently.report import Report
from evidently.metric_preset import DataDriftPreset
from evidently import ColumnMapping
import requests

# تحميل المرجع (لقطة التدريب) والحالي (نافذة الاستدلال للساعة الأخيرة)
reference = pd.read_parquet("s3://ml-features/reference/train_features_v3.parquet")
current   = pd.read_parquet("s3://ml-features/inference/2024-01-15T14.parquet")

column_mapping = ColumnMapping(
    target=None,                        # التسمية الحقيقية غير متاحة بعد
    prediction="predicted_score",
    numerical_features=["age", "credit_balance", "txn_count_7d"],
    categorical_features=["country_code", "device_type"],
)

report = Report(metrics=[DataDriftPreset(drift_share=0.3)])
report.run(reference_data=reference, current_data=current,
           column_mapping=column_mapping)

result = report.as_dict()
drift_detected = result["metrics"][0]["result"]["dataset_drift"]
share_drifted  = result["metrics"][0]["result"]["share_of_drifted_columns"]

# دفع مقياس مخصص إلى Prometheus Pushgateway
payload = (
    "# HELP ml_data_drift_share نسبة الخصائص التي اكتُشف فيها انجراف\n"
    "# TYPE ml_data_drift_share gauge\n"
    f"ml_data_drift_share{{model=\"fraud_v3\",env=\"prod\"}} {share_drifted}\n"
)
requests.post("http://pushgateway:9091/metrics/job/ml_drift_job", data=payload)

if drift_detected:
    # تشغيل DAG إعادة التدريب عبر Argo Workflows REST API
    requests.post(
        "http://argo-server:2746/api/v1/workflows/ml-platform",
        json={"resourceKind": "WorkflowTemplate",
              "resourceName": "fraud-retrain-v3",
              "submitOptions": {"labels": "trigger=drift"}},
        headers={"Authorization": "Bearer $ARGO_TOKEN"},
    )
    print(f"اكتُشف انجراف ({share_drifted:.1%} من الخصائص). تُشغَّل إعادة التدريب.")

انجراف التنبؤات: مراقبة مخرجات النموذج

انجراف التنبؤات (المعروف أيضاً بـالانجراف المفاهيمي حين يكون سببه تغيُّر P(Y|X)) يُكشَف بمتابعة توزيع درجات النموذج أو احتمالات الفئات عبر الزمن. هذا قيِّم بالتحديد لأنك لا تحتاج تسميات حقيقية للكشف عنه — تحتاج فقط مخرجات النموذج المتاحة فور خدمة أي استدلال.

الإشارات الشائعة للتتبع في لوحات Grafana:

انزياح توزيع الدرجات: يجب أن يكون مدرج الاحتمالات المتوقعة ثابتاً. الانزياح المفاجئ نحو درجات أعلى أو أدنى إنذار أحمر — نموذج احتيال يصنِّف 90% من المعاملات خطرة دليل شبه مؤكد على انجراف.
اختلال توازن الفئات في التنبؤات: تتبع نسبة الطلبات في كل فئة متوقعة. نموذج ثنائي كان يتنبأ بـ2% إيجابية في يناير لكنه يتنبأ بـ8% في مارس قد تغير سلوكه بصرف النظر عن تغير العالم.
معايرة الثقة: تتبع نسبة التنبؤات في كل فترة ثقة. توزيع ثقة النموذج المعاير جيداً يجب أن يكون ثابتاً مع الوقت.

الممارسة الإنتاجية: سجِّل كل استدلال — خصائص المدخلات وإصدار النموذج والتنبؤ ودرجة الثقة والطابع الزمني — في مخزن استدلال مخصص (جدول S3 مُجزَّأ أو BigQuery/Redshift). هذا هو الأساس لكل مراقبة لاحقة وأمر أساسي لتشخيص الحوادث الإنتاجية. المهندسون في منصة Meta لتعلم الآلة يسجلون 100% من استدعاءات الاستدلال للنماذج ذات المخاطر العالية؛ بعض الفرق تعمل بعينة 10% لنماذج الإنتاجية العالية للتحكم في تكاليف التخزين. لا تسجِّل أقل من 1% — أنت بحاجة إلى قوة إحصائية لاختبارات الانجراف.

مراقبة أداء النموذج: مشكلة الحقيقة الأرضية

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

الاستراتيجيات التشغيلية للتعامل معها هي:

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

بنية مراقبة النماذج الإنتاجية: سجلات الاستدلال تُغذِّي كلاً من كاشف الانجراف (لا تسميات مطلوبة) ومُقيِّم الأداء (يتطلب تسميات حقيقية مؤجلة)، مع توجيه التنبيهات إلى PagerDuty وإعادة التدريب الآلي.

حلقات التغذية الراجعة: حين تغيِّر المراقبة النموذج

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

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

التخفيفات التشغيلية — جميعها تتطلب هندسة متعمدة — تشمل:

التسجيل المضاد للواقع: سجِّل ما كان النموذج سيتنبأ به للخيارات التي لم يختَرها. يتطلب هذا بنية تحتية مخصصة لتسجيل المدخلات المضادة للواقع أثناء الخدمة.
سياسات الاستكشاف: أدخل نسبة صغيرة من القرارات العشوائية (epsilon-greedy أو Thompson sampling) لضمان استمرار رؤية النموذج لتسميات التوزيع الكامل للمدخلات. Netflix وSpotify كلتاهما تستخدم ميزانيات استكشاف في أنظمة التوصيات.
مراجعات مجموعة بيانات إعادة التدريب: قبل كل تشغيل لإعادة التدريب، أجرِ فحص تغطية: هل تحتوي مجموعة التدريب أمثلة كافية للمناطق منخفضة الثقة? طبِّق حداً أدنى للتغطية كبوابة لخط بيانات التدريب.

فخ إنتاجي — إجهاد التنبيهات من عتبات الانجراف الحساسة جداً: ضبط عتبات تنبيه PSI على مستويات منخفضة جداً سينتج إيجابيات كاذبة مستمرة، خاصةً للنماذج ذات أنماط حركة موسمية أو أسبوعية. قسِّم نوافذك المرجعية حسب اليوم أو ساعة اليوم، واستخدم عتبات تكيفية تراعي التباين الدوري المتوقع، قبل إيقاظ مهندس في الإناوبة. تنبيه انجراف يُطلَق كل صباح سبت ويُكتَم دائماً دون تحقيق أسوأ من لا تنبيه — فهو يُدرِّب المهندسين على تجاهل الإشارة.

إعداد المراقبة في Kubernetes

في منصة تعلم آلة مبنية على Kubernetes، تُنفَّذ مراقبة النماذج عادةً كمجموعة من موارد CronJob التي تكتب مقاييس إلى Prometheus عبر Pushgateway، بالإضافة إلى مكوِّن زمني فوري يقرأ من موضوع Kafka لأحداث الاستدلال:

# k8s/ml-monitoring/drift-cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: fraud-model-drift-check
  namespace: ml-monitoring
spec:
  schedule: "0 * * * *"          # كل ساعة
  concurrencyPolicy: Forbid       # تجاوز إن كانت التشغيلة السابقة لا تزال نشطة
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          serviceAccountName: ml-monitoring-sa
          containers:
          - name: drift-checker
            image: ml-platform/drift-checker:v2.1.4
            env:
            - name: MODEL_NAME
              value: "fraud_v3"
            - name: REFERENCE_PATH
              value: "s3://ml-features/reference/train_features_v3.parquet"
            - name: INFERENCE_BUCKET
              value: "s3://ml-features/inference"
            - name: PUSHGATEWAY_URL
              value: "http://prometheus-pushgateway.monitoring:9091"
            - name: PSI_ALERT_THRESHOLD
              value: "0.2"
            resources:
              requests:
                memory: "2Gi"
                cpu: "500m"
              limits:
                memory: "4Gi"
                cpu: "2"
---
# PrometheusRule للتنبيه على الانجراف — تتكامل مع Alertmanager الموجود
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: ml-drift-alerts
  namespace: ml-monitoring
spec:
  groups:
  - name: ml.drift
    rules:
    - alert: MLDataDriftHigh
      expr: ml_data_drift_share{env="prod"} > 0.2
      for: 10m
      labels:
        severity: warning
        team: ml-platform
      annotations:
        summary: "اكتُشف انجراف بيانات للنموذج {{ $labels.model }}"
    - alert: MLPredictionScoreShift
      expr: abs(ml_prediction_mean{env="prod"} - ml_prediction_mean_7d{env="prod"}) > 0.15
      for: 30m
      labels:
        severity: critical
        team: ml-platform

الممارسة الاحترافية — ربط مراقبة النماذج بإطار SLO: عرِّف SLOs صريحة لأداء النموذج إلى جانب SLOs موثوقيتك. على سبيل المثال: "يجب أن يبقى AUROC نموذج كشف الاحتيال فوق 0.91 على نافذة تقييم التسميات المتحركة لآخر 7 أيام، بميزانية خطأ شهرية 0.5%." حين تُستنفَد ميزانية SLO الأداء، تكون الاستجابة حادثة إعادة تدريب وترقية، تُدار بنفس طريقة إدارة حوادث الموثوقية — بقائد حادثة وجدول زمني وما بعد الحادثة. هذا التوافق التنظيمي بين SRE وهندسة تعلم الآلة أحد علامات ممارسة تشغيل تعلم الآلة الناضجة.

الصورة الكاملة: قائمة تدقيق المراقبة

قبل نشر أي نموذج في الإنتاج، تحقَّق من وجود عقود المراقبة التالية:

تسجيل الاستدلال — 100% من الطلبات مسجلة مع الخصائص والتنبؤ والثقة وإصدار النموذج والطابع الزمني.
وظيفة انجراف البيانات — حساب PSI/KS كل ساعة مقارنةً بالمرجع، مقياس مخصص يُدفع إلى Prometheus، تنبيه عند PSI أكبر من 0.2.
لوحة تحكم انجراف التنبؤات — مدرج التوزيع المتحرك وتوازن الفئات مُتتبَّع في Grafana.
خط بيانات التسميات — ربط آلي للتسميات الحقيقية المؤجلة بسجلات الاستدلال، حساب AUROC/F1/RMSE المتحرك ومتابعته مقابل SLO الأداء.
تدقيق حلقة التغذية الراجعة — تحليل موثق لما إذا كانت قرارات النموذج تؤثر على بيانات تدريبه، مع تخفيف صريح إن كانت تفعل.
مشغِّل إعادة التدريب — سير عمل إعادة التدريب الآلي (Argo أو SageMaker Pipelines) موصول بتنبيهات الانجراف وليس بجدول ثابت فحسب.
تقييم البطل والمنافس بالظل — كل إصدار نموذج جديد يعمل في وضع الظل على حركة المرور المباشرة لنافذة تقييم دنيا قبل الترقية.