RAG-Chatbot zu langsam? Antwortzeiten optimieren (Thread: 16s+)

Wenn ein RAG-Chatbot in n8n auf einfache Fragen 16 Sekunden oder länger braucht, liegt das selten am Sprachmodell allein, sondern meist an der Kombination aus Vector-Store-Wahl, Chunk-Größe, Modellauswahl und fehlendem Caching. In einem vielbeachteten Thread im n8n-Forum berichtete ein Nutzer von 16 bis 18 Sekunden Antwortzeit bei einem produktiven RAG-Chatbot mit AI-Agent-Node, während eine schlankere HTTP-/Code-Pipeline mit denselben Daten auf 3 bis 5 Sekunden kam. Die folgenden Stellschrauben lassen sich in bestehenden n8n-Workflows meist ohne Komplettumbau anpassen. Stand: Juli 2026.

Vector-Store-Wahl: nicht jede Datenbank ist für Tempo gebaut

n8n bindet mehrere Vector-Stores nativ ein: Pinecone, Qdrant, Supabase Vector Store und PGVector als Postgres-Erweiterung, dazu einen In-Memory-Store für Prototypen. Für die Antwortzeit zählt weniger der Name des Anbieters als die Kombination aus Indexierungsmethode, Netzwerklatenz zur Datenbank und Filterfähigkeit bei der Ähnlichkeitssuche. In einem dokumentierten Community-Fall mit PGVector führten hohe Antwortzeiten und aufgeblähter Tokenverbrauch dazu, dass Nutzer testweise auf einen dedizierten Vector-Store wie Qdrant auswichen, weil dieser für reine Vektorsuche mit Filteroptionen ausgelegt ist, während PGVector als Erweiterung einer relationalen Datenbank zusätzlichen Overhead mitbringt. Wer PGVector aus Gründen der Datenhoheit behalten möchte, sollte prüfen, ob die Postgres-Instanz nah am n8n-Server liegt, denn ein Teil der Latenz entsteht durch Netzwerk-Roundtrips zwischen Agent-Node und Datenbank.

Chunk-Größe und Overlap: kleiner ist oft schneller

Die Chunk-Größe bestimmt, wie viel Text pro Abschnitt in den Vector-Store wandert und wie viel Kontext bei jeder Anfrage an das Sprachmodell geht. n8n verwendet im Recursive Character Text Splitter standardmäßig eine Chunk-Größe von 1000 Zeichen mit 200 Zeichen Overlap. Im selben PGVector-Fall lösten kleinere Werte spürbare Probleme: Der Nutzer reduzierte die Chunk-Größe von 1200 auf 512 Zeichen, den Overlap von 200 auf 100 und die Batch-Größe beim Einfügen von 200 auf 32, wodurch sich Tokenverbrauch und Antwortzeit spürbar verringerten. Der Effekt ist plausibel: Kleinere Chunks bedeuten weniger irrelevanten Text pro Treffer, dadurch kürzere Prompts und weniger Rechenzeit beim Sprachmodell. Die Kehrseite ist Fragmentierung, zusammenhängende Informationen können auf mehrere Chunks verteilt werden. Ein guter Ausgangspunkt für viele Wissensdatenbanken liegt zwischen 500 und 800 Zeichen mit 10 bis 20 Prozent Overlap, angepasst an die Textstruktur der Quelldokumente.

Modellwahl und Agent-Architektur: woher die Sekunden wirklich kommen

Der eigentliche Auslöser der 16 Sekunden im referenzierten Thread war weniger die Modellwahl als die Architektur: Der AI-Agent-Node führt pro Anfrage typischerweise zwei bis vier interne Sprachmodell-Aufrufe aus, unter anderem für Tool-Auswahl und Reasoning-Schleifen, bevor die eigentliche Antwort entsteht. Eine schlankere Pipeline aus Embedding, Vektorsuche, Prompt-Aufbau und einem einzelnen Sprachmodell-Aufruf kam im selben Thread auf 3 bis 5 Sekunden, weil sie genau diese Zwischenschritte überspringt. Für einfache Retrieve-and-Answer-Szenarien ohne echte Werkzeugauswahl ist der volle Agent-Modus damit oft überdimensioniert. Zusätzlich wirkt sich die Modellwahl direkt auf die Antwortzeit aus: kleinere, schnellere Modelle liefern in der Regel niedrigere Latenz als größere Modelle, allerdings auf Kosten der Antwortqualität bei komplexeren Fragen. Wer die volle Agent-Flexibilität wirklich braucht, etwa weil der Chatbot zwischen mehreren Werkzeugen und Datenquellen wählen soll, kann diesen Overhead kaum vermeiden. Für alle anderen Fälle lohnt sich der Umbau auf eine deterministische Retrieval-Kette.

