RAG auf Unternehmensdaten: Was es braucht – und wo es meist scheitert

Was die Kette tatsächlich ist

Retrieval-Augmented Generation gilt als komplizierter, als sie ist. Reduziert sind es vier Schritte: die passenden Abschnitte finden, sie in den Prompt legen, das Modell ausschließlich daraus antworten lassen und dem Nutzer zeigen, woher die Antwort stammt.

Alles Schwierige steckt in Schritt eins. Das Modell ist der Teil, der funktioniert. Enthalten die gefundenen Abschnitte die Antwort, produziert sie praktisch jedes brauchbare Modell; enthalten sie sie nicht, schafft es keines. Deshalb kommen Teams, die ihre Kraft in Prompt-Formulierungen und Modellauswahl stecken, meist nicht über ein Plateau hinaus – und Teams, die sie in die Suchqualität stecken, liefern.

Für die Planung heißt das: Ein RAG-Projekt ist überwiegend ein Daten-Projekt. Kalkulieren Sie es so.

Das Berechtigungsproblem, das zuerst kommt

Das ist der Fehler mit echten Folgen, deshalb steht er vor der Qualitätsfrage.

Die verlockende Abkürzung ist, alles in eine Sammlung zu indexieren und dem Modell aufzutragen, keine Dokumente preiszugeben, die der Nutzer nicht sehen darf. Das ist keine Kontrolle. Eine Prompt-Anweisung ist eine Bitte an ein probabilistisches System – und die Gehaltstabelle liegt bereits im Kontextfenster, während das Modell überlegt, ob es diskret sein soll.

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. Praktisch bedeutet das dreierlei.

Die Zugriffslisten in den Index übernehmen. Jeder Abschnitt speichert, welche Identitäten und Gruppen sein Quelldokument lesen dürfen, und die Abfrage filtert vor der Bewertung auf die Identität des Anfragenden.

Auch bei Berechtigungsänderungen neu abgleichen, nicht nur bei Dokumentänderungen. Jemand verlässt eine Gruppe, und die Dokumente haben sich überhaupt nicht geändert – sein Zugriff aber schon. Indizes, die nur auf Änderungsdaten von Dateien achten, übersehen das vollständig, und so überlebt eine veraltete Berechtigung am häufigsten.

Protokollieren, was für wen abgerufen wurde. Wenn jemand fragt, ob der Assistent ein Dokument hätte offenlegen können, wollen Sie aus einem Protokoll antworten und nicht über Wahrscheinlichkeiten nachdenken.

Wo die Quellsysteme verschachtelte, geerbte Berechtigungen haben – eine lange gewachsene SharePoint-Umgebung ist der Normalfall – bestimmt dieser Schritt den Projektzeitplan. Das sollte man in Woche eins herausfinden.

Zerlegung und Metadaten: wichtiger als das Modell

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

Metadaten zahlen sich zweimal aus: beim Abruf, wo Sie auf Dokumentart oder Zeitraum einschränken können, und in der Antwort, wo eine Quellenangabe mit echtem Dokumentnamen und Datum das ist, was das System vertrauenswürdig macht. Ein Assistent, der seine Quellen nennt, wird von seinen Nutzern geprüft und korrigiert; einer, der es nicht tut, wird nach der ersten falschen Antwort still aufgegeben.

Hybride Suche – Stichwortsuche kombiniert mit semantischer Ähnlichkeit – lohnt den geringen Mehraufwand in fast jedem Unternehmensbestand. Rein semantische Suche versagt zuverlässig bei dem, wonach Unternehmen am häufigsten suchen: Teilenummern, Vertragsreferenzen, Fehlercodes, Projektnamen. Dafür braucht es exakte Treffer.

Der Testsatz, den niemand baut

Dieser Schritt trennt Projekte, die besser werden, von Projekten, die im Kreis laufen.

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 kostet zwei Tage mit einer Fachperson und ist die wertvollste Arbeit im ganzen Projekt.

