لكل شخص رأيه حول الضبط الدقيق (Fine-tuning) مقابل تقنية RAG. تصفح أي منتدى للذكاء الاصطناعي وستجد نقاشات حادة مليئة بمخططات البنية التحتية وادعاءات المعايير المرجعية (benchmarks). معظم الذين يكتبون تلك التعليقات لم يسبق لهم تدريب نموذج على بياناتهم الخاصة أو مراقبة فشل مسار RAG بصمت في بيئة الإنتاج.

قضيت شهوراً في إجراء التجارب. اثنتا عشرة تجربة، على وجه التحديد. قمت بالضبط الدقيق لنماذج LLMs، وبالضبط الدقيق للمُدمِجات (embedders)، وبنيت ستة تكوينات مختلفة لـ RAG. كان المجال هو التنبؤ المالي، وتحديداً محاولة التنبؤ بنتائج السوق المشوشة من بيانات تاريخية غير منظمة. التزمت بمعايير إحصائية صارمة لأنني أردت إجابات حقيقية، وليس مجرد ادعاءات في تدوينات.

فشلت معظم التجارب. وتبين أن تلك الإخفاقات كانت أكثر فائدة بكثير من أي نجاح وليد الصدفة.

الحقيقة المرة حول الإشارة (Signal)

قبل الدخول في التفاصيل، إليكم الدرس الذي يربط كل شيء ببعضه. الضبط الدقيق وRAG هما أداتان لتغيير ما يعرفه النموذج أو ما يراه. ليسا عصا سحرية تصنع الإشارات من العدم. إذا كانت بياناتك الأساسية لا تحتوي على نمط حقيقي يمكن استغلاله، فلن تخلق هذه التقنيات نمطاً. بل ستساعدك فقط على بناء قصة أكثر إقناعاً حول ضوضاء عشوائية.

في التنبؤ المالي، يعد هذا الفخ خطيراً بشكل خاص. الأسواق مشوشة بطبيعتها. عندما تربط نموذج LLM قوياً ببيانات الأسعار التاريخية وتضيف تقنيات الاسترجاع أو الضبط الدقيق، فلن تحصل تلقائياً على ميزة تنافسية. بل ستحصل على طريقة أكثر فصاحة لتبرير نتائج رمي العملة. إذا لم تكن الإشارة موجودة، فسيصبح النموذج بارعاً جداً في الكذب عليك. عليك التحقق من ذلك أولاً.

عندما يحفظ النموذج الأكبر بدلاً من أن يتعلم

كان خطئي الكبير الأول هو افتراض أن الحجم (scale) سيصلح كل شيء. اختبرت نموذجاً بـ 14 مليار معلمة (parameter) مقابل نموذج بـ 7 مليارات معلمة على 777 مثالاً تدريبياً بالضبط. حقق النموذج الأكبر eval_loss أفضل بشكل ملحوظ، وانخفضت درجة الحيرة (perplexity) لديه. على الورق، كان النموذج يتعلم.

ثم نظرت إلى معدل الفوز (win rate)، وهو المعدل الفعلي الذي قدم فيه النموذج تنبؤات صحيحة. كان أداء نموذج الـ 14B أسوأ بكثير من نموذج الـ 7B. لقد حفظ الضوضاء التدريبية. مع وجود أقل من 3,000 مثال، كان لدى النموذج الأكبر سعة كافية للإفراط في التخصيص (overfit) على الارتباطات الزائفة والتقلبات العشوائية في البيانات. لقد قام أساساً ببناء جدول بحث (lookup table) للضوضاء.

أما نموذج الـ 7B، وبسبب محدودية سعته، فقد أُجبر على تعلم أنماط أوسع. لم يكن بمقدوره حفظ كل خصوصية أو تفصيلة صغيرة. إذا كنت تعمل مع مجموعات بيانات صغيرة، فابدأ بنماذج أصغر. الحجم ليس مجانياً، بل يمكن أن يضرك فعلياً عندما تكون البيانات شحيحة.

لا تثق في منحنى الخسارة (Loss Curve)

تعلمت أن أتوقف عن التحديق في منحنيات الخسارة. يمكن للنموذج أن يحسن مستوى الـ cross-entropy على مستوى الرموز (tokens) بينما يصبح أسوأ في اتخاذ القرار التجاري الفعلي الذي يهمك. يحدث هذا لأن خسارة نمذجة اللغة تكافئ التنبؤ بالرمز التالي بدقة. في العديد من المجالات، وخاصة التمويل، لا يكون القرار الصحيح والرمز التالي الأكثر احتمالاً هما الشيء نفسه.

رأيت نماذج تعيد إنتاج النصوص التدريبية بجمال، لكنها تختار الرهان الاتجاهي الخاطئ في كل مرة. انخفضت الخسارة، وانخفض رأس المال معها.

I tested eight separate RAG configurations for prediction tasks. Across the board, adding retrieval changed roughly 30 percent of the model's decisions. That sounds impactful. It was not. Those changes were pure noise. The overall accuracy did not improve. What did change was the model's confidence. RAG made the system sound more certain, cite more sources, and produce longer justifications. All while being just as wrong.

This overconfidence is a product risk. A user sees citations and assumes the model has done its homework. In reality, it was doing sophisticated-looking guesswork.

The most painful lesson came from backtesting one RAG variant. It showed an 11 percent annual profit. On the surface, that looks like a winning strategy. But its AUC, the area under the ROC curve and a measure of classification skill, was 0.486. That is worse than a coin flip, which sits at 0.500. The profit was a fluke of the specific market period, not a repeatable edge. Using P&L alone as a metric is dangerous. Markets hand out lucky streaks all the time. You need statistical skill metrics to separate flukes from competence.

Know What Each Tool Actually Does

So where does this leave us? Use fine-tuning when the model needs to learn new words, specific formats, or a distinctive style. Use RAG when the model needs access to facts, code repositories, or institutional memory that lives outside its weights. Do not use either tool to discover signal in data that has none. If the underlying pattern is not there, retrieval and fine-tuning will only help you dress up the noise in a sharper suit.

The Real Bottleneck

The infrastructure for fine-tuning and RAG has never been easier to set up. You can spin up a pipeline in an afternoon. The technique is no longer the bottleneck. Evaluation is. Most teams skip the hard statistical work and celebrate vanity metrics instead. They ship systems that sound smart but fail silently.

Run honest tests before you spend money. Question your metrics. Check for overfitting. Make sure the model is actually better,