Was ist RAG in der KI

RAG (Retrieval-Augmented Generation) verbindet große Sprachmodelle mit externen Wissensquellen, damit sie Antworten aus echten Daten erzeugen statt aus dem Gedächtnis ihres Trainings. Statt sich darauf zu verlassen, was das Modell aus seinem Trainingskorpus „behält“, ruft RAG zuerst passende Dokumente ab und erzeugt die Antwort dann aus diesem abgerufenen Kontext.

So kommen KI-Systeme im Unternehmen zu korrekten, überprüfbaren und aktuellen Antworten. Fragen Sie ein Sprachmodell nach der Rückgaberegelung Ihres Unternehmens, erfindet es aus seinen Trainingsdaten eine plausibel klingende Regelung. Ein RAG-System ruft das tatsächliche Regelungsdokument ab und erzeugt eine Antwort, die konkrete Klauseln nennt. Der Unterschied ist der zwischen einer selbstbewussten Vermutung und einer belegten Auskunft.

So funktioniert RAG

RAG läuft in zwei Stufen ab, die innerhalb einer einzigen Anfrage stattfinden. Diese Stufen zu verstehen ist wesentlich, denn jede hat eigene Fehlerbilder.

Stufe 1, der Abruf. Die Anfrage des Nutzers wird von demselben Embedding-Modell, das die Wissensbasis indexiert hat, in einen Vektor umgewandelt. Dieser Vektor wird per Ähnlichkeitssuche mit den gespeicherten Dokumentvektoren verglichen, und die k ähnlichsten Chunks (Textabschnitte) werden abgerufen. Fragt ein Produktmanager „Wie ist unsere Rückgaberegelung für Unternehmenslizenzen?“, löst das eine Suche über alle indexierten Dokumente aus. Der Retriever liefert die drei semantisch ähnlichsten Chunks zurück, im Idealfall die tatsächliche Vertragsvorlage und den Abschnitt zur Regelung.

Stufe 2, die Erzeugung. Die abgerufenen Dokumente werden zusammen mit der ursprünglichen Frage in den Prompt des LLM eingesetzt. Das Modell erzeugt eine Antwort, die sich auf den abgerufenen Kontext stützt statt auf seine Trainingsdaten. Ein gut gebauter Prompt weist das Modell an, seine Quellen zu nennen und „Dazu habe ich nicht genug Informationen“ zu sagen, wenn die abgerufenen Dokumente die Frage nicht beantworten. Das hindert das Modell daran, Lücken mit Erfundenem zu füllen.

Entscheidend ist, dass Abruf und Erzeugung entkoppelt sind. Die Wissensbasis lässt sich aktualisieren, ohne das Modell neu zu trainieren. Das Modell lässt sich austauschen, ohne die Wissensbasis neu aufzubauen. Genau diese Trennung macht RAG für Unternehmen praktikabel, in denen sich Informationen häufig ändern.

Die vier Bausteine

Ein RAG-System besteht aus vier Bausteinen, jeder mit eigenen Fehlerbildern und eigenen Entscheidungen bei der Konfiguration.

Wissensbasis, der Bestand an Informationen, aus dem das System abruft. Das können interne Dokumente sein, Wikis, Produktspezifikationen, Vertragsvorlagen, Einträge aus dem Datenkatalog oder API-Endpunkte. Die Wissensbasis ist keine statische Halde, sie braucht Pflege. Doppelte Dokumente, widersprüchliche Fassungen und veraltete Inhalte verschlechtern die Abrufqualität. Wer 50.000 ungeprüfte Dokumente in eine Vektordatenbank kippt, bekommt ein RAG-System, das widersprüchliche Antworten abruft.

Embedding-Modell, es wandelt Text in dichte Zahlenvektoren um, die die Bedeutung abbilden. Das Embedding-Modell entscheidet darüber, was als „ähnlich“ gilt. Ein Allzweckmodell (etwa text-embedding-3 von OpenAI oder quelloffene Alternativen wie E5) reicht für breite Anwendungsfälle. Fachspezifische Embedding-Modelle, auf Branchentexte nachtrainiert, schneiden bei speziellem Vokabular besser ab, wo Allzweckmodelle die Nuancen verfehlen. Das Embedding-Modell muss beim Indexieren und beim Abfragen dasselbe sein: Unterschiedliche Modelle erzeugen bedeutungslose Ähnlichkeitswerte.

