¿Enviar actualizaciones de estado intermedio al usuario sin nodos de Chat adicionales?

Preguntas
, , , , , , , ,
1

Hola a todos,

Actualmente tengo un flujo de trabajo de IA/chat más grande en n8n donde algunas solicitudes pueden tardar un poco más en completarse.

Para mejorar la experiencia del usuario, agregué varios nodos de Chat que envían actualizaciones de estado intermedio como:

  • “Buscando artículos…”

  • “Procesando solicitud…”

  • “Se encontraron coincidencias múltiples…”

El problema es que cada nodo de Chat adicional aumenta notablemente el tiempo de ejecución del flujo de trabajo.
En mi caso, el tiempo de ejecución aumentó alrededor del 20% solo por estos mensajes intermedios.

Así que mi pregunta es:

¿Hay una forma de enviar actualizaciones de progreso/estado intermedio al usuario durante la ejecución del flujo de trabajo SIN usar nodos de Chat adicionales?

Quizás a través de:

  • Nodo de código

  • Transmisión de respuesta por webhook

  • Evento personalizado de frontend

  • SSE/WebSocket

  • ganchos de ejecución

  • ¿o algún otro enfoque ligero?

Mi objetivo es básicamente:

  • mantener el flujo de trabajo receptivo

  • proporcionar retroalimentación de progreso en vivo

  • evitar ralentizar significativamente el flujo de trabajo

¿Cómo estás manejando esto en flujos de trabajo de IA/chat más grandes?

¡Muchas gracias!

2

buen día @Leon22
En mi experiencia, en el chat nativo de n8n aún no he visto una forma genérica de enviar estado intermedio sin nodos de Chat o streaming soportado; cuando necesito algo más ligero, suelo trasladar el progreso a un frontend externo vía polling/SSE/WebSocket.

3

Agregar un nodo de código realmente no ayudará mucho aquí. Seguirá teniendo que hacer la misma llamada subyacente con la misma sobrecarga.

Si prefieres seguir en la interfaz de chat nativa de n8n, la solución más rápida es ser selectivo, pasando de 5 actualizaciones de estado a algo más como 2. Si se hace en puntos de control significativos, eso recuperará la mayoría del 20% sin necesidad de cambios arquitectónicos grandes.

Si controlas tu frontend, SSE es la solución correcta a largo plazo que mencionaste. ¿Cómo es tu configuración actual? Eso determinará cuál es la ruta más realista.