pgvector — بحث متجهي داخل قاعدة البيانات التي تشغّلها أصلًا

ما هي pgvector؟

يعمل الاسترجاع بتحويل النص إلى قائمة أرقام — تضمين — وإيجاد أقربها إلى تضمين السؤال. وهذا يتطلب مكانًا لتخزين المتجهات وفهرسًا يستطيع البحث فيها بسرعة.

ويضيف pgvector ذلك بالضبط إلى PostgreSQL. فيصبح المتجه عمودًا في الصف الذي ينتمي إليه، ويصبح بحث التشابه جزءًا من استعلام SQL عادي — ما يعني إمكانية دمجه مع جملة WHERE في العبارة نفسها.

والنقطة الأخيرة هي المهمة عمليًا. فالاسترجاع الحقيقي نادرًا ما يكون تشابهًا خالصًا؛ بل «أقرب التطابقات، في هذا المستأجر، مما يجوز لهذا المستخدم رؤيته، من النسخة الحالية للمستند». وفي Postgres هذا استعلام واحد.

متى نختار pgvector

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

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

وكلما كان الترشيح بالمستأجر أو الصلاحية أو التاريخ جزءًا من الاستعلام — وهو دائمًا تقريبًا.

متى لا نستخدم pgvector

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

وحين لا يكون العميل على PostgreSQL ولا سبب لديه للانتقال.

ما الذي نبنيه بـ pgvector

استرجاع فوق مجموعات مستندات متعددة المستأجرين

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

بحث دلالي على كتالوج قائم

منتجات أو مقالات أو إعلانات قابلة للبحث بالمعنى لا بالكلمة المفتاحية، دون نقل الكتالوج خارج قاعدة البيانات التي يعيش فيها أصلًا.

كشف التكرار والتطابق التقريبي

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

توصيات محتوى ذي صلة

اقتراح المقال أو المنتج أو دراسة الحالة الأقرب معنًى لما يقرؤه أحد، محسوبًا في قاعدة البيانات بلا خدمة توصيات منفصلة تُشغَّل.

كيف نطلق مشاريع pgvector

مع فهرس HNSW مقاس على المجموعة الفعلية، وتتبع زمن الاستعلام عند المئين 95 من الإطلاق فيُقاس السقف لا يُخمَّن.

والتضمينات تُعاد توليدها آليًا حين يتغير النص المصدر، في المعاملة نفسها مع التحديث. فالتضمين القديم هو النسخة الصامتة من الإجابة الخاطئة.

مع اختيار استراتيجية التقطيع على مستنداتك الفعلية لا على افتراض. فحجم المقطع يحدد جودة الاسترجاع أكثر مما يحددها النموذج، والحجم الصحيح لدليل سياسات ليس الحجم الصحيح لكتالوج منتجات.

ما تكلّفك pgvector

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

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

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

أسئلة تُطرح علينا عن pgvector