RAG für Unternehmenswissen: Wann der KI-Zugriff auf interne Daten hilft

RAG kann einer KI Zugriff auf Unternehmenswissen geben, ohne dieses Wissen in das Modelltraining zu übernehmen. Das Verfahren eignet sich, wenn Antworten auf interne, veränderliche oder umfangreiche Informationen gestützt werden sollen. Es löst aber weder unklare Dokumente noch fehlende Zuständigkeiten: Die Qualität der Antwort hängt davon ab, welche Inhalte gefunden und dem Modell tatsächlich bereitgestellt werden. Für Geschäftsführung, Produktverantwortliche und technische Leitung ist deshalb nicht nur die Frage wichtig, ob RAG technisch möglich ist. Entscheidend ist, ob die relevanten Informationen auffindbar, aktuell und zugänglich sind – und ob sich die Qualität der Antworten prüfen lässt. Dieser Beitrag erklärt den Ablauf und zeigt Kriterien, mit denen Sie entscheiden, ob RAG für Ihren Anwendungsfall passt.

Kurz gesagt

RAG steht für Retrieval-Augmented Generation: Vor der Antwort sucht ein System passende Informationen aus einer Wissensquelle und gibt sie dem Sprachmodell als Kontext. Das Modell formuliert auf dieser Grundlage eine Antwort, statt sich ausschließlich auf sein vortrainiertes Wissen zu stützen. RAG hilft, wenn relevante Inhalte zugänglich, ausreichend klar und regelmäßig überprüfbar sind. Es ist keine Garantie für korrekte Antworten und ersetzt weder Datenpflege noch Tests.

Ausgangslage

Sprachmodelle beantworten Fragen auf Basis ihres Trainings und des Kontexts, den sie bei einer Anfrage erhalten. Unternehmensinterne Richtlinien, Produktdaten, Prozessbeschreibungen oder aktuelle Dokumente sind meist nicht automatisch Teil dieses Kontexts. RAG ergänzt einen Abrufschritt: Das System sucht in einer kontrollierten Wissensbasis nach passenden Inhalten und übergibt ausgewählte Textstellen an das Modell.

Der typische Ablauf besteht aus zwei Teilen:

1. Vorbereitung der Wissensbasis: Dokumente werden eingelesen, bereinigt, in Abschnitte zerlegt und mit Informationen wie Quelle, Datum oder Zugriffsbereich versehen. Häufig werden Abschnitte zusätzlich als Vektoren gespeichert, damit inhaltlich ähnliche Textstellen auffindbar sind.
2. Beantwortung einer Anfrage: Die Anfrage wird verarbeitet, passende Abschnitte werden gesucht und nach Relevanz ausgewählt. Das Sprachmodell erhält die Frage zusammen mit diesem Kontext und erzeugt daraus eine Antwort.

Die Vektorsuche ist dabei nur ein möglicher Teil der Suche. Je nach Bestand können auch klassische Stichwortsuche oder eine Kombination aus beiden Verfahren sinnvoll sein. Entscheidend ist, dass das System die richtigen Textstellen findet – nicht, dass eine bestimmte Suchtechnik eingesetzt wird.

RAG verändert nicht automatisch das Sprachmodell und macht es nicht dauerhaft mit den Dokumenten vertraut. Die Inhalte werden bei Bedarf als Kontext abgerufen. Werden Quelldokumente aktualisiert, müssen die Änderungen deshalb in den Suchbestand übernommen werden, bevor sie zuverlässig in Antworten einfließen.

Entscheidungskriterien

1. Ist das Wissen dokumentiert und auffindbar?

RAG kann vorhandene Informationen zugänglich machen. Es kann nicht rekonstruieren, was nie dokumentiert wurde, und gleicht widersprüchliche Dokumente nicht zuverlässig selbst ab. Prüfen Sie vor einer Umsetzung, ob es für zentrale Fragen verlässliche Quellen gibt und ob klar ist, welche davon maßgeblich sind.

