إذا كنت ترغب في مناقشة تجربتك، فلا تتردد في تحديد موعد محادثة عبر مكالمة نقدر أي ملاحظات
الميزات
بحث سريع
القدرة على البحث في المواضيع والمنشورات ورسائل الدردشة والمستخدمين
تشمل نتائج المنشورات والمواضيع الرسائل الخاصة
تشمل رسائل الدردشة القنوات الخاصة والرسائل المباشرة
عوامل تصفية قائمة على واجهة المستخدم لأشياء مثل العلامات والفئات والمستخدمين وصناديق الوارد والقنوات وما إلى ذلك.
أوضاع البحث بالكلمات المفتاحية، الدلالي، الهجين، و HyDE
أسئلة متكررة
يتوقف البحث عن العمل بعد فترة على الصفحة
بالفعل يتوقف؛ يرجى التحديث.
لا يدعم قواعد البحث الخاصة بنا، مثل @user أو #category
بالفعل لا يدعم، ولكن يمكن إضافته بسهولة إذا قررنا شحن هذا.
استهداف البحث عن المواضيع والمنشورات بشكل منفصل هو اختيار غريب
أفهم لماذا، خاصة إذا كنت معتادًا على كيفية عمل بحث Discourse على مدار العقد الماضي. إذا قررنا شحن هذا، يمكننا بناء وضع يقوم بكلا الأمرين في نفس الوقت، أو حتى تشغيل كليهما وعرضهما في واجهة المستخدم. بالنسبة لقيود هذه التجربة، كانت هذه أسهل طريقة لمعالجة كلتا حالتي الاستخدام:
أعرف أن هذا الموضوع موجود وأريد فقط العثور عليه (بحث الموضوع)
أريد البحث عن أي تكرار لهذا الاستعلام (بحث المنشور)
جودة النتائج ليست جيدة تمامًا
لم نلمس بالكاد ما هو ممكن هنا؛ في الوقت الحالي، نعطي الأولوية للفئات فقط ونعين أوزانًا للعنوان والنص. سيحتاج هذا إلى تعديلات إضافية لمطابقة التحسين الذي لدينا على البحث الحالي، ولكنه يجلب أيضًا إمكانيات الذهاب إلى أبعد من ذلك. للأسف، يتم التحكم في الكثير عبر واجهة برمجة تطبيقات JavaScript، والمكتبة التي نستخدمها أعاقتنا كثيرًا هنا.
البحث الدلالي / HyDE / الهجين بطيء
أضفنا تأخيرًا أكبر لتلك الأوضاع لتجاوز بعض الإزعاجات في مكتبة JavaScript التي نستخدمها. إذا قررنا شحن هذا، فإن مكتبة JavaScript هذه هي أول ما سيتم التخلص منه. أما بالنسبة للسرعة الإجمالية لتلك الأوضاع، فهي تعتمد على طلبين، الأول للتضمينات، والذي يعمل على أجهزة قديمة على AWS، وهذا لا يساعد. يمكننا أيضًا حقن التضمينات في وكيل الوسيط لتقليل الكمون. مرة أخرى، قيود وقت التجربة.
التفاصيل الفنية
تستخدم هذه التجربة Typesense، وهو استنساخ مفتوح المصدر لـ Algolia. إنه يعمل على مثيل EC2 في نفس مكان كل شيء آخر على استضافة Meta.
الواجهة الأمامية لا تطلب مباشرة من Typesense؛ بدلاً من ذلك، يتم تمرير جميع المكالمات عبر تطبيق Discourse، باستخدام وسيط Rack.
يستخدم شريط البحث / النتائج / عوامل التصفية InstantSearchJS مغلفًا في EmberJS. للأسف، تسببت هذه المكتبة في الكثير من المتاعب، ولن نستخدمها إذا قمنا بشحن هذا.
يستخدم الخادم 7.35 جيجابايت من ذاكرة الوصول العشوائي لفهرسة كل Meta. فقط ضع في اعتبارك أن معظم هذا بسبب التضمينات؛ سيكون أقل من 2 جيجابايت بدون تضمينات.
أعتقد أنه إذا واصلنا استخدام هذا المكون الإضافي، فقد يكون من المنطقي تعيين وضع “hybrid” كخيار افتراضي لأن الناس ليسوا معتادين حقًا على تبديل أنواع البحث بهذه الطريقة.
لقد جربتها بسرعة وأجدها واعدة. في الأيام الماضية، بحثت عن موضوع شريط المسؤول التجريبي وموضوع استعادة النسخ الاحتياطي من سطر الأوامر. في الحالة الأولى، استغرق الأمر بعض الوقت للعثور عليه في نتائج البحث، وفي الحالة الثانية، انتهى بي الأمر بالبحث في إشاراتي المرجعية. لكن البحث الجديد يعرض كلاهما وهو أسرع بكثير من البحث القديم. لذا بالتأكيد تحسين بالنسبة لي
مثير للاهتمام، لا أطيق الانتظار لاستكشافه أكثر! يبدو واعدًا حتى الآن!
هل يمكننا رؤية شيء مثل هذا يحل محل وظيفة البحث بالكامل في النهاية؟ بالإضافة إلى ذلك، هل ستكون هذه الأداة إضافة إلى أداة البحث الحالية في الشريط العلوي؟
تم إجراء هذه التجربة للبحث في جدوى إعادة بناء بحثنا من الألف إلى الياء وما هي المفاضلات لهذا النهج الجديد. في حين أنه من السابق لأوانه تحديد ذلك، إذا تم استقبال تجربة البحث الجديدة بشكل جيد بما فيه الكفاية، فيمكن حينئذٍ النظر في دمجها في العديد من ميزات البحث في Discourse، سواء كان ذلك بحثًا بصفحة كاملة، أو بحثًا مضمنًا في الرأس، أو بحثًا عن مواضيع مماثلة للمواضيع ذات الصلة، أو إشارات المستخدم، أو الإكمال التلقائي للهاشتاج، وما إلى ذلك.
هذا قابل للتنفيذ بسهولة باستخدام هذه التقنية، سواء على الجوال أو سطح المكتب، تمامًا مثل واجهة بحث Google.
الوضعيات موجودة فقط للتجربة حتى يتمكن الأشخاص من المقارنة والاختبار بسهولة، إذا تم شحنها، فستصبح الوضعيات خيارًا إداريًا على الأرجح، بدلاً من شيء يواجه المستخدم.
أحب أيضًا تجربة /filter والطريقة التي تعرض بها جميع خيارات التصفية الخاصة بي. لذلك يبدو أن هناك اتجاهين تم استكشافهما فيما يتعلق بالعثور على المحتوى. هل سيلعب هذان الاتجاهان معًا؟
ما من شأنه أن يبسط الأمور حقًا بالنسبة لي إذا كانت هناك لغة مشتركة في النهاية، لذلك كمستخدم سيكون لدي فهم مباشر لـ:
ما هو البحث؟ ما هو الفلتر؟
كيف يمكنني التعرف على كل منهما في الواجهة، وأين يجب أن أتوقع العثور على كل منهما؟
متى يتم تقديم مجموعة بسيطة/مشتركة من المرشحات لي؟ كيف يمكنني الوصول إلى المجموعة الكاملة/توسيعها؟
إذا لم تمانع في سؤالي، للسياق ولذلك أعرف بالضبط ما الذي أبحث عنه عندما أقوم بالاختبار:
ما الخطأ في البحث الحالي اليوم الذي تتطلع إلى تغييره أو تحسينه؟
ما الذي نقوم بتقييمه هنا بخلاف السرعة؟
إذا قررت إعادة بناء البحث من الصفر، فهل هناك فرصة لجعل بحث Discourse يبحث في أماكن أخرى للمحتوى؟ على سبيل المثال، المستندات غير المستضافة داخل Discourse؟
لدي قائمة طويلة أيضًا، لكنني أردت التأكد من أنني أقدم الأسئلة والفهم قبل أن أبدأ بالضغط
يسعدني حقًا رؤية الاهتمام بالتحسين. على سبيل المثال، بينما لا يزال هناك عمل يتعين القيام به، يُقال لنا باستمرار كم يحب مستخدمونا البحث لدينا (المعروف باسم بحث Discourse) عند مقارنته بتجارب البحث الأخرى التي لديهم، حتى مع غرائبه.
كعامل إلزامي، يستخدم فريقي حصريًا (على الأقل بين فريقنا) Discourse حصريًا للتواصل. كان هذا هو الطلب الأول من أحد أعضاء فريقي اليوم:
هذا شيء فكرنا فيه كثيرًا عند تجربة حل جاهز مثل Typesense. سيجعل من السهل جدًا توسيع نطاق بحثنا ليشمل “مستندات” خارجية، إما عن طريق السماح للعملاء بحقن المستندات في قاعدة بياناتنا أو السماح للواجهة الأمامية باستهلاكها من مثيلات أخرى تتبع بعض الإرشادات لتكون متوافقة.
من الجيد أننا حصلنا على هذين الأمرين بشكل صحيح من البداية مع التجربة! شكراً على ملاحظاتك.