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