اختيار مخزن متجهات (vector store) للمستندات المالية

مخزن المتجهات (vector store) أقل أهمية من خطّ الأنابيب الذي يغذّيه. بالنسبة للاسترجاع المالي تحت بضعة ملايين من المقاطع (chunks)، عادةً ما يكون pgvector فوق قاعدة Postgres الموجودة لديك هو الجواب الصحيح: فهو يضع التضمينات (embeddings) بجانب البيانات الوصفية (metadata) التي تُرشّح عليها، ويحذف نظامًا من مخطّطك التشغيلي. تلجأ إلى مخزن مخصّص عندما يبدأ زمن بناء الفهرس أو الذاكرة أو تزامن الاستعلامات في التسبّب بالألم. هذا الاختيار يضبط زمن استجابتك وتكلفتك، لا دقّتك.

تلك النقطة الأخيرة هي حيث تنحرف معظم نقاشات الاختيار عن مسارها. تتجادل الفرق حول HNSW مقابل IVF، أو أي مزوّد مُدار لديه أسرع معيار استرجاع (recall benchmark)، بينما الجودة الفعلية للمقاطع المسترجَعة تُحسَم في المنبع بواسطة التقطيع، ونموذج التضمين، ومدى جودة إتاحة البيانات الوصفية لتحديد نطاق الاستعلام. فهرس مثالي فوق مستندات مقسّمة بشكل سيّئ يُعيد هراءً بثقة. لذا قبل مقارنة المخازن، كن صادقًا حول ما المخزن مسؤول عنه وما ليس مسؤولًا عنه.

عمّا يتحمّل المخزن المسؤولية فعلًا

يؤدّي مخزن المتجهات ثلاث مهام: يحتفظ بالتضمينات، ويجد أقرب الجيران التقريبيين (approximate nearest neighbors) بسرعة، ويُرشّح المرشّحين بواسطة البيانات الوصفية. في القطاع المالي، المهمة الثالثة هي التي يقلّل الناس من وزنها وهي التي تُعطِب المشاريع.

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

• الترشيح المسبق (Pre-filtering) يُضيّق مجموعة المرشّحين بالبيانات الوصفية أولًا، ثم يُجري بحث المتجهات على ما تبقّى. نتائج صحيحة، لكن إذا كان المرشّح انتقائيًا يصبح رسم HNSW البياني متناثرًا وينخفض الاسترجاع، أحيانًا بشدّة.
• الترشيح اللاحق (Post-filtering) يُجري بحث المتجهات أولًا، ثم يتخلّص من المرشّحين الذين يفشلون في المرشّح. سريع، لكن إذا كان مرشّحك انتقائيًا فقد تسترجع خمسين جارًا وتُبقي ثلاثة، فتفوتك المقاطع ذات الصلة تمامًا.

بالنسبة لبنك يسأل عن مَدين واحد من أصل أربعين ألفًا، فإن الترشيح اللاحق الساذج سيُعيد بهدوء لا شيء مفيدًا. أنت تريد مخزنًا يُتقن HNSW المُرشَّح (filtered HNSW)، بمعنى أنه يُقلّم اجتياز الرسم البياني وفق مُسنَد البيانات الوصفية بدلًا من تركيب المرشّح على أي من الطرفين. المسح الفهرسي التكراري (iterative index scan) في pgvector، والبحث المدرك للحمولة (payload-aware search) في Qdrant، والبحث المُرشَّح في Weaviate كلها تتعامل مع هذا؛ أما المخزن الذي لا يقدّم سوى الترشيح اللاحق فمستبعَد للاسترجاع المالي محدّد النطاق بغضّ النظر عن أرقام معاييره.

الصحّة الزمنية (point-in-time) ليست خيارًا

تُعاد صياغة المستندات المالية، وتُستبدَل، وتُصحَّح. يُعدَّل نموذج 10-K. لسياسة الائتمان نسخ. تُنقَّح ورقة الشروط أربع مرّات قبل التوقيع. إذا كان مخزنك عاجزًا عن الإجابة عن “ماذا كنا نعرف اعتبارًا من هذا التاريخ”، فقد بنيت آلة استشراف تُسرّب معلومات مستقبلية إلى إجابات عن الماضي.

