RAG-System für Unternehmen: Daten, Qualität und Betrieb

Ein RAG-System für Unternehmen verbindet ein Sprachmodell mit kontrolliert abgerufenen Informationen. Statt ausschließlich aus dem im Modell enthaltenen Wissen zu antworten, sucht das System passende Abschnitte in freigegebenen Quellen und stellt sie für die Antwort bereit.

Die kurze Antwort: RAG passt, wenn Antworten auf veränderlichem oder internem Wissen beruhen, die Quellen identifizierbar sind und der Nutzen häufig genug entsteht. Der eigentliche Aufwand liegt selten im Chatfenster. Er liegt in Datenqualität, Zugriffsrechten, Retrieval-Tests, Aktualisierung und Betrieb.

Was bei RAG technisch passiert

Ein vereinfachter Ablauf besteht aus sechs Schritten:

1. Dokumente werden aus definierten Quellen übernommen.
2. Inhalte werden bereinigt und in sinnvolle Abschnitte zerlegt.
3. Abschnitte erhalten Metadaten und eine durchsuchbare Repräsentation.
4. Eine Nutzerfrage wird in eine Suchanfrage übersetzt.
5. Das System ruft passende Abschnitte unter Beachtung der Rechte ab.
6. Das Sprachmodell formuliert daraus eine Antwort mit Quellenbezug.

Jeder Schritt kann das Ergebnis verbessern oder verschlechtern. Fehlt eine aktuelle Version, wird sie nicht gefunden. Sind Abschnitte schlecht getrennt, fehlt Kontext. Ist die Suche ungenau, erhält das Modell irrelevante Passagen. Ignoriert der Abruf Berechtigungen, entsteht ein Sicherheitsproblem.

Für welche Anwendungsfälle RAG gut passt

Ein geeigneter Use Case hat einen klaren Nutzerkreis, wiederkehrende Fragen und eine abgrenzbare Wissensbasis.

Interne Wissensassistenz

Mitarbeitende suchen Richtlinien, Prozessbeschreibungen, Produktinformationen oder technische Dokumentation. Quellenangaben ermöglichen, die Antwort zu prüfen und direkt im Original weiterzulesen.

Service- und Supportunterstützung

Ein System schlägt auf Basis freigegebener Dokumentation Antworten oder Lösungsschritte vor. Bei externen Antworten sollten Freigabe und Eskalation zum Risiko passen.

Vertriebs- und Angebotswissen

Teams finden passende Leistungsinformationen, freigegebene Referenzen oder standardisierte Textbausteine. Vertrauliche Preis- und Kundendaten erfordern eine besonders saubere Rechteprüfung.

Fachliche Recherche in begrenzten Beständen

Große Dokumentensammlungen können anhand konkreter Fragen erschlossen werden. Das System unterstützt die Recherche; es ersetzt nicht automatisch die fachliche Bewertung.

Wann eine einfachere Lösung besser ist

RAG ist nicht für jedes Informationsproblem erforderlich.

Eine normale Suche oder strukturierte Wissensdatenbank ist oft besser, wenn:

• Nutzer bekannte Dokumente oder exakte Begriffe suchen;
• Antworten vollständig deterministisch sein müssen;
• wenige Inhalte übersichtlich strukturiert werden können;
• keine generative Zusammenfassung nötig ist.

Eine klassische Automation passt besser, wenn:

• Eingaben und Entscheidungen klare Regeln haben;
• ein Prozess Datensätze verschieben oder Status ändern soll;
• die Ausgabe exakt reproduzierbar sein muss.

Und manchmal ist die wichtigste Maßnahme keine KI, sondern die Bereinigung von Dokumentablagen, Verantwortlichkeiten und Versionen.

Schritt 1: Den Use Case als überprüfbare Aufgabe beschreiben

„Unsere Dokumente mit KI nutzbar machen“ ist zu breit. Eine belastbare Beschreibung beantwortet:

• Wer stellt welche Fragen?
• Aus welchen Quellen darf geantwortet werden?
• Welche Antwortform wird erwartet?
• Welche Fehler wären tolerierbar, welche kritisch?
• Muss jede Aussage eine Quelle nennen?
• Welche Aktion folgt aus der Antwort?
• Woran erkennt das Team einen messbaren Nutzen?

Ein Beispiel: „Servicemitarbeitende finden für wiederkehrende technische Fragen innerhalb von zwei Minuten eine Antwort aus der aktuellen Produktdokumentation und sehen die verwendeten Passagen.“ Das lässt sich testen. „Besserer Wissenszugang“ kaum.

Schritt 2: Quellen und Eigentümer festlegen

Erstelle kein Verzeichnis aller verfügbaren Dateien, sondern ein kontrolliertes Quellenregister.

