البنية التحتية للاسترجاع والمخازن المتّجهية

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

نحن محايدون تجاه المورّدين فيما يخص المحرّك. وممارستنا غير مرتبطة بمحرّك بعينه عبر Qdrant وMilvus وWeaviate وpgvector وElasticsearch kNN، وأيُّها نوصي به يعتمد على عدد متّجهاتك، وأنماط استعلاماتك، ومتطلبات تعدّد المستأجرين، وقدرتك التشغيلية.

من عرض تجريبي بـ 50 ألف متّجه إلى إنتاج بـ 200 مليون متّجه

الفجوة بين العرض التجريبي والنظام الإنتاجي هي بالكامل تقريبًا مشكلة بنية تحتية. يحمّل العرض التجريبي 50 ألف متّجه إلى Pinecone، وينفّذ استعلام تشابه جيب التمام، ويُرجع النتائج في 40 مللي ثانية. أما الإنتاج فلا يشبه ذلك إطلاقًا.

• 200 مليون متّجه و 500 استعلام في الثانية بشكل مستدام
• 15 بُعدًا لتصفية البيانات الوصفية ومستندات تُحدَّث كل ساعة
• ثلاثة فرق تتشارك عنقودًا واحدًا في ظل عزل صارم للمستأجرين

عند ذلك النطاق، ترفع طفرات دمج HNSW مؤشر P99 لديك إلى 800 مللي ثانية، ويتدهور الاستدعاء بصمت بعد أسبوع من التحديثات التدريجية، ولا يستطيع خط أنابيب التضمين مواكبة معدل تغيّر مستنداتك. هنا يكمن عملنا.

اختيار المحرّك تمرين قياس مرجعي، لا قرار علامة تجارية

يدّعي كل مورّد أداءً هو الأفضل في فئته؛ لكن القياسات المرجعية تروي قصة أكثر دقة. نحن لا نختار قاعدة بيانات من مصفوفة ميزات — بل نحمّل متّجهاتك الفعلية، وننفّذ استعلاماتك الفعلية بمرشحات بياناتك الوصفية الفعلية، ونقيس الاستدعاء عند قيم k ذات الصلة تشغيليًا إلى جانب زمن الاستجابة P50/P95/P99 تحت حمل متزامن.

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

خط أنابيب التضمين هو المكان الذي ينهار فيه الاسترجاع الإنتاجي فعليًا

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

• المعرفة القديمة — ثاني أكثر أعطال RAG الإنتاجية شيوعًا. يُحدَّث مستند في Confluence لكن الفهرس لا يزال يقدّم التضمين القديم. الحل هو مُشغّلات التقاط تغيّر البيانات (CDC) التي تُعيد التضمين تدريجيًا، لا إعادة الفهرسة الدفعية الليلية.
• المستندات الشبحية — يُحذف مستند مصدر لكن يبقى متّجهه، فيُرجع نتائج لمحتوى لم يعد موجودًا. ولأن المعاملات الذرّية عبر نظام مصدر الحقيقة والمخزن المتّجهي شبه مستحيلة في البُنى المنفصلة، فإننا نبني طبقات مطابقة تكتشف المتّجهات اليتيمة وتطهّرها.

يُعدّ اختيار نموذج التضمين أهم مما تدركه معظم الفرق، والتبديل لاحقًا مكلف: فإعادة تضمين 8 ملايين مستند عند الترقية من text-embedding-ada-002 إلى text-embedding-3-large تكلّف أيامًا من الحوسبة وتتطلب بنية كتابة مزدوجة لتفادي التوقّف. نحن نقيّم النماذج مقابل مجموعة استعلاماتك الخاصة بمجالك قبل أن تلتزم.

• Cohere embed-v4 — يتصدّر الاسترجاع متعدّد اللغات بسعر 0.01 دولار لكل مليون رمز (token) عبر أكثر من 100 لغة.
• Nomic Embed v2 — 137 مليون معامِل، يعمل على وحدة المعالجة المركزية (CPU)، بأفضل نسبة جودة إلى حجم في السوق.
• OpenAI text-embedding-3-large — خيار قوي متعدّد الاستخدامات.

يعتمد الخيار الصحيح على مزيج لغاتك، ومتطلبات زمن الاستجابة، وما إذا كان بإمكانك قبول الاعتماد على واجهة برمجة التطبيقات (API) أم أنك تحتاج إلى الاستدلال داخل المؤسسة.

دورة حياة الفهرس: المشكلة التشغيلية التي لا يحذّرك منها أحد

فهارس HNSW تتدهور — وهذا ليس خللًا بل واقع معماري. عند 160 مليون متّجه، تستغرق إعادة البناء الكاملة لـ HNSW 3–6 ساعات. تجعل التحديثات التدريجية بنية الرسم البياني دون المثلى وتقلّص الاستدعاء بمرور الوقت؛ وترفع أحداث الدمج زمن استجابة الاستعلام؛ وكل عملية إدراج-أو-تحديث وحذف ودمج مقاطع تُطلق عمليات إعادة بناء للفهارس الفرعية تستهلك وحدة المعالجة المركزية في الصيانة بدل خدمة الاستعلامات. المفاضلة لا مفرّ منها: فالانتقال من استدعاء 0.8 إلى 0.95 يزيد زمن استجابة HNSW بنحو 31%.

نحن نهندس إدارة دورة حياة تستوعب الاستيعاب المستمر دون فقدان الجودة:

