Wie RAG funktioniert: Architektur in vier Schritten
Auf einen Satz verkürzt läuft jede RAG-Anwendung in vier Schritten ab:
- Ingestion und Chunking: Quelldokumente werden eingelesen, bereinigt und in sinnvolle Abschnitte zerlegt.
- Embedding und Vektorindex: Jeder Abschnitt wird in einen Bedeutungsvektor übersetzt und in einem Index abgelegt.
- Retrieval: Zu jeder Nutzerfrage werden die inhaltlich passendsten Abschnitte aus dem Index geholt.
- Generation mit Kontext: Das Sprachmodell formuliert die Antwort ausschließlich auf Basis der gefundenen Abschnitte – idealerweise mit Quellenangabe.
Die ersten beiden Schritte bilden die Vorbereitung der Wissensbasis (Indexierung), die letzten beiden die Beantwortung einer Anfrage (Abruf und Generierung).
Phase 1: Die Wissensbasis aufbauen
Zunächst werden die Quelldokumente — PDFs, Wiki-Seiten, Produktdaten, Support-Tickets — in handhabbare Abschnitte zerlegt, sogenannte Chunks. Jeder Chunk wird durch ein Embedding-Modell in einen Zahlenvektor übersetzt, der seine inhaltliche Bedeutung repräsentiert. Diese Vektoren landen in einer Vektordatenbank, die semantische Ähnlichkeitssuche in Millisekunden beherrscht. Inhaltlich verwandte Texte liegen in diesem Vektorraum nah beieinander — auch wenn sie kein einziges gemeinsames Wort enthalten.
Phase 2: Anfrage, Abruf, Antwort
Stellt ein Nutzer eine Frage, durchläuft sie denselben Weg: Die Frage wird in einen Vektor übersetzt, die Vektordatenbank liefert die inhaltlich ähnlichsten Chunks zurück, und diese Fundstellen werden zusammen mit der ursprünglichen Frage in den Prompt des Sprachmodells eingebettet — hier fließen die Disziplinen RAG und Prompt Engineering zusammen. Das Modell formuliert die Antwort ausschließlich auf Basis des mitgelieferten Kontexts, idealerweise mit Quellenangabe. Moderne Systeme ergänzen diesen Kern um weitere Stufen: hybride Suche (Vektor- plus Stichwortsuche), Re-Ranking der Treffer und Filterung nach Zugriffsrechten.
RAG vs. Fine-Tuning – oder großes Kontextfenster?
RAG ist nicht der einzige Weg, einem Modell zusätzliches Wissen beizubringen. Die drei gängigen Ansätze lösen aber unterschiedliche Probleme:
In der Praxis schließen sich die Ansätze nicht aus: Ein feingetuntes Modell kann in einer RAG-Architektur laufen, und für kleine Wissensmengen ist das große Kontextfenster oft die einfachste Lösung. Als Faustregel gilt: Geht es um Faktenwissen, das sich ändert, ist RAG der richtige Hebel. Geht es um Verhalten des Modells, ist Fine-Tuning der richtige.
RAG vs. Fine-Tuning im direkten Vergleich
Realbeispiel: Support-Assistent im E-Commerce
Ein mittelständischer Onlinehändler mit rund 40.000 Artikeln möchte seinen Kundenservice entlasten. Ein klassischer Chatbot scheitert dort regelmäßig: Fragen wie „Passt das Ersatzteil X an Modell Y von 2019?" lassen sich nicht mit vorformulierten Antworten abdecken, und ein reines Sprachmodell würde mangels Produktwissen raten.
Die RAG-Lösung: Produktdatenblätter, Kompatibilitätslisten, Versand- und Retourenrichtlinien sowie die häufigsten gelösten Support-Tickets werden in Chunks zerlegt, eingebettet und indexiert. Fragt ein Kunde nach der Kompatibilität, findet das Retrieval die passende Kompatibilitätsliste und das zugehörige Datenblatt, und das Modell formuliert daraus eine konkrete, belegbare Antwort — inklusive Link auf die Quelle. Ändert sich eine Retourenfrist, wird nur das betreffende Dokument neu indexiert; fünf Minuten später antwortet der Assistent korrekt. Kein Nachtraining, keine Codeänderung. Genau diese Eigenschaft macht RAG für den Mittelstand attraktiv: Die Wissenspflege bleibt dort, wo sie heute schon stattfindet — in den Dokumenten.
Typische Stolperfallen in RAG-Projekten
So elegant das Muster ist, so viele Projekte bleiben hinter den Erwartungen zurück. Die häufigsten Ursachen liegen fast nie im Sprachmodell, sondern in der Datenaufbereitung und im Retrieval:
- Schlechte Chunking-Strategie: Werden Dokumente stumpf alle 500 Zeichen zerschnitten, reißen Tabellen, Aufzählungen und Sinnzusammenhänge auseinander. Das Retrieval findet dann Fragmente, mit denen das Modell nichts anfangen kann.
- Veraltete oder widersprüchliche Quellen: RAG macht die Wissensbasis zur einzigen Wahrheit. Liegen dort drei Versionen derselben Preisliste, zitiert das System irgendwann die falsche. Datenhygiene ist kein Vorprojekt, sondern Teil des Betriebs.
- Fehlende Rechteprüfung: Das Retrieval muss Zugriffsrechte respektieren. Ein Assistent, der Gehaltslisten an jeden ausliefert, der geschickt fragt, ist ein Datenschutzvorfall mit Ansage.
- Kein Umgang mit „nicht gefunden": Liefert das Retrieval nichts Brauchbares, muss das System das sagen — statt das Modell frei fantasieren zu lassen. Ein ehrliches „dazu liegt mir nichts vor" ist der halbe Wert einer RAG-Anwendung.
- Fehlende Evaluation: Ohne ein Testset aus realen Fragen mit erwarteten Antworten lässt sich nicht messen, ob eine Änderung an Chunking, Embedding-Modell oder Prompt die Qualität verbessert oder verschlechtert.
Datenschutz und DSGVO: warum RAG im Mittelstand punktet
Ein oft unterschätzter Vorteil von RAG liegt im Datenschutz. Beim Fine-Tuning wandern Unternehmensdaten dauerhaft in die Gewichte eines Modells — was einmal eintrainiert ist, lässt sich weder gezielt löschen noch auskunftsfähig machen. Bei RAG bleiben die Dokumente dagegen in einer normalen Datenbank unter eigener Kontrolle. Löschpflichten nach Art. 17 DSGVO lassen sich erfüllen, indem das betreffende Dokument aus dem Index entfernt wird; Auskunftsersuchen lassen sich beantworten, weil nachvollziehbar ist, welche Quellen gespeichert sind. An das Sprachmodell gehen Inhalte nur anfragebezogen als Kontext — bei einem EU-gehosteten Anbieter mit Auftragsverarbeitungsvertrag oder einem selbst gehosteten Modell ist damit ein sauberer, dokumentierbarer Datenfluss möglich. Für Unternehmen mit sensiblen Beständen ist genau diese Trennung von Wissen und Modell häufig das entscheidende Argument für RAG.
Varianten: von Naive RAG bis GraphRAG
Unter dem Oberbegriff haben sich mehrere Ausbaustufen etabliert. Naive RAG bezeichnet die Grundform: einbetten, suchen, antworten — schnell gebaut, aber anfällig für schwache Treffer. Advanced RAG ergänzt Optimierungen vor und nach dem Abruf: Anfragen werden umformuliert oder in Teilfragen zerlegt (Query Rewriting), Treffer durch ein Re-Ranking-Modell neu sortiert und Metadaten-Filter (Datum, Abteilung, Sprache) angewendet. GraphRAG verbindet die Vektorsuche mit einem Wissensgraphen, der Beziehungen zwischen Entitäten abbildet — nützlich, wenn Antworten Zusammenhänge über viele Dokumente hinweg erfordern, etwa „welche Kunden sind von der Änderung an Produkt X betroffen?". Für die meisten Mittelstandsprojekte ist Advanced RAG der realistische Zielzustand; GraphRAG lohnt erst bei komplex vernetzten Datenbeständen.
RAG und KI-Agenten
In modernen Architekturen ist RAG selten ein Einzelsystem, sondern ein Baustein: KI-Agenten nutzen Retrieval als eines von mehreren Werkzeugen. Statt dass jede Anfrage stur denselben Abruf-Pfad durchläuft, entscheidet der Agent selbst, ob und welche Wissensquelle er befragt — man spricht dann von Agentic RAG. Der Agent kann eine Suche mehrfach mit umformulierten Anfragen wiederholen, Ergebnisse aus verschiedenen Quellen kombinieren und bei Widersprüchen nachrecherchieren. Damit wandert die Retrieval-Logik vom starren Pipeline-Design in die Planungsschleife des Agenten — mit allen Chancen und Kontrollanforderungen, die Agentensysteme mit sich bringen.
Wie viel Aufbau-Aufwand realistisch ist, hängt fast vollständig vom Zustand der Quelldaten ab. Ein sauber gepflegtes Confluence-Wiki oder strukturierte Produktdaten lassen sich in wenigen Tagen indexieren. Ein historisch gewachsener Ablageordner mit gescannten PDFs, Duplikaten und veralteten Versionen braucht dagegen zuerst eine Bereinigungsrunde — und genau dort entscheidet sich, ob die spätere Anwendung vertrauenswürdige oder zufällige Antworten liefert. Eine ehrliche Ist-Aufnahme der Datenlage gehört deshalb an den Anfang jedes RAG-Projekts, nicht an dessen Ende.
Fazit
Retrieval Augmented Generation ist der pragmatischste Weg, Sprachmodelle mit aktuellem und unternehmenseigenem Wissen zu verbinden: aktualisierbar ohne Nachtraining, zitierfähig, datenschutzfreundlich, weil die Dokumente in der eigenen Infrastruktur bleiben. Der Erfolg entscheidet sich dabei weniger an der Modellwahl als an handwerklichen Fragen — Datenqualität, Chunking, Rechtekonzept und Evaluation. Wer diese Grundlagen sauber baut, bekommt mit RAG den Baustein, der aus einem generischen Sprachmodell einen Assistenten mit echtem Firmenwissen macht — eine Kernaufgabe jeder fundierten KI-Beratung.
Häufige Fragen zu Retrieval Augmented Generation
Verhindert RAG Halluzinationen vollständig?
Nein, aber es reduziert sie deutlich und macht sie überprüfbar. Das Modell kann mitgelieferte Quellen falsch zusammenfassen oder trotz Kontext eigenes „Wissen" einmischen. Quellenzitate, ein striktes „nur aus dem Kontext antworten" im Prompt und ein definiertes Verhalten bei fehlenden Treffern sind deshalb Pflicht.
Braucht jedes RAG-System eine Vektordatenbank?
Für semantische Suche ist eine Vektordatenbank der Standard, aber kein Dogma. Kleine Bestände funktionieren auch mit klassischer Volltextsuche oder einer Kombination aus beidem (hybride Suche). Entscheidend ist, dass das Retrieval die tatsächlich relevanten Passagen findet — mit welcher Technik, ist zweitrangig.
Was kostet der Betrieb einer RAG-Anwendung?
Die laufenden Kosten setzen sich aus Embedding- und LLM-API-Aufrufen (oder eigener Modell-Infrastruktur), dem Betrieb der Vektordatenbank und der Datenpflege zusammen. Für typische Mittelstands-Szenarien liegen die reinen Modellkosten pro Anfrage im Cent-Bereich; der größere Posten ist erfahrungsgemäß die initiale Datenaufbereitung. Eine erfahrene KI-Agentur hilft, genau diesen Aufwand realistisch einzuschätzen und die passende RAG-Architektur zu wählen.
RAG ist kein Produkt, sondern ein Architekturmuster – ob eine konkrete Anwendung DSGVO-konform ist, entscheidet sich an Hosting und Datenfluss. Weil die Dokumente in einer eigenen Datenbank liegen und nur anfragebezogen als Kontext an das Modell gehen, lässt sich der Datenfluss gut dokumentieren und auf EU-Hosting oder ein selbst betriebenes Modell beschränken. Löschpflichten erfüllst du über den Index, nicht über ein Nachtraining. Ein Auftragsverarbeitungsvertrag mit dem Modellanbieter bleibt Pflicht, sobald personenbezogene Daten im Kontext landen.
Brauche ich für RAG ein eigenes Modell?
Nein. RAG funktioniert mit jedem aktuellen Sprachmodell – über eine API eines EU-gehosteten Anbieters oder mit einem offenen Modell auf eigener Infrastruktur. Das Firmenwissen steckt in der Wissensbasis, nicht im Modell; das Modell muss nur gut aus mitgeliefertem Kontext antworten können.
RAG oder Fine-Tuning – was zuerst?
In den meisten Unternehmensprojekten zuerst RAG. Es ist schneller aufgesetzt, hält das Wissen aktuell und liefert Quellenangaben. Fine-Tuning lohnt sich erst, wenn das Modell dauerhaft anders antworten soll – in einem bestimmten Ton, Format oder Fachjargon – und bleibt auch dann meist eine Ergänzung innerhalb einer RAG-Architektur.
Du willst Firmenwissen per RAG nutzbar machen? Dann RAG-Wissensassistenten entwickeln lassen – mit Berechtigungsprüfung, Quellenangaben und EU-Hosting.
