Estoy creando automatizaciones impulsadas por IA utilizando scripts de triaje de IA independientes (por ejemplo, verificación de spam, determinación de etiquetas). Actualmente se ejecutan simultáneamente, lo que es ineficiente. Necesito “encadenarlos” para que, por ejemplo, el script de etiquetas solo se ejecute si el script de spam no marca el contenido.
¿Cómo puedo gobernar y orquestar estos scripts para un flujo de trabajo más lógico? Específicamente, ¿cómo puedo encadenar estos scripts condicionalmente?
¿Puedes describir el flujo completo que buscas? ¿Sería algo que ejecutarías en un servidor separado o te gustaría que se ejecutara en Discourse?
Los flujos de trabajo de IA son algo en lo que pensamos mucho, la capacidad de definir cadenas es clave con los flujos de trabajo. Estoy completamente de acuerdo con eso.
Por lo que puedo ver, la mayoría de mis casos de uso se pueden realizar en Discourse con IA Triage y Automatización, si uno puede activar el siguiente.
Aquí hay un flujo hipotético donde cada paso enviaría el contenido de la publicación y una indicación al LLM:
Comprobar si es spam
Si es spam, ocultar y marcar
Si no es spam, determinar los productos discutidos
Añadir etiqueta(s) de producto
A continuación, determinar la intención:
** Queja
** Pregunta
** Sugerencia
** Compartir información
** Comentarios positivos
Añadir etiqueta de intención
Si la intención es ‘queja’, evaluar los temas candentes: es decir, contiene frases candentes (cancelar, terrible, lento)
Si es un tema candente, añadir la etiqueta ‘candente’ y asignar a Sam
Si la intención es ‘comentarios positivos’ y el producto es ‘plan de teléfono inalámbrico’, escribir una invitación personalizada al programa de referencia y enviarla como mensaje privado.
Las herramientas personalizadas ya tienen soporte para scripting, por lo que tenemos un gran vehículo para este tipo de cambio.
Estoy pensando en Persona + uso forzado de herramientas; luego, desde la herramienta, podemos ejecutar el flujo dado que ya tenemos toda la infraestructura para hacerlo. Solo necesitamos dar a las herramientas personalizadas la capacidad de activar otras llamadas LLM, algo que es razonablemente simple de agregar.
Curiosamente, dado que las herramientas personalizadas tienen soporte para llamadas REST, pueden ejecutar todo el flujo (y simplemente usar la API REST de Discourse para conectarlo).
Déjame pensar en esto durante el fin de semana y volveré a responder la próxima semana con cómo creo que podemos lograr esto.
La encadenación de automatización también es un enfoque muy interesante aquí, @j.jaffeux ¿has pensado en este problema?
Esto me recuerda a la cadena de acciones de IFTT/Zapier, creo que podríamos tomar prestados muchos de sus elementos de UI/UX si construimos algo como esto.
Hola @Cloud_spanner, estoy tratando de llegar al fondo de esto y me gustaría detallar un poco más el flujo real, ¿puedes ayudar con algunas respuestas a las preguntas a lo largo del camino? 5.
¿Qué publicaciones se deben escanear?
¿Cada nueva publicación en el foro?
¿Cada tema nuevo, por ejemplo, la publicación número 1, en el foro?
¿Qué pasa con las ediciones? ¿Se debe escanear cada edición? ¿Con qué frecuencia? (Debounce de 10 minutos)
¿Qué pasa con los usuarios de alta confianza? ¿Personas que ya publicaron dos veces en el foro?
Intención
¿Debería aplicarse a TODOS los temas? ¿A TODAS las publicaciones?
¿Qué pasa si ya existe una etiqueta de intención?
¿Puede un tema tener más de 1 intención (¿es este un grupo de etiquetas?)
Si la intención puede ser manual, ¿también se deben escanear las cosas etiquetadas manualmente para ver si son “hot button”?
¿Es hot una etiqueta invisible o visible?
En particular, lo que estoy pensando aquí es:
¿El “flujo de trabajo” contiene atajos, donde publicaciones particulares simplemente omiten pasos y proceden al siguiente?
¿Cómo evitamos bucles de retroalimentación y casos extremos?
Cada tema nuevo debería iniciar un flujo de trabajo de clasificación de IA. Las ediciones se pueden ignorar.
Para que quede claro, estoy usando la intención para ilustrar el flujo de trabajo, por lo que no debe considerarse un flujo codificado. El punto que intento plantear es que no hay razón para iniciar el flujo de trabajo de ‘intención’ si el primer flujo de trabajo de clasificación lo considera innecesario. +1 al concepto de flujo de trabajo IFTTT.
La intención y ‘caliente’ serían etiquetas invisibles en este ejemplo visibles solo para moderadores y administradores.
Debería haber una etiqueta de intención por publicación.
Creo que, en aras del flujo de trabajo, podemos ignorar las publicaciones etiquetadas manualmente.
Sí.
¿Qué pasa si se usara una etiqueta privada para mostrar que el flujo se ha ejecutado para ese tema? Y luego se puede ignorar para futuras ejecuciones.
Otro pensamiento que tengo es que, con la mayor capacidad de “razonamiento” de LLM + grandes ventanas de contexto, ¿sería mejor permitir salidas estructuradas en la ventana de Automatización de Discourse? La lógica IFTTT podría aplicarse a una sola automatización en lugar de encadenar múltiples automatizaciones. Imagina si hubiera la capacidad de tener una automatización, pero muchas acciones de “Buscar texto”.
Luego podemos permitirle algunas funciones más como llm.generate y topic.close, topic.tag y así sucesivamente que podrían ser utilizadas por la herramienta para realizar este tipo de flujos de trabajo.
Otra ventaja que tiene es que incluso podrías probarlo, lo que facilitaría su ajuste.
Eso suena como una gran idea. Aún soy bastante nuevo en el ecosistema de Discourse, así que investigaré las Herramientas Personalizadas y también cómo las solicitudes de funciones llegan a producción.
Tengo buenas noticias, ¡tu flujo de trabajo ahora es totalmente funcional utilizando herramientas personalizadas!
La idea es que definirías una única herramienta personalizada con todos los parámetros:
is_spam, intent, hot, requires_invite
Luego, en triage using persona llamarías a la herramienta y esta realizaría todas las acciones (en este momento a través de la API de Discourse, pero podemos exponer más funciones integradas a medida que avancemos).
Un buen resumen sobre cómo se puede unir todo esto es:
También me encontré con el problema de no poder orquestar la ejecución de un script de automatización junto con el detector de spam.
La gran noticia es que Discourse ha creado ahora un plugin central llamado “Workflows” (Flujos de trabajo) que facilita el mismo tipo de aplicaciones que el plugin “Automation” (Automatización), pero de una manera mucho más potente y flexible:
La orquestación solicitada aquí se puede lograr si utilizas el plugin Workflows para implementar los sistemas que anteriormente se habrían implementado mediante el plugin Automation.
El propósito de mi automatización era marcar publicaciones con ciertas características que podrían indicar spam, pero no de forma definitiva. El problema que encontré es que estas mismas características suelen estar presentes en las publicaciones marcadas como spam por el sistema de detección de spam de Discourse AI. Esto provocaba que la automatización generara frecuentemente marcas redundantes, creando trabajo adicional innecesario para los moderadores.
La solución alternativa de “mezclar todo en una única automatización” presentada anteriormente no era aplicable a mi sistema, porque separé intencionadamente los dos sistemas:
La función del sistema de detección de spam es detectar publicaciones con una alta probabilidad de ser spam.
La función de mi sistema complementario es llamar la atención de los moderadores sobre publicaciones que tienen cierta posibilidad de ser spam.
Dado que el detector de spam de Discourse AI tiene una implementación especial en el marco de Discourse (a diferencia de operar puramente en el marco de Discourse AI proporcionado al administrador del foro), no tenía ningún interés en intentar reemplazarlo por una automatización.
Además, no era apropiado fusionar mi sistema complementario con el detector de spam (añadiendo instrucciones al prompt). El comportamiento del sistema de spam, que oculta inmediatamente la publicación y silencia al autor, es adecuado siempre que se configure para operar con un alto grado de precisión. Por el contrario, mi sistema complementario es inherentemente propenso a falsos positivos, por lo que sus marcas no deben afectar al usuario afectado antes de una revisión humana.
La solución que pude lograr después de reemplazar la automatización por un flujo de trabajo:
Disparador “Publicación creada”.
Paso “Esperar” para dar tiempo a que el sistema de detección de spam se ejecute.
Paso “Data Explorer” (Explorador de datos) para obtener los datos de la publicación:
