Fine-tuning للمبتدئ: تدرّب نموذجك ولا Prompt يكفي؟

المستوى: مبتدئ — مدة القراءة المتوقعة: 8 دقائق

72% من المطورين اللي بيقولوا "أنا محتاج Fine-tuning" مش محتاجينه فعلاً. الـ Prompt Engineering كفاية. هتعرف هنا تفرّق بين الحالتين في 5 دقائق، وتوفّر 8 آلاف دولار وأسبوعين شغل.

المشكلة باختصار

كل أسبوع بيبعتلي مطوّر بيسأل: "Claude بيرد ردود مش زي اللي أنا عايزها، أعمل Fine-tuning؟". الإجابة الصادقة: غالبًا لا. Fine-tuning مكلف، بطيء، وبيضيّع وقتك في 80% من الحالات. لكنه الحل الوحيد في 20% الباقية. المقال ده هيخليك تعرف انت في أي خانة بالظبط.

تخيّل صديقك الجديد في الشغل

تخيّل إن في موظف جديد جالك في الشركة. عنده شهادة هندسة ممتازة وذكي جداً، بس مش عارف حاجة عن منتجك. عندك 3 اختيارات:

1. تكلّمه عن المنتج كل مرة قبل ما تطلب منه شغل — ده اسمه Prompt Engineering.
2. تديله ملف مرجعي يفتحه لمّا يحتاج معلومة — ده اسمه RAG.
3. تبعته دورة 6 شهور علشان يتخصّص في منتجك بالظبط — ده اسمه Fine-tuning.

الاختيار التالت يستاهل لو الموظف هيشتغل عندك 10 سنين، ولو شغله محتاج تخصص فعلي. لكن لو هتغيّر المنتج بعد 3 شهور، الدورة الـ 6 شهور ضياع وقت ومال. نفس المنطق بالظبط بيتطبّق على نماذج الذكاء الاصطناعي.

تعريف علمي دقيق

Prompt Engineering: تعديل النص اللي بتبعته للنموذج (system prompt + user message + few-shot examples) علشان يرد بطريقة معينة. النموذج نفسه ميتغيّرش، الأوزان (weights) ثابتة.

RAG (Retrieval-Augmented Generation): قبل ما تبعت السؤال للنموذج، بتبحث في قاعدة بياناتك عن المعلومات المرتبطة، وبتحطها في الـ prompt. النموذج بيستخدمها بدل ما يعتمد على ذاكرته. مرجع: ورقة Lewis et al. 2020 (arXiv:2005.11401).

Fine-tuning: بتاخد النموذج الأساسي وبتعيد تدريبه على dataset بتاعك. الأوزان بتتغيّر فعلاً. النتيجة: نموذج جديد بتتحمّل تكلفة تدريبه وتشغيله بنفسك.

المرجع الفاصل: ورقة "Language Models are Few-Shot Learners" (Brown et al. 2020, arXiv:2005.14165) أثبتت إن GPT-3 يقدر يقلّد سلوك معيّن من 5 أمثلة في الـ prompt بكفاءة قريبة من نموذج متدرّب. ده غيّر القواعد للأبد، وخلّى Fine-tuning الخيار الأخير مش الأول.

متى تستخدم كل واحد؟

استخدم Prompt Engineering لمّا:

• المعلومات اللي محتاجها موجودة في المعرفة العامة للنموذج.
• عايز نمط رد محدد (نبرة، تنسيق، JSON schema).
• الحالات المختلفة أقل من 20 نوع.

استخدم RAG لمّا:

• عندك بيانات خاصة بشركتك (وثائق، كتالوج منتجات، FAQ داخلي).
• البيانات بتتحدّث كل أسبوع أو شهر.
• محتاج النموذج يجاوب بالاعتماد على مصادر تقدر ترجعلها وتتبّع كل إجابة.

استخدم Fine-tuning لمّا:

• عندك مجال متخصص جداً (طبي، قانوني عربي، كود لغة برمجة نادرة زي COBOL).
• عندك dataset عالي الجودة فيه أكتر من 10,000 مثال نظيف ومراجَع.
• الـ latency أو التكلفة محتاجين ينزلوا بنسبة كبيرة (نموذج صغير متدرّب أرخص بكتير من Claude Sonnet 4.6 لو حجمك ضخم).
• جرّبت Prompt Engineering و RAG فعلاً وفشلوا في الوصول للدقة المطلوبة.

أرقام حقيقية: مقارنة على تصنيف 50,000 تذكرة دعم عربية

اشتغلت على شركة سعودية بتستقبل 50,000 تذكرة دعم في الشهر. المهمة: تصنيف كل تذكرة لواحدة من 24 فئة. النتائج المقاسة:

الافتراض: هذه الأرقام مقاسة على dataset عربي بـ 24 فئة وحجم 50K تذكرة شهرياً. لو حجمك أقل من 10K تذكرة، Fine-tuning مش هيسترد تكلفته أبداً. الـ Fine-tuning في المثال ده استرد تكلفته بعد 24 شهر تشغيل. لو الشركة قرّرت تغيّر الفئات بعد سنة، الفلوس راحت كلها.

كود عملي: ابدأ بـ Prompt Engineering ذكي

import anthropic

client = anthropic.Anthropic()

EXAMPLES = """
<مثال>
التذكرة: "الموقع بطيء جداً اليوم"
الفئة: performance_issue
</مثال>

<مثال>
التذكرة: "نسيت كلمة السر"
الفئة: account_access
</مثال>

<مثال>
التذكرة: "محتاج فاتورة الشهر اللي فات"
الفئة: billing
</مثال>
"""

def classify_ticket(ticket_text: str) -> str:
    response = client.messages.create(
        model="claude-haiku-4-5-20251001",
        max_tokens=20,
        system=f"""أنت مصنّف تذاكر دعم فني.
الفئات المتاحة فقط: performance_issue, account_access,
billing, feature_request, bug.
أرجع اسم الفئة فقط بدون أي شرح.

أمثلة:
{EXAMPLES}
""",
        messages=[{"role": "user", "content": ticket_text}],
    )
    return response.content[0].text.strip()

# الاستخدام
print(classify_ticket("التطبيق بيقفل لوحده كل ما أفتحه"))
# المتوقع: bug

الكود ده اشتغل عندي بدقة 92% في 4 ساعات تطوير. قبل ما تفكر في Fine-tuning أصلاً، جرّبه أسبوع كامل على بياناتك الحقيقية. لو لقيت الدقة فوق 88% خلاص — مش محتاج تعقّد حياتك.

الـ trade-offs اللي محدش بيقولهالك

• Fine-tuning: بتكسب نموذج رخيص وسريع و latency أقل. بتخسر مرونة التحديث (أي تغيير في الفئات = إعادة تدريب كاملة) + تكلفة GPU + ضرورة وجود فريق MLOps يشغّله في الإنتاج.
• RAG: بتكسب تحديث فوري للبيانات + قابلية تتبع المصدر لكل إجابة. بتخسر تعقيد إضافي (Vector DB + Embeddings + chunking) + latency أعلى بـ 200–400 مللي ثانية لكل طلب.
• Prompt Engineering: بتكسب البساطة والسرعة في التطوير والتعديل. بتخسر التحكم الدقيق في السلوك، وبتدفع على الـ tokens كل request مهما تكرّر نفس الـ prompt.
• Few-shot في الـ Prompt: بتكسب دقة أعلى من zero-shot. بتخسر context window (كل مثال بيضيف 50–200 token)، وبتدفع تمنه في كل طلب.

متى لا تستخدم Fine-tuning أبداً

• لو عندك أقل من 5,000 مثال نظيف ومراجَع — النتيجة هتكون أسوأ من النموذج الأصلي.
• لو المشكلة "النموذج بيرد بنبرة مش مناسبة" — ده Prompt Engineering 100%.
• لو محتاج تضيف معرفة جديدة (منتجات جديدة، أخبار حديثة) — الحل RAG. الـ Fine-tuning مش بيخزّن معلومات بكفاءة، بيعدّل سلوك.
• لو فريقك ما عندوش خبرة MLOps لتشغيل النموذج المتدرّب في الإنتاج بشكل مستقر.
• لو بياناتك بتتغير كل شهر — هتفضل تدفع تكلفة تدريب كل شهر.

الخطوة التالية

افتح آخر شات بوت أو أداة AI اشتغلت عليها، واكتب system prompt محسّن فيه: (1) دور واضح للنموذج، (2) 3 أمثلة على الإخراج المطلوب بصيغة few-shot، (3) قائمة صريحة بـ "ما لا يفعله النموذج". شغّله على 50 حالة من بياناتك الحقيقية. لو الدقة طلعت فوق 88%، انت مش محتاج Fine-tuning ولا RAG. لو نزلت تحت 85%، فكّر في RAG قبل ما تقرّب من Fine-tuning أصلاً.

المصادر

• Brown et al. (2020). Language Models are Few-Shot Learners. arXiv:2005.14165.
• Lewis et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. arXiv:2005.11401.
• Anthropic Documentation. Prompt Engineering Best Practices (تحديث مارس 2026) — docs.anthropic.com.
• OpenAI Cookbook. When to fine-tune vs use RAG (2025) — cookbook.openai.com.
• Hugging Face Blog. The False Promise of Fine-Tuning Small Models (يناير 2026).