Warum normales RAG nicht ausreicht, um mit den eigenen Unternehmensdaten zu chatten

Warum RAG zum Standard wurde — und was dahintersteckt

Fast jedes Tool, das damit wirbt, „mit den eigenen Dokumenten zu chatten“, setzt im Kern auf dieselbe Technik: Retrieval-Augmented Generation, kurz RAG. Dokumente werden in kleine Textabschnitte zerlegt (Chunks), jeder Abschnitt wird als Vektor gespeichert, und bei einer Frage werden die Abschnitte herausgesucht, die diesem Vektor am ähnlichsten sind. Diese Abschnitte bekommt die KI dann als Kontext mitgegeben, bevor sie antwortet.

Das ist gegenüber einer reinen Stichwortsuche ein echter Fortschritt: RAG findet auch Textstellen, die inhaltlich passen, ohne dass exakt dasselbe Wort vorkommt. Für Fließtext — Handbücher, Prozessbeschreibungen, Vertragsklauseln — funktioniert das erstaunlich gut. Das Problem ist nicht, dass RAG grundsätzlich falsch wäre. Das Problem ist, dass die meisten Tools genau diesen einen Ansatz auf jede Art von Dokument anwenden, egal wie unterschiedlich der Inhalt tatsächlich ist.

Problem 1: Ein Chunk ist keine Bedeutungseinheit

Ein Dokument wird beim Chunking meist stur nach Zeichen- oder Wortanzahl zerschnitten, nicht nach Sinnabschnitten. Das reißt Aufzählungen mitten durch, trennt eine Tabelle von ihrer Überschrift, oder zerlegt einen zusammenhängenden Absatz in zwei Hälften, die für sich genommen beide unvollständig sind. Die Vektorsuche findet dann zwar „etwas Ähnliches“ — aber eben nur den halben Gedanken, nicht den vollständigen Zusammenhang.

Für die Person, die eine Frage stellt, ist das unsichtbar: Die Antwort klingt fertig formuliert und selbstsicher, obwohl sie auf einem abgeschnittenen Ausschnitt beruht. Genau das macht diese Fehlerklasse so tückisch — sie fällt im Alltag nicht auf, bis jemand die Originalquelle danebenlegt.

Problem 2: Ähnlichkeit ist nicht dasselbe wie Richtigkeit

Vektorsuche beantwortet im Grunde die Frage „welcher Text klingt bedeutungsmäßig am ähnlichsten zur Frage?“ — nicht „welcher Text enthält die vollständige, korrekte Antwort?“. Bei einer allgemeinen Wissensfrage an ein Handbuch liegen beide Antworten meistens nah beieinander. Sobald es aber um eine exakte Filterbedingung, eine konkrete Zahl oder eine vollständige Liste geht (etwa in einer Tabelle oder Preisliste), klaffen beide Fragen deutlich auseinander — dazu gibt es einen eigenen Artikel, weil dieser Einzelfall so häufig vorkommt.

Das eigentliche Risiko dabei: Eine KI, die auf Basis einer nur ähnlichen statt einer tatsächlich passenden Textstelle antwortet, sagt das selten dazu. Sie formuliert genauso selbstsicher wie bei einer wirklich fundierten Antwort — der Unterschied zwischen „ich habe die Antwort gefunden“ und „ich habe geraten, weil etwas Ähnliches in der Nähe lag“ verschwindet für die Person am anderen Ende des Chats komplett.

Problem 3: Ein Chatbot, der nicht weiß, wer gerade fragt

Viele einfache RAG-Aufbauten kennen nur eine gemeinsame Wissensbasis für alle, die den Chat nutzen — unabhängig davon, wer die Frage stellt. Das wird spätestens dann zum echten Problem, wenn nicht jedes hochgeladene Dokument für jeden im Team gedacht ist: ein Gehaltsvertrag, eine Kalkulation mit Einkaufspreisen, eine Personalakte. Ist die Vertraulichkeit nur eine Einstellung in der Oberfläche, aber nicht fest in der eigentlichen Suche verankert, kann eine geschickt formulierte Frage im Chat trotzdem an vertrauliche Inhalte gelangen.

Vertraulichkeit gehört deshalb dorthin, wo die Suche tatsächlich stattfindet, nicht nur in eine Berechtigungsliste, die irgendwo in den Einstellungen liegt. Ein Ordner oder Dokument, das als vertraulich markiert ist, sollte für die Suche selbst schon nicht existieren, wenn die falsche Person fragt — nicht erst nachträglich aus der fertigen Antwort herausgefiltert werden.

Problem 4: Ein statischer Index lernt aus dem Alltag nichts dazu

Klassisches RAG baut den Suchindex einmal beim Hochladen auf und lässt ihn dann unverändert liegen. Fragen, die niemand beantworten kann, weil das passende Dokument schlicht fehlt, verschwinden meist spurlos — die Person bekommt eine ausweichende Antwort oder gar keine, und niemand im Unternehmen erfährt, dass genau hier eine Lücke in der Wissensbasis klafft.

Dabei ist jede unbeantwortete Frage eigentlich eine kostenlose, sehr konkrete Information: Sie zeigt exakt, welches Dokument als Nächstes ergänzt werden sollte. Ein System, das nur sucht statt auch mitzuprotokollieren, verschenkt diesen Hinweis systematisch — die Wissensbasis wird zwar größer, wenn neue Dateien hochgeladen werden, aber sie wird nicht klüger durch die Art, wie sie tatsächlich genutzt wird.

Worauf es bei der Anbieterwahl wirklich ankommt

Die naheliegende Frage an jeden Anbieter ist deshalb nicht „Nutzt ihr RAG?“ — das tun inzwischen fast alle —, sondern wie differenziert damit umgegangen wird. Ein robusterer Ansatz erkennt, dass nicht jedes Dokument gleich behandelt werden sollte, dass Vertraulichkeit technisch in der Suche selbst verankert sein muss statt nur in der Oberfläche, und dass eine gute Wissensbasis sich durch echte Nutzung verbessert, statt statisch zu bleiben.

• — Wird jedes Dokument gleich behandelt, oder unterscheidet das System zumindest grob zwischen Fließtext und strukturierten Daten wie Tabellen?
• — Ist eine „vertraulich“-Markierung nur eine Einstellung in der Oberfläche, oder wirkt sie bereits in der eigentlichen Suche, bevor überhaupt etwas an die KI weitergegeben wird?
• — Sagt das System ehrlich „das steht nicht in meinen Dokumenten“, wenn nichts Passendes gefunden wurde — oder formuliert es lieber eine plausibel klingende, aber ungedeckte Antwort?
• — Werden unbeantwortete Fragen irgendwo sichtbar gemacht, damit gezielt nachgebessert werden kann — oder verschwinden sie einfach im Nichts?