Fine-tuning مقابل Few-shot prompting: معركة النماذج خلف الكواليس

في صباح يوم عمل عادي، كان السيرفر الخاص بفريق معالجة اللغة الطبيعية في شركة ناشئة يصرخ تحت ضغط ٣٠٠ طلب في الثانية. النموذج الذي تم ضبطه بدقة على بياناتهم المحلية كان يرد بدقة مذهلة، لكن كل استدعاء كان يكلف ٢٠٠ ميلي ثانية و٥٠ ميجابايت من الذاكرة. في نفس الوقت، كان نموذج آخر من فئة ١٧٥ مليار باراميتر يُدار عبر API خارجي يرد في ٨٠ ميلي ثانية لكن بفواتير شهرية تتجاوز ١٢ ألف دولار. السؤال الذي لم يكن لديهم وقت للإجابة عليه: هل كان Fine-tuning هو الحل الأمثل أم أن Few-shot prompting كان سيوفر عليهم الوقت والمال دون التضحية بالجودة؟

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

التشريح التقني: ماذا يحدث داخل النموذج حقاً؟

عندما تقوم بـ Fine-tuning لنموذج مثل BERT أو T5، فأنت في الواقع تقوم بتعديل أوزان الطبقات العليا من الشبكة العصبونية بينما تحافظ على الطبقات الدنيا مجمدة. هذه العملية تشبه إعادة تدريب جزء من الدماغ البشري على مهمة جديدة دون نسيان المهارات الأساسية. على سبيل المثال، في نموذج مثل RoBERTa، قد تقوم بتجميد أول ٩ طبقات وتدريب آخر ٣ طبقات على بياناتك الخاصة. هذا يعني أنك تحتاج إلى بيانات كافية لتجنب الـ overfitting، لكنك تستفيد من المعرفة العامة التي تعلمها النموذج مسبقاً.

أما في حالة Few-shot prompting، فأنت لا تعدل أي أوزان على الإطلاق. بدلاً من ذلك، تعتمد على قدرة النموذج على فهم المهمة من خلال أمثلة قليلة تُضاف إلى الـ prompt. هذه العملية تعتمد بشكل كبير على ما يسمى بـ "in-context learning"، حيث يستخدم النموذج السياق المقدم في الـ prompt لتعديل سلوكه دون تغيير أوزانه. المشكلة هنا أن هذه القدرة ليست متساوية بين النماذج؛ فالنماذج الأكبر مثل GPT-4 أو PaLM 2 تتفوق بشكل كبير في هذا المجال مقارنة بالنماذج الأصغر مثل GPT-2 أو حتى BERT.

# Fine-tuning مثال على باستخدام Hugging Face
from transformers import RobertaForSequenceClassification, RobertaTokenizer, Trainer, TrainingArguments

model = RobertaForSequenceClassification.from_pretrained("roberta-base", num_labels=2)
tokenizer = RobertaTokenizer.from_pretrained("roberta-base")

training_args = TrainingArguments(
 output_dir="./results",
 num_train_epochs=3,
 per_device_train_batch_size=8,
 per_device_eval_batch_size=16,
 warmup_steps=500,
 weight_decay=0.01,
 logging_dir="./logs",
 logging_steps=10,
 save_steps=10_000,
 evaluati"steps",
)

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

trainer.train()

# Few-shot prompting مثال على باستخدام OpenAI API
import openai

response = openai.ChatCompletion.create(
 model="gpt-4",
 messages=[
 {"role": "system", "content": "You are a helpful assistant."},
 {"role": "user", "content": 
 "Classify the following sentences as positive or negative:\n"
 "1. I love this product! -> positive\n"
 "2. This is the worst experience ever. -> negative\n"
 "3. It's okay, not great. -> "}
 ],
 temperature=0.1,
)

الذاكرة والمعالج: أين يذهب وقتك ومالِك؟

دعونا نتحدث بالأرقام. في مشروع حقيقي عملت عليه مع فريق في دبي، استخدمنا نموذج RoBERTa-base لضبط دقيق على مجموعة بيانات تحتوي على ٥٠ ألف مثال. استغرق التدريب ٤ ساعات على جهاز V100 GPU، واستهلك حوالي ١٢ جيجابايت من الذاكرة. بعد التدريب، كان النموذج جاهزاً للعمل على سيرفر داخلي بتكلفة تشغيلية منخفضة جداً. لكن المشكلة ظهرت عندما حاولنا توسيع نطاقه؛ فكل استدعاء للنموذج كان يستغرق ١٥٠ ميلي ثانية، مما يعني أن السيرفر كان قادراً على معالجة حوالي ٦-٧ طلبات في الثانية قبل أن يبدأ في التعطل.