Quellen brauchen Verantwortliche. Ohne Eigentümer bleibt unklar, wer veraltete Informationen korrigiert oder eine fehlerhafte Datei sperrt.

Die Forschung zum industriellen RAG-Einsatz beschreibt Datenaufbereitung, Datenschutz, Sicherheit, Datenqualität und Evaluation als zentrale praktische Themen. Ein Interviewpapier zu RAG in der Industrie zeigt außerdem, dass viele Systeme noch im Prototypstadium bleiben. Das ist ein guter Hinweis, den Betrieb von Beginn an mitzudenken.

Schritt 3: Dokumente semantisch sinnvoll aufbereiten

Dateien sind nicht automatisch gute Wissenseinheiten. PDF-Kopfzeilen, Tabellen, Fußnoten, gescannte Seiten und wiederholte Navigation können die Suche stören.

Bei der Aufbereitung sind wichtig:

• Text zuverlässig extrahieren;
• Überschriften und Abschnitte erhalten;
• Tabellen und Listen sinnvoll repräsentieren;
• wiederkehrende Störelemente entfernen;
• Version, Quelle, Datum und Rechte als Metadaten speichern;
• Abschnitte so teilen, dass Frage und Antwortkontext zusammenbleiben.

Eine pauschale Abschnittslänge ist selten optimal. Kurze FAQ-Einträge, mehrseitige Richtlinien und technische Tabellen benötigen unterschiedliche Strategien. Testfragen zeigen besser als ein allgemeiner Richtwert, ob relevanter Kontext erhalten bleibt.

Schritt 4: Retrieval getrennt von der Antwort testen

Wenn eine Antwort falsch ist, muss das Team unterscheiden können:

• War die richtige Information in den Quellen?
• Wurde sie indexiert?
• Hat die Suche den passenden Abschnitt gefunden?
• War der Abschnitt weit oben genug?
• Hat das Modell den gefundenen Kontext korrekt verwendet?

Deshalb braucht ein RAG-System mindestens zwei Testebenen.

Retrieval-Evaluation

Für bekannte Fragen wird geprüft, ob der erwartete Quellabschnitt in den ersten Treffern liegt. So lassen sich Suchverfahren, Metadatenfilter und Abschnittsbildung vergleichen.

Antwort-Evaluation

Fachverantwortliche bewerten, ob die Antwort korrekt, vollständig, verständlich und durch die angezeigten Quellen gestützt ist. Zusätzlich werden unerwünschte Fälle getestet: fehlende Information, widersprüchliche Versionen, unberechtigte Anfrage und manipulative Dokumentinhalte.

Ein kleines, hochwertiges Set aus realen Fragen ist für den Start wertvoller als eine große Sammlung künstlicher Beispiele.

Schritt 5: Rechte vor dem Abruf durchsetzen

Ein Nutzer darf durch die Frage keinen Zugriff auf Dokumente erhalten, die er im Quellsystem nicht sehen dürfte. Berechtigungen müssen deshalb vor oder beim Retrieval wirken, nicht erst in der formulierten Antwort.

Wichtige Prinzipien:

• Identität der anfragenden Person zuverlässig bestimmen;
• Gruppen und Dokumentrechte aus der führenden Quelle übernehmen;
• Treffer bereits vor der Modellübergabe filtern;
• keine vertraulichen Inhalte in allgemeinen Protokollen speichern;
• Zugriff und Änderungen nachvollziehbar protokollieren;
• Löschung und Rechteentzug zeitnah in den Index übertragen.

NIST stellt mit dem AI Risk Management Framework einen freiwilligen Rahmen bereit, um Risiken über Gestaltung, Entwicklung, Einsatz und Nutzung hinweg zu behandeln. Für ein RAG-Projekt ist besonders hilfreich, technische Qualität nicht getrennt von Governance und Betrieb zu betrachten.

Schritt 6: Antworten begrenzen und Quellen sichtbar machen

Ein produktives System sollte nicht so tun, als kenne es jede Antwort. Sinnvolle Verhaltensregeln sind:

• nur aus den bereitgestellten Quellen antworten;
• Unsicherheit oder fehlende Belege sichtbar benennen;
• relevante Quellen mit Titel und Abschnitt verlinken;
• widersprüchliche Quellen nicht still zusammenführen;
• bei sensiblen Fragen an eine zuständige Stelle verweisen;
• keine Aktionen ausführen, die der Use Case nicht vorsieht.

Quellenangaben erhöhen nicht automatisch die Richtigkeit. Sie ermöglichen aber eine Prüfung und machen Fehler diagnostizierbar.

Schritt 7: Aktualisierung und Löschung planen