Wenn zwei Dokumente verschiedene Prozessschritte beschreiben, braucht es eine Entscheidung über Gültigkeit und Priorität. Ein Suchsystem kann beide finden; das löst den fachlichen Widerspruch nicht.

2. Wie aktuell und veränderlich sind die Inhalte?

RAG ist besonders interessant, wenn sich Quellen häufiger ändern, als ein Modell sinnvoll neu trainiert werden könnte. Dafür muss der Bestand Aktualisierungen, Löschungen und Versionswechsel abbilden. Fragen Sie, wer Inhalte freigibt, wie Änderungen in den Index gelangen und wie veraltete Fassungen ausgeschlossen werden.

Ein Import, der Dokumente nur ergänzt, aber überholte Fassungen nicht entfernt, kann falsche Treffer erzeugen. Aktualität ist damit eine Eigenschaft des gesamten Datenprozesses – nicht nur des Sprachmodells.

3. Lassen sich Zugriffsrechte im Abruf durchsetzen?

Ein RAG-System muss berücksichtigen, wer welche Informationen sehen darf. Eine Antwort darf nicht auf Textstellen beruhen, die der anfragenden Person verborgen bleiben sollten. Dazu gehören geeignete Rechte- und Bereichsfilter bereits bei der Suche sowie Tests, die unterschiedliche Rollen abbilden.

Eine nachträgliche Prüfung der fertigen Antwort reicht nicht zuverlässig aus: Vertrauliche Inhalte könnten bereits in den Modellkontext gelangt sein. Die Rechteprüfung muss daher Teil der Abrufarchitektur sein.

4. Sind die Dokumente sinnvoll strukturiert?

Überschriften, Tabellen, Listen und Fußnoten können beim Einlesen ihre Bedeutung verlieren. Wenn ein Abschnitt ohne den Titel oder die zugehörige Tabelle unverständlich ist, wird auch ein passender Suchtreffer wenig nützen. Prüfen Sie die tatsächliche Textfassung, die das System aus den Quelldateien übernimmt, nicht nur das Originaldokument.

Metadaten wie Dokumenttyp, Fachbereich, Gültigkeitsdatum oder Version können helfen, die Suche einzugrenzen. Sie sollten allerdings aus verlässlichen Regeln stammen oder kontrolliert gepflegt werden. Ungeprüfte Metadaten führen zu falschen Filtern.

5. Sind die Abschnitte passend zugeschnitten?

Beim sogenannten Chunking werden Dokumente in kleinere Einheiten zerlegt. Zu große Abschnitte enthalten womöglich viel irrelevanten Text; zu kleine verlieren Zusammenhänge und Definitionen. Ein guter Zuschnitt bewahrt die Information, die für eine Antwort zusammengehört.

Die passende Größe hängt von den Dokumenten und Fragen ab. Eine Verfahrensanweisung mit nummerierten Schritten sollte beispielsweise nicht so zerlegt werden, dass Voraussetzungen und Handlung voneinander getrennt sind. Ein Glossareintrag braucht möglicherweise weniger Kontext. Testen Sie verschiedene Zuschnitte anhand echter Fragen statt eine pauschale Regel auf alle Inhalte anzuwenden.

6. Müssen Antworten auf Quellen verweisen?

Quellenangaben sind nützlich, wenn Mitarbeitende Aussagen nachprüfen oder an die zuständige Dokumentation weitergehen müssen. Das System sollte Quelle und möglichst auch den relevanten Abschnitt so mitführen, dass eine Antwort überprüfbar bleibt.

Eine angezeigte Quelle beweist jedoch nicht, dass die Antwort sie korrekt wiedergibt. Prüfen Sie, ob die angegebene Textstelle die Aussage tatsächlich stützt. Legen Sie außerdem fest, was bei fehlenden oder widersprüchlichen Treffern geschehen soll: etwa eine Rückfrage, eine kenntlich gemachte Unsicherheit oder keine inhaltliche Antwort.

7. Können Sie die Qualität gezielt messen?

Vor dem Einsatz brauchen Sie einen Testsatz aus realistischen Fragen und fachlich geprüften Erwartungen. Dazu gehören einfache Fragen, mehrdeutige Formulierungen, Fragen ohne passende Quelle und Fälle, in denen mehrere Dokumente relevant sind.

Bewerten Sie getrennt, ob das System relevante Quellen findet, ob die Antwort durch diese Quellen gedeckt ist und ob es bei fehlender Grundlage angemessen reagiert. Änderungen an Dokumenten, Chunking, Suche oder Modell können das Ergebnis verändern. Wiederholen Sie die Tests deshalb nach wesentlichen Änderungen.

Wann RAG passt – und wann nicht

RAG ist sinnvoll, wenn …

• Antworten auf interne oder regelmäßig aktualisierte Dokumente gestützt werden sollen.
• Nutzende in einer großen Wissensbasis Fragen in natürlicher Sprache stellen.
• Antworten mit nachvollziehbaren Fundstellen verbunden werden sollen.
• klar geregelt werden kann, welche Quellen und Berechtigungen gelten.

RAG ist nicht die erste Wahl, wenn …

• eine einfache, eindeutige Abfrage aus strukturierten Daten genügt. Für einen aktuellen Lagerbestand ist eine direkte Datenbankabfrage meist geeigneter als eine Textsuche mit anschließender Formulierung.
• Inhalte lückenhaft, widersprüchlich oder nicht freigegeben sind. Dann ist zunächst die Wissensbasis zu ordnen.
• eine Entscheidung festen Regeln folgen muss. Berechnungen, Berechtigungsprüfungen und verbindliche Prozessschritte sollten nicht dem Sprachmodell überlassen werden.
• die Antwort keine relevante Quelle benötigt und ein klar begrenzter klassischer Workflow zuverlässiger ist.

RAG und klassische Softwarelogik schließen sich nicht aus. Ein System kann Daten strukturiert abfragen, Regeln in Code prüfen und ein Sprachmodell nur dort einsetzen, wo eine verständliche Zusammenfassung oder flexible Formulierung gebraucht wird.

Praxisbeispiel

Im Projekt Ting dient PostgreSQL mit pgvector als Gedächtnis. Mehrere KI-Anbieter antworten unabhängig voneinander und stimmen strukturiert mit den Optionen „approve“, „revise“ oder „reject“ ab. Freigegeben wird nur bei Einstimmigkeit; strukturierte Ausgaben werden über ein Schema geführt.

Das Beispiel zeigt, dass ein Vektorspeicher wie pgvector Teil einer kontrollierten Architektur sein kann. Er macht für sich genommen weder Inhalte verlässlich noch Antworten korrekt. Dafür braucht es zusätzlich klare Eingaben, definierte Freigaberegeln und eine überprüfbare Ausgabe. Die konkrete RAG-Eignung hängt weiterhin davon ab, wie Quellen erschlossen und Antworten getestet werden.

Typische Fehler

• RAG als Reparatur für schlechte Dokumentation behandeln. Widersprüche und Lücken müssen fachlich geklärt werden, bevor sie automatisiert durchsucht werden.
• Alle Dateien ungeprüft indexieren. Entwürfe, veraltete Fassungen und freigegebene Inhalte sollten unterscheidbar sein.
• Chunking nach einer festen Faustregel festlegen. Der Zuschnitt muss die Bedeutung der jeweiligen Inhalte bewahren.
• Nur die sprachliche Qualität der Antwort bewerten. Eine gut formulierte Antwort kann trotzdem auf irrelevanten oder unzureichenden Quellen beruhen.
• Quellenangaben mit Belegbarkeit verwechseln. Prüfen Sie, ob die Fundstelle die konkrete Aussage tatsächlich trägt.
• Berechtigungen erst nach der Suche berücksichtigen. Nicht zugelassene Inhalte dürfen nicht in den Kontext für die Antwort gelangen.
• Einen erfolgreichen Prototyp als Evaluation behandeln. Ein einzelner überzeugender Testfall sagt wenig über Grenzfälle und unbeantwortbare Fragen aus.

