Eine Halluzination (KI) ist eine Ausgabe eines Sprachmodells, die flüssig und überzeugend klingt, aber sachlich falsch, erfunden oder nicht durch Eingabe und Quellen gedeckt ist. Beispiele sind erfundene Zitate, nicht existierende API-Funktionen, falsche Zahlen oder Tool-Aufrufe mit ausgedachten Argumenten. Halluzinationen folgen aus der Art, wie Modelle Text erzeugen, und lassen sich verringern, aber nicht ganz ausschließen.
Was ist eine KI-Halluzination?
Eine Halluzination (KI) liegt vor, wenn ein großes Sprachmodell Inhalte erzeugt, die sich gut lesen, aber nicht stimmen oder nicht durch die bereitgestellten Informationen belegt sind. Das Modell lügt nicht im menschlichen Sinn. Es erzeugt die nächsten Tokens auf Basis gelernter Wahrscheinlichkeiten, und eine statistisch plausible Fortsetzung ist nicht automatisch eine korrekte. Fehlt dem Modell das nötige Wissen, liefert es häufig trotzdem eine Antwort, statt Unwissen einzuräumen.
Für produktive Systeme ist das ein Zuverlässigkeitsproblem, nicht nur eine Qualitätsfrage. Eine halluzinierte Antwort kommt in der Regel erfolgreich zurück, mit normaler Latenz und ohne Fehlercode. Klassisches Monitoring bemerkt sie daher nicht. Um sie zu erkennen, braucht es die Methoden der LLM Observability und systematische Evaluierung.
Arten von Halluzinationen
- Sachfehler: falsche Daten, Namen, Zahlen oder Aussagen über die Welt.
- Nicht quellentreue Antworten: Die Antwort widerspricht den im Prompt mitgegebenen Dokumenten oder geht über sie hinaus, etwa in einer RAG-Anwendung.
- Erfundene Belege: ausgedachte Quellen, URLs, Studientitel, Aktenzeichen oder Zitate.
- Code-Halluzinationen: Aufrufe von Bibliotheksfunktionen, Parametern oder Konfigurationsschlüsseln, die es nicht gibt.
- Tool- und Agenten-Halluzinationen: Aufruf eines nicht verfügbaren Tools, erfundene Argumente oder die Behauptung, eine Aktion sei ausgeführt worden, obwohl das nicht geschah.
Warum halluzinieren LLMs?
Mehrere Faktoren spielen zusammen. Trainingsdaten können lückenhaft, veraltet oder widersprüchlich sein. Modelle haben einen Wissensstichtag und kennen aktuelle Ereignisse nur, wenn sie diese als Kontext erhalten. Trainingsziele belohnen plausiblen Text und können je nach Verfahren das Raten stärker belohnen als das Eingestehen von Unsicherheit. Auf Anwendungsseite erhöhen vage Prompts, fehlender oder irrelevanter Kontext aus dem Retrieval, sehr lange Kontexte, in denen relevante Fakten untergehen, und eine hohe Sampling-Temperatur das Risiko.
In Agenten-Workflows verstärkt sich das Risiko. Ein halluziniertes Zwischenergebnis, etwa eine erfundene Bestellnummer, wird zur Eingabe des nächsten Schritts, und spätere Schritte bauen darauf auf. Die finale Antwort wirkt dann in sich stimmig, beruht aber auf einer falschen Annahme. Deshalb sollte jeder Schritt eines Agentenlaufs nachvollziehbar sein und, wo möglich, validiert werden. Ein Trace pro Lauf zeigt, an welcher Stelle die falsche Information zuerst auftaucht, und trennt so Fehler des Modells von Fehlern in Tools oder Datenquellen.
Halluzinationen im Betrieb erkennen
Kein einzelnes Signal erkennt zuverlässig jede Halluzination. Teams kombinieren daher mehrere Ansätze:
- Groundedness-Prüfungen: Jede Aussage der Antwort wird mit den abgerufenen Quellen abgeglichen, unbelegte Aussagen werden markiert.
- LLM-as-a-Judge: Ein zweites Modell bewertet Quellentreue oder Korrektheit anhand eines Bewertungsschemas. Das skaliert gut, ist aber selbst fehlbar und sollte gegen menschliche Bewertungen kalibriert werden.
- Deterministische Validierung: Zitate, Links, IDs, Zahlen und Code werden gegen das Quellsystem, ein Schema oder einen Compiler geprüft.
- Referenztests: Ein kuratierter Satz von Fragen mit bekannten Antworten läuft vor jedem Release als Teil der LLM-Evaluierung.
- Nutzerfeedback: negative Bewertungen, Korrekturen und Eskalationen, verknüpft mit dem Trace der Anfrage.
Speichern Sie Bewertungsergebnisse als Attribute oder Events am Trace der Anfrage. So lassen sich halluzinierte Antworten nach Modell, Prompt-Version oder Retrieval-Quelle filtern, und Sie sehen, was das Modell tatsächlich als Eingabe erhalten hat.
Beispiel: einer falschen Antwort nachgehen
Ein illustratives Beispiel: Ein interner Assistent teilt Mitarbeitenden mit, die Richtlinie erlaube 30 Tage mobiles Arbeiten im Ausland, laut aktueller Fassung sind es 20. Der Trace der Anfrage zeigt, dass der Retrieval-Schritt eine veraltete Fassung des Dokuments mit hohem Ähnlichkeitswert geliefert hat, während die aktuelle Fassung noch nicht indiziert war. Das Modell hat seinem Kontext treu geantwortet. Die Ursache liegt also in veralteten Daten im Index, nicht im Modell. Die Lösung: Neuindizierung bei Dokumentänderungen und das Dokumentdatum als Metadatum im Retrieval-Ergebnis.
Halluzinationen reduzieren
- Stützen Sie Antworten auf abgerufene, aktuelle und zugriffsgeschützte Quellen und lassen Sie das Modell diese zitieren.
- Weisen Sie das Modell an, offen zu sagen, wenn der Kontext die Antwort nicht enthält, und werten Sie diese Antwort als gültig.
- Nutzen Sie strukturierte Ausgaben und Schemas für Tool-Aufrufe und validieren Sie Argumente vor der Ausführung.
- Senken Sie die Sampling-Temperatur bei faktenbezogenen Aufgaben.
- Ergänzen Sie KI-Guardrails, die unbelegte Aussagen in sensiblen Bereichen blockieren oder markieren.
- Binden Sie Menschen bei Entscheidungen mit rechtlicher, finanzieller oder sicherheitsrelevanter Tragweite ein.
Wie Obseria hilft
Obseria speichert den vollständigen Trace einer GenAI-Anfrage einschließlich Retrieval- und Modell-Spans. Eine markierte Antwort lässt sich so auf ihren Kontext, ihre Prompt-Version und ihr Modell zurückführen. Bewertungsergebnisse und Nutzerfeedback, die als OpenTelemetry-Attribute oder -Events eingehen, können Sie neben Latenz- und Token-Metriken auswerten und alarmieren. Mehr unter AI Observability.
