في الآونة الأخيرة، وبسبب التعليقات الداخلية، قررنا إعطاء الأولوية لمجموعة من التحسينات لخوارزمية البحث لدينا.
تم الآن طرح هذه التغييرات على جميع المواقع كجزء من Discourse 3.1.0.beta3. بعد التحديث، سيبدأ موقعك تلقائيًا في إعادة فهرسة جميع المحتوى الخاص بك للبحث.
هناك إعدادان جديدان للموقع كجزء من هذا، ولكن تم تعيينهما على قيم وجدنا أنها تعمل بشكل جيد في اختباراتنا هنا في meta، لذلك لا نتوقع أن يكون لدى معظم المواقع أي سبب لتغييرها.
إعطاء الأولوية لمطابقة المصطلح الكامل في العنوان على المطابقة الجزئية
يقوم Discourse بإجراء stem + prefix match عند البحث. يمكن أن يؤدي هذا أحيانًا إلى نتائج مفاجئة للغاية.
على سبيل المثال: redis يتم تقليصها إلى redi لذا يمكن أن يؤدي البحث عن redis إلى العثور على جميع الكلمات التي تبدأ بـ redi مثل redirect والمزيد.
تمت إضافة إعداد موقع مخفي جديد: prioritize_exact_search_title_match والذي تم تمكينه الآن افتراضيًا.
هذا يعني أنه إذا كنت تتذكر العنوان وكتبته، فمن المرجح جدًا أن تجد العنوان.
تقليل تكرار الفهرس الأقصى
تقوم خوارزمية التصنيف لدينا بترتيب المشاركات التي تحتوي على عدة مطابقات لمصطلح أعلى من المشاركات التي تحتوي على المصطلح مرة واحدة فقط. هذا يعني أنه يمكنك “الغش” في البحث عن طريق تكرار كلمة مرات عديدة. كلما كتبت الكلمة أكثر، كلما ارتفعت إلى أعلى نتائج البحث.
تمت إضافة إعداد موقع مخفي جديد SiteSetting.max_duplicate_search_index_terms والذي يبلغ افتراضيه 6.
بمجرد تطبيق هذا، فهذا يعني أنه إذا كتبت sam، 6 مرات أو 60 مرة في منشور، فسيظل ترتيبه كما هو. إنه يضع سقفًا للمكافأة التي يمكنك منحها للنتائج.
هذا التغيير له أيضًا تأثير أداء إيجابي، نظرًا لأن فهرس البحث يصبح أصغر قليلاً.
سابقًا، اعتمدنا بشكل كبير على مطابقات البادئة لعمليات البحث عن “النطاق”. مما يعني أن الكلمة happy لن تجد https://happy.com لأن happy يتم تقليصها إلى happi وتفشل مطابقة البادئة. تم إصلاح هذا (https://github.com/discourse/discourse/pull/20136).
العمل المستقبلي
نخطط للتجربة مع البحث “المشوش” لإكمال أسماء الإشارة تلقائيًا. (السماح لك بتخطي حرف على سبيل المثال)
نخطط للتحقيق في تقليل أولوية المصطلحات المكررة في العناوين. حاليًا، الموضوع المغلق hello goodbye hello له ترتيب أعلى من الموضوع المفتوحhello world
PageRank… نحن حاليًا لا نأخذ في الاعتبار عدد الروابط الداخلية الواردة عند ترتيب النتائج. هذا يعني أن بعض المواضيع المرتبطة بشكل لا يصدق يمكن أن تحتل مرتبة أقل من موضوع نادر مرتبط من لا مكان. سيكون من الجيد أخذ ذلك في الاعتبار في خوارزمية التصنيف لدينا.
لدينا مبادرة مفتوحة تبحث في عمليات تكامل الذكاء الاصطناعي، قد نتمكن من استلهام بعض الأفكار من أدوات مثل GPT.
ما يمكنك فعله للمساعدة؟
هل تلاحظ أي نتائج سيئة على meta؟ إذا كان الأمر كذلك، فيرجى تضمين المصطلح الذي بحثت عنه مع شرح سبب كون النتائج دون المستوى المطلوب.
فقط للتأكد… إذا قمت بتحديث/ترقية الإعداد الخاص بي، هل سأجد هذين الإعدادين؟ أعرف كيفية العثور على الإعداد المخفي، هذه ليست مشكلة — ولكن هل هما خاصان بـ Meta في هذا الوقت؟ بالنسبة لي، من الأسهل اختبارهما على دوائري بدلاً من هنا
لقد نظرنا في عمليات تكامل مختلفة بما في ذلك sphinx و melli و elastic و solr/lucene ولكنها تأتي بتكلفة. استضافة عملية أخرى لتشغيل الفهرسة، وخطر الفهارس القديمة، والتعقيد… إلخ، كلها ليست مجانية.
أود أن أرى مقدار الاستفادة التي نحصل عليها من PG قبل استكشاف أي خيارات أخرى والاحتفاظ بها كحل أخير.
مشكلة مثيرة للاهتمام للغاية، نعم، تم (وما زالت دائمًا) إعطاؤها الأولوية المنخفضة. أعتقد أنه يمكننا على الأقل النظر في إضافة إعداد موقع إلى discourse-solved للسماح للمسؤولين بتحديد ما يجب فعله في هذه الحالات (تحديد الأولويات/تقليل الأولويات/محايد إلخ).
للأسف، لا يتكيف PostgreSQL كمحرك بحث. وMeiliSearch يتمتع باستهلاك ذاكرة منخفض بشكل لا يصدق وإمكانيات بحث لا حصر لها. سيكون الحمل الزائد على الخادم مقارنة بـ Ruby غير مرئي ببساطة.
هذه ليست مشكلة بسيطة. يحتوي بحثنا على كميات هائلة من الأبعاد والكثير من المعلمات، وهو يتصل مباشرة بجداول postgres.
مع مزود بحث خارجي، نحتاج إلى القلق بشأن “المزامنة”.
يتم إغلاق موضوع في Discourse → إخطار المحرك
يتم حذف منشور → إخطار المحرك
يتم إجراء إعجاب → إخطار المحرك
يتم تقسيم موضوع أو دمجه → إخطار المحرك
القائمة تطول، بما في ذلك بناء فهارس متعددة (مستخدمون/منشورات/مواضيع/فئات)
ومع ذلك، بالاستثمار الصحيح، هذا ليس بالضرورة أمراً لا يمكن التغلب عليه، ولكنه مهمة ضخمة ولا يوجد دليل مفهوم يوضح مدى تحسنه. من الجيد أن لدى melli مصنف ترتيب للأخطاء المطبعية، والعديد من الميزات الأخرى لا جدال في ذلك. لكن دمجه ليس مجانياً على الإطلاق.
كتقدير تقريبي، أعتقد أن هناك حوالي 3 أشهر من العمل لبناء تكامل قوي ومتين في mellisearch. ربما حتى 6 أشهر إذا قمنا بتصميم Discourse بطريقة تجعل محرك البحث “قابلاً للتوصيل”.
لاحظ أننا ندعم تكامل algolia هنا: https://discourse.algolia.com/ إنه ليس قوياً تماماً، ويمكنك أن ترى أن البحث المتقدم بأكمله محذوف من التنفيذ.
بعد فترة سألت عن رأي أكثر المستخدمين نشاطًا لدي (فكروا) حول البحث — لم أخبرهم أبدًا أنه حصل على بعض الستيرويدات.
قال الجميع نفس الشيء بالضبط؛ لم يفكروا في الأمر ولكن لأنني سألتهم أدركوا أنهم وجدوا الآن نتائج ذات صلة بسهولة أكبر، وفي معظم الحالات على الفور،
جزء من Discourse يعمل كنظام تعليقات لـ WordPress. لا، لم أحصل على المزيد من التعليقات (لا شيء مبالغ فيه مثل التعليقات على المدونات) ولكنه أظهر وجود (هل هذه هي الطريقة الصحيحة لكتابتها؟) للمنتدى. في الوقت الحاضر لدي عدد قليل من المستخدمين الذين يستخدمون Discourse كمحرك بحث. لا يعلقون ولكنهم يبحثون عما يبحثون عنه من WordPress عبر مواضيع Discourse ويعودون إلى المدونة. بالتأكيد، نظام العلامات يساعد كثيرًا أيضًا. وتفتقر WordPress إلى كليهما: البحث الفعال والعلامات العاملة،
لا أعرف ما إذا كان يجب علي نشر هذا في Praise بدلاً من ذلك، ولكني أردت فقط أن أخبركم بأنني راضٍ جدًا عن كيفية عمل هذا البحث الجديد والمحسن.
عذرًا إذا كنت غبيًا - هل يجب أن يكون هذا نشطًا على المواقع المستضافة (مع آخر نشر)؟ يشير إعلان الإصدار إلى هنا، لكن هذا يتحدث عن إعداد مخفي - هل هذا الإعداد المخفي قيد التشغيل؟
لست متأكدًا مما إذا كانت هذه مشكلة من قبل، لكنني لاحظت ظهور العديد من المشاركات التي تم إنشاؤها بواسطة النظام في نتائج البحث. ربما تكون حالة هامشية أكثر وضوحًا هنا في ميتا، لكنني لا أتوقع أن تكون رسائل النظام ذات صلة بالبحث.
مثال للنتيجة عند البحث عن مصطلحات مثل “مغلق تلقائيًا”:
) حول البحث — لم أخبرهم أبدًا أنه حصل على بعض الستيرويدات.
شكراً لكم.