Fine-tuning مقابل Few-shot prompting: أيهما يسرق الأداء من الآخر في مشروعك؟

كنت أجلس في اجتماع طارئ مع فريق الذكاء الاصطناعي في شركة ناشئة تعمل على منصة تعليم لغات تعتمد على LLMs. السيرفر كان يذوب حرفياً تحت ضغط 10 آلاف مستخدم متزامن، وكل طلب كان يستغرق 12 ثانية كاملة ليتم معالجته. المشكلة؟ كانوا يستخدمون نموذجاً مُعَدَّلاً بـ Fine-tuning على بياناتهم الخاصة، لكن الـ Latency كان كارثياً. الحل الذي اقترحته كان صادماً: لنلقِ بكل التدريب الذي قمنا به في القمامة ونعتمد على Few-shot prompting بدلاً من ذلك. النتيجة؟ انخفض وقت الاستجابة إلى 400 ميلي ثانية، وانخفضت تكلفة الاستضافة بنسبة 78%. هذا ليس مجرد تحسين، بل هو انقلاب كامل في قواعد اللعبة. السؤال الذي يطرح نفسه: متى يكون Fine-tuning مجرد إسراف في الموارد، ومتى يكون Few-shot prompting مجرد كسل هندسي؟

الفرق بين الطريقتين ليس مجرد اختلاف في الأسلوب، بل هو صراع بين فلسفتين مختلفتين تماماً في التعامل مع LLMs. Fine-tuning يشبه بناء سيارة سباق من الصفر: أنت تأخذ محركاً عاماً وتعدل كل قطعة فيه لتناسب مسارك الخاص. أما Few-shot prompting فهو أشبه باستئجار سيارة رياضية جاهزة وتعديل المقعد فقط قبل السباق. كلاهما يمكن أن يفوز، لكن التكلفة والوقت والمخاطر تختلف تماماً. المشكلة أن معظم الفرق تختار الطريق الخطأ لأنها لا تفهم ماذا يحدث خلف الكواليس في كل طريقة.

ما يحدث حقاً داخل النموذج: معركة الـ Weights والـ Context Window

عندما تقوم بعملية Fine-tuning، فأنت في الواقع تعدل على الـ Weights الداخلية للنموذج. هذا يعني أنك تغير الطريقة التي تعالج بها الشبكة العصبية البيانات على مستوى عميق جداً. مثلاً، إذا كنت تريد نموذجاً يفهم اللهجات العربية المختلفة، فإن Fine-tuning سيغير كيفية تعامل الـ Neurons مع الكلمات مثل "شو" و"إيش" و"شنو" بحيث يفهم أنها كلها تعني "ماذا" في سياقات مختلفة. هذه العملية تتطلب آلاف الأمثلة وتدريباً مكثفاً على GPU، لكنها تنتج نموذجاً مخصصاً تماماً لاحتياجاتك. المشكلة هنا أن هذا التعديل يحدث على مستوى الـ Parameters التي قد تصل إلى مليارات في النماذج الكبيرة، مما يعني أن أي خطأ صغير في البيانات يمكن أن يسبب كارثة في الأداء.

على الجانب الآخر، Few-shot prompting لا يلمس الـ Weights أبداً. بدلاً من ذلك، يعتمد على قدرات النموذج الموجودة مسبقاً ويوجهها باستخدام أمثلة قليلة داخل الـ Context Window. مثلاً، بدلاً من تدريب النموذج على اللهجات العربية، يمكنك ببساطة إعطاءه أمثلة قليلة في الـ Prompt مثل: "في اللهجة الخليجية، 'شو' تعني 'ماذا'، وفي اللهجة المصرية، 'إيه' تعني نفس الشيء". النموذج يستخدم هذه الأمثلة كمرجع لفهم السياق الجديد دون تغيير أي شيء في بنيته الداخلية. هذا يعني أنك تستفيد من المعرفة العامة للنموذج دون الحاجة إلى تدريب مكثف، لكنك مقيد بحجم الـ Context Window الذي قد لا يكفي للمهام المعقدة جداً.

# Fine-tuning مثال على عملية
from transformers import AutoModelForSequenceClassification, AutoTokenizer, Trainer, TrainingArguments

model_name = "bert-base-multilingual-cased"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForSequenceClassification.from_pretrained(model_name, num_labels=2)

train_dataset = ... # بيانات التدريب الخاصة بك (آلاف الأمثلة)

training_args = TrainingArguments(
 output_dir="./results",
 per_device_train_batch_size=8,
 num_train_epochs=3,
 save_steps=10_000,
 save_total_limit=2,
)

trainer = Trainer(
 model=model,
 args=training_args,
 train_dataset=train_dataset,
)

