スパム検出器と連動して Automation スクリプトの実行をオーケストレーションできないという問題にも直面しました。
朗報は、Discourse が「Automation」プラグインと同様のアプリケーションを、はるかに強力かつ柔軟な方法で可能にする「Workflows」コアプラグインを新たに作成したことです：
ここで要求されているオーケストレーションは、以前 Automation プラグインを使用して実装されていたシステムを Workflows プラグインを使用して実装することで実現できます。
私の Automation の目的は、スパムを示唆する可能性のある特定の特性を持つ投稿にフラグを立てることでしたが、それが決定的な証拠となるものではありませんでした。私が遭遇した問題は、これらの同じ特性が Discourse AI スパム検出システムによってフラグが立てられたスパム投稿にも頻繁に存在することでした。その結果、Automation が頻繁に冗長なフラグを立て、モデレーターにとって意味のない追加作業を生み出していました。
上記で紹介された「すべてを単一の Automation にまとめる」という回避策は、私のシステムには適用できませんでした。これは、私は意図的に2つのシステムを分離していたからです：
- スパム検出システムの役割は、スパムの可能性が高い投稿を検出することです。
- 私の補完システムの役割は、スパムの可能性が多少ある投稿をモデレーターの注意に引き付けることです。
Discourse AI スパム検出器は、Discourse フレームワーク内で特別な実装を持っています（フォーラム管理者に提供される Discourse AI フレームワークのみで純粋に動作するのではなく）。そのため、それを Automation で置き換えることに興味はありませんでした。
さらに、私の補完システムをスパム検出器に統合する（プロンプトに指示を追加する）ことも適切ではありませんでした。投稿を即座に非表示にし、著者をミュートするスパムシステムの動作は、高精度で動作するように設定されている限り適切です。一方、私の補完システムは本質的に誤検知を起こしやすく、そのためそのフラグは人間のレビューの前に対象ユーザーに影響を与えてはいけません。
Automation を Workflow に置き換えることで達成できた解決策：
- 「投稿が作成された」トリガー。
- スパム検出システムが実行される時間を確保するための「待機」ステップ。
- 投稿データを取得するための「Data Explorer」ステップ：
- 投稿データに基づいてワークフローの実行を続行するかどうかを判断するための「フィルタ」ステップ：
