RAG erklärt: So wird Unternehmenswissen für KI nutzbar

Ihr Unternehmen besitzt Wissen, das in keinem Sprachmodell steckt: Verträge, Projektberichte, Produktdokumentation, interne Richtlinien, E-Mail-Verläufe. Fragen Mitarbeitende ChatGPT oder ein anderes KI-Werkzeug nach internen Themen, erhalten sie bestenfalls eine Absage. Schlimmstenfalls eine plausibel klingende, aber falsche Antwort. Retrieval-Augmented Generation, kurz RAG, schließt diese Lücke. Das Verfahren verbindet ein Sprachmodell mit Ihren eigenen Dokumenten, ohne dass das Modell dafür trainiert werden muss. Dieser Guide erklärt, wie das funktioniert, warum Quellenangaben der eigentliche Vertrauensgewinn sind und warum die meisten RAG-Projekte nicht an der KI scheitern, sondern an Zugriffsrechten.

Was ist Retrieval-Augmented Generation?

Retrieval-Augmented Generation (RAG) ist ein Verfahren, bei dem ein Sprachmodell vor der Beantwortung einer Frage relevante Textpassagen aus einer definierten Dokumentensammlung erhält und seine Antwort auf diese Passagen stützt. Der Name beschreibt die zwei Schritte: Retrieval (Abruf passender Inhalte) und Generation (Formulierung der Antwort durch das Modell). Das Sprachmodell selbst bleibt unverändert. Es greift nicht auf einbetoniertes Trainingswissen zurück, sondern auf die Dokumente, die ihm das System zur Laufzeit mitliefert.

Ein Vergleich aus dem Arbeitsalltag: Ein neuer Mitarbeiter beantwortet eine Fachfrage nicht aus dem Gedächtnis, sondern schlägt im Handbuch nach und fasst die gefundene Stelle zusammen. RAG macht genau das, nur in Sekunden und über den gesamten Dokumentenbestand.

Wie RAG technisch funktioniert – in vier Schritten

Für Entscheider reicht ein Verständnis auf Prozessebene. Die Details übernimmt ein RAG-Entwickler. Die Schritte sind aber wichtig, um Aufwand und Risiken einschätzen zu können.

• 1. Aufbereitung: Ihre Dokumente (PDFs, Wiki-Seiten, Tickets, Verträge) werden in handhabbare Abschnitte zerlegt. Dieser Schritt heißt Chunking. Wie gut die Zerlegung gelingt, entscheidet später mit über die Qualität der Antworten.
• 2. Indexierung: Jeder Abschnitt wird in eine numerische Repräsentation überführt, ein sogenanntes Embedding. Embeddings bilden die Bedeutung eines Textes als Zahlenreihe ab, sodass inhaltlich ähnliche Texte rechnerisch nahe beieinander liegen. Gespeichert wird das in einer Vektordatenbank, einer Datenbank, die auf Ähnlichkeitssuche spezialisiert ist.
• 3. Abruf: Stellt ein Nutzer eine Frage, sucht das System die Abschnitte heraus, die der Frage inhaltlich am nächsten kommen. Auch dann, wenn die Formulierung abweicht. Wer nach „Kündigungsfrist“ fragt, findet auch Dokumente, die von „Vertragsbeendigung“ sprechen.
• 4. Antwort: Die gefundenen Abschnitte werden dem Sprachmodell zusammen mit der Frage übergeben. Das Modell formuliert eine Antwort, die sich auf genau diese Abschnitte stützt, und kann angeben, aus welchem Dokument welche Aussage stammt.

Warum kein Training nötig ist

Ein verbreitetes Missverständnis lautet: „Wir müssen die KI erst mit unseren Daten trainieren.“ Für die allermeisten Wissens-Anwendungsfälle stimmt das nicht. Das Training eines Sprachmodells, oder das nachträgliche Anpassen, das sogenannte Fine-Tuning, verändert die Gewichte des Modells selbst. Das ist teuer, erfordert Spezialwissen und muss bei jeder Wissensänderung wiederholt werden. Vor allem aber löst es das falsche Problem. Fine-Tuning eignet sich, um einem Modell einen Stil oder ein Verhalten beizubringen, nicht, um Fakten zuverlässig abrufbar zu machen.

