Was ist RAG für eigene Dokumente? Was es kann – und was nicht

RAG kann Fragmente aus Unternehmensdokumenten finden und Antworten mit Quellenbezug erstellen. Es ist aber weder Modelltraining noch Wahrheitsmaschine oder Ersatz für Zugriffskontrollen.

Am Montagmorgen fragt die Personalleiterin den internen Assistenten, wie lange Bewerberdaten aufzubewahren sind, und erhält eine überzeugende Antwort samt Link zur Unternehmensrichtlinie; das einzige Problem: Die gefundene Fassung ist seit acht Monaten außer Kraft. Wer sich fragt: „Was ist RAG für eigene Dokumente?“, sieht hier die entscheidende Grenze: Technisch kann die Lösung alles getan haben, was von ihr verlangt wurde – ein semantisch ähnliches Fragment finden, es in den Modellkontext einfügen und eine flüssige Antwort formulieren; sie hat jedoch nicht geprüft, ob die Datei die neueste genehmigte Fassung ist, wenn der Versionsstatus im Index nicht verlässlich hinterlegt wurde.

RAG steht für Retrieval-Augmented Generation, also eine Generierung, der im Moment der Antwort abgerufener externer Kontext hinzugefügt wird; dabei wird das Modell weder mit den Unternehmensdokumenten trainiert, noch entsteht eine eigene „Wissensschicht“, die automatisch erkennt, welches Dokument wahr ist. Eher gleicht das Verfahren einer Bibliothek mit einem sehr schnellen Bibliothekar und einem talentierten Redakteur: Der Bibliothekar kann den falschen Band bringen, während der Redakteur trotzdem einen überzeugenden Absatz schreibt. Bereits die ursprüngliche RAG-Arbeit trennt das parametrische Gedächtnis des Modells ausdrücklich von einer extern abgerufenen, nichtparametrischen Quelle.

Der praktische Nutzen ist erheblich, wenn die Grenzen offen benannt werden: Das System kann passende Fragmente in einem verwalteten Dokumentenbestand suchen, sie zu einem für die Frage geeigneten Kontext zusammenstellen und einen Entwurf mit überprüfbarem Quellenverweis erstellen. Die Verantwortungsgrenze muss auch für den Nutzer sichtbar sein: Die Oberfläche darf nicht den Eindruck erwecken, das Vorhandensein einer Quelle sei eine rechtliche Freigabe, und Fehler oder Unklarheiten zu melden muss ebenso einfach sein wie eine Frage zu stellen. Die Lösung kann mangelhafte Dokumentation nicht reparieren, sachliche Richtigkeit nicht garantieren, Zugriffsrechte nicht selbst durchsetzen und weder deterministische Abläufe noch menschliche Freigaben ersetzen, wenn ein Fehler rechtliche, finanzielle, sicherheitsbezogene oder menschenrechtliche Risiken schafft; diese Grenze bestimmt sowohl die Architektur als auch das, was sich in einem Piloten sinnvoll messen lässt.

Warum eine alte Richtlinie als aktuelle Quelle abgerufen werden kann

Der Vorfall mit der alten Richtlinie beginnt nicht im Sprachmodell, sondern in der Dokumentenverwaltung: Auf dem gemeinsamen Laufwerk liegen „Personen_daten_final.docx“, „Personen_daten_final2.docx“ und ein genehmigtes PDF, doch keine Datei besitzt einheitliche Angaben zu Inkrafttreten, Status oder ersetzter Version. Der Index sieht drei inhaltlich ähnliche Kandidaten, und die semantische Suche kann das alte Dokument hoch bewerten, weil dessen Formulierung genauer zur Frage passt. Das Modell kennt den Beschluss einer Besprechung nicht, wenn dieser nicht in den Daten steht, und ein Dateiname mit „final“ ist kein Verwaltungsmechanismus.

Die Folgen sind tückisch, weil die Antwort besser wirken kann als ein gewöhnliches Suchergebnis: Sie ist kurz, grammatisch korrekt, verweist auf ein echtes Dokument und vermittelt deshalb das Gefühl, die Prüfung sei bereits erfolgt. Ein Quellenlink belegt nur, dass eine bestimmte Datei angezeigt oder mit der Antwort verknüpft wurde; er beweist noch nicht, dass jede Aussage aus dem zitierten Fragment folgt, dass das Fragment nicht aus einem Ausnahmeabschnitt gerissen wurde oder dass das Dokument überhaupt autoritativ sein darf. Das NIST-GenAI-Profil betrachtet einen solchen vertrauenswürdigen Anschein nicht als ausreichende Risikokontrolle und betont die Steuerung über den gesamten Lebenszyklus des Systems.

