بعد درس 101: Language Models & Next-Token Prediction ودرس 102: كيف تعمل LLMs، نلقي نظرة مفاهيمية على كيف يتدرّب نموذج لغوي كبير فعلًا — من corpus ضخم إلى نموذج "مفيد ومتوافق". هذا درس مفاهيمي، لا تدريب GPUs فعلي.
حدود هذه الصفحة: لا تتعلّم هنا كيف تدرّب نموذجًا من الصفر، ولا fine-tuning implementation. هذه مواضيع متقدّمة تُغطّى في موجات لاحقة. هنا نشرح ماذا يحدث ولماذا.
الصورة الكبيرة — مراحل التدريب
تدريب LLM الحديث ليس مرحلة واحدة. هو خط أنابيب متعدّد المراحل، كل مرحلة تخدم هدفًا مختلفًا:
1. Pre-training ← يتعلّم اللغة من corpus ضخم
2. Instruction Tuning ← يتعلّم اتّباع التعليمات
3. Preference / Alignment ← يتعلّم تفضيلات بشرية
4. Evaluation ← تقييم مستمر عبر المراحل
5. Inference ← الاستخدام الفعلي بعد التدريب
كل مزوّد/فريق يستخدم وصفة مختلفة قليلًا. هذه خريطة مفاهيمية عامة، لا عقد تقني موحّد.
1. Pre-training — التعلّم من corpus ضخم
الهدف: تعريض النموذج لكميات هائلة من النصّ ليتعلّم:
- بنية اللغة (قواعد، ترتيب، علامات ترقيم).
- المعرفة العامة (حقائق، مفاهيم، علاقات).
- أنماط الاستدلال البدائية.
البيانات: تريليونات الرموز من كتب، مقالات، صفحات ويب، كود، منتديات... مع فلترة وتنظيف لإزالة المحتوى منخفض الجودة أو الضار.
الهدف التقني: ذات الهدف البسيط في درس 101:
maximize P(token التالي | كل الرموز السابقة)
هذا يعطي النموذج أساسًا لغويًا ومعرفيًا، لكنه لا يجعل النموذج مساعدًا مفيدًا بعد. النموذج قبل التدريب يميل إلى الإكمال، لا إلى الإجابة عن أسئلة أو اتّباع تعليمات.
Prompt: "ما هي عاصمة فرنسا؟"
Pre-trained فقط يكمل: "...؟ العاصمة مدينة كبيرة تقع في قارّة أوروبا،
تشتهر ببرج إيفل الذي بُني عام 1889. السؤال..."
(يكمل، لا يجيب)
2. Instruction Tuning (Supervised Fine-Tuning)
الهدف: تعويد النموذج على اتّباع تعليمات محددة بصيغة prompt → response.
البيانات: أزواج (تعليمات بشرية مكتوبة، إجابات نموذجية). تُجمع بعدة طرق:
- كتّاب بشريون يكتبون prompts وإجابات نموذجية.
- استخدام نموذج قوي لتوليد إجابات، ثم مراجعة بشرية.
- بيانات من تطبيقات حقيقية (بإذن المستخدمين، مع إزالة PII).
الفرق عن pre-training:
Pre-training: "أكمل هذا النصّ بأيّ شكل"
Instruction tuning: "أجب عن هذا السؤال وفق هذه التعليمات"
النتيجة: النموذج يصبح أفضل في تحويل prompt إلى response مفيدة بدل مجرّد الإكمال.
3. Preference / Alignment — تعلّم التفضيلات
الهدف: ضبط النموذج ليتوافق مع تفضيلات بشرية (مساعدة، أمان، عدم ضرر، دقة...).
الفكرة العامة: بدلاً من إجابات "صحيحة/خاطئة" مطلقة، النموذج يتعلّم التفضيل بين إجابتين:
Q: "كيف أتعلّم البرمجة؟"
A1: "ابدأ بـ Python، ركّز على الأساسيات، مارس يوميًا، اقرأ كود الآخرين..."
A2: "انسَ الأمر، صعب."
التفضيل البشري: A1 أفضل.
النموذج يتعلّم زيادة احتمال A1 وتقليل احتمال A2 (نسبيًا).
تقنيات شائعة (مثال، لا حصري):
- RLHF (Reinforcement Learning from Human Feedback): نموذج مكافأة (reward model) يُدرَّب على تفضيلات بشرية، ثم يُستخدم لتدريب النموذج اللغوي بإشارة مكافأة.
- DPO (Direct Preference Optimization): تبسيط يلغي نموذج المكافأة المنفصل ويعمل مباشرة من التفضيلات.
- تقنيات أخرى (Constitutional AI، ORPO، KTO...): كل مزوّد/فريق يستخدم توليفته.
ملاحظة مهمة: وصفات ما بعد التدريب تختلف بين النماذج والمزودين. لا توجد "طريقة موحّدة". ما يهمّ فهمه هو المبدأ العام: النموذج يُعدَّل ليتوافق مع تفضيلات بشرية باستخدام إشارات تفضيل.
4. Evaluation — تقييم مستمر
التقييم ليس مرحلة "بعد التدريب"، بل يحدث طوال خط الأنابيب:
Pre-training → perplexity على held-out corpus
Instruction tuning → دقة على معايير قياسية (MMLU، HumanEval...)
Alignment → معايير أمان، تقييم بششري، red teaming
Inference (production) → مراقبة الجودة، drift detection
معايير التقييم نفسها متحيّزة وغير مكتملة:
- لا معيار واحد يعكس كل ما يهمّ.
- النماذج قد "تُحسَّن" لمعايير معيّنة (benchmark gaming).
- التقييم البشري ما زال المعيار الذهبي في مهام كثيرة، لكنه بطيء ومكلّف.
5. Inference — الاستخدام الفعلي
بعد كل المراحل السابقة، النموذج جاهز للاستخدام. في الموجة الحالية (2026)، معظم التفاعل مع LLMs يتم عبر API (درس 108: استخدام LLM API من Python)، لا بتنزيل النموذج محليًا.
نموذج مدرَّب + stack inference (API أو hosting ذاتي)
↓
تطبيقات ومستخدمون
التمييزات المهمة
Pre-training ≠ Fine-tuning
Pre-training: تدريب من الصفر على بيانات ضخمة. تكلفة عالية جدًا.
عادةً فقط للشركات الكبرى.
Fine-tuning: تكملة تدريب نموذج مدرَّب على بيانات مهمتك.
تكلفة أقل بكثير، تناسب المؤسسات والمطورين.
الـ Fine-tuning Implementation يغطّى في موجات لاحقة. هنا نكتفي بتمييز المفهوم.
Alignment ≠ Safety بالكامل
Alignment: النموذج يفضّل إجابات تتوافق مع تفضيلات معيّنة.
لكن لا يضمن سلوكًا آمنًا في كل المواقف.
Safety: ممارسات أوسع تشمل:
- guardrails في التطبيق
- تصفية مدخلات/مخرجات
- إشراف بشري
- red teaming
التطبيقات الجادة لا تعتمد على alignment وحده — تضيف طبقات حماية إضافية.
لماذا تتغيّر الوصفات؟
لا توجد وصفة واحدة. الأسباب:
- التجريب: المجال يتطوّر بسرعة. ما نجح العام الماضي قد يُحسَّن هذا العام.
- البيانات المتاحة: مزوّدون مختلفون لديهم بيانات تدريب مختلفة.
- الأهداف: مزوّد يريد نموذج "محادثة"، آخر يريد نموذج "كود"، ثالث "استدلال".
- التنظيم: قوانين مختلفة في مناطق مختلفة تؤثّر على ما يُدرَّب ضدّه.
- التكلفة: بعض التقنيات (مثل RLHF التقليدي) أغلى من غيرها.
النصيحة العملية: لا تفترض أن "جميع النماذج الحديثة تدرّب بالطريقة X". اقرأ بطاقة النموذج (model card) المنشورة من المزوّد.
ما الذي لا يُغطّى هنا
عمدًا لا يغطّى هذا الدرس:
- كيف تدرّب نموذجًا من الصفر: تكاليف بملايين الدولارات، خارج نطاق معظم المطورين.
- Fine-tuning implementation: درس مستقل قادم.
- Distributed training: تقنية متقدّمة جدًا.
- Data curation details: يتعلّق أكثر بخطوط أنابيب بيانات الشركات.
- Specific RLHF math: رياضيات معقّدة، مفهومها العام يكفي لـ Wave 6.
أخطاء شائعة
- "النموذج المدرَّب مسبقًا جاهز للاستخدام مباشرة": ليس للاستخدام الإنتاجي مباشرة. يحتاج instruction tuning + alignment، وإلا سلوكه غير متوقّع.
- "RLHF هي الطريقة الوحيدة لـ alignment": لا. DPO وغيرها طرق شائعة. والمجال يتطوّر.
- "Alignment يجعل النموذج آمنًا 100%": لا. Alignment يوجّه السلوك ضمن تفضيلات معيّنة، لكن لا يلغي الحاجة لطبقات حماية إضافية في التطبيق.
- "Fine-tuning يحلّ كل مشاكل الجودة": Fine-tuning مفيد لكن ليس بديلًا عن prompt هندسي جيد أو بيانات تعلّم جيّدة.
الخطوات التالية
- Context Windows و Tokens — كيف يُدار السياق في التطبيقات.
- استخدام LLM API من Python — كيف تتفاعل مع نموذج مدرَّب برمجيًا.
ملاحظة النطاق: تدريب نموذج من الصفر، Fine-tuning implementation، و MLOps تُغطّى في الموجات التالية. هذا الدرس حدّه المفاهيمي.