Ein einmaliger Import ist nur für statische Demonstrationen ausreichend. Im Betrieb muss feststehen:

• Welche Ereignisse lösen eine Aktualisierung aus?
• Wie schnell müssen Änderungen sichtbar sein?
• Was passiert bei gelöschten oder zurückgezogenen Dokumenten?
• Wie werden Altversionen erkannt?
• Kann ein fehlerhafter Import zurückgerollt werden?
• Wer sieht den Synchronisationsstatus?

Jeder indexierte Abschnitt sollte zur Quelle zurückverfolgbar sein. Ohne diese Verbindung werden Korrekturen unnötig aufwendig.

Schritt 8: Kosten, Leistung und Fehler überwachen

Die laufenden Kosten entstehen nicht nur durch das Sprachmodell. Zu betrachten sind:

• Datenübernahme und Aufbereitung;
• Suche und Speicherung;
• Modellaufrufe und Kontextgröße;
• Rechenzeit für erneute Indexierung;
• Monitoring und Protokollierung;
• fachliche Evaluation;
• Wartung von Quellen und Berechtigungen.

Ein Dashboard kann Abrufqualität, Antwortlatenz, Fehlerrate, Kosten je Anfrage, Nutzung nach Anwendungsfall und häufige unbeantwortete Fragen zeigen. Diese Signale helfen, gezielt zu verbessern, statt pauschal Modell oder Prompt zu wechseln.

Ein realistischer Einführungsplan

Phase 1: Abgegrenzter Prototyp

Ein Nutzerkreis, wenige hochwertige Quellen und 30 bis 50 reale Testfragen. Noch keine kritischen Aktionen, aber sichtbare Quellen und ein vollständiger Fehlerpfad.

Phase 2: Fachliche Evaluation

Fachverantwortliche prüfen Antworten und Retrieval. Datenaufbereitung, Metadaten und Grenzen werden angepasst. Der Nutzen wird gegen die bisherige Suche gemessen.

Phase 3: Kontrollierter Pilot

Ein begrenztes Team nutzt das System im Alltag. Zugriff, Aktualisierung, Monitoring, Support und Kosten werden unter realen Bedingungen geprüft.

Phase 4: Produktiver Betrieb

Erst jetzt folgen größere Nutzergruppen oder weitere Quellen. Jede Erweiterung bringt eigene Rechte, Fehlerfälle und Tests mit.

Die Seite RAG-Systeme für Unternehmen ordnet diese Bausteine als konkrete Umsetzung ein. Wenn RAG nur ein Teil einer größeren Architektur ist, beschreibt KI-Integration den breiteren Ansatz.

Häufige Fragen zu RAG-Systemen

Verhindert RAG Halluzinationen?

Nein. RAG kann relevante und aktuelle Quellen bereitstellen und Antworten prüfbarer machen. Das Modell kann Kontext trotzdem falsch interpretieren oder eine Lücke unzulässig ergänzen. Grenzen und Evaluation bleiben notwendig.

Braucht ein RAG-System eine Vektordatenbank?

Nicht zwingend in jeder Architektur. Je nach Daten, Fragen und vorhandener Suche können lexikalische, semantische oder kombinierte Verfahren passen. Entscheidend ist messbare Retrieval-Qualität.

Wie viele Dokumente braucht ein sinnvoller Pilot?

So wenige wie möglich und so viele wie nötig, um einen echten Anwendungsfall abzudecken. Eine kleine, gepflegte Quelle eignet sich besser als ein ungeprüfter Import der gesamten Ablage.

Kann ein internes RAG-System vertrauliche Daten nutzen?

Technisch ja, aber nur mit passender Architektur, Rechts- und Datenschutzprüfung, Zugriffskontrolle und dokumentierten Datenflüssen. Die Vertraulichkeit der Quelle muss bis zum Abruf und Modellaufruf erhalten bleiben.

Woran erkennt man Produktionsreife?

An wiederholbar guter Retrieval- und Antwortqualität, durchgesetzten Rechten, kontrollierter Aktualisierung, sichtbaren Fehlern, definiertem Support und vertretbaren laufenden Kosten – nicht an einer überzeugenden Demo.

Fazit: Produktives RAG beginnt bei der Wissensverantwortung

Ein RAG-System für Unternehmen ist kein Chatbot mit Dokumentupload. Es ist ein betriebenes Informationssystem. Datenquellen, Verantwortliche, Rechte, Evals, Aktualisierung und Monitoring entscheiden, ob daraus verlässliche Unterstützung entsteht.

atondix entwickelt solche Systeme vom abgegrenzten Use Case bis zur Integration in bestehende Abläufe. Entscheidend ist zuerst, ob RAG wirklich die passende Lösung ist.