Caching: wiederholte Anfragen nicht jedes Mal neu berechnen

Caching wurde im referenzierten Forenthread nicht ausdrücklich diskutiert, gehört aber zu den naheliegenden Hebeln, sobald ein RAG-Chatbot in Produktion läuft. Die Dokumente werden nur einmal eingebettet und in den Vector-Store geschrieben, bei jeder neuen Anfrage muss lediglich die Nutzerfrage neu vektorisiert werden, das Embedding der Wissensbasis selbst sollte nicht bei jedem Chat-Aufruf erneut berechnet werden. Wiederkehrende oder sehr ähnliche Fragen lassen sich zusätzlich über einen einfachen Cache-Schritt im Workflow abfangen, etwa indem Frage und Antwort zwischengespeichert und bei einer Wiederholung direkt ausgegeben werden, ohne erneut Vektorsuche und Sprachmodell zu durchlaufen. Das lohnt sich vor allem bei FAQ-lastigen Anwendungsfällen mit wiederkehrenden Formulierungen, bei individuellen Supportanfragen ist der Effekt kleiner. Wer die Latenz systematisch senken will, sollte Caching erst nach den ersten drei Hebeln angehen, denn es behebt keine strukturellen Probleme in Chunking oder Architektur, sondern reduziert nur, wie oft diese durchlaufen werden.

Wer diese Stellschrauben in einem bestehenden n8n-Workflow nicht allein durchgehen möchte oder einen Chatbot mit klarer Architektur von Anfang an sauber aufsetzen lassen will, findet in der KI-Agenten-Entwicklung von NordFlux eine Anlaufstelle mit Festpreis und deutscher Datenhoheit. Für die n8n-Automatisierung unabhängig vom Chatbot-Thema ist die n8n-Beratung der passende Einstieg.

Häufige Fragen zu langsamen RAG-Chatbots in n8n

Woher stammt der Wert von 16 Sekunden?

Aus einem Thread im n8n-Forum, in dem ein Nutzer für einen produktiven RAG-Chatbot mit AI-Agent-Node und Vector-Store-Anbindung Antwortzeiten von 16 bis 18 Sekunden dokumentierte, während eine einfachere Pipeline mit denselben Daten auf 3 bis 5 Sekunden kam.

Ist der AI-Agent-Node grundsätzlich zu langsam für RAG?

Nein. Er ist für Szenarien mit echter Werkzeugauswahl und mehrstufigem Reasoning gebaut und macht dort seine Aufrufe zu Recht. Bei einem einfachen Retrieve-and-Answer-Flow ohne diese Anforderungen erzeugt er jedoch Overhead, der sich durch eine schlankere Kette vermeiden lässt.

Welche Chunk-Größe ist für die meisten Wissensdatenbanken sinnvoll?

Ein Bereich von 500 bis 800 Zeichen mit 10 bis 20 Prozent Overlap ist für viele Anwendungsfälle ein brauchbarer Ausgangspunkt, sollte aber anhand der eigenen Dokumentstruktur getestet werden. Zu kleine Chunks können Zusammenhänge zerreißen, zu große Chunks blähen Prompts und Antwortzeit auf.

Lohnt sich ein Wechsel des Vector-Stores allein wegen der Geschwindigkeit?

Nicht als erster Schritt. Zunächst lohnt sich die Prüfung, ob Netzwerklatenz, Chunk-Größe oder Agent-Architektur die eigentliche Ursache sind. Ein Wechsel des Vector-Stores ist aufwendiger als eine Konfigurationsanpassung und sollte erst folgen, wenn die anderen Hebel ausgeschöpft sind.