Vektordatenbank, sie speichert die Dokumentvektoren und ermöglicht schnelle Ähnlichkeitssuche. Zur Wahl stehen Pinecone (verwaltet, niedrige Latenz), Weaviate (quelloffen, hybride Suche), Chroma (leichtgewichtig, entwicklerfreundlich) und pgvector (PostgreSQL-Erweiterung für Teams, die keine weitere Datenbank aufnehmen wollen). Die Wahl hängt an Größenordnung, Latenzanforderungen und daran, ob das Team verwaltete Dienste oder eigenen Betrieb bevorzugt.

Sprachmodell, es erzeugt die endgültige Antwort aus dem abgerufenen Kontext. Das Modell erhält einen Prompt mit der Frage des Nutzers und den abgerufenen Dokumenten und liefert eine Antwort, die in diesem Kontext verankert ist. Modelle wie GPT-4, Claude oder quelloffene Alternativen (Llama, Mistral) können diesen Baustein übernehmen. Größere Modelle verarbeiten mehr abgerufenen Kontext und fassen kohärenter zusammen, kosten aber mehr pro Anfrage.

Architekturmuster

RAG-Architekturen reichen vom schlichten Abrufen und Erzeugen bis zu mehrstufigen, agentengesteuerten Abläufen. Welches Muster passt, hängt an der Komplexität der Anfragen und an den Genauigkeitsanforderungen.

Naive RAG, ein einzelner Abrufdurchlauf, die Treffer wandern in den Prompt, ein Erzeugungsschritt. Einfach umzusetzen und tragfähig für geradlinige Faktenfragen. Es scheitert an komplexen Anfragen, die Schlüsse über mehrere Dokumente hinweg verlangen, oder wenn die beste Antwort nicht unter den k besten Treffern liegt.

Advanced RAG ergänzt das Umschreiben der Anfrage (die Frage des Nutzers wird für den Abruf neu formuliert), hybride Suche (Stichwortsuche verbunden mit semantischer Ähnlichkeit) und Re-Ranking (ein zweites Modell bewertet die abgerufenen Dokumente nach Relevanz, bevor sie an den Generator gehen). Diese Verbesserungen steigern die Abrufpräzision deutlich, ohne die grundlegende Architektur zu ändern.

Modular RAG behandelt jede Stufe der Pipeline als austauschbaren Baustein. Retriever, Ranker und Generator lassen sich unabhängig voneinander tauschen. Ein juristisches Frage-Antwort-System nutzt vielleicht einen fachspezifischen Retriever mit einem Allzweckgenerator, während ein System im Kundenservice einen leichtgewichtigen Retriever mit einem auf Gesprächston nachtrainierten Generator verbindet.

Agentic RAG, hier entscheidet ein autonomer Agent, wann und was abgerufen wird. Bei einer komplexen Frage wie „Vergleiche unseren Umsatz im dritten Quartal zwischen EMEA und APAC und erkläre den Unterschied“ geht ein Agentic-RAG-System womöglich so vor: (1) Definitionen der Umsatzdaten aus dem Datenkatalog abrufen, (2) die Analysedatenbank abfragen, (3) regionalen Kontext aus internen Berichten abrufen und (4) die Erkenntnisse zusammenführen. Über das Model Context Protocol (MCP) greifen Agentic-RAG-Systeme programmatisch auf gesteuerte Metadaten zu und fragen den Katalog nach Kennzahlendefinitionen, Datenaktualität und Verantwortung ab, bevor sie eine Antwort erzeugen.

Warum RAG für KI im Unternehmen zählt

Fünf Eigenschaften machen RAG zur Standardarchitektur für KI-Systeme im Unternehmen, die korrekt und prüfbar sein müssen.

Es senkt Halluzinationen. Ein LLM ohne RAG erfindet Antworten, wenn es etwas nicht weiß. Ein LLM mit RAG erzeugt Antworten aus abgerufenen Dokumenten und lässt sich anweisen, „Das weiß ich nicht“ zu sagen, wenn der abgerufene Kontext die Antwort nicht enthält. Für ein Rechtsteam, das KI für Compliance-Fragen einsetzt, ist der Unterschied zwischen einer erfundenen Antwort und dem Hinweis auf fehlende Informationen der Unterschied zwischen einem nützlichen Werkzeug und einem Haftungsrisiko.

Es hält KI aktuell. Ein großes Sprachmodell neu zu trainieren kostet Millionen und dauert Wochen. Eine RAG-Wissensbasis zu aktualisieren dauert Stunden. Veröffentlicht Ihr Unternehmen eine neue Preisregelung, nehmen Sie das Dokument in die Wissensbasis auf, und das RAG-System liefert die neue Regelung bei der nächsten Anfrage. Kein erneutes Training nötig.

Es bringt Fachwissen ohne Fine-Tuning. Verbinden Sie das LLM mit Ihrer internen Dokumentation, Ihren Produktkatalogen und Ihren Compliance-Regeln. Das Modell muss nicht auf Ihren eigenen Daten trainiert werden, es muss sie nur zur Laufzeit abrufen. So bedient ein einziges Allzweckmodell Marketing, Entwicklung, Recht und Finanzen, jeweils an die eigene Wissensbasis angebunden.

Es schafft Prüfbarkeit. Jede RAG-Antwort kann ihre Quelldokumente nennen. Fragt ein Compliance-Verantwortlicher „Woher stammt diese Antwort?“, verweist das System auf bestimmte Absätze in bestimmten Dokumenten. Diese Belegkette ist in regulierten Branchen unverzichtbar, wo KI-erzeugte Antworten auf maßgebliche Quellen zurückführbar sein müssen.

Es kostet weniger als Fine-Tuning. Fine-Tuning verlangt GPU-Rechenleistung, aufbereitete Trainingsdaten und laufende Pflege, während das Modell von den aktuellen Fakten wegdriftet. RAG verlangt nur die Aufnahme der Dokumente, also Embedding und Indexierung. Für Organisationen mit häufig wechselnden Informationen ist RAG im Unterhalt dramatisch günstiger als ein nachtrainiertes Modell, das regelmäßig erneut trainiert werden muss.

RAG und Fine-Tuning

RAG und Fine-Tuning lösen verschiedene Probleme. Wer sie vermengt, bekommt Systeme, die entweder kenntnisreich, aber schlecht formatiert sind oder gut formatiert und sachlich falsch.

Nehmen Sie RAG, wenn: sich die Informationen häufig ändern (Regelungen, Produktspezifikationen, Preise), Sie Quellenangaben für Compliance oder Vertrauen brauchen, Sie mehrere Wissensgebiete aus einem Modell bedienen oder Ihnen das GPU-Budget für Fine-Tuning-Zyklen fehlt.

Nehmen Sie Fine-Tuning, wenn: das Modell ein bestimmtes Ausgabeformat, einen bestimmten Ton oder ein bestimmtes Denkmuster übernehmen soll. Fine-Tuning bringt dem Modell bei, wie es antwortet. RAG liefert, womit es antwortet. Ein auf einfühlsame, strukturierte Antworten nachtrainierter Servicebot, verbunden mit RAG-Abruf aus der Produktdokumentation, gibt Ihnen beides: das richtige Verhalten und die richtigen Fakten.

In der Praxis verbinden produktive Systeme beides. Fine-Tuning formt das Verhalten des Modells, also Antwortformat, Ton und den Umgang mit Randfällen. RAG liefert die sachliche Verankerung, also aktuelle Daten, konkrete Dokumente, Fachwissen. Wer Faktenwissen ins Fine-Tuning steckt, erhält ein Modell, das sich ohne erneutes Training nicht aktualisieren lässt. Wer Verhalten über RAG-Prompts formen will, erhält uneinheitliche Ausgaben, die mit dem abgerufenen Kontext schwanken.

Die Wissensbasis entscheidet

