Elasticsearch 8.13 يسرّع البحث المتجهي ويضيف إعادة الترتيب عبر LTR

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

أسرع على مستوى المحرّك

التغيير الأول هو الانتقال إلى Apache Lucene 9.10. فـ Elasticsearch مبني على Lucene، ومن هناك يأتي تسريع البحث المتجهي. لا تحتاج إلى إعادة كتابة الاستعلامات أو إعادة فهرسة كل شيء من جديد: تحدّث الإصدار فتحصل على مكسب في سرعة استعلامات kNN. لا تتضمن الإعلانات أرقامًا محددة، لذا سيتعيّن عليك قياس التسريع على بياناتك الخاصة. وإذا كان بحثك بالتضمينات (embeddings) يصطدم بزمن التأخير، فابدأ بقياس الأداء على الإصدار الحالي والجديد باستخدام مجموعة الاستعلامات نفسها.

Learning to Rank: تمريرة ثانية على النتائج

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

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

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

موصّلات بلا جهد يدوي زائد

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

ما ينبغي أخذه في الحسبان

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

الخلاصة العملية

إذا كنت تستخدم Elasticsearch، فالخطة كالتالي:

• حدّث عنقودًا تجريبيًا وقِس زمن التأخير لاستعلامات المتجهات؛
• اجمع مجموعة من 50–100 استعلام نموذجي مع تقييمات الصلة وتحقق مما إذا كانت LTR تحسّن أعلى 10 نتائج؛
• أعد النظر في أدوات تحميل البيانات المكتوبة يدويًا: فقد يمكن استبدال بعضها بموصّلات جاهزة.

أما إذا كنت تختار للتو منظومة بحث لـ RAG، فإن الإصدار يُظهر الاتجاه: البحث الهجين وإعادة الترتيب واستقبال البيانات تجتمع في منصة واحدة. وبالنسبة للفرق الصغيرة، يعني ذلك عمل تكامل أقل وأجزاء متحركة أقل.