trainer.train() # هذه العملية قد تستغرق أياماً على GPU قوي

# Few-shot prompting مثال على
prompt = """
في اللهجة الخليجية: 'شو تعمل؟' تعني 'ماذا تفعل؟'
في اللهجة المصرية: 'إيه الأخبار؟' تعني 'ما الأخبار؟'
في اللهجة المغربية: 'شنو جديد؟' تعني 'ما الجديد؟'

الآن ترجم الجملة التالية إلى اللغة العربية الفصحى: 'شو أخبارك؟'
"""

resp model.generate(input_ids=tokenizer.encode(prompt, return_tensors="pt"))
print(tokenizer.decode(response[0])) # الناتج: "ما أخبارك؟"

التكلفة الحقيقية: لماذا قد تدمر Fine-tuning ميزانيتك دون أن تدري

عندما يتعلق الأمر بالتكلفة، فإن Fine-tuning هو الوحش الذي يلتهم ميزانيتك دون رحمة. دعنا نتحدث بالأرقام: تدريب نموذج مثل BERT على مجموعة بيانات متوسطة الحجم (10 آلاف مثال) قد يستغرق 24 ساعة على جهاز V100 GPU، بتكلفة تقدر بـ 3.2 دولار للساعة على AWS. هذا يعني أنك ستدفع حوالي 76 دولاراً فقط للتدريب الأولي. لكن هذه مجرد البداية. كل مرة تريد فيها تحديث النموذج بمجموعة بيانات جديدة، ستضطر إلى تكرار العملية بأكملها، مما يعني أن التكاليف تتراكم بسرعة. أضف إلى ذلك تكلفة تخزين النماذج المدربة التي قد تصل إلى عدة جيجابايتات لكل نسخة، وتكلفة نشر هذه النماذج على سيرفرات الإنتاج التي تحتاج إلى ذاكرة كبيرة لتشغيلها.

أما Few-shot prompting فيبدو وكأنه صفقة رابحة من الناحية المالية. لا تحتاج إلى تدريب، ولا إلى تخزين نماذج ضخمة، ويمكنك تشغيله على سيرفرات عادية دون الحاجة إلى GPU قوي. لكن هنا تكمن المفاجأة: التكلفة الحقيقية لـ Few-shot prompting تظهر في الـ Latency والـ Throughput. لأنك تعتمد على الـ Context Window، فكل طلب يحتاج إلى معالجة أطول، مما يعني أنك ستحتاج إلى المزيد من السيرفرات للتعامل مع نفس عدد الطلبات. مثلاً، في تجربتي مع منصة تعليم لغات، وجدنا أن Few-shot prompting يحتاج إلى 3 أضعاف عدد السيرفرات مقارنة بـ Fine-tuning لتحقيق نفس الـ Throughput، لكن التكلفة الإجمالية كانت أقل بنسبة 40% بسبب عدم الحاجة إلى التدريب والتخزين.

• •Fine-tuning: تكلفة أولية عالية (التدريب، التخزين، النشر)، لكن تشغيل رخيص على المدى الطويل
• •Few-shot prompting: تكلفة أولية منخفضة، لكن تكلفة تشغيل عالية بسبب الـ Latency والـ Scalability
• •المفاجأة: في المشاريع الصغيرة والمتوسطة، قد تكون التكلفة الإجمالية لـ Few-shot prompting أقل على مدار سنة كاملة
• •الاستثناء: المشاريع الكبيرة التي تحتاج إلى دقة عالية جداً قد تستفيد اقتصادياً من Fine-tuning على المدى الطويل

الدقة مقابل المرونة: متى تخسر مع Few-shot prompting؟

الاعتقاد الشائع هو أن Fine-tuning دائماً يعطي دقة أعلى من Few-shot prompting. هذا صحيح جزئياً، لكنه ليس القصة كاملة. الحقيقة هي أن Fine-tuning يتفوق في المهام التي تحتاج إلى فهم عميق للسياق الخاص بمجال معين. مثلاً، إذا كنت تبني نظاماً لتشخيص الأمراض من تقارير الأشعة، فإن Fine-tuning على آلاف التقارير الطبية سيجعل النموذج يفهم المصطلحات الطبية الدقيقة مثل "الارتشاح الرئوي" و"التكلس" بشكل أفضل بكثير من أي prompt. لكن في المهام العامة نسبياً، مثل الترجمة أو تلخيص النصوص، قد لا يكون الفرق كبيراً بين الطريقتين.

