RAG (Retrieval-Augmented Generation) ist ein KI-Architekturmuster, das die Generierung einer Antwort durch ein Sprachmodell mit einem vorgelagerten Abruf relevanter Informationen kombiniert. Statt eine Frage allein aus dem Trainingswissen des Modells zu beantworten, sucht das System zunächst in einer Wissensbasis – etwa Handbüchern, Verträgen, Tickets oder Intranet-Seiten – nach den passenden Textstellen und gibt diese dem Modell als zusätzlichen Kontext mit. Das Modell formuliert die Antwort dann auf Basis dieses bereitgestellten Materials. Der Name beschreibt diese Mechanik exakt: Retrieval (Abruf) erweitert (augmented) die Generation (Erzeugung).
Ein Sprachmodell kennt nur das, was zum Zeitpunkt seines Trainings in den Daten enthalten war. Drei strukturelle Schwächen ergeben sich daraus für den betrieblichen Einsatz. Erstens veraltet das Wissen: Ein Modell, dessen Training Anfang 2025 endete, weiß nichts über die Preisliste von gestern, die neue Betriebsvereinbarung oder das gestern abgeschlossene Projekt. Zweitens fehlt das Spezialwissen: Interne Prozesse, Produktdetails, Kundenhistorien oder firmeneigene Begriffe waren nie Teil des öffentlichen Trainingskorpus – das Modell kann sie schlicht nicht kennen. Drittens neigen Modelle zum Halluzinieren: Fehlt belastbares Wissen, erzeugen sie dennoch flüssige, überzeugend klingende Antworten, die aber faktisch falsch sein können. Gerade die sprachliche Souveränität macht diese Fehler so gefährlich, weil sie nicht als Fehler erkennbar sind.
Für ein Beratungsunternehmen, eine Versicherung oder einen Maschinenbauer bedeutet das: Ein nacktes LLM kann zwar formulieren, aber nicht zuverlässig über das eigene Geschäft Auskunft geben. Genau hier setzt RAG an – es macht aus einem generischen Sprachmodell einen Assistenten, der auf den aktuellen, geprüften Bestand des Unternehmens zugreift.
Die zentrale Verschiebung, die RAG bewirkt, lässt sich auf eine Formel bringen: Das Modell soll nicht aus dem Gedächtnis raten, sondern aus bereitgestellten Quellen antworten. Bildlich gesprochen verwandelt RAG eine Closed-Book-Prüfung – bei der nur das auswendig Gelernte zählt – in eine Open-Book-Prüfung, bei der das Modell vor jeder Antwort die relevanten Seiten aufschlagen darf. Das hat zwei wertvolle Nebeneffekte: Antworten werden aktuell, weil die Wissensbasis jederzeit ergänzt werden kann, ohne das Modell neu zu trainieren, und sie werden belegbar, weil sich jede Aussage auf konkrete Quelldokumente zurückführen lässt.
In der Praxis hat sich RAG seit 2023 von einem akademischen Konzept zum dominierenden Muster für Unternehmens-KI entwickelt. 2026 ist es der Standardweg, um Chatbots, interne Assistenten und Recherchewerkzeuge auf den eigenen Wissensbestand aufzusetzen – weil es im Vergleich zu Alternativen wie Fine-Tuning günstiger, schneller einzuführen und vor allem deutlich transparenter ist.
Bevor RAG eine Frage beantworten kann, muss das Unternehmenswissen durchsuchbar gemacht werden. Dazu werden Quelldokumente eingelesen und in handhabbare Stücke zerlegt (Chunking, siehe Kapitel 04). Jedes Stück wird anschließend durch ein Embedding-Modell in einen numerischen Vektor übersetzt, der die Bedeutung des Textes repräsentiert. Diese Vektoren werden gemeinsam mit dem Originaltext und Metadaten (Quelle, Abteilung, Datum, Berechtigung) in einer Vektordatenbank abgelegt. Das Ergebnis ist ein durchsuchbarer Index, der nicht nach Stichwörtern, sondern nach inhaltlicher Ähnlichkeit funktioniert. Dieser Schritt läuft beim Aufbau einmal vollständig und danach inkrementell, sobald neue oder geänderte Dokumente hinzukommen.
Stellt ein Nutzer eine Frage, durchläuft das System drei Schritte. Im Retrieval wird die Frage selbst in einen Vektor übersetzt und die Vektordatenbank nach den ähnlichsten Textstücken durchsucht – typischerweise werden die fünf bis zwanzig relevantesten Treffer zurückgegeben. In der Augmentation werden diese Treffer in einen Prompt eingebettet: Das System baut eine Anweisung an das Modell, die sinngemäß lautet „Beantworte die folgende Frage ausschließlich auf Basis dieses Kontexts“ und hängt die abgerufenen Textstellen an. In der Generation formuliert das LLM die Antwort aus diesem angereicherten Prompt und kann dabei die Quellen referenzieren. Der Nutzer erhält so eine Antwort, die auf nachprüfbaren Dokumenten beruht.
Entscheidend ist das Zusammenspiel: Eine RAG-Anwendung ist immer nur so gut wie ihr schwächstes Glied. Hervorragende Generation hilft nicht, wenn das Retrieval die falschen Stellen liefert; und das beste Retrieval bringt nichts, wenn die Dokumente schlecht zerlegt wurden. Diese Kette zu beherrschen ist die eigentliche Ingenieursaufgabe hinter RAG.
Ein Embedding ist die Übersetzung eines Textstücks in eine Liste von Zahlen – einen Vektor, der oft mehrere hundert bis einige tausend Dimensionen umfasst. Das Embedding-Modell ist so trainiert, dass inhaltlich ähnliche Texte ähnliche Vektoren erhalten, also im Vektorraum nahe beieinander liegen. „Wie kündige ich meinen Vertrag?“ und „Vertragsbeendigung durch den Kunden“ enthalten kaum gemeinsame Wörter, landen aber dicht beieinander, weil sie dasselbe meinen. Genau das ist der Vorteil gegenüber der klassischen Stichwortsuche: RAG findet die richtige Stelle auch dann, wenn der Nutzer andere Begriffe verwendet als das Dokument. Diese Fähigkeit nennt man semantische Suche.
Die Wahl des Embedding-Modells ist keine Nebensache. Für den deutschsprachigen Raum sind mehrsprachige oder explizit deutsch trainierte Modelle wichtig, weil sie Fachbegriffe, Komposita und Flexionen besser erfassen. Modelle unterscheiden sich in Dimensionalität, maximaler Eingabelänge und Domäneneignung; ein Modell, das für allgemeine Webtexte trainiert wurde, kann bei juristischen oder technischen Inhalten schwächeln.
Eine Vektordatenbank ist auf eine spezielle Aufgabe optimiert: in Millionen von Vektoren blitzschnell die ähnlichsten zu einem Suchvektor zu finden. Ein naiver Vergleich mit jedem einzelnen Eintrag wäre zu langsam, deshalb nutzen Vektordatenbanken Näherungsverfahren (Approximate Nearest Neighbor, etwa über HNSW-Indizes), die nahezu so genau, aber um Größenordnungen schneller sind. Die Ähnlichkeit selbst wird meist über die Kosinus-Distanz gemessen – ein Maß für den Winkel zwischen zwei Vektoren. Neben dem reinen Vektorabruf bieten gute Systeme Metadaten-Filter, mit denen sich die Suche auf bestimmte Abteilungen, Zeiträume oder Berechtigungsgruppen eingrenzen lässt – ein für Datenschutz und Relevanz entscheidendes Feature.
Am Markt existieren spezialisierte Vektordatenbanken ebenso wie Vektor-Erweiterungen klassischer Datenbanken. Für den DACH-Mittelstand ist relevant, dass mehrere dieser Systeme self-hostbar sind und damit vollständig in der eigenen oder einer EU-Infrastruktur betrieben werden können.
Dokumente müssen in Stücke (Chunks) zerlegt werden, weil weder die Embedding-Modelle noch der Kontext des LLM beliebig lange Texte verarbeiten – und weil ein zu großer Chunk die Treffsicherheit verwässert. Die Größe ist ein Balanceakt: Zu kleine Chunks reißen Sinnzusammenhänge auseinander; ein einzelner Satz ohne Umgebung ist oft nicht interpretierbar. Zu große Chunks mischen mehrere Themen, sodass der relevante Kern in irrelevantem Text untergeht und der Embedding-Vektor unscharf wird. In der Praxis bewähren sich mittlere Chunk-Größen mit einem Overlap – einer Überlappung zwischen aufeinanderfolgenden Stücken, damit Sätze, die an einer Chunk-Grenze stehen, nicht verloren gehen.
Über die reine Größe hinaus lohnt es sich, strukturbewusst zu zerlegen: an Überschriften, Absätzen oder semantischen Grenzen statt an festen Zeichenzahlen. Ein Chunk, der genau einem Unterkapitel oder einem Frage-Antwort-Paar entspricht, liefert dem Retrieval ein sauberes, in sich geschlossenes Wissenshäppchen. Tabellen, Listen und Aufzählungen verdienen besondere Behandlung, weil sie beim naiven Zerschneiden ihren Sinn verlieren.
Jeder Chunk sollte mit Metadaten angereichert werden: Quelldokument, Überschriftenpfad, Abteilung, Gültigkeitsdatum und Berechtigungsstufe. Diese Angaben erlauben dem Retrieval, gezielt zu filtern – etwa nur aktuelle Dokumente einer bestimmten Abteilung zu durchsuchen – und sie bilden die Grundlage für Quellenangaben in der Antwort. Eine bewährte Technik ist es, jedem Chunk eine kurze Kontextzeile voranzustellen, die das übergeordnete Dokument und Kapitel benennt, damit auch ein isoliert abgerufener Abschnitt verständlich bleibt.
Mindestens ebenso wichtig ist die Vorverarbeitung der Rohdaten. PDFs mit mehrspaltigem Layout, gescannte Dokumente, Tabellen und Bilder müssen sauber extrahiert werden, sonst landen Layoutartefakte und zerrissene Sätze im Index. Wer hier schludert, vergiftet die gesamte Pipeline an der Quelle – ein Effekt, der sich im laufenden Betrieb kaum noch korrigieren lässt.
RAG versorgt das Modell zur Laufzeit mit abgerufenem Wissen. Es ist die richtige Wahl, wenn es um Faktenwissen geht, das sich häufig ändert, groß ist und belegbar sein muss. Fine-Tuning trainiert das Modell mit Beispieldaten nach und verändert dadurch sein Verhalten – etwa Tonfall, Format oder die Beherrschung einer Fachsprache. Es eignet sich für Stil und Verhalten, nicht für aktuelles Faktenwissen, denn das einmal antrainierte Wissen ist statisch und veraltet ebenso wie das Basismodell. Der lange Kontext nutzt die Fähigkeit moderner Modelle, sehr große Textmengen direkt im Prompt zu verarbeiten: Man gibt die relevanten Dokumente einfach komplett mit. Das ist bestechend einfach, lohnt sich aber nur bei wenigen, überschaubaren Dokumenten – bei jeder Anfrage entstehen Token-Kosten und Latenz, und sehr lange Kontexte verlieren mitunter an Treffsicherheit.
Als Orientierung gilt: Geht es um Wissen, nimm RAG; geht es um Verhalten und Stil, nimm Fine-Tuning; geht es um wenige Dokumente pro Anfrage, reicht oft der lange Kontext. Diese Wege schließen sich nicht aus. Eine häufige Kombination ist ein RAG-System, dessen Sprachmodell zusätzlich leicht feingetunt wurde, damit es im gewünschten Ton antwortet und das firmeneigene Vokabular sicher beherrscht – das Wissen kommt aus dem Retrieval, das Verhalten aus dem Training. Für den Mittelstand ist RAG meist der pragmatische Einstieg, weil es ohne ML-Trainingsexpertise auskommt, mit kleinen Datenmengen startet und sofort nachvollziehbare Ergebnisse liefert.
Die Qualität einer RAG-Antwort hängt überwiegend davon ab, ob das Retrieval die richtigen Stellen geliefert hat. Bringt der Abruf irrelevante oder unvollständige Treffer, kann auch das beste Sprachmodell keine korrekte Antwort bilden – es antwortet dann entweder ausweichend oder, schlimmer, es füllt die Lücke mit plausibel klingender Erfindung. Typische Retrieval-Schwächen sind: zu grobes oder zu feines Chunking, ein Embedding-Modell, das die Domäne nicht versteht, fehlende Stichwortsuche für exakte Begriffe wie Artikelnummern, oder eine Wissensbasis, die die gesuchte Information schlicht nicht enthält. Letzteres ist kein Modellfehler, sondern eine Lücke im Bestand – RAG kann nur wiedergeben, was vorhanden ist.
RAG senkt das Halluzinationsrisiko erheblich, weil das Modell auf konkretem Kontext antwortet statt zu raten. Vollständig verschwinden Halluzinationen aber nicht: Das Modell kann den bereitgestellten Kontext fehlinterpretieren, Informationen über mehrere Chunks hinweg falsch kombinieren oder über die Quellen hinaus generalisieren. Wirksame Gegenmaßnahmen sind eine klare Instruktion, ausschließlich aus dem Kontext zu antworten und bei fehlender Deckung „Das geht aus den Unterlagen nicht hervor“ zu sagen, sowie die konsequente Anzeige der Quellen, damit Nutzer jede Aussage selbst prüfen können. Quellenangaben sind nicht nur ein Komfortmerkmal – sie sind das wichtigste Vertrauensinstrument einer RAG-Anwendung.
Ein RAG-System lässt sich nicht nach Gefühl optimieren. Notwendig ist eine systematische Evaluierung entlang zweier Dimensionen: der Retrieval-Qualität (werden die richtigen Stellen gefunden?) und der Antwortqualität (ist die Antwort treu zum Kontext und beantwortet sie die Frage?). Bewährt hat sich ein Satz repräsentativer Goldfragen mit bekannten Idealantworten, gegen den jede Änderung getestet wird, sowie Metriken wie Treue zum Kontext, Relevanz der Antwort und Präzision des Abrufs. Werkzeuge wie Evaluierungs-Frameworks automatisieren das. Ohne diese Messung gleicht jede Verbesserung einem Glücksspiel – mit ihr wird Optimierung zum kontrollierten Prozess.
Naive RAG ist die Grundform: Frage einbetten, ähnlichste Chunks abrufen, in den Prompt geben, Antwort generieren. Sie ist schnell aufgesetzt und für klar abgegrenzte, gut strukturierte Wissensbasen oft schon erstaunlich gut. Ihre Schwächen zeigen sich bei mehrdeutigen Fragen, bei der Notwendigkeit exakter Begriffstreffer und wenn die relevante Information über viele Dokumente verstreut ist. Als Einstieg und für Piloten ist Naive RAG dennoch der sinnvolle Startpunkt.
Advanced RAG setzt an den Schwächen der naiven Variante an. Hybrid Search kombiniert die semantische Vektorsuche mit klassischer Stichwortsuche und fängt so exakte Begriffe – Produktcodes, Eigennamen, Paragrafen – zuverlässig ab, die rein semantisch leicht verschwimmen. Reranking schaltet hinter den ersten Abruf ein zweites, präziseres Modell, das die Kandidaten neu sortiert und die wirklich passenden nach oben bringt; man ruft bewusst mehr Treffer ab, als man braucht, und lässt den Reranker die besten auswählen. Hinzu kommen Techniken der Query-Optimierung, etwa das Umformulieren oder Aufteilen der Nutzerfrage, um den Abruf zu verbessern. In Summe heben diese Maßnahmen die Trefferqualität deutlich – sie sind der häufigste und lohnendste Schritt nach einem erfolgreichen Piloten.
Agentic RAG geht einen Schritt weiter: Hier entscheidet ein steuerndes Sprachmodell selbst, ob, wo und wie oft es sucht. Es kann eine komplexe Frage in Teilfragen zerlegen, mehrere Quellen nacheinander befragen, Zwischenergebnisse bewerten und bei Bedarf nachfassen – und sogar verschiedene Werkzeuge wie Datenbanken oder Rechenfunktionen einbeziehen. Das ermöglicht mehrstufige Recherchen, die eine einfache Pipeline überfordern würden. Der Preis ist höhere Komplexität, mehr Latenz und schwierigere Vorhersagbarkeit. Agentic RAG lohnt sich für anspruchsvolle Analyse- und Recherche-Szenarien, ist für einen einfachen Wissens-Chatbot aber meist überdimensioniert.
Der entscheidende Hebel für Datenhoheit ist der Verarbeitungsort. Eine RAG-Pipeline berührt mehrere Stationen, an denen Daten anfallen: die Quelldokumente, das Embedding-Modell (das jeden Chunk verarbeitet), die Vektordatenbank (die Vektoren und Originaltext speichert) und das generierende LLM (das die abgerufenen Inhalte sieht). Werden Embedding- und Sprachmodell als Cloud-Dienst außerhalb der EU genutzt, verlassen Unternehmensinhalte die eigene Sphäre. Für datenschutzsensible Anwendungen sind daher EU-gehostete Dienste oder vollständiges Self-Hosting die naheliegende Wahl – mehrere Vektordatenbanken und offene Sprachmodelle lassen sich in der eigenen oder einer souveränen europäischen Infrastruktur betreiben. Wichtig: Auch ein Embedding ist nicht anonym; es kodiert den Inhalt, und der zugehörige Klartext liegt ohnehin im Index. Die gesamte Pipeline ist deshalb datenschutzrechtlich wie der Quellbestand zu behandeln.
RAG darf die im Unternehmen bestehenden Zugriffsrechte nicht aushebeln. Wenn der Vertrieb plötzlich über den Chatbot Personalakten einsehen kann, ist das ein gravierender Verstoß. Deshalb gehört eine Berechtigungsprüfung in das Retrieval: Über Metadaten und Filter wird sichergestellt, dass jeder Nutzer nur Inhalte abgerufen bekommt, für die er berechtigt ist. Hinzu kommen die klassischen DSGVO-Pflichten – Zweckbindung, Datenminimierung, Transparenz und die Wahrung der Betroffenenrechte. Letzteres wirft eine praktische Frage auf: Wird ein Löschbegehren wirksam umgesetzt, müssen das Quelldokument und die daraus abgeleiteten Chunks und Vektoren aus dem Index entfernt werden. Das gehört von Beginn an in die Architektur, weil ein nachträglich gewachsener Index schwer zu bereinigen ist.
Den größten Hebel hat RAG dort, wo viel Wissen in Dokumenten steckt und viele Menschen es immer wieder suchen müssen. Der interne Wissens-Chatbot beantwortet Fragen zu Prozessen, Richtlinien und Produkten aus dem eigenen Intranet, Handbüchern und Wikis – und entlastet damit erfahrene Kolleginnen und Kollegen von wiederkehrenden Auskünften. Im Kundenservice liefert RAG belegte Antworten aus der Wissensdatenbank, beschleunigt die Bearbeitung und ermöglicht verlässlichen Self-Service. In der Dokumenten- und Vertragsrecherche findet es Klauseln, Fristen oder technische Details in großen Beständen, für die manuelle Suche zu langsam wäre. Und im Onboarding gibt es neuen Mitarbeitenden einen geduldigen Ansprechpartner für das gesammelte Hauswissen.
Die Grundsatzfrage lautet, ob ein Unternehmen RAG selbst baut, einen Managed-Dienst nutzt oder eine in bestehende Plattformen integrierte Lösung wählt. Eigenbau mit offenen Frameworks und einer self-hosted Vektordatenbank bietet maximale Kontrolle und Datenhoheit, erfordert aber Entwicklungs- und Betriebskompetenz. Managed-Dienste verkürzen den Weg zur ersten Lösung erheblich, binden aber an einen Anbieter und werfen Fragen zum Verarbeitungsort auf. Integrierte Lösungen innerhalb vorhandener Software-Stacks sind bequem, wenn der passende Stack ohnehin vorhanden ist, schränken aber die Flexibilität ein. Für viele Mittelständler ist ein hybrider Weg sinnvoll: ein schlanker Eigenbau auf bewährten, EU-betreibbaren Komponenten, der Datenhoheit sichert, ohne das Rad neu zu erfinden.
