RAG oder Enterprise Search: Antworten generieren oder Informationen finden?

Die Frage kommt selten so direkt, wie sie hier steht. Meistens klingt sie so: „Wir wollen, dass unsere Mitarbeitenden Fragen an unsere Dokumente stellen können, wie bei ChatGPT.” Dahinter stecken aber zwei sehr unterschiedliche Bausteine, die häufig durcheinandergeworfen werden: eine Suchfunktion, die Informationen findet, und ein Sprachmodell, das aus gefundenen Informationen einen Antworttext formuliert. Beides zusammen heißt Retrieval-Augmented Generation (RAG). Nur der erste Teil – ohne den generierenden Sprachmodell-Schritt – ist das, was seit Jahrzehnten als Enterprise Search bekannt ist.

Dieser Artikel ordnet beide Ansätze im Zusammenhang mit dem Cluster RAG, Wissensdatenbanken und Daten ein: Was leistet klassische Enterprise Search, was ergänzt RAG tatsächlich, wo unterscheiden sich Fehlerbilder und Transparenz, und nach welcher Logik triffst du die Entscheidung für dein Unternehmen. Nicht jede Wissensfrage braucht generierten Text – aber manche profitieren enorm davon.

Das Problem: falsche Frage, falsches Werkzeug

In Beratungsgesprächen erlebe ich häufig zwei Ausgangslagen. Die erste: Ein Unternehmen hat bereits eine gute Suche – etwa im Intranet, im Dokumentenmanagementsystem oder im Ticketsystem – und möchte jetzt zusätzlich „KI” draufsetzen, ohne zu klären, welches konkrete Problem damit gelöst werden soll. Die zweite, häufigere: Es gibt gar keine funktionierende unternehmensweite Suche, Wissen liegt verstreut in Laufwerken, E-Mail-Postfächern und Köpfen – und die Erwartung ist, dass ein RAG-Chatbot dieses Grundproblem quasi nebenbei mitlöst.

Beide Ausgangslagen führen zu Enttäuschung, wenn man die Werkzeuge verwechselt. Eine gute Suche braucht vor allem sauber indexierte, zugängliche und aktuelle Dokumente – daran ändert ein Sprachmodell obenauf nichts. Und ein RAG-System ist nur so gut wie die Dokumente, aus denen es zitiert; über schlecht gepflegte oder widersprüchliche Quellen hinweg generiert es trotzdem eine selbstsichere Antwort, die falsch sein kann. Die Entscheidung zwischen Enterprise Search und RAG ist deshalb zuerst eine Entscheidung über die Aufgabe, nicht über die Technologie.

Zielgruppe dieses Artikels sind Geschäftsführung, Operations, IT und Fachbereiche in KMU, die vor der Frage stehen, wie internes Wissen zugänglich gemacht werden soll – sei es für den Kundenservice, die interne Dokumentation, die Angebotserstellung oder die technische Wissensbasis.

Begriffe kurz geklärt

• Information Retrieval / Suche ist die Kerntechnologie, die zu einer Anfrage die relevantesten Dokumente oder Textabschnitte findet – klassisch über Schlagworte, moderner über semantische Ähnlichkeit mittels Embeddings.
• Enterprise Search ist eine Suchanwendung, die diese Retrieval-Technologie auf unternehmensinterne Datenquellen anwendet: Dateiablagen, Wikis, CRM, Ticketsysteme, E-Mail-Archive. Ergebnis ist eine Trefferliste mit Fundstellen, nicht ein neu formulierter Text.
• RAG (Retrieval-Augmented Generation) kombiniert genau diese Suchfunktion mit einem generativen Sprachmodell. Laut der Orientierungshilfe der Datenschutzkonferenz (DSK) zu RAG-Systemen besteht ein RAG-System im Kern aus Retriever, Embedding-Modell, Vektordatenbank und textgenerierendem Sprachmodell: Referenzdokumente werden in Textabschnitte (Chunks) zerlegt, per Embedding-Modell in Vektoren überführt und bei einer Anfrage nach semantischer Nähe durchsucht; die gefundenen Chunks ergänzen dann die Eingabe an das Sprachmodell, das daraus eine Antwort formuliert.
• Halluzination bezeichnet laut BSI Ausgaben eines Sprachmodells, die weder Teil der Trainingsdaten noch – im RAG-Fall – Teil der bereitgestellten Quelltexte waren, aber trotzdem plausibel formuliert werden.

