독립적인 AI 분류 스크립트(예: 스팸 검사, 태그 결정)를 사용하여 AI 기반 자동화를 구축하고 있습니다. 현재 이 스크립트들은 동시에 실행되고 있어 비효율적입니다. 예를 들어, 스팸 스크립트가 콘텐츠를 스팸으로 표시하지 않을 때만 태그 스크립트가 실행되도록 스크립트를 "체인"해야 합니다.
더 논리적인 워크플로우를 위해 이 스크립트들을 어떻게 거버넌스하고 오케스트레이션할 수 있을까요? 구체적으로, 이 스크립트들을 조건부로 체인하는 방법은 무엇일까요?
원하시는 전체 흐름을 설명해 주시겠어요? 이는 별도의 서버에서 실행하시게 될까요, 아니면 Discourse 안에서 실행되기를 원하시나요?
AI 워크플로우는 우리가 많이 생각하고 있는 부분이며, 워크플로우에서 체인(연속된 처리 과정)을 정의할 수 있는 능력이 핵심입니다. 그 점에 전적으로 동의합니다.
제가 볼 때, 다음 단계를 트리거할 수 있다면 대부분의 사용 사례를 AI Triage와 자동화를 통해 Discourse에서 처리할 수 있을 것 같습니다.
각 단계에서 게시물 내용과 프롬프트를 LLM에 전송하는 가상의 플로우를 아래에 제시합니다:
정말 훌륭하고 매우 흥미로운 사용 사례입니다.
커스텀 도구는 이미 스크립팅을 지원하므로, 이러한 종류의 변경 사항에 대해 매우 좋은 기반이 마련되어 있습니다.
현재는 페르소나(Perona) + 강제 도구 사용(forced tool use) 방식을 고려하고 있습니다. 기존에 필요한 인프라가 모두 갖춰져 있으므로, 도구에서 플로우를 실행할 수 있습니다. 커스텀 도구가 다른 LLM 호출을 트리거할 수 있는 기능만 추가하면 되는데, 이는 비교적 쉽게 구현할 수 있습니다.
흥미롭게도 커스텀 도구가 REST 호출을 지원하므로, 디스코르스(Discourse) REST API를 활용하여 전체 플로우를 실행할 수 있습니다.
주말 동안 이 문제에 대해 좀 더 생각해보고, 다음 주에 어떻게 이 문제를 해결할 수 있을지 의견을 다시 공유하겠습니다.
자동화 체이닝(Automation chaining)도 여기서는 매우 흥미로운 접근 방식입니다. @j.jaffeux 님, 이 문제에 대해 생각해 보신 적이 있으신가요?
안녕하세요 @Cloud_spanner. 이 문제를 파악하려고 노력 중이며, 실제 플로우를 좀 더 구체적으로 정리해 보고 싶습니다. 진행 중일 때 몇 가지 질문에 대한 답변을 주실 수 있을까요? 5번 항목까지 포함해서요.
어떤 게시글을 스캔해야 하나요?
의도(Intent)
의도를 수동으로 지정할 수 있다면, 수동으로 태그가 지정된 항목도 "핫버튼(hot button)"을 위해 스캔해야 하나요?
hot은 보이지 않는 태그인가요, 아니면 보이는 태그인가요?특히 여기에서 제가 생각하고 있는 것은 다음과 같습니다:
모든 새 토픽은 AI 분류(triage) 워크플로우를 시작해야 합니다. 편집은 무시해도 됩니다.
명확히 하자면, 저는 워크플로우를 설명하기 위해 ‘intent’(의도) 태그를 예시로 든 것이므로 이를 하드코딩된 플로우로 해석해 주시면 안 됩니다. 제가 하려는 핵심은 첫 번째 분류 워크플로우에서 불필요하다고 판단될 경우 ‘intent’ 워크플로우를 시작할 이유가 없다는 것입니다. IFTTT 워크플로우 개념에 +1을 드립니다.
이 예시에서 'intent’와 ‘hot’ 태그는 이례적으로 관리자 및 운영진에게만 표시되는 비공개 태그입니다.
각 게시글에는 하나의 intent 태그만 있어야 합니다.
네.
해당 토픽에 대해 플로우가 실행되었음을 나타내는 비공개 태그를 사용하는 것은 어떨까요? 그러면 향후 실행 시 이를 무시할 수 있습니다.
또 다른 생각으로는, LLM의 “추론” 능력과 대규모 컨텍스트 윈도우가 향상됨에 따라 Discourse 자동화 창에서 구조화된 출력을 허용하는 것이 더 나을 수 있다고 봅니다. 그러면 IFTTT 로직을 여러 자동화를 체인하는 대신 단일 자동화에 적용할 수 있습니다. 하나의 자동화를 가지되, “텍스트 검색” 액션은 여러 개 가질 수 있는 상황을 상상해 보세요.
정말 좋은 아이디어네요. 저는 아직 Discourse 생태계에 익숙하지 않아서, Custom Tools와 기능 요청이 프로덕션 환경에 반영되는 과정을 자세히 살펴보겠습니다.
좋은 소식이 있습니다. 이제 커스텀 도구를 사용하면 워크플로우가 모두 정상적으로 작동합니다!
핵심 아이디어는 모든 매개변수를 포함하는 단일 커스텀 도구를 정의하는 것입니다.
is_spam, intent, hot, requires_invite
그런 다음 triage using persona에서 해당 도구를 호출하도록 설정하면, 도구가 모든 작업을 수행합니다 (현재는 Discourse API를 통해 수행되며, 향후 더 많은 내장 기능을 공개할 예정입니다).
이러한 요소들이 어떻게 결합되는지 이해하는 데 좋은 참고 자료는 다음과 같습니다:
스팸 탐지기와 자동화(Automation) 스크립트의 실행을 오케스트레이션(조율)하지 못하는 문제를我也 겪었습니다.
좋은 소식은 Discourse가 이제 “Workflows” 핵심 플러그인을 만들었다는 것입니다. 이 플러그인은 “Automation” 플러그인과 동일한 유형의 애플리케이션을 지원하지만, 훨씬 더 강력하고 유연한 방식으로 작동합니다:
여기서 요청된 오케스트레이션은 Automation 플러그인을 통해 구현되던 시스템을 Workflows 플러그인을 사용하여 구현할 경우 달성할 수 있습니다.
제 Automation의 목적은 스팸일 가능성이 높지만 확정적이지는 않은 특정 특성을 가진 게시글에 플래그를 올리는 것이었습니다. 제가 겪은 문제는 이러한 동일한 특성들이 Discourse AI 스팸 탐지 시스템이 플래그를 올리는 스팸 게시글에도 자주 존재한다는 것이었습니다. 이로 인해 Automation이 중복된 플래그를 자주 올렸고, 이는 모더레이터에게 무의미한 추가 작업을 발생시켰습니다.
위에서 제시된 "모든 것을 하나의 Automation으로 통합한다"는 우회 방법은 제 시스템에는 적용할 수 없었습니다. 저는 두 시스템을 의도적으로 분리했기 때문입니다:
Discourse AI 스팸 탐지기는 Discourse 프레임워크 내에서 특수한 구현을 가지고 있으므로(포럼 관리자에게 제공되는 Discourse AI 프레임워크만으로 작동하는 것이 아님), 저는 Automation으로 이를 대체하려는 관심이 없었습니다.
또한, 제 보조 시스템을 스팸 탐지기에 통합하는 것(프롬프트에 지침을 추가하는 것)도 적절하지 않았습니다. 스팸 시스템의 게시글을 즉시 숨기고 작성자를 무음 처리하는 동작은 높은 정확도로 작동하도록 구성된 한 적절합니다. 반면, 제 보조 시스템은 본질적으로 오탐(false positive)이 발생하기 쉬우므로, 인간의 검토 전에 해당 사용자에게 영향을 미치는 플래그를 올리지 않아야 합니다.
Automation을 Workflow로 대체한 후 달성할 수 있었던 해결책:
