إصدار المتجهات (embeddings) وإعادة الفهرسة دون توقّف الخدمة

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

الفخّ هو التعامل مع المتجهات كأنها بيانات دائمة. إنها ناتج مُشتقّ، كالثنائي المُصرَّف (compiled binary). مصدر الحقيقة هو مقاطعك (chunks) وبياناتها الوصفية؛ أما المتجهات فهي دالّة في تلك المقاطع وفي نموذج بعينه عند إصدار بعينه. وحين تتغيّر الدالّة يصير الناتج عتيقًا، كلّه دفعةً واحدة. الفِرَق التي تخزّن المتجهات دون تسجيل النموذج الذي أنتجها تكتشف هذا بالطريقة الصعبة أوّل مرّة تُرقّي فيها، عادةً حين تنهار جودة الاسترجاع فجأةً ولا يفسّر شيء في السجلّات السبب.

لماذا تفرض الترقية إعادة تضمين كاملة

لا يمكنك الردم التراكمي (backfill). لا يوجد ترحيل ذكيّ يعيد تضمين الوثائق التي تغيّرت ويترك البقيّة على حالها. فالمتجه الصادر عن text-embedding-3-large والمتجه الصادر عن نموذج أحدث لا يعيشان في الفضاء نفسه، بل كثيرًا ما لا يتّفقان حتى في الأبعاد (dimensionality)، ومسافاتهما الجيبيّة (cosine distances) تقع على مقاييس لا يمكنك مقارنتها. مزجهما في فهرس واحد يعني أن الاستعلام سيرتّب المقاطع بثقة استنادًا إلى ناتج عارض هو أيّ نموذج صادف أن ضمّنها. هذا هو المكافئ الاسترجاعي لمقارنة أسعار بعملتين دون سعر صرف.

لذا يفرض كل تغيير في النموذج قرارًا ينبغي أن تتّخذه عن قصدٍ لا أن تتعثّر فيه:

• تغيّر نموذج التضمين نفسه. يوقف مزوّد إصدارًا، أو تنتقل من نموذج مُستضاف إلى نموذج تشغّله داخليًّا لتقليص الاعتماد على أطراف ثالثة، وهو نوع مخاطر تركّز تقنية المعلومات والاتصالات (ICT concentration risk) الذي تتوقّع لائحة DORA من الكيان المالي أن يديره. إعادة تضمين كاملة.
• تغيّر استراتيجية التقطيع (chunking). حدود مختلفة أو أحجام نوافذ مختلفة تعني نصًّا مُدخَلًا مختلفًا، ومن ثمّ متجهات مختلفة. إعادة تضمين كاملة، وعادةً إعادة تقييم لجودة الاسترجاع، لأن التقطيع يحرّك الجودة أكثر مما يحرّكها النموذج.
• تغيّر المعالجة المسبقة (preprocessing). تبدأ بتجريد النصوص النمطيّة، أو تطبيع الجداول، أو حلّ أسماء الكيانات قبل التضمين. لقد تغيّر النص المُدخَل، فصارت المتجهات عتيقة.

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

امنح كل متجه مفتاح إصدار

كل متجه مخزّن يحتاج أن يحمل نسبًا (lineage) كافيًا للإجابة عن سؤال واحد: ما الذي أنتجك بالضبط؟ عمليًّا هذا مفتاح إصدار مضغوط مُلحق بكل متجه وبالفهرس ككل. نحن نسجّل أربعة أشياء:

• نموذج التضمين وسلسلة إصداره الدقيقة، لا اسمًا مستعارًا عائمًا (floating alias) يستطيع المزوّد إعادة توجيهه بصمت.
• استراتيجية التقطيع ومعاملاتها: قواعد الحدود، طول الرموز (tokens) المستهدف، والتداخل (overlap).
• إصدار مسار المعالجة المسبقة، كتجزئة (hash) أو وسم لشفرة التطبيع وحلّ الكيانات.
• الأبعاد ومقياس المسافة (distance metric)، بحيث يفشل أي عدم تطابق بصخبٍ وقت الاستعلام بدلًا من إعادة نفايات.

اجمع هذه في مُعرِّف واحد اسمه embedding_version واختمه على الفهرس. الآن يستطيع مسار الاستعلام أن يؤكّد أن المتجه الذي أنتجه للاستعلام والفهرس الذي يبحث فيه يتشاركان الإصدار نفسه. وإن اختلفا، يُخطئ الاستعلام بدل إعادة هراء معقول الظاهر. هذا التأكيد يكسب قيمته في المجال المالي. المقطع الخاطئ المُسترجَع لأن إصدارَي الاستعلام والفهرس انحرفا أحدهما عن الآخر هو تحديدًا عطل «الجملة الواثقة بالرقم الخاطئ»: خفيّ في العرض التوضيحي، باهظ في التدقيق.

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

التحويل: ابنِ إلى جوار القديم، ثمّ أثبت، ثمّ بدّل

إعادة الفهرسة دون توقّف هي نشر أزرق-أخضر (blue-green deployment) مطبَّق على المتجهات. أنت لا تعدّل الفهرس الحيّ في مكانه أبدًا. تبني فهرسًا جديدًا بجواره ولا تعيد توجيه الحركة إلا حين يستحقّ التبديل.

التسلسل الذي نتّبعه:

1. ابنِ الفهرس الجديد على البارد. أعِد تضمين المجموعة كاملةً في فهرس أو مساحة أسماء جديدة موسومة بـembedding_version الجديد. يجري هذا في الخلفية مقابل لقطة (snapshot) من المقاطع، ولا يمسّ الفهرس الذي يخدم الإنتاج قط. قد يستغرق ساعات، وهذا لا بأس به، لأن لا أحد ينتظره.
2. جمّد الفارق ووفّق بينه وبين الجديد. الوثائق التي دخلت أثناء عمل الردم تحتاج تضمينًا أيضًا. تتبّع أختام زمن الاستيعاب (ingestion timestamps) وضمّن ذلك الفارق في الفهرس الجديد قبل التحويل، كي لا تفوته آخر بضع ساعات من الإفصاحات (filings).
3. قيّم قبل أن يثق به أحد. شغّل مجموعة تقييم ثابتة من استعلامات حقيقية بمقاطع معروفة الصحّة على كلٍّ من الفهرس القديم والجديد. قارن الاستدعاء (recall) عند نطاق التحديد الإنتاجي والدقّة بعد إعادة الترتيب. إن لم يفُز النموذج الجديد أو يتعادل، توقّف هنا ولم تخسر شيئًا، لأن الفهرس القديم لم يتوقّف عن الخدمة قط. لا تُجرِ التحويل بناءً على معيار مزوّد أبدًا؛ قِس على مجموعتك.
4. بدّل المؤشِّر ذرّيًّا (atomically). التحويل تغيير مفرد لأيّ فهرس يقرأ منه مسار الاستعلام، راية تهيئة (config flag) أو مبادلة اسم مستعار. طلب واحد يقرأ الفهرس القديم؛ والذي يليه يقرأ الجديد. ولا توجد نافذة يرى فيها الاستعلام خليطًا.
5. أبقِ الفهرس القديم دافئًا للتراجع. احتفظ به مدّة محدّدة. إن انحرفت الدقّة بعد إعادة الترتيب أو تراجع زمن الاستجابة في الإنتاج، تعيد المؤشِّر إلى موضعه في ثوانٍ. ولا تستعيد ذاكرة الفهرس القديم إلا بعد أن يصمد الجديد، وهي بالنسبة لـHNSW المورد الباهظ.

لمجموعة كبيرة يمكنك القراءة الظلّيّة (shadow-read) قبل التبديل. أرسل عيّنة من الاستعلامات الحيّة إلى الفهرسين معًا، سجّل مجموعتَي النتائج، وقارن بينهما دون اتصال (offline). هذا يلتقط الانحدارات التي فاتت مجموعة التقييم، لأن حركة الاستعلامات الحقيقية أغرب دومًا من مجموعة تقييمك. راقب على وجه الخصوص استعلامات المُعرِّفات ذات الرموز الدقيقة، أرقام CUSIP وLEI ومراجع الأقسام، حيث يمكن لتغيير نموذجٍ كثيف (dense) أن يزيح السلوك بهدوء.

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