Ohne ihn ist jede Änderung Ansichtssache: Jemand stellt die Zerlegung um, drei Leute probieren es, zwei sagen, es fühle sich besser an, und niemand weiß es. Mit ihm können Sie die einzigen 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. Ist die Suche gut und diese Zahl schlecht, liegt es an Prompt oder Modell – und erst dann.

Diese Trennung macht Fehlersuche überhaupt erst möglich. Die meisten Teams messen nur das Endergebnis, finden es enttäuschend und tauschen das Modell – also die eine Komponente, die vermutlich in Ordnung war.

Aktualität und der leise Fehler

Der Fehler mit dem größten Rufschaden ist nicht eine falsche Antwort. Es ist eine selbstsichere, gut formulierte Antwort aus einem Dokument, das vor vier Monaten abgelöst wurde.

Drei Gewohnheiten verhindern das. 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. Nutzer verzeihen ein „weiß ich nicht“. Selbstsicher in die Irre geführt zu werden verzeihen sie nicht, und es muss nur einmal passieren.

Worauf es läuft

Die Infrastrukturfrage fällt meist kleiner aus als erwartet und zerfällt in zwei Teile.

Das Einbetten des Bestands ist ein einmaliger Schub: Jedes Dokument wird einmal verarbeitet, danach nur noch, was sich ändert – bis Sie das Einbettungsmodell wechseln, denn dann wird alles neu eingebettet. Ein paar hunderttausend Dokumente sind ein Nachmittag auf einer professionellen GPU mit einem kleinen Einbettungsmodell (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.

Der Betrieb ist die Dauerlast, und sie hängt an gleichzeitigen Unterhaltungen, nicht an der Bestandsgröße – der Vektorindex wird in Gigabyte gemessen, grob 4 Byte mal Dimensionen mal Chunks plus Index-Overhead, und liegt im Arbeitsspeicher. GPU-Speicher verbrauchen die KV-Caches gleichzeitiger Nutzer, und RAG-Prompts sind lang, weil in jedem gefundene Abschnitte stecken. Danach ist zu dimensionieren: Die Formeln stehen in wie viel VRAM ein LLM braucht, der Kostenvergleich zur gehosteten API in privates LLM oder Cloud-API.

Für die meisten internen Installationen ist das ein Server, kein Cluster. Beginnt ein Angebot mit einem Mehrknoten-Cluster, bevor irgendjemand eine Abfrage gemessen hat, fragen Sie nach der Messung.

Die Reihenfolge, die funktioniert

Erst schmal. Eine Abteilung, ein Dokumentenbestand, ein klar umrissener Fragetyp – und die Menschen, die es nutzen werden, von Anfang an dabei. Bringen Sie die Trefferquote dort hoch, bevor ein zweiter Bestand dazukommt.

Das Fehlermuster ist das Gegenteil: 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 schmaler Pilot, der die Fragen eines Teams wirklich beantwortet, ist mehr wert als ein breiter, der die Fragen aller halb beantwortet – und er ist das, was für die nächste Stufe bewilligt wird.

Was wir tun

KI/ML-Integration ist ein Projekt, kein Produkt: zuerst eine technische Bewertung zum Festpreis – wie Ihre Dokumente wirklich aussehen, wie das Berechtigungsmodell funktioniert, welche Hardware die gemessene Last braucht – dann ein Pilot auf einem Bestand, dann Produktion. Eurokommerz hält den Vertrag und liefert die Hardware; unser Engineering-Partner Vixen.UNO baut und betreibt die Plattform. Alles bleibt in Ihrem Netz oder in EU-gehosteter Kapazität, je nachdem, was Sie brauchen.

Die Erstberatung ist kostenlos und besteht größtenteils aus Fragen zu Ihren Dokumenten und Ihren Berechtigungen, denn dort entscheidet sich das Projekt.

FAQ