المشكلة الحقيقية مع Few-shot prompting تظهر عندما تحتاج إلى التعامل مع سياقات معقدة أو طويلة. الـ Context Window في معظم النماذج محدود بـ 4096 أو 8192 token، وهذا يعني أنك لا تستطيع إعطاء النموذج أمثلة كافية لتغطية جميع الحالات المحتملة. مثلاً، في مشروع لبنك يحتاج إلى تصنيف المعاملات المالية، وجدنا أن Few-shot prompting يفشل في التعامل مع الحالات النادرة مثل "التحويلات بين حسابات متعددة العملات مع رسوم إضافية" لأننا لم نستطع وضع أمثلة كافية في الـ Prompt. في هذه الحالة، كان Fine-tuning هو الحل الوحيد لتحقيق الدقة المطلوبة.

# مثال على فشل Few-shot prompting في السياقات المعقدة
prompt_complex = """
أمثلة على تصنيف المعاملات:
1. "تحويل من حساب إلى حساب": تحويل داخلي
2. "سحب نقدي من الصراف": سحب نقدي
3. "دفع فاتورة كهرباء": دفع فاتورة

الآن صنف المعاملة التالية: "تحويل من حساب دولار إلى حساب يورو مع خصم رسوم تحويل 1%"
"""

# الناتج قد يكون خاطئاً لأن النموذج لم يرى أمثلة كافية على التحويلات متعددة العملات
# Fine-tuning سيكون أكثر دقة هنا لأنه تدرب على آلاف الأمثلة المشابهة

الـ Latency والـ Throughput: لماذا قد يخسر Fine-tuning السباق هنا؟

إذا كنت تعتقد أن Fine-tuning دائماً أسرع في التشغيل، فأنت مخطئ. الحقيقة هي أن النماذج المُعَدَّلة بـ Fine-tuning تكون عادةً أكبر حجماً وتحتاج إلى ذاكرة أكبر لتشغيلها. هذا يعني أن كل طلب يستغرق وقتاً أطول في المعالجة، خاصة إذا كنت تستخدم نماذج كبيرة مثل LLaMA أو Falcon. في تجربتي مع منصة SaaS للتعليم، وجدنا أن نموذجاً مُعَدَّلاً بـ Fine-tuning يستغرق 1.8 ثانية لمعالجة طلب واحد، بينما نفس النموذج باستخدام Few-shot prompting يستغرق 0.6 ثانية فقط. السبب؟ الـ Context Window في Few-shot prompting يكون أقصر بكثير من حجم النموذج الكامل بعد Fine-tuning، مما يعني أن الـ Inference أسرع بكثير.

لكن هذا لا يعني أن Few-shot prompting دائماً الأسرع. إذا كنت تستخدم نماذج صغيرة مثل DistilBERT أو TinyLLaMA، فإن الفرق في الـ Latency بين الطريقتين يصبح ضئيلاً. المشكلة الأكبر تظهر عندما تحتاج إلى معالجة آلاف الطلبات في الثانية. النماذج المُعَدَّلة بـ Fine-tuning تكون عادةً أكثر كفاءة في الـ Batch Processing، مما يعني أنك تستطيع معالجة عدد أكبر من الطلبات في وقت واحد. مثلاً، في مشروع للتعامل مع مراجعات المنتجات، وجدنا أن Fine-tuning يسمح لنا بمعالجة 10 آلاف مراجعة في الدقيقة، بينما Few-shot prompting لم يستطع تجاوز 3 آلاف مراجعة في نفس الوقت بسبب قيود الـ Context Window.

الحل الوسط: متى تستخدم Hybrid Approach؟

إذا كنت عالقاً بين الخيارين، فهناك حل وسط قد يكون الأفضل في كثير من الحالات: استخدام نموذج مُعَدَّل بـ Fine-tuning خفيف الوزن، مع تعزيزه بـ Few-shot prompting عند الحاجة. مثلاً، يمكنك تدريب نموذج على المهام الأساسية باستخدام Fine-tuning، ثم استخدام Few-shot prompting للتعامل مع الحالات النادرة أو الاستثناءات. هذا النهج يجمع بين دقة Fine-tuning وكفاءة Few-shot prompting، لكنه يتطلب هندسة معقدة قليلاً في تصميم النظام.

# مثال على Hybrid Approach
from transformers import pipeline

# نموذج مُعَدَّل بـ Fine-tuning للمهام الأساسية
fine_tuned_model = pipeline("text-classification", model="my_fine_tuned_model")

# استخدام Few-shot prompting للحالات النادرة
def classify_with_fallback(text):
 result = fine_tuned_model(text)
 if result[0]['score'] < 0.7: # إذا كانت الثقة منخفضة
 prompt = f"صنف النص التالي إلى فئة مناسبة: '{text}'\nأمثلة:\n1. 'هذا منتج رائع': إيجابي\n2. 'الخدمة سيئة': سلبي"
 few_shot_result = model.generate(input_ids=tokenizer.encode(prompt, return_tensors="pt"))
 return "فئة مخصصة: " + tokenizer.decode(few_shot_result[0])
 return result[0]['label']

