RAG auf Unternehmensdaten: was es braucht und wo es meist scheitert

Wie eine RAG-Pipeline funktioniert: vier Schritte

RAG auf Unternehmensdaten (Retrieval-Augmented Generation) besteht aus vier Schritten: die Abschnitte in den Dokumenten des Unternehmens finden, die die Frage beantworten, sie in den Prompt legen, das Modell ausschließlich daraus antworten lassen und dem Nutzer zeigen, woher die Antwort stammt.

Die meiste Arbeit steckt im ersten Schritt. Enthalten die gefundenen Abschnitte die Antwort, liefert ein aktuelles Instruct-Modell sie meist, auch wenn eine Antwort in der Mitte eines langen Kontexts weniger zuverlässig gefunden wird. Enthalten sie sie nicht, hilft weder ein anderer Prompt noch ein anderes Modell; messen Sie deshalb die Suche, bevor Sie Prompts anpassen oder Modelle tauschen.

Für die Planung heißt das, dass ein RAG-Projekt überwiegend ein Data-Engineering-Projekt ist und auch so geplant und besetzt werden sollte. Ob sich stattdessen Fine-Tuning eines Modells lohnt, ist eine eigene Frage, die unser Vergleich von Fine-Tuning und RAG beantwortet.

Zugriffsrechte: beim Abruf durchsetzen

Ein Abfluss gesperrter Dokumente hat rechtliche Folgen, deshalb steht dieser Punkt vorn.

Eine verlockende Abkürzung ist, alles in eine Sammlung zu indexieren und dem Modell aufzutragen, keine Dokumente preiszugeben, die der Nutzer nicht sehen darf. Damit wird der Zugriff nicht kontrolliert. Eine Prompt-Anweisung ist eine Bitte an ein probabilistisches System, und wenn das Modell sie verarbeitet, liegt die Gehaltstabelle bereits im Kontextfenster.

Die Berechtigungen müssen beim Abruf greifen: Die Suche selbst gibt nie einen Abschnitt zurück, den der anfragende Nutzer im Quellsystem nicht öffnen dürfte. Dafür sind drei Maßnahmen nötig.

Die Zugriffskontrolllisten (ACLs) in den Index übernehmen. Jeder Abschnitt speichert, welche Nutzer und Verzeichnismitgliedschaften sein Quelldokument lesen dürfen, und die Abfrage filtert auf die Identität und die Mitgliedschaften des Anfragenden. Bei einem approximativen Vektorindex muss der Filter vor oder während der Suche greifen: Wird er erst danach auf die Kandidaten angewendet, bleiben einem Nutzer, der nur einen kleinen Teil des Bestands lesen darf, zu wenige Abschnitte. Unser Vergleich von Vektordatenbanken zeigt, wie pgvector, Qdrant, Milvus und OpenSearch damit umgehen.

Auch bei Berechtigungsänderungen neu abgleichen, nicht nur bei Dokumentänderungen. Die Verzeichnismitgliedschaft einer Person ändert sich, und die Dokumente haben sich überhaupt nicht geändert, ihr Zugriff aber schon. Indizes, die nur auf Änderungsdaten von Dateien achten, übersehen das, und die alte Berechtigung bleibt im Index, bis sich das Dokument selbst ändert.

Protokollieren, was für wen abgerufen wurde. Wenn jemand fragt, ob der Assistent ein Dokument hätte offenlegen können, gibt das Protokoll die Antwort.

Der Filter beim Abruf hält fremde Dokumente aus dem Kontext heraus. Er verhindert nicht, dass ein Dokument, das der Nutzer lesen darf, Anweisungen an das Modell enthält, etwa Daten über einen Link oder einen Tool-Aufruf nach außen zu senden. Das ist indirekte Prompt Injection. OWASP führt Prompt Injection als LLM01 an erster Stelle seiner Top 10 for LLM Applications 2026, und unser Leitfaden zu Prompt Injection beschreibt die Gegenmaßnahmen, die sie begrenzen.

Wo die Quellsysteme verschachtelte, geerbte Berechtigungen haben (ein über viele Jahre gewachsenes Dokumentenmanagementsystem ist der Normalfall), bestimmt dieser Schritt den Projektzeitplan. Das sollte man gleich zu Beginn herausfinden.

Assistenten, die wir im Rahmen unserer Leistung Private AI/ML bauen, antworten aus Ihren Dokumenten, nennen die Quelle und beachten die Zugriffsrechte jedes Nutzers. Nennen Sie uns die Systeme, in denen die Dokumente liegen, und wie dort Berechtigungen vergeben werden; wir antworten innerhalb eines Werktages.

Zerlegung und Metadaten

Dokumente werden vor dem Indexieren zerlegt, und wie sie zerlegt werden, entscheidet, was gefunden werden kann.

Metadaten werden zweimal genutzt: beim Abruf, wo Sie die Suche auf eine Dokumentart oder einen Zeitraum einschränken können, und in der Antwort, wo eine Quellenangabe mit echtem Dokumentnamen und Datum das System vertrauenswürdig macht. Mit einer Quellenangabe kann der Nutzer die Quelle öffnen und die Antwort in wenigen Sekunden prüfen.

Hybride Suche, Stichwortsuche kombiniert mit semantischer Ähnlichkeit, lohnt den geringen Mehraufwand in fast jedem Unternehmensbestand. Einbettungsmodelle erfassen die Bedeutung, können aber exakte Treffer verfehlen; Teilenummern, Vertragsreferenzen, Fehlercodes und Projektnamen brauchen daher zusätzlich die Stichwortsuche.

Einen Testsatz aus echten Fragen aufbauen

Schreiben Sie fünfzig bis hundert echte Fragen der Menschen auf, die das System nutzen werden, mit der richtigen Antwort und dem Dokument, aus dem sie kommen soll. Das braucht eine Fachperson und ist die nützlichste Arbeit im Projekt.

Ohne ihn ist jede Änderung Ansichtssache: Jemand stellt die Zerlegung um, ein paar Kollegen probieren es aus, und niemand kann sagen, ob es besser ist. Mit ihm können Sie die zwei Dinge messen, auf die es ankommt:

Trefferquote der Suche: wie oft der richtige Abschnitt in den gefundenen enthalten ist. Ist sie niedrig, kann nichts danach die Antwort retten, und Sie wissen genau, wo zu arbeiten ist.

Antwortrichtigkeit: wie oft die Antwort stimmt, wenn der richtige Abschnitt vorlag. Erst wenn die Suche gut ist und diese Zahl trotzdem niedrig bleibt, liegt das Problem bei Prompt oder Modell. Metriken und Werkzeuge für beide Messungen beschreibt unser Leitfaden zur LLM-Evaluierung.

Die beiden Werte zeigen, wo anzusetzen ist: Eine niedrige Trefferquote deutet auf Zerlegung, Metadaten oder Suche hin, eine niedrige Antwortrichtigkeit bei guter Trefferquote auf Prompt oder Modell. Ein einziger Wert für die Endantwort verdeckt, welcher Teil versagt hat.

Den Index aktuell halten

Den größten Schaden für den Ruf des Systems richtet eine selbstsichere, gut formulierte Antwort aus einem Dokument an, das vor vier Monaten abgelöst wurde.

Bei Änderung indexieren, nicht nach Zeitplan, wo das Quellsystem das hergibt, damit eine korrigierte Richtlinie am selben Tag auffindbar ist. Das Dokumentdatum in jeder Quellenangabe zeigen, damit ein Mensch bemerkt, wenn die Antwort auf etwas Altem beruht. Und abgelöste Dokumente aus dem Index entfernen, statt auf die Bewertung zu vertrauen; ist die alte Fassung noch drin, wird sie irgendwann abgerufen.

Dazu gehört, dem System das Ablehnen beizubringen. Wird nichts Relevantes oberhalb einer Sicherheitsschwelle gefunden, lautet die richtige Ausgabe „dazu finde ich nichts in den vorliegenden Dokumenten“ und nicht ein plausibler Absatz aus benachbartem Material. Eine Antwort, die meldet, dass nichts gefunden wurde, schickt den Nutzer ins Quellsystem; nach einer selbstsicheren falschen Antwort wird womöglich gehandelt.

Hardware für RAG: Einbetten, Betrieb und Vektorindex

Die Last besteht aus zwei Teilen: dem Einbetten des Bestands und der Beantwortung der Fragen.

