Ich erstelle KI-gesteuerte Automatisierungen mit unabhängigen KI-Triage-Skripten (z. B. Spam-Prüfung, Tag-Bestimmung). Diese laufen derzeit parallel, was ineffizient ist. Ich muss sie „verkettet“, sodass beispielsweise das Tag-Skript nur ausgeführt wird, wenn das Spam-Skript den Inhalt nicht markiert.
Wie kann ich diese Skripte für einen logischeren Workflow steuern und orchestrieren? Insbesondere, wie kann ich diese Skripte bedingt verketten?
Können Sie den vollständigen Ablauf beschreiben, den Sie anstreben? Würden Sie dies auf einem separaten Server ausführen oder möchten Sie, dass dies in Discourse ausgeführt wird?
KI-Workflows sind etwas, worüber wir viel nachdenken. Die Fähigkeit, Ketten zu definieren, ist der Schlüssel zu Workflows. Dem stimme ich vollkommen zu.
Soweit ich das beurteilen kann, können die meisten meiner Anwendungsfälle in Discourse mit KI-Triage und Automatisierung erledigt werden, wenn man sie nacheinander auslösen kann.
Hier ist ein hypothetischer Ablauf, bei dem jeder Schritt den Beitragsinhalt und eine Aufforderung an das LLM sendet:
Das ist großartig und ein sehr interessanter Anwendungsfall.
Benutzerdefinierte Tools unterstützen jetzt bereits Skripting, sodass wir ein großartiges Mittel für diese Art von Änderung haben.
Ich denke an Persona + erzwungene Toolnutzung – dann können wir vom Tool aus den Ablauf ausführen, da wir bereits die gesamte Infrastruktur dafür haben. Wir müssen benutzerdefinierten Tools nur die Möglichkeit geben, andere LLM-Aufrufe auszulösen, was relativ einfach hinzuzufügen ist.
Interessanterweise können benutzerdefinierte Tools, da sie REST-Aufrufe unterstützen, den gesamten Ablauf ausführen (und einfach die Discourse-REST-API verwenden, um dies zu verdrahten).
Ich werde am Wochenende darüber nachdenken und nächste Woche erneut antworten, wie ich denke, dass wir das schaffen können.
Automatisierungsverkettung ist hier ebenfalls ein sehr interessanter Ansatz. @j.jaffeux, haben Sie über dieses Problem nachgedacht?
Das erinnert mich an die IFTT/Zapier-Aktionsketten. Ich denke, wir könnten viele ihrer UI/UX-Elemente übernehmen, wenn wir so etwas aufbauen.
Hallo @Cloud_spanner, ich versuche, das hier zu verstehen und möchte den tatsächlichen Ablauf hier etwas genauer ausarbeiten. Können Sie mir bei einigen Antworten auf die Fragen helfen? 5.
Welche Beiträge sollten gescannt werden?
Absicht
Wenn die Absicht manuell sein kann, sollten auch manuell getaggte Elemente auf „Hot Button“ gescannt werden?
hot ein unsichtbarer oder sichtbarer Tag?Insbesondere denke ich hier an:
Jedes neue Thema sollte einen KI-Triage-Workflow auslösen. Bearbeitungen können ignoriert werden.
Um es klarzustellen, ich verwende “Absicht”, um den Workflow zu veranschaulichen, daher sollte er nicht als fest codierter Ablauf betrachtet werden. Der Punkt, den ich machen möchte, ist, dass es keinen Grund gibt, den “Absichts”-Workflow zu starten, wenn der erste Triage-Workflow ihn für unnötig hält. +1 für das IFTTT-Workflow-Konzept.
Absicht und “hot” wären in diesem Beispiel unsichtbare Tags, die nur für Moderatoren und Administratoren sichtbar sind.
Es sollte ein Absicht-Tag pro Beitrag geben.
Ja.
Was ist, wenn ein privater Tag verwendet wird, um anzuzeigen, dass der Workflow für dieses Thema ausgeführt wurde? Und dann kann er für zukünftige Ausführungen ignoriert werden.
Ein weiterer Gedanke ist, dass es mit der erhöhten Fähigkeit der LLM-“Argumentation” + großen Kontextfenstern besser wäre, strukturierte Ausgaben im Discourse Automation-Fenster zu ermöglichen. Die IFTTT-Logik könnte dann auf eine einzige Automatisierung angewendet werden, anstatt mehrere Automatisierungen zu verketten. Stellen Sie sich vor, es gäbe die Möglichkeit, eine Automatisierung zu haben, aber viele “Text suchen”-Aktionen.
Ich habe darüber nachgedacht, wie wir dies in unserem aktuellen System lösen können, und eine sehr attraktive Option ist die Einführung eines neuen Automatisierungstyps:
triage_using_custom_tool
Wir haben bereits das System für benutzerdefinierte Tools:
Wir können ihm dann einige weitere Funktionen wie llm.generate und topic.close, topic.tag und so weiter zur Verfügung stellen, die das Tool zur Ausführung dieser Arten von Workflows verwenden könnte.
Ein weiterer Vorteil ist, dass Sie es sogar testen könnten, was die Abstimmung erleichtern würde.
Das klingt nach einer großartigen Idee. Ich bin noch relativ neu im Discourse-Ökosystem, also werde ich mich mit den benutzerdefinierten Werkzeugen und auch damit beschäftigen, wie Funktionsanfragen in die Produktion gelangen.
Ich habe gute Nachrichten: Ihr Workflow funktioniert jetzt mit benutzerdefinierten Tools!
Die Idee ist, dass Sie ein einziges benutzerdefiniertes Tool mit allen Parametern definieren würden:
is_spam, intent, hot, requires_invite
Dann würden Sie auf triage using persona klicken, um das Tool aufzurufen, und das Tool würde alle Aktionen ausführen (derzeit über die Discourse API, aber wir können im Laufe der Zeit weitere integrierte Funktionen bereitstellen).
Eine gute Einführung, wie all diese Dinge zusammengefügt werden können, finden Sie hier:
