KI-Halluzinationen: Falsche Antworten erkennen und abfangen

Ein Supportbot darf keine Ausnahme von einer Richtlinie erfinden. Ein Berichtsassistent darf sich keine Gesamtsumme ausdenken. Ein Agent, also Software, die mithilfe eines Modells Aktionen auswählt und Tools aufruft, darf nicht raten, welcher Kundendatensatz geändert werden soll. Das praktische Ziel: Unbelegte Antworten und Aktionen dürfen die Anwendung nicht verlassen.

Geprüft am 17. Oktober 2026 anhand der verlinkten Hinweise der Modellanbieter, API-Dokumentationen, Forschungsbeispiele und Gerichtsentscheidung. Die folgenden Beispiele sind Beobachtungen mit Quellenangabe. Der Validator und die Wochencheckliste sind Umsetzungsempfehlungen, keine Ergebnisse aus dem Produktivbetrieb.

Was sind KI-Halluzinationen und warum entstehen sie?

Von einer LLM-Halluzination spricht man, wenn ein Sprachmodell eine falsche oder unbelegte Aussage als Antwort ausgibt. LLM steht für Large Language Model, also ein großes Sprachmodell: Es wird darauf trainiert, Sprache anhand von Mustern in Texten zu erzeugen. Eine Aussage kann auch im Verhältnis zu den bereitgestellten Dokumenten unbelegt sein, selbst wenn sie in einem anderen Zusammenhang zutrifft.

Das Modell lässt sich mit einem versierten Autor vergleichen, der aus den Unterlagen auf seinem Schreibtisch ein Briefing vervollständigt. Einen fehlenden Absatz kann er überzeugend formulieren. Damit ist aber noch nicht belegt, dass dieser Absatz in die Unterlagen des Unternehmens gehört.

Plausiblen Text vorherzusagen heißt nicht, Fakten zu prüfen

OpenAI erklärt im Forschungsbeitrag über die Ursachen von Halluzinationen bei Sprachmodellen vom 5. September 2025: Beim Vortraining lernt das Modell, Text vorherzusagen, ohne dass jede Aussage als wahr oder falsch gekennzeichnet ist. Seltene, willkürliche Fakten lassen sich besonders schwer aus Mustern erschließen. Späteres Training verbessert das Verhalten. Flüssige Sprache wird dadurch jedoch nicht zur Wahrheitsgarantie.

Für die Entwicklung folgt daraus: Produktrichtlinien, Kontostatus und Lagerbestände gehören in maßgebliche Quellen, auf die die Anwendung zugreifen kann. Wer die aus dem Modellgedächtnis erzeugte Antwort zur Datenbank macht, schafft eine vermeidbare Fehlerquelle.

Fehlender oder veralteter Kontext hinterlässt Lücken

Möglicherweise hat das Modell die Information, die der Kunde braucht, nie erhalten. Ein hochgeladenes Dokument kann veraltet sein, die Suche eine falsche Produktausgabe finden oder die Kontoabfrage fehlschlagen. Anthropic nennt in seiner Erklärung zu fehlerhaften Antworten von Claude ausdrücklich fehlende aktuelle Informationen als Ursache für Verwechslungen.

Zwei Fälle müssen auseinandergehalten werden. Erfindet der Assistent eine Richtlinie, ist die Generierung fehlgeschlagen. Gibt er eine nicht mehr gültige Richtlinie korrekt wieder, liegt der Fehler in der Quellenverwaltung. In beiden Fällen erhalten Kunden eine falsche Antwort. Ein geänderter Prompt repariert aber weder ein veraltetes Dokument noch eine defekte Kontoabfrage.

Antwortdruck belohnt das falsche Verhalten

Nach OpenAI können Bewertungen, die ausschließlich die Trefferquote messen, das Raten stärker belohnen als das Eingestehen von Unsicherheit. Eigene Erfolgskennzahlen können denselben Fehler machen: etwa wenn jede fertige Antwort als Erfolg und jede Übergabe an einen Menschen als Misserfolg zählt.

Wer nach einem garantierten Liefertermin fragt, braucht eine belastbare Lieferprognose. Liegt diese vom Versanddienstleister noch nicht vor, ist eine gezielte Erklärung der fehlenden Information das hilfreiche Ergebnis. Dieses Verhalten sollte in Tests und im Betriebsdashboard positiv gewertet werden.

Beispiele für KI-Halluzinationen: Vier Fehler, die abgefangen werden müssen

Fehler lassen sich danach einteilen, was die Anwendung prüfen muss. Die Kategorien überschneiden sich, geben einem kleinen Team aber konkrete Ansatzpunkte für Prüfungen.

Erfundene Fakten: Die Beispiele mit den Dissertationstiteln stammen aus OpenAIs eigenem Forschungsbericht. Dass der Name bekannt war, half beim fehlenden Titel nicht weiter. Im Unternehmensalltag entspricht das einer erfundenen Produktfunktion, die ähnliche Produkte tatsächlich besitzen.

Falsche Zahlen: Die Geburtstagsbeispiele aus demselben Bericht zeigen, warum präzise wirkende Datumsangaben keine Belege sind. In der Anwendung müssen unbelegte Zahlen von Rechenfehlern getrennt werden. Mengen gehören aus Datensätzen ausgelesen, Summen mit gewöhnlichem Code berechnet. Das Modell sollte das Ergebnis erklären, das es erhält.

Fingierte Quellenangaben: Die Entscheidung vom 20. März 2024 in United States v. Cohen beschreibt drei nicht existierende Fälle, die Google Bard lieferte, Googles damaliger generativer Assistent. Eine der vermeintlichen Fundstellen lautete United States v. Figueroa-Florez. Ein plausibler Fallname und ein passendes Zitierformat verwiesen hier auf keine tatsächlich existierende Rechtsquelle.

Falsche Tool-Argumente: Die Autoren des Berkeley Function Calling Leaderboard zeigen einen Aufruf mit annual_interest_rate: 5 für einen angefragten Zinssatz von 5%. Daneben steht die korrekte Dezimaldarstellung 0.05. Beide Werte sind Zahlen. Eine reine Typprüfung kann sie nicht auseinanderhalten. Das ist ein semantischer Fehler im Argument. Nicht jeder falsche Tool-Aufruf ist ein erfundenes Faktum, er gehört aber in dieselbe Prüfung vor der Ausführung.

Wie lassen sich Halluzinationen abfangen, bevor Kunden sie sehen?

Die Generierung braucht Belege und Validierung. Zusätzlich muss feststehen, was das System tut, wenn eines von beidem fehlt. Das Entwicklungsteam verantwortet die Prüfungen, die Betriebsverantwortlichen die maßgebliche Datenquelle und den Eskalationsweg.

Antworten auf aktuelle, passende Quellen stützen

Retrieval-Augmented Generation, kurz RAG, durchsucht externe Materialien und stellt dem Modell relevante Passagen bereit. Der Autor bekommt also Unterlagen, mit denen er arbeiten kann. Anthropics Erklärung zu Contextual Retrieval zeigt, warum der Bedeutungszusammenhang einer gefundenen Passage erhalten bleiben muss: Ein isolierter Auszug kann verschweigen, um welches Unternehmen, welchen Zeitraum oder welchen Gegenstand es geht.

Für eine Supportfunktion wird zunächst die maßgebliche Richtliniensammlung festgelegt. Dazu gehören Metadaten zu Produkt, Region, Gültigkeitsbeginn und Zugriffsrechten. Nach diesen Feldern wird vor der Generierung gefiltert. Kündigungsregel und Ausnahmen müssen gemeinsam abgerufen werden. Fehlt einem Absatz seine Einschränkung, kann daraus eine falsche Zusage entstehen.

Aktuelle Kontoinformationen werden aus der Anwendungsdatenbank oder dem zuständigen Dienst gelesen. Eine Dokumentensuche ist kein guter Ersatz für die Frage, ob die Bestellung dieses Kunden bereits versandt wurde. Schlägt die Abfrage fehl, muss das System die Information als nicht verfügbar melden, statt sie stillschweigend durch Allgemeinwissen zu ersetzen.

Für den Einstieg genügt ein einfacher Abrufablauf. Agentic RAG, bei dem das Modell zusätzliche Abrufschritte auswählen kann, eignet sich für Fragen, die Folgesuchen über mehrere Quellen hinweg erfordern. Auch zusätzliche Suchen brauchen Abbruchregeln und dieselben Quellenprüfungen.

Die entscheidende Diagnosefrage lautet: Haben die richtigen Belege das Modell erreicht? Werden Quellen-IDs und Versionen gemeinsam mit der Antwort gespeichert, lässt sich später unterscheiden, ob der Abruf etwas übersehen oder das Modell eine unbelegte Aussage ergänzt hat.

„Ich weiß es nicht“ als Anwendungszustand vorsehen

Anthropic empfiehlt im Leitfaden zur Verringerung von Halluzinationen, Unsicherheit zuzulassen, die Arbeit auf Zitate zu stützen, Belege anzuführen und unbelegte Aussagen zu entfernen. Daraus sollte eine verbindliche Antwortspezifikation werden.

Das Modell erhält ausdrückliche Ergebniszustände wie answered, needs_clarification und insufficient_evidence. Ein Pflichtfeld darf keine erfundene Antwort erzwingen, wenn keine Antwort vorliegt. Die Benutzeroberfläche sollte aus jedem Zustand etwas Hilfreiches machen: eine gezielte Rückfrage, eine Erklärung zum fehlenden Datensatz oder eine Übergabe, der der abgerufene Kontext beigefügt wird.

Eine brauchbare Anweisung lautet: „Verwende ausschließlich die bereitgestellten Richtlinien und Kontodatensätze. Wenn sich die Antwort daraus nicht belegen lässt, benenne die fehlenden Informationen. Leite einen Anspruch nicht aus ähnlichen Fällen ab.“ Diese Anweisung muss mit fehlenden Belegen getestet werden, nicht nur mit einfachen Fragen.

Der Zustand „unbekannt“ ist etwas anderes als eine Ablehnung aus Sicherheitsgründen, ein Tool-Timeout oder eine Anfrage ohne ausreichende Berechtigung. Werden diese Zustände getrennt protokolliert, kann die jeweils zuständige Stelle den Fehler beheben.

Quellenangaben maschinell prüfbar machen

Eine Quellenangabe sollte auf Belege verweisen, die der Anwendung bereits bekannt sind. Der Abruf vergibt Quellen-IDs, die der Server in freigegebene URLs auflöst. Das Modell sollte weder ein Quellenverzeichnis noch eine Ziel-URL aus dem Gedächtnis erfinden müssen.

Drei Eigenschaften sind getrennt zu prüfen:

• Existenz: Die angeführte Quellen-ID gehört zu den autorisierten Unterlagen, die für diese Anfrage bereitgestellt wurden.
• Zitat: Der zitierte Text kommt in genau der Quellenversion vor, die für die Antwort verwendet wurde.
• Belegwirkung: Die Passage stützt diese Aussage für die Situation dieses Kunden.

Die ersten beiden Punkte lassen sich einfach im Code prüfen. Der dritte erfordert eine fachliche Regel, ein vertrauenswürdiges strukturiertes Feld oder eine gesonderte Prüfung, ob die Aussage belegt ist. Das Wort „berechtigt“ in einem Dokument beweist nicht, dass ein bestimmter Kunde berechtigt ist.

Anthropics Dokumentation zu Quellenzitaten beschreibt dokumentgebundene Zitate, mit denen sich Belege auffinden lassen. Ein Quellenverweis erleichtert die Prüfung einer Antwort. Er klärt aber nicht, ob die Quelle aktuell, maßgeblich oder richtig ausgelegt ist.

Strukturierte Ausgaben verwenden und anschließend die Werte prüfen

Strukturierte Ausgaben beschränken eine Antwort auf ein Schema, das zulässige Felder und Werttypen definiert. Dadurch lassen sich Anwendungsprüfungen leichter schreiben. OpenAI warnt im Leitfaden zu Structured Outputs ausdrücklich davor, dass Ausgaben weiterhin Fehler enthalten können. Unpassende Eingaben können Halluzinationen begünstigen, wenn die Antwortspezifikation keinen geeigneten Ausweichfall vorsieht.

Vor der Ausführung eines Tool-Aufrufs werden Operation, Pflichtargumente, Einheiten, zulässige Werte, die Existenz der Datensätze und die Berechtigung des Aufrufers geprüft. Mandant und authentifizierter Nutzer werden im Anwendungscode ermittelt. Wo es sinnvoll ist, darf das Modell unter autorisierten Datensätzen auswählen. Eine vom Modell gelieferte Kunden-ID ist jedoch niemals ein Zugriffsnachweis.

Auch nach einem erfolgreichen Tool-Aufruf muss die Kundenantwort den Tatsachen entsprechen. Eine Kündigung darf nicht als abgeschlossen gemeldet werden, wenn das Tool einen ausstehenden Status oder einen Fehler zurückgegeben hat. Maßgeblich für die abschließende Nachricht ist der zurückgegebene Status. Der Leitfaden zu Schutzmechanismen für KI-Agenten behandelt die dazugehörigen Handlungsgrenzen.

KI-Halluzinationen erkennen: Eine Prüfung zum Ausführen

Bei einem klar abgegrenzten Faktenfeld lässt sich der vorgeschlagene Wert mit einem freigegebenen Datensatz abgleichen. Die Anwendung formuliert die Antwort anschließend selbst. Für dieses Feld ist die Absicherung stärker als eine Prüfung, ob beliebiger Fließtext schlüssig klingt.

Das folgende Python-Beispiel verwendet einen Beispieldatensatz für eine Supportrichtlinie, keine echte Unternehmensrichtlinie. Es wird als verify_answer.py gespeichert und mit python3 verify_answer.py ausgeführt. Es benötigt nur die Standardbibliothek und führt keine API-Aufrufe aus.

# Records must be filtered for the caller's access and policy scope
# before reaching this function. These are illustrative fixtures.
records = {
    "support-policy": {
        "text": "The support channel for this workspace is email.",
        "current": True,
        "fields": {"support_channel": "email"},
    }
}


def validate(result, sources):
    keys = {"status", "field", "value", "source_id", "quote"}
    if not isinstance(result, dict) or set(result) != keys:
        return False
    if result["field"] != "support_channel":
        return False
    if result["status"] == "unknown":
        return all(result[k] is None
                   for k in ("value", "source_id", "quote"))
    if result["status"] != "answered":
        return False
    if not all(isinstance(result[k], str)
               for k in ("value", "source_id", "quote")):
        return False
    source = sources.get(result["source_id"])
    if source is None or source["current"] is not True:
        return False
    quote = result["quote"].strip()
    return (
        bool(quote)
        and quote in source["text"]
        and result["value"]
        == source["fields"].get(result["field"])
    )


proposal = {
    "status": "answered",
    "field": "support_channel",
    "value": "chat",
    "source_id": "support-policy",
    "quote": "The support channel for this workspace is email.",
}

if not validate(proposal, records):
    print("Hold: evidence or value check failed.")
elif proposal["status"] == "unknown":
    print("I cannot confirm the support channel from these records.")
else:
    print(f"Your support channel is {proposal['value']}.")

Die vorgeschlagene Antwort chat fällt durch, obwohl ihr Zitat echt ist. Mit dem Wert email besteht sie diese eng begrenzte Prüfung. Das vertrauenswürdige Feld belegt die Antwort; der bloße Zitatabgleich reicht dafür nicht aus.

Die Grenze dieser Prüfung ist entscheidend: Der Validator kann weder die Wahrheit einer frei formulierten Erklärung feststellen noch prüfen, ob die für die Richtlinie verantwortliche Person den richtigen Fakt eingetragen hat oder ob der vorgeschaltete Zugriffsfilter funktioniert hat. Sein unknown-Zweig validiert eine zulässige Antwortform, nicht die Notwendigkeit, auf eine Antwort zu verzichten. Diese Fragen brauchen eigene Prüfungen und Evaluationen. Bei feststehenden Fakten mit weitreichenden Folgen kann eine mit vertrauenswürdigen Daten gefüllte Vorlage die Generierung vollständig überflüssig machen.

Evaluationen, die richtige Antworten und berechtigte Abbrüche belohnen

Eine Evaluation, kurz Eval, prüft die Anwendung wiederholbar gegen ein erwartetes Verhalten. Maßgeblich sind dabei Fehler, die Kunden betreffen. Die Evaluation sollte laufen, sobald sich Modell, Prompt, Suchindex, Tool-Schema oder Richtlinie ändern.

Die Ergebnisse werden getrennt erfasst: richtige belegte Antwort, unbelegte Antwort, berechtigter Antwortverzicht, unnötiger Antwortverzicht und unzulässige vorgeschlagene Aktion. Ein einziger Durchschnittswert verdeckt, ob eine Verbesserung auf besseren Belegen beruht oder lediglich darauf, dass mehr Fragen unbeantwortet bleiben.

Exakte Werte, die Zugehörigkeit zu einer Quellenmenge, Pflichtfelder, Berechtigungen und Tool-Ergebnisse werden mit gewöhnlichem Code geprüft. Für sprachabhängige Fragen kann ein bewertendes Modell eingesetzt werden, etwa dafür, ob eine Passage eine Paraphrase stützt. Von Menschen geprüfte Beispiele helfen, seine Entscheidungen zu kalibrieren. Ein LLM als Bewerter bleibt ein weiteres fehlbares Modell und ist keine unabhängige Faktenquelle.

Promptfoo ist ein Evaluationswerkzeug. Seine modellgestützten Prüfungen umfassen sowohl die sachliche Richtigkeit gegenüber einer Referenz als auch die Treue zum bereitgestellten Kontext. Diese Unterscheidung ist hilfreich: Eine Antwort kann einem veralteten Dokument entsprechen und für heute trotzdem falsch sein. Sobald feststeht, wann ein Test als bestanden gilt, hilft der Promptfoo-Leitfaden beim Aufbau der Testumgebung.

Anfrage, abgerufene Belege, vorgeschlagene Argumente, Ergebnis des ausgeführten Tools und abschließende Antwort gehören gemeinsam in das Ablaufprotokoll jedes Tests. Schlägt ein Fall fehl, zeigt dieses Protokoll, wo eingegriffen werden muss. Fehlende Quellenangaben und unzulässige Argumente müssen ausdrücklich als Fehler zählen, selbst wenn der formulierte Text vom bewertenden Modell gut benotet wird.

Welche Versprechen gehen zu weit?

RAG macht nicht jede Antwort wahr. Eine hilfreiche Passage kann gefunden und falsch gelesen werden; eine veraltete Passage lässt sich fehlerfrei zitieren. Abruf und Generierung müssen getrennt getestet werden. Für die Quellensammlung braucht es eine verantwortliche Person.

Ein größeres Kontextfenster ersetzt keine Quellenauswahl. Anthropic warnt in seinen Hinweisen zum Context Engineering, dass mit wachsendem Kontext die Fähigkeit, Informationen wiederzufinden, und die Präzision nachlassen können. In den Kontext gehören die relevante Regel, ihre Ausnahmen und die erforderlichen Kontobelege. Sämtliche Dokumente in den Prompt zu kippen, ist keine Strategie für aktuelle Informationen.

Das Urteil „sieht richtig aus“ eines zweiten Modells ist allein noch keine Verifikation. Prüfende Instanzen brauchen die tatsächlichen Belege und ein klares Kriterium. Ohne unabhängige Belege kann Übereinstimmung dieselbe unbelegte Annahme fortschreiben.

Gültiges JSON ist kein Korrektheitszertifikat. Das Schema kann eine Quellen-ID und ein numerisches Argument verlangen. Die Anwendung muss weiterhin sicherstellen, dass die Quelle existiert und die Zahl die richtige Bedeutung hat.

Entscheidend sind die Grenzen der eigenen Anwendung: Welche Fragen können die Quellen nicht beantworten? Welche Felder können die Prüfungen nicht verifizieren? Welche Aktionen lassen sich nicht sicher rückgängig machen? Es gibt keine allgemeingültige Halluzinationsquote, die verrät, ob ein konkreter Workflow einsatzbereit ist.

Eine Wochencheckliste für kleine Teams

Handlungsbedarf besteht jetzt, wenn eine Funktion Kunden faktische Zusagen macht oder Geschäftsdaten verändert. Erstellt sie lediglich Entwürfe, die eine verantwortliche Person ohnehin anhand von Quellen prüft, sollte das Team zunächst den Evaluationsdatensatz aufbauen und diese Prüfung verbessern, bevor es eine aufwendige automatisierte Architektur ergänzt. Eine deterministische Abfrage, die bereits maßgebliche Felder zurückgibt, braucht möglicherweise überhaupt kein Modell.

Dies ist ein Vorschlag für den Einstieg, kein Beleg dafür, dass eine Woche Arbeit Zuverlässigkeit im Produktivbetrieb herstellt.

Der erste Schritt am Montag: eine kürzlich ausgegebene falsche Antwort nehmen und ihr vollständiges Ablaufprotokoll sichern. Dann feststellen, ob Belege fehlten, veraltet waren, falsch gelesen oder umgangen wurden. Die kleinste Prüfung ergänzen, die genau diesen Fehler abfängt, und den Vorfall dauerhaft in die Regressionstests aufnehmen.

Häufige Fragen zu LLM-Halluzinationen

Für praktische Anleitungen zum Aufbau zuverlässiger KI-Workflows den Newsletter abonnieren.