Warum RAG-Chatbots im KMU halluzinieren — und was wirklich hilft

Der Pitch klingt gut: "Wir laden Ihre Handbücher, SharePoint-Ordner und Confluence-Seiten in eine Vektordatenbank, ein LLM beantwortet damit Mitarbeiterfragen, fertig ist der interne KI-Assistent." Retrieval Augmented Generation, kurz RAG, ist seit 2023 der Standardweg, um ein Sprachmodell mit eigenem Wissen zu versorgen, ohne es nachtrainieren zu müssen.

In der Demo funktioniert das. In der Realität nicht. Wer RAG-Projekte in österreichischen KMU genauer ansieht — vom Maschinenbauer mit 80 Mitarbeitern bis zur Steuerberatungskanzlei — sieht ein wiederkehrendes Muster: Nach drei Wochen produktivem Betrieb melden sich die ersten Mitarbeiter, weil der Bot "Unsinn" antwortet. Nicht offensichtlichen Unsinn — das wäre einfach zu fixen — sondern plausibel klingende, falsche Antworten mit Quellenangabe. Das ist die gefährliche Sorte.

Dieser Artikel erklärt, woran das liegt. Nicht am LLM. Fast nie am LLM.

Was RAG eigentlich macht — und wo die Illusion entsteht

Kurz technisch: Bei einer Anfrage wird der Text des Users in einen Vektor übersetzt (Embedding), in einer Vektordatenbank werden die ähnlichsten Dokumentenstücke gesucht, und diese werden dem LLM als Kontext mitgegeben. Das LLM formuliert dann eine Antwort, idealerweise auf Basis dieser Kontextstücke.

Die typische Erwartung in Geschäftsführungsrunden lautet: "Wenn der Bot nur unsere Dokumente verwendet, kann er ja nicht halluzinieren." Das ist der zentrale Denkfehler. Ein LLM halluziniert nicht primär, weil es zu wenig weiß. Es halluziniert, weil es trainiert ist, immer eine flüssige, kohärente Antwort zu produzieren — auch wenn der mitgegebene Kontext lückenhaft, widersprüchlich oder schlicht das falsche Dokument ist.

Und genau das passiert in einer typischen KMU-Wissensdatenbank ständig.

Fehlerquelle 1: Chunking — der unterschätzte Schritt

Dokumente kommen nicht als ein einziger Vektor in die Datenbank. Sie werden in Stücke zerlegt, meist 500 bis 1.000 Tokens groß, oft mit Überlappung. Diese Stücke werden einzeln embedded und gespeichert.

Die Standard-Chunking-Strategie der meisten Frameworks (LangChain, LlamaIndex) zerschneidet Texte alle X Zeichen, wahlweise an Absatzgrenzen. Das funktioniert für Wikipedia-artige Texte. Für KMU-Dokumente ist es eine Katastrophe.

Typisches Beispiel: ein Anlagenbauer, dessen technische Handbücher als PDF-Exporte aus Word vorliegen, mit Tabellen, Stücklisten und Querverweisen. Der naive Chunker zerschneidet eine Sicherheitsanweisung mitten im Satz, weil das 1.000-Zeichen-Limit erreicht ist. In Chunk A steht dann: "Vor Wartungsarbeiten ist die Anlage spannungsfrei zu schalten und gegen" — und Chunk B beginnt mit: "Wiedereinschalten zu sichern." Beide Chunks werden separat embedded. Beide haben bei der Query "Wartung Sicherheit" einen schlechten Ähnlichkeitswert, weil die Sätze zerstückelt sind. Das LLM bekommt einen anderen, oberflächlich passenden Chunk und antwortet damit. Falsch, aber überzeugend.

Was hilft: Chunking entlang semantischer Grenzen, nicht Zeichengrenzen. Bei strukturierten Dokumenten heißt das, die Struktur (Überschriften, Listenpunkte, Tabellen) muss beim Import erhalten bleiben. Im Anlagenbauer-Setup bedeutet das eine Custom-Pipeline, die Word-Dokumente direkt verarbeitet (nicht über PDF-Umweg), Überschriftshierarchien erkennt und Tabellen separat als zusammenhängende Einheit speichert. Aufwand: zwei Wochen. Effekt: Die Trefferquote bei Sicherheitsfragen steigt typischerweise von ungefähr 60 auf über 90 Prozent.

Fehlerquelle 2: Embedding-Qualität für deutsche Fachsprache

Die meisten Embedding-Modelle sind primär auf englischen Daten trainiert. OpenAIs text-embedding-3-small und -large funktionieren auf Deutsch passabel, aber nicht hervorragend — und schon gar nicht auf österreichischer Fachsprache.

Ein typisches Muster, das man bei einer Versicherungsmaklerei findet, die RAG über Polizzenbedingungen aufsetzt: Mitarbeiter stellen Fragen wie "Was ist beim Selbstbehalt im Kasko inkludiert?". Das System zieht regelmäßig den falschen Tarif, weil "Selbstbehalt" und "Selbstbeteiligung" im Embedding-Raum nicht eng genug zusammenliegen — obwohl es synonym verwendet wird. Im Englischen wäre das "deductible" und das Modell hätte keine Probleme.

Was hilft: Bei deutschem Fachvokabular sollte man Embedding-Modelle vergleichen. In der Praxis lohnt es sich, mindestens drei zu testen: OpenAI, Cohere multilingual, und ein open-source Modell wie bge-m3 oder multilingual-e5-large. Im Versicherungs-Setup performt Cohere multilingual oft deutlich besser als OpenAI. Das ist kein Naturgesetz — es muss pro Anwendungsfall gemessen werden, mit einem konkreten Test-Set aus echten Mitarbeiterfragen.

Das zweite, was hilft: ein Synonym-Layer vor dem Retrieval. Eine kleine, gepflegte Liste fachlicher Synonyme ("Selbstbehalt" = "Selbstbeteiligung" = "SB") erweitert die Query vor dem Embedding entsprechend. Niedrigtechnisch, aber effektiv.

Fehlerquelle 3: Veraltete und widersprüchliche Dokumente

Die ehrlichste Fehlerquelle, weil sie kein technisches sondern ein organisatorisches Problem ist. In praktisch jedem KMU-Wissensspeicher liegen Dokumente, die einander widersprechen. Eine alte Reisekostenrichtlinie aus 2019, eine neue aus 2023, beide in SharePoint. Eine Preisliste, die seit zwei Jahren nicht aktualisiert wurde. Ein Onboarding-Dokument, das auf Tools verweist, die längst abgelöst sind.

Für einen Menschen ist das händelbar — er erkennt am Datum oder am Kontext, was aktuell ist. Für RAG ist es Gift. Beide Versionen werden embedded, beide können retrieved werden, das LLM mischt fröhlich. Ergebnis: "Sie können bis zu 80 Euro pro Übernachtung abrechnen" (alte Richtlinie) oder "110 Euro" (neue Richtlinie) — je nach Tagesform.

Was hilft: Vor dem RAG-Projekt eine ehrliche Inventur. Welche Dokumente sind aktuell, welche sind Archiv? Diese Trennung muss in den Metadaten landen, und das Retrieval muss Archiv-Dokumente standardmäßig ausschließen oder mit Warnung kennzeichnen. Das ist kein KI-Problem, das ist Datenhygiene. Aber es ist die Voraussetzung dafür, dass die KI funktioniert.

Beispielhaft: eine Steuerberatungskanzlei mit rund 4.200 Dokumenten. Realistisch sind die ersten drei Wochen ausschließlich Sichtung — kein einziges Embedding berechnet. Am Ende landen typischerweise rund 1.100 Dokumente im Index. Der Rest sind Duplikate, veraltete Stände oder mandantenspezifische Inhalte, die für allgemeines RAG nicht geeignet sind.

Fehlerquelle 4: Naives Top-K-Retrieval

Standardmäßig holt RAG die K ähnlichsten Chunks (oft K=4 oder K=5) aus der Vektordatenbank und gibt sie dem LLM. Klingt vernünftig. Hat aber zwei Probleme.

Erstens: Wenn die richtige Antwort in zehn Chunks verteilt ist (lange Erklärung in einem Handbuch), bekommt das LLM nur die Hälfte. Es ergänzt den Rest aus seinem Trainingswissen — und genau dort entstehen die plausibel klingenden Halluzinationen.

Zweitens: Wenn die Frage mehrdeutig ist, sind die Top-K-Chunks oft alle aus demselben Dokument oder demselben Themenbereich, der nur oberflächlich passt. Diversität fehlt.

Was in der Praxis funktioniert: Hybrid Retrieval — Vektorsuche kombiniert mit klassischer BM25-Volltextsuche. Vektoren fangen semantische Ähnlichkeit, BM25 fängt exakte Begriffsübereinstimmungen (Produktnummern, Eigennamen, Paragrafen). Beide Ergebnislisten werden mit einem Reranker (z.B. Cohere Rerank oder ein Cross-Encoder) zusammengeführt und neu sortiert.

Der Aufwand ist überschaubar — eine zusätzliche Indexschicht, eine API-Call mehr pro Query — der Effekt deutlich. Im Anlagenbauer-Setup hebt das die Antwortqualität auf Fragen mit Produktnummern (typisch: "Wie ist die Wartungsintervall für das Modell XR-2840?") von etwa 50 auf über 95 Prozent. Reine Vektorsuche scheitert an solchen Strings, weil Embeddings auf Bedeutung trainiert sind, nicht auf Zeichenfolgen.

Fehlerquelle 5: Kein "Ich weiß es nicht"

Der letzte und vielleicht wichtigste Punkt. Ein gewöhnlicher RAG-Prompt lautet sinngemäß: "Beantworte die Frage des Users auf Basis der folgenden Dokumente." Was passiert, wenn die Dokumente die Frage nicht beantworten? Das LLM beantwortet sie trotzdem. Mit dem, was es allgemein weiß, oder mit Halbwissen aus den schwach passenden Chunks.

Das ist der Standardfehler in den meisten RAG-Implementierungen, die in Audits auftauchen. Der Prompt erlaubt dem Modell nicht explizit, zu sagen: "Diese Frage kann ich auf Basis der vorhandenen Dokumente nicht beantworten."

Was hilft: Ein expliziter, scharfer Prompt. Etwa: "Beantworte die Frage ausschließlich auf Basis der folgenden Dokumente. Wenn die Dokumente die Frage nicht oder nicht eindeutig beantworten, antworte: 'Ich finde dazu in den verfügbaren Dokumenten keine ausreichende Information.' Erfinde nichts. Verwende kein Allgemeinwissen."

Das reduziert die Antwortrate — das System sagt häufiger "weiß ich nicht". Genau das ist gewollt. Eine Wissensdatenbank, die in 60 Prozent der Fälle korrekt antwortet und in 40 Prozent ehrlich passt, ist um Welten brauchbarer als eine, die zu 95 Prozent antwortet, aber bei 30 Prozent davon falsch liegt — ohne dass der User das erkennt.

Dazu kommt die Pflicht zur Quellenangabe. Jede Antwort muss nennen, aus welchem Dokument (idealerweise mit Seitenzahl oder Abschnitt) sie stammt. Das ermöglicht dem User, die Antwort zu verifizieren — und disziplinert das Modell, weil es nur zitieren kann, was tatsächlich da ist.

Was das alles kostet

Die Kurzversion: Ein RAG-System, das in der Demo funktioniert, ist in zwei Wochen gebaut. Ein RAG-System, das produktiv für Mitarbeiter eines KMU brauchbar ist, braucht zwei bis vier Monate. Der Hauptteil davon ist nicht Programmierung, sondern Datenarbeit — Inventur, Chunking-Strategie pro Dokumententyp, Test-Set bauen, Embedding-Modelle vergleichen, Hybrid Retrieval einrichten, Prompt iterieren, Feedback-Loop mit den Nutzern aufbauen.

Mein Rat an Geschäftsführer, die ein RAG-Projekt erwägen: Rechnen Sie damit, dass 70 Prozent des Budgets in Datenqualität und Evaluierung gehen, und 30 Prozent in das eigentliche KI-System. Wer das umkehrt — was die meisten Anbieter tun, weil sie nur das KI-System verkaufen wollen — bekommt einen Bot, der eindrucksvoll wirkt und in der Praxis nicht hält.

RAG ist kein magischer Schalter, der eine Wissensdatenbank in einen Assistenten verwandelt. Es ist eine Suche mit besserer Oberfläche. Wie gut die Suche ist, hängt davon ab, was Sie indexieren — und wie ehrlich Sie mit den Antworten umgehen, die das System nicht weiß.