RAG للتطبيقات العربية: LLM + Vector Database + Object Storage على خادمك

تخيّل تطبيقًا يجيب موظّفيك أو عملاءك عن أي سؤال بالعربية اعتمادًا على مستندات شركتك أنت — عقود، سياسات، أدلّة منتجات، ملفات PDF — بدل إجابات عامة أو مختَلَقة. هذه هي فكرة Arabic RAG (الاسترجاع المعزّز بالتوليد للغة العربية): تجمع بين نموذج لغوي (LLM) قادر على الصياغة، وقاعدة متجهات (Vector Database) للبحث الدلالي، وتخزين كائنات (Object Storage) للملفات الأصلية — والأهمّ أنك تشغّلها على خادمك الخاص فلا تغادر بيانات عملائك حدودك. في هذا الدليل نشرح البنية كاملةً، ونعرض تجربة بحث دلالي عربي حقيقية قِسناها على خادم مرام، ونحدّد بدقّة ما الذي يعمل على CPU وما الذي يحتاج GPU فعلًا.

ما هو RAG ولماذا يهمّ التطبيقات العربية؟

RAG اختصار لـRetrieval-Augmented Generation أي «التوليد المعزّز بالاسترجاع». المشكلة التي يحلّها بسيطة: النموذج اللغوي مهما كان قويًّا لا يعرف مستنداتك الخاصّة — لم يُدرّب عليها، وقد يختلق إجابة تبدو مقنعة لكنها خاطئة (ظاهرة الهلوسة). RAG يعالج ذلك بأن يبحث أولًا عن المقاطع الأكثر صلة بالسؤال داخل مستنداتك، ثمّ يُعطيها للنموذج كسياق ليصوغ منها إجابة دقيقة موثّقة.

بالنسبة للتطبيقات العربية تحديدًا، يصبح Arabic RAG ضرورة لا رفاهية:

• محتواك عربي وحسّاس: عقود، لوائح، أسئلة عملاء — لا يصحّ إرسالها إلى واجهة خارجية في الخارج.
• الدقّة الموثّقة: الإجابة تُبنى على نصّك أنت، فتستطيع أن تُرجعها إلى مصدرها بدل الاعتماد على «معرفة» النموذج العامة.
• التحديث الفوري: حين تتغيّر سياستك، تُحدّث المستند فقط — لا حاجة لإعادة تدريب نموذج مكلف.
• الاقتصاد: نموذج مفتوح المصدر على خادمك يُلغي فاتورة الاستدعاءات المتصاعدة لكل سؤال.

ملاحظة: RAG لا يعني تدريب نموذج من الصفر. النموذج يبقى كما هو؛ أنت فقط تُغذّيه بالمقاطع الصحيحة وقت السؤال. هذا ما يجعله عمليًّا وقابلًا للتطبيق على خادم واحد.

بنية Arabic RAG: من المستند إلى الإجابة

تتكوّن أي بنية RAG من مسارَين منفصلين زمنيًّا: مسار التجهيز (يُنفَّذ مرّة عند إضافة المستندات) ومسار الإجابة (يُنفَّذ لكل سؤال). فهم الفصل بينهما هو مفتاح تصميم النظام:

المسار الأول: تجهيز المستندات (مرّة واحدة)

1. الرفع والتخزين: تُرفع ملفاتك (PDF, Word, صور) وتُحفظ نُسخها الأصلية في Object Storage.
2. الاستخراج والتقطيع (Chunking): يُستخرج النصّ ويُقطَّع إلى مقاطع صغيرة متماسكة (فقرة أو بضع جُمل) ليسهل البحث فيها بدقّة.
3. توليد المتجهات (Embeddings): يحوّل نموذج التضمين كل مقطع إلى متجه رقمي يمثّل «معناه».
4. التخزين في Vector Database: تُخزَّن المتجهات مع نصوصها لتصبح قابلة للبحث الدلالي السريع.

المسار الثاني: الإجابة على السؤال (لكل استعلام)

1. يصل سؤال المستخدم بالعربية عبر واجهة الـAPI.
2. يُحوَّل السؤال نفسه إلى متجه بالنموذج ذاته المستخدم في التجهيز.
3. يبحث Vector Database عن أقرب المقاطع معنًى للسؤال (Top-K).
4. تُمرَّر هذه المقاطع مع السؤال إلى LLM ليصوغ إجابة عربية دقيقة مبنية عليها.

لاحظ أن Vector Database هي حلقة الوصل بين المسارَين: نكتب فيها أثناء التجهيز، ونقرأ منها أثناء الإجابة. هذا ما يوضّحه المخطّط أعلاه.

المكوّنات الثلاثة: تخزين وبحث وصياغة

تقوم بنية RAG على ثلاثة أعمدة، كلٌّ منها يؤدّي دورًا لا غنى عنه، وكلّها يمكن أن تعمل على بنيتك الخاصّة:

• Object Storage (تخزين الكائنات): يحفظ ملفاتك الأصلية بأمان وقابلية توسّع شبه لا محدودة. هو المصدر الذي تُبنى منه المتجهات ويُرجَع إليه عند الحاجة. أدوات: S3 وMinIO وWasabi.
• Vector Database (قاعدة المتجهات): قلب البحث الدلالي — يخزّن متجهات المقاطع ويجد الأقرب معنًى لسؤال المستخدم في أجزاء من الثانية. أدوات: pgvector وQdrant وMilvus.
• LLM (النموذج اللغوي): يأخذ السؤال والمقاطع المسترجَعة كسياق ويولّد إجابة عربية طبيعية. نماذج: Llama وMistral وQwen.

الجميل أن هذه المكوّنات مستقلّة: يمكنك البدء بـpgvector على قاعدة PostgreSQL موجودة أصلًا، وتأجيل الـLLM الثقيل حتى تحتاجه، والاعتماد على مساحة قرص عادية بدل Object Storage كامل في البداية.

كيف يعمل البحث الدلالي فعليًا؟

«البحث الدلالي» هو ما يميّز RAG عن بحث الكلمات المفتاحية التقليدي. الفكرة أن نموذج التضمين (Embedding Model) يحوّل كل نصّ إلى متجه من مئات الأرقام (مثلًا 384 أو 768 بُعدًا) بحيث تقع النصوص المتقاربة في المعنى قريبةً بعضها من بعض في هذا الفضاء الرياضي — حتى لو اختلفت كلماتها تمامًا.

مثال عربي: سؤال «كم يومًا لإرجاع المنتج؟» لا يشترك في كلماته مع مقطع «سياسة الإرجاع: يمكنك إرجاع المنتج خلال 14 يومًا»، لكن متجهَيهما متقاربان لأن المعنى واحد. البحث بالكلمات المفتاحية قد يفشل هنا؛ البحث الدلالي ينجح. القياس المستخدم عادةً هو تشابه جيب التمام (Cosine Similarity): كلّما اقترب من 1 كان المعنى أقرب.

-- في pgvector: إيجاد أقرب مقطعين معنًى لمتجه السؤال
SELECT content, 1 - (embedding <=> :q) AS score
FROM chunks
ORDER BY embedding <=> :q   -- <=> = مسافة جيب التمام
LIMIT 2;

💡 نصيحة: جودة نموذج التضمين للّغة العربية أهمّ من حجم الـLLM. نموذج تضمين متعدّد اللغات جيّد يجعل الاسترجاع دقيقًا، والاسترجاع الدقيق هو نصف نجاح RAG.

تجربة Arabic RAG حقيقية على خادم مرام

لأنّ الكلام النظري لا يكفي، شغّلنا تجربة Arabic RAG فعلية على أحد خوادم مرام: أدخلنا ستّة مقاطع من «مستندات شركة» افتراضية بالعربية (سياسة الإرجاع، ساعات العمل، الشحن، طرق الدفع، الضمان، الدعم الفني)، ولّدنا متجهاتها بنموذج تضمين مفتوح متعدّد اللغات، خزّنّاها في pgvector، ثمّ سألنا ثلاثة أسئلة عربية وقِسنا ماذا استرجع النظام وكم استغرق:

• سؤال «كم مدة إرجاع المنتج؟» ← استرجع مقطع سياسة الإرجاع بتطابق 0.827 خلال 25 مللي ثانية.
• سؤال «هل التوصيل متاح خارج بغداد؟» ← استرجع مقطع الشحن بتطابق 0.695 خلال 24 مللي ثانية.
• سؤال «ما مدة الضمان على الأجهزة؟» ← استرجع مقطع الضمان بتطابق 0.586 خلال 36 مللي ثانية.

في كل مرّة اختار النظام المقطع الصحيح دلاليًّا رغم اختلاف صياغة السؤال عن نصّ المستند — دون أي كلمة مفتاحية مشتركة أحيانًا. تحميل نموذج التضمين استغرق نحو 12.6 ثانية (مرّة واحدة عند الإقلاع)، وتوليد متجهات المقاطع الستّة استغرق 0.07 ثانية فقط، وكل عملية بحث بقيت تحت 40 مللي ثانية.

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

لماذا الاستضافة الذاتية؟ الخصوصية والتكلفة

يمكنك نظريًّا بناء RAG عبر خدمات سحابية جاهزة، لكن الاستضافة الذاتية على خادمك تحسم ثلاث نقاط حاسمة للشركات العربية:

• الخصوصية والسيادة: مستنداتك ومتجهاتها وأسئلة عملائك تبقى كلّها على خادمك — لا تُرسَل إلى طرف ثالث. هذا شرط أساسي للبيانات القانونية والطبية والمالية والحكومية.
• التكلفة الثابتة: بدل الدفع لكل استدعاء وكل توكن، تدفع ثمن الخادم فقط مهما كثُرت الأسئلة. مع النموّ يصبح الفرق آلاف الدولارات شهريًّا.
• التحكّم الكامل: تختار النموذج، وتضبط التقطيع، وتحدّد عدد المقاطع المسترجَعة، وتُحدّث المستندات فورًا — بلا حدود معدّل ولا سياسات مزوّد خارجية.