Die Lösung besteht in Veröffentlichungsstatus, Versionskette und Prioritätsregeln, nicht in einem längeren Prompt: Im Index benötigt jedes Dokument einen Eigentümer, ein Anfangs- und Enddatum der Gültigkeit, einen Status, das ersetzte Dokument, die Abteilung, die Vertraulichkeitsklasse und den nächsten Prüftermin; der Abruffilter muss Entwürfe und außer Kraft getretene Fassungen standardmäßig ausschließen. Widersprechen sich Quellen, muss das System den Konflikt anzeigen und darauf verzichten, eine einzige sichere Antwort vorzutäuschen, während der verantwortliche Eigentümer die Aufgabe erhält, den Dokumentenbestand zu bereinigen. RAG kann das Chaos sichtbar machen, aber nicht in eine Richtlinie verwandeln.

In einer solchen Situation muss die Antwortoberfläche neben dem Dokumentnamen auch Fassung, Gültigkeitsstatus, Fragment und Konfliktwarnung anzeigen; im Protokoll ist festzuhalten, welche Kandidaten gefunden wurden und warum einer davon ausgewählt wurde, damit sich der Fehler nach einer Indexänderung reproduzieren lässt. Gibt das System später eine andere Antwort, muss das Team feststellen können, ob sich Dokument, Chunking (die Zerlegung in Fragmente), Suchkonfiguration oder Modell geändert haben; ohne diese Nachvollziehbarkeit wird ein Qualitätsvorfall zu einer Vermutung über das „KI-Verhalten“ statt zu einem behebbaren Systemfehler.

Was ist RAG für eigene Dokumente und wie funktioniert es?

Eine RAG-Pipeline beginnt mit der Datenaufnahme, nicht mit dem Chatfenster: Dateien werden aus festgelegten Speichern übernommen, Text, Tabellen und vorhandene Strukturen extrahiert, während gescannte Dokumente eine optische Zeichenerkennung, kurz OCR, benötigen; danach wird der Inhalt in sinnvolle Fragmente zerlegt, die jeweils mit dem Dokument, der Seite, dem Abschnitt und den Verwaltungsmetadaten verknüpft bleiben. Microsoft beschreibt das Chunking als eine Entscheidung, die die Nützlichkeit der Suche beeinflusst: Ein zu kleines Fragment verliert den Gedanken, ein zu großes bringt viel Rauschen mit, und eine blinde Trennung nach einer festen Zeichenzahl kann eine Tabelle oder eine Ausnahmeregel zerschneiden.

Beim Indexieren erhalten die Fragmente eine für die Suche geeignete Darstellung, meist durch eine Verbindung von Stichwortsuche und semantischem Vergleich anhand numerischer Vektoren; stellt ein Nutzer eine Frage, kann das System sie in mehrere Suchanfragen umformen, Filter für Abteilung, Datum und Zugriff anwenden, Kandidaten abrufen und neu sortieren. Erst danach gelangen die ausgewählten Fragmente zusammen mit dem Auftrag in das Kontextfenster des Modells: Es soll anhand der verfügbaren Belege antworten, Quellen nennen und mitteilen, wenn die Belege nicht ausreichen. In diesem Moment wird nichts „für immer gelernt“; der Kontext gilt für die konkrete Anfrage.

Der letzte Schritt ist die Generierung: Ein vortrainiertes Sprachmodell verwandelt die Fragmente in eine verständliche Antwort und kann dabei unbeholfen paraphrasieren, unvereinbare Quellen zusammenführen oder ein glaubwürdiges Detail aus seinem Allgemeinwissen ergänzen. Das Ergebnis muss deshalb die Verbindung zwischen Fragment und Aussage bewahren und darf nicht bloß am Ende eine dekorative Quellenliste tragen. Verlangt die Frage eine Handlung – etwa eine Preisänderung im CRM –, sollte das Modell sie nicht frei ausführen dürfen: Ein strukturierter Werkzeugaufruf wird durch Anwendungscode, Berechtigungen und einen Freigabeschritt geprüft. Der Abruf hilft, eine Begründung zu finden; er ist keine Handlungserlaubnis.

In der Praxis bewährt sich ein hybrider Abruf, bei dem ein exakter Produktcode oder eine Richtliniennummer als Stichwort gesucht wird, die Bedeutung der Frage dagegen semantisch; anschließend wählt ein Reranking die Fragmente aus, die die vollständige Frage am besten beantworten. Diese Abfolge muss mit echten Abkürzungen, falsch geschriebenen Codes, Flexionsformen und mehrsprachigen Dokumenten getestet werden, denn eine Demonstrationsfrage ist gewöhnlich zu sauber. Taucht das benötigte Fragment unter den Kandidaten nicht auf, kann das generierende Modell es nicht durch Sprachgewandtheit zurückholen; deshalb ist der Suchfehler zu beheben, bevor der Prompt umformuliert wird.

Für welche dokumentenbasierten Anwendungen RAG geeignet ist

Die besten Kandidaten sind Fragen, deren Antwort bereits in vielen verwalteten Dokumenten liegt, deren Suche für einen Menschen aber zu lange dauert: interne Verfahren, Produkthandbücher, technische Anleitungen, Qualitätsdokumentation, Erläuterungen zu Vertragsvorlagen und Wissensbestände des Kundensupports. Die Aufgabe von RAG besteht hier nicht darin, eine neue Entscheidung zu erfinden, sondern den einschlägigen Abschnitt zu finden, einige miteinander vereinbare Fragmente zu verbinden und einen Entwurf zu erstellen. Eine gute Frage lautet: „In welcher Anleitung wird dieser Fehler beschrieben, und welche Prüfschritte nennt sie?“, nicht: „Wie soll das Unternehmen in jeder Notlage handeln?“. Nützlich ist außerdem eine Dokumentenrecherche vor der eigentlichen Arbeit: Ein Projektleiter kann Lieferbedingungen in Verträgen finden, ein Einkäufer Erwähnungen einer Anforderung und ein Servicemitarbeiter frühere Lösungen für eine ähnliche Anlage. In solchen Fällen muss die Antwort die genaue Fundstelle öffnen, damit der Nutzer den Kontext prüfen kann; zugleich muss das System Anfrage, gefundene Fragmente und verwendete Version protokollieren. So wird RAG zu einem Navigations- und Entwurfswerkzeug statt zu einem anonymen Urteilsgeber, dessen Entscheidungsweg später nicht mehr nachvollzogen werden kann.

Schlechte Kandidaten sind Aufgaben ohne stabile dokumentarische Grundlage, mit präziser Arithmetik oder zwingender Regelausführung sowie Fälle, in denen ein einzelner Fehler automatisch eine unumkehrbare Handlung auslöst. Gehaltsberechnung, Vergabe von Zugriffsrechten, Zahlungsausführung und Überwachung einer rechtlichen Frist gehören in Code und überprüfbare Geschäftsregeln; RAG kann die Erläuterung eines Verfahrens finden, aber weder Rechenwerk noch Autorisierungskette ersetzen. Wenn das eigentliche Ziel darin besteht, Systeme zu verbinden und Daten vorhersehbar zu übertragen, ist die Geschäftsprozess-Automatisierung zu prüfen, statt eine generierte Antwort zum zentralen Schalter des Prozesses zu machen.

Zur Eignung gehört auch ein Verantwortlicher: Jeder Dokumentenbestand braucht einen Menschen, der Quellen freigibt, Konflikte löst und über die Entfernung aus dem Index entscheidet; jede Anwendung benötigt ein Team, das Fehler prüft und den Testsatz anpasst. Übernimmt niemand diese Arbeit, wird der Pilot nach einigen Monaten zum Spiegel alter Dokumente, obwohl sich das Modell selbst nicht verändert hat. Ein technisch einfacher, aber verwalteter Supportleitfaden ist deshalb ein besseres erstes Projekt, als an einem Abend das gesamte Unternehmenslaufwerk anzuschließen.

Was RAG im Alltag mit Unternehmensdokumenten leisten kann

RAG kann die Zeit verkürzen, die Beschäftigte mit dem Erraten des richtigen Ordners und der passenden Stichwörter verbringen, weil eine semantische Suche ein Fragment auch dann findet, wenn die Wörter der Frage nicht mit der Terminologie im Dokument übereinstimmen. Es kann mehrere vereinbare Quellen in einer Antwort verbinden, eine komplizierte Anleitung einfacher erklären, einen E-Mail- oder Berichts­entwurf erstellen und zeigen, aus welchen Seiten jede wesentliche Aussage stammt. OpenAI File Search und die Sucharchitektur von Microsoft sind konkrete Beispiele für Werkzeuge, doch die Produktwahl hebt die Pflicht nicht auf, den eigenen Dokumentenstatus, die Filter und Qualitätsprüfungen festzulegen. Das System kann zudem Dokumentationsprobleme offenlegen, die beim gewöhnlichen Durchsuchen von Ordnern verborgen bleiben: Zu einer Frage erscheinen zwei widersprüchliche Anweisungen, häufige Fragen besitzen keine Quelle, oder eine Abteilung dominiert die Ergebnisse, weil ihre Dateien besser strukturiert sind. Diese Fälle sind nur wertvoll, wenn sie nicht hinter einer einzigen glatten Antwort verschwinden; eine fehlende Quelle und ein Konflikt müssen zu messbaren Ereignissen werden, die der Dokumenteneigentümer sieht. Dann wird das RAG-Qualitätsprotokoll zugleich zu einer Aufgabenliste für das Wissensmanagement und nicht bloß zu einem Diagramm der Modellleistung.