Empfehlung

• Wenn Mitarbeitende in einer gepflegten, umfangreichen Dokumentation suchen und Antworten mit Quellen nachvollziehen müssen, prüfen Sie RAG an einem klar abgegrenzten Anwendungsfall.
• Wenn Informationen überwiegend in Tabellen oder Fachsystemen liegen und konkrete Werte gefragt sind, verwenden Sie eine kontrollierte Datenabfrage statt einer rein semantischen Dokumentsuche.
• Wenn Inhalte widersprüchlich, veraltet oder ohne Zuständigkeit sind, ordnen Sie zuerst Datenpflege und Freigabeprozess.
• Wenn Zugriffsrechte zwischen Rollen oder Teams variieren, planen Sie diese vor dem Indexieren und testen Sie den Abruf mit den jeweiligen Rollen.
• Wenn ein Fehler verbindliche Folgen haben kann, begrenzen Sie die KI auf unterstützende Aufgaben und behalten Sie Regeln, Berechnungen und Freigaben in nachvollziehbaren Prozessen.
• Wenn Sie die Qualität nicht anhand realistischer Fragen und Quellen prüfen können, ist das System noch nicht reif für einen produktiven Einsatz.

Checkliste

• Ist der konkrete Anwendungsfall auf eine klar abgegrenzte Gruppe von Fragen beschränkt?
• Sind maßgebliche Dokumente, Versionen und Zuständigkeiten festgelegt?
• Werden veraltete, gesperrte und gelöschte Inhalte zuverlässig behandelt?
• Bleiben Überschriften, Tabellen und relevante Zusammenhänge beim Einlesen erhalten?
• Ist das Chunking anhand echter Fragen geprüft?
• Werden Berechtigungen bereits beim Abruf berücksichtigt?
• Können Nutzende Quellen und Fundstellen nachvollziehen?
• Gibt es Tests für falsche, widersprüchliche und fehlende Treffer?
• Werden Suchqualität, Antwortbezug und Umgang mit Unsicherheit getrennt bewertet?
• Ist festgelegt, wie Änderungen an Quellen in den Suchbestand übernommen werden?

Häufige Fragen

Ist RAG dasselbe wie das Training eines KI-Modells?

Nein. RAG ruft passende Informationen bei einer Anfrage ab und stellt sie dem Modell als Kontext bereit. Die Inhalte werden dadurch nicht automatisch Teil des Modelltrainings.

Macht RAG Antworten automatisch korrekt?

Nein. Die Antwort kann trotz RAG falsch sein, etwa wenn die Suche ungeeignete Textstellen findet oder das Modell den Kontext falsch wiedergibt. Quellenprüfung und Tests bleiben notwendig.

Braucht RAG zwingend eine Vektordatenbank?

Nicht zwingend. Vektorsuche ist eine Möglichkeit, inhaltlich ähnliche Textstellen zu finden. Je nach Bestand können Stichwortsuche oder kombinierte Verfahren besser passen.

Wann sollte ein RAG-System nicht antworten?

Wenn keine ausreichend passende Quelle gefunden wird, Quellen einander widersprechen oder eine Berechtigungsprüfung scheitert, sollte das System nicht einfach eine plausible Antwort ergänzen. Der Umgang mit solchen Fällen muss bewusst festgelegt und getestet werden.

Weiterführend

• KI mit eigenen Daten: Was Unternehmen technisch beachten müssen
• KI-Workflows richtig testen: Wie man Qualität messbar macht
• Human-in-the-loop: Warum gute KI-Workflows Menschen nicht entfernen
• KI-Automatisierung im Unternehmen: Prozesse sicher steuern

Weiterführende Quellen

Diese offiziellen Dokumentationen und Standards vertiefen die behandelten Themen.

• NIST AI Risk Management Framework