قواعد بيانات المتجهات: متى تحتاج واحدة فعلًا؟

سؤال يتكرّر عند أول نظام RAG: «أي قاعدة بيانات متجهات نختار؟» والجواب الذي يوفّر شهورًا: غالبًا لا تحتاج واحدة بعد.

ما الذي تفعله فعلًا

تخزّن متجهات وتبحث عن أقربها إلى متجه الاستعلام. البحث الشامل الدقيق تكلفته خطّية بعدد المتجهات، ولذلك تستعمل الأنظمة الجادة فهارس تقريبية — أشهرها HNSW [1] الذي يبني رسمًا متعدّد الطبقات يُقفز فيه نحو الجوار الأقرب بخطوات قليلة.

الكلمة المفتاحية هنا تقريبي: تكسب سرعة وتدفع من الاستدعاء. المعاملات (M, efConstruction, efSearch) هي مقبض هذه المقايضة، وضبطها بلا قياس تخمين.

ثلاثة خيارات وحدودها

القاعدة العملية التي أعمل بها: ابدأ حيث بياناتك. إن كان لديك PostgreSQL أصلًا، فامتداد المتجهات يوفّر عليك خدمة كاملة، ويجعل الترشيح المركّب (تاريخ + قسم + صلاحية) استعلامًا واحدًا بدل تنسيق بين نظامين.

ما يبرّر الانتقال فعلًا

ليس عدد المتجهات وحده. الأسباب الحقيقية:

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

ما يُنسى دائمًا: البيانات الوصفية

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

متى لا يهمّ اختيار المخزن أصلًا

في نموذج أوّلي بأقلّ من عشرة آلاف مقطع، أي خيار يعمل. أنفق وقتك على التقطيع والمجموعة الذهبية — أثرهما على الجودة أكبر بمراتب من اختيار المخزن.

قياس المخزن قبل الالتزام به

المقارنة بين المخازن تُحسم بأرقامك أنت لا بجداول المزوّدين. تجربة يوم واحد تكفي:

1. حمّل عيّنة تمثيلية — لا ألف متّجه بل عُشر حجمك المتوقّع على الأقل. سلوك الفهرس عند ألف متّجه لا يشبه سلوكه عند مليون.
2. قِس الاستدعاء لا السرعة وحدها. جهّز ثلاثين سؤالًا تعرف مسبقًا أيّ المستندات يجب أن تُسترجَع لها، واحسب كم مرّة ظهر المستند الصحيح ضمن أعلى خمس نتائج. مخزن سريع يُخطئ الاسترجاع أسوأ من بطيء يصيبه.
3. قِس تحت ترشيح حقيقي. شغّل الاستعلامات نفسها مع شرط على البيانات الوصفية يشبه شرط الإنتاج (مالك، أو صلاحية، أو نطاق تاريخ). هنا تفترق المخازن أكثر مما تفترق في البحث المجرّد.
4. قِس زمن إعادة بناء الفهرس. ستحتاجه في كل تغيير لنموذج التضمين، وهو رقم يُنسى حتى يصير عائقًا تشغيليًّا.
5. جرّب حذف مستند وتحديثه. الحذف الناعم الذي يترك المتّجه قابلًا للاسترجاع مشكلة امتثال لا مشكلة أداء.

اكتب الأرقام الخمسة في جدول واحد. القرار بعدها يصير واضحًا، أو يصير واضحًا أن الفرق لا يستحقّ الهجرة.

الأخطاء الشائعة

1. اختيار قاعدة متخصّصة قبل قياس الحجم الحقيقي.
2. استعمال فهرس تقريبي بمعاملات افتراضية بلا قياس الاستدعاء.
3. تخزين المتجه بلا النصّ، فيتعذّر عرض المصدر.
4. خلط متجهات من نموذجين مختلفين في فهرس واحد — نتائجه بلا معنى.
5. نسيان أن تغيير نموذج التضمين يفرض إعادة بناء الفهرس كاملًا.

الأسئلة الشائعة

هل pgvector كافٍ للإنتاج؟

لكثير من الأنظمة نعم: مئات الآلاف من المقاطع مع ترشيح SQL، وبنسخ احتياطية وصلاحيات تديرها أصلًا. الحدّ يظهر مع التوسّع الأفقي والأحمال الكتابية العالية.

كيف أقيس جودة الفهرس التقريبي؟

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

ما بُعد المتجه المناسب؟

يحدّده نموذج التضمين لا القاعدة. الأبعاد الأعلى تعني فهرسًا أكبر وبحثًا أبطأ، وبعض النماذج تدعم تقليص البُعد بأثر محدود على الجودة — قِسه قبل اعتماده.

المراجع

1. Malkov, Y. & Yashunin, D. Efficient and Robust Approximate Nearest Neighbor Search Using HNSW Graphs. arXiv:1603.09320
2. Johnson, J., Douze, M. & Jégou, H. Billion-scale Similarity Search with GPUs (FAISS). arXiv:1702.08734
3. Karpukhin, V. et al. Dense Passage Retrieval for Open-Domain Question Answering. arXiv:2004.04906
4. Gao, Y. et al. Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997