Zwischenstatus-Updates an den Benutzer senden, ohne zusätzliche Chat-Knoten zu verwenden?

Fragen
, , , , , , , ,
1

Hallo zusammen,

Ich habe derzeit einen größeren AI/Chat-Workflow in n8n, bei dem einige Anfragen etwas länger dauern können.

Um die UX zu verbessern, habe ich mehrere Chat-Knoten hinzugefügt, die zwischenzeitliche Statusupdates senden wie:

  • “Durchsuche Artikel…”

  • “Verarbeite Anfrage…”

  • “Mehrere Übereinstimmungen gefunden…”

Das Problem ist, dass jeder zusätzliche Chat-Knoten die Workflow-Ausführungszeit merklich erhöht.
In meinem Fall ist die Ausführungszeit um etwa 20% angewachsen, nur wegen dieser zwischenzeitlichen Meldungen.

Meine Frage ist also:

Gibt es eine Möglichkeit, Fortschritts-/Statusupdates während der Workflow-Ausführung an den Benutzer zu senden, OHNE zusätzliche Chat-Knoten zu verwenden?

Vielleicht über:

  • Code-Knoten

  • Webhook-Response-Streaming

  • benutzerdefinierte Frontend-Events

  • SSE/WebSocket

  • Execution Hooks

  • oder einen anderen leichtgewichtigen Ansatz?

Mein Ziel ist im Grunde:

  • den Workflow reaktionsfähig halten

  • Live-Fortschrittsrückmeldungen bereitstellen

  • den Workflow nicht erheblich verlangsamen

Wie handhabt ihr das in größeren AI/Chat-Workflows?

Vielen Dank!

2

Guten Morgen @Leon22
Nach meiner Erfahrung habe ich im nativen Chat von n8n noch keine generische Möglichkeit gesehen, den Zwischenstatus ohne Chat-Knoten oder unterstütztes Streaming zu senden; wenn ich etwas Leichteres brauche, verschiebe ich den Fortschritt normalerweise über Polling/SSE/WebSocket zu einem externen Frontend.

3

Das Hinzufügen eines Code-Knotens wird hier wirklich nicht viel helfen. Es muss immer noch denselben zugrunde liegenden Aufruf mit demselben Overhead durchführen.

Wenn du lieber in n8ns nativer Chat-UI bleiben möchtest, ist die schnellste Lösung, selektiv vorzugehen – von 5 Statusupdates auf etwa 2 zu reduzieren. Wenn das an aussagekräftigen Kontrollpunkten geschieht, werden die meisten dieser 20% ohne große architektonische Änderungen zurückgewonnen.

Wenn du dein Frontend kontrollierst, ist SSE die von dir erwähnte korrekte Langzeitlösung. Wie sieht dein aktuelles Setup aus? Das wird bestimmen, welcher Weg am realistischsten ist.