عندما تقول شركة إنها تريد «شات بوت يعرف كل ملفاتنا»، فهي غالباً تصف مشكلة RAG من دون أن تسميها. الاسترجاع المعزز بالتوليد، أو RAG، هو أسلوب يجعل النموذج يبحث أولاً في مصادر محددة ثم يصوغ جواباً مستنداً إلى ما وجده. لكنه ليس زر رفع PDF ثم معجزة. نجاحه يعتمد على جودة الوثائق، طريقة التقسيم والفهرسة، صلاحيات الوصول، وكيف تعرض المصادر للمستخدم. هذا الدليل يشرح بناء RAG بالعربي للشركات الخليجية، من الحالة المناسبة إلى الاختبار والحوكمة.
الخلاصة التنفيذية
- RAG لا يدرّب النموذج على ملفاتك؛ يضيف خطوة بحث واسترجاع قبل الإجابة.
- المصدر المعتمد والبيانات الوصفية والصلاحيات أهم من اختيار قاعدة متجهات مشهورة.
- الإجابة الجيدة يجب أن تعرض رابطاً أو مقطعاً من المصدر، وأن تعترف عندما لا تجد دليلاً كافياً.
- ابدأ بسؤال واحد وفريق واحد، واختبر الدقة والاسترجاع والرفض، قبل ربط النظام بعمليات أو أدوات تنفيذية.
ما هو RAG، ولماذا لا يعد تدريباً للنموذج؟
RAG اختصار لعبارة Retrieval-Augmented Generation. عند وصول سؤال المستخدم، لا يعتمد النظام على ذاكرة النموذج العامة فقط. يبحث أولاً في فهرس لمصادر سمحت بها، ويختار مقاطع يحتمل أن تجيب عن السؤال، ثم يرسل السؤال وهذه المقاطع إلى النموذج ليكتب رداً. لذلك تستطيع تحديث سياسة أو دليل دون إعادة تدريب النموذج كله؛ يكفي أن تحدّث المصدر والفهرس وفق دورة العمل المناسبة.
هذه البنية مهمة لأن معلومات الشركات تتغير: إصدار منتج، سياسة سفر، شروط عقد، أو دليل تشغيل. تدريب نموذج على نسخة قديمة ليس طريقة عملية لتحديثها كل أسبوع. أما RAG فيفصل بين المعرفة المتغيرة والمحرك اللغوي. النموذج يظل مسؤولاً عن فهم السؤال وترتيب الجواب، بينما تبقى الوثائق هي المرجع الذي يمكن للمستخدم ومراجع المحتوى العودة إليه.
لكن RAG لا يجعل كل جواب صحيحاً. إذا استرجعت مقطعاً خطأ، أو مقطعاً ناقصاً، أو نسخة قديمة، فقد يكتب النموذج جواباً واثقاً لا يصلح للعمل. وإذا لم تسترجع أي دليل لكنه واصل الإجابة من معلوماته العامة، فقد يظن المستخدم أن هذا جواب الشركة الرسمي. لهذا نحتاج إلى تصميم الاسترجاع والرفض والمصادر، لا إلى برومبت يقول فقط «لا تهلوس».
متى تحتاج الشركة إلى RAG فعلاً؟
الحالة المناسبة ليست «لدينا ملفات كثيرة». الحالة المناسبة هي سؤال متكرر تكون الإجابة عنه موجودة في مصادر داخلية، ويضيع الموظفون وقتاً في العثور عليها أو يخاطرون باستخدام نسخة غير صحيحة. قد يكون ذلك دليل منتج لفريق المبيعات، سياسات موارد بشرية، إجراءات دعم، كتيبات تشغيل، أو قاعدة معرفة قانونية محدودة يراجعها المختصون.
لا تبدأ بـRAG إذا كانت المعلومات الأساسية غير مكتوبة أو لا يوجد صاحب عمل يعتمد النسخة الصحيحة. عندئذ سيجعل النظام الفوضى أسرع في الوصول، لا أكثر موثوقية. ابدأ بترتيب المعرفة: من يملك الوثيقة؟ هل لها تاريخ مراجعة؟ هل هناك نسخة سارية؟ هل يحتاج كل المستخدمين الوصول إليها؟ هذه الخطوات هي جوهر إدارة المعرفة بالذكاء الاصطناعي للشركات، وRAG هو طبقة تقنية تخدم هذا الجوهر.
كما لا تستخدمه للحكم النهائي في مجالات حساسة. يمكن لمساعد قانوني داخلي أن يعرض بنوداً محتملة من سياسة مع روابط، لكن لا ينبغي أن يقرر التزاماً تعاقدياً. ويمكن لمساعد موارد بشرية أن يشرح الإجراء من الدليل، لكنه لا يفصل في حالة موظف خاصة خارج السياسة. لا تختصر المساءلة في واجهة محادثة.
بنية RAG من ست طبقات يمكن للفريق فهمها
1. المصادر والملكية
هي الملفات والصفحات والبيانات التي توافق المؤسسة على استخدامها. أضف لكل مصدر مالكاً، نطاقاً، تاريخ مراجعة، درجة حساسية، وإذن وصول. لا تخلط السياسات الرسمية مع ملاحظات شخصية أو عروض قديمة، لأن الفهرس سيتعامل معها جميعاً كمرشحين للجواب.
2. الاستخراج والتنظيف
يُحوّل النظام PDF أو مستند المكتب أو صفحة الويب إلى نص قابل للبحث. يجب أن يعالج العناوين والجداول والصفحات والأخطاء الضوئية، لكن من دون فقدان الرابط إلى المصدر الأصلي. في الفواتير والعقود الممسوحة قد تحتاج خطوة استخراج متخصصة؛ راجع دليل OCR واستخراج المستندات لفهم الفرق بين قراءة الحروف وفهم الحقول.
3. التقسيم إلى مقاطع
لا ترسل ملفاً كاملاً لكل سؤال. يقسم النظام النص إلى أجزاء مع بعض التداخل والسياق. المقطع القصير جداً قد يفصل الاستثناء عن قاعدته، والطويل جداً يضعف دقة البحث ويستهلك سياقاً بلا فائدة. لا توجد قيمة سحرية لعدد الكلمات؛ اختبر نوع مستنداتك وأسئلة المستخدمين.
4. الفهرسة والاسترجاع
يمثل النظام المقاطع بطريقة تسمح بالبحث الدلالي، وقد يضيف بحثاً لفظياً تقليدياً. عند السؤال يسترجع المرشحين ثم يعيد ترتيبهم. يجب أن يحمل كل مقطع بيانات وصفية: المصدر، القسم، الإصدار، التاريخ، الدور المسموح، وربما اللغة أو المنتج. هذه البيانات غالباً ما تحل مشكلة جواب خاطئ أكثر من تبديل نموذج التضمين.
5. التوليد والاستشهاد
يحصل النموذج على السؤال والمقاطع المسترجعة وتعليمات واضحة: استخدمها فقط، أشر إلى المصدر، وقل إن لم يكن الدليل كافياً. لا تجعله يكتب رداً طويلاً قبل أن ترى جودة الاسترجاع؛ الصياغة الجميلة يمكن أن تخفي مصدرًا غير مناسب.
6. المراقبة والتحسين
سجل السؤال، المصادر التي استُرجعت، النتيجة، تقييم المستخدم، والحالة التي احتاجت تصحيحاً، مع تقليل تخزين البيانات الحساسة. بعد ذلك تعرف هل المشكلة في تقسيم المستند أو صلاحية الوصول أو سؤال مبهم أو مصدر قديم.
| طبقة العمل | سؤال المراجع | فشل شائع |
|---|---|---|
| المصدر | هل هذه النسخة معتمدة وحديثة؟ | فهرسة عروض قديمة مع السياسات |
| التقسيم | هل يبقى الاستثناء مع القاعدة؟ | مقاطع تقطع المعنى |
| البيانات الوصفية | من يحق له رؤية هذا المقطع؟ | تسرب نتيجة لمستخدم غير مخول |
| الاسترجاع | هل جلب أفضل دليل للسؤال؟ | نتائج متشابهة لفظياً لا موضوعياً |
| الإجابة | هل أشارت للمصدر وحدودها؟ | جواب واثق بلا دليل كافٍ |
| التقييم | هل نعرف سبب التصحيح؟ | قياس المحادثات بدلاً من الجودة |
العربية في RAG: ما الذي يحتاج عناية إضافية؟
العربية ليست ملفاً تقنياً واحداً. قد يأتي السؤال بالفصحى بينما يحتوي الدليل مصطلحات إنجليزية أو أسماء منتجات أو اختصارات، وقد يستخدم الموظف لهجة خليجية في البحث. كما تختلف كتابة الهمزات والتاء المربوطة والأرقام والتعريب بين المصادر. لا تفترض أن محركاً جيداً بالإنجليزية سيعالج هذه الحالات تلقائياً بالدرجة نفسها.
ابدأ بتنظيف محدود ومحافظ: وحّد الصيغ التي تؤثر في البحث، واحفظ النص الأصلي للعرض. أضف مرادفات للمصطلحات التي يستخدمها فريقك، مثل اسم المنتج بالعربية والإنجليزية، لكن لا تحوّل النظام إلى قائمة استبدال ضخمة تخفي النص. اختبر أسئلة عربية فصحى ولهجية، وأسئلة ثنائية اللغة، وسيناريوهات رقمية. إذا كانت النتيجة لا تعرض المصدر الصحيح، لا تعالج ذلك بوضع الإجابة النموذجية داخل البرومبت؛ أصلح الفهرس أو البيانات الوصفية.
اختيار قاعدة المتجهات أو مزود الاسترجاع: ابدأ بالأسئلة الصحيحة
يوجد عدد كبير من الأدوات، لكنه ليس أول قرار. اسأل: أين ستخزن الفهارس؟ كيف ستطبق صلاحيات المستخدم؟ هل تدعم الحذف والتحديث؟ هل تحفظ بيانات وصفية قابلة للتصفية؟ كيف تتعامل مع اللغة العربية؟ هل يستطيع الفريق مراقبة الاسترجاع؟ وهل يمكن تصدير بياناتك إن غيرت المزود؟
قد يبدأ فريق صغير بخدمة مدارة كي يختبر القيمة بسرعة، وقد تختار مؤسسة بيئة داخلية بسبب تصنيف البيانات. لا تقدم إحدى الطريقتين على الأخرى كقاعدة دائمة. إذا كانت مستنداتك حساسة، صمم أيضاً طريقة الوصول إلى النموذج وواجهة البحث. يمكن لتشغيل محلي مثل Ollama وLM Studio أن يكون جزءاً من المعمارية، لكنه لا يحل وحده مسألة فهرسة ملفات خاطئة أو منح مستخدم نتيجة لا يحق له رؤيتها.
كيف تضع الصلاحيات داخل مسار الاسترجاع؟
الصلاحية يجب أن تطبق قبل أن يصبح المقطع جزءاً من جواب النموذج. لا يكفي أن تقول للنموذج «لا تذكر المستندات السرية» بعد أن أرسلتها إليه في السياق. عند كل بحث، صفِّ المصادر أو المقاطع وفق دور المستخدم وفريقه وكيانه، ثم استرجع من المجموعة المتاحة فقط. راجع العمليات التي تنقل الملفات إلى الفهرس، لأن فشل الصلاحية هناك قد يكون أخطر من واجهة الدردشة نفسها.
احتفظ بقاعدة قابلة للتفسير: لماذا ظهر هذا المقطع لهذا المستخدم؟ ما المصدر؟ ما النسخة؟ ما الدور؟ واحتفظ بخيار إلغاء الوصول أو حذف المستند وإعادة الفهرسة عند انتهاء مشروع أو تغير عقد. هذه ليست تفاصيل ثانوية، بل أساس لمنظومة تتعامل مع معرفة داخلية. استخدم مبادئ حوكمة الذكاء الاصطناعي للشركات الخليجية لتحديد المالك والمراجعة وسجل القرار.
تعليمات جواب RAG داخلية مقترحة:
- استخدم المقاطع المسترجعة فقط في الحقائق المتعلقة بالشركة.
- اذكر اسم المصدر أو رابط القسم بجانب كل نتيجة مهمة.
- إذا تعارض مصدران أو لم يكن الدليل كافياً، قل ذلك بوضوح.
- لا تستنتج صلاحية أو التزاماً قانونياً أو مالياً من دون نص واضح.
- لا تعرض أي مقطع لا يملك المستخدم حق الوصول إليه.التقييم: كيف تعرف أن RAG يعمل؟
قس الأمر على مرحلتين: الاسترجاع ثم الإجابة. في الاسترجاع، هل ظهر المصدر الصحيح ضمن النتائج الأولى؟ هل احتفظ بالمقطع بالسياق اللازم؟ هل فشل بسبب لغة السؤال أو بيانات وصفية؟ في الإجابة، هل تعكس النتيجة ما يقوله المصدر؟ هل الاستشهاد صحيح؟ هل امتنع النظام عندما لا توجد معلومة؟
أنشئ مجموعة تقييم من أسئلة حقيقية مع مصادر مرجعية. ضمّن أسئلة لها جواب، وأسئلة لا يجب أن يجيب عنها النظام، وأسئلة فيها وثيقتان متعارضتان، وأسئلة تتطلب تحديد إصدار أو تاريخ. اجعل مراجعاً من صاحب المعرفة يقيم الجودة، لا فريق التقنية وحده. راقب أيضاً زمن الرد؛ جواب موثق بعد دقيقتين قد لا يخدم موظف دعم في مكالمة، لكن لا تضحي بالمصدر لأجل بضع ثوانٍ.
لا تجعل عدد المحادثات مؤشراً رئيسياً. قد يستخدم الناس الأداة كثيراً لأنها مثيرة، ثم يتوقفون عندما يكتشفون أن المراجع غير ثابتة. الأثر الأفضل هو انخفاض الوقت للوصول إلى جواب موثق، وتحسن الاتساق، وانخفاض التحويلات إلى خبير، مع بقاء قدرة الموظف على فتح المصدر.
معالجة التحديث والحذف: الاختبار الذي تنساه الفرق
اسأل منذ البداية: ماذا يحدث إذا تغيرت سياسة أو حُذف عقد أو انتهى مشروع؟ يجب أن يعرف النظام أن المصدر لم يعد صالحاً للاسترجاع، وأن يعيد فهرسة النسخة الجديدة، وأن يحتفظ بسجل مفهوم للنسخة التي استند إليها جواب سابق إذا احتجت إلى مراجعته. لا يكفي استبدال ملف في مجلد ثم افتراض أن المساعد نسي النسخة القديمة؛ يعتمد ذلك على آلية الفهرسة والتحديث في بنية مشروعك.
صمم مساراً واضحاً: يبلّغ مالك المصدر عن التغيير، يتحقق النظام من النسخة والمعرف، يعيد معالجة المقاطع المتأثرة، ثم يشغّل مجموعة اختبار صغيرة. وإذا كان المصدر حساساً أو حُذف حق الوصول إليه، يجب أن يتوقف الاسترجاع منه فوراً لا في المراجعة الليلية التالية. هذه التفاصيل تجعل RAG مناسباً لعمل مؤسسي متغير، لا مجرد عرض على مجموعة ملفات ثابتة.
ومن المفيد إبقاء زر أو مسار «أبلغ عن مصدر قديم». أحياناً يكتشف موظف المبيعات أو الدعم الخطأ قبل الفريق التقني. إذا جمعتم هذه البلاغات مع الأسئلة التي لم تجد إجابة، ستحصلون على قائمة تحسينات حقيقية للمحتوى بدلاً من تخمين أين فشل النظام.
خطة بناء أول نسخة خلال 45 يوماً
الأسبوع الأول: اختر نطاقاً واحداً ومصادره ومالكيه وأكثر 30 سؤالاً متكرراً. الأسبوعان الثاني والثالث: نظف المصادر، أضف البيانات الوصفية، وابن فهرساً أولياً. الأسبوع الرابع: اختبر الاسترجاع والإجابة على مجموعة مرجعية، وأصلح أخطاء التقسيم والنسخ القديمة. الأسبوع الخامس: فعّل صلاحيات المستخدم وسجلات المراجعة وتجربة محدودة. الأسبوع السادس: راجع النتائج مع المالك التشغيلي، ثم قرر التوسع أو التوقف أو تغيير الحالة.
لا تضف أدوات تنفيذية في النسخة الأولى. اجعلها «اقرأ، ابحث، واستشهد». عندما تثبت جودة المعرفة، يمكن أن تربط الوكيل بأداة مسودة تذكرة أو اقتراح خطوة، مع موافقة بشرية. عند هذه المرحلة يفيدك دليل MCP الآمن لفصل المعرفة عن الأفعال.
حدود صريحة تحافظ على ثقة المستخدم
ضع في الواجهة ما يعرفه المساعد وما لا يعرفه. إذا كانت المصادر تغطي سياسة السفر ولا تغطي التفسيرات القانونية، فقل ذلك. وإذا كان السؤال يتطلب معرفة حالة المستخدم الحالية في نظام آخر، فلا تدع المساعد يتظاهر بأنه يملكها. هذه الحدود تقلل الإحباط وتمنع أن يتحول الجواب السلس إلى بديل غير رسمي لخبير أو نظام سجل معتمد.
الخلاصة
RAG ليس قاعدة معرفة مسحورة؛ هو نظام بحث ومعرفة وحوكمة يستخدم نموذجاً لغوياً ليجعل النتيجة أسهل في القراءة. إذا كانت مصادر الشركة معتمدة وحديثة، واسترجاعك يراعي اللغة والصلاحيات، وإجابتك تشير إلى الدليل، فستحصل على مساعد عملي. أما إذا كانت الملفات فوضوية أو لا يملكها أحد، فابدأ بتنظيم المعرفة قبل أن تزيدها طبقة ذكاء اصطناعي.
أسئلة شائعة
هل RAG أفضل من تدريب نموذج خاص؟
للمعرفة التي تتغير باستمرار، غالباً يكون RAG أسهل في التحديث والتدقيق. التدريب قد يناسب أهدافاً أخرى، لكنه لا يحل تلقائياً مشكلة المصدر الحالي أو الصلاحية.
هل يمكن بناء RAG بالعربية؟
نعم، لكن يجب اختبار مستندات وأسئلة عربية حقيقية، مع الانتباه للمصطلحات الثنائية اللغة والبيانات الوصفية وجودة OCR إن وجدت ملفات ممسوحة.
هل RAG يمنع الهلوسة تماماً؟
لا. يقللها عندما تكون المصادر والاسترجاع والتعليمات جيدة، لكن يلزم اختبار الامتناع والاستشهاد ومراجعة الحالات الحساسة.
ما أول حالة استخدام؟
مجال صغير له مالك ومصادر معتمدة وأسئلة متكررة، مثل دليل منتج أو سياسات تشغيل محددة، وليس أرشيف الشركة كله.
هل أحتاج مطوراً لبداية RAG؟
التجربة البسيطة قد تبدأ بأداة جاهزة، لكن أي استخدام مؤسسي يحتاج شخصاً يفهم المصدر والصلاحيات والتحديث والتكامل، مع مالك تجاري يراجع جودة الإجابات والمخاطر التشغيلية دورياً.