Die Qualität von RAG ist durch die Qualität der Wissensbasis begrenzt. Das Modell kann nur Antworten erzeugen aus dem, was der Retriever findet, und der Retriever findet nur, was in der Wissensbasis liegt. Jedes Problem der Wissensbasis wird zu einem Problem der RAG-Ausgabe.

Veraltete Dokumente ergeben veraltete Antworten. Liegt in der Wissensbasis das Preisdokument des Vorjahres neben dem diesjährigen, kann der Retriever beide zurückgeben. Das Modell erzeugt eine Antwort mit den falschen Preisen, und der Nutzer vertraut ihr, weil die Quellenangabe maßgeblich aussieht. Die Pflege der Wissensbasis, also überholte Dokumente entfernen, Fassungen kennzeichnen, Aktualität halten, ist nicht optional.

Doppelte Inhalte verschlechtern den Abruf. Steht dieselbe Regelung in fünf leicht abweichenden Dokumenten, liefert der Retriever fünf Varianten derselben Information und verdrängt damit andere passende Treffer. Doppelte Einträge zu bereinigen und eine kanonische Quelle zu bestimmen sind Voraussetzungen für guten Abruf.

Widersprüchliche Informationen ergeben widersprüchliche Antworten. Das Wiki von Abteilung A sagt, die Rückgabefrist betrage 30 Tage, die FAQ von Abteilung B sagt 60. Das RAG-System nennt selbstbewusst das Dokument, das es zuerst abruft. Ein Prozess für Data Governance, der maßgebliche Quellen bestimmt, verhindert das, genauso wie ein Business Glossary widersprüchliche Kennzahlendefinitionen in der Analytik verhindert.

Die Chunking-Strategie bestimmt die Kontextqualität. Dokumente werden für Embedding und Abruf in Chunks zerlegt. Zu kleine Chunks verlieren Kontext: „30 Tage“ ohne den einschränkenden Zusatz „nur für Unternehmenslizenzen“ ergibt eine unvollständige Antwort. Zu große Chunks verwässern das semantische Signal und verschwenden Platz im Kontextfenster. Gutes Chunking verlangt ein Verständnis der Dokumentstruktur, nicht nur einen Schnitt nach fester Zeichenzahl.

Das Muster ist eindeutig: Organisationen, die in die Governance ihrer Wissensbasis investieren, also Quellen pflegen, Doppeltes entfernen, Fassungen führen und maßgebliche Dokumente bestimmen, bekommen verlässliches RAG. Wer ungesteuerte Inhalte in eine Vektordatenbank kippt, bekommt ein System, das selbstbewusst klingt und dabei das falsche Dokument zitiert.

Hürden in der Umsetzung

Die Abrufqualität ist der Engpass. Ein RAG-System ist nur so gut wie seine Abrufstufe. Liefert der Retriever unpassende Dokumente, erzeugt der Generator Antworten, die in unpassendem Kontext verankert sind, und das ist schlimmer als gar keine Verankerung. Den Abruf zu verbessern verlangt Aufmerksamkeit für die Wahl des Embedding-Modells, die Chunking-Strategie und die hybride Suche (semantische und Stichwortsuche verbunden). Die meiste Fehlersuche bei RAG beginnt und endet in der Abrufstufe.

Grenzen des Kontextfensters erzwingen Kompromisse. Sprachmodelle haben endliche Kontextfenster, also eine Obergrenze für den Text, den sie in einer Anfrage verarbeiten. Zu viele abgerufene Dokumente in den Prompt zu stopfen sprengt das Fenster oder verschlechtert die Leistung des Modells. Zu wenige abzurufen riskiert, die passende Antwort zu verfehlen. Re-Ranking-Modelle helfen, indem sie die abgerufenen Chunks vor dem Einsetzen nach Relevanz bewerten, damit der begrenzte Platz an die relevantesten Inhalte geht.

