Agentic RAG in n8n: Warum klassisches RAG oft scheitert – und wie es besser geht

Viele Unternehmen setzen heute auf KI-Assistenten, die Fragen zu eigenen Dokumenten beantworten sollen – zu Meeting-Protokollen, Kennzahlen-Tabellen oder Kundenfeedback. Das gängige Verfahren dahinter heißt Retrieval Augmented Generation (RAG). Es ist verbreitet, gut unterstützt und in No-Code-Werkzeugen wie n8n schnell umgesetzt. Nur: In der Praxis liefert klassisches RAG erstaunlich oft falsche oder unvollständige Antworten. Cole Medin zeigt in seinem Video, woran das liegt und wie ein sogenanntes Agentic-RAG-Setup die typischen Schwächen umgeht. Wir fassen die wichtigsten Punkte nüchtern zusammen.

Warum klassisches RAG in der Praxis enttäuscht

RAG funktioniert über eine Ähnlichkeitssuche: Die Anfrage wird mit gespeicherten Textstücken („Chunks“) abgeglichen, und die passendsten werden an das Sprachmodell weitergegeben. Das Problem ist die Auswahl. Sie übersieht regelmäßig wichtigen Kontext.

Medin nennt zwei konkrete Schwachstellen:

• Kein Blick auf ganze Dokumente: RAG zieht nur einzelne Ausschnitte heran. Wer Trends in einer Tabelle analysieren will, bekommt vielleicht nur ein Viertel der Zeilen – und damit ein falsches Ergebnis.
• Keine echte Datenanalyse: Summen oder Maximalwerte über eine Tabelle lassen sich mit einer reinen Textsuche nicht zuverlässig berechnen.

Hinzu kommt ein praktisches Ärgernis: Wird nach dem Protokoll eines bestimmten Datums gefragt, zieht RAG mitunter das Dokument vom falschen Tag – obwohl das Datum im Titel steht. Und unterschiedliche Dokumente miteinander zu verknüpfen, um einen breiteren Zusammenhang herzustellen, gelingt selten.

Was Agentic RAG anders macht

Der Kerngedanke ist einfach: Statt dem KI-Agenten nur ein einziges Suchwerkzeug zu geben, erhält er mehrere – und darf selbst entscheiden, wie er die Wissensdatenbank erschließt. Medin definiert Agentic RAG so:

Agentic RAG bedeutet, dem Agenten die Fähigkeit zu geben, darüber nachzudenken, wie er die Wissensdatenbank durchsucht – statt ihn auf ein einzelnes Werkzeug festzunageln.

Konkret kann der Agent dadurch seine Suchanfragen verbessern, bei Bedarf ein anderes Werkzeug wählen und mehrere Wege ausprobieren, bis er eine belastbare Antwort hat. Schlägt die reine RAG-Suche fehl, ist er nicht mehr blockiert.

Die vier Werkzeuge des Agenten

Im n8n-Workflow stehen dem Agenten folgende Werkzeuge zur Verfügung:

• RAG-Suche – die klassische Ähnlichkeitssuche, in der verbesserten Version inklusive Quellenangabe.
• Dokumente auflisten – der Agent ruft alle Dokumente samt Titeln und IDs ab und überlegt, welche relevant sein könnten.
• Dateiinhalt abrufen – über die Datei-ID holt er den vollständigen Text eines bestimmten Dokuments (etwa das Protokoll vom 23. Februar, erkennbar am Titel).
• SQL-Abfrage über Tabellen – CSV- und Excel-Dateien werden wie SQL-Tabellen abgefragt, um Summen, Maxima und ähnliche Auswertungen zu ermöglichen.

Im System-Prompt wird der Agent angewiesen, mit RAG zu beginnen und nur dann auf die übrigen Werkzeuge auszuweichen, wenn die Suche nicht das Richtige liefert. Ein wichtiger Hinweis aus dem Video: Den Agenten ausdrücklich zur Ehrlichkeit aufzufordern – also offen zu sagen, wenn keine Antwort gefunden wurde – reduziert Halluzinationen spürbar.

Wie Tabellendaten gespeichert werden

Der technisch interessanteste Teil betrifft Tabellen. In Supabase werden dafür drei Tabellen angelegt:

• documents – enthält die Embeddings für RAG, Metadaten und die Inhalte der einzelnen Chunks.
• document_metadata – speichert übergeordnete Informationen: Titel, URLs für Quellenangaben und – bei Tabellen – das Schema (also die Spaltennamen).
• document_rows – legt die Tabellenzeilen ab. Die eigentlichen Daten landen in einer flexiblen JSONB-Spalte namens row_data.

Der Trick: Über JSONB lassen sich beliebige Spaltenstrukturen speichern, ohne für jede CSV- oder Excel-Datei eine eigene SQL-Tabelle erstellen zu müssen. Der Agent liest zuerst das Schema aus den Metadaten, versteht die verfügbaren Spalten und formuliert dann eine SQL-Abfrage gegen row_data. Medin weist ausdrücklich darauf hin, dass dieses Setup vereinfacht ist – das Schema verrät etwa nichts über Datentypen, sodass eine Summe über eine Spalte mit Dollarzeichen scheitern kann. Es geht ihm um das Konzept, nicht um eine perfekte Umsetzung.

Die RAG-Pipeline: von Google Drive nach Supabase

Bevor der Agent arbeiten kann, muss die Wissensdatenbank befüllt werden. Die Pipeline läuft dabei in mehreren Schritten ab:

• Auslöser: Ein Google-Drive-Trigger prüft jede Minute auf neue oder geänderte Dateien. Alternativ funktionieren Dropbox oder ein lokaler Datei-Trigger. Gelöschte Dateien werden allerdings nicht erkannt.
• Mehrere Dateien gleichzeitig: Eine neu eingebaute Schleife verarbeitet jetzt auch mehrere Dateien, die im selben Polling-Intervall ankommen – ein bekanntes Manko der Vorgängerversion.
• Alte Daten löschen: Vor jedem Import werden bestehende Einträge zur jeweiligen Datei-ID entfernt. So bleibt kein veralteter Chunk zurück, wenn ein Dokument kürzer geworden ist.
• Inhalt extrahieren: Ein Switch-Knoten verzweigt je nach Dateityp – PDF, Google Doc, Text oder Tabelle werden unterschiedlich ausgelesen. Weitere Formate wie JSON oder HTML lassen sich über zusätzliche Knoten ergänzen.
• Tabellen doppelt ablegen: CSV-Dateien werden einerseits als Textdokument für RAG aufbereitet, andererseits zeilenweise in document_rows für SQL-Abfragen gespeichert.

Ein praktischer Stolperstein bei der Einrichtung: Für die Postgres-Verbindung zu Supabase muss laut Video der Transaction-Pooler verwendet werden (Port 6543), nicht die direkte Verbindung. Die n8n-Dokumentation sei an dieser Stelle unklar.

Eingesetzte Modelle

Für die Einbettungen kommt OpenAIs text-embedding-3 zum Einsatz, als Sprachmodell GPT-4o mini – bewusst günstig und schnell gewählt. Für anspruchsvollere Fälle empfiehlt Medin leistungsfähigere Modelle wie GPT-4o oder Claude 3.5 Sonnet. Wichtig: Beim Einfügen und beim Abrufen muss dasselbe Embedding-Modell mit derselben Dimensionszahl genutzt werden.

Drei Beispiele aus dem Video

Medin demonstriert, wie der Agent je nach Frage unterschiedliche Werkzeuge wählt:

• Tabellenfrage: Auf „In welchem Monat hatten wir die meisten Neukunden?“ schreibt der Agent eine SQL-Abfrage und liefert das korrekte Ergebnis (Dezember, 129 Neukunden) – statt sich auf unvollständige Chunks zu verlassen.
• Reine RAG-Frage: Auf „Wo können wir besser werden?“ findet die Ähnlichkeitssuche das Feedback-Dokument, obwohl bewusst nicht das Wort „Verbesserung“ verwendet wurde.
• Datei-Abruf mit Quelle: Beim Abruf eines kompletten Meeting-Protokolls liefert der Agent die Action Items und auf Nachfrage einen anklickbaren Link zur Quelle.

Fazit

Der Beitrag zeigt nüchtern, warum naives RAG für viele Geschäftsanwendungen nicht ausreicht: Es übersieht Kontext und kann mit Tabellen nicht rechnen. Der Agentic-Ansatz löst das pragmatisch, indem er dem KI-Agenten mehrere Werkzeuge und Entscheidungsspielraum gibt. Für KMU-Entscheider, die einen Dokumenten-Assistenten erwägen, ist das eine wichtige Erkenntnis: Die Qualität steht und fällt nicht mit dem Modell allein, sondern mit der Architektur dahinter. Wer das vorgestellte n8n-Setup übernimmt, sollte es als Ausgangspunkt verstehen – Prompts, Werkzeuge und Datenmodell gehören an den eigenen Datenbestand angepasst. Gerade die SQL-Abfrage über Tabellen und die Behandlung von Datentypen bieten Raum für Verbesserungen.

Quelle: Cole Medin – „I Built the ULTIMATE n8n RAG AI Agent Template“, https://www.youtube.com/watch?v=mQt1hOjBH9o