في المقابل، عندما استخدمنا نموذج GPT-3.5 عبر API خارجي لنفس المهمة، كانت الاستجابة تأتي في ٦٠ ميلي ثانية فقط، لكن التكلفة كانت مرتفعة جداً. على سبيل المثال، لمعالجة نفس الـ ٥٠ ألف مثال، كانت التكلفة تتجاوز ٣ آلاف دولار شهرياً. لكن الفائدة كانت واضحة: لا حاجة لإدارة سيرفرات، ولا قلق بشأن الـ scaling، وكل التحديثات تتم تلقائياً من قبل مزود الخدمة. السؤال هنا ليس فقط عن التكلفة، بل عن نوع المشروع؛ هل أنت بحاجة إلى تحكم كامل في النموذج وتكاليف تشغيلية منخفضة على المدى الطويل، أم أنك تفضل السرعة والمرونة على حساب التكلفة؟

الـ GPU Memory: العدو الخفي في Fine-tuning

عندما تقوم بـ Fine-tuning، فإنك تحتاج إلى تحميل النموذج بالكامل في ذاكرة الـ GPU. هذا يعني أنك مقيد بحجم الذاكرة المتاحة. على سبيل المثال، نموذج مثل BERT-large يتطلب حوالي ٣ جيجابايت من الذاكرة للتحميل فقط، دون احتساب البيانات والـ gradients. إذا كنت تستخدم batch size كبير، فقد تحتاج إلى أكثر من ١٦ جيجابايت من الذاكرة. هذا هو السبب في أن معظم الفرق تستخدم نماذج أصغر مثل DistilBERT أو TinyBERT عندما تكون الموارد محدودة.

هناك حيلة تقنية تستخدمها الفرق الذكية لتوفير الذاكرة: الـ gradient checkpointing. هذه التقنية تقلل من استخدام الذاكرة عن طريق إعادة حساب الـ gradients أثناء الـ backpropagation بدلاً من تخزينها. لكن الثمن هنا هو زيادة وقت التدريب، حيث أن إعادة الحساب تستهلك وقتاً إضافياً. في مشروع سابق، استخدمنا هذه التقنية لتدريب نموذج على جهاز بـ ٨ جيجابايت فقط من ذاكرة GPU، لكن وقت التدريب زاد من ٣ ساعات إلى ٧ ساعات.

# استخدام gradient checkpointing لتوفير الذاكرة
from transformers import TrainingArguments

training_args = TrainingArguments(
 output_dir="./results",
 gradient_checkpointing=True, # تفعيل الـ gradient checkpointing
 per_device_train_batch_size=16, # زيادة الـ batch size
 num_train_epochs=5,
 save_steps=10_000,
)

Few-shot prompting: متى تكون البراعة أهم من البيانات؟

هناك اعتقاد سائد أن Few-shot prompting هو الحل السحري عندما تكون بياناتك محدودة. لكن الحقيقة أكثر تعقيداً. في تجربة أجريناها على مهمة تصنيف النصوص العربية، وجدنا أن نموذج GPT-4 كان قادراً على تحقيق دقة ٨٥٪ باستخدام ١٠ أمثلة فقط في الـ prompt، بينما نموذج RoBERTa الذي تم ضبطه بدقة على ١٠ آلاف مثال حقق دقة ٨٨٪. الفرق هنا ليس كبيراً، لكن التكلفة كانت هائلة: النموذج المحلي كان يكلف تقريباً ٠ دولار بعد التدريب، بينما النموذج الخارجي كان يكلف ٠.٠٦ دولار لكل ١٠٠٠ رمز.

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

فن صياغة الـ prompts: هل هو علم أم فن؟

هناك فرق كبير بين كتابة prompt جيد وكتابة prompt ممتاز. على سبيل المثال، في مهمة استخراج المعلومات من النصوص الطبية، وجدنا أن إضافة تعليمات واضحة مثل "استخرج جميع الأدوية المذكورة في النص التالي مع الجرعات إن وجدت" كانت تعطي نتائج أفضل بكثير من مجرد قول "استخرج الأدوية". أيضاً، استخدام أمثلة متنوعة في الـ prompt يساعد النموذج على فهم المهمة بشكل أفضل. في تجربة مع فريق في مصر، استخدمنا ٥ أمثلة مختلفة لتوضيح مهمة تصنيف المشاعر، وكان الفرق في الدقة بين الـ prompt البسيط والمعقد حوالي ١٢٪.

