Je construis des automatisations alimentées par l’IA à l’aide de scripts de triage IA indépendants (par exemple, vérification de spam, détermination de balises). Ceux-ci s’exécutent actuellement simultanément, ce qui est inefficace. Je dois les « chaîner » afin que, par exemple, le script de balisage ne s’exécute que si le script de spam ne signale pas le contenu.
Comment puis-je gouverner et orchestrer ces scripts pour un flux de travail plus logique ? Plus précisément, comment puis-je chaîner ces scripts conditionnellement ?
Pouvez-vous décrire le flux complet que vous recherchez ? S’agirait-il de quelque chose que vous exécutez sur un serveur séparé ou souhaitez-vous que cela s’exécute dans Discourse ?
Les flux de travail d’IA sont quelque chose auquel nous réfléchissons beaucoup, la capacité de définir des chaînes est essentielle avec les flux de travail. Je suis tout à fait d’accord avec cela.
D’après ce que je vois, la plupart de mes cas d’utilisation peuvent être réalisés dans Discourse avec l’IA Triage et Automatisation, si l’on peut déclencher ensuite.
Voici un flux hypothétique où chaque étape enverrait le contenu du message et une invite au LLM :
Vérifier si c’est du spam
Si c’est du spam, alors masquer et signaler
Si ce n’est pas du spam, déterminer les produits discutés
Si l’intention est une « plainte », évaluer les problèmes sensibles : c’est-à-dire, contient des phrases sensibles (annuler, terrible, lent)
Si problème sensible, ajouter la balise « hot » et assigner à Sam
Si l’intention est un « retour positif » et le produit « forfait de téléphonie sans fil », rédiger une invitation personnalisée au programme de parrainage et l’envoyer en MP.
C’est génial et un cas d’utilisation très intéressant.
Les outils personnalisés prennent déjà en charge les scripts, nous avons donc un excellent moyen pour ce type de changement.
Je pense à Persona + utilisation forcée d’outils - ensuite, à partir de l’outil, nous pouvons exécuter le flux étant donné que nous avons déjà toute l’infrastructure pour le faire. Il suffit de donner aux outils personnalisés la capacité de déclencher d’autres appels LLM, ce qui est raisonnablement simple à ajouter.
Il est intéressant de noter que, étant donné que les outils personnalisés prennent en charge les appels REST, ils peuvent exécuter l’intégralité du flux (et utiliser simplement l’API REST de Discourse pour cela).
Je vais y réfléchir ce week-end et je vous répondrai la semaine prochaine pour vous dire comment je pense que nous pouvons y parvenir.
L’enchaînement d’automatisations est également une approche très intéressante ici, @j.jaffeux avez-vous réfléchi à ce problème ?
Cela me rappelle la chaîne d’actions IFTT/Zapier, je pense que nous pourrions emprunter bon nombre de leurs éléments d’interface utilisateur/expérience utilisateur si nous construisons quelque chose comme ceci.
Salut @Cloud_spanner, j’essaie de comprendre cela et j’aimerais approfondir le flux réel ici. Peux-tu m’aider avec quelques réponses aux questions en cours de route ? 5.
Quels messages doivent être analysés ?
Chaque nouveau message sur le forum ?
Chaque nouveau sujet - par exemple, le premier message - sur le forum ?
Qu’en est-il des modifications ? Chaque modification doit-elle être analysée ? À quelle fréquence ? (anti-rebond de 10 minutes)
Qu’en est-il des utilisateurs de haut niveau de confiance ? Les personnes qui ont déjà posté deux fois sur le forum ?
Intention
Cela devrait-il s’appliquer à TOUS les sujets ? À TOUS les messages ?
Que se passe-t-il si une balise d’intention est déjà présente ?
Un sujet peut-il avoir plus d’une intention (s’agit-il d’un groupe de balises ?)
Si l’intention peut être manuelle, les éléments marqués manuellement doivent-ils également être analysés pour le « bouton sensible » ?
Est-ce que hot est une balise invisible ou visible ?
En particulier, ce à quoi je pense ici, c’est :
Le « workflow » contient-il des raccourcis, où des messages particuliers sautent des étapes et passent à la suivante ?
Comment éviter les boucles de rétroaction et les cas limites ?
Chaque nouveau sujet devrait déclencher un flux de travail de triage par IA. Les modifications peuvent être ignorées.
Pour être clair, j’utilise l’intention pour illustrer le flux de travail, donc cela ne devrait pas être considéré comme un flux codé en dur. Le point que j’essaie de faire est qu’il n’y a aucune raison de déclencher le flux de travail « d’intention » si le premier flux de travail de triage le juge inutile. +1 au concept de flux de travail IFTTT.
L’intention et « hot » seraient des balises invisibles dans cet exemple, visibles uniquement par les modérateurs et les administrateurs.
Il devrait y avoir une seule balise d’intention par publication.
Je pense que pour le bien du flux de travail, nous pouvons ignorer les publications marquées manuellement.
Oui.
Et si une balise privée était utilisée pour indiquer que le flux s’est exécuté pour ce sujet ? Et ensuite, il pourrait être ignoré pour toute exécution future.
Une autre réflexion que j’ai est qu’avec la capacité accrue de « raisonnement » des LLM + de grandes fenêtres de contexte, ne serait-il pas préférable de permettre des sorties structurées dans la fenêtre d’automatisation Discourse. La logique IFTTT pourrait alors être appliquée à une seule automatisation au lieu d’enchaîner plusieurs automatisations. Imaginez s’il y avait la possibilité d’avoir une automatisation, mais de nombreuses actions de « recherche de texte ».
J’ai réfléchi à la manière de résoudre ce problème dans notre système actuel et une option très attrayante est de permettre un nouveau type d’automatisation :
triage_using_custom_tool
Nous avons déjà le système d’outils personnalisés :
Nous pouvons ensuite lui accorder quelques fonctions supplémentaires telles que llm.generate et topic.close, topic.tag, etc., qui pourraient être utilisées par l’outil pour effectuer ces types de flux de travail.
Un autre avantage est que vous pourriez même le tester, ce qui le rendrait plus facile à régler.
Ça semble être une excellente idée. Je suis encore relativement nouveau dans l’écosystème Discourse, donc je vais examiner les Outils Personnalisés ainsi que la façon dont les demandes de fonctionnalités entrent en production.
J’ai une bonne nouvelle, votre flux de travail est maintenant entièrement fonctionnel à l’aide d’outils personnalisés !
L’idée est que vous définiriez un seul outil personnalisé avec tous les paramètres :
is_spam, intent, hot, requires_invite
Ensuite, vous utiliseriez triage using persona pour appeler l’outil, et l’outil effectuerait toutes les actions (actuellement via l’API Discourse, mais nous pouvons en exposer davantage au fur et à mesure).
Un bon aperçu de la manière dont tout cela peut être assemblé est :
J’ai également rencontré le problème de ne pas pouvoir orchestrer l’exécution d’un script d’Automation avec le détecteur de spam.
La bonne nouvelle est que Discourse a maintenant créé un plugin central « Workflows » qui facilite les mêmes types d’applications que le plugin « Automation », mais d’une manière bien plus puissante et flexible :
L’orchestration demandée ici peut être réalisée si vous utilisez le plugin Workflows pour implémenter les systèmes qui auraient auparavant été mis en place via le plugin Automation.
Le but de mon Automation était de signaler les publications ayant certaines caractéristiques qui pourraient indiquer du spam, mais pas de manière définitive. Le problème que j’ai rencontré est que ces mêmes caractéristiques sont souvent présentes dans les publications spam signalées par le système de détection de spam Discourse AI. Cela a entraîné une multiplication des signalements redondants par l’Automation, créant un travail supplémentaire inutile pour les modérateurs.
La solution de contournement consistant à « tout mélanger dans une seule Automation » présentée ci-dessus n’était pas applicable à mon système, car j’ai délibérément séparé les deux systèmes :
Le rôle du système de détection de spam est de détecter les publications ayant une forte probabilité d’être du spam.
Le rôle de mon système complémentaire est d’attirer l’attention des modérateurs sur les publications ayant une certaine probabilité d’être du spam.
Comme le détecteur de spam Discourse AI a une implémentation spéciale dans le framework Discourse (par opposition à un fonctionnement purement sur le framework Discourse AI fourni à l’administrateur du forum), je n’avais aucun intérêt à essayer de le remplacer par une Automation.
De plus, il n’était pas approprié de fusionner mon système complémentaire dans le détecteur de spam (en ajoutant des instructions à l’invite). Le comportement du système de spam, qui consiste à masquer immédiatement la publication et à faire taire l’auteur, est approprié tant qu’il est configuré pour fonctionner avec un haut degré de précision. À l’inverse, mon système complémentaire est intrinsèquement sujet aux faux positifs, et ses signalements ne doivent donc pas affecter l’utilisateur concerné avant une revue humaine.
La solution que j’ai pu obtenir après avoir remplacé l’Automation par un Workflow :
Déclencheur « Publication créée ».
Étape « Attendre » pour laisser le temps au système de détection de spam de s’exécuter.
Étape « Data Explorer » pour obtenir les données de la publication :