Eine weitere reale Möglichkeit ist die Anpassung an Rolle und Kontext: Ein Techniker erhält eine ausführliche Anleitung mit Codes, ein Kundenberater dagegen eine kürzere Erklärung, sofern beide dieselben Quellen sehen dürfen. Die Darstellung unterscheidet sich, nicht die Wahrheit; für jede Rolle bleiben derselbe Quellenstatus und dasselbe Verbot bestehen, Fehlendes zu erfinden. Unsere Arbeit an KI-Lösungen für Unternehmen beginnt mit der Abgrenzung eines solchen Anwendungsfalls und seiner Risiken statt mit einer Modelldemonstration, denn ein guter Prototyp weist einen konkreten Arbeitsnutzen anhand Ihrer Dokumente nach und zeigt zugleich, bei welchen Fragen das System „Ich weiß es nicht“ sagen muss.

Im Alltag entsteht der größte Nutzen, wenn der Mensch erkennt, was das System bereits für ihn erledigt hat und was noch zu prüfen ist. Im Antwortentwurf lassen sich Aussagen mit unvollständiger Begründung markieren, verwandte Dokumente anbieten und falsche Versionen mit einer einzigen Aktion melden; eine solche Rückmeldung ist wertvoller als ein einfacher Daumen. Die Korrektur muss mit Frage, Fragment und Fehlerart verknüpft werden, damit das Team zwischen einer nicht gefundenen Quelle, unbeholfener Sprache und einer falschen Geschäftsregel unterscheiden und die passende Korrektur wählen kann.

Was RAG nicht kann, so überzeugend die Antwort auch klingt

RAG kann keine Wahrheit garantieren, denn ein Fehler kann vor, während oder nach der Generierung entstehen: Die Quelle kann eine falsche Tatsache enthalten, der Abruf ein ungeeignetes Fragment auswählen, der Kontext eine Ausnahme verlieren und das Modell korrekte Absätze falsch miteinander verbinden. Ein Zitat mindert das Risiko blinden Vertrauens nur dann, wenn der Nutzer die genaue Stelle öffnen und prüfen kann, ob die Aussage tatsächlich daraus folgt; ein Link zu einem echten PDF ist dagegen ebenso wenig ein Qualitätssiegel, wie eine Bibliografie in einem fehlerhaften Bericht die Schlussfolgerung richtig macht.

RAG kann Zugriffskontrollen nicht selbst durchsetzen: Filtert die Suchschicht Dokumente vor dem Abruf nicht anhand einer geprüften Nutzeridentität und der Dokumentenberechtigungen, kann ein Fragment in den Modellkontext gelangen, das der Nutzer nicht sehen darf; ein später in den Prompt geschriebenes „Keine vertraulichen Informationen preisgeben“ behebt diesen Architekturfehler nicht. Microsofts Leitlinien zur Zugriffskontrolle auf Dokumentebene sehen Berechtigungsdaten und Sicherheitsfilter im eigentlichen Suchpfad vor; eine in der Oberfläche versteckte Schaltfläche schützt nicht, wenn sich die Anfrage auf einem anderen Weg auslösen lässt.

RAG macht auch nicht vertrauenswürdige Inhalte nicht sicher: Ein Dokument, eine Webseite oder eine E-Mail kann eine Anweisung enthalten, die das vorgesehene Systemverhalten umzuschreiben versucht – eine Prompt-Injection –, und OWASP führt dies als eigenständiges Risiko auf, das sich nicht vollständig durch ein einfaches Verbot im System-Prompt lösen lässt. Externe Inhalte sind daher als Daten und nicht als Befehle zu behandeln; Werkzeugaufrufe müssen eng begrenzt und validiert sein, während eine risikoreiche Handlung einer deterministischen Regel und menschlichen Freigabe vorbehalten bleibt. Das Modell darf etwas vorschlagen; die Befugnis erteilt das System.

