لقد قرأت الكثير هنا مؤخرًا ولاحظت أن مصطلحي “منشور” و"رد" يُستخدمان إلى حد ما بالتبادل.
لو تم ذلك، لنتج عنه عدد أقل من الأسئلة المزعجة عندما يستخدم شخص ما المصطلح الخاطئ من الاثنين في بحثه قبل طرح سؤاله بموضوع جديد (هههه، لقد حدث لي للتو: “حذف المنشور بعد” لم يُنتج نفس نتائج “حذف الرد بعد”…)
ومن هنا جاء سؤال موضوعي…
ردّ ومشاركة ليسا قابلين للتبادل بنسبة 100%. في معظم الاستخدامات التي نراها هنا في ميتا، هما كذلك، لكن ليس دائمًا.
أقترح مراجعة Understanding Discourse for new users الذي يصف ما هي المشاركة. الردّ هو أي مشاركة ليست المنشور الأصلي.
لكنني أفضل العثور على ما أبحث عنه حتى لو لم أعرف المصطلح الصحيح.
أما بالنسبة لأولئك المطلعين أكثر، ألا يزال لديهم خيار إجراء بحث صريح بوضع علامات اقتباس حول المصطلح المحدد الذي يهتمون به، على سبيل المثال “reply” 
شكرًا لك، سأقرأ ذلك، لكن هل يقرأ الكثير من الأشخاص ذلك قبل إنشاء مواضيع جديدة هنا؟
لذلك، قرأت “دليل المستخدم الجديد لـ Discourse” ولم أتمكن من العثور على أي تعريف صريح لكلمة “رد”.
ولكن كما أنني اقتبست منك أعلاه، فإن “الرد” هو بالضرورة “مشاركة”، لذا عندما يبحث شخص ما عن “مشاركة”، يجب أن تُعرض جميع تطابقات “الرد” أيضًا…
ما إذا كان البحث عن “رد” يجب أن يُظهر جميع إدخالات “المشاركة” يظل غير معروف أيضًا بعد قراءة ذلك الدليل.
لذلك، أود أن أظل أطلب تنفيذ طلب عنوان هذا الموضوع. (ولكن مرة أخرى، هذا مجرد رأيي)
الرد هو بالضرورة منشور، لكن بعض المنشورات ليست ردودًا، لذا فإن البحث عن ‘منشور’ لا يجب أن يضيف تلقائيًا مصطلح البحث ‘الرد’.
إذا تم تلبية تفضيلك، فسيؤدي ذلك إلى إزعاج مستخدمين آخرين مثلي يبحثون فقط عن ‘منشور’ وليس ‘رد’.
لكنك بالطبع على دراية كافية، ومن المرجح أن تستخدم مصطلح بحث صريح بدلاً من إزعاج الناس هنا بموضوع جديد حول سبب ظهور نتائج بحث كثيرة لكلمة ‘post’ في عمليات البحث عن ‘reply’.
بغض النظر عن دلالات المنشور/الرد، فإن إضافة مرادفات للبحث ليس أمرًا يمكن تكوينه في Discourse في الوقت الحالي.
حسنًا، هذا يجعلني أصمت 
لكن ربما يجب أن تكون هناك طريقة لإضافتها، فأنا أتوقع أنها قد تخفف العبء عن الأشخاص الطيبين الذين يردون على المبتدئين في هذا المنتدى الرائع 
في الواقع، أقوم بإجراء عمليات بحث عامة ثم أتبع الروابط ذات الصلة التي تتقاطع إلى حد ما مع ما أبحث عنه.
تتمتع محركات البحث بفكرة حول الروابط التي يتم متابعتها. لدى Discourse شيء مشابه. “الرسائل المقترحة” في نهاية الموضوع هي مصدر مثمر للمواضيع ذات الصلة غير المرتبطة مباشرة بمصطلحات البحث المحددة.
أعيد تصنيف هذا الطلب ضمن Contribute > Feature لأن طلب الميزة واضح بالنسبة لي. فهو يطلب إضافة واجهة في تجربة المستخدم (UX) لتعريف المرادفات المخصصة.
يدعم Postgres تقنياً المرادفات وفقاً للروابط التالية:
لذا، إذا كنت ترغب في الغوص بعمق في الجوانب التقنية، يمكنك ربط شيء ما اليوم، لكنني أتفق مع أن إضافة واجهة مستخدم (UI) تسمح للمشرفين بتعريف هذه المرادفات قد تكون فكرة مثيرة للاهتمام في وقت لاحق.
لا أضع عليه علامة pr-welcome لأنه أمر معقد ويستغرق وقتاً طويلاً لتحقيقه بشكل صحيح، مع احتمال أن تكون الفائدة منه محدودة.
من حيث الجدول الزمني، أعتقد أن هذا الأمر لن أتمكن من العمل عليه في العام المقبل، ومن المرجح أن أبدأ فيه خلال السنوات الخمس القادمة.
تهانينا دال 
لقد أجرينا تحديثًا لمصطلحاتنا (أصبح المستخدم الآن “عضو”) وقمنا بتحديث وثائقنا وفقًا لذلك، ولكنني أود أن أتمكن من جعل أي شخص يبحث عن المستخدم يرى تلقائيًا النتائج التي تذكر “عضو”. أي أفكار حول طريقة سهلة لتحقيق ذلك؟
CC: @michellefs
إنها مهمة صعبة إلى حد ما، يمكننا بناء إضافة تقوم بحقن المرادفات في البيانات المفهرسة - ولكننا نتحدث عن أي شيء يتراوح بين يوم واحد وخمسة أيام عمل.
أعتقد أن السؤال الكبير هنا هو مدى أهمية هذا الأمر بالنسبة لك؟ يمكن القيام بذلك ولكنه يتطلب بعض الاستشارات المخصصة من جانبنا.
لا أعرف شيئًا، ولكن أليس هذا مجرد مسألة تغيير النصوص من جانب التخصيص؟ أم أنني، كالعادة، أفهم خطأ تمامًا؟
أعتقد أن الأمل هو أن تكون هناك القدرة على التأثير على خوارزمية البحث بشكل غير مباشر من خلال أداة مثل مرادفات العلامات. ولكن لأي كلمات رئيسية داخل منشور (أو المنشور الأصلي، على الأقل).
مثال على حالة استخدام سيكون لأعضاء المجتمع/زوار الموقع الذين يبحثون عن عباراتهم العامية بدلاً من مصطلحات العلامة التجارية المماثلة. تعطي خوارزمية البحث الأولوية لمواضيع مختلفة جدًا. مثال على موقعنا سيكون البحث عن مواضيع “تطبيق سطح المكتب” مقابل “العميل الأصلي”.
فضولي لمعرفة ما إذا كانت وجهات النظر حول الأخطاء الإملائية قد تغيرت على مر السنين:
في Discourse-AI، بدأنا في تجربة البحث الدلالي. لا يزال هذا في مراحله الأولى ولا نزال نستكشف هذه الأنظمة.
استخدام نماذج اللغة الكبيرة لتحسين موجه البحث هو أيضًا نهج ممكن (وإن كان بطيئًا اليوم):
تم ذكر هذه التقنية هنا: GitHub - texttron/hyde: HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels
إلى جانب الأساليب المؤتمتة بنسبة 100٪
استراتيجيتنا العامة هنا هي التكرار. لدينا بالفعل “كلمات مراقبة” في المنتج، ولن أمانع في ميزة تضيف “مرادفات البحث” حيث تحدد الأخطاء المطبعية الشائعة والعبارات الشائعة التي ترغب في “حشوها”. إنه ليس عملًا مجدولًا ولكنه بالتأكيد شيء يمكنك النظر في رعايته.
هناك سابقة لهذه الميزة بالضبط في Postgres وفقًا لـ: https://www.postgresql.org/docs/current/textsearch-dictionaries.html#TEXTSEARCH-SYNONYM-DICTIONARY
المجال الآخر الذي أنا منفتح على استكشافه (أنا متحمس له فقط بدرجة فاترة) هو السماح بـ “بيانات وصفية” مخفية في المنشورات، حيث يمكن للمسؤولين حشو مصطلحات البحث. إنه غير مرئي للغاية وبشكل عام أوصي فقط بـ “حشو” الأعمال “بشكل صحيح” حتى لا يتم إخفاء الأشياء على سبيل المثال:
دلالي، ذو صلة، تحسين
هذه فكرة عبقرية بحتة، فهي تحل المشكلة الرئيسية للبحث المستند إلى التضمينات: إدخال المستخدم السيئ.
وهي تتطلب الحد الأدنى من التغييرات من إعدادنا الحالي، حيث تحتاج فقط إلى إضافة خطوة صغيرة “لإثراء” استعلام البحث 
في هذا الموضوع، هناك شيء آخر يمكننا القيام به وهو إجراء بحث هجين:
نحن نقوم بالفعل بشحن مُعيد ترتيب قادر للغاية في واجهة برمجة تطبيقات التضمينات الحالية لدينا تحت نقطة نهاية منفصلة، وهذا يحتوي على جميع القطع اللازمة لحدوث ذلك.
مثال هنا:
https://github.com/pgvector/pgvector-python/blob/master/examples/hybrid_search.py#L67-L70