KI-Halluzinationen - woher sie kommen und wie man sie begrenzt
Eine Halluzination ist eine plausibel klingende, aber falsche Antwort. Sechs Techniken, die ihr Risiko tatsächlich senken, und eine, die nur so wirkt.

Eine KI-Halluzination — in NIST-Dokumenten Konfabulation genannt — ist ein überzeugend klingender Inhalt, der falsch ist oder keine Grundlage in den Quellen hat. Das Risiko betrifft die gesamte Klasse generativer Modelle, nicht nur einen Anbieter; NIST führt es auf den Mechanismus zurück, Antworten aus der Verteilung der Trainingsdaten zu erzeugen.
Es gibt keine einzelne Technik, die das Ausbleiben solcher Fehler garantiert. Die bessere Frage lautet: Wie lässt sich ihre Häufigkeit begrenzen, eine fehlende Grundlage erkennen und die Auswirkung eines Fehlers verringern?
Woher Halluzinationen kommen
Vier Mechanismen, jeder mit einer anderen Gegenmaßnahme:
- Das Modell besitzt die nötige Information nicht. Sie fragen nach Ihrem Verfahren, das das Modell nie gesehen hat. Es füllt die Lücke mit dem, was statistisch passend wirkt.
- Das Modell erhielt unvollständige oder widersprüchliche Informationen. Zwei Versionen eines Dokuments, eine davon veraltet. Das Modell wählt eine aus und sagt nicht, dass es zwei gab.
- Die Frage setzt etwas Falsches voraus. „Welcher Paragraph unseres Vertrags regelt Vertragsstrafen bei Verzögerung?“ — obwohl es keinen solchen Paragraphen gibt. Das Modell nennt ihn gern, weil die Frage seine Existenz nahelegt.
- Die Aufgabe erfordert eine Präzision, die das Modell nicht von Natur aus hat. Rechnen, exakte Beträge wiedergeben, aus dem Gedächtnis zitieren.
Passender Kontext hilft vor allem bei fehlender Information, löst aber widersprüchliche Quellen, suggestive Fragen oder Aufgaben mit deterministischer Präzision nicht allein. Diese Fälle erfordern zusätzlich Quellenkontrolle, ein gutes Anweisungsdesign und Sicherungen außerhalb des Modells.
Sechs Techniken, die tatsächlich funktionieren
1. Fundierung in eigenen Daten
Das Grundprinzip: Das Modell erhält vor der Antwort passende Quellenabschnitte. Das ist RAG. Es kann Fehler aus fehlendem Wissen begrenzen, garantiert aber keine Richtigkeit: Die Suche kann den falschen Abschnitt abrufen, und das Modell kann ihn falsch auslegen.
2. Pflicht zur Quellenangabe
Eine Antwort ohne Hinweis auf den Abschnitt, auf dem sie beruht, kann abgelehnt oder an einen Menschen weitergeleitet werden. Ein Zitat beweist noch nicht, dass die Schlussfolgerung korrekt ist, ermöglicht aber eine schnelle Prüfung und zeigt, wenn das System keine Grundlage hat.
3. Die ausdrückliche Erlaubnis, „ich weiß es nicht“ zu sagen
Ein Modell ist darauf optimiert, eine Antwort zu erzeugen. Deshalb muss man ihm eine sichere Alternative ausdrücklich geben: Wenn die bereitgestellten Abschnitte keine Grundlage enthalten, ist die richtige Ausgabe der Hinweis auf fehlende Daten plus der Weg, wo weitergesucht werden kann. Das ist eine kostengünstige Änderung an Anweisung und Ablauf, ihre Wirksamkeit muss aber an Fragen ohne Antwort geprüft werden.
4. Aufteilen: Das Modell versteht, der Code rechnet
Arithmetik, Vergleiche und feste Regeln sollten im Code ausgeführt werden; dem Modell bleiben die Interpretation der Frage und die Darstellung des Ergebnisses. Das begrenzt Rechenfehler, doch die vom Modell erzeugte Abfrage, Datentypen und die Darstellung des Resultats müssen weiterhin validiert werden.
5. Prüfung in einem zweiten Durchlauf
Ein separater Schritt prüft, ob die Antwort tatsächlich aus den bereitgestellten Abschnitten folgt. Das kann eine Regel, ein Vergleich mit strukturierten Daten oder ein zweiter Modellaufruf mit enger Aufgabe sein. Ein zweites Modell ist kein unabhängiger Beweis und kann denselben Fehler wiederholen; bei hohem Risiko braucht es deshalb einen Menschen oder eine deterministische Kontrolle. Bei mehrstufigen Aufgaben kann eine separate Prüferrolle sinnvoll sein, auch ihr Nutzen muss jedoch gemessen werden.
6. Ein Mensch am Ende, wenn viel auf dem Spiel steht
Der Modus „Das System bereitet vor, ein Mensch gibt frei“ ist kein Scheitern der Automatisierung. Er ist eine Designentscheidung darüber, wo die Grenze liegt. Bei Antworten an Kunden zu Vertragsthemen sollte das Kontrollniveau aus Risiko, Unternehmensrichtlinie und rechtlicher Bewertung folgen; das Modell allein darf nicht die endgültige Instanz sein.
Eine Technik, die nur wie eine Lösung aussieht
Die Prompt-Anweisung: „Erfinde nichts, antworte nur auf Grundlage von Fakten.“
Sie hilft ein wenig und sollte vorhanden sein, sie als Absicherung zu behandeln ist jedoch ein Fehler. Ein Prompt ist ein Hinweis, keine technische Begrenzung — das Modell kann ihn missachten, besonders bei suggestiven Fragen oder unvollständigem Kontext. Die Absicherung besteht darin, dass das System keine Antwort ohne Quelle akzeptiert, nicht darin, dass wir das Modell um Sorgfalt gebeten haben.
Wie man misst, ob es besser wird
Ohne Messung bleiben all diese Techniken eine Erzählung. Eine minimale Messversion:
- Ein repräsentativer Satz realer Fragen aus Ihrem Prozess mit erwarteter Antwort, darunter Fragen, auf die „ich weiß es nicht“ die richtige Antwort ist. Ein Pilot kann mit 30–50 Fällen beginnen, wenn wichtige Kategorien und Risiken enthalten sind, und den Satz anschließend um entdeckte Fehler erweitern.
- Nach jeder Änderung zählen wir drei Dinge: wie viele Antworten korrekt, wie viele falsch und wie oft das System fehlende Daten eingestanden hat.
- Die Kennzahl, die wir besonders aufmerksam betrachten: Wie oft antwortete das System sicher und falsch? Das ist ein besonders riskanter Fehler, weil er unbemerkt bleiben kann. Auch ein falsches „ich weiß es nicht“ hat Kosten — es erhöht die Zahl der Eskalationen und ungelösten Fälle — daher müssen beide Fehlertypen getrennt berichtet werden.
Wann das Halluzinationsrisiko die Idee ausschließt
- Wenn der Fehler irreversibel ist. Eine Überweisung, Personalentscheidung, Meldung an eine Behörde. Hier wollen wir Code und einen Menschen.
- Wenn niemand die Antwort beurteilen kann. Gibt es niemanden, der das Ergebnis verifizieren kann, merken Sie nicht, wann das System zu irren beginnt.
- Wenn die Quelldaten widersprüchlich sind und niemand sie ordnen will. Das System wird dann veraltete Informationen überzeugend präsentieren, was schlimmer ist als gar kein System.
Häufige Fragen
Halluziniert ein leistungsfähigeres Modell weniger?
Vielleicht, aber das Ergebnis hängt von Aufgabe, Sprache, Daten und Bewertungsmethode ab. Man sollte keine Verbesserung allein aus dem Modellnamen ableiten — Modelle müssen am selben Fragenkatalog verglichen werden; Fundierung und Kontrolle bleiben unabhängig vom Ergebnis erforderlich.
Lässt sich null Halluzination erreichen?
Das sollte man bei einem offenen generativen System nicht versprechen. Ein realistisches Projektziel sind gemessenes Risiko, das Erkennen unbegründeter Antworten und so begrenzte Berechtigungen, dass ein einzelner Fehler keine irreversible Handlung auslöst.
Wer sollte die Qualität nach der Einführung überwachen?
Der Prozesseigner auf Ihrer Seite plus die regelmäßige Ausführung des Evaluationskatalogs. Die Qualität eines KI-Systems kann sich ohne offensichtlichen Ausfall verschlechtern, etwa nach einer Änderung von Modell, Daten oder Nutzerverhalten.
In einem wissensbasierten System entwerfen wir eine Regel, die eine Antwort ohne ausreichende Grundlage stoppt oder eskaliert, und messen Qualität mit einem Fragenkatalog statt mit einem Eindruck. Sehen Sie sich Second Brain für Unternehmen an oder schreiben Sie uns, welche Fragen Ihr System beantworten soll.

Autor
Maciej Szukalski
Gründer von Condictor · Systemarchitekt · Forschung und Entwicklung
Seit 2014 entwickelt er digitale Produkte. Seine Schwerpunkte sind Architektur, Forschung und Anwendungen mit Automatisierungs- und Intelligenzschichten.
Erfahrung und Arbeitsweise kennenlernenEin Problem zu lösen?
Finden wir den richtigen ersten Schritt
Beschreiben Sie Ihre Situation in wenigen Sätzen. Wir melden uns mit Fragen oder einem konkreten Vorschlag für den nächsten Schritt.
