Chatbots auf Basis der RAG-Architektur sollten der Durchbruch beim Zugang zum Unternehmenswissen sein – schnelle Antworten auf Fragen von Mitarbeitern, Kunden oder Partnern, ohne sich durch Dutzende Ordner und Systeme zu wühlen. Und wie so oft hat die Realität diese Pläne ziemlich brutal korrigiert. Bei Web Systems entwerfen wir seit Jahren KI-Lösungen für Unternehmen und sehen immer dasselbe Muster: Eine vielversprechende Einführung wird zur Frustrationsquelle, weil der Chatbot Dinge erzählt, die in den Dokumenten keine Deckung haben. Halluzinationen in RAG-Systemen kommen nicht aus dem Nichts. Sie sind die Folge konkreter Architekturfehler, die sich aufspüren und beseitigen lassen, bevor das System zu den Nutzern gelangt. Wir gehen die sechs häufigsten Gründe durch, aus denen ein Chatbot auf Firmendokumenten das Blaue vom Himmel lügt – und zeigen, wie Sie damit umgehen.
Spis treści
Keine Kuratierung der Wissensbasis – Datenmüll rein, Antwortmüll raus
Der häufigste Fehler bei RAG-Einführungen? Der Ansatz “werfen wir alles rein und schauen, was passiert”. Unternehmen laden den kompletten Inhalt von Netzlaufwerken, SharePoint oder Intranet ohne jede Auswahl in die Wissensbasis. Das Ergebnis ist meist trostlos. Der Chatbot antwortet auf Basis einer drei Jahre alten Richtlinie oder zitiert eine Arbeitsversion eines Dokuments, die nie freigegeben wurde. Jede Dublette, jede veraltete Prozedur, jeder Scan ohne sauberes OCR ist eine fertige Quelle für Halluzinationen.
Richtig unangenehm wird es aber, wenn in der Wissensbasis inhaltlich widersprüchliche Dokumente liegen. Stellen Sie sich zwei Versionen der Urlaubsregelung vor – eine von 2021, eine aktuelle. Das Modell weiß nicht, welche gilt, also kann es eine beliebige wählen. Oder, schlimmer, Informationen aus beiden vermischen. Der Nutzer erhält eine Antwort, die glaubwürdig klingt, aber falsche Daten enthält. Und das war es. Das Vertrauen in das System bricht nach einem einzigen solchen Vorfall ein, und der Wiederaufbau dauert Monate.
“Sie brauchen die bestmögliche semantische Suche auf einer sorgfältig kuratierten Wissensbasis, damit die abgerufenen Informationen wirklich zur Anfrage passen. Sind die abgerufenen Daten irrelevant, mag die erzeugte Antwort im Kontext verankert sein, aber am Thema vorbeigehen oder schlicht falsch sein.”
Tipp: Führen Sie vor der Indexierung ein ordentliches Dokumenten-Audit durch. Werfen Sie Dubletten und Arbeitsversionen raus, aktualisieren Sie veraltete Materialien, führen Sie fragmentierte Dateien zu stimmigen Einheiten zusammen. Testen Sie die OCR-Qualität bei Scans – wenn der Text für Sie unlesbar ist, ist er auch für das Modell nutzlos. Die Wissensbasis muss wie ein Produkt behandelt werden, das regelmäßige Pflege braucht. Einmaliges Hochladen reicht nicht.
Falsch gewählte Chunking-Strategie für Dokumente
Die Aufteilung von Dokumenten in Fragmente wirkt wie ein technisches Detail, kann aber über den Erfolg der ganzen Einführung entscheiden. Zu große Chunks? Das Modell bekommt einen Überschuss an Informationen und verliert das Wesentliche im Rauschen der Nebendaten. Zu kleine? Sie reißen Sätze aus dem Kontext und nehmen ihnen den Sinn. Die richtige Granularität zu finden setzt voraus, dass Sie die Struktur der Dokumente verstehen und wissen, wie Menschen tatsächlich Fragen stellen.
Ein häufiges Problem ist es, beim Aufteilen die natürliche Struktur des Dokuments zu ignorieren. Ich habe das viele Male getestet – in einzelne Zeilen zerlegte Tabellen verlieren ihren Sinn, über Fragmente verteilte Schrittlisten einer Prozedur werden unbrauchbar, und vom Inhalt gelöste Überschriften führen das Modell in die Irre. Der Chunking-Algorithmus muss die semantischen Grenzen des Textes respektieren. Mechanisches Zählen von Tokens oder Zeichen reicht nicht.
Unterschiedliche Dokumenttypen verlangen unterschiedliche Aufteilungsansätze. Hier die am häufigsten eingesetzten Strategien und die Situationen, in denen sie sich am besten bewähren:
- Chunking nach Überschriften – ideal für technische Dokumentation und Anleitungen, wo Abschnitte eigenständige Informationseinheiten bilden
- Chunking mit Überlappung (Overlap) – bewährt sich bei erzählenden Texten, in denen der Kontext fließend zwischen Absätzen übergeht
- Semantisches Chunking – am besten für komplexe Rechtsdokumente und Verträge, in denen zusammengehörige Klauseln an verschiedenen Stellen stehen können
- Rekursives Chunking – die universelle Wahl, wenn die Basis eine Mischung aus Formaten und Inhaltstypen enthält
- Tabellarisches Chunking – unverzichtbar bei Finanzdokumenten, Berichten und Aufstellungen, in denen Tabellendaten ihre Struktur behalten müssen
In unseren Projekten testen wir mehrere Strategien an einer repräsentativen Stichprobe von Dokumenten, bevor wir die finale Entscheidung treffen. Die Kosten solcher Experimente? Minimal im Vergleich zum Risiko, ein System einzuführen, das wegen schlecht aufgeteilter Quellen regelmäßig halluziniert.
Schwacher Mechanismus für semantische Suche
Sie können eine perfekt vorbereitete Wissensbasis haben – wenn die Suche die richtigen Fragmente nicht findet, wozu dann das Ganze? Eine einfache Vektorsuche allein auf Basis von Similarity Search ist ein Ausgangspunkt. Keine Produktivlösung. Ohne Reranker, Metadatenfilter und hybride Mechanismen liefert das System zu oft Fragmente, die semantisch ähnlich wirken, inhaltlich aber danebenliegen.
Hybrid Search – die Kombination aus Vektorsuche und klassischer Keyword-Suche – verbessert die Trefferqualität deutlich. Ich habe das in vielen Projekten überprüft. Embeddings kommen mit Umschreibungen und Synonymen gut zurecht, versagen aber bei Fachterminologie, Dokumentnummern oder Produktnamen. Und genau hier kommt die Keyword-Suche ins Spiel, die diese Lücke hervorragend schließt. Diesen Ansatz auszulassen ist einer der häufigeren Fehler, die wir selbst in technologisch reifen Organisationen beobachten.
Die Konfiguration des Parameters top-k und der Schwellenwerte für den Similarity Score verlangt einiges an Umsicht. Ein zu hoher top-k-Wert überschwemmt das Modell mit irrelevanten Fragmenten, verwässert den Kontext und erhöht das Halluzinationsrisiko. Zu niedrig? Dann fehlen Informationen für eine vollständige Antwort, und das Modell füllt die Lücken mit eigenem Wissen. So funktioniert es nun einmal – es sagt nicht gern “ich weiß es nicht”. In der Praxis unterscheiden sich die optimalen Werte je nach Domäne und Fragetyp. Ein universeller Default bewährt sich im Produktivbetrieb selten.
Ein Reranker als zweite Bewertungsschicht der Ergebnisse kann die Retrieval-Qualität dramatisch verbessern. Die erste Suchstufe liefert Kandidaten schnell, aber ungenau. Der Reranker analysiert sie im Kontext der Anfrage tiefer und legt die richtige Reihenfolge fest. Diese zweistufige Architektur erhöht die Präzision, ohne die Geschwindigkeit zu opfern, was im Produktivbetrieb enorm wichtig ist.
Fehlende Evaluierung und Qualitätsmetriken für Antworten
Einen RAG-Chatbot ohne System zur Messung der Antwortqualität einzuführen ist wie Autofahren mit abgeklebten Instrumenten. Sie wissen nicht, wie schnell Sie fahren, wie viel Sprit Sie haben oder ob der Motor überhitzt. Bei Web Systems behandeln wir die Evaluierung als integralen Teil der Architektur, nicht als optionales Extra. Metriken wie Groundedness, Faithfulness und Relevance erlauben eine objektive Bewertung, ob das System korrekt arbeitet – statt sich auf den Eindruck einiger Personen zu verlassen, die “ein bisschen herumgeklickt haben und es sieht okay aus”.
Moderne Evaluierungsplattformen bieten ganze Metriksätze zur Bewertung generierter Texte. Coherence misst die logische Stimmigkeit der Antwort, Fluency bewertet die Natürlichkeit der Sprache, Groundedness prüft die Verankerung in den Quellen, und instruction_following kontrolliert die Übereinstimmung mit den Systemanweisungen. Jede dieser Metriken deckt einen anderen Aspekt möglicher Probleme auf und zeigt, was konkret zu verbessern ist. Ohne sie beruht die iterative Verbesserung des Systems auf Vermutungen. Nicht auf Daten.
Der RAG-Ops-Ansatz setzt einen fortlaufenden Zyklus aus Messung, Analyse und Optimierung voraus – analog zu DevOps, aber auf die Qualität der generierten Antworten fokussiert. Nach jeder Konfigurationsänderung, jeder Aktualisierung der Wissensbasis und jeder Prompt-Anpassung starten Sie eine Testreihe und vergleichen die Ergebnisse mit den vorherigen. Diese Disziplin erlaubt systematische Qualitätsverbesserung, statt blind zu ändern und die Daumen zu drücken.
Tipp: Bauen Sie einen Satz von mindestens 50 Testfragen mit erwarteten Antworten auf, der die typischen Nutzungsszenarien abdeckt. Lassen Sie ihn nach jeder Änderung am System automatisch laufen. Und ergänzen Sie Fangfragen, auf die die korrekte Antwort eine Verweigerung ist – das ist der beste Weg, Halluzinationen abzufangen, bevor sie die Endnutzer erreichen.
Unüberlegter Prompt und fehlende Grounding-Anweisungen für das Modell
Ein Sprachmodell ohne die klare Anweisung “antworte ausschließlich auf Basis des bereitgestellten Kontexts” verhält sich wie ein redseliger Partygast, der nicht gern zugibt, etwas nicht zu wissen. Wenn der abgerufene Kontext die Antwort auf die Frage nicht enthält, greift das Modell auf Allgemeinwissen zurück und erzeugt eine Antwort, die selbstbewusst klingt, aber nichts mit den Firmendokumenten zu tun hat. Der Nutzer kann eine solche Halluzination nicht von einer korrekten Antwort unterscheiden. Und genau deshalb ist sie so gefährlich.
Ein Verweigerungsmechanismus – das ist das Element, das in den meisten Einführungen fehlt. Das System sollte sagen können “ich habe in den verfügbaren Dokumenten nicht genug Informationen gefunden”, statt sich etwas auszudenken. Dieses Verhalten zu gestalten erfordert präzise Anweisungen im System-Prompt, die Sicherheitsschwellen und Eskalationsszenarien festlegen. Eine generische Vorlage “antworte auf Basis des Kontexts” genügt nicht. Der Prompt muss die Besonderheiten der Domäne, die Fachterminologie und typische Fallstricke berücksichtigen.
Der Unterschied zwischen einem auf ein konkretes Fachgebiet zugeschnittenen Prompt und einer generischen Vorlage ist mitunter gewaltig. In Projekten für Anwaltskanzleien ergänzen wir Anweisungen zur Präzision beim Zitieren von Vorschriften, in medizinischen Systemen Vorsichtsregeln bei der Interpretation von Befunden. Jede Domäne hat eigene Regeln, deren Bruch die Glaubwürdigkeit der gesamten Lösung untergräbt. Das Feintuning des Prompts auf die Besonderheiten des Unternehmens ist eine Investition, die sich schnell auszahlt – in Antworten, auf die sich Nutzer verlassen können.
Der System-Prompt ist auch Schiedsrichter in uneindeutigen Situationen. Wenn die abgerufenen Fragmente scheinbar widersprüchliche Informationen enthalten, sagt ein gut gestalteter Prompt dem Modell, wie solche Konflikte zu entscheiden sind. Hat das neuere Dokument Vorrang? Das Dokument mit der höheren Freigabestufe? Oder soll das System beide Versionen vorlegen und den Nutzer bitten, die Frage zu präzisieren? Das muss von vornherein entworfen werden.
Vernachlässigte Wartung des Systems nach der Einführung
Firmendokumente führen ein Eigenleben. Regelwerke ändern sich, Prozeduren entwickeln sich weiter, neue Produkte entstehen, alte verschwinden aus dem Angebot. Ein RAG-Chatbot, dessen Wissensbasis nicht regelmäßig aktualisiert wird, liefert schon wenige Wochen nach dem Start veraltete Informationen. Es geht nicht darum, ob er veraltet – sondern wann. Ohne automatisierte Update-Pipeline wird das System mit jedem Tag unglaubwürdiger.
Genauso wichtig ist das Monitoring der Nutzeranfragen. Denn ohne Analyse dessen, wonach die Leute tatsächlich fragen, wissen Sie nicht, wo der Chatbot patzt. Vielleicht scheitert er regelmäßig an Fragen zu einem bestimmten Produkt, weil dessen Dokumentation löchrig ist. Vielleicht formulieren Nutzer Fragen so, dass das System sie nicht versteht. Ein Feedback-Loop zwischen Nutzern und dem Team, das das RAG-System betreut, ist das Fundament langfristiger Qualität. Ohne ihn fliegen Sie blind.
Die Wartungskosten eines RAG-Systems werden in der Planungsphase oft unterschätzt. Neuindexierung der Dokumente nach Aktualisierungen, Neuberechnung der Embeddings beim Modellwechsel, Versionierung der Wissensbasis, Monitoring von Performance und Qualität – das alles erfordert Ressourcen und Prozesse. In unseren Umsetzungen entwerfen wir die Softwarearchitektur stets mit Blick auf den Betrieb nach dem Start. Denn ein System, das niemand wartet, verfällt schneller, als es entstanden ist.
Die Praxis zeigt eines – Unternehmen, die RAG als Projekt mit Enddatum statt als Produkt mit laufender Betreuung behandeln, verlieren die investierten Mittel binnen eines Quartals. Die Versionierung der Wissensbasis erlaubt es, Änderungen zurückzunehmen, wenn eine neue Dokumentencharge die Antwortqualität senkt, und automatische Alerts melden einen Rückgang der Metriken, bevor Nutzer zu klagen beginnen.
FAQ
Kann ein RAG-Chatbot Halluzinationen vollständig ausschließen?
Nein. Kein System auf Basis von Sprachmodellen garantiert hundertprozentige Genauigkeit. Man kann das Halluzinationsrisiko jedoch auf ein im Geschäftsumfeld akzeptables Niveau senken. Dazu braucht es einen mehrschichtigen Ansatz – sorgfältige Kuratierung der Wissensbasis, einen präzisen Prompt mit Grounding-Anweisungen, einen Verweigerungsmechanismus bei geringer Sicherheit und laufende Qualitätsevaluierung. Jede dieser Schichten senkt die Fehlerwahrscheinlichkeit, und ihre Kombination ergibt ein System, dem Nutzer im Alltag vertrauen können. Und noch etwas – der Chatbot sollte den Sicherheitsgrad seiner Antworten transparent kommunizieren. Kein Vortäuschen, alles zu wissen.
Wie viele Dokumente braucht es, damit RAG im Unternehmen Sinn ergibt?
Die Zahl der Dokumente ist weniger wichtig als ihre Qualität und die thematische Abdeckung. Wir haben wirksame Umsetzungen auf Basis von zwanzig sorgfältig aufbereiteten Dokumenten gesehen, die 80 % der Nutzerfragen beantworteten. Wirklich – zwanzig. Eine minimal tragfähige Wissensbasis sollte die häufigsten Anfrageszenarien der jeweiligen Organisation abdecken. Besser mit einem engen, gut abgedeckten Bereich beginnen und den Umfang schrittweise erweitern, als sofort Tausende Dateien ohne Qualitätskontrolle zu indexieren. Dieses iterative Vorgehen liefert schnell Nutzen und baut Vertrauen auf, statt gleich zu Beginn Enttäuschung zu riskieren.
Fazit
Jeder der sechs beschriebenen Fehler ist eine bewusste oder unbewusste Entwurfsentscheidung. Kein zufälliger Unfall. Fehlende Datenkuratierung, unüberlegtes Chunking, schwache Suche, fehlende Evaluierung, generischer Prompt und vernachlässigte Wartung – das sind Architekturelemente, die man von Anfang an richtig entwerfen oder in einem bestehenden System korrigieren kann. RAG ist keine Plug-and-play-Lösung, die man an die Dokumente anschließt und dann vergisst. Es braucht eine durchdachte Architektur, systematisches Testen und laufende operative Betreuung.
Bei Web Systems gehen wir Einführungen von RAG-Chatbots an wie jedes andere Ingenieurprojekt – mit Plan, Metriken und klar definierten Erfolgskriterien. Wenn Sie den Start eines Chatbots auf Ihren Firmendokumenten planen oder Ihr aktuelles System Antworten liefert, denen Nutzer nicht trauen, nehmen Sie Kontakt mit uns auf. Wir helfen Ihnen, eine gegen Halluzinationen robuste RAG-Architektur zu entwerfen, oder auditieren Ihre bestehende Lösung und zeigen konkrete Verbesserungsstellen auf.
