الوحدة 10 — إعادة التدريب الآلي والتراجع

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

المُطلقات: متى نُعيد التدريب

ثلاثة أنواع من المُطلقات (triggers) شائعة في الممارسة:

• الجدول الزمني (schedule): نعيد التدريب كلّ أسبوع أو كلّ شهر، بغضّ النظر عن أيّ إشارة. بسيط، متوقّع، ولا يتفاعل مع الواقع.
• الأداء (performance-based): نعيد التدريب عندما ينخفض مقياس المراقبة تحت عتبة (AUC < 0,80، مثلًا). أذكى، لكنّه يفترض توفّر الحقيقة الأرضية سريعًا.
• الانحراف (drift-based): نعيد التدريب عندما تكشف اختبارات الوحدة السابقة انحرافًا مؤكّدًا في البيانات. مؤشّر مبكّر، لكن قد يُطلق إعادة تدريب لسبب لن ينفعه (انحراف صغير في متغيّر ضعيف الأهمّية).

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

المصادقة قبل الترقية: لا تكرار الخطأ

كلّ ما رأيناه في الوحدة 5 عن الترقية العمياء يعود هنا مضاعفًا. إعادة التدريب الآليّة تعني أنّ نموذجًا جديدًا يُنتَج تلقائيًّا؛ إن رقّينا آليًّا كلّ نموذج جديد إلى الإنتاج، فإنّنا نُعرّض المستخدمين لأيّ حادث في البيانات.

المسار الصحيح لإعادة تدريب آليّة:

1. إعادة التدريب تُنتج نموذجًا جديدًا، يُسجَّل باسم بديل @candidate.
2. اختبارات آلية: نفس عتبات الوحدة 7 (AUC ≥ العتبة، الأداء على الشرائح، زمن الاستدلال).
3. مقارنة مع المُنتَج الحاليّ: هل الجديد أفضل من @production على نفس مجموعة الاختبار الحديثة؟ إن كان الأداء متساويًا أو أسوأ، لا نُرقّي.
4. مصادقة إنسانية: حتّى مع كلّ الاختبارات الآلية، شخص واحد على الأقلّ يجب أن يقرأ التقرير ويضغط زرًّا. هذا يمنع «إن كان AUC = 0,87، رقّ» أن يُرقّي نموذجًا حصل على 0,87 عبر ثغرة في البيانات.

النشر التدرّجي: كناري وأزرق/أخضر

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

كناري (canary): نُوجّه 5 بالمائة من طلبات الإنتاج إلى النموذج الجديد، و95 بالمائة إلى القديم. نُراقب لمدّة يوم أو أسبوع. إن كانت المقاييس صحيحة، نرفع النسبة إلى 25 بالمائة، ثمّ 50، ثمّ 100. إن انهارت مقاييس المجموعة الكناريّة، نرجع تلقائيًّا إلى القديم على كلّ الحركة.

أزرق/أخضر (blue/green): نُنشر النسختين بالتوازي على البنية التحتيّة. الطلبات تذهب إلى «الأزرق» (النسخة الحاليّة). عند التبديل، نُوجّه فجأةً إلى «الأخضر» (النسخة الجديدة). التراجع بتبديل عكسيّ سريع. أبسط من كناري لكنّه لا يوفّر التدرّج.

الظلّ (shadow): النموذج الجديد يستقبل نسخة من الطلبات دون أن تُسلَّم توقّعاته للمستخدم؛ فقط تُقارَن بتوقّعات الحاليّ. مفيد جدًّا لتقييم نموذج جديد على الحمل الفعليّ دون أيّ مخاطرة.

التراجع في أمر واحد

كلّ إستراتيجية نشر يجب أن تدعم تراجعًا سريعًا. مع الأسماء البديلة في MLflow، رأينا سابقًا:

mlflow-cli alias --model churn-classifier --alias production --version 11

مع بنية أزرق/أخضر:

kubectl rollout undo deployment/churn-api

الاختبار الحقيقيّ: مهندس مناوب في الساعة الثالثة صباحًا، بدون قراءة الويكي، يستطيع إرجاع النموذج السابق في أقلّ من دقيقتين. إن لم يكن كذلك، الترتيب فاشل بغضّ النظر عن جودته النظرية.

نُوثّق أمر التراجع في «قصّة الحوادث» (runbook): صفحة قصيرة، أوامر جاهزة، لا شرح فلسفي. أفضل runbook هو الذي يُقرأ في 30 ثانية ويُنفَّذ في 90.

التكلفة: ما لا يُقال كثيرًا

إعادة تدريب أسبوعية لنموذج على 10 غيغابايت من البيانات على GPU تُكلّف مالًا حقيقيًّا. حساب ذلك مبكّرًا يمنع مفاجآت الفواتير:

• تكلفة الحوسبة لكلّ إعادة تدريب (نوع الآلة × الوقت)
• تكلفة تخزين إصدارات النماذج والبيانات المتراكمة
• تكلفة المراقبة (Prometheus، رسائل التنبيه، تقارير Evidently)
• تكلفة الاستدلال (خدمة تعمل باستمرار مقابل دفعات ليلية)

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

الحوكمة: من يُقرّر ماذا

إعادة تدريب آليّة تُنشئ سؤالًا جديدًا: من يملك السلطة على قرار الترقية؟ الأدوار الشائعة:

• عالِمة البيانات: تُصمّم النموذج والاختبارات، تُوقّع على شهادة القبول.
• مهندس MLOps: يُدير الخطّ، الحاويات، السجلّ.
• مالك المنتج: يُقرّر إذا كان النموذج الجديد صالحًا لهدف الأعمال.
• فريق الامتثال: يتحقّق من الأثر على الأقلّيات، والالتزام بالتنظيم (GDPR، AI Act الأوروبيّ في 2026).

مصفوفة صلاحيات صريحة (RACI) على قرار الترقية تمنع فجوات صامتة. النموذج الذي رقّي «لأنّ الاختبار أخضر» دون أن يُدرك أحد أنّه غيّر معنى مقياس تجاريّ هو مصدر كوارث حقيقيّة.

الحلقة تُغلَق، والدرس يعود إلى الوحدة 1

انتهت الدورة بحلقة كاملة: دفتر Jupyter بدأنا معه في الوحدة 1 أصبح الآن نظامًا يعرف كيف يعيد إنتاج نفسه، ويُتتبَّع، ويُنشر، ويُراقَب، ويُعيد تدريب نفسه. الدرس المركزيّ: MLOps ليست أدوات، بل ممارسات. كلّ أداة اخترناها (MLflow، DVC، Docker، GitHub Actions، Evidently) قابلة للاستبدال. الممارسات (البذور، التتبّع، السجلّ، المصادقة، المراقبة، التراجع) هي الثابتة.

في الخلاصة

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