Eigene Dokumente mit KI durchsuchbar machen (RAG)

Das Wissen eines Betriebs steckt selten dort, wo man es sucht: in PDFs auf dem Fileserver, im alten Wiki, in Handbüchern, Angeboten und langen E-Mail-Verläufen. Mitarbeiter verbringen einen erstaunlichen Teil ihres Tages damit, Antworten zusammenzusuchen, die längst irgendwo dokumentiert sind. Die naheliegende Frage lautet: Kann ich ein Sprachmodell einfach auf unsere eigenen Dokumente loslassen? Das geht – aber nicht so, wie die meisten es sich vorstellen. Der Baustein dafür heißt RAG. Dieser Artikel erklärt für Geschäftsführer und Prozessverantwortliche, was dahintersteckt, wie man es in n8n baut und wo die Grenzen verlaufen.

Warum ein Sprachmodell Ihre Dokumente nicht kennt

Ein Modell wie GPT oder Llama kennt nur, was in seinen Trainingsdaten stand. Ihre Preisliste, Ihr Qualitätshandbuch, der Rahmenvertrag mit Lieferant X – all das hat es nie gesehen. Fragt man trotzdem danach, passiert eines von zwei Dingen: Das Modell gibt zu, dass es das nicht weiß, oder – häufiger – es erfindet eine plausibel klingende Antwort. In seiner RAG-Dokumentation benennt n8n genau diese drei Probleme des reinen Modells: Es halluziniert Details, es kennt die internen Daten nicht, und man kann sein Wissen nicht aktualisieren, ohne es aufwendig nachzutrainieren.

Der naheliegende Ausweg – einfach alle Dokumente in den Prompt kopieren – scheitert an der Menge. Ein Sprachmodell kann pro Anfrage nur eine begrenzte Textmenge verarbeiten, und je mehr man hineinstopft, desto teurer und ungenauer wird die Antwort. Man braucht also einen Weg, dem Modell zu jeder Frage nur die wenigen wirklich relevanten Absätze mitzugeben. Genau das leistet RAG.

Was RAG bedeutet

RAG steht für „Retrieval-Augmented Generation“: abrufgestützte Antworterzeugung. Statt das Modell alles wissen zu lassen, holt das System zur konkreten Frage die passenden Textstellen aus Ihren eigenen Dokumenten und legt sie ihm zusammen mit der Frage vor. Das Modell antwortet dann nicht aus dem Gedächtnis, sondern auf Basis der mitgelieferten Belege.

RAG (Retrieval-Augmented Generation) verbindet ein Sprachmodell mit Ihren eigenen Dokumenten: Zu jeder Frage sucht das System die inhaltlich passenden Textabschnitte heraus und gibt sie dem Modell zusammen mit der Frage. Die Antwort entsteht so aus belegtem Firmenwissen statt aus dem Trainingsgedächtnis – aktuell, nachvollziehbar und ohne das Modell neu zu trainieren.

Wie RAG in n8n arbeitet: zwei getrennte Abläufe

RAG besteht aus zwei Pipelines, die man nicht verwechseln darf. Die erste läuft einmalig und danach bei jedem neuen oder geänderten Dokument im Hintergrund. Die zweite läuft bei jeder Frage.

Phase 1 – Dokumente indexieren

Hier werden die Dokumente in eine durchsuchbare Form gebracht. In n8n sind das vier Schritte:

1. Laden: Der Default Data Loader-Knoten liest die Dateien ein – als Binärdaten (PDF, Word) über den passenden MIME-Typ oder als JSON.
2. Zerlegen (Chunking): Ein langes Dokument wird in kleine Abschnitte geschnitten. n8n nutzt dafür standardmäßig den Recursive Character Text Splitter mit einer Chunk-Größe von 1000 Zeichen und einer Überlappung von 200. Die Überlappung sorgt dafür, dass ein Gedanke, der über eine Chunk-Grenze läuft, nicht zerrissen wird.
3. Einbetten (Embeddings): Jeder Chunk wird über einen Embeddings-Knoten (z. B. Embeddings OpenAI oder – lokal – Embeddings Ollama) in einen Vektor umgewandelt: eine lange Zahlenreihe, die die Bedeutung des Textes abbildet. Ähnliche Inhalte bekommen ähnliche Vektoren.
4. Speichern: Die Vektoren landen in einem Vektor-Store, aus dem sie sich später blitzschnell nach Ähnlichkeit durchsuchen lassen.

Phase 2 – Fragen beantworten

Stellt ein Nutzer eine Frage, wird sie mit demselben Embedding-Modell in einen Vektor umgewandelt. Das System sucht im Vektor-Store die inhaltlich nächstliegenden Chunks, hängt sie an den Prompt an und lässt das Chat-Modell daraus die Antwort formulieren. n8n bietet dafür zwei Wege: den Question and Answer Chain-Knoten, der einen Vektor-Store direkt als Retriever nutzt, oder einen AI-Agent, dem der Vektor-Store als Werkzeug (Tool) angehängt wird. Wichtig: In beiden Phasen muss dasselbe Embedding-Modell zum Einsatz kommen – sonst passen die Vektoren nicht zusammen und die Suche liefert Unsinn.

Die Bausteine in n8n

Aufgabe	n8n-Knoten
Dateien einlesen	Default Data Loader
Text in Chunks zerlegen	Recursive Character Text Splitter
Chunks in Vektoren wandeln	Embeddings OpenAI / Embeddings Ollama
Vektoren speichern und suchen	Simple Vector Store / Qdrant / PGVector
Frage beantworten	Question and Answer Chain oder AI-Agent

Diese Knoten steckt man wie Bausteine zusammen. Für die Recherche empfiehlt sich die offizielle n8n-Dokumentation zum Question and Answer Chain und zum Default Data Loader.

Zum Testen reicht der Arbeitsspeicher – im Betrieb nicht

Für erste Experimente gibt es den Simple Vector Store. Er legt die Vektoren im Arbeitsspeicher der n8n-Instanz ab und ist in Sekunden eingerichtet. Die Dokumentation ist hier unmissverständlich: Alle Daten gehen verloren, wenn n8n neu startet, und können bei Speicherknappheit ohnehin verworfen werden. Für ein schnelles Ausprobieren ist das in Ordnung – für eine Wissensdatenbank, die Ihr Team täglich nutzt, nicht.

Für den Produktivbetrieb braucht es einen persistenten Store. n8n bindet unter anderem Qdrant und PGVector (die Vektor-Erweiterung für PostgreSQL, die Sie vielleicht schon im Haus haben) an. Beide sprechen eine benannte Sammlung („Collection“) an, in der die Vektoren dauerhaft liegen. Der praktische Vorteil: Neue Dokumente lassen sich einzeln nachindexieren, ohne alles neu aufzubauen.

Woran RAG in der Praxis scheitert

RAG ist kein Zauberstab, und es lohnt sich, die Schwachstellen vorher zu kennen:

• Datenqualität schlägt durch. n8n formuliert es nüchtern: RAG hängt von der Qualität Ihrer Daten ab. Liegen im Store veraltete Preislisten oder widersprüchliche Versionen desselben Dokuments, antwortet die KI selbstbewusst falsch.
• Chunking will abgestimmt sein. Zu kleine Abschnitte (etwa 200 bis 500 Token) finden sehr gezielt, verlieren aber Kontext. Zu große Chunks tragen mehr Zusammenhang, werden laut Doku aber schnell „diluted or noisy“ – die eigentliche Antwort geht im Rauschen unter. Bei uneinheitlich strukturierten Dokumenten muss man hier nachjustieren.
• Das Modell erfindet weiterhin. RAG reduziert Halluzinationen, es beseitigt sie nicht. Die eigentliche Antwort formuliert immer noch das Sprachmodell – findet die Suche die falschen oder gar keine passenden Chunks, entsteht trotzdem eine glatte, aber falsche Aussage. Deshalb gehört zu einer seriösen RAG-Antwort immer die Quelle: Aus welchem Dokument stammt das? So kann ein Mensch gegenprüfen.
• Der Index veraltet. Ein RAG-System ist nur so aktuell wie sein letzter Indexlauf. Ohne einen Automatismus, der neue und geänderte Dateien nachlädt, beantwortet die KI Fragen auf Basis von letztem Quartal.

DSGVO, Sicherheit und Kosten

Drei Punkte, die in der Begeisterung gern untergehen:

Datenschutz. Ihre Chunks und deren Vektoren enthalten sensibles Firmenwissen – Verträge, Personaldaten, Kalkulationen. Schickt der Embeddings-Knoten diese Texte an einen US-Cloud-Anbieter, verlässt Ihr internes Wissen das Haus. Wer das vermeiden will, betreibt die Einbettung lokal; wie das mit Ollama geht, habe ich in lokale Sprachmodelle DSGVO-konform betreiben beschrieben.

Sicherheit. Die Dokumente, die Sie indexieren, sind eine Angriffsfläche. Enthält eine eingelesene Datei versteckte Anweisungen, kann sie das Modell über die zurückgelieferten Chunks manipulieren – eine indirekte Prompt Injection. Bei Dokumenten aus dem eigenen Haus ist das Risiko kleiner, bei Inhalten von außen sollten Sie es einkalkulieren.

Kosten. Jeder Chunk wird beim Indexieren einmal eingebettet, und jede Frage kostet erneut eine Einbettung plus die eigentliche Generierung. Bei großen Dokumentbeständen summiert sich das. Wie man die laufenden Kosten eines KI-Workflows im Blick behält, ordne ich in KI-Kosten im Workflow ein.

Lohnt sich das für meinen Betrieb?

Als Faustregel: RAG rechnet sich, wenn viele Menschen wiederkehrende Fragen zu einem umfangreichen, sich ändernden Dokumentbestand stellen – etwa im Support, beim Onboarding neuer Mitarbeiter oder in der Angebotserstellung. Geht es dagegen um eine Handvoll stabiler Dokumente, ist eine gut gepflegte Volltextsuche oder ein sauber strukturiertes Wiki oft die ehrlichere Lösung: weniger beweglich, keine Halluzinationsgefahr, kein laufender Modellbetrieb. Und wer den Schritt zum dialogfähigen Assistenten gehen möchte, sollte prüfen, ob es dafür wirklich einen eigenen KI-Agenten braucht oder ob eine schlanke Suchfunktion genügt.

RAG ist mächtig, aber es lebt von der Disziplin dahinter: saubere Quelldokumente, ein durchdachtes Chunking, ein aktueller Index und ein Mensch, der die Antworten stichprobenartig gegenliest. Wenn Sie überlegen, welches Wissen in Ihrem Betrieb sich lohnen würde, durchsuchbar zu machen – und ob RAG oder eine einfachere Suche der richtige Weg ist –, schauen wir uns das im kostenlosen Prozess-Check gemeinsam an.