Zu den Grenzen gehören ebenso Verfügbarkeit und Betriebskontinuität: Ist der Suchindex nicht erreichbar, darf ein sicheres System nicht vortäuschen, weiterhin über Unternehmensquellen zu verfügen, sondern muss eindeutig in einen Fehlerzustand oder eingeschränkten Modus wechseln; andernfalls kann der Nutzer eine quellenbasierte Antwort nicht von einer freien Improvisation des Modells unterscheiden. Außerdem sind Kosten- und Anfragelimits, eine Notabschaltung und die Wiederherstellung der vorherigen Konfiguration einzuplanen. Ein RAG-Produkt ist eine Kette mehrerer Dienste, und jeder stille Ausfall kann die Bedeutung der Antwort verändern, obwohl das Chatfenster weiter funktioniert.

Dokumentenreife: OCR, Metadaten und Versionsverwaltung

Die Größe eines Dokumentenordners ist kein Reifegrad: Ein schief gescannter Vertrag, eine Tabelle ohne lesbare Überschrift, ein PDF mit falscher Textreihenfolge oder ein kontrastarmes Foto können für einen Menschen verständlich wirken, während im OCR-Auszug eine Ziffer, die Zuordnung einer Spalte oder eine Absatzgrenze verloren geht. Microsofts Beschreibung der OCR-Grenzen verknüpft das Ergebnis ausdrücklich mit Scanqualität, Auflösung, Kontrast, Beleuchtung, Drehung und Texteigenschaften. Repräsentative Dokumente sind deshalb nach der Extraktion zu prüfen, indem Text, Tabellen, Seitenverweise und wesentliche Felder mit dem Original verglichen werden, statt darauf zu vertrauen, dass eine Datei „erfolgreich verarbeitet“ wurde.

Metadaten geben einem Fragment den organisatorischen Kontext: Dokumenttyp, Organisationseinheit, Produkt, Sprache, Eigentümer, Freigebender, Vertraulichkeit, Gültigkeitsbeginn und Versionsstatus erlauben es, die Suche bereits vor dem semantischen Ähnlichkeitsvergleich einzugrenzen. Ohne sie vergleicht die Suchmaschine Sätze, weiß aber nicht, dass die Lageranweisung nur für Litauen gilt oder ein Vertragsanhang durch eine neuere Fassung ersetzt wurde. Die wichtigsten Felder müssen aus einem verlässlichen System stammen oder von einem Menschen geprüft werden; eine generierte Vermutung über den Dokumentenstatus darf nicht zum Filter werden, der die nächste Antwort bestimmt.

Auch Aktualisierung ist Teil des Produkts und kein einmaliger Import: Es muss bekannt sein, wie schnell eine genehmigte Änderung im Index erscheint, wie ein zurückgezogenes Fragment gelöscht wird, was bei einer geänderten Dateiadresse geschieht und ob das System bei einem Fehler weiterhin die alte Version zeigt. Microsofts Indexleitlinien unterscheiden inkrementelle Aktualisierungen von einer Neuindexierung, weshalb jede Quelle eine dokumentierte Methode für Synchronisation und Fehlerkontrolle benötigt. Vor einem RAG-Projekt lohnt es sich, einen einzigen autoritativen Dokumentenfluss zu ordnen; andernfalls beschleunigt ein schneller Abruf nur die Folgen einer unklaren Verwaltung.

Vor der ersten Indexierung ist eine Stichprobe zur Dokumentenreife hilfreich: Ausgewählt werden unterschiedliche Dateitypen, Altersstufen, Sprachen, Tabellen, Scans und Zugriffsklassen; anschließend prüft man für jedes Exemplar den extrahierten Text, die Fragmentgrenzen, Metadaten und den Quellenlink. Die Fehlerquote sollte nicht in einen einzigen Durchschnittswert überführt werden, denn ein verlorenes Komma in einer Anleitung und ein verlorener Betrag in einem Vertrag haben unterschiedliche Folgen. Die Stichprobe schafft eine Grundlage für die Entscheidung, welche Formate automatisch angenommen werden, welche eine menschliche Prüfung benötigen und welche vorerst nicht indexiert werden; diese Arbeit steigert die Qualität oft stärker als die Wahl eines anderen Sprachmodells.

Zugriffsrechte, Datenschutz und die Wahl der Bereitstellung