RAG verfolgt den umgekehrten Ansatz: Das Wissen bleibt außerhalb des Modells, in Ihren Systemen, und wird nur bei Bedarf herangezogen. Die Unterschiede im Überblick:

Auch aus Datenschutzsicht ist der Unterschied relevant: Bei RAG lässt sich ein Dokument aus dem Index entfernen, und es ist weg. Wissen, das per Fine-Tuning in ein Modell eingeflossen ist, lässt sich praktisch nicht mehr gezielt löschen. Ein Problem, sobald Betroffenenrechte nach DSGVO greifen.

Quellenangaben: der unterschätzte Vorteil

Sprachmodelle können Aussagen erfinden, die plausibel klingen, aber falsch sind. Das Phänomen wird als Halluzination bezeichnet. Für den Unternehmenseinsatz ist das der zentrale Vertrauenskiller. Eine Antwort, die niemand prüfen kann, ist in vielen Kontexten wertlos.

RAG entschärft das Problem auf zwei Ebenen. Erstens sinkt die Halluzinationsneigung, wenn das Modell angewiesen ist, nur auf Basis der mitgelieferten Passagen zu antworten. Zweitens, und das ist im Alltag wichtiger, kann das System jede Aussage mit der Quelle belegen: Dokumentname, Abschnitt, idealerweise ein direkter Link ins Quellsystem. Mitarbeitende verifizieren die Antwort in Sekunden, statt ihr blind vertrauen zu müssen.

Ehrlich gesagt werden muss auch: RAG eliminiert Halluzinationen nicht vollständig. Ein Modell kann abgerufene Passagen falsch zusammenfassen oder Aussagen verknüpfen, die nicht zusammengehören. Quellenangaben machen solche Fehler aber auffindbar, und das ist der qualitative Unterschied zu einem Modell ohne Quellenbezug. Für Anwendungen mit Haftungsrelevanz (Rechtsauskünfte, medizinische Aussagen, verbindliche Preiszusagen) gehört deshalb immer eine menschliche Prüfung in den Prozess.

Zugriffsrechte: der Stolperstein, an dem Projekte scheitern

Die Technik hinter RAG ist inzwischen gut verstanden. Woran Projekte in der Praxis scheitern, ist meist etwas anderes: Berechtigungen.

Das Problem entsteht so: Ein RAG-System indexiert typischerweise Dokumente aus mehreren Quellen, etwa SharePoint, Confluence, Fileserver, CRM. In jedem dieser Systeme gelten Zugriffsrechte. Die Gehaltsliste sieht nur die Personalabteilung, den Vorstandsbericht nur die Geschäftsführung. Wird all das in einen gemeinsamen Index geladen und das RAG-System antwortet jedem Nutzer aus dem Gesamtbestand, sind diese Grenzen aufgehoben. Das System wird dann zur unbeabsichtigten Auskunftsstelle für Dinge, die der Fragende nie hätte sehen dürfen.

Die Lösung heißt berechtigungsbewusster Abruf. Das System prüft bei jeder Anfrage, welche Dokumente der konkrete Nutzer im Quellsystem sehen dürfte, und zieht nur diese für die Antwort heran. Das klingt selbstverständlich, ist aber der aufwendigste Teil vieler RAG-Projekte. Dafür gibt es drei Gründe:

• Berechtigungen müssen synchron bleiben. Wenn jemand die Abteilung wechselt oder das Unternehmen verlässt, muss das im RAG-System zeitnah wirken, nicht erst beim nächsten Neuaufbau des Index.
• Quellsysteme sprechen verschiedene Sprachen. SharePoint-Gruppen, Confluence-Spaces und Fileserver-ACLs (Access Control Lists, also Zugriffssteuerungslisten) folgen unterschiedlichen Logiken, die auf ein gemeinsames Modell abgebildet werden müssen.
• Gewachsene Berechtigungen sind oft unsauber. Viele Unternehmen entdecken im RAG-Projekt, dass ihre bestehenden Freigaben zu weit gefasst sind. Das ist kein KI-Problem. Aber das RAG-Projekt macht es sichtbar und sollte es nicht verschärfen.