Veraltete Wissensbasen ergeben veraltete Antworten. Aktualisiert niemand die Dokumente, ruft RAG überholte Informationen ab und gibt sie als aktuell aus. Organisationen brauchen Prozesse zur Auffrischung der Inhalte: automatische Prüfungen auf das Alter von Dokumenten, Anbindung an Content-Management-Systeme und Hinweise, wenn sich maßgebliche Quellen ändern. Metadaten zur Aktualität eines Dokuments sind so wichtig wie die Dokumente selbst.

Latenz summiert sich. RAG fügt jeder Anfrage Abrufaufwand hinzu: die Anfrage einbetten, die Vektordatenbank durchsuchen und zusätzlichen Kontext im LLM verarbeiten. Für interaktive Anwendungen muss diese Latenz unter wenigen Sekunden bleiben. Den Abruf zu beschleunigen (effiziente Vektorindizes, Zwischenspeichern häufiger Anfragen) und den Kontext zu begrenzen (weniger, dafür passendere Chunks abrufen) hält die Latenz beherrschbar.

Wie Dawiso RAG ermöglicht

Der Datenkatalog und das Business Glossary von Dawiso sind die gesteuerte Wissensbasis, die RAG-Systeme im Unternehmen brauchen. Nutzt ein KI-Agent RAG, um Datenfragen zu beantworten, ruft er aus dem Katalog von Dawiso ab: Beschreibungen von Datensätzen, Spaltendefinitionen, Definitionen von Fachbegriffen, Data Lineage und Qualitätsbewertungen.

Fragt ein Nutzer „Welche Datensätze enthalten Umsatzdaten von Kunden für EMEA?“, löst das eine RAG-Pipeline aus, die den Katalog von Dawiso nach passenden Datensätzen durchsucht, ihre Beschreibungen und Verantwortlichkeiten abruft, ihren Governance-Status prüft und eine Antwort erzeugt, die konkrete Tabellen, ihre verantwortlichen Personen und ihren Aktualisierungsstand nennt. Die Antwort ist in gesteuerten Metadaten verankert, nicht im allgemeinen Training des Modells.

Über MCP binden sich KI-Agenten direkt an die Wissensbasis von Dawiso als RAG-Quelle an. Statt statische Dokumentation einzubetten, fragen Agenten den Katalog in Echtzeit ab und erhalten aktuelle Metadaten, Lineage-Einträge und Qualitätsbewertungen. Agentic-RAG-Muster nutzen MCP, um Dawiso schrittweise abzufragen: erst Definitionen von Datensätzen abrufen, dann der Lineage folgen, um die Herkunft der Daten zu verstehen, dann Qualitätsbewertungen prüfen, bevor eine Empfehlung entsteht. Dieser mehrstufige Abruf ergibt Antworten, die den aktuellen Stand der Datenlandschaft abbilden und nicht eine Momentaufnahme vom letzten Indexlauf.

Die Governance-Metadaten von Dawiso lösen außerdem die Frage „Welches Dokument ist maßgeblich?“, die ungesteuerte RAG-Wissensbasen plagt. Jeder Katalogeintrag hat eine Verantwortung, einen Governance-Status (gesteuert, Entwurf, abgekündigt) und einen Hinweis auf seine Aktualität. RAG-Systeme können den Abruf auf gesteuerte Quellen begrenzen und so sicherstellen, dass Antworten aus maßgeblichen, aktuellen und qualitätsgeprüften Metadaten stammen statt aus veralteten oder ungeprüften Inhalten.

Fazit

RAG löst die grundlegende Beschränkung großer Sprachmodelle: Sie erzeugen plausiblen Text, kennen aber keine Fakten. Indem es Wissen (die Wissensbasis) vom Schlussfolgern (das Modell) trennt, ermöglicht RAG KI-Systeme, die korrekt, prüfbar und aktualisierbar sind. Diese Trennung heißt aber auch, dass die Qualität von RAG vollständig an der Qualität der Wissensbasis hängt. Eine ungesteuerte Wissensbasis ergibt ungesteuerte Antworten, selbstbewusst zitiert aus dem falschen Dokument. Für RAG im Unternehmen ist die Wissensbasis keine Dateihalde. Sie ist ein gesteuerter, gepflegter, metadatenreicher Bestand, und genau das liefert ein Datenkatalog.