الوحدة 9 — مراقبة جودة المتغيّرات

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

ماذا يمكن أن يخطأ في متغيّر

قائمة ما نراه فعلًا في الإنتاج:

• قيم ناقصة تنفجر: عمود كان دائمًا مليئًا يعود بـNULL في 30% من الحالات — علامة على تعطّل مصدر أعلى.
• حداثة تتدهور: النضارة كانت 5 دقائق، أصبحت ساعة. مهمّة التجسيد تفشل بصمت.
• توزيع ينحرف: توزيع avg_amount_7d يتحرّك يمينًا لأنّ عملة جديدة أُضيفت وسعر الصرف لم يُطبَّق.
• قيم شاذّة تظهر: عدّاد كان بحدّ أقصى 200 يُصبح 60000 — عيد يُغيّر السلوك، أو خطأ في المصدر.
• مخطّط يتغيّر: عمود يتغيّر نوعه من Int64 إلى String بعد ترقية مسار المصدر.

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

القياسات الأساسيّة الأربعة

للاختصار: أربعة قياسات تكشف 90% من المشاكل.

1. معدّل القيم الناقصة. نسبة الصفوف حيث المتغيّر NULL، محسوبة على نافذة منزلقة (آخر ساعة، آخر يوم). عتبة نموذجيّة: تنبيه إذا زاد المعدّل بأكثر من نقطتين فوق الأساس التاريخيّ.

2. الحداثة الفعليّة. عمر آخر تجسيد لكلّ وصفة، مقارنًا بالنضارة المُتفَق عليها في SLA. تنبيه إذا تجاوز العمر ضعف النضارة الموعودة.

3. الإحصائيّات الوصفيّة. متوسّط، وسيط، انحراف معياريّ، الحدّ الأدنى والأقصى. تُحسَب يوميًّا وتُقارَن بنافذة مرجعيّة (آخر 30 يومًا). تنبيه إذا تحرّك المتوسّط بأكثر من ثلاثة انحرافات معياريّة.

4. مؤشّر استقرار التوزيع (PSI). مقياس مُخصَّص لمقارنة توزيعَين. يُقسّم المتغيّر إلى شرائح، ويحسب فارق النسبة في كلّ شريحة. PSI أقلّ من 0,1 مستقرّ، وبين 0,1 و0,25 يستحقّ التحقيق، وأكثر من 0,25 انحراف حقيقيّ يستوجب فحصًا.

أين تُحسَب هذه القياسات

هذا سؤال معماريّ. ثلاثة خيارات، بمزايا مختلفة:

• جانب المخزن غير المتّصل: مهمّة يوميّة بـSpark على Parquet. سهلة، رخيصة، لكن مع تأخّر يوم.
• جانب المخزن المتّصل: قراءة عيّنة دوريّة من Redis وحساب على السريان. حديث، لكنّه لا يرى الأحداث النادرة.
• جانب مُخدَم الاستدلال: تسجيل المتغيّرات المُخدَّمة مع كلّ تنبّؤ في مسار سجلّ. الأدقّ لأنّه يعكس ما يراه النموذج حرفيًّا، لكن يُضيف كلفة.

في الإنتاج الجادّ، الاثنان معًا: مهمّة يوميّة للتوزيع الكامل، وتسجيل مستمرّ للنمذجة الفعليّة عند الطلب.

ربط المراقبة بالنموذج

المراقبة على المتغيّرات وحدها لا تكفي. يجب ربطها بأداء النموذج لتفسير: أيّ متغيّر انحرف؟ هل هذا الانحراف يُفسّر تدهور AUC؟

قاعدة عمليّة:

• إذا تدهور AUC وانحرفت المتغيّرات، السبب في مقدّم المسار: بيانات المصدر، أو مهمّة التجسيد، أو ترميز في مُخدَم الاستدلال.
• إذا تدهور AUC ولم تنحرف المتغيّرات، السبب في المفهوم: العلاقة بين المتغيّرات والهدف تغيّرت — تدخل خارجيّ، منافس جديد، تغيير قانونيّ. إعادة التدريب هي الحلّ.
• إذا انحرفت المتغيّرات ولم يتدهور AUC، النموذج متين أمام هذا الانحراف. تنبيه إعلاميّ لا حادثة.

هذه الشجرة الصغيرة تقصّر تشخيص الحوادث من ساعات إلى دقائق.

بناء تنبيه لا يُقرأ ثمّ يُتَجاهل

تنبيه سيّئ يعمل لأسبوع ثمّ يُصمَت لأنّ الفريق مَلَّ. تنبيه جيّد يحترم أربع قواعد:

1. قابل للتنفيذ: يقول ماذا نفعل («تحقّق من مهمّة Airflow materialize_customer_counters»).
2. نادر: لا يُطلَق أكثر من مرّة في اليوم. إذا كان أكثر، فالعتبة خاطئة أو المشكلة قائمة تحتاج إصلاحًا لا تنبيهًا متكرّرًا.
3. يُرسَل إلى المالك: من التاجز owner في الوصفة، لا إلى كلّ الفريق.
4. يحتوي رابط لوحة القيادة: القيمة المُقاسة، والمرجع، والرسم البيانيّ للنافذة الزمنيّة.

في Prometheus + Alertmanager، القاعدة تُصاغ:

alert: FeatureFreshnessBreached
expr: feature_freshness_seconds{view="customer_counters"} > 900
for: 10m
labels:
  severity: warning
  owner: fraud-team
annotations:
  summary: "Freshness > 15 min pour customer_counters"
  runbook: "https://internal-docs/runbooks/feast-materialization"

دورة إصلاح: من التنبيه إلى الحلّ

عند تلقّي تنبيه، دورة ثلاث خطوات:

1. احتوِ: هل نُوقف النموذج مؤقّتًا؟ إن كان الأثر التجاريّ عاليًا (حجب عملاء شرعيّين بالخطأ)، نعم. غالبًا لا.
2. شخّص: باستعمال قياسات الوحدة 5 (سلامة النقطة الزمنيّة)، تأكّد أنّ ما يراه النموذج فعلًا مطابق لما نظنّه.
3. أصلح ووثّق: تعديل الشفرة، عودة التنبيه إلى الصمت، سجلّ مكتوب لسبب الحادثة. هذه السجلّات هي ما يمنع تكرار المشكلة نفسها بعد أشهر.

المراقبة ليست بديلًا عن اختبار العقد

مراقبة تكشف انحرافًا بعد وقوعه؛ اختبار العقد (تحقّق Field من النوع، ومن الحدود، ومن التنسيق عند الكتابة إلى المخزن) يمنع الكتابة أصلًا. الاثنان لازمان: العقد للأخطاء المُبرمَجة، والمراقبة لما لا نتوقّعه.

الخلاصة

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

الوحدة التالية: مشروع كامل نطبّق فيه كلّ ما سبق على قاعدة بيانات معاملات فعليّة.