RAG مقابل الضبط الدقيق (Fine-tuning): الأداة المناسبة لمعرفة المؤسسات
لماذا يجب على معظم المؤسسات البدء بـ RAG ومتى يكون الضبط الدقيق (Fine-tuning) منطقياً بالفعل. إطار عمل عملي للاختيار بين النهجين بناءً على حداثة البيانات، نوع الاستعلام، ومتطلبات الخصوصية.
كل مشروع ذكاء اصطناعي في المؤسسات يصل في النهاية إلى نفس مفترق الطرق: هل نقوم بعمل ضبط دقيق (fine-tuning) للنموذج على بياناتنا، أم نبني نظام RAG؟ كلا النهجين يربطان النموذج اللغوي الكبير (LLM) بمجال عملك الخاص. الاختيار الخاطئ قد يضيع شهوراً من العمل الهندسي وعشرات الآلاف من الدولارات.
هذا هو إطار العمل الذي نستخدمه لتحديد نطاق المشاريع في Verel Systems.
الخلاصة باختصار: ابدأ بـ RAG. لا تلجأ إلى الضبط الدقيق (fine-tuning) إلا إذا كانت لديك فجوة محددة وقابلة للقياس لا يمكن لـ RAG سدها — وكان لديك حجم البيانات الكافي لتبرير ذلك (ما لا يقل عن 10 آلاف عينة عالية الجودة).
ما الذي يفعله كل نهج فعلياً؟
نظام RAG (الاسترجاع المعزز بالتوليد) يبقي معرفتك خارجية. عند إرسال استعلام، يسترجع النظام مقاطع (chunks) المستندات ذات الصلة من قاعدة بيانات المتجهات (vector database) ويحقنها كـ context (سياق) قبل أن يقوم النموذج (LLM) بتوليد الإجابة. النموذج نفسه لا يتغير أبداً.
أما الضبط الدقيق (Fine-tuning) فيدمج المعرفة داخل أوزان النموذج (model weights) من خلال مواصلة تدريبه على بيانات مجال عملك. يتغير النموذج بشكل دائم؛ وأنت تدفع تكلفة الحوسبة (compute) لتعديل توزيعات الاحتمالات داخل الشبكة العصيبية.
كلا النهجين يحلان مشاكل مختلفة. وفهم المشكلة التي تواجهها هو أساس اللعبة بالكامل.
إطار عمل اتخاذ القرار
اطرح هذه الأسئلة الخمسة بالترتيب. أول سؤال يمنحك إجابة حاسمة هو خيارك الأنسب.
1. هل تتغير معرفتك باستمرار؟
| السيناريو | الإجابة | السبب |
|---|---|---|
| كتالوج المنتجات يتحدث يومياً | RAG | إعادة الفهرسة (re-indexing) تستغرق دقائق، بينما إعادة التدريب تستغرق أياماً |
| قضايا قانونية جديدة تضاف أسبوعياً | RAG | الـ fine-tuning لا يمكنه مواكبة هذه السرعة |
| دليل موظفين ثابت، يتحدث سنوياً | كلاهما | كلاهما يعمل؛ التكلفة هي الفيصل |
| النموذج يحتاج إلى "التفكير بشكل مختلف"، وليس مجرد معرفة المزيد | Fine-tune | الفجوة ليست في المعرفة بل في أنماط الاستنتاج (reasoning) |
إذا كانت قاعدة المعرفة لديك تتغير أكثر من مرة في الشهر، فإن RAG يتفوق لأسباب تشغيلية بحتة. النموذج الذي تم عمل ضبط دقيق له يكون متجمداً في لحظة زمنية معينة. وإبقاؤه محدثاً يتطلب خط معالجة (pipeline) لإعادة التدريب يكلف ما بين 200 إلى 2,000 دولار لكل عملية تشغيل لنموذج بحجم 7B parameters على سحابة الـ GPUs.
2. هل يحتاج المستخدمون إلى مراجع ومصادر (citations)؟
إذا سأل مستخدم نظام ذكاء اصطناعي طبي "ما هي الجرعة الموصى بها من العقار X؟" وحصل على إجابة، فإنه يحتاج إلى معرفة المستند الذي جاءت منه هذه المعلومة ليثق بها. يعيد نظام RAG مقاطع المصادر المسترجعة جنباً إلى جنب مع الإجابة — فالتوثيق والمصادر ميزة أصيلة في بنية النظام (architecture).
أما النماذج التي خضعت لـ fine-tuning فتقوم بدمج المعرفة داخل الأوزان. وتنتج إجابات بليغة ولكن دون مصدر يمكن التحقق منه. بالنسبة للقطاعات الخاضعة للتنظيم والرقابة (القانونية، الطبية، المالية)، لا يعد هذا خياراً مقبولاً للامتثال — بل يمثل مسؤولية قانونية (liability).
النموذج الذي تمت تهيئته بالـ fine-tuning ويجيب بثقة دون ذكر أي مصدر هو أكثر خطورة من نموذج يقول "لا أعرف". التوثيق المدمج في التصميم (Citation-by-design) هو القوة الخارقة لنظام RAG.
3. هل خصوصية البيانات شرط صارم؟
يبقي نظام RAG مستنداتك داخل بنيتك التحتية الخاصة — مثل نسخة مستضافة ذاتياً من Qdrant أو pgvector خلف جدار الحماية الخاص بك. ولا يرى الـ LLM سوى المقطع المسترجع فقط، وليس كامل مجموعة بياناتك (corpus).
بينما يتطلب الضبط الدقيق (Fine-tuning) إرسال بيانات التدريب الخاصة بك إلى الجهة التي تدير عملية التدريب (OpenAI، أو مزودي سحابة الـ GPU، أو العنقود الحسابي الخاص بك). كل مستند تتدرب عليه يُكتب كحد أدنى في التخزين السحابي. وبالنسبة لأي بيانات محمية قانونياً، أو حساسة طبياً، أو مملوكة تجارياً، فإن هذا غالباً ما يكون عائقاً يمنع استخدام هذا الخيار.
راجع مقالنا حول تشغيل نظام RAG للإنتاج بالكامل محلياً (on-premise) للحصول على تفاصيل العتاد (hardware) ومكونات التقنية (stack).
4. ما هي طبيعة الأسئلة التي يطرحها المستخدمون؟
| نوع السؤال | الخيار الأفضل | السبب |
|---|---|---|
| البحث عن الحقائق: "ماذا تقول سياسة الاسترداد لدينا؟" | RAG | استرجاع مستند السياسة مباشرة |
| التلخيص والتركيب: "لخّص جميع حوادث الربع الثالث" | RAG + نافذة سياق أكبر | استرجاع تجميعي (Aggregate retrieval) |
| الاستنتاج (Reasoning): "هل هذا البند في العقد غير معتاد؟" | Fine-tune (أو few-shot) | أنماط الاستنتاج الخاصة بالمجال، وليست الحقائق المجردة |
| الأسلوب: "اكتب بنبرة هويتنا التجارية" | Fine-tune | النبرة والأسلوب هما مشكلة تتعلق بمساحة الأوزان (weight-space) |
| الأسئلة متعددة الخطوات (Multi-hop): "أي مورد لديه أفضل معدل تسليم في الوقت المحدد بناءً على معايير المخاطر لدينا؟" | RAG + وكلاء (agents) | الاسترجاع + سلسلة الاستنتاج (reasoning chain) |
الفكرة الجوهرية هنا: الضبط الدقيق (fine-tuning) يحسن أنماط الاستنتاج (reasoning)، وليس استدعاء الحقائق. إذا كان المستخدمون يسألون "ماذا يقول المستند X؟"، فلن يفيدك الـ fine-tuning. أما إذا كان المستخدمون بحاجة إلى قيام النموذج بـ الاستنتاج والتفكير في مفاهيم المجال بالطريقة التي يفعلها خبير أول، فإن الضبط الدقيق يمكنه سد هذه الفجوة.
5. هل لديك أكثر من 10,000 عينة مصنفة وعالية الجودة؟
الضبط الدقيق على بيانات مشوشة (noisy) أو شحيحة ينتج نموذجاً غير موثوق ويصعب تصحيح أخطائه (debug). الحد الأدنى التقريبي للمتطلبات هو:
- ▸الضبط الدقيق للتعليمات (Instruction fine-tuning) (السلوك، النبرة، التنسيق): 5,000 إلى 10,000 عينة.
- ▸معرفة المجال (Domain knowledge) (الاستنتاج في تخصص معين): 10,000 إلى 50,000 عينة.
- ▸الضبط القائم على التفضيل البشري (RLHF/preference tuning): أكثر من 1,000 زوج من التفضيلات، ولكنه يتطلب نموذجاً أساسياً خضع لـ SFT أولاً.
معظم المؤسسات لا تملك مجموعات بيانات منسقة ومجهزة بهذا الحجم. بينما لا يتطلب RAG بيانات مصنفة على الإطلاق — فقط مستنداتك الحالية.
مقارنة التكلفة الفعلية
بافتراض استخدام نموذج بحجم 7B parameters، وعملية ضبط دقيق واحدة، على AWS:
| بند التكلفة | RAG | الضبط الدقيق (Fine-tuning) |
|---|---|---|
| الإعداد الأولي | 500$ – 3,000$ عمل هندسي | 2,000$ – 8,000$ هندسة وبنية تحتية |
| حوسبة التدريب | 0$ | 150$ – 2,000$ لكل تشغيل |
| تحديثات المعرفة | إعادة الفهرسة (0$ – 50$) | إعادة التدريب (150$ – 2,000$) |
| الاستنتاج (Inference) | نفس تكلفة النموذج الأساسي | نفس تكلفة النموذج المعدل |
| الصيانة المستمرة | تحديثات الفهرس | دورات إعادة تدريب دورية |
| إجمالي التكلفة التقديرية للسنة الأولى | 1,000$ – 5,000$ | 5,000$ – 25,000$+ |
التكلفة الخفية للضبط الدقيق هي الاستثمار المستمر. بياناتك تتغير بمرور الوقت (data drifts)، والنموذج يحتاج إلى تحديث، وكل تحديث يتطلب عملية تدريب أخرى. في المقابل، تكلفة تحديث RAG هي مجرد عملية إعادة فهرسة تستغرق دقائق معدودة.
متى يتفوق الضبط الدقيق (Fine-tuning) فعلياً؟
لا تستبعد الضبط الدقيق تماماً. فهو يتفوق في حالات محددة وضيقة:
1. الاستنتاج الحرج من حيث زمن الاستجابة (Latency-critical) بدون ميزانية استرجاع. إذا كنت بحاجة إلى استجابات في أقل من 200 مللي ثانية ولا يمكنك تحمل وقت خطوة الاسترجاع (50-200 مللي ثانية)، فإن النموذج الذي تم ضبطه دقيقاً يجيب مباشرة من الأوزان دون الحاجة لرحلة ذهاب وإياب لقاعدة البيانات. حالة نادرة ولكنها حقيقية.
2. ضرورة اتساق الأسلوب والنبرة. مثل النصوص الموجهة للعملاء، نبرة الهوية التجارية، وتنسيق المستندات الخاضعة للوائح. السياق المسترجع عبر RAG لا يغير طريقة كتابة النموذج — بل يغير ما يقوله. ولتغيير كيفية كتابته، تحتاج إلى تغييرات على مستوى الأوزان (weight-level).
3. استدعاء الدوال (Function calling) وأنماط المخرجات المهيكلة. إذا كان تطبيقك يخرج دائماً مخطط JSON معيناً أو يتبع شجرة اتخاذ قرار صارمة، فإن الضبط الدقيق على هذا النمط يقلل من عبء هندسة الموجّهات (prompt engineering) ويحسن الموثوقية بشكل أكبر مما يفعله RAG.
4. امتلاكك فعلياً لأكثر من 50 ألف عينة منسقة. يمكن لبعض المؤسسات التي تمتلك ميزانيات ضخمة لتصنيف البيانات (مثل مراكز الاتصال، والشركات القانونية التي تمتلك قواعد بيانات قضايا مهيكلة) بناء نماذج خضعت لضبط دقيق تتفوق على RAG في توزيع الاستعلامات الخاص بها.
البنية الهجينة (معظم الأنظمة الإنتاجية)
عملياً، تستخدم أنظمة الذكاء الاصطناعي المتطورة في المؤسسات كلا النهجين معاً:
- ▸نظام RAG لربط الإجابات بالحقائق (factual grounding) — استرجاع السياق ذي الصلة في وقت الاستعلام.
- ▸نموذج خاضع للضبط الدقيق لاستنتاج المجال (domain reasoning) — يفهم النموذج منطق مجال عملك ويطبقه على السياق المسترجع بشكل صحيح.
هذا النظام أكثر تكلفة في البناء ولكنه يعطي أفضل النتائج للاستعلامات المعقدة. فكر في RAG كطبقة الاسترجاع (retrieval layer) وفي الضبط الدقيق كطبقة الاستنتاج (reasoning layer).
في Verel Systems، نبدأ كل مشروع معرفي للمؤسسات بنظام RAG. وإذا حددنا بعد النشر فجوات استنتاجية معينة لا يمكن للاسترجاع حلها، فإننا نقوم بتصميم طبقة ضبط دقيق مستهدفة فوقه.
قائمة التحقق العملية لاتخاذ القرار
قبل اجتماع التخطيط القادم، أجب عن هذه الأسئلة:
- ▸ هل تتغير معرفتنا أكثر من مرة في الشهر؟ ← RAG
- ▸ هل يحتاج المستخدمون إلى التحقق من المصادر؟ ← RAG
- ▸ هل بياناتنا محمية قانونياً أو حساسة طبياً؟ ← RAG (محلي/on-prem)
- ▸ هل يطرح المستخدمون أسئلة من نوع "ماذا يقول المستند X؟"؟ ← RAG
- ▸ هل لدينا أكثر من 10 آلاف عينة منسقة؟ ← ربما الضبط الدقيق (fine-tune)
- ▸ هل المشكلة في الأسلوب/النبرة وليست في الحقائق؟ ← الضبط الدقيق (fine-tune)
- ▸ هل زمن الاستجابة الأقل من 200 مللي ثانية شرط صارم؟ ← تقييم الضبط الدقيق (fine-tune)
إذا قمت بتحديد ثلاثة خيارات أو أكثر لصالح RAG: ابدأ ببناء نظام RAG.
الأسئلة الشائعة
هل يمكن لنظام RAG أن يهلوس؟ نعم، ولكن بطريقة مختلفة. بدون توليد مقيد (constrained generation)، يمكن للـ LLM أن يختلق معلومات حتى مع وجود السياق المسترجع. تضيف أنظمة RAG الإنتاجية قيوداً صريحة: حيث يتم توجيه النموذج للإجابة فقط من المقاطع المسترجعة، وتؤدي الاستجابات ذات الثقة المنخفضة إلى تفعيل خيار بديل مثل "لم يتم العثور عليها في قاعدة المعرفة". معدلات الهلوسة في أنظمة RAG المصممة هندسياً بشكل جيد أقل بكثير من استجابات الـ LLM العادية.
كيف هو أداء RAG مع المستندات الطويلة جداً؟ يعتمد هذا على استراتيجية تقسيم المقاطع (chunking). تقسيم المقاطع التقليدي ذو الحجم الثابت في المستندات الطويلة يفقد السياق عبر حدود المقاطع. النهج الأفضل يتضمن: التقسيم الدلالي (semantic chunking)، علاقات المقاطع الأب والابن (parent-child chunk relationships)، والاسترجاع الهجين الكثيف والناثر (hybrid dense+sparse retrieval). مستند مكون من 500 صفحة سيعمل بشكل ممتاز مع خط المعالجة (pipeline) المناسب.
ما هي قاعدة بيانات المتجهات (vector database) التي يجب أن أستخدمها؟ لمعظم عمليات النشر الإنتاجية: Qdrant (مستضافة ذاتياً، سريعة، وتدعم التصفية)، أو pgvector (إذا كنت تستخدم Postgres بالفعل وتريد تقليل الأجزاء المتحركة)، أو Pinecone (مدارة بالكامل، بدون عمليات تشغيلية). راجع مقالنا حول RAG للإنتاج للحصول على مقارنة مفصلة.
هل يعمل RAG مع البيانات المهيكلة (الجداول وملفات CSV)؟ نعم، باستخدام أدوات إضافية. يمكنك تضمين (embed) البيانات الجدولية كتمثيلات نصية واسترجاعها، أو الأفضل من ذلك: دمج RAG للنصوص غير المهيكلة مع طبقة SQL للبيانات المهيكلة، وتوجيه الاستعلامات إلى الخلفية المناسبة بناءً على النية المكتشفة (detected intent).