AI + 자동화 거버넌스: 독립적 AI 트리아지 스크립트 오케스트레이션

I’m building AI-powered automations using independent AI triage scripts (e.g., spam check, tag determination). These currently run concurrently, which is inefficient. I need to “chain” them so, for example, the tag script only runs if the spam script doesn’t flag the content.

How can I govern and orchestrate these scripts for a more logical workflow? Specifically, how can I chain these scripts conditionally?

Can you describe the full flow you are after? Would this be something you run on a separate server or would you like this to run in Discourse?

AI workflows is something we are thinking about a lot, the ability to define chains is key with workflows. I agree completely with that.

From what I can see, most of my use cases can be done in Discourse with AI Triage and Automation, if one can trigger then next.

Here is a hypothetical flow where each step would send the post contents and a prompt to the LLM:

  1. Check if spam
  • If spam, then hide and flag
  1. If not spam, determine products discussed
  • Add product label(s)
  1. Next determine intent:
    ** Complaint
    ** Question
    ** Suggestion
    ** Information sharing
    ** Positive feedback
  • Add intent tag
  1. If ‘complaint’ then evaluate for hot button issues: ie. contains hot-button phrases (cancel, terrible, slow)
  • If hot button issue, add ‘hot’ tag and assign to Sam
  1. If the intent is ‘positive feedback’ and product ‘wireless phone plan’, write a custom invitation to referral program and send as PM.

This is great and a very interesting use case.

Custom tools already have support now for scripting so we have a great vehicle for this kind of change.

I am thinking Persona + forced tool use - then from the tool we can run the flow given we already have all the infra to do so. Just need to give custom tools the ability to trigger other llm calls, something that is reasonably simple to add.

Interestingly given custom tools have support for rest calls they can run the entire flow (and just use the discourse rest api to wire this up)

Let me have a think about this over the weekend, and will reply again next week with how I think we can swing this.

Automation chaining is also a very interesting approach here, @j.jaffeux have you thought about this problem?

This reminds me of the IFTT/Zapier chain of actions, I think we could borrow a lot of their UI/UX elements if we build something like this out

Hi @Cloud_spanner I am trying to get to the bottom of this and would like to flesh out the actual flow here a bit more, can you help with some answer to questions along the way 5. ?

  1. Which posts should be scanned?

    1. Every new post on the forum?
    2. Every new topic - eg post number 1 - on the forum?
    3. What about edits? Should every edit be scanned? At what frequency? (10 minute debounce)
    4. What about high trust users? People that already posted twice on the forum?
  2. Intent

    1. Should it apply to ALL topics? ALL posts?
    2. What if an intent tag is already there?
    3. Can a topic have more than 1 intent (is this a tag group?)
  3. If intent can be manual, should manually tagged stuff also be scanned for “hot button”?

    1. Is hot an invisible tag or visible tag?

Particularly, what I am thinking about here is:

  1. Does the “workflow” contain shortcuts, where particular posts just skip steps an proceed to next
  2. How do we avoid feedback loops and edge cases
  1. Every new topic should kick off an AI triage workflow. Edits can be ignored.

  2. To be clear, I am using intent to illustrate the workflow so it shouldn’t be considered a hard-coded flow. The point I am trying to make is that there is no reason to kick off ‘intent’ workflow if the first triage workflow deems it unnecessary. +1 to the IFTTT workflow concept.

Intent and ‘hot’ would be invisible tags in this example visible to mods and admins only.

There should be one intent tag per post.

  1. I think for the sake of the workflow, we can ignore manually tagged posts.

Yes.

What if a private tag was used to show that the flow has run for that topic? And then it can be ignored for any future runs.

Another thought I have is that with the increased ability for LLM “reasoning” + large context windows would it be better to allow for structured outputs in the Discourse Automation window. IFTTT logic could then just be applied to a single automation instead of chaining multiple automations together. Imagine if there were the ability to have one automation, but many “Search for text” actions.

I have been thinking about how to solve this within our current system and one very appealing option is allow for a new automation type:

triage_using_custom_tool

We already have the custom tool system:

We can then allow it a few more functions such as llm.generate and topic.close, topic.tag and so on which could be used by the tool to perform these types of workflows.

Another advantage this has is that you could even test it which would make it easier to tune it.

That sounds like a great idea. I’m still newish to the Discourse ecosystem, so I’ll dig into Custom Tools and also how feature requests make their way into production.

좋은 소식이 있습니다. 이제 커스텀 도구를 사용하면 워크플로우가 모두 정상적으로 작동합니다!

핵심 아이디어는 모든 매개변수를 포함하는 단일 커스텀 도구를 정의하는 것입니다.

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로 대체한 후 달성할 수 있었던 해결책:

  1. “게시글 생성” 트리거.
  2. 스팸 탐지 시스템이 실행될 시간을 주기 위한 “기다림(Wait)” 단계.
  3. 게시글 데이터를 가져오기 위한 “Data Explorer” 단계:
  4. 게시글 데이터에 기반하여 워크플로 실행을 계속할지 결정하기 위한 “필터(Filter)” 단계: