قواعد المتجهات مقارنة عملية: pgvector أم Qdrant أم Chroma لتطبيق RAG؟

لو تبني تطبيق RAG (توليد معزّز بالاسترجاع) وتحتار بين قواعد المتجهات، الجواب المباشر لأغلب الشركات: ابدأ بامتداد pgvector فوق PostgreSQL الذي تستخدمه أصلاً، فهو يكفي عملياً حتى عدة ملايين متجه دون إضافة قاعدة بيانات منفصلة تزيد التعقيد والتكلفة. انتقل إلى Qdrant فقط حين تتجاوز عشرات الملايين من المتجهات أو تحتاج فلترة معقّدة عالية الأداء أو توزيعاً على عدة عُقد. أما Chroma فمكانه الطبيعي هو النماذج الأولية والتجارب السريعة على جهازك، لا الإنتاج الجاد.

القاعدة العملية في سطر: إن كان لديك PostgreSQL ولم تتجاوز مليونين إلى خمسة ملايين متجه، فلا تعقّد حياتك، pgvector يكفي ويعمل على نفس خادمك ونفس نسخك الاحتياطية. تحتاج قاعدة متخصصة حين يصبح البحث عن أقرب الجيران عنق الزجاجة الحقيقي في تطبيقك، لا قبل ذلك.

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

ما الذي تفعله قاعدة المتجهات أصلاً

في تطبيق RAG، تحوّل كل قطعة نص إلى متجه رقمي (embedding) بطول ثابت، مثلاً 768 أو 1536 رقماً. حين يسأل المستخدم، تحوّل سؤاله إلى متجه أيضاً، ثم تبحث عن أقرب المتجهات المخزّنة إليه لتسترجع النصوص الأوثق صلة وتمرّرها للنموذج اللغوي. جوهر المهمة إذن هو البحث عن أقرب الجيران بسرعة في فضاء عالي الأبعاد، وكل قواعد المتجهات تحلّ هذه المسألة عبر فهرس تقريبي مثل HNSW الذي يوازن بين السرعة والدقة.

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

جدول المقارنة العملي

المعيار	pgvector	Qdrant	Chroma
الطبيعة	امتداد على PostgreSQL	قاعدة متخصصة مستقلة	مكتبة/قاعدة خفيفة
الحجم العملي المريح	حتى ملايين قليلة	عشرات إلى مئات الملايين	مئات الآلاف
الفلترة مع البحث	جيدة عبر SQL	ممتازة ومحسّنة	أساسية
التوزيع على عُقد	محدود	مدمج	لا
سهولة التشغيل	الأسهل لو عندك PostgreSQL	خدمة إضافية تُدار	الأسهل للتجارب
النسخ الاحتياطي	مع قاعدتك نفسها	منفصل	ملفات محلية
الأنسب لـ	أغلب شركات RAG	مقياس ضخم وفلترة معقّدة	نموذج أولي

الميزة الحاسمة لـpgvector أنه يعيش داخل قاعدتك الحالية: نفس المصادقة، نفس النسخ الاحتياطي اليومي، نفس أدوات المراقبة، ونفس المعاملات (transactions). تقدر تدمج البحث المتجهي مع استعلامات SQL عادية في استعلام واحد، مثل "أقرب المستندات إلى هذا السؤال ضمن قسم المبيعات ولهذا العميل فقط"، وهذا يوفّر عليك تزامن بيانات بين قاعدتين.

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

حساب الذاكرة بسيط ومفيد قبل اختيار الباقة. المتجه بطول 1536 وبدقة float32 يحتل 1536 مضروبة في 4 بايتات، أي 6,144 بايتاً، قرابة 6 كيلوبايت. إذن مليون متجه بهذا الطول يحتاج نحو 6GB خام، يضاف إليها فهرس HNSW الذي يخزّن روابط بين المتجهات، وبمعامل ربط شائع يضيف قرابة 256 ميجابايت لكل مليون. الجدول يلخّص الحاجة حسب طول المتجه:

طول المتجه	حجم المتجه	مليون متجه (خام)	مع فهرس HNSW تقريباً
384	~1.5KB	~1.5GB	~1.8GB
768	~3KB	~3GB	~3.3GB
1536	~6KB	~6GB	~6.3GB

خلاصة عملية: مليون متجه بطول 768 يعمل بأريحية على باقة أعمال بذاكرة 8GB، وحتى بطول 1536 يبقى ضمن حدود مؤسسة بذاكرة 16GB. لو احتجت أكثر، خفض طول المتجه (نماذج 768 كافية لأغلب حالات RAG العربية) يخفّض الذاكرة إلى النصف مقابل float32، كما أن الكمّنة إلى نصف الدقة (halfvec) تقلّص الحجم إلى النصف مرة أخرى بخسارة دقة طفيفة. راجع الأسعار والباقات لموازنة الرام، فترقية 2GB بـ600 ريال تكفي غالباً لاستيعاب مئات آلاف المتجهات الإضافية.

متى تحتاج Qdrant فعلاً

Qdrant قاعدة ممتازة، لكنها تحلّ مشكلات لا يواجهها أغلب الشركات إلا متأخراً. انتقل إليها حين يتحقق أحد هذه الشروط:

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

لاحظ أن Qdrant خدمة إضافية تُدار وتُنسخ احتياطياً بمعزل عن قاعدتك، وهذا التعقيد ثمن مبرَّر عند الحجم الكبير فقط. لو لم تصل لهذه الشروط فأنت تدفع تعقيداً بلا مقابل.

ضبط فهرس HNSW يصنع الفرق

كثير من شكاوى "pgvector بطيء" سببها فهرس غير مضبوط لا حدّ القاعدة نفسها. فهرس HNSW يتحكم فيه معاملان أساسيان يوازنان بين سرعة البناء ودقة البحث واستهلاك الذاكرة:

• معامل الربط m: عدد الروابط لكل عقدة في الفهرس. رفعه يحسّن الدقة ويزيد الذاكرة وزمن البناء. القيمة الشائعة 16 تكفي أغلب الحالات، ويُرفع إلى 32 حين تكون الدقة أولوية قصوى.
• عمق البناء ef_construction: كم مرشّحاً يفحص الفهرس أثناء بنائه. رفعه يحسّن جودة الفهرس ويبطئ بناءه مرة واحدة فقط، فقيمة بين 64 و200 خيار متوازن.
• عمق البحث ef_search: يُضبط وقت الاستعلام لا وقت البناء، ويوازن مباشرة بين السرعة والدقة لكل بحث. ارفعه لو لاحظت أن نتائج قريبة مهمة تفوتك.

القاعدة العملية: ابنِ الفهرس بقيم متوازنة، ثم قِس معدل الاسترجاع الصحيح (recall) على أسئلة حقيقية من تطبيقك، وارفع ef_search تدريجياً حتى تصل لجودة مقبولة عند زمن استجابة معقول. لا تقفز إلى قاعدة أخرى قبل أن تجرّب هذا الضبط، فكثير من "بطء pgvector" يختفي بمجرد فهرس مضبوط.

البحث الهجين يرفع جودة RAG

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

تشغيل الثلاثة على خادم كلاود

كلها تعمل على خادم سحابي سعودي، والفرق في طريقة النشر:

• pgvector: ثبّت الامتداد على PostgreSQL القائم بأمر واحد، وأنشئ فهرس HNSW على عمود المتجهات. لا خدمة إضافية ولا منفذ جديد.
• Qdrant: شغّله عبر Docker من قالب استضافة الذكاء الاصطناعي، واحرص أن يستمع على الشبكة الخاصة لا على الإنترنت المفتوح.
• Chroma: الأسهل للتجارب، يعمل كمكتبة داخل تطبيقك مباشرة، مناسب لبناء نموذج أولي قبل الالتزام بحلّ إنتاجي.

وجود السيرفر في الرياض يعني أن زمن الاستجابة بين تطبيقك وقاعدة المتجهات نحو 8ms، وهذا مهم لأن كل طلب RAG يتضمن جولة بحث متجهي قبل استدعاء النموذج اللغوي، فالقرب الجغرافي يقلّص زمن الاستجابة الكلي المحسوس.

الخاتمة: قرار عملي

ابدأ بأبسط حلّ يكفي حاجتك اليوم لا حاجتك المتخيّلة بعد ثلاث سنوات. إن كان عندك PostgreSQL ولم تتجاوز بضعة ملايين متجه، فعّل pgvector على باقة أعمال أو مؤسسة وابنِ تطبيقك دون قاعدة إضافية. راقب زمن البحث فعلياً، وحين يصبح عنق الزجاجة رغم ضبط الفهرس، عندها فقط انتقل إلى Qdrant. استخدم Chroma للتجارب السريعة على جهازك، لا للإنتاج. هذا التدرّج يوفّر عليك تعقيداً وتكلفة مبكرة، ويترك لك حرية الترقية حين تحتاجها فعلاً. جرّب قالب استضافة الذكاء الاصطناعي للبدء في دقائق.