스팸 탐지기와 자동화(Automation) 스크립트의 실행을 오케스트레이션(조율)하지 못하는 문제를我也 겪었습니다.
좋은 소식은 Discourse가 이제 “Workflows” 핵심 플러그인을 만들었다는 것입니다. 이 플러그인은 “Automation” 플러그인과 동일한 유형의 애플리케이션을 지원하지만, 훨씬 더 강력하고 유연한 방식으로 작동합니다:
여기서 요청된 오케스트레이션은 Automation 플러그인을 통해 구현되던 시스템을 Workflows 플러그인을 사용하여 구현할 경우 달성할 수 있습니다.
제 Automation의 목적은 스팸일 가능성이 높지만 확정적이지는 않은 특정 특성을 가진 게시글에 플래그를 올리는 것이었습니다. 제가 겪은 문제는 이러한 동일한 특성들이 Discourse AI 스팸 탐지 시스템이 플래그를 올리는 스팸 게시글에도 자주 존재한다는 것이었습니다. 이로 인해 Automation이 중복된 플래그를 자주 올렸고, 이는 모더레이터에게 무의미한 추가 작업을 발생시켰습니다.
위에서 제시된 "모든 것을 하나의 Automation으로 통합한다"는 우회 방법은 제 시스템에는 적용할 수 없었습니다. 저는 두 시스템을 의도적으로 분리했기 때문입니다:
- 스팸 탐지 시스템의 역할은 스팸일 가능성이 높은 게시글을 탐지하는 것입니다.
- 제 보조 시스템의 역할은 스팸일 가능성이 있는 게시글을 모더레이터의 주의를 끌기 위한 것입니다.
Discourse AI 스팸 탐지기는 Discourse 프레임워크 내에서 특수한 구현을 가지고 있으므로(포럼 관리자에게 제공되는 Discourse AI 프레임워크만으로 작동하는 것이 아님), 저는 Automation으로 이를 대체하려는 관심이 없었습니다.
또한, 제 보조 시스템을 스팸 탐지기에 통합하는 것(프롬프트에 지침을 추가하는 것)도 적절하지 않았습니다. 스팸 시스템의 게시글을 즉시 숨기고 작성자를 무음 처리하는 동작은 높은 정확도로 작동하도록 구성된 한 적절합니다. 반면, 제 보조 시스템은 본질적으로 오탐(false positive)이 발생하기 쉬우므로, 인간의 검토 전에 해당 사용자에게 영향을 미치는 플래그를 올리지 않아야 합니다.
Automation을 Workflow로 대체한 후 달성할 수 있었던 해결책:
- “게시글 생성” 트리거.
- 스팸 탐지 시스템이 실행될 시간을 주기 위한 “기다림(Wait)” 단계.
- 게시글 데이터를 가져오기 위한 “Data Explorer” 단계:
- 게시글 데이터에 기반하여 워크플로 실행을 계속할지 결정하기 위한 “필터(Filter)” 단계:
