RAG-Architektur verständlich erklärt

Große Sprachmodelle wie GPT-4, Claude oder Gemini sind beeindruckende Generalisten. Sie kennen aber nicht die Vertragsdaten Ihrer Kunden, nicht Ihre internen Richtlinien, nicht die Produkt-Dokumentation Ihres letzten Release. Sie haben einen Wissens-Cutoff – und sie wurden nicht mit Ihren Daten trainiert.

Es gibt drei Wege, ein LLM mit unternehmensinternem Wissen zu verbinden: Fine-Tuning (Modell-Training), Long-Context-Prompting (alle Daten ins Prompt schreiben), Retrieval-Augmented Generation (relevante Daten zur Laufzeit abrufen). Für die meisten Unternehmens-Use-Cases ist RAG die beste Wahl.

RAG ist günstig (kein Re-Training), aktuell (Daten können sich täglich ändern), nachvollziehbar (Quellenangabe pro Antwort), modular (Wissensbasis austauschbar) und sicher (Berechtigungen pro Datenquelle). Diese Vorteile machen RAG zur Standard-Architektur für Wissens-Agenten in Unternehmen.

Eine produktive RAG-Architektur besteht aus sieben Schichten, die jede für sich Aufmerksamkeit verdient. Wer eine Schicht vernachlässigt, opfert Qualität an unerwarteter Stelle.

RAG ist nur so gut wie die Datenquellen. Typische Quellen: Document-Management-Systeme (DMS), Wikis (Confluence, SharePoint), CRMs/ERPs, Ticketsysteme, Mailsysteme, Datenbanken, Webseiten. Wichtig ist die Inventur: Welche Quellen gibt es, wer hat Zugriff, welche Formate, welche Aktualität, welche Qualität?

Vorverarbeitung ist oft der größte Aufwand. PDFs müssen geparst werden (mit Tabellen-Erkennung), HTML bereinigt, Office-Dokumente konvertiert, OCR für gescannte Dokumente angewandt, Boilerplate entfernt, Sprachen erkannt. Tools: Unstructured.io, LlamaParse, Azure Document Intelligence, Textract, eigene Parser.

Strukturierung verbessert die Retrieval-Qualität dramatisch: Hierarchien (Kapitel, Absatz), Metadaten (Autor, Datum, Geltungsbereich), Tags (Produkt, Region, Vertraulichkeit). Diese Information wird beim Embedding und beim Retrieval genutzt.

Chunking ist die Aufteilung der Quelldokumente in Retrieval-Einheiten. Zu kleine Chunks verlieren Kontext, zu große Chunks enthalten zu viel Irrelevantes. Die Chunk-Strategie hat erheblichen Einfluss auf die Retrieval-Qualität.

Bewährte Strategien: Festgrößen-Chunking (z.B. 500 Token mit 50 Token Overlap), strukturbasiertes Chunking (entlang von Absätzen, Kapiteln), semantisches Chunking (Themenwechsel-Erkennung), hierarchisches Chunking (Eltern-Kind-Beziehungen).

Empfehlung für die meisten Anwendungen: Strukturbasiertes Chunking mit semantischem Fallback, Chunk-Größe 300–800 Token, Overlap 50–100 Token, Eltern-Chunks für Kontext bei Bedarf abrufbar. Bei Tabellen und Listen lohnen sich spezielle Chunking-Strategien.

Embedding-Modelle wandeln Text in numerische Vektoren um. Ähnliche Inhalte erhalten ähnliche Vektoren – das ist die Grundlage der Vektor-Suche. Die Wahl des Embedding-Modells hat erheblichen Einfluss auf die Retrieval-Qualität.

Etablierte Modelle: OpenAI text-embedding-3-large/small, Cohere Embed v3, Voyage AI, Multilingual-E5, BGE-Modelle, Jina Embeddings. Für deutsche Inhalte sind Multilingual-Modelle oder spezialisierte deutsche Modelle vorzuziehen.

Wichtig ist die Konsistenz: Embedding zur Index-Zeit und zur Query-Zeit muss mit demselben Modell erfolgen. Bei Modell-Wechsel müssen alle Vektoren neu berechnet werden – ein Aufwand, den man bei der initialen Wahl bedenken sollte.

Vektor-Datenbanken speichern die Embedding-Vektoren und ermöglichen schnelle Ähnlichkeits-Suche. Der Markt hat sich konsolidiert; etablierte Optionen: Qdrant, Weaviate, Milvus, Pinecone, pgvector (PostgreSQL-Extension), Azure AI Search, Elasticsearch mit Vektor-Support.

Auswahl-Kriterien: Self-Hosting vs. Managed, Skalierungsbedarf, Hybrid-Search-Support, Metadaten-Filter, Performance-Charakteristik, Kostenstruktur, EU-Hosting für DSGVO. Für Mittelstand und Pilotprojekte ist pgvector oft eine pragmatische Wahl, wenn ein PostgreSQL-Stack vorhanden ist.

Wichtige Funktionen einer modernen Vektor-DB: HNSW-Index für schnelle Suche, Filter über Metadaten, Hybrid-Search (Vektor + Keyword), Multi-Tenant-Support, Berechtigungs-Filter, Snapshot/Backup, Observability.

Reine Vektor-Suche (semantische Ähnlichkeit) ist der Standard, aber selten optimal. Hybrid-Search kombiniert Vektor-Suche mit klassischer Keyword-Suche (BM25, sparse Vektoren) und ist in fast allen Fällen besser. Der Effekt ist messbar: 15–25 Prozentpunkte Recall-Verbesserung.

Zusätzlich lohnt sich ein Re-Ranking-Schritt: Die Top-N-Ergebnisse der ersten Suche werden von einem spezialisierten Re-Ranking-Modell (z.B. Cohere Rerank, BGE-Reranker, ms-marco-Modelle) neu sortiert. Effekt: Die wirklich relevanten Treffer rutschen nach oben. Erwartbarer Qualitätsgewinn: 10–20 Prozentpunkte.

Weitere Verbesserungen: Query-Expansion (Anfrage paraphrasiert mit LLM), HyDE (Hypothetical Document Embeddings), strukturierte Filter (Metadaten), parent-child Retrieval (kleines Chunk findet, großes Chunk wird zurückgegeben).

Die Top-Ergebnisse aus dem Retrieval werden zusammen mit der Nutzer-Anfrage in einen Prompt eingefügt und an das LLM gesendet. Wichtig sind die Reihenfolge der Treffer (besteres oben), klare Quellenangaben, Anweisungen an das LLM (z.B. „antworte nur auf Basis der gegebenen Quellen“, „gib bei Unsicherheit explizit an, dass du es nicht weißt“).

Quellenangabe pro Aussage ist Pflicht – sowohl für Vertrauen als auch für Auditierung. Die Antwort sollte mit Hinweisen auf die zugrunde liegenden Dokumente versehen werden, damit der Nutzer die Quellen prüfen kann.

Halluzinations-Schutz: Wenn das Retrieval keine relevanten Treffer liefert, sollte der Agent das transparent kommunizieren („Ich finde dazu keine verlässliche Information“) statt zu halluzinieren. Diese Logik wird über Confidence-Schwellen und Eval-Pipelines abgesichert.

RAG-Evaluation ist mehrdimensional. Mindestens vier Metriken: Recall (wie viele relevante Dokumente wurden gefunden?), Precision (wie viele der gefundenen Dokumente waren relevant?), Faithfulness (basiert die Antwort auf den gefundenen Quellen?), Answer Relevance (beantwortet die Antwort die Frage?).

Tools für RAG-Evaluation: RAGAS, TruLens, Phoenix, Langfuse Evaluations, LangSmith Evals. Sie bieten teils Modell-basierte (LLM-as-a-Judge), teils klassische Metriken. Eine Mischung aus beidem ist Standard.

Wichtig ist eine Eval-Datensatz-Pflege: 100–500 reale Anfragen mit menschlich erstellten Goldantworten. Dieser Datensatz wird regelmäßig erweitert und ist die Grundlage für jedes Architektur-Experiment.

RAG-Systeme verarbeiten oft sensible Daten. Drei Bausteine sind zentral: Berechtigungs-Filter zur Retrieval-Zeit (Agent sieht nur, was Nutzer sehen darf), Quellen-Audit (welche Dokumente wurden für welche Antwort genutzt), Verschlüsselung in Transit und at rest.

Berechtigungen werden über Metadaten-Filter realisiert: Jedes Chunk trägt Berechtigungs-Metadaten (z.B. Abteilung, Sicherheitsstufe). Beim Retrieval wird gegen die Nutzer-Identität gefiltert. Implementierung muss aus dem Quellsystem (z.B. SharePoint-Berechtigungen) abgeleitet und konsistent gepflegt werden.

Für DSGVO und EU AI Act ist die Quellen-Auditierung pro Antwort wichtig: Welche personenbezogenen Daten wurden in der Antwort verwendet, woher kamen sie, gab es eine Rechtsgrundlage. Diese Information muss systematisch gespeichert und auswertbar sein.

RAG-Kosten gliedern sich in vier Blöcke: Embedding-Kosten (einmalig pro Dokument, wiederholt bei Updates), Storage-Kosten (Vektor-DB), Retrieval-Kosten (pro Anfrage), LLM-Kosten (pro Anfrage, dominant). Bei großen Wissensbasen können Embedding und Storage relevant werden, bei hohem Anfragevolumen sind LLM-Kosten dominant.

Optimierungs-Hebel: Modell-Routing (kleines Modell für einfache Anfragen, großes Modell für komplexe), Caching (gleiche Anfragen werden gecacht), kleinere Embedding-Modelle (text-embedding-3-small statt -large), kürzere Chunks zur Token-Reduktion, gezielte Top-K-Wahl statt Top-50.

Klassisches RAG ist ein einmaliger Retrieval-Schritt vor der LLM-Antwort. Moderne Patterns gehen weiter:

Agentic RAG: Der Agent entscheidet selbst, ob und wie oft er retrieval-en muss, kombiniert mehrere Retrieval-Schritte mit Reasoning. Höhere Qualität bei komplexen Fragen, höhere Kosten und Latenz.

Self-RAG: Das Modell evaluiert die Retrieval-Ergebnisse selbst und entscheidet über Re-Retrieval oder direkte Antwort. Robusterer Halluzinations-Schutz.

Graph-RAG: Statt isolierter Chunks wird ein Wissens-Graph aufgebaut, der semantische Beziehungen zwischen Entitäten abbildet. Sehr stark bei Fragen, die über mehrere Dokumente verstreut sind.