قواعد البيانات المتّجهة: مقارنة عملية

Chroma وQdrant وpgvector في حمل حقيقي — لا في صفحات التسويق.

الاختيار بين قواعد البيانات المتّجهة يُطرح عادةً كسؤال عن السرعة. في الاستعمال الحقيقي، السرعة نادراً ما تكون العامل الحاسم — الحاسم هو ما يحيط بها: الترشيح، والتحديث، والتشغيل.

ما الذي تفعله هذه القواعد فعلاً

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

pgvector — حين تكون بياناتك في Postgres أصلاً

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

الترشيح المصاحب هو المكسب الأكبر عملياً. «أقرب عشر وثائق من قسم المبيعات المحدّثة هذا العام» جملة واحدة هنا، وعملية معقّدة في نظام منفصل.

SELECT id, title
FROM documents
WHERE department = 'sales'
  AND updated_at > now() - interval '1 year'
ORDER BY embedding <=> $1
LIMIT 10;

Chroma — للبدء السريع والنماذج الأوّلية

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

حدوده تظهر عند الحجم وعند الحاجة إلى تشغيل إنتاجي بضمانات. ليس عيباً — هذا ليس ما صُمّم له. استعمله لتتعلّم شكل المشكلة، ثم قرّر.

Qdrant — حين يصير البحث هو النظام

يستحقّ الانتقال إليه حين يصبح البحث المتّجه جوهر المنتج لا ميزة فيه: ملايين المتّجهات، ترشيح معقّد، وحاجة إلى ضبط دقيق للمفاضلة بين الدقّة والسرعة.

الثمن نظام إضافي تشغّله وتراقبه وتنسخه احتياطياً. لا تدفع هذا الثمن قبل أن تحتاجه فعلاً.

ما يجب قياسه بدل السرعة الخام

• زمن إعادة الفهرسة بعد تحديث دفعة كبيرة — كثيراً ما يكون العنق الحقيقي
• سلوك الترشيح: هل يرشّح قبل البحث أم بعده؟ الفرق هائل في النتائج
• استهلاك الذاكرة عند حجمك المتوقّع بعد سنة لا اليوم
• سهولة الحذف: الوثيقة التي بطلت يجب أن تختفي فوراً من النتائج

توصيتنا العملية

1. إن كانت بياناتك في Postgres — ابدأ بـpgvector ولا تنتقل حتى يجبرك رقم
2. إن كنت تستكشف — Chroma حتى تتّضح المتطلّبات
3. إن صار البحث هو المنتج وتجاوزت الملايين — قيّم Qdrant بجدّية
4. في كل الحالات: اعزل طبقة البحث خلف واجهة بسيطة ليبقى التبديل ممكناً

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

التضمين قبل قاعدة البيانات

يقع كثير من الجهد على اختيار القاعدة بينما الأثر الأكبر في نموذج التضمين نفسه. القاعدة تجد الأقرب؛ ونموذج التضمين هو الذي يقرّر ما معنى «أقرب».

• اختبر نموذج تضمين يدعم العربية فعلاً لا اسماً — الفرق كبير
• ثبّت النموذج: تغييره يوجب إعادة فهرسة كل شيء
• خزّن اسم النموذج ونسخته مع كل متّجه
• قِس على أسئلتك: نموذج ممتاز عموماً قد يكون ضعيفاً في مجالك

القاعدة تُبدَّل في يوم؛ ونموذج التضمين يُبدَّل بإعادة بناء الفهرس كلّه. رتّب اهتمامك بحسب كلفة التراجع.

سنعيد القياس مع تغيّر الإصدارات. لكن القاعدة تبقى: اختر الأقلّ إضافةً لتعقيد التشغيل، ما دام يجتاز أرقامك.