# هذا النهج يعطي دقة عالية مع الحفاظ على الأداء الجيد

المشكلة التي لا يتحدث عنها أحد: الـ Data Drift في Fine-tuning

هناك مشكلة قاتلة مع Fine-tuning لا يتحدث عنها معظم المطورين: الـ Data Drift. عندما تقوم بتدريب نموذج على بيانات معينة، فإنه يتعلم الأنماط الموجودة في تلك البيانات فقط. لكن في العالم الحقيقي، تتغير البيانات باستمرار. مثلاً، إذا قمت بتدريب نموذج لتصنيف الأخبار في عام 2020، فإنه قد يفشل تماماً في التعامل مع الأخبار في عام 2024 لأن المصطلحات والسياقات تغيرت. هذا يعني أنك ستضطر إلى إعادة تدريب النموذج بشكل دوري، مما يزيد التكاليف ويعقد الصيانة.

على الجانب الآخر، Few-shot prompting لا يعاني من هذه المشكلة لأنه يعتمد على المعرفة العامة للنموذج. طالما أن النموذج الأساسي محدث، فإنك تستطيع التعامل مع البيانات الجديدة دون الحاجة إلى إعادة تدريب. مثلاً، في مشروع لتحليل مشاعر العملاء، وجدنا أن نموذجاً مُعَدَّلاً بـ Fine-tuning في عام 2022 بدأ يعطي نتائج خاطئة تماماً في عام 2023 لأن لغة العملاء تغيرت. بينما نفس النموذج باستخدام Few-shot prompting استمر في الأداء الجيد لأنه يعتمد على فهمه العام للغة وليس على بيانات قديمة.

قرار المهندس: خريطة طريق لاختيار الطريقة المناسبة

بعد كل هذه النقاشات، كيف تختار الطريقة المناسبة لمشروعك؟ إليك خريطة طريق مبسطة تعتمد على تجربتي في عشرات المشاريع:

• •**استخدم Fine-tuning إذا:** كانت دقة النموذج أمراً حاسماً (مثل التشخيص الطبي أو التحليل المالي)، لديك بيانات كافية للتدريب، تستطيع تحمل التكلفة الأولية، وتحتاج إلى معالجة كميات كبيرة من البيانات بكفاءة.
• •**استخدم Few-shot prompting إذا:** كنت بحاجة إلى نتائج سريعة، لديك ميزانية محدودة، البيانات متغيرة باستمرار، أو تحتاج إلى مرونة في التعامل مع حالات جديدة دون إعادة تدريب.
• •**جرب Hybrid Approach إذا:** لديك مهام أساسية تحتاج إلى دقة عالية، لكنك تريد أيضاً التعامل مع الحالات النادرة بكفاءة، أو إذا كنت تريد تقليل التكلفة دون التضحية بالأداء.
• •**تجنب Fine-tuning إذا:** كنت تعمل على مشروع صغير أو مؤقت، ليس لديك بيانات كافية، أو لا تستطيع تحمل تكاليف الصيانة المستمرة.
• •**تجنب Few-shot prompting إذا:** تحتاج إلى معالجة سياقات طويلة ومعقدة، أو إذا كانت الدقة العالية أمراً لا يمكن المساومة عليه.

خلاصة المهندس: لا تختر الأداة قبل فهم المشكلة

الخطأ الأكبر الذي يرتكبه المطورون هو اختيار الأداة قبل فهم المشكلة تماماً. Fine-tuning وFew-shot prompting ليسا مجرد تقنيتين مختلفتين، بل هما فلسفتان مختلفتان تماماً في التعامل مع LLMs. الأولى هي استثمار طويل الأمد يتطلب صبراً وموارد، والثانية هي حل سريع ومرن لكنه قد لا يكون كافياً للمهام المعقدة. القاعدة الذهبية التي أتبعها دائماً هي: ابدأ بـ Few-shot prompting واختبر حدوده، وإذا وجدت أنه لا يكفي، انتقل إلى Fine-tuning. لكن لا تفعل العكس أبداً، لأنك ستضيع وقتاً ومالاً في تدريب نماذج قد لا تحتاج إليها أصلاً. وفي النهاية، تذكر أن أفضل أداة هي التي تحل مشكلتك بأقل تكلفة وأعلى كفاءة، وليس الأداة التي تبدو أكثر تعقيداً أو حداثة.