- ·نموذج التضمين يحول أي نص إلى قائمة أرقام (متجه) تتقارب فيها المعاني المتشابهة. وقاعدة بيانات المتجهات تخزن الملايين منها وتجيب عن سؤال 'ما الأقرب لهذا؟' في أجزاء من الثانية.
- ·السرعة تأتي من الفهارس التقريبية (HNSW): بدل المقارنة مع كل متجه، يقفز البحث عبر شبكة من الجوار ويفحص جزءاً صغيراً جداً.
- ·في 2026 الاختيار العملي قصير: pgvector داخل Postgres لمعظم الفرق (حتى نحو 50 مليون متجه)، وQdrant عندما تكون المتجهات هي العمل الأساسي، وMilvus فقط عند مئات الملايين.
لنبدأ من الفشل، لأن الجميع عاشه. زميل يطلب "العقد الذي فيه غرامة تأخير التسليم". تبحث في الأرشيف عن "غرامة". لا شيء. العقد يقول "تعويض عن تأخر الاستلام". المستند كان موجوداً دائماً؛ البحث هو الذي لم يرَ أن جملتين مختلفتين تعنيان الشيء نفسه. كل بحث بالكلمات يفشل هكذا، في كل لغة، ويفشل في العربية أكثر حيث يأخذ الجذر الواحد عشرات الصور. قواعد بيانات المتجهات وجدت لتحل هذا الفشل بالذات، وهي الذاكرة خلف كل نظام ذكاء اصطناعي جاد رأيته. إليك كيف تعمل، بشرح صحيح.
الخطوة 1: المعنى يصبح أرقاماً (التضمين)
نموذج التضمين شبكة عصبية لها عمل واحد: تقرأ نصاً وتخرج قائمة أرقام ثابتة الطول، عادة بين 768 و1,536 رقماً، تسمى متجهاً. التدريب علم النموذج أن يعطي المعاني المتشابهة أرقاماً متقاربة. "غرامة تأخير التسليم" و"تعويض عن تأخر الاستلام" يعطيان متجهين قريبين؛ أما "سياسة الإجازة السنوية" فتقع بعيداً. تخيلها خريطة بألف بعد بدل بعدين: كل جملة لها إحداثيات، والمسافة على الخريطة هي الفرق في المعنى. والصور والصوت والكود تضمن بالطريقة نفسها، ولهذا تشغل الآلية نفسها البحث في الصور والبحث في الكود.
الخطوة 2: مشكلة الجار الأقرب
الآن أرشيفك مليون متجه ويصل سؤال: ضمّن السؤال، ثم ابحث عن المتجهات المخزنة الأقرب إليه (القرب عادة هو تشابه جيب التمام، أي الزاوية بين المتجهين). الطريقة الساذجة تقارن مع المليون كله، وهي تعمل ودقيقة، لكنها تنهار عند عشرات الملايين من المتجهات وآلاف الأسئلة في الثانية. هذه بالضبط هي المشكلة التي تحلها قواعد بيانات المتجهات: بحث الجار الأقرب على نطاق واسع، وبسرعة.
الخطوة 3: الحيلة التي تصنع السرعة (HNSW)
الفهرس السائد هو HNSW (الشبكة الهرمية سهلة التنقل). تخيل المتجهات مدناً والفهرس شبكة طرق مبنية طبقات: طبقة عليا من طرق سريعة طويلة بين المناطق البعيدة، وطبقات أدنى من طرق إقليمية أقصر، وطبقة سفلى من شوارع محلية تربط الجيران الحقيقيين. يبدأ البحث على الطرق السريعة فيصل إلى المنطقة الصحيحة تقريباً في قفزات قليلة، ثم ينزل عبر الطرق الأقصر حتى يمشي في الشوارع المحلية حول الجواب. بدل فحص مليون متجه يفحص بضعة آلاف، ويجد الجيران الأقرب الحقيقيين في 95-99% من الحالات. هذه المقايضة المقصودة، ذرة من الدقة مقابل سرعة بألف ضعف، هي الروح الهندسية لقاعدة بيانات المتجهات كلها. ولها مقابض ضبط (كم طريقاً لكل مدينة، وكم يتوسع البحث) تبادل بها السرعة بالدقة في كل سؤال.
ماذا تفعل القاعدة الحقيقية غير الفهرس
بيئة الإنتاج تحتاج أكثر من الجار الأقرب. التصفية بالبيانات الوصفية: "أقرب العقود، لكن من هذا المورد فقط، وبعد 2024"، وعلى القاعدة تطبيقها دون تخريب أداء الفهرس. البحث الهجين: جمع تشابه المتجهات مع البحث الكلاسيكي بالكلمات، لأن الرموز الدقيقة مثل "INV-4471" يجب أن تطابق حرفياً. الضغط: تصغير المتجهات إلى ربع ذاكرتها بخسارة دقة لا تذكر تقريباً، وهو ما يحدد فاتورة الأجهزة. ثم البقية غير اللامعة: تحديث وحذف دون إعادة بناء الفهرس، ونسخ احتياطي، وصلاحيات وصول. الفهرس هو الروح؛ وهذه القائمة هي الوظيفة.
خريطة 2026، بالقياس
اقرأ الرسم بانتباه، لأن العمود الأبطأ هو الجواب الصحيح في العادة. pgvector يعيش داخل Postgres: مستنداتك وبياناتها الوصفية ومتجهاتها في قاعدة واحدة، ومعاملة واحدة، ونسخة احتياطية واحدة، وتصفية بلغة SQL، دون نظام ثانٍ تديره. والقياسات المنشورة هذه السنة تظهر Postgres مع إضافة pgvectorscale يجيب عن 471 سؤالاً في الثانية بدقة 99% على 50 مليون متجه، أي أضعاف ما ستحتاجه معظم الشركات يوماً. وشجرة القرار العملية في 2026 جملة واحدة: pgvector إن كنتم تشغلون Postgres وعندكم أقل من نحو 50 مليون متجه؛ وQdrant عندما يكون بحث المتجهات هو المنتج نفسه؛ وMilvus فقط عند مئات الملايين فعلاً.
سؤال الزميل الذي فتحنا به المقال يصبح: ضمّنوا الأرشيف مرة واحدة، وخزنوا المتجهات بجانب السجلات، فيرجع البحث عن "غرامة تأخير التسليم" العقد الذي يقول "تعويض عن تأخر الاستلام" في النتيجة الأولى، مع تصفية المورد. هذا هو الوعد كله: بحث يجد ما قصدته. وكل قطعة فيه تعمل على خوادمكم داخل شبكتكم.