RAG oder Enterprise Search: Antworten generieren oder Informationen finden?

Das Wichtigste in Kürze:

• Enterprise Search findet Originalstellen in deinen Dokumenten und zeigt sie samt Fundort an.
• RAG setzt ein Sprachmodell obendrauf und formuliert aus den Treffern eine direkte Antwort.
• Beide nutzen fast dieselbe Suchtechnik; der Unterschied liegt im letzten Schritt: zeigen oder generieren.
• Die Wahl hängt von der Aufgabe ab, nicht von der Technologie.

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 zwei Bausteine, die häufig durcheinandergeworfen werden. Der erste ist eine Suchfunktion, die Informationen findet. Der zweite ist ein Sprachmodell, das aus den Funden einen Antworttext formuliert. Beides zusammen heißt Retrieval-Augmented Generation (RAG).

Nur der erste Teil, ohne den generierenden Schritt, ist seit Jahrzehnten als Enterprise Search bekannt. Dieser Artikel ordnet beide Ansätze im Cluster RAG, Wissensdatenbanken und Daten ein. Du erfährst, was klassische Suche leistet, was RAG ergänzt, wo sich Fehlerbilder und Transparenz unterscheiden und nach welcher Logik du am Ende für dein Unternehmen entscheidest. Nicht jede Wissensfrage braucht generierten Text. Manche profitieren aber enorm davon.

Das Problem: falsche Frage, falsches Werkzeug

In Beratungsgesprächen erlebe ich meist 2 Ausgangslagen. Die erste: Ein Unternehmen hat bereits eine gute Suche, etwa im Intranet, im Dokumentenmanagementsystem oder im Ticketsystem. Jetzt soll zusätzlich „KI“ draufgesetzt werden, ohne dass das konkrete Problem geklärt ist. Die zweite, häufigere: Es gibt gar keine funktionierende unternehmensweite Suche. Wissen liegt verstreut in Laufwerken, E-Mail-Postfächern und Köpfen. Die Erwartung: Ein RAG-Chatbot löst dieses Grundproblem quasi nebenbei mit.

Beide Ausgangslagen führen zu Enttäuschung, wenn man die Werkzeuge verwechselt. Der Grund ist simpel. Eine gute Suche braucht vor allem sauber indexierte, zugängliche und aktuelle Dokumente. Daran ändert ein Sprachmodell obenauf nichts. Umgekehrt ist ein RAG-System 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 beiden Werkzeugen ist deshalb zuerst eine Entscheidung über die Aufgabe, nicht über die Technologie. Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die internes Wissen zugänglich machen wollen. Typische Anlässe: Kundenservice, interne Dokumentation, Angebotserstellung oder die technische Wissensbasis.

Begriffe kurz geklärt

4 Begriffe reichen für die Abgrenzung.

• Information Retrieval ist die Kerntechnologie, die zu einer Anfrage die relevantesten Dokumente oder Textabschnitte findet, klassisch über Schlagworte oder semantisch über Embeddings.
• Enterprise Search wendet diese Suche auf interne Quellen wie Dateiablagen, Wikis, CRM und Ticketsysteme an; das Ergebnis ist eine Trefferliste mit Fundstellen, kein neu formulierter Text.
• RAG (Retrieval-Augmented Generation) kombiniert genau diese Suchfunktion mit einem generativen Sprachmodell.
• Halluzination bezeichnet laut BSI Ausgaben, die weder aus den Trainingsdaten noch aus den bereitgestellten Quelltexten stammen, aber trotzdem plausibel formuliert sind.

Ein RAG-System besteht laut der Orientierungshilfe der Datenschutzkonferenz (DSK) im Kern aus 4 Komponenten: Retriever, Embedding-Modell, Vektordatenbank und textgenerierendes Sprachmodell. Referenzdokumente werden dafür in Textabschnitte (Chunks) zerlegt und per Embedding-Modell in Vektoren überführt, in denen das System bei einer Anfrage nach semantisch nahen Chunks sucht. Diese ergänzen die Eingabe an das Sprachmodell, das daraus eine Antwort formuliert.

Wichtig für die Abgrenzung: RAG ändert laut DSK nichts daran, wie das 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 mit Dokumenttitel, Ausschnitt und Speicherort. Den relevanten Abschnitt lesen sie im Original.

Das ist ideal, wenn eine konkrete Information gefunden oder mehrere Quellen verglichen werden sollen. Es passt auch, wenn die Verantwortung für die korrekte Auslegung eines Textes bei der Person bleiben muss, 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 3 statt 1 landen, der Inhalt selbst bleibt aber echt. Enterprise Search „erfindet“ nichts hinzu. Das ist ihre Stärke.

