BM25 مقابل RAG: لماذا يعطي البحث بالكلمات المفتاحية والبحث الدلالي إجابات مختلفة

يظل BM25 الآلية الأساسية للبحث في Elasticsearch و Lucene، لكنه يواجه قيوداً صارمة: فهو يفهم الكلمات وليس المعنى. في مقابل ذلك، يحل RAG مع التضمينات الموجهة مشكلة مختلفة—فهو يعثر على أجزاء ذات صلة حتى عندما لا تتطابق الاستعلام والوثيقة تماماً في الصيغة.

كيفية عمل BM25

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

آلية التشبع في تكرار المصطلح مهمة بشكل خاص. إذا ظهرت كلمة خمس مرات، فعادة ما ترفع الصلة بشكل ملحوظ؛ إذا ظهرت خمسين مرة، فالمكسب بالكاد يغير الصورة. تتحكم معاملة k1 في سرعة تفعيل هذا التشبع، بينما تتحكم معاملة b في مدى عقاب المستندات الطويلة. طبقة IDF (معكوس تكرار الوثيقة) تضخم الكلمات النادرة وتضعف الشائعة منها. لكن العيب الأساسي في BM25 لا يزول مع أي ضبط: الخوارزمية ترى النص كمجموعة من الرموز ولا تميز السياق أو ترتيب الكلمات أو المعنى.

حيث يتفوق RAG

البحث الموجه، الذي يقع عادة داخل خط أنابيب RAG، يعمل بطريقة مختلفة. يحول النظام المستندات والاستعلام نفسه إلى متجهات رقمية كثيفة من خلال نموذج التضمين، ثم يقارنها بالتشابه الكوسيني. في المثال من المقالة، يتم استخدام نموذج text-embedding-3-small من OpenAI بأبعاد 1536. يسمح هذا باستعلام حول "العثور على محتوى مشابه بدون تطابق كلمات دقيق" بإرجاع نص ذي صلة حتى إذا لم تظهر الكلمات الضرورية في الوثيقة على الإطلاق.

"لا أي من النهجين أفضل في كل شيء: فهما يخفقان في اتجاهات معاكسة."

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

الممارسة والحلول الوسط

تبني المقالة مقارنتها على عرض توضيحي بسيط في Python مع 12 جزءاً نصياً يغطي BM25 و TF-IDF و RAG والمحولات وDjango و PostgreSQL وموضوعات أخرى. بالنسبة لـ BM25، يتم استخدام مكتبة rank_bm25، وللتضمينات، يتم استخدام واجهة برمجية OpenAI وحساب التشابه الكوسيني القياسي. تُمرر الاستعلام نفسها بعد ذلك عبر كلا المسترجعين لترى أي أجزاء تصل إلى أفضل النتائج. يوضح هذا بوضوح: الأنظمة تجيب على سؤال واحد لكنها تصل إلى النتيجة من خلال إشارات مختلفة تماماً.

• يبحث BM25 عن الكلمات الدقيقة من الاستعلام ويشرح بسهولة السبب في ترتيب المستند أعلى.
• يبحث البحث الموجه عن المعنى ويمسك بشكل أفضل بالمرادفات والإعادة الصياغة.
• لا يتطلب BM25 وحدات معالجة الرسوميات أو نماذج أو استدعاءات خارجية.
• تتطلب التضمينات فهرساً منفصلاً واستدعاءات نموذج ومساحة لتخزين المتجهات.
• يجمع البحث الهجين بين كلا النهجين وأصبح المعيار للإنتاج.

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

ما يعنيه هذا

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