独立したAIトリアージスクリプト（例：スパムチェック、タグ決定）を使用してAI搭載の自動化を構築しています。これらは現在並行して実行されており、非効率的です。例えば、スパムスクリプトがコンテンツをフラグ付けしなかった場合にのみタグスクリプトを実行するように、それらを「連鎖」させる必要があります。
より論理的なワークフローのために、これらのスクリプトをどのように管理およびオーケストレーションできますか？具体的には、これらのスクリプトを条件付きで連鎖させるにはどうすればよいですか？
求めている完全なフローを説明していただけますか？これは別のサーバーで実行するものでしょうか、それとも Discourse 内で実行したいものでしょうか？
AI ワークフローは、私たちが多く考えていることです。ワークフローにおけるチェーンを定義する機能は重要です。その点については完全に同意します。
私の見るところ、AIトリアージと自動化を備えたDiscourseで、ほとんどのユースケースが実現可能です。もしそれらがトリガーできれば、次のステップに進めます。
以下は、各ステップで投稿内容とプロンプトをLLMに送信する、仮説的なフローです。
- スパムかどうかを確認する
- スパムの場合、非表示にしてフラグを立てる
- スパムでない場合、議論されている製品を特定する
- 製品ラベルを追加する
- 次にインテントを特定する:
** クレーム
** 質問
** 提案
** 情報共有
** ポジティブなフィードバック
- インテントタグを追加する
- インテントが「クレーム」の場合、ホットボタンの問題を評価する: つまり、ホットボタンのフレーズ（キャンセル、ひどい、遅い）が含まれているか。
- ホットボタンの問題の場合、「ホット」タグを追加し、サムに割り当てる
- インテントが「ポジティブなフィードバック」で、製品が「ワイヤレス電話プラン」の場合、紹介プログラムへのカスタム招待状を作成し、PMとして送信する。
これは素晴らしい、非常に興味深いユースケースです。
カスタムツールはすでにスクリプティングのサポートがあるため、このような変更には最適な手段となります。
Persona + 強制的なツール使用を考えています。ツールから、すでにすべてのインフラストラクチャを持っているため、フローを実行できます。カスタムツールに他のLLM呼び出しをトリガーする機能を与えるだけでよく、これは追加するのが比較的簡単です。
興味深いことに、カスタムツールはREST呼び出しをサポートしているため、フロー全体を実行できます（そして、これを連携させるためにディスコースREST APIを使用するだけです）。
週末にかけてこの件について考えて、来週、どのように実現できるかについて再度返信します。
オートメーションの連鎖も非常に興味深いアプローチです。@j.jaffeux、この問題について考えたことはありますか？
こんにちは @Cloud_spanner さん。この問題を根本から理解しようとしており、実際のフローをもう少し詳しく説明したいのですが、途中でいくつか質問に答えていただけますでしょうか？ 5.
-
どの投稿をスキャンすべきですか？
- フォーラムの新しい投稿すべてですか？
- フォーラムの新しいトピック（例：投稿番号1）すべてですか？
- 編集についてはどうですか？ すべての編集をスキャンすべきですか？ どのくらいの頻度で？（10分間のデバウンス）
- 高い信頼度を持つユーザーについてはどうですか？ すでにフォーラムに2回投稿したユーザーは？
-
意図
- すべてのトピックに適用すべきですか？ すべての投稿に？
- 意図タグが既にある場合はどうなりますか？
- 1つのトピックに複数の意図を持たせることができますか？（これはタググループですか？）
-
意図が手動で設定できる場合、手動でタグ付けされたものも「ホットボタン」のためにスキャンすべきですか？
hotは不可視タグですか、それとも可視タグですか？
特に、ここで考えているのは次の点です。
- 「ワークフロー」には、特定の投稿がステップをスキップして次に進むショートカットが含まれていますか？
- フィードバックループやエッジケースをどのように回避しますか？
-
すべての新しいトピックは、AIトリアージワークフローを開始する必要があります。編集は無視できます。
-
明確にするために、ワークフローを説明するためにインテントを使用していますが、これはハードコーディングされたフローとは見なされるべきではありません。私が伝えたいのは、最初のトリアージワークフローで不要と判断された場合に「インテント」ワークフローを開始する理由がないということです。IFTTTワークフローの概念に賛成です。
インテントと「ホット」は、この例ではモデレーターと管理者にのみ表示される不可視のタグになります。
投稿ごとに1つのインテントタグが必要です。
- ワークフローのために、手動でタグ付けされた投稿は無視できると思います。
はい。
フローがそのトピックで実行されたことを示すプライベートタグを使用するのはどうでしょうか？そして、将来の実行では無視できます。
もう1つの考えは、LLMの「推論」能力と大きなコンテキストウィンドウが増加したことで、Discourse Automationウィンドウで構造化出力を許可する方が良いのではないかということです。IFTTTロジックは、複数のオートメーションを連鎖させるのではなく、単一のオートメーションに適用されるだけになります。「検索テキスト」アクションが多数ある1つのオートメーションを持つ機能があればどうなるでしょうか。
それは素晴らしいアイデアのようです。私はまだDiscourseエコシステムに新しいので、カスタムツールについて調べたり、機能リクエストがどのようにして本番環境に入るのかも調べてみます。
良いニュースがあります。カスタムツールを使用すると、ワークフローがすべて機能するようになりました。
アイデアは、すべてのパラメータを持つ単一のカスタムツールを定義することです。
is_spam、intent、hot、requires_invite
次に、「triage using persona」をクリックしてツールを呼び出すと、ツールがすべての操作を実行します（現在は Discourse API を介して行われますが、今後さらに多くの組み込み機能を利用できるようにします）。
これらのすべてをどのように連携できるかについての良い入門書は次のとおりです。
スパム検出器と連動して Automation スクリプトの実行をオーケストレーションできないという問題にも直面しました。
朗報は、Discourse が「Automation」プラグインと同様のアプリケーションを、はるかに強力かつ柔軟な方法で可能にする「Workflows」コアプラグインを新たに作成したことです：
ここで要求されているオーケストレーションは、以前 Automation プラグインを使用して実装されていたシステムを Workflows プラグインを使用して実装することで実現できます。
私の Automation の目的は、スパムを示唆する可能性のある特定の特性を持つ投稿にフラグを立てることでしたが、それが決定的な証拠となるものではありませんでした。私が遭遇した問題は、これらの同じ特性が Discourse AI スパム検出システムによってフラグが立てられたスパム投稿にも頻繁に存在することでした。その結果、Automation が頻繁に冗長なフラグを立て、モデレーターにとって意味のない追加作業を生み出していました。
上記で紹介された「すべてを単一の Automation にまとめる」という回避策は、私のシステムには適用できませんでした。これは、私は意図的に2つのシステムを分離していたからです：
- スパム検出システムの役割は、スパムの可能性が高い投稿を検出することです。
- 私の補完システムの役割は、スパムの可能性が多少ある投稿をモデレーターの注意に引き付けることです。
Discourse AI スパム検出器は、Discourse フレームワーク内で特別な実装を持っています（フォーラム管理者に提供される Discourse AI フレームワークのみで純粋に動作するのではなく）。そのため、それを Automation で置き換えることに興味はありませんでした。
さらに、私の補完システムをスパム検出器に統合する（プロンプトに指示を追加する）ことも適切ではありませんでした。投稿を即座に非表示にし、著者をミュートするスパムシステムの動作は、高精度で動作するように設定されている限り適切です。一方、私の補完システムは本質的に誤検知を起こしやすく、そのためそのフラグは人間のレビューの前に対象ユーザーに影響を与えてはいけません。
Automation を Workflow に置き換えることで達成できた解決策：
- 「投稿が作成された」トリガー。
- スパム検出システムが実行される時間を確保するための「待機」ステップ。
- 投稿データを取得するための「Data Explorer」ステップ：
- 投稿データに基づいてワークフローの実行を続行するかどうかを判断するための「フィルタ」ステップ：
