هل تضحي بالوقت والمال في ضبط نموذجك بدقة، أم تعتمد على براعة الـ Prompting؟ مقارنة تقنية عميقة تكشف ما يحدث خلف الكواليس في الذاكرة والمعالج، وتجيب: أيهما يستحق مكاناً في مشروعك القادم.
ساعة واحدة من الـ Fine-tuning على نموذج متوسط الحجم مثل Llama-3-8B تستهلك ما يعادل 120 دولاراً على AWS، وتترك سيرفرك يلهث لمدة ست ساعات متواصلة. في المقابل، يمكنك كتابة Prompt ذكي في خمس دقائق، ويرد عليك النموذج خلال ثوانٍ، وبدون أي تكلفة إضافية. السؤال الذي يطرحه كل مهندس يعمل على مشروع حقيقي: هل الـ 120 دولار والساعات الست تستحق العناء، أم أن الـ Few-shot prompting هو الحل السحري الذي نبحث عنه جميعاً؟ الحقيقة هي أن الإجابة ليست بنعم أو لا، بل تعتمد على ما يحدث خلف الكواليس في الذاكرة والمعالج، وعلى نوع المشكلة التي تحاول حلها.
دعونا نبدأ بالحقائق الصادمة: نموذج مثل GPT-4 يمكنه تحقيق دقة تصل إلى 92% في مهمة تصنيف النصوص باستخدام 10 أمثلة فقط في الـ Prompt، بينما يتطلب نموذج أصغر مثل Mistral-7B أكثر من 500 مثال في الـ Fine-tuning للوصول إلى نفس الدقة. لكن، هذا لا يعني أن الـ Few-shot هو الفائز دائماً. عندما يتعلق الأمر بمهام تتطلب فهم السياق العميق أو التعامل مع بيانات حساسة، فإن الـ Fine-tuning يصبح الخيار الوحيد القابل للتطبيق. المشكلة تكمن في أننا غالباً ما نختار الأداة بناءً على ما نعرفه، وليس بناءً على ما يحتاجه المشروع حقاً.
عندما نتحدث عن الـ Fine-tuning، فإننا نتحدث عن تعديل الأوزان الداخلية للنموذج بناءً على مجموعة بيانات محددة. هذه العملية تشبه تدريب سائق جديد على قيادة سيارة ذات ناقل حركة يدوي: في البداية، يكون الأداء متقطعاً، لكن مع الوقت والتكرار، يصبح السائق قادراً على التعامل مع أي طريق بسهولة. خلف الكواليس، الـ Fine-tuning يستخدم خوارزميات مثل AdamW لتحسين الأوزان، حيث يتم حساب الـ Gradient لكل وزن في النموذج، وتحديثه بناءً على الخطأ الذي يحدث في المخرجات. هذه العملية تتطلب موارد هائلة، خاصة عندما نتحدث عن نماذج تحتوي على مليارات البارامترات.
في المقابل، الـ Few-shot prompting لا يلمس الأوزان الداخلية للنموذج أبداً. بدلاً من ذلك، يعتمد على قدرة النموذج على فهم السياق من الأمثلة المقدمة في الـ Prompt نفسه. تخيل أنك تعلم شخصاً كيفية حل معادلة رياضية: بدلاً من شرح النظرية كاملة، تعطيه ثلاثة أمثلة وتقول له "اتبع نفس النمط". هذا بالضبط ما يفعله الـ Few-shot prompting. لكن، هناك مشكلة كبيرة هنا: النموذج لا يتعلم حقاً، بل يعتمد على قدرته على التعميم من الأمثلة القليلة. إذا كانت الأمثلة غير ممثلة بشكل جيد، فإن الأداء سينهار بسرعة.
# مثال على Fine-tuning لنموذج Mistral-7B باستخدام مكتبة Transformers
from transformers import AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments
model_name = "mistralai/Mistral-7B-v0.1"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)
training_args = TrainingArguments(
output_dir="./results",
per_device_train_batch_size=4,
num_train_epochs=3,
save_steps=10_000,
save_total_limit=2,
logging_dir="./logs",
logging_steps=500,
learning_rate=2e-5,
fp16=True,
)
trainer = Trainer(
model=model,
args=training_args,
train_dataset=train_dataset,
eval_dataset=eval_dataset,
)
trainer.train()
# لاحظ أن هذا الكود يتطلب GPU قوي (مثل A100) ووقت طويل للتنفيذ
# كما أن حجم البيانات المطلوب كبير لتحقيق نتائج جيدة# مثال على Few-shot prompting باستخدام نفس النموذج
from transformers import AutoModelForCausalLM, AutoTokenizer
model_name = "mistralai/Mistral-7B-v0.1"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)
prompt = """
Classify the following sentences into positive or negative sentiment:
Example 1: "I love this product!" -> Positive
Example 2: "This is the worst experience ever." -> Negative
Example 3: "It's okay, nothing special." -> Neutral
Sentence: "The service was incredibly fast and friendly."
"""
inputs = tokenizer(prompt, return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=50)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))
# هذا الكود يعمل بسرعة كبيرة ولا يتطلب موارد إضافية
# لكن دقته تعتمد بشكل كامل على جودة الأمثلة في الـ Promptعندما تختار الـ Fine-tuning، فإنك لا تدفع فقط ثمن الـ GPU Hours. هناك تكلفة خفية أكبر بكثير: تكلفة جمع البيانات وتنظيفها. في تجربتي مع مشروع لتصنيف المراجعات العربية، استغرق فريقنا أكثر من شهرين لجمع وتنظيف 50 ألف مثال. المشكلة الأكبر كانت في التوازن بين الفئات: بعض الفئات كانت نادرة جداً، مما اضطرنا لاستخدام تقنيات مثل SMOTE لزيادة تمثيلها. حتى بعد كل هذا الجهد، وجدنا أن النموذج كان يعاني من الـ Overfitting على بعض الأنماط اللغوية الخاصة بمصدر البيانات، مما اضطرنا لإعادة العملية بأكملها باستخدام بيانات من مصادر مختلفة.
ثم تأتي مشكلة الـ Memory Leak. نماذج اللغة الكبيرة مثل Llama-3 تستهلك ما يصل إلى 40 جيجابايت من VRAM أثناء الـ Fine-tuning. حتى مع استخدام تقنيات مثل Gradient Checkpointing و Mixed Precision Training، فإن أي خطأ بسيط في الكود يمكن أن يؤدي إلى استهلاك الذاكرة بشكل غير متوقع. في إحدى المرات، قضينا ليلة كاملة في تصحيح خطأ بسيط في الـ DataLoader أدى إلى تحميل الدفعة بأكملها في الذاكرة بدلاً من تحميلها بشكل متتابع. النتيجة؟ السيرفر توقف عن الاستجابة بعد ساعتين من التدريب، وفقدنا كل التقدم الذي أحرزناه.
هناك أيضاً تكلفة الفرصة البديلة. الوقت الذي تقضيه في الـ Fine-tuning هو وقت لا تقضيه في تحسين المنتج نفسه. في مشروع سابق لشركة ناشئة في مجال الصحة، قررنا استخدام الـ Fine-tuning لنموذج لتحليل تقارير الأشعة. بعد ثلاثة أشهر من العمل، اكتشفنا أن الـ Few-shot prompting مع نموذج مثل GPT-4 كان يحقق دقة مقبولة بنسبة 85%، بينما وصلنا إلى 88% فقط بعد الـ Fine-tuning. الفرق البسيط لم يكن يستحق الثلاثة أشهر التي ضاعت، خاصة أننا كنا نستطيع استخدام هذا الوقت في تحسين واجهة المستخدم أو إضافة ميزات جديدة.
الـ Few-shot prompting ليس مجرد حل سريع للمبتدئين. في الواقع، هناك حالات يكون فيها الخيار الوحيد المنطقي. عندما تعمل على مشروع تجريبي أو MVP، فإن الـ Few-shot يسمح لك باختبار الفكرة بسرعة وبدون استثمار كبير. في إحدى المرات، طلب مني عميل تطوير نظام لتصنيف رسائل البريد الإلكتروني إلى فئات مختلفة. بدلاً من البدء مباشرة بالـ Fine-tuning، استخدمت الـ Few-shot prompting مع نموذج GPT-3.5 لتحديد الفئات الرئيسية. النتيجة؟ تمكنا من تقديم نموذج أولي للعملاء في يومين فقط، وحصلنا على تغذية راجعة قيمة ساعدتنا في تصميم نظام الـ Fine-tuning لاحقاً بشكل أفضل.
هناك أيضاً حالات يكون فيها الـ Few-shot هو الخيار الوحيد الممكن. عندما تتعامل مع بيانات حساسة لا يمكنك مشاركتها مع نموذج خارجي، أو عندما تعمل في بيئة ذات قيود تنظيمية صارمة، فإن الـ Fine-tuning على نموذج مفتوح المصدر مثل Mistral أو Llama يصبح الخيار الوحيد. لكن حتى في هذه الحالات، يمكنك استخدام الـ Few-shot كخطوة أولى لتقييم جدوى المشروع قبل الاستثمار في الـ Fine-tuning.
الـ Few-shot prompting ليس مجرد وضع أمثلة عشوائية في الـ Prompt. هناك علم كامل خلف تصميم الـ Prompts الفعالة. في تجربتي، وجدت أن الأمثلة التي تغطي الحالات الحدية (Edge Cases) هي الأكثر أهمية. مثلاً، إذا كنت تبني نظاماً لتصنيف المراجعات، فلا تكتفِ بأمثلة واضحة مثل "المنتج رائع" أو "الخدمة سيئة". أضف أمثلة مثل "المنتج جيد لكنه وصل متأخراً" أو "الخدمة كانت جيدة لكن السعر مرتفع". هذه الأمثلة تعلم النموذج كيفية التعامل مع السياقات المعقدة.
# مثال على Prompt مصمم بعناية لتغطية الحالات الحدية
prompt = """
Classify the following customer reviews into one of these categories:
1. Positive
2. Negative
3. Mixed (both positive and negative aspects)
4. Neutral (no clear sentiment)
Make sure to consider the context and not just individual words.
Examples:
- "The product is amazing, I love it!" -> Positive
- "The delivery was late but the product itself is great." -> Mixed
- "The service was okay, nothing special." -> Neutral
- "I hate this company, they never deliver on time." -> Negative
- "The item arrived in good condition but the packaging was damaged." -> Mixed
Now classify this review:
"The food was delicious but the waiter was rude."
"""
# هذا النوع من الـ Prompts يعطي نتائج أفضل بكثير من الأمثلة البسيطة
# لأنه يعلم النموذج كيفية التعامل مع السياقات المعقدةسواء اخترت الـ Fine-tuning أو الـ Few-shot prompting، هناك فخاخ شائعة يجب تجنبها. في حالة الـ Fine-tuning، أكبر خطأ هو استخدام بيانات غير ممثلة بشكل جيد. في أحد المشاريع، استخدمنا بيانات من منصة واحدة فقط لتدريب نموذج لتصنيف المراجعات. عندما نشرنا النموذج في الإنتاج، وجدنا أنه يعمل بشكل رائع على البيانات المشابهة لتلك التي تدرب عليها، لكنه يفشل تماماً مع البيانات من منصات أخرى. السبب؟ الاختلاف في اللهجات والأسلوب اللغوي بين المنصات. الحل؟ جمع بيانات من مصادر متعددة والتأكد من تمثيل جميع الفئات بشكل متوازن.
في حالة الـ Few-shot prompting، أكبر خطأ هو الاعتماد على الأمثلة دون اختبارها بشكل كافٍ. في إحدى المرات، استخدمت 5 أمثلة فقط في الـ Prompt لتصنيف الأخبار إلى فئات مختلفة. النتائج الأولية كانت واعدة، لكن عندما اختبرنا النموذج على مجموعة أكبر من البيانات، وجدنا أنه يفشل في تصنيف الأخبار التي تحتوي على أكثر من فئة واحدة. السبب؟ الأمثلة التي استخدمتها كانت بسيطة جداً ولم تغطِ الحالات المعقدة. الحل؟ إضافة المزيد من الأمثلة التي تغطي الحالات الحدية، واستخدام تقنيات مثل Chain-of-Thought prompting لتعليم النموذج كيفية التفكير خطوة بخطوة.
يعتقد الكثيرون أن الـ Few-shot prompting لا يعاني من مشكلة الـ Overfitting، لكن هذا غير صحيح. عندما تعتمد على عدد قليل من الأمثلة، فإن النموذج قد يتعلم الأنماط الخاصة بهذه الأمثلة بدلاً من التعميم. مثلاً، إذا استخدمت أمثلة تحتوي جميعاً على كلمات معينة، فإن النموذج قد يعتمد على هذه الكلمات بدلاً من فهم السياق العام. الحل؟ تغيير الأمثلة بشكل دوري واختبار النموذج على بيانات جديدة باستمرار.
الآن بعد أن فهمنا كيف يعمل كل منهما، وماذا يحدث خلف الكواليس، يمكننا وضع قواعد واضحة لاختيار الأداة المناسبة. إذا كانت مهمتك تتطلب دقة عالية جداً (أكثر من 95%)، وتتطلب التعامل مع بيانات حساسة أو خاصة، فإن الـ Fine-tuning هو الخيار الوحيد. مثلاً، في مجال الرعاية الصحية أو التمويل، حيث تكون الدقة والخصوصية أمرين حاسمين، لا يوجد بديل عن الـ Fine-tuning. لكن حتى في هذه الحالات، يمكنك استخدام الـ Few-shot كخطوة أولى لتقييم جدوى المشروع قبل الاستثمار في الـ Fine-tuning.
إذا كنت تعمل على مشروع تجريبي أو MVP، أو إذا كانت مهمتك لا تتطلب دقة عالية جداً، فإن الـ Few-shot prompting هو الخيار الذكي. ليس فقط لأنه أسرع وأرخص، بل لأنه أيضاً يسمح لك بالتجربة والتكرار بسرعة. في عالم الـ Startups، السرعة غالباً ما تكون أهم من الكمال. يمكنك دائماً الانتقال إلى الـ Fine-tuning لاحقاً إذا وجدت أن الـ Few-shot لا يلبي احتياجاتك.
إذا كنت تريد نصيحة واحدة فقط من هذا المقال، فهي هذه: لا تختر الأداة بناءً على ما تعرفه، بل بناءً على ما يحتاجه مشروعك حقاً. الـ Fine-tuning ليس دائماً الحل الأفضل، والـ Few-shot prompting ليس دائماً الحل السريع. ابدأ دائماً باختبار الـ Few-shot مع أمثلة مصممة بعناية، وقم بقياس الأداء بشكل دقيق. إذا وجدت أن الأداء غير كافٍ، عندها فقط انتقل إلى الـ Fine-tuning. وفي كل الأحوال، تذكر أن الذكاء الاصطناعي ليس سحراً، بل أداة تحتاج إلى فهم عميق واستخدام ذكي.
في المرة القادمة التي تواجه فيها قرار الاختيار بين الـ Fine-tuning والـ Few-shot prompting، اسأل نفسك هذه الأسئلة الثلاثة: ما هي الدقة التي أحتاجها حقاً؟ ما هي الموارد التي أملكها (وقت، مال، بيانات)؟ ما هي المخاطر التي يمكنني تحملها؟ الإجابات ستخبرك بالضبط بأي طريق تسلك.