Eine sichere Architektur beginnt mit der Identität: Wer fragt, zu welcher Organisation und Abteilung gehört die Person, welche Dokumentenklassen darf sie sehen, und werden diese Rechte bei jeder Abrufanfrage geprüft? Der Berechtigungsfilter muss greifen, bevor Fragmente in den Modellkontext gelangen; zugleich ist in Protokollen eine unnötige Kopie vollständiger Fragen, Antworten und sensibler Fragmente zu vermeiden. Auch Grenzfälle sind zu testen: Ein Mitarbeiter wechselt die Rolle, ein Dokument wird eingeschränkt, ein Zugriff widerrufen oder ein Kunde versucht, Inhalte eines anderen Kunden zu finden. „Der Chat verlangt eine Anmeldung“ ist kein ausreichendes Abnahmekriterium.

Auf die Frage „Werden meine Daten für das Modelltraining verwendet?“ gibt es ohne Nennung von Anbieter, Produkt, Konto und Einstellungen keine ehrliche allgemeine Antwort. Die Geschäfts- und API-Unterlagen von OpenAI sehen vor, dass Daten der betreffenden Geschäftsprodukte standardmäßig nicht für das Modelltraining verwendet werden; die Dokumentation zur API-Datenkontrolle beschreibt dagegen Speicherung, Missbrauchsüberwachung und Ausnahmen einzelner Endpunkte gesondert. Auch Anthropic unterscheidet zwischen der Verarbeitung in kommerziellen Produkten, einer bewussten Einwilligung zur Verbesserung und den jeweiligen Speicherbedingungen. Vertrag und technisches Konzept müssen deshalb den konkreten Dienst prüfen, statt sich auf die Formulierung „Business-API“ zu verlassen.

Eine Bereitstellung in einer EU-Region oder in der eigenen Infrastruktur kann helfen, bestimmte Anforderungen an Datenstandort, Kontrolle oder Integration zu erfüllen, belegt für sich allein jedoch weder DSGVO-Konformität noch Sicherheit. Weiterhin festzulegen sind Verarbeitungszweck und Rechtsgrundlage, Datenminimierung, Aufbewahrungsfristen, Unterauftragsverarbeiter, Löschung, Vorfallprozess und Zugriffsprüfung; die Grundsätze der DSGVO gelten für die gesamte Kette und nicht nur für das Land des Modellservers. Mitunter ist es die richtige Entscheidung, bestimmte Dokumente überhaupt nicht in RAG aufzunehmen oder vor dem Indexieren Felder zu entfernen, die für die Antwort nicht benötigt werden.

Das Bedrohungsmodell muss nicht nur einen neugierigen Mitarbeiter berücksichtigen, sondern auch eine fehlerhafte Gruppensynchronisierung, einen geteilten Link, eine Administratorrolle, einen gespeicherten Cache und ein Dokument mit einer bösartigen Anweisung. Testnutzer müssen jede Rolle und jede unzulässige Rollenkombination abdecken und direkt, mit Synonymen sowie durch eine indirekte Bitte um Zusammenfassung fragen; im Ergebnis dürfen weder ein Fragment noch der Dokumentname oder ein aus der Antwort ableitbares Geheimnis erscheinen. Nach einer Rechteänderung ist der Test zu wiederholen, weil der sichere Filter von gestern im Cache verblieben sein kann. Diese Prüfungen sind Abnahmekriterien und keine Dekoration für ein späteres Sicherheitsaudit.

Wie Abruf, Quellenbezug und Richtigkeit gemessen werden

Eine einzige „Genauigkeit“ für ein RAG-System gleicht einer einzigen Durchschnittsbewertung für ein Krankenhaus: Die Zahl kann gut aussehen, während eine kritische Fehlerklasse unsichtbar bleibt. Zunächst wird der Abruf gesondert gemessen – erschien das benötigte Fragment innerhalb einer festgelegten Zahl der höchsten Treffer, und wurde es nicht durch ungeeignete Fragmente verdrängt? Danach misst man die Relevanz des Kontexts für die Frage, den Quellenbezug der Antwort auf die bereitgestellten Fragmente, die sachliche Richtigkeit gegenüber einer genehmigten Referenz, die Eignung jedes Quellenverweises für die konkrete Aussage und die Fähigkeit des Systems, eine Antwort zu verweigern, wenn eine Quelle fehlt oder Quellen einander widersprechen.

Die Dokumentation zu den RAG-Evaluatoren von Microsoft trennt diese Dimensionen; ähnlich unterscheidet die Forschungsarbeit ARES zwischen Kontextrelevanz, Quellenbezug der Antwort und Antwortrelevanz. Im praktischen Testsatz benötigt jede reale Frage deshalb nicht nur eine „richtige Antwort“, sondern ebenso die zwingende Quelle, zulässige Formulierungen, verbotene Aussagen, die Rolle, die Dokumentversion und das erwartete Verhalten bei unzureichenden Belegen. Ein Teil der Beispiele stammt aus häufigen Fragen, ein anderer aus kostspieligen Ausnahmen und absichtlich eingebauten Fallen.