Wichtig für die Abgrenzung: RAG ändert laut DSK nichts daran, wie das zugrunde liegende Sprachmodell trainiert wurde oder was es „weiß” – es reichert lediglich die Eingabe pro Anfrage um passende Textstellen an. Enterprise Search und der Retriever-Teil eines RAG-Systems sind technisch oft nahezu identisch; der Unterschied liegt im letzten Schritt: zeigen oder generieren.

Was leistet Enterprise Search?

Enterprise Search durchsucht vorhandene Dokumente und liefert echte Fundstellen samt Quellenangabe zurück, ohne Texte neu zu erzeugen. Nutzende bekommen eine sortierte Trefferliste – Dokumenttitel, Ausschnitt, Speicherort – und lesen den relevanten Abschnitt im Original. Das ist ideal, wenn die Aufgabe darin besteht, eine konkrete Information zu finden, mehrere Quellen zu vergleichen oder Verantwortung für die korrekte Auslegung eines Textes zu behalten, etwa bei Verträgen, Normen oder Richtlinien.

Der zentrale Vorteil: Was angezeigt wird, stand tatsächlich so im Dokument. Der Fehlerraum beschränkt sich im Wesentlichen auf die Relevanz-Sortierung – ein gutes Ergebnis kann auf Platz drei statt eins landen – nicht auf den Inhalt selbst. Enterprise Search „erfindet” nichts hinzu.

Die Grenze liegt in der Aufbereitung: Eine Trefferliste beantwortet keine zusammengesetzte Frage wie „Welche Kündigungsfristen gelten für Kunden in Kategorie B, und was ändert sich, wenn der Vertrag vor 2023 geschlossen wurde?” Dafür müsste die Person selbst mehrere Treffer lesen, verstehen und zusammenführen. Bei häufig wiederkehrenden, komplexen Fragen wird das schnell aufwändig – genau hier setzt RAG an.

Was ergänzt RAG?

RAG setzt eine Antwortschicht auf eine Suche. Statt einer Trefferliste bekommen Nutzende einen zusammenfassenden Antworttext in ganzen Sätzen, der die relevanten Fundstellen zu einer Aussage verdichtet – im Idealfall mit Verweis darauf, aus welchen Dokumenten die Antwort stammt. Für Fragen, die mehrere Quellen zusammenführen müssen, oder für Nutzende, die keine Zeit oder Routine für die Auswertung mehrerer Treffer haben, spart das spürbar Aufwand.

Der Effekt, den viele Unternehmen unterschätzen, betrifft die Richtigkeit: Ein Sprachmodell ohne Zugriff auf aktuelle oder unternehmensspezifische Dokumente muss bei entsprechenden Fragen entweder passen oder rät auf Basis seiner Trainingsdaten – mit entsprechendem Halluzinationsrisiko. Laut DSK kann die RAG-Methode dieses Risiko in gewissem Umfang reduzieren, weil die Antwort im Idealfall auf den bereitgestellten Referenzdokumenten statt auf unspezifischem Trainingswissen beruht. Vollständig ausschließen lässt sich das laut DSK aber nicht: Auch mit passenden Referenzdokumenten kann ein Sprachmodell weiterhin unrichtige Inhalte erzeugen oder – bei widersprüchlichen Angaben – die eigenen Trainingsdaten den bereitgestellten Quellen vorziehen.

Und RAG hat laut DSK systembedingte Grenzen bei der Suche selbst: Die Anreicherung der Anfrage funktioniert nur innerhalb dessen, was das Embedding-Modell als semantisch benachbart erkennt. Komplexe Gedankenketten, die sich über mehrere, semantisch nicht direkt ähnliche Textstellen erstrecken, werden dadurch unter Umständen unvollständig gefunden – ein strukturelles Problem, kein reiner Konfigurationsfehler.

Wie unterscheiden sich Transparenz und Fehler?

Das ist der Kernunterschied, der in vielen Entscheidungsvorlagen fehlt. Bei Enterprise Search ist die Fehlerquelle eng begrenzt: Ein System kann eine relevante Quelle übersehen oder falsch gewichten, aber es zeigt keinen erfundenen Inhalt – die Nutzenden sehen den Originaltext und beurteilen ihn selbst.

