AI は、長いトピックをふるい分け、分析する際に役立ちます。
AI 言語モデルのコンテキストでトピックのデータを使用するための現在の手順モデルを以下に示します。
- トピックのすべてのディスカッション投稿をダウンロードします。
- 関連データを抽出します。
- 関連データを AI 言語モデルにアップロードします。
- AI 言語モデルにデータ関連のクエリを実行します。
トピックのすべてのディスカッション投稿のダウンロード:
- これは CLI プログラム「discourse-reader」を介して可能です。
- 必要事項:
- ユーザー API キーの 1 回限りの申請。
- (フォーラム) ユーザー設定での API キーの承認。
ユーザー API キーの 1 回限りの申請:
- これは CLI プログラム「discourse-user-api-key」を介して可能です。
- 正確なワークフローは、プログラムのヘルプに記載されています。
トピックのダウンロードにより、複雑な JSON ファイルが生成されます。
{
"meta_data": ...,
"post_data": [ ... ]
}
例:
# フォーラムからトピックをダウンロード
discourse-reader -forum="meta.discourse.org" -topic=210780 -output="210780.json" -userapikey="107dc02b7fad3bc217b6f0c121fdc805"
関連データの抽出:
- これは CLI プログラム「jq」を介して可能です。
- JSON データへの変更も可能です。
例:
# 不要なデータをフィルタリング
# メタデータ
jq '.meta_data | {title, created_by:.details.created_by.username, created_at, id, posts_count, last_posted_at}' 210780.json > 210780.compact.json
# 投稿データ
jq '.post_data[] | .post_stream.posts[] | {post_number, username, created_at, reply_to_post_number, post:.cooked, reactions, accepted_answer}' 210780.json >> 210780.compact.json
関連データを AI 言語モデルにアップロードします。
AI 言語モデルにデータ関連のクエリを実行します。
- これを目的としたシンプルな CLI プログラムがまもなく開発されます。
- 当初は、AI 言語モデルのブラウザインターフェイスを使用できます。
言及されたプログラムは GitHub で見つけることができます。
そして、このフォーラムのトピック 210780 の使用例を以下に示します:
https://meta.discourse.org/t/matrix-protocol-for-chat/210780/
AI - Google Gemini 2.0 (exp)
Gemini へのプロンプト:
ユーザーごとの投稿数をリスト化してください。
ディスカッションの簡単な要約を作成してください。
ディスカッションの結果はどうなっていますか？
次のステップは何ですか？
Gemini からの応答:
ユーザーごとの投稿数:
- mattdm: 4
- david: 1
- sam: 4
- AquaL1te: 2
- seong: 1
- Stephen: 1
- satonotdead: 1
- user12: 1
- attj: 1
- Falco: 3
- halfshot: 2
- merefield: 2
- anarcat: 1
- dan: 1
- rokejulianlockhart: 3
- volanar: 4
- mcdanlj: 1
- jimkleiber: 2
- sunjam: 6
- dubwoc: 1
- davy: 2
- Lhc_fl: 1
- Thomas_Rother: 12
- thoka: 2
- mcwumbly: 4
- joshsimmons: 2
- hellekin: 5
- kOS: 1
ディスカッションの要約:
ディスカッションは、Matrix プロトコルを Discourse チャットに統合するというアイデアを中心に展開しています。最初の提案は、Discourse チャットルームを Matrix ルームにすることであり、ブリッジよりもシームレスになります。参加者は、多くの人が Matrix をオープンでフェデレーションされた標準として強く支持しているため、その魅力を認識しています。しかし、非 Discourse Matrix クライアントを使用している場合、「スローレーン」(トピック) に参加する可能性が低いユーザーがいるという懸念が提起されています。チャットとフォーラムが異なるプラットフォームにあることも障壁であると指摘する人もいます。ディスカッションでは、ActivityPub の使用だけでなく、Matrix を介した Discourse インスタンスのフェデレーションの可能性についても触れられています。
Discourse チャット用の Matrix ブリッジプラグインの開発が注目されており、その機能が概説されています。しかし、Discourse チャットでのエンドツーエンド暗号化の欠如についても議論されています。ユーザーマッピング、プロキシ、および全体的な必要な労力の複雑さが、重大な課題として強調されています。Discourse チャットと Matrix との相互運用性の利点については、特に Matrix が大手企業によってますます採用されていることを考えると、コンセンサスがあります。
ディスカッションの結果:
Matrix との統合というアイデアには多くの熱意と支持がありますが、ディスカッションでは次のような重大な課題が浮き彫りになっています。
- ユーザー管理: 2 つのシステム間でユーザーをマッピングすることは複雑です。
- 技術的な困難: 堅牢なブリッジを実装することはかなりの作業であり、特定のスキルセットが必要になる場合があります。
- リソースの制約: CDCK は、リソースが限られているため、これを優先事項としていません。また、説得力のあるビジネスケースもまだ見つかっていません。
- 資金調達の課題: ドイツの政府系ファンドからの資金調達の機会は過ぎました。
既存のブリッジコードは良い出発点と見なされていますが、アルファ段階であり、十分に文書化されておらず、さらなる開発が必要であると考えられています。CDCK からこの統合を優先するという明確なコミットメントはありません。外部からの資金調達が確保されるか、顧客がリクエストを優先して開発をスポンサーする場合を除きます。ディスカッションは、実装に向けた明確な道筋やコミットメントなしに終了します。
次のステップ:
- 熟練した開発者の発見: 最大の障壁は、Matrix と Discourse の両方の専門知識を持つ開発者の必要性です。
- 顧客スポンサーシップ: 開発を正当化するためのビジネスケースは作成されていません。顧客がこの取り組みをスポンサーする必要があるかもしれません。
- Matrix Foundation との連携: Matrix Foundation とより連携し、支援、技術ガイダンス、および潜在的な資金調達の機会を得ます。
- 既存コードの評価: 既存コードを見直し、ベータステータスに必要な開発を評価し、これが保守可能なアプローチであるかどうかを判断します。
- コミュニティイニシアチブ: コミュニティがサードパーティプラグインを開発する可能性を検討します。
- クラウドファンディング: クラウドファンディングの可能性を評価します。
- OFFDEM ディスカッション: 次回の OFFDEM でさらなる資金調達の機会について話し合います。