Das Einbetten des Bestands ist eine einmalige Lastspitze: Jedes Dokument wird einmal verarbeitet und danach nur noch, was sich ändert, bis Sie das Einbettungsmodell wechseln und alles neu einbetten müssen. Nach unserer Schätzung aus NVIDIAs NIM-Werten für sein Einbettungsmodell mit 1B Parametern in FP8 (144,3 Texte zu 512 Token je Sekunde auf einer L40S, 49,2 auf einer L4; Dokumentation von NIM 1.14.0 vom 30. September 2026) brauchen 300.000 Dokumente mit je zehn Chunks zu 512 Token auf einer L40S etwa 5,8 Stunden und auf einer L4 etwa 17 Stunden (große, von LLMs abgeleitete Einbettungsmodelle brauchen Tage, und das Parsen der PDFs dauert oft länger als das Einbetten). Danach fällt die Last auf nahezu null. Die Rechnung hinter diesen Werten und die GPU-Last eines Rerankers stehen in unserem Leitfaden zu Embedding- und Reranker-Servern für RAG.

Der Betrieb ist die Dauerlast, und sie hängt von gleichzeitigen Unterhaltungen ab und nicht von der Größe des Bestands. Der Vektorindex wird in GB gemessen, grob 4 Byte mal Dimensionen mal Chunks plus Index-Overhead, bei quantisiert gespeicherten Vektoren weniger, und liegt meist im Arbeitsspeicher, sofern die Datenbank ihn nicht auf der Platte hält; unser Vergleich von Vektordatenbanken für RAG nennt den Arbeitsspeicher je Million Vektoren für vier Datenbanken. Der GPU-Speicher geht an den KV-Cache für gleichzeitige Nutzer, und RAG-Prompts sind lang, weil jeder von ihnen gefundene Abschnitte enthält. Die Formeln für diese Dimensionierung stehen im Artikel Wie viel VRAM ein LLM braucht, der Kostenvergleich mit einer gehosteten API im Artikel Privates LLM oder Cloud-API.

Für die meisten internen Installationen ist das ein Server, kein Cluster, und ein Mehrknoten-Cluster sollte sich aus der gemessenen Abfragelast ergeben. Zwei der Referenz­konfigurationen auf unserer Seite KI-Server passen dazu: zwei Karten RTX PRO 6000 Server Edition für Pilotprojekte und RAG-Assistenten mit Modellen bis etwa 70B Parameter und vier für die produktive Inferenz mehrerer Teams und Modelle.

Die Dimensionierung dieses Servers, einschließlich der Modell- und GPU-Auswahl, ist Teil des technischen Assessments in unserer Leistung Private AI/ML, und wir liefern die Hardware unter demselben Vertrag. Schreiben Sie uns, wie viele Dokumente das System erfassen soll und wie viele Nutzer gleichzeitig damit arbeiten.

Mit einem eng umrissenen Pilotprojekt beginnen

Beginnen Sie mit einer Abteilung, einem Dokumentenbestand und einem klar umrissenen Fragetyp, und binden Sie die Menschen, die das System nutzen werden, von Anfang an ein. Bringen Sie dort die Trefferquote der Suche nach oben, bevor ein zweiter Bestand dazukommt.

Projekte geraten ins Stocken, wenn sie das Gegenteil tun: alles indexieren, was das Unternehmen hat, es allen vorführen, eine lange Liste unzusammenhängender Beschwerden einsammeln und nie herausfinden, welches Suchproblem zuerst zu lösen ist. Ein eng umrissener Pilot liefert einem Team messbare Antworten, und seine Trefferquote und Antwortrichtigkeit sind die Grundlage für die Entscheidung über den nächsten Dokumentbestand.

Was wir tun

Unsere Leistung Private AI/ML folgt der Reihenfolge oben. Das erste Gespräch mit unserem Engineering-Partner Vixen.UNO ist kostenlos und beginnt bei Ihren Dokumenten und der Frage, wie Berechtigungen heute funktionieren; das kostenpflichtige technische Assessment umfasst dann die Lösungsarchitektur, die Modell- und GPU-Auswahl und einen Pilotplan mit Metriken, zu einem Preis, der vor Beginn feststeht. Der Pilot läuft auf einem Dokumentenbestand, und skaliert wird nur, was seinen Wert bewiesen hat. Eurokommerz hält den Vertrag und liefert die Hardware; Vixen.UNO baut und betreut die Plattform, in Ihrer Infrastruktur oder auf dedizierter Hardware in einem Tier-III-Rechenzentrum in Litauen, und öffentliche APIs kommen nur zum Einsatz, wenn Sie sie für eine Aufgabe freigeben.

FAQ