هذا امتداد طبيعي لفكرة امتلاك بنيتك التي تناولناها في استضافة نموذج ذكاء اصطناعي على خادم GPU خاص.

أي مكوّنات تختار؟

قاعدة المتجهات: pgvector أم Qdrant؟

pgvector امتداد لقاعدة PostgreSQL — الخيار الأمثل إن كنت تستخدم PostgreSQL أصلًا، لأنه يبقي بياناتك ومتجهاتها في مكان واحد مع معاملات SQL كاملة. يكفي لملايين المتجهات. أمّا Qdrant وMilvus فقواعد متخصّصة تتفوّق عند مئات الملايين من المتجهات أو الحاجة لفلترة metadata معقّدة. للأغلبية العربية اليوم، pgvector أبسط وأكفأ للبدء.

نموذج التضمين والـLLM

لنموذج التضمين اختر نموذجًا متعدّد اللغات يدعم العربية جيّدًا (مثل عائلة paraphrase-multilingual). للـLLM، النماذج المفتوحة مثل Llama وMistral وQwen تعطي جودة عربية جيّدة عند التشغيل المحلّي. ابدأ بنموذج تضمين ممتاز، وأجّل ترقية الـLLM حتى تتأكّد أن الاسترجاع دقيق.

طبقة التطبيق

تُبنى واجهة الـAPI عادةً بـFastAPI على VPS لأداء عالٍ وتزامن مريح، وتُخزَّن المتجهات في PostgreSQL كما شرحنا في MySQL أم PostgreSQL.

متطلبات الخادم: CPU مقابل GPU

أكثر سوء فهم حول RAG أنه «يحتاج GPU حتمًا». الحقيقة أدقّ — وزّعها على المكوّنات:

• Vector Database + البحث الدلالي: يعمل ممتازًا على CPU. كما أثبتت تجربتنا أعلاه، الاسترجاع تحت 40 مللي ثانية على خادم عادي.
• توليد متجهات التضمين: يعمل على CPU بسرعة مقبولة للأحجام المتوسّطة؛ ويتسارع كثيرًا مع GPU عند ملايين المستندات.
• Object Storage: لا يحتاج سوى مساحة قرص موثوقة وشبكة جيّدة — بلا GPU إطلاقًا.
• صياغة الإجابة بالـLLM الكبير: هنا وحده يصبح GPU مهمًّا لسرعة استجابة مقبولة، خصوصًا مع النماذج الأكبر.

💡 نصيحة: خطة عملية للبدء باقتصاد: شغّل التقطيع والتضمين والبحث الدلالي على VPS قوي بالـCPU، وابدأ بنموذج LLM صغير أو استدعاء خارجي للصياغة فقط، ثمّ انتقل إلى خادم GPU للـLLM حين يكبر الاستخدام. بهذا تمتلك 80% من قيمة RAG بأقلّ تكلفة.

خطوات البناء العملية

خارطة طريق مختصرة لبناء أول تطبيق Arabic RAG على خادمك:

1. هيّئ التخزين: جهّز Object Storage (أو مجلّدًا منظّمًا في البداية) لملفاتك الأصلية.
2. ركّب قاعدة المتجهات: فعّل امتداد pgvector على PostgreSQL وأنشئ جدول المقاطع مع عمود vector.
3. استخرج وقطّع: استخرج نصّ المستندات وقطّعه إلى مقاطع متماسكة مع حفظ مرجع كل مقطع لملفه الأصلي.
4. ولّد وخزّن المتجهات: مرّر كل مقطع عبر نموذج التضمين وخزّن المتجه مع النصّ في pgvector.
5. ابنِ الـAPI: نقطة نهاية تستقبل السؤال، تحوّله لمتجه، تبحث عن Top-K، ثمّ تمرّره للـLLM.
6. اربط الصياغة: صُغ prompt يضع المقاطع المسترجَعة كسياق ويطلب إجابة عربية موثّقة منها فقط.
7. قِس وحسّن: راقب دقّة الاسترجاع وزمنه، واضبط حجم المقاطع وعدد Top-K حتى تستقرّ الجودة.

للتوسّع لاحقًا، غلّف المكوّنات في حاويات وأدر التزامن كما في Kubernetes للمطوّر العربي. وللمراجع التقنية الموثّقة: pgvector وتوثيق PostgreSQL وQdrant ونماذج التضمين على Hugging Face.

الخلاصة

Arabic RAG ليس حلمًا بعيدًا بل بنية عملية تبنيها اليوم على خادمك: Object Storage لملفاتك، وVector Database للبحث الدلالي، وLLM للصياغة. وكما أثبتنا بأرقام مقيسة على خادم مرام، الجزء الأصعب — البحث الدلالي العربي — يعمل بكفاءة على CPU، فيبقى GPU مطلوبًا فقط لصياغة الإجابة النهائية. النتيجة: تطبيق يجيب عن مستنداتك بدقّة موثّقة، وبياناتك لا تغادر خادمك، وتكلفتك ثابتة مهما نمَوت.