Unsere Markteinschätzung: Wer Zugriffsrechte erst nach dem Piloten betrachtet, baut den Piloten zweimal. Die Berechtigungsfrage gehört in die erste Projektwoche, nicht in die letzte.

Was RAG nicht kann

Ein realistisches Erwartungsbild gehört zu jeder seriösen Einführung. Drei Grenzen sollten Sie kennen:

• RAG repariert keine schlechte Dokumentation. Veraltete, widersprüchliche oder lückenhafte Dokumente führen zu veralteten, widersprüchlichen oder lückenhaften Antworten. Das System macht Wissensqualität sichtbar, es erzeugt sie nicht.
• RAG rechnet und aggregiert schlecht. Fragen wie „Wie hat sich unser Umsatz je Region entwickelt?“ verlangen strukturierte Auswertungen über Datenbanken, keine Textsuche. Dafür sind andere Architekturen zuständig, die sich mit RAG kombinieren lassen.
• RAG versteht keine impliziten Zusammenhänge über viele Dokumente. Antworten, die das Zusammenführen von Wissen aus Dutzenden Quellen erfordern, überfordern den klassischen Abruf-Mechanismus. Hier helfen erweiterte Verfahren, die ein erfahrener Entwickler je nach Anwendungsfall auswählt.

Wie Sie ein RAG-Projekt sinnvoll starten

Ein bewährtes Vorgehen für den Einstieg:

• Einen Anwendungsfall wählen, nicht zehn. Gut geeignet: ein abgegrenzter Dokumentenbestand mit hoher Nachfrage, etwa Produktdokumentation für den Support oder interne Richtlinien für HR-Anfragen.
• Berechtigungslage vorab klären. Welche Quellsysteme, welche Rechtemodelle, wer darf was sehen? Diese Antworten bestimmen die Architektur.
• Betriebsmodell entscheiden. Cloud-Modelle in EU-Regionen, dedizierte Instanzen oder lokal betriebene Modelle: Die Wahl hängt von Schutzbedarf und Budget ab und sollte mit Datenschutzbeauftragten abgestimmt werden.
• Qualität messen, nicht raten. Vor dem Rollout eine Testmenge realer Fragen definieren und die Antworten systematisch bewerten. Ohne Messung lässt sich nicht beurteilen, ob das System produktionsreif ist.
• Pilot zeitlich begrenzen. Ein arbeitsfähiger Pilot ist typischerweise in wenigen Wochen erreichbar. Der Weg zum produktiven Betrieb dauert länger, weil Berechtigungen und Datenqualität den Hauptaufwand ausmachen.

Für die Umsetzung gibt es zwei Wege. Sie holen sich Expertise ins Team: Ein geprüfter RAG-Entwickler bringt die Erfahrung aus vergleichbaren Projekten mit und vermeidet die typischen Anfängerfehler bei Chunking, Abrufqualität und Berechtigungen. Oder Sie setzen auf eine fertig konzipierte Lösung wie unseren Wissens-Agenten, der den beschriebenen Aufbau als Paket umsetzt. Begriffe, die Ihnen in Gesprächen mit Dienstleistern begegnen, erklärt unser Glossar.

Fazit

RAG ist der pragmatische Weg, Unternehmenswissen für KI nutzbar zu machen: kein Training, aktuelle Antworten, nachvollziehbare Quellen, Dokumente bleiben unter Ihrer Kontrolle. Die Technik ist ausgereift. Der Projekterfolg entscheidet sich an Datenqualität und Zugriffsrechten. Unsere Handlungsempfehlung: Starten Sie mit einem einzelnen, klar abgegrenzten Anwendungsfall, klären Sie die Berechtigungsfrage vor der ersten Zeile Code und messen Sie die Antwortqualität, bevor Sie ausrollen. Wenn Sie dafür Verstärkung brauchen, finden Sie über uns geprüfte RAG-Entwickler. Oder Sie prüfen, ob der Wissens-Agent Ihren Fall bereits abdeckt.