هذا هو الانضباط نفسه الذي تطبّقه على مخزن الميزات (feature store)، مُنقولًا إلى الاسترجاع. بشكل ملموس، يعني ذلك أن يحمل كل مقطع على الأقل تاريخ سريان، وطابعًا زمنيًا للإدخال، ومعرّفًا لنسخة المستند، وأن يتمكّن كل استعلام من الترشيح عليها. لا يحتاج المخزن إلى ميزات زمنية مدمجة. يحتاج إلى ترشيح للبيانات الوصفية سريع وصحيح بما يكفي بحيث إن إضافة effective_date <= :as_of AND superseded_at > :as_of إلى كل استعلام لا تُحطّم زمن استجابتك. هذا المتطلّب يدفعك نحو المخازن ذات البحث المُرشَّح القوي، وهو سبب آخر يجعل إبقاء التضمينات في Postgres جذّابًا: المُسنَدات الزمنية تعيش في SQL الذي تثق به بالفعل، وتتبّع النسب (lineage) من المقطع رجوعًا إلى المستند المصدر هو عملية ربط (join)، لا نظام ثانٍ للتوفيق بينه وبين غيره.

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

البحث الهجين، لأن القطاع المالي يعمل على رموز دقيقة

المتجهات الكثيفة (dense vectors) جيّدة في المعنى وسيّئة في المعرّفات. المستندات المالية مليئة بمعرّفات يجب أن تتطابق بدقّة: أرقام CUSIP، وISIN، وLEI، ورموز التداول (tickers)، والمصطلحات المُعرَّفة، وأرقام الأقسام، وأرقام نقاط الأساس (basis points). ضمِّن “SR 11-7” وسيُبرز بحث المتجهات الصرف بكل سرور مقاطع عن مخاطر النماذج عمومًا بينما يفوّت المقطع الذي يُسمّي التوجيه بعينه. تلك فجوة استرجاع لا يُصلحها أي قدر من تحديث نموذج التضمين، لأن الإشارة معجمية (lexical)، لا دلالية (semantic).

لذا ابنِ البحث الهجين منذ البداية. تُجري استرجاعًا كثيفًا جنبًا إلى جنب مع استرجاع متناثر أو قائم على الكلمات المفتاحية (BM25، أو نموذج متناثر مُتعلَّم مثل SPLADE) وتدمج النتائج، عادةً بدمج الرتبة المتبادل (reciprocal rank fusion). عندما تُقيّم مخزنًا، تحقّق ممّا يمنحك إياه هنا:

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

يأتي Weaviate وQdrant بالبحث الهجين أصليًا. يمنحك Postgres نصًا كاملًا عبر tsvector بجانب pgvector وتدمج في كود التطبيق، وهو عمل أكثر لكنه يُبقي كل شيء في مكان واحد بنموذج اتساق واحد. أما Elasticsearch وOpenSearch فيأتيان من جهة البحث ويتعاملان الآن مع المتجهات باقتدار، ما يجعلهما معقولين إن كانت مؤسستك تُشغّلهما وتوفّر لهما الكادر بالفعل.

كيف يجري القرار فعلًا

رتّب الأسئلة بحيث تأتي المُستبعِدة أولًا. هل يُتقن HNSW المُرشَّح، بحيث تُحافظ الاستعلامات محدّدة النطاق على استرجاعها؟ هل يستطيع فرض الصحّة الزمنية عبر مُسنَدات بيانات وصفية سريعة؟ هل يدعم الاسترجاع الهجين بلا نظام ثانٍ؟ فقط بعد تلك، تصبح الأسئلة التشغيلية المألوفة مهمّة: زمن بناء الفهرس عند حجم مستنداتك، والبصمة الذاكرية (HNSW نهم للذاكرة، والتكميم (quantization) يقايض الاسترجاع مقابل الذاكرة)، والتوسّع الأفقي إن تجاوزت عقدة واحدة، وما إذا كنت تريد خدمة مُدارة أم استضافة ذاتية لأسباب تتعلّق بموطن البيانات (data residency) سيسأل عنها DORA وضوابطك الخاصة.

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