Bei RAG kommen zwei zusätzliche Fehler- und Transparenzebenen hinzu:

Erstens Halluzination trotz korrekter Quellen. Laut BSI stellen Halluzinationen bei Sprachmodellen ein zentrales Risiko dar, gerade weil generierte Ausgaben „zumeist glaubhaft erscheinen” – auch wenn sie erfundene Inhalte enthalten, etwa vermeintliche Zitate oder Referenzen, die es so nicht gibt. Ein RAG-System reduziert dieses Risiko, weil es echte Textstellen mitliefert, beseitigt es aber nicht.

Zweitens fehlende Erklärbarkeit der Formulierung. Die DSK-Orientierungshilfe zu RAG-Systemen hält fest, dass Transparenz in einem RAG-System im Kern darauf beschränkt bleibt, nachzuvollziehen, welche Textstellen dem Sprachmodell als Kontext übergeben wurden. Wie das Modell aus diesen Textstellen genau die finale Formulierung ableitet, sei dagegen „sehr schwer” nachzuvollziehen und damit intransparent. Das BSI beschreibt dieselbe Eigenschaft allgemeiner als fehlende Reproduzierbarkeit und Erklärbarkeit generativer Modelle (Blackbox-Charakter): Identische Eingaben können unterschiedliche Ausgaben erzeugen, und die interne Entscheidungslogik ist nicht einsehbar.

Hinzu kommt ein drittes, eher menschliches Risiko, das laut BSI unabhängig vom konkreten Anwendungsfall auftritt: Automation Bias. Weil generierte Antworten sprachlich glatt und selbstsicher wirken, neigen Nutzende dazu, sie ungeprüft zu übernehmen – ein Risiko, das bei einer Trefferliste mit sichtbaren Originalquellen strukturell geringer ausfällt, weil dort immer noch ein Lese- und Bewertungsschritt dazwischen liegt.

Praktisch heißt das: Enterprise Search verlagert die Verantwortung für die Interpretation vollständig zu den Nutzenden, mit dem Vorteil maximaler Nachvollziehbarkeit. RAG nimmt einen Teil dieser Arbeit ab, verlangt dafür aber Kontrollmechanismen gegen Halluzination und Automation Bias, die bei reiner Suche nicht nötig sind.

Welche Nutzeraufgabe entscheidet?

Die Technologiefrage folgt der Aufgabenfrage. Drei Leitfragen helfen bei der Einordnung:

Muss die Person selbst die Quelle prüfen und verantworten? Bei rechtlich bindenden, vertraglichen oder sicherheitsrelevanten Inhalten – etwa der genauen Formulierung einer Klausel – reicht eine Zusammenfassung nicht; hier braucht es den Originaltext. Enterprise Search ist dann nicht nur ausreichend, sondern das richtigere Werkzeug, weil es den Interpretationsschritt bewusst bei der Person belässt.

Ist die Frage komplex und quellenübergreifend, aber der Fehler tolerierbar oder leicht überprüfbar? Wenn eine falsche oder unvollständige Antwort schnell auffällt und ohne größeren Schaden korrigiert werden kann – etwa bei einer internen Recherchehilfe, die anschließend noch von einer fachkundigen Person gegengelesen wird – ist RAG oft die effizientere Wahl.

Wie oft wird dieselbe Art Frage gestellt? Bei seltenen, sehr heterogenen Anfragen lohnt sich der Aufwand für ein sauber eingerichtetes RAG-System oft nicht; eine gute Suche reicht. Bei häufig wiederkehrenden, ähnlich strukturierten Fragen – etwa im First-Level-Support – zahlt sich die Investition in eine Antwortschicht eher aus.

Die folgende Matrix fasst die Entscheidung zusammen und ist als eigene Orientierungshilfe gedacht, nicht als Ersatz für eine Einzelfallprüfung:

Kriterium	Enterprise Search passt besser	RAG passt besser
Art der Frage	Einzelne, klar formulierbare Fakten oder Dokumente finden	Zusammengesetzte Fragen über mehrere Quellen hinweg
Fehlerfolgen	Hoch: rechtliche, vertragliche oder sicherheitskritische Inhalte	Moderat: Fehler fallen auf oder werden gegengeprüft
Prüfaufwand pro Antwort	Vertretbar, da Nutzende ohnehin recherchieren	Soll bewusst reduziert werden
Nachvollziehbarkeit	Muss lückenlos sein (Originaltext sichtbar)	Quellenangabe reicht, exakte Formulierung nicht kritisch
Frageaufkommen	Selten, heterogen	Häufig, ähnlich strukturiert
Datenlage	Auch bei unsauber strukturierten Dokumenten nutzbar	Profitiert stark von guter Chunk- und Metadatenqualität
Personenbezogene Daten in Quellen	Zugriffssteuerung wie gewohnt über Rechte-/Rollenkonzept	Zusätzlich: Zweckbindung und Verkettungsrisiko zwischen Vektordatenbank und LLM prüfen

Eigene Entscheidungsmatrix Philogic Labs, abgeleitet aus Beratungspraxis und den zitierten Orientierungshilfen der Datenschutzkonferenz und des BSI.

Wann kombiniert man beides?

In der Praxis ist die Entscheidung selten ein Entweder-oder. Ein RAG-System braucht ohnehin eine funktionierende Suchkomponente im Hintergrund – Retriever und Embedding-Modell sind technisch kaum von Enterprise Search zu unterscheiden. Der naheliegende Schritt ist deshalb, beide Ausgaben parallel anzuzeigen: die generierte, zusammenfassende Antwort oben, darunter die Trefferliste mit den tatsächlich verwendeten Originalstellen und Fundorten.

Diese Kombination adressiert direkt die Transparenzlücke, die DSK und BSI beschreiben: Nutzende erhalten den Effizienzgewinn der generierten Antwort, können aber bei Bedarf – oder routinemäßig bei kritischeren Fragen – die zugrunde liegende Quelle prüfen, ohne das System wechseln zu müssen. In meiner Arbeit ist das mittlerweile die Standardempfehlung für produktive interne Wissenssysteme, nicht die Ausnahme: reine Trefferliste für Fälle mit hohem Prüfbedarf, Antwort-plus-Quellen als Standardansicht für alles andere.

Umsetzung: so gehst du vor

Unabhängig davon, ob am Ende Enterprise Search, RAG oder die Kombination steht, ist der Ausgangspunkt derselbe: die Datenbasis. Ohne zugängliche, halbwegs aktuelle und strukturierte Dokumente liefert weder die eine noch die andere Technologie gute Ergebnisse – das gilt für RAG laut DSK explizit, weil unvollständige oder veraltete Referenzdokumente direkt zu unrichtigen Ausgaben führen.

Ein sinnvoller Ablauf für ein KMU sieht so aus:

1. Frageninventar erstellen. Sammle über zwei bis drei Wochen typische Fragen aus dem Zielbereich (z. B. Support, Vertrieb, interne IT) – am besten aus echten Tickets, E-Mails oder Chatverläufen, nicht aus dem Bauch heraus.
2. Fragen nach den drei Leitfragen oben klassifizieren. Wie viele davon sind faktenbasiert und quellenkritisch versus zusammengesetzt und fehlertolerant? Das Verhältnis entscheidet, wohin die erste Investition geht.
3. Datenbasis prüfen und bereinigen. Welche Dokumente sind digital, aktuell und zugänglich? Laut DSK sollten Dokumente vor der technischen Aufbereitung von störenden Elementen wie Kopf-/Fußzeilen bereinigt und – wo nicht erforderlich – von personenbezogenen Daten befreit werden.
4. Klein starten, mit einem klar begrenzten Dokumentenbestand und einer Nutzergruppe. Ein Pilot mit einem einzelnen, gut gepflegten Wissensbereich zeigt schneller, ob Suche allein reicht oder eine Antwortschicht den erwarteten Unterschied macht, als ein unternehmensweiter Rollout von Anfang an.
5. Quellenanzeige von Beginn an mitplanen, wenn RAG zum Einsatz kommt – nicht als nachträgliches Feature. Das ist laut DSK der wesentliche Hebel, um die Transparenzlücke zumindest teilweise zu schließen.
6. Rollen klären, gerade bei personenbezogenen Daten in den Quellen. Wer darf welche Dokumente in den Index oder die Vektordatenbank einspeisen, und wer prüft die Zugriffsrechte? Grundkompetenz im Team – etwa über eine Schulung zu RAG und Sprachmodellen – reduziert Fehlbedienung und überzogene Erwartungen an beiden Seiten deutlich.

Zur Zeit- und Kosteneinordnung nur so viel, ohne erfundene Zahlen: Der Aufwand hängt fast vollständig von der Datenlage ab, nicht von der gewählten Technologie. Ein sauber strukturierter, bereits digitaler Dokumentenbestand lässt sich in Tagen bis wenigen Wochen an eine Such- oder RAG-Lösung anbinden; ein verstreuter, unstrukturierter Bestand erfordert zuerst Aufräumarbeit, die den größten Teil des Aufwands ausmacht – unabhängig davon, ob am Ende gesucht oder generiert wird.

Risiken & Grenzen

• Datenschutz ist bei RAG kein Nebenschauplatz. Sobald personenbezogene Daten in Referenzdokumenten stehen, gelten laut DSK die üblichen DSGVO-Grundsätze für die Vektordatenbank ebenso wie für das Sprachmodell – inklusive der Frage, ob die Übergabe von Daten aus der Vektordatenbank an das LLM zu einer unzulässigen Verkettung mit im Modell enthaltenen Informationen führt. Das ist Stand Juli 2026 ein aktiv diskutiertes, nicht abschließend geklärtes Thema und keine Rechtsberatung – bei sensiblen Datenkategorien gehört die konkrete Prüfung zu Datenschutzbeauftragten oder Rechtsberatung.
• Halluzination lässt sich reduzieren, nicht auf null bringen. Wer RAG einführt, weil „dann nichts mehr erfunden wird”, überschätzt die Technologie. Ein Prüfschritt bei kritischen Antworten bleibt sinnvoll.
• Automation Bias trifft gerade gute Systeme. Je überzeugender die generierten Antworten klingen, desto eher werden sie laut BSI ungeprüft übernommen. Das spricht dafür, Quellenangaben sichtbar zu halten statt sie zu verstecken, weil sie „die Antwort verlangsamen”.
• Reine Suche löst kein Strukturproblem. Wenn die zugrunde liegenden Dokumente widersprüchlich, veraltet oder unauffindbar sind, hilft weder eine bessere Suche noch RAG dauerhaft – dann ist Dokumentenpflege die eigentliche Aufgabe.
• Model Collapse und Trainingsdatenqualität sind ein längerfristiges, aber reales Risiko für generative Komponenten allgemein, sobald zunehmend KI-generierte Inhalte selbst wieder als Trainings- oder gar Referenzmaterial verwendet werden – ein Grund mehr, Referenzdokumente aktiv zu kuratieren statt sie automatisch anwachsen zu lassen.

Checkliste: RAG oder Enterprise Search wählen

1. Wir haben ein Frageninventar aus echten Anfragen erstellt, nicht aus Annahmen.
2. Wir wissen, wie viele dieser Fragen faktenbasiert-quellenkritisch versus zusammengesetzt-fehlertolerant sind.
3. Wir haben geprüft, ob unsere Dokumente digital, aktuell und zugänglich sind – unabhängig von der Technologiewahl.
4. Bei rechtlich, vertraglich oder sicherheitsrelevant heiklen Fragen setzen wir auf Enterprise Search mit sichtbarem Original, nicht auf generierte Zusammenfassungen.
5. Falls RAG zum Einsatz kommt: Quellenangaben sind von Beginn an Teil der Antwortoberfläche, nicht nachträglich geplant.
6. Wir haben eine Rolle benannt, die Zugriffsrechte auf Referenzdokumente und Vektordatenbank pflegt und prüft.
7. Bei personenbezogenen Daten in den Quellen ist die datenschutzrechtliche Bewertung – Zweckbindung, Rechtsgrundlage, Verkettungsrisiko – vor dem produktiven Start geklärt, nicht danach.
8. Die Nutzenden wissen, dass generierte Antworten Halluzinationen enthalten können, und haben bei kritischen Fragen einen Prüfschritt.

Wenn du unsicher bist, welches der beiden Werkzeuge – oder welche Kombination – zu eurem Frageninventar passt: Eine kurze Einschätzung im Erstgespräch oder der direkte Kontakt klärt das anhand eurer tatsächlichen Anwendungsfälle, nicht anhand einer generischen Empfehlung.