Wann braucht Unternehmens-KI tatsächlich RAG?

💡 Kurz gesagt: zentrale Punkte

• Nicht jede Informationsfrage braucht RAG. Eine kleine, stabile Quelle kann direkt in den Kontext; aktuelle Transaktionsdaten sollten über API oder Datenbank kommen.
• RAG löst das Problem, die richtige Stelle in einer großen Dokumentensammlung zu finden. Ist die relevante Quelle bereits bekannt, kann eine weitere Retrieval-Schicht Komplexität ohne Nutzen hinzufügen.
• Ein Dokument zu finden, berechtigt nicht zu seiner Offenlegung. Zugriffskontrollen müssen gelten, bevor Inhalt das Modell erreicht; Retrieval-Qualität, Aktualität und Kosten sind mit echten Fragen zu testen.

Stellen Sie sich ein Kundensupport-System vor, das drei Fragen beantworten muss:

1. Welchen Filter braucht dieses Gerät für seine jährliche Wartung?
2. Wo befindet sich meine Bestellung gerade?
3. Enthält mein Vertrag für dieses Produkt einen Sonderrabatt?

Alle drei wirken wie Informationsfragen. Das System sollte die Informationen aber nicht auf dieselbe Weise beziehen.

Die erste Antwort kann auf einer einzelnen Seite eines Wartungshandbuchs stehen; diese Seite lässt sich mit der Frage direkt an das Modell geben. Die zweite ändert sich fortlaufend und sollte aus dem Bestellsystem oder dessen API kommen. Die dritte kann sowohl Vertrag als auch aktuellen Kundendatensatz verlangen. Das System muss zudem sicherstellen, dass die fragende Person beides sehen darf.

Sie könnten alle drei Fälle lösen wollen, indem Sie Dokumente in ein Suchsystem legen und RAG hinzufügen. Das macht es nicht zur richtigen Architektur.

Welches Problem löst RAG?

RAG, Retrieval-Augmented Generation, durchsucht einen Informationsbestand, bevor das Modell antwortet. Es findet relevante Passagen und fügt sie dem Kontext des Modells hinzu.

Kontext ist die Information, die einem Modell beim Erzeugen einer Antwort zur Verfügung steht: Nutzerfrage, Anweisungen, abgerufene Dokumente, frühere Nachrichten und Werkzeugergebnisse.

Ist das Quellenmaterial klein, brauchen Sie möglicherweise gar keine Retrieval-Schicht. In seinem Leitfaden zu Contextual Retrieval schreibt Anthropic, dass die gesamte Wissensbasis die einfachste Option sein kann, wenn sie bequem in den Modellkontext passt. Das Beispiel von 200.000 Tokens ist keine allgemeingültige Schwelle. Modell, Kosten, Latenz und Folgen eines Fehlers beeinflussen die Entscheidung.

Suche wird nützlich, wenn die Sammlung wächst oder vorher nicht bekannt ist, welcher Abschnitt zählt. Statt Tausende Seiten an das Modell zu senden, kann RAG die zur Frage passenden Passagen auswählen.

Das ist das Kernproblem von RAG: Wo befindet sich in einer großen Sammlung die Information, die das Modell braucht? Es ist ein wichtiges Problem, aber nicht der gesamte Unternehmenskontext.

Aktuelle operative Daten sind kein Dokument

Fragt ein Kunde „Wo ist meine Bestellung?“, steht die Antwort nicht in einem gestern vorbereiteten Dokument. Aktueller Bestellstatus, Ereignis des Versanddienstleisters und Lieferprognose liegen in operativen Systemen.

Diese Datensätze regelmäßig in Dokumente zu exportieren und in einen Suchindex zu kopieren, erzeugt eine Kopie, die sofort altert. Das System kann das richtige Dokument abrufen und trotzdem falsch antworten.

Verlässlicher ist, die Bestellnummer zu prüfen und den aktuellen Status über eine autorisierte API oder Datenbankabfrage zu lesen. Das Sprachmodell kann das Ergebnis verständlich für den Kunden formulieren. Das Bestellsystem bleibt die Informationsquelle.

Ein Unternehmenssystem muss daher vor „Welches Dokument soll ich abrufen?“ zunächst fragen, wo die Information liegt:

• direkter Kontext für kleine und stabile Quellen,
• Enterprise Search oder RAG für eine große Sammlung von Textdokumenten,
• Datenbankabfrage oder API für aktuelle Datensätze,
• deterministische Software für explizite, stabile Regeln.