Für jede Dimension und Risikoklasse ist die Abnahmeschwelle festzulegen, bevor die Ergebnisse vorliegen; sonst wählt das Team nach der Demonstration die Kennzahl, die am besten aussieht. Die Pilotmessungen müssen außerdem die Fehlerverteilung nach Dokumenttypen, Abteilungen, Sprachen und Fragearten bewahren, denn der Gesamtdurchschnitt kann verbergen, dass Handbücher gut funktionieren, Vertragstabellen dagegen schlecht. Ein automatischer Modellbewerter hilft, die Prüfung zu skalieren, doch eine Stichprobe muss von Menschen geprüft und eine kritische Antwort mit einer autoritativen Quelle verglichen werden, nicht mit der Überzeugung eines zweiten Modells.

Nach dem Start sind dieselben Dimensionen mit einer kontrollierten Produktionsstichprobe und datenschutzschonenden Protokollen zu messen. Eine Änderung am Dokumentenkorpus, am Chunking-Algorithmus, am Embedding-Modell, am Reranking oder am generierenden Modell kann eine Fragengruppe verbessern und eine andere verschlechtern; deshalb benötigt jede Version einen Regressionstest und eine vergleichbare Basislinie mit unveränderten Bewertungsregeln für den gesamten Testsatz. Eine Warnung darf nicht nur beim Rückgang der Gesamtkennzahl ausgelöst werden, sondern auch beim Auftreten eines kritischen Fehlers, etwa eines unzulässigen Fragments oder einer erfundenen Antwort dort, wo eine Verweigerung erwartet wurde.

RAG, Suche, langer Kontext, Modellanpassung und Agenten

Eine gewöhnliche Volltextsuche ist besser, wenn der Nutzer den genauen Namen, Code oder Ausdruck kennt und ein Dokument statt einer zusammengestellten Antwort benötigt; sie ist günstiger, vorhersehbarer und leichter zu prüfen. Die semantische Suche hilft bei Synonymen und unklaren Fragen, doch die Generierung sollte nur dort hinzukommen, wo eine Zusammenfassung echten Wert schafft. RAG ist für eine unternehmensinterne Suche nicht zwingend: Mitunter ist das richtige Produkt eine gute Suchseite mit Filtern, Fragmentvorschau und Versionsstatus, weil der Nutzer die Schlussfolgerung selbst aus dem vollständigen Dokument zieht.

Ein vollständiges Dokument in ein langes Kontextfenster zu legen kann bei einem kleinen, stabilen Material einfach sein; in einem großen Korpus steigen jedoch Kosten, Rauschen und das Risiko, dass ein wesentlicher Absatz zwischen unwichtigem Inhalt verloren geht. Eine zusätzliche Modellanpassung, also Fine-Tuning, kann Format, Stil oder das Verhalten bei einer bestimmten Aufgabe festigen, ist aber keine praktische Ablage für häufig wechselnde Preise, Richtlinien und Anweisungen, weil Aktualisierung und Zitieren der Quelle weniger transparent werden. RAG erlaubt es, den Dokumentenbestand unabhängig vom Training der Modellgewichte zu ändern; diese Flexibilität erfordert dafür die Verwaltung von Index, Versionen und Abrufqualität.

Eine Automatisierung führt vorab definierte Schritte aus, während ein KI-Agent ein Werkzeug und den nächsten Schritt auswählen kann; diese Freiheit verlangt strengere Grenzen für Befugnisse, Validierung und Abbruch. RAG kann dem Agenten Informationen geben, aber keine Rechte: Findet das Modell eine Urlaubsrichtlinie, darf es deshalb noch keine Abwesenheit genehmigen oder das Lohnsystem verändern. Ein strukturierter Funktionsaufruf ist lediglich ein Vorschlag an die Anwendung, die Schema, Identität, zulässige Handlung, Beträge oder andere Limits und die erforderliche menschliche Freigabe prüft. Der Technologievergleich beginnt mit dem Prozessrisiko und nicht mit dem Wunsch, den modernsten Begriff zu verwenden.

