Would be pretty fantastic if suggested topics took topic titles and content into account. E.g. If reading a topic about the subject of ‘analytics’, then topics that contain similar content could be mixed into the current suggested results.
If this could be done efficiently, I’m confident this would be a sure win for increasing engagement for both new visitors and active users. Even if these suggestions only used the topic titles (instead of title + content).
I created a similar thread but it is locked.
Currently I have disabled this feature and replaced it with mine.
This is very complicated feature to build efficiently and the rabbit hole is enormous. At some point you start considering machine learning, and the rabbit hole goes deeper and deeper.
I see the appeal of using AI to determine related content, this can be very handy on support topics, which can almost be made “self service”. You post a question, ML picks up 10 candidates and just posts them as a reply you can either accept or delete. Similarly when anon hits something for support it is handy to show related content.
That said… gigantic enormous task. Not on our roadmap for next year. But @eviltrout is keen to experiment with AI/ML at some point and this is the type of project that could relate.
@codinghorror remains a massive fan of DJ random, cause he reckons it can outperform many many fancy algorithms (and it often does)
DJ random is fantastic, though we do gate it by time and category / tag — that matters.
مرحباً،
أنا جديد هنا، لذا آسف إذا كنتُ أكرر ما قيل سابقاً.
أتفق مع @sam بوجود تعقيدات، لكن من ناحية أخرى، أصبحت تقنية نمذجة المواضيع ناضجة جداً، وتوجد أدوات جاهزة ممتازة. لقد حللتُ في مشروع لي حديثاً حوالي 5 ملايين من عناوين و ملخصات براءات الاختراع؛ وتحليل آلاف المواضيع على موقعي الجديد الرائع Discourse سيكون أمراً يسيراً. وعلاوة على ذلك، قد تكون لمجتمعي الطاقة الكافية لجعل ذلك يحدث.
من الخبراء: أود الحصول على نصيحة حول ما إذا كان ينبغي لي التفكير في تصميم إضافة (plugin)، أم أن أفكر في التعديل على مصدر Discourse (الذي قمت بتحميله من GitHub)؟
وجدت هذا الموضوع حول استخراج مواضيع Discourse باستخدام Python، لكنني لم أتمكن من جعله يعمل بعد. شيء مشابه لذلك يجب أن يسمح لي بسحب البيانات خارجاً، وبناء النموذج، ليكون قابلاً للتحميل والاستعلام عنه لاحقاً.
معظم الأدوات الجيدة موجودة في Python، مجرد معلومة جانبية…
من الناحية الوظيفية، يناسب هذا الأمر بشكل أفضل لوحة “موضوعك مشابه لـ…” عند إنشاء موضوع جديد.
أوصي بالتأكيد باستخدام إضافة هنا بدلاً من العبث بالكود المصدري. فالاحتمالات ضئيلة للغاية بأن نتمكن من إصدار شيء مثل هذا في النواة الأساسية، لأن ذلك سيتطلب اعتمادًا ضخمًا على مكتبات بايثون، بالإضافة إلى واجهة مستخدم ضخمة للتدريب وما إلى ذلك.
هناك الكثير من العمل المتعلق بآليات التدريب وما شابه. هل يمكنك توضيح الآليات التي ستقوم بها للتدريب؟ وما هي النماذج الدقيقة التي تنصح باستخدامها؟ وماذا يحدث عندما يكون للموضوع 100 منشور؟ أو 1000 منشور؟
ما الذي ستستخدمه كإشارة، وما هي القوة التي ستمنحها لكل عنصر (مشاهدات/فئة/وسم وما إلى ذلك)؟
أنا معجب جدًا بهذا المشروع، لكنني أشعر بأنه مهمة ضخمة إلى حد ما.
هناك الكثير من العمل المتعلق بآليات التدريب وما إلى ذلك. هل يمكنك تقديم ملخص لآليات التدريب التي ستنفذها؟ وما هي النماذج المحددة التي توصي باستخدامها؟
تستخدم أدوات فريقنا حاليًا مكتبة gensim. تحتوي على واجهة قياسية لـ وحدة بايثون. وقد خضعت لاختبارات مكثفة لسنوات عديدة.
التكوين الذي يخطر ببالي هو:
من وقت لآخر (مثلًا مرة في الأسبوع؟ أو مرة في الشهر؟ حسب حركة المرور على المنتدى)، قم ببناء نموذج doc2vec:
doc2vec (من تنفيذ gensim) لبناء نموذج يربط كل مستند بمتجه في فضاء ذي أبعاد d. يجب عليك اختيار المعلمة الفائقة d من خلال التجربة؛ حيث تستخدم Google قيمة d=40 لنماذج براءات الاختراع لديها؛ ولا أعرف القيمة التي تستخدمها Google Scholar. عادةً ما أستخدم d=200. يمكن اعتبار كل بعد في الفضاء “ميزة” مرتبطة بالمحتوى الدلالي.
سيتم ذلك في وضع عدم الاتصال (Offline). ثم في وضع الاتصال (Online):
ماذا يحدث عندما يكون للموضوع 100 منشور؟ أو 1000 منشور؟
يتوسع الجزء غير المتصل (Offline) بشكل شبه خطي مع عدد المستندات، ولكنه يجب أن يكون قابلًا للإدارة جدًا لعدد يتراوح بين 10 آلاف و100 ألف مستند. حتى ملايين المستندات مقبولة لدفعات أسبوعية.
ماذا ستستخدم للإشارة، وما هي القوة التي ستمنحها لكل شيء (المشاهدات/الفئة/الوسم وما إلى ذلك)؟
في هذا السياق، تُفسّر “قوة الإشارة” للموضوع الجديد مباشرة على أنها (المقلوب) للمسافة بين تضمين الفضاء المتجهي للموضوع الجديد ومتجهات المستندات الموجودة. يمكن تزيين هذه الإشارة اعتبارات أخرى (مثل الإعجابات، المشاهدات، إلخ)، لكن هذه إضافات تجميلية للخوارزمية الأساسية التي أصفها.
بمجرد أن يعمل (أنا أو شخص آخر) عملية السحب (scraping)، فإن الجزء غير المتصل الموصوف أعلاه سهل وآلي إلى حد كبير.
الجزء الصعب (بالنسبة لي) سيكون الجزء المتصل (Online)، والذي سيتطلب ربط Rails الخاص بـ Discourse مع عدد قليل من استدعاءات بايثون (مثلًا لأدوات gensim). أي أمثلة على هذا النوع من الواجهات ستكون مفيدة جدًا لي لأراجعها.
@Bcat: سأكون مهتمًا جدًا برؤية كيف قمت بـ ‘استبدالها بالخاصة بك’. هل لديك إضافة أو مستودع يمكنني الاطلاع عليه؟
الجزء الصعب من حيث الأداء هو آلية RPC هنا. لا تريد إطلاق عملية بايثون جديدة لكل عرض موضوع.
حتى استدعاء HTTP قد يكون بطيئًا جدًا.
ربما … يمكن ملء جدول related_topics يحتوي على (topic_id, related_topic_id, rank)؟ عندها يمكنك الاعتماد على WebHooks لتحديث الجدول بسرعة عند نشر أشخاص مواضيع جديدة، ولن يحتاج Ruby إلى استدعاء Python.
من ناحية التنفيذ في جانب Discourse سيكون الأمر سهلًا جدًا، حيث ستقوم ببساطة بإعادة كتابة هذه الطريقة للبحث عن المعلومات في جدول related_topics الجديد.
الطريقة القديمة لم تنجح، لذا استبدلتها بإعلانات جوجل. المواضيع التي يقترحها جوجل ذكية جداً.
أما فيما يتعلق بالطريقة القديمة للقيام بالأمر، فقد قمت بإيقاف الاقتراح الافتراضي واستبدله بقطعة كود JavaScript تستدعي /search ثم تُرجع قائمة بالمواضيع.
شكرًا لك على التوجيه نحو تنفيذ الجدول. غير أني لست متأكدًا من أن نهج الجدول قابل للتوسع. بالنسبة لـ N موضوع، نحتاج إلى جدول بحجم N^2. إذن، بالنسبة لـ 10^4 موضوع، سيكون للجدول 10^8 إدخال.
لا أرى كيف يمكن تجنب الحاجة إلى استدعاء بايثون لتحليل موضوع جديد، وتضمينه، وإيجاد أقرب الجيران. لقد قمت سابقًا ببناء واجهة ويب، لكنني على الأرجح سأميل هنا إلى مجرد تشغيل عملية بايثون جانبية والتواصل مع discourse عبر مقبس أو أنبوب، بشكل يشبه إلى حد كبير القراءة والكتابة في ملف بدلاً من استدعاء بايثون فعلي. (بعد كل شيء، كل ذلك يعمل على خادمي…)
آسف، أعتقد أنني أسيء الفهم تمامًا هنا؟
إذا كان لديك 100 موضوع وكل موضوع يعرض 5 مواضيع ذات صلة، فلماذا يحتاج الجدول إلى أن يكون أكبر من 500؟
عدد المواضيع = N نقطة في تمثيل فضاء المتجهات.مصفوفة المسافات بين كل نقطة هي N^2. (المصفوفة متماثلة، لذا هناك N*(N-1)/2 قيمة مستقلة). هذا هو N^2 الذي كنت أشير إليه.لكن هياكل البيانات الذكية (مثل شجرة kd) تتيح إيجاد أقرب الجيران دون البحث بالقوة الغاشمة في جدول الفروقات المكون من N^2.على أي حال، أعرف كيفية القيام بكل هذا بلغة بايثون، مع إرجاع الجدول الصغير الذي تشير إليه، وهو N × 5 لأقرب 5 مواضيع.
ثم، إذا قمت بتشغيل ذلك يوميًا باستخدام بايثون، يمكنك ببساطة ربط بايثون مباشرة بقاعدة بيانات ديسكورش، مما يسمح لها بإنشاء جدول التخزين المؤقت هذا.
بعد ذلك، يصبح جزء إضافة ديسكورش تافهًا إلى حد ما. فبدلًا من الاختيار من الموقع X، يتم الاختيار من الموقع Y (جدول مختلف).
لن تحتاج بعد الآن إلى التعامل مع خطوط الأنابيب التي يجب أن تمتد بين لغتي برمجة مختلفتين لطلب واحد.
يبدو النهج الذي تم اقتراحه هنا مثيرًا للاهتمام وقد يكون الحل الأمثل.
أتساءل عما إذا كان الأمر يستحق النظر في نهج أقل تقنية - يمكن أن يحتوي قسم المواضيع المقترحة على زر “اقتراح موضوع”. سيسمح النقر على الزر للمستخدمين بنشر رابط لموضوع آخر على الموقع، ووصف موجز لسبب ارتباط الموضوعين.
ليس نموذجًا أوليًا مناسبًا، ولكن للتأكد من أننا على نفس الصفحة، أعني شيئًا كهذا:
للسياق، أنا مهتم باقتراح مواضيع تدعم وتعارض وجهات النظر المعبر عنها في موضوع معين. على سبيل المثال، إذا أنشأ شخص ما موضوعًا يدعي أن تغير المناخ ليس بالأمر الكبير، فأود أن يتمكن المستخدمون على الموقع من اقتراح مواضيع ذات صلة تعارض هذا الجدل أو تدعمه.
يمكن أن يكون مفيدًا أيضًا للمواضيع الأقل إثارة للجدل. عند الرد على موضوع هنا، غالبًا ما أستخدم وظيفة البحث في الموقع لمعرفة ما إذا كانت هناك أي مواضيع ذات صلة. يمكن الحفاظ على نتائج هذا الجهد من خلال السماح للمستخدمين باقتراح مواضيع ذات صلة. على سبيل المثال، قراءة هذا الموضوع جعلتني أفكر في استخدام Discourse الأخير للذكاء الاصطناعي هنا: Discourse Disorder. سيبدو من الملاءمة أن يظهر هذا الموضوع في قائمة المواضيع المقترحة لهذا الموضوع، مع ملاحظة تذكر أن Discourse يبدو أنه يبحث في طرق دمج المنتديات مع الذكاء الاصطناعي.
تحديث، تم تطبيق هذا الآن في المكون الإضافي Discourse AI 