Eine Antwort kann mehrere dieser Wege nutzen. Die Daten müssen nicht zuerst in einen einzigen Speicher kopiert werden.

Das richtige Dokument zu finden, gibt keinen Zugriff darauf

Das relevanteste Suchergebnis kann eine Vergütungstabelle, ein Mitarbeiterdatensatz oder ein Kundenvertrag sein, den der Nutzer nicht sehen darf.

Das korrekte Dokument abzurufen, macht den Zugriff nicht legitim. Authentifizierung, Nutzer- und Gruppenrechte, Mandantengrenzen und Zugriffskontrollen auf Dokumentebene müssen weiterhin durchgesetzt werden.

AWS warnt ausdrücklich, dass Berechtigungsfilter für Dokumente in Bedrock Knowledge Bases für sich allein keine Autorisierungsgrenze bilden. Der Dienst kann nicht prüfen, ob die von der Anwendung gelieferte Identität echt ist; die Anwendung bleibt für die Authentifizierung verantwortlich.

Azure AI Search kann Dokumentberechtigungen im Index speichern und sie zur Abfragezeit mit der Identität vergleichen. Änderungen der Berechtigungen im Quellsystem wirken sich jedoch erst nach Synchronisierung dieser Metadaten auf Suchergebnisse aus. Sowohl Berechtigungsmodell als auch dessen Aktualität zählen.

Die Grenze ist einfach:

Suche findet ein Dokument. Autorisierung entscheidet, ob dieses Dokument für diesen Nutzer gefunden werden darf.

Ein nicht autorisiertes Dokument darf nicht erst an das Modell übergeben und nach Erzeugung der Antwort herausgefiltert werden. Es muss entfernt werden, bevor es in die Kandidatenergebnisse gelangt.

Mehr Kontext liefert nicht immer eine bessere Antwort

Mit wachsenden Kontextfenstern liegt es nahe, jedes Dokument auf einmal zu senden. Bei einem kleinen, stabilen Informationsbestand kann das die einfachere und bessere Option sein.

Kontextkapazität und Kontextqualität sind jedoch verschieden. Je mehr irrelevantes Material vorliegt, desto schwerer kann es dem Modell fallen, das Wesentliche zu erkennen. In einer Studie, die RAG mit Long-Context-Ansätzen verglich, schnitt Long Context bei vielen Tests besser ab, wenn ausreichend Ressourcen verfügbar waren, während RAG einen klaren Kostenvorteil behielt. Das bedeutet weder, dass RAG überholt ist, noch dass Long Context nicht funktioniert. Leistung hängt von Frage, Quellenmaterial, Modell und wirtschaftlicher Beschränkung ab.

Qualität hängt auch davon ab, wie Dokumente geteilt werden, ob exakte Stichwortsuche und semantische Suche kombiniert werden und ob die ersten Treffer neu gerankt werden. Microsofts Hinweise zu RAG-Retrieval weisen darauf hin, dass Reranking Relevanz verbessern kann, aber jeder Abfrage Latenz hinzufügt.

Stichwortsuche, semantische Suche und ein zusätzliches Reranking-Modell sind keine Reifegrade. Jede ist eine Intervention gegen einen bestimmten Retrieval-Fehler. Funktioniert die einfache Suche, macht zusätzliche Technik das System nicht unternehmensreifer.

Die Entscheidung vor dem Bau von RAG

Ein Unternehmen muss nicht mit „Sollen wir RAG bauen?“ beginnen. Hilfreicher ist die Frage:

Wie gelangt die richtige, autorisierte Information in dem Moment in dieses System, in dem sie gebraucht wird?

Ist die Information klein und stabil, kann direkter Kontext reichen. Muss das System eine große Dokumentensammlung durchsuchen, können RAG oder Enterprise Search sinnvoll sein. Braucht es aktuellen operativen Zustand, sollte es das Quellsystem abfragen. Variiert der Zugriff nach Nutzer, müssen Berechtigungen vor dem Retrieval durchgesetzt werden.

RAG ist eine dieser Optionen und am richtigen Ort leistungsfähig. Wird es zum Sammelbegriff für jedes Datenproblem, verdeckt es gerade die Entscheidungen zu Quelle, Zugriff und Aktualität, die wichtiger sind.

Die Grenze zwischen Fine-Tuning, direktem Kontext und RAG anhand von Information, Regeln und gelernten Mustern habe ich im vorigen Artikel behandelt.

Die weiteren Entscheidungen zu Modellen, Information, Befugnis und Evaluierung finden Sie im Leitfaden für den Entwurf eines KI-Systems für Ihr Unternehmen.