# مثال على prompt جيد لمهمة استخراج المعلومات
prompt = """
استخرج جميع الأدوية المذكورة في النص التالي مع الجرعات إن وجدت:

النص: "أخذ المريض ٥٠٠ ملغ من الباراسيتامول مرتين يومياً، و٢٠ ملغ من الليزينوبريل مرة واحدة يومياً."
الأدوية: الباراسيتامول (٥٠٠ ملغ)، الليزينوبريل (٢٠ ملغ)

النص: "يوصى بتناول ١٠ ملغ من أتورفاستاتين قبل النوم."
الأدوية: أتورفاستاتين (١٠ ملغ)

النص: "لم يذكر المريض أي أدوية أخرى."
الأدوية: لا يوجد

النص: "{text}"
الأدوية:
"""

resp openai.Completion.create(
 engine="text-davinci-003",
 prompt=prompt,
 max_tokens=100,
 temperature=0.1,
)

التكلفة الخفية: ما لا يخبرك به مزودو الخدمات

عندما تتحدث عن Fine-tuning، فإن التكلفة الخفية غالباً ما تكون في إدارة البنية التحتية. تحتاج إلى سيرفرات قوية، وصيانة دورية، وفريق لدعمها. في شركة ناشئة عملت معها، كانت التكلفة الشهرية لتشغيل سيرفر GPU داخلي حوالي ١٥٠٠ دولار، بالإضافة إلى ٢٠٠ دولار شهرياً لصيانة النظام وتحديثاته. لكن الفائدة كانت في التحكم الكامل؛ لم نكن مقيدين بعدد الطلبات أو حجم البيانات، وكل شيء كان تحت سيطرتنا.

أما في حالة Few-shot prompting، فإن التكلفة الخفية تأتي من الاعتماد على مزود خارجي. على سبيل المثال، إذا كنت تستخدم OpenAI API، فأنت مقيد بعدد الرموز في الدقيقة، وقد تواجه مشاكل في التوافر إذا كان هناك ضغط على الخدمة. في مشروع مع فريق في قطر، واجهنا هذه المشكلة عندما كان النموذج يتعطل بشكل متكرر بسبب ارتفاع الطلب العالمي. أيضاً، هناك مشكلة الخصوصية؛ فكل بياناتك تمر عبر سيرفرات خارجية، وهذا قد يكون غير مقبول في بعض الصناعات مثل الرعاية الصحية أو المالية.

الـ Latency: العدو الصامت في تطبيقات الإنتاج

في تطبيقات الإنتاج، الـ latency هو عامل حاسم. نموذج Fine-tuning المحلي قد يكون سريعاً، لكن إذا كان السيرفر غير محسن، فقد تواجه مشاكل في الأداء. على سبيل المثال، في تطبيق محادثة آلية عملنا عليه، كان النموذج المحلي يستغرق ٢٠٠ ميلي ثانية للرد، لكن عندما زاد عدد المستخدمين، بدأ الـ latency في الارتفاع إلى أكثر من ثانية. الحل كان في استخدام تقنية الـ model quantization لتقليل حجم النموذج وتحسين الأداء.

في المقابل، النماذج الخارجية مثل GPT-4 قد تكون أسرع في الرد، لكنك تعتمد على سرعة الإنترنت والتوافر العالمي. في تجربة مع فريق في المغرب، وجدنا أن الـ latency كان يتراوح بين ٨٠ و٥٠٠ ميلي ثانية اعتماداً على وقت اليوم. هذا يعني أنك بحاجة إلى تصميم تطبيقك ليتحمل هذه التقلبات، ربما باستخدام تقنيات مثل الـ caching أو الـ fallback إلى نموذج محلي أصغر في حالة الفشل.

# استخدام model quantization لتحسين الأداء
from transformers import AutoModelForSequenceClassification, AutoTokenizer
import torch

model = AutoModelForSequenceClassification.from_pretrained("fine-tuned-model")
tokenizer = AutoTokenizer.from_pretrained("fine-tuned-model")

# تحويل النموذج إلى dtype أصغر
quantized_model = torch.quantization.quantize_dynamic(
 model, {torch.nn.Linear}, dtype=torch.qint8
)

# حفظ النموذج المضغوط
quantized_model.save_pretrained("quantized-model")

خلاصة المهندس: أيهما تختار ولماذا؟

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

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

الذكاء الاصطناعي ليس عن حجم النموذج، بل عن كيفية استخدامه. أحياناً، تكون البراعة في الـ prompt هي الفرق بين النجاح والفشل.

— مهندس برمجيات سنيور في شركة تقنية رائدة