Die Wahl lässt sich als einfache Prüfung formulieren: Soll eine Datei gefunden und geöffnet werden, beginnt man mit einer Suche; sollen einige veränderliche Quellen samt Verweisen zusammengefasst werden, prüft man RAG; soll ein stabiles Format oder Klassifikationsverhalten eingehalten werden, kommt eine Modellanpassung infrage; soll eine vorhersehbare Abfolge von Handlungen ausgeführt werden, baut man eine Automatisierung. Ein Agent kommt nur hinzu, wenn sich der nächste Schritt nicht sicher programmieren lässt und der Nutzen das zusätzliche Risiko überwiegt. Diese Ansätze lassen sich kombinieren, doch jede Schicht braucht eine eigene Aufgabe, Kennzahl und Abbruchgrenze; sonst verschwindet die Fehlerursache hinter dem Wort „KI“.

Wie ein begrenzter Pilot mit echten Fragen aufgebaut wird

Ein Pilot beginnt mit einem Dokumentenbestand, einer Nutzergruppe und einer Entscheidungsgrenze, beispielsweise mit Handbüchern des technischen Supports, bei denen das System ausschließlich Quellen findet und einen Antwortentwurf vorbereitet. Vor der Entwicklung sammelt das Team reale Fragen aus Suchprotokollen, E-Mails und Mitarbeitergesprächen, fügt die richtigen Quellen hinzu und nimmt bewusst unbeantwortbare, veraltete, widersprüchliche und unzulässige Fälle auf. Für jeden Fall wird festgelegt, was als akzeptabel gilt: Das erforderliche Fragment wurde gefunden, die Aussage ist durch die Quelle gestützt, das Zitat führt an die richtige Stelle, die Antwort ist sachlich richtig und das System erfindet fehlende Angaben nicht.

Die Schwellenwerte werden vor der Demonstration festgelegt und nach Risiko getrennt: Bei einer häufigen Informationsfrage kann ein korrigierbarer Entwurf genügen, bei Fragen zu personenbezogenen Daten, Verträgen, Sicherheit oder Zahlungen sind eine strengere Prüfung und eine menschliche Freigabe erforderlich. Im Piloten werden außerdem Antwortzeit, Kosten pro Anfrage, Funktion der Zugriffsfilter, Verzögerung der Indexaktualisierung und die Häufigkeit gemessen, mit der Beschäftigte eine Quelle öffnen oder eine Antwort korrigieren. Verbessert das System nur die Demonstrationsbeispiele, besteht aber keinen zuvor zurückgehaltenen Testsatz, ist kein Produktergebnis belegt; belegt ist lediglich, dass das Team eine Demonstration vorbereiten kann.

Unsere Entwicklung von KI-Lösungen kostet ab 3.500 € und dauert gewöhnlich 3–8 Wochen; einen funktionsfähigen Piloten mit Ihren eigenen Daten können wir dagegen in 2–3 Wochen liefern. Diese Zahlen nennen den Einstiegspreis der Leistung und den allgemeinen Zeitrahmen, nicht ein Festpreisangebot für einen unbekannten Umfang. Am Ende des Piloten sollten nicht bloß ein Chatfenster, sondern ebenso ein versionierter Dokumentenkorpus, Testfragen, getrennte Qualitätskennzahlen, ein Fehlerprotokoll, Zugriffsprüfungen und eine Entscheidung darüber vorliegen, was die Lösung nicht tun darf. Spätere Integrationsanforderungen sollten so klar festgehalten werden wie bei jedem anderen Digitalprojekt, nach dem in unserem Beitrag über 10 Fehler bei der Beauftragung einer Website-Entwicklung beschriebenen Grundsatz: Abnahmekriterien und Verantwortliche werden vor der vollständigen Umsetzung festgelegt und nicht erst nach dem ersten eindrucksvollen Bildschirm.

Der Pilot wird nur fortgeführt, wenn er die zuvor bestimmten Schwellenwerte an einem ungesehenen Teil des Testsatzes erreicht, unzulässige und unbeantwortbare Fragen sicher behandelt und einen messbaren Nutzen für die menschliche Arbeit schafft. Findet der Abruf systematisch nicht die richtige Quelle, werden zuerst Dokumente, Metadaten und Index verbessert; ist die Quelle richtig, wird aber durch die Generierung entstellt, werden Kontext, Prompt oder Modell geändert; tritt der Fehler nur bei risikoreichen Entscheidungen auf, bleiben diese einer deterministischen Lösung und einem Menschen vorbehalten. Ein gestoppter Pilot ist kein Misserfolg, sondern ein kostengünstig gewonnener Beleg dafür, dass bei diesem konkreten Prozess die Grenzen von RAG wichtiger sind als der Demonstrationseffekt.