• تدوير الفهرس بالأزرق-الأخضر (blue-green) — إعادة البناء على بنية تحتية منفصلة والتبديل ذرّيًا دون أي توقّف.
• بوابات تحقّق آلية من الاستدعاء — مقارنة مجموعة استعلامات ذهبية بالفهرس الحالي بعد كل عملية كبرى؛ وإذا انخفض الاستدعاء دون العتبة، فلا يحدث التبديل.
• بناء HNSW المُسرَّع بوحدة معالجة الرسومات (GPU) في Qdrant وElasticsearch يقلّص أزمنة إعادة البناء بمقدار رتبة من حيث الحجم، وإن كان تنسيق متى يُعاد البناء وكيف يُتحقّق وكيف يُبدَّل هندسةً مخصّصة.

يمضي التكميم بهذا إلى أبعد من ذلك. يوفّر Qdrant الآن 1.5 بت و2 بت وغير المتماثل من التكميم، ويقلّل Elasticsearch BBQ الذاكرة الكومة (heap) بنسبة أكثر من 95% مقارنةً بـ float32. توفّر هذه الأساليب الذاكرة وتحسّن الإنتاجية، لكن لكل مخطّط ملفَّ استدعاء مختلفًا مقابل توزيعات بيانات مختلفة — لذا نحدّد أثر الاستدعاء على متّجهاتك المحدّدة قبل نشر التكميم في الإنتاج.

تعدّد المستأجرين والعزل على نطاق حقيقي

فرق المنصّات التي تخدم أكثر من 200 فريق تعلّم آلي داخلي، أو منتجات البرمجيات كخدمة (SaaS) التي تضم آلاف المستأجرين من العملاء، تحتاج إلى بنية تحتية تضمن العزل: يجب ألا تُرجع استعلامات المستأجر (أ) بيانات المستأجر (ب) أبدًا، ويجب أن تتتبع سجلات التدقيق كل استعلام إلى هوية مستأجر، وينبغي ألا يستهلك المستأجرون الخاملون الموارد التي يحتاجها المستأجرون النشطون.

• Weaviate — نموذج جزء واحد لكل مستأجر مع حالات للمستأجرين (نشط (ACTIVE)، وغير نشط (INACTIVE)، ومُفرَّغ (OFFLOADED) إلى S3) هو التنفيذ الأكثر نضجًا لعمليات النشر ذات أعداد المستأجرين المرتفعة.
• Milvus — يدعم العزل على مستوى قاعدة البيانات أو المجموعة أو القسم أو مفتاح القسم، بما يطابق مستوى التفصيل مع متطلبات امتثالك.

يتطلب كلاهما تنسيقًا مخصّصًا على النطاق الواسع — فتزويد المستأجرين، وانتقالات الحالة، وإدارة الحصص، وكشف التسرّب بين المستأجرين أمور لا تتولاها قاعدة البيانات نفسها. نحن نبني الطبقة التشغيلية التي تجعل تعدّد المستأجرين قابلًا للإدارة لعمليات النشر الخاضعة للتنظيم التي تتطلب الامتثال لـ SOC 2 أو ISO 27001 .

سير العمل الوكيلي يعيد تشكيل متطلبات البنية التحتية

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

لا توجد قاعدة بيانات متّجهية واحدة تتعامل مع طبقات الذاكرة الثلاث جميعًا بشكل جيد، لذا تجمع الفرق بُنى متعدّدة المخازن: Redis لحالة الجلسة، وQdrant أو Milvus للبحث الدلالي، و قاعدة بيانات رسم بياني لتتبّع العلاقات. نواة الذاكرة الموحّدة من Oracle (مارس 2026) تحاول توحيد الاستعلامات المتّجهية وJSON والرسم البياني والعلائقية والمكانية في محرّك واحد. نحن نصمّم طبقة الاسترجاع للأنظمة الوكيلة — أي المخازن تتعامل مع أي أنواع من الذاكرة، وكيف تُوجَّه الاستعلامات عبر المخازن، وكيف يبقى الاتساق قائمًا عندما يحدّث وكيل الحالة عبر خلفيات متعدّدة في خطوة استدلال واحدة.

ما نقدّمه

يبدأ كل ارتباط بـ مرحلة قياس مرجعي؛ نحمّل متّجهاتك، وننفّذ استعلاماتك، ونُصدر توصيات محرّك مُقاسة كمّيًا. ومن هناك نبني البنية التحتية الإنتاجية:

• عنقود المخزن المتّجهي، مع تخطيط السعة وأدلة تشغيل التوسّع.
• خط أنابيب التضمين، مع إعادة فهرسة تدريجية مُشغَّلة بـ CDC وإدارة إصدارات النماذج.
• أتمتة دورة حياة الفهرس، مع التدوير بالأزرق-الأخضر وبوابات التحقّق من الاستدعاء.
• طبقة تنسيق تعدّد المستأجرين، عندما تحتاج إلى عزل المستأجرين.
• حزمة القابلية للمراقبة، مع كشف الانحراف، وتنبيهات تراجع الاستدعاء، ومراقبة زمن الاستجابة P95/P99.
• أدوات الترحيل للفرق التي تنتقل بين المحرّكات، باستخدام تنسيقات Parquet وسيطة للحفاظ على التضمينات حيث تتطابق الأبعاد بدلًا من فرض إعادة تضمين كاملة.

نحن نحدّد نطاق كل ارتباط بـ توقعات شهرية صريحة لتكلفة البنية التحتية، لتعرف ما ستكلّفه عملية الإنتاج قبل أن تلتزم.