Die Grenze liegt in der Aufbereitung. Eine Trefferliste beantwortet keine zusammengesetzte Frage wie diese: „Welche Kündigungsfristen gelten für Kunden in Kategorie B, und was ändert sich bei Verträgen vor 2023?“ 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 die Suche. Statt einer Trefferliste bekommen Nutzende einen zusammenfassenden Antworttext in ganzen Sätzen, im Idealfall mit dem Hinweis, aus welchen Dokumenten die Antwort stammt. Das spart spürbar Aufwand bei Fragen, die mehrere Quellen zusammenführen müssen, und hilft Nutzenden, denen Zeit oder Routine für die Auswertung mehrerer Treffer fehlt. Wie ein RAG-System im Detail arbeitet, liest du im Grundlagenartikel zu RAG.

Viele Unternehmen unterschätzen den Effekt auf die Richtigkeit. Ein Sprachmodell ohne Zugriff auf eure aktuellen, internen Dokumente muss bei solchen Fragen passen oder raten. Das Halluzinationsrisiko ist entsprechend hoch. Laut DSK kann die RAG-Methode dieses Risiko in gewissem Umfang reduzieren, weil die Antwort dann im Idealfall auf den bereitgestellten Referenzdokumenten statt auf unspezifischem Trainingswissen beruht.

Vollständig ausschließen lässt sich das laut DSK aber nicht, denn auch mit passenden Referenzdokumenten kann ein Sprachmodell weiterhin unrichtige Inhalte erzeugen. Bei widersprüchlichen Angaben zieht es mitunter die eigenen Trainingsdaten den bereitgestellten Quellen vor.

Dazu kommen 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 über mehrere, semantisch nicht direkt ähnliche Textstellen werden unter Umständen unvollständig gefunden. Das ist ein strukturelles Problem, kein reiner Konfigurationsfehler.

Wie unterscheiden sich die Fehlerbilder?

Hier liegt 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. Es zeigt aber keinen erfundenen Inhalt. Die Nutzenden sehen den Originaltext und beurteilen ihn selbst. Bei RAG kommen 2 zusätzliche Fehler- und Transparenzebenen hinzu.

Erstens: Halluzination trotz korrekter Quellen. Laut BSI sind Halluzinationen ein zentrales Risiko, weil generierte Ausgaben „zumeist glaubhaft erscheinen“. Das gilt 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. Laut DSK bleibt Transparenz in einem RAG-System im Kern darauf beschränkt, welche Textstellen dem Sprachmodell als Kontext übergeben wurden. Wie das Modell daraus 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: Identische Eingaben können unterschiedliche Ausgaben erzeugen, und die interne Entscheidungslogik ist nicht einsehbar. Mehr Einblick gibt es nicht.

Hinzu kommt ein drittes, eher menschliches Risiko: Automation Bias. Es tritt laut BSI unabhängig vom konkreten Anwendungsfall auf. Generierte Antworten wirken sprachlich glatt und selbstsicher. Nutzende neigen deshalb dazu, sie ungeprüft zu übernehmen. Bei einer Trefferliste mit sichtbaren Originalquellen fällt dieses Risiko strukturell geringer aus, 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 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. Das klingt banal, ist aber der Kern. 3 Leitfragen helfen bei der Einordnung.

Muss die Person selbst die Quelle prüfen und verantworten? Bei rechtlich bindenden, vertraglichen oder sicherheitsrelevanten Inhalten reicht eine Zusammenfassung nicht. Dazu zählt etwa die genaue Formulierung einer Klausel. Hier braucht es den Originaltext. Enterprise Search ist dann das richtigere Werkzeug, weil es den Interpretationsschritt bewusst bei der Person belässt.

Ist die Frage komplex, der Fehler aber tolerierbar oder leicht überprüfbar? Wenn eine falsche Antwort schnell auffällt und ohne größeren Schaden korrigiert werden kann, ist RAG oft die effizientere Wahl. Ein Beispiel ist eine interne Recherchehilfe, die eine fachkundige Person anschließend gegenliest.

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 dann. Bei häufig wiederkehrenden, ähnlich strukturierten Fragen zahlt sich die Antwortschicht eher aus, etwa im First-Level-Support.

Die folgende Übersicht fasst die Entscheidung zusammen. Sie ist als Orientierung gedacht, nicht als Ersatz für eine Einzelfallprüfung.

Enterprise Search passt besser, wenn:

• einzelne, klar formulierbare Fakten oder Dokumente gefunden werden sollen.
• Fehlerfolgen hoch sind, etwa bei rechtlichen, vertraglichen oder sicherheitskritischen Inhalten.
• die Nachvollziehbarkeit lückenlos sein muss und der Originaltext sichtbar bleiben soll.
• Fragen selten und heterogen sind.
• die Dokumente eher unsauber strukturiert sind.

RAG passt besser, wenn:

• Fragen zusammengesetzt sind und mehrere Quellen überspannen.
• Fehler auffallen oder ohnehin gegengeprüft werden.
• der Prüfaufwand pro Antwort bewusst sinken soll und eine Quellenangabe reicht.
• Fragen häufig kommen und ähnlich strukturiert sind.
• die Chunk- und Metadatenqualität gut ist oder gepflegt werden kann.

Ein Sonderfall sind personenbezogene Daten in den Quellen. Bei Enterprise Search steuert wie gewohnt das Rechte- und Rollenkonzept den Zugriff. Bei RAG sind zusätzlich Zweckbindung und das Verkettungsrisiko zwischen Vektordatenbank und LLM zu 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. Im Gegenteil. 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, beide Ausgaben parallel anzuzeigen: oben die generierte, zusammenfassende Antwort, 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. Bei Bedarf, oder routinemäßig bei kritischeren Fragen, prüfen sie die zugrunde liegende Quelle, ohne das System wechseln zu müssen.

In meiner Arbeit ist das mittlerweile die Standardempfehlung für produktive interne Wissenssysteme. Reine Trefferliste für Fälle mit hohem Prüfbedarf. Antwort plus Quellen als Standardansicht für alles andere.

Umsetzung: so gehst du vor

Der Ausgangspunkt ist immer die Datenbasis. Das gilt für Enterprise Search, RAG und die Kombination gleichermaßen. Ohne zugängliche, aktuelle und strukturierte Dokumente liefert keine der Technologien gute Ergebnisse; für RAG gilt das laut DSK explizit, weil unvollständige oder veraltete Referenzdokumente direkt zu unrichtigen Ausgaben führen. Ein sinnvoller Ablauf für ein KMU hat 6 Schritte.

1. Frageninventar erstellen. Sammle über 2 bis 3 Wochen typische Fragen aus dem Zielbereich, zum Beispiel Support, Vertrieb oder interne IT. Nutze echte Tickets, E-Mails oder Chatverläufe, nicht das Bauchgefühl.

2. Fragen klassifizieren. Ordne jede Frage den 3 Leitfragen von oben zu. Das Verhältnis von quellenkritisch zu fehlertolerant 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 Aufbereitung von störenden Elementen wie Kopf- und Fußzeilen bereinigt werden. Nicht erforderliche personenbezogene Daten gehören ebenfalls entfernt.

4. Klein starten. Wähle einen klar begrenzten Dokumentenbestand und eine Nutzergruppe. Ein Pilot mit einem gepflegten Wissensbereich zeigt schneller als ein Rollout, ob Suche allein reicht oder eine Antwortschicht den Unterschied macht.

5. Quellenanzeige von Beginn an mitplanen. Sie gehört zur Antwortoberfläche, sobald RAG zum Einsatz kommt, und ist kein nachträgliches Feature. Laut DSK ist sie der wesentliche Hebel, um die Transparenzlücke zumindest teilweise zu schließen.

6. Rollen klären. Wer darf Dokumente in Index oder Vektordatenbank einspeisen, und wer prüft die Zugriffsrechte? Grundkompetenz im Team, etwa über eine Schulung zu RAG und Sprachmodellen, reduziert Fehlbedienung und überzogene Erwartungen deutlich.

Zu Zeit und Kosten nur so viel, ohne erfundene Zahlen: Der Aufwand hängt fast vollständig von der Datenlage ab. Ein sauber strukturierter, bereits digitaler Bestand 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, egal ob am Ende gesucht oder generiert wird.

Risiken & Grenzen

5 Punkte solltest du realistisch einplanen.

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. Offen ist etwa, ob die Übergabe von Daten aus der Vektordatenbank an das LLM zu einer unzulässigen Verkettung mit Modellinhalten führt. Das ist Stand Juli 2026 aktiv diskutiert und nicht abschließend geklärt. Dieser Artikel ist 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. Sind die Dokumente widersprüchlich, veraltet oder unauffindbar, hilft weder eine bessere Suche noch RAG dauerhaft. Dann ist Dokumentenpflege die eigentliche Aufgabe.

Model Collapse ist ein längerfristiges, aber reales Risiko. Es betrifft generative Komponenten allgemein, sobald zunehmend KI-generierte Inhalte selbst wieder als Trainings- oder Referenzmaterial dienen; 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 Fragen faktenbasiert-quellenkritisch sind und wie viele zusammengesetzt-fehlertolerant.

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.

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. Die datenschutzrechtliche Bewertung von Zweckbindung, Rechtsgrundlage und Verkettungsrisiko ist vor dem produktiven Start geklärt, nicht danach.

8. Die Nutzenden kennen das Halluzinationsrisiko generierter Antworten und haben bei kritischen Fragen einen Prüfschritt.

Du bist unsicher, welches Werkzeug 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.