Eine Halluzination ist eine Ausgabe, die plausibel klingt, aber nicht durch die verfügbaren Belege gestützt wird. Sie kann ein Zitat erfinden, zwei Personen vermischen, eine veraltete Richtlinie verwenden, eine Tabelle falsch lesen oder selbstbewusst eine Lücke füllen, die die Quelle nie beantwortet hat. Flüssige Sprache macht diese Fehler gefährlich, weil Darstellungsqualität mit Zuverlässigkeit verwechselt werden kann.
Das Verhalten ergibt sich aus der Funktionsweise generativer Modelle. Sie erzeugen wahrscheinliche Fortsetzungen auf Basis der gegebenen Anweisungen und des Kontexts; sie konsultieren kein internes Verzeichnis, das die Wahrheit jedes Satzes garantiert. Bessere Modelle können Fehlerraten senken, doch kein universell einsetzbares System macht Kontrollen überflüssig.
Das Risiko hängt von der Aufgabe ab. Eine unerwartete Metapher in einer Brainstorming-Sitzung kann nützlich sein. Eine erfundene Zahl in einem Finanzbericht ist es nicht. Definieren Sie, welche Behauptungen Belege erfordern, welche Unsicherheit akzeptabel ist und wer die Kosten eines Fehlers trägt, bevor Sie den Grad der Automatisierung festlegen.
Belegbindung ist die erste Verteidigungslinie. Stellen Sie aktuelle, relevante Quellen bereit und weisen Sie das Modell an, sie zu verwenden. Retrieval-Augmented Generation kann private oder sich ändernde Dokumente in die Anfrage einbringen. Auch Belegbindung muss jedoch evaluiert werden: Eine irrelevante oder veraltete Passage kann einen gut zitierten Fehler erzeugen.
Fordern Sie Nachvollziehbarkeit auf Ebene einzelner Behauptungen. Eine Quellenliste am Ende einer Antwort zeigt nicht, welche Quelle welche Aussage stützt. Verlangen Sie Zitate direkt bei Tatsachenbehauptungen, bewahren Sie Dokumentkennungen auf und machen Sie es einer prüfenden Person leicht, die referenzierte Passage zu öffnen. Behandeln Sie ein vom Modell erzeugtes Zitat nie als geprüft, bevor Ziel und Beleggrundlage kontrolliert wurden.
Erlauben Sie dem Modell, sich zu enthalten. Wenn die Belege die Frage nicht beantworten, kann die richtige Ausgabe „unzureichende Informationen“, die Bitte um ein fehlendes Dokument oder eine Liste offener Punkte sein. Eine Anwendung, die Abschlüsse um jeden Preis belohnt, fördert selbstsicheres Raten.
Die Validierung sollte zur Ausgabe passen. Strukturierte Daten lassen sich gegen ein Schema, einen Wertebereich oder ein bekanntes Vokabular prüfen. Berechnungen können neu ausgeführt werden. Namen und Kennungen können mit einer Datenbank abgeglichen werden. Zitate können im Quelltext gefunden werden. Code kann kompiliert und getestet werden. Solche deterministischen Kontrollen entdecken Fehler, die eine weitere freie Modellprüfung möglicherweise wiederholt.
Trennen Sie bei schwierigen Dokumenten Extraktion und Interpretation. Erfassen Sie zunächst die relevanten Werte und Passagen mit Koordinaten oder Zitaten. Bitten Sie das Modell erst danach um eine Erklärung. So entsteht ein Zwischenartefakt, das Menschen oder Tests prüfen können, und es sinkt die Gefahr, dass eine polierte Darstellung einen Lesefehler verdeckt.
Setzen Sie bei Entscheidungen mit hoher Wirkung auf unabhängige Prüfung. Die prüfende Person braucht die ursprünglichen Belege, nicht nur die Antwort. Menschliche Kontrolle ist am nützlichsten, wenn diese Person befugt ist, den Workflow zu stoppen, und genügend Zeit hat, riskante Behauptungen zu untersuchen; ein reines Abhak-Feld bietet wenig Schutz.
Überwachen Sie Fehler im Produktivbetrieb, statt sich nur auf Evaluierungen vor dem Start zu verlassen. Speichern Sie im Rahmen der Datenschutzvorgaben repräsentative Prompts, abgerufene Belege, Ausgaben, Korrekturen und Modellversionen. Gruppieren Sie Fehler nach Ursache: fehlende Quelle, falscher Abruf, unklarer Prompt, unbelegte Synthese, veraltete Daten oder Validierungsfehler. Jede Ursache verlangt eine andere Korrektur.
Kommunizieren Sie Unsicherheit ehrlich in der Oberfläche. Zeigen Sie Prüfzeitpunkte, Quellenabdeckung und ob die Antwort aus nutzerbereitgestellten Dokumenten oder allgemeinem Modellwissen erzeugt wurde. Vermeiden Sie Siegel, die eine Garantie suggerieren, die das System nicht geben kann.
Das praktische Ziel ist nicht zu versprechen, dass eine KI nie halluziniert. Es geht darum, unbelegte Behauptungen schwerer erzeugbar, leichter erkennbar, günstiger korrigierbar und weniger wahrscheinlich zu machen, dass sie unbemerkt in eine folgenreiche Entscheidung gelangen.
Wir verbinden Primärquellen, Produktdokumentation und reale Anwendungsszenarien, damit Sie besser einschätzen können, ob ein Tool zu Ihrem Workflow passt.