RAG-Workflows: KI, die deine Daten kennt

🔄 In den letzten Lektionen hast du KI-Agenten mit Tools und Memory gebaut. Dein Agent kann das Web durchsuchen und sich an Konversationen erinnern. Aber er kennt nur öffentliche Informationen. Was, wenn du willst, dass er Fragen zu deinen internen Dokumenten beantwortet? Zu deinem Handbuch, deinen Prozessbeschreibungen, deiner Wissensdatenbank?

Dafür gibt es RAG — Retrieval-Augmented Generation.

Was du lernst

Am Ende dieser Lektion hast du eine funktionierende RAG-Pipeline: Dokumente hochladen, in Vektoren umwandeln, speichern und per KI-Agent abfragen.

RAG in 60 Sekunden

RAG besteht aus zwei Phasen:

Phase 1: Ingestion (einmalig)

Dokumente → Chunks → Embeddings → Vector Store

Phase 2: Abfrage (bei jeder Frage)

Frage → Embedding → Ähnlichkeitssuche → Relevante Chunks → LLM → Antwort

Das ist ja im Grunde wie eine smarte Suchmaschine für deine eigenen Daten. Statt Google zu fragen, fragst du deine Wissensdatenbank — und bekommst eine zusammengefasste Antwort statt einer Liste von Links.

✅ Quick Check: Warum heißt es „Retrieval-Augmented"? (Weil die KI-Antwort durch abgerufene (retrieved) Dokumente ergänzt (augmented) wird. Das LLM generiert nicht aus dem Nichts — es bekommt relevante Textpassagen als Kontext und antwortet basierend darauf. Weniger Halluzinationen, mehr Genauigkeit.)

Phase 1: Ingestion-Pipeline bauen

Schritt 1: Dokumente laden

n8n bietet mehrere Document Loaders:

Für unseren Prototyp nutzen wir den File Loader mit PDFs.

Schritt 2: Text splitten (Chunking)

Dokumente werden in kleinere Stücke geschnitten — sogenannte Chunks. Warum? Zwei Gründe:

1. Embedding-Modelle haben Token-Limits (OpenAI: 8.191 Tokens)
2. Kleinere Chunks = präzisere Suchergebnisse

Text Splitter konfigurieren:

• Chunk Size: 500-1000 Tokens (Standard: 1000)
• Chunk Overlap: 200 Tokens (verhindert, dass Kontext an Chunk-Grenzen verloren geht)

Puh, die richtige Chunk-Größe ist Erfahrungssache. Zu klein → die KI bekommt Schnipsel ohne Kontext. Zu groß → die Suche wird ungenau. 500-1000 Tokens sind ein guter Start.

Schritt 3: Embeddings erstellen

Embeddings wandeln Text in Zahlenvektoren um — so kann der Computer „Ähnlichkeit" berechnen.

Embedding-Node konfigurieren:

1. Füge den „Embeddings OpenAI" Node hinzu
2. Modell: text-embedding-3-small (günstig und gut genug)
3. Credential: Dein OpenAI-Key

Kosten: text-embedding-3-small kostet ~$0.02 pro 1M Tokens. Ein 100-Seiten-Dokument hat 50.000 Tokens → **$0.001 für die gesamte Ingestion**. Quasi kostenlos.

Schritt 4: In Vector Store speichern

Für den Prototyp: In-Memory Vector Store (kein Setup nötig). Für Produktion: PGVector (PostgreSQL-Erweiterung) oder Qdrant.

In-Memory Vector Store:

1. Füge den „In-Memory Vector Store" Node hinzu
2. Verbinde ihn mit dem Embedding-Node
3. Fertig — die Vektoren leben im RAM

PGVector (für Produktion):

1. PostgreSQL mit pgvector-Erweiterung installieren (CREATE EXTENSION vector;)
2. PGVector-Credential in n8n anlegen
3. Table Name: documents (wird automatisch erstellt)
4. Collection Name: z.B. mein_handbuch

✅ Quick Check: Wann solltest du von In-Memory auf PGVector wechseln? (Wenn du mehr als ein paar Dutzend Dokumente hast, wenn die Daten einen Server-Neustart überleben müssen, oder wenn mehrere Nutzer gleichzeitig abfragen. In-Memory ist nur für Prototypen.)

Phase 2: Abfrage-Workflow

Jetzt bauen wir den zweiten Workflow — den, der Fragen beantwortet.

Option A: Question-Answer Chain (einfach)

Chat Trigger → QA Chain → Antwort
                 ↑
            Vector Store + LLM

Die Question and Answer Chain ist der einfachste RAG-Node. Sie:

1. Nimmt die Frage
2. Wandelt sie in ein Embedding um
3. Sucht im Vector Store nach ähnlichen Chunks
4. Schickt Frage + Chunks ans LLM
5. Gibt die Antwort zurück

Konfiguration:

• Top K: 4 (die 4 ähnlichsten Chunks werden verwendet)
• LLM: GPT-4o oder Claude

Option B: Agent mit Vector Store als Tool (flexibel)

Chat Trigger → AI Agent → Antwort
                 ↑
     Tools: Vector Store + Web-Suche
     Memory: PostgreSQL

Hier ist der Vector Store ein Tool, das der Agent nach Bedarf nutzt. Vorteil: Der Agent kann entscheiden, ob er in der Wissensbasis sucht oder eine Web-Suche macht.

Seit n8n v1.74.0 (Januar 2025) können Vector Stores direkt als Agent-Tools verwendet werden — du verbindest den Vector Store einfach unter „Tools" im Agent-Node.

Vector Store Vergleich

Für n8n Self-Hosted ist PGVector oft die beste Wahl — du hast PostgreSQL wahrscheinlich schon für n8n selbst. Einfach die Extension aktivieren und loslegen.

Ingestion-Tipps

Dokument-Qualität > Menge RAG ist so gut wie deine Daten. Schlechte Dokumente = schlechte Antworten. Lieber 50 gut strukturierte Seiten als 500 unformatierte.

Metadata nutzen n8n kann Metadata zu Chunks speichern — Dateiname, Seitenzahl, Kategorie. Das ermöglicht gefilterte Suche:

{
  "text": "Die Kündigungsfrist beträgt 3 Monate...",
  "metadata": {
    "source": "arbeitsvertrag.pdf",
    "page": 12,
    "category": "personal"
  }
}

Regelmäßig aktualisieren Dokumente ändern sich. Plane einen Schedule-Workflow, der die Ingestion regelmäßig ausführt — z.B. wöchentlich oder bei Dateiänderungen.

Wichtigste Erkenntnisse

• RAG besteht aus zwei Phasen: Ingestion (Dokumente → Vektoren) und Abfrage (Frage → relevante Chunks → Antwort)
• Chunking splittet Dokumente in 500-1000 Token-Stücke — kleiner = präziser, größer = mehr Kontext
• Embeddings kosten fast nichts (~$0.001 für 100 Seiten) — die Abfrage-Kosten beim LLM sind relevanter
• In-Memory Vector Store für Prototypen, PGVector oder Qdrant für Produktion
• Vector Stores können seit n8n v1.74.0 direkt als Agent-Tools genutzt werden
• Dokument-Qualität bestimmt die Antwort-Qualität — schlechte Daten rein, schlechte Antworten raus

Nächste Lektion

Du hast jetzt KI-Agenten mit Tools, Memory und RAG. Alles funktioniert im Testmodus. Aber wie bringst du das in Produktion? In der nächsten Lektion lernst du Produktions-Patterns: Fehlerbehandlung, Queue Mode, Monitoring und DSGVO-konforme Deployment-Strategien.