قاعدة البيانات المتجهية
الاختيار يُحسم بالبيانات الوصفية، لا بسرعة البحث
اختيار قاعدة بيانات متجهية وتغذيتها بالبيانات
نشر فريق خدمة متجهية متخصصة لتخزين 12 000 مقطع. وبعد ستة أسابيع، صار لا بد من حصر البحث في المستندات المتاحة للمستخدم المتصل، بينما تقيم الصلاحيات في PostgreSQL. ولا توجد أي عملية ربط (join) بين النظامين. وانتهى الأمر بالفريق إلى جلب 200 نتيجة من الخدمة المتجهية، ثم الاستعلام من PostgreSQL لمعرفة أيّها مسموح به، ولم يُبقِ منها إلا ثلاث نتائج. تضاعف زمن الاستجابة ثلاث مرات، وانهار الاستدعاء (recall) كلما قلّت صلاحيات المستخدم، علمًا بأن 12 000 متجه كانت ستتسع في 50 ميغابايت فقط من الذاكرة.
يُقدَّم اختيار قاعدة البيانات المتجهية في الغالب على أنه مسألة أداء بحث. لكنه ليس المعيار الحاسم في أغلب المشاريع: فدون بضعة ملايين من المتجهات تكون جميع الخيارات سريعة بما يكفي. ما يحسم الأمر هو قدرتك على التصفية بالبيانات الوصفية، وعلى الحفاظ على الاتساق بين متجهاتك ومصدر الحقيقة لديك، وعلى حذف مستند حذفًا نظيفًا. فاختر على أساس هذه المحاور الثلاثة، لا على أساس اختبار سرعة.
المقاربات الثلاث ونطاق صلاحية كلٍّ منها
الفهرس في الذاكرة (NumPy وFAISS وhnswlib) هو الجواب الصحيح حتى نحو 100 000 مقطع. فالبحث الشامل في 100 000 متجه بأبعاد 768 يستغرق بضع عشرات من المللي ثانية في NumPy. لا خدمة تحتاج إلى تشغيل، ولا انجراف في الإصدارات، وتصحيح الأخطاء بالغ السهولة. أما الثمن فهو أن الفهرس يُعاد بناؤه عند كل إقلاع، ولا يمكن مشاركته بين عدة عمليات دون جهد إضافي.
التعليقات
التعليقات مدعومة عبر GitHub Discussions
سجّل الدخول باستخدام GitHub للمشاركة في النقاش