もし推奨トピックがトピックのタイトルと内容を考慮してくれるなら、とても素晴らしいでしょう。例えば、「分析」に関するトピックを読んでいる場合、類似の内容を含むトピックを現在の推奨結果に混ぜて表示できるような仕組みです。
これが効率的に実現できれば、新規訪問者にもアクティブユーザーにもエンゲージメントを高める確実な成功要因になると確信しています。たとえこれらの推奨がタイトルと内容の両方ではなく、タイトルのみを使用するだけでもです。
「いいね！」 6
この機能は効率的に構築するには非常に複雑で、その奥深さは計り知れません。ある時点で機械学習の検討が始まり、さらに深く、さらに深く掘り進めることになります。
AI を使って関連コンテンツを判定するという点には魅力を感じます。特に Support トピックでは非常に便利で、ほぼ「セルフサービス」化できるかもしれません。質問を投稿すると、ML が 10 件の候補を選び出し、それらを返信として投稿します。ユーザーはそれらを受け入れるか削除するかを選べます。同様に、匿名ユーザーがサポート関連の投稿をした際にも、関連コンテンツを表示するのは役立ちます。
とはいえ……これは途方もなく巨大な作業です。来年のロードマップには含まれていません。しかし、@eviltrout は将来的に AI/ML を実験することに熱心であり、これはそのようなプロジェクトに関連する可能性があります。
@codinghorror は DJ Random の大ファンで、彼はそのようなアプローチが多くの高度なアルゴリズムを上回ると信じています（実際、よくそうなります）。
「いいね！」 7
DJ random は素晴らしいですが、時間やカテゴリ／タグで制限を設けています。それが重要なのです。
「いいね！」 3
こんにちは、
初めましてなので、もし既に出ている話題を蒸し返してしまっていたらすみません。
@sam さんも仰る通り、奥が深い部分もありますが、一方ではトピックモデリング技術は現在かなり成熟しており、すぐに使える優れたツールも存在します。最近行ったプロジェクトでは、約500万件の特許タイトルと要約を分析しました。私の新しいDiscourse サイト で数千のトピックを分析するのは、まさに朝飯前です。さらに、私のコミュニティにはそれを実現する意欲があるかもしれません。
専門家の方々へ：プラグインの設計を考えるべきか、それともGitHubからダウンロードしたDiscourseのソースコードを直接いじるべきか、アドバイスをお願いできますでしょうか。
PythonでDiscourseのトピックをスクレイピングする方法について こちら を見つけましたが、まだ動作させることができていません。それに似た方法で、データをオフラインに取得し、モデルを構築し、後でクエリを実行できるようにロードできるような仕組みが必要だと考えています。
余談ですが、優れたツールの多くはPythonで書かれています。
「いいね！」 4
機能的には、新しいトピックを作成する際に「あなたのトピックは…に似ています」というパネルに最も適しています。
「いいね！」 1
ソースコードを直接改変するよりも、ここではプラグインの作成を強くお勧めします。コア機能としてこの種の機能をリリースする可能性は極めて低いです。なぜなら、巨大な Python 依存関係が必要になり、トレーニングのための UI など多数の実装が必要になるからです。
トレーニングの仕組みなどについては、まだ多くの検討が必要です。トレーニングを行う具体的な仕組みについて概要はありますか？どのモデルを使用することを推奨しますか？トピックに 100 件の投稿がある場合や 1000 件の場合、どうなりますか？
どのようなシグナルを使用し、それぞれ（閲覧数、カテゴリ、タグなど）にどの程度の重み付けを行うのでしょうか？
このプロジェクトには非常に興味を持っていますが、かなり大規模な作業になると感じています。
「いいね！」 3
トレーニングのメカニズムなどについて多くの作業が必要です。トレーニングを行う際のメカニズムの概要をいただけますか？また、具体的にどのモデルの使用をお勧めしますか？
私のチームが現在使用しているツールは、gensim に由来します。これは標準的な Python モジュール インターフェースを持っています。長年にわたり非常に良くテストされてきました。
私が思い浮かべるセットアップは以下の通りです：
- 第一に：ドキュメントセットを選択します。すべてのトピックのルート、あるいはすべての投稿を含めることができます。
定期的（例：週に一度、月に一度、フォーラムのトラフィックに応じて）に doc2vec モデルを構築します：
- Discourse のトピックを、md テキスト形式（タイトル＋トピック本文）のファイル（または複数ファイル）にスクレイピングします。ここで、各トピックを gensim アルゴリズムにおける「ドキュメント」として扱います。
- 標準的な NLP ツールを使用してドキュメントを処理し、単語の語幹抽出などを行います。
doc2vec（gensim 実装から）を使用して、各ドキュメントを d 次元空間内のベクトルにマッピングするモデルを構築します。メタパラメータ d は実験を通じて選択する必要があります。Google は特許モデルに d=40 を使用していますが、Google Scholar がどの d を使用しているかは不明です。私は通常 d=200 を使用します。空間の各次元は、意味内容に関連する「特徴」と考えることができます。- （参考：doc2vec アルゴリズムは、単語の系列を学習するように設計されたニューラルネットをトレーニングすることで特徴空間を構築します。このニューラルネットには d 次元の隠れ層があり、その隠れ層の出力が特徴の潜在空間を形成します）
- モデルの構築は、ドキュメントの数に依存する重厚なタスクです。38 年分の特許（500 万ドキュメント）の場合、8 コアの古いマシンでも overnight（一晩中）かかります。
- オプションの興味深い追加タスク：d 次元特徴空間内のドキュメントの雲をクラスタリングします。
- Python の sklearn ライブラリなどの市販のクラスタリングツールを使用できます。
- クラスタリングは「創発的な分類」をもたらします。これらの分類がキーワード（または Discourse タグ）のカテゴリとどのように重なり合うかという、興味深い研究課題があります。
これはオフラインで行われます。その後、オンラインでは：
- モデルをロードします。
- モデルがロードされれば、新しいドキュメントを解析し、その d 次元特徴空間内の位置をモデルに問い合わせることは、比較的軽いタスクです。
- なお、この新しいドキュメントはモデルの再構築をトリガーしません。モデルはオンラインクエリに対して静的に保持されます。新しいドキュメントは、次の（例：週次）モデル構築時に統合されます。
- 最後に、特徴空間内でどのドキュメントが近接しているかを問い合わせるという、さらに軽いタスクがあります。近接ドキュメントのリストを取得するための gensim ツールもありますが、numpy を直接使用してすべてのドキュメントベクトルを kd-ツリーのような構造に読み込み、近接点を直接高速にクエリすることも可能です。
トピックに投稿が 100 件、1000 件ある場合はどうなりますか？
オフライン部分はドキュメント数に対してほぼ線形にスケーリングしますが、1 万〜10 万ドキュメントであれば非常に管理可能です。100 万ドキュメントでも週次バッチであれば問題ありません。
シグナルには何を、また各要素（閲覧数、カテゴリ、タグなど）にどの程度の強度を与えるべきでしょうか？
この文脈における新しいトピックの「シグナル強度」は、新しいトピックのベクトル空間埋め込みと既存のドキュメントベクトルとの距離（逆数）として直接解釈されます。このシグナルに「いいね」や「閲覧数」などの他の要素を付加することもできますが、これらは私が説明している基本アルゴリズムへの追加の装飾に過ぎません。
スクレイピングが動作するようになったら（私が、あるいは誰かが）、上記のオフライン部分は非常に簡単で機械的な作業です。
難しい部分（私にとって）はオンライン部分であり、Discourse の Rails といくつかの Python 呼び出し（例：gensim ツールへの呼び出し）を連携させる必要があります。このようなインターフェースの例があれば、参考になるため是非見てみたいです。
「いいね！」 6
@Bcat : あなたが「自分のものに置き換えた」方法を見てみたいのですが、確認できるプラグインやリポジトリはありますか？
ここで厄介なパフォーマンス上の課題は、RPC メカニズムです。トピックの表示ごとに新しい Python プロセスを起動するのは避けたいところです。
HTTP 呼び出しであっても、遅すぎる可能性があります。
あるいは…… related_topics テーブル（topic_id, related_topic_id, rank）を事前に構築するのはどうでしょうか。これにより、新しいトピックが投稿された際に WebHooks を使ってテーブルを素早く更新し、Ruby から Python を呼び出す必要をなくすことができます。
Discourse 側の実装は非常に簡単です。このメソッドを書き換えて、新しく作成した related_topics テーブルから情報を検索するようにするだけです。
「いいね！」 2
従来の方法ではうまくいかなかったため、Google広告に置き換えました。Googleが提案するトピックは非常に巧妙です。
従来の手法については、デフォルトの提案を無効化し、/search を呼び出してトピックのリストを返す JavaScript スニペットに置き換えました。
「いいね！」 2
テーブル実装へのヒントをありがとうございます。ただし、テーブル方式が拡張可能かどうかは疑問です。トピックが N 個ある場合、サイズ N^2 のテーブルが必要になります。つまり、10^4 のトピックであれば、テーブルには 10^8 のエントリが存在することになります。
新しいトピックを解析し、埋め込みを行い、最近傍を検索するために Python の呼び出しが必要になることを回避する方法が見当たりません。過去には Web インターフェースを構築したことがありますが、ここではサイドで Python プロセスを実行し、ソケットやパイプを通じて Discourse と通信する方が魅力的でしょう。ファイルへの読み書きとほぼ同じように動作し、実際の Python 呼び出しとは異なります。（結局のところ、すべてが私のサーバー上で実行されているのですから。）
すみません、私が完全に誤解しているのでしょうか？
トピックが100個あり、各トピックに5つの関連トピックが表示される場合、なぜテーブルが500より大きく必要になるのでしょうか？
「いいね！」 1
N 個のトピックは、ベクトル空間表現における N 個の点に対応します。
各点間の距離の行列は N^2 になります（行列は対称であるため、独立な値は N*(N-1)/2 です）。これが私が言及していた N^2 です。
しかし、kd-tree などの巧妙なデータ構造を使えば、N^2 の差分テーブルを蛮力的に検索することなく、最近傍探索を行うことができます。
いずれにせよ、Python でこれらすべてを実行する方法は知っています。あなたが言及している小さなテーブル、つまり 5 つの最近傍トピックに対応する N x 5 のテーブルを返すことができます。
「いいね！」 1
その後、その処理を毎日 Python で実行すれば、Python から直接 Discourse のデータベースに接続させ、このキャッシュテーブルを生成させることができます。
Discourse プラグイン側の処理は比較的簡単です。場所 X から選択する代わりに、場所 Y（別のテーブル）から選択するようにするだけです。
単一のリクエストに対して 2 つのプログラミング言語の間を行き来させる必要があるパイプラインと格闘する必要がなくなります。
ここに提案されているAIアプローチは興味深く、理想的な解決策になる可能性があります。
より技術的でないアプローチを検討する価値があるかどうか疑問に思っています。たとえば、「Suggested Topics」セクションに「Suggest Topic」ボタンを設けることができます。このボタンをクリックすると、ユーザーはサイト上の別のトピックへのリンクと、2つのトピックが関連している理由の簡単な説明を投稿できるようになります。
これは正式なモックアップではありませんが、認識を合わせるために、私が意味するのはこのようなものです。
文脈として、私は、特定のトピックで表明された見解を支持し、かつ反対するトピックを提案することに関心があります。たとえば、気候変動は大きな問題ではないと主張するトピックが作成された場合、その議論に反対または賛成する関連トピックをサイトのユーザーが提案できるようにしたいと考えています。
これは、それほど議論を呼ぶトピックでない場合にも役立つ可能性があります。ここでトピックに返信する際、サイトの検索機能を使用して関連トピックがあるかどうかを確認することがよくあります。その努力の結果は、ユーザーが関連トピックを提案できるようにすることで保存できます。たとえば、このトピックを読んで、Discourseが最近AIをここでどのように使用しているかについて考えるようになりました。https://meta.discourse.org/t/disorder-automatic-toxicity-detection-for-your-community/246587/1。このトピックが、DiscourseがフォーラムとAIを統合する方法を模索しているように見えることに言及したメモとともに、このトピックの推奨トピックリストに表示されることは関連性があるように思われます。
「いいね！」 3
更新、これはDiscourse AIプラグインで実装されました 
「いいね！」 5