KI-Halluzination

Was ist KI-Halluzination?

Eine KI-Halluzination ist ein selbstbewusster Output eines Modells, der sachlich falsch oder komplett erfunden ist: eine Funktion, die es in der Bibliothek nicht gibt, ein Parameter, den die API nie akzeptiert hat, ein Paket, das niemand veröffentlicht hat, ein Zitat aus einem nie geschriebenen Paper. Der Output ist flüssig und plausibel, und genau das macht ihn gefährlich. Das Problem ist im großen Maßstab messbar: Eine Stanford-Studie von 2024 fand, dass LLMs bei 58 Prozent (ChatGPT) bis 88 Prozent (Llama 2) überprüfbarer Fragen zu zufälligen Bundesgerichtsfällen halluzinierten [1].

Die wichtigsten Punkte

• In der Softwarearbeit konzentrieren sich Halluzinationen auf Schnittstellen: erfundene Methoden, falsche Argumentnamen, veraltete Signaturen, die als aktuell dargestellt werden, und Imports von Paketen, die nicht existieren.
• Halluzination ist eine strukturelle Eigenschaft davon, wie Sprachmodelle Text generieren — sie sagen plausible Fortsetzungen voraus —, weshalb sie stark reduziert, aber nicht auf null gebracht werden kann.
• Die Schwere-Skala reicht von lästig (Code, der nicht kompiliert) über gefährlich (Code, der läuft, aber das Falsche tut) bis ausnutzbar (Installation eines halluzinierten Paketnamens, den ein Angreifer registriert hat — der Angriff heißt Slopsquatting).
• Verteidigung ist systemisch: Grounding in echtem Kontext, Tool-Zugriff, damit das Modell prüfen statt sich erinnern kann, Compiler und Tests als Verifikation, und Review durch jemanden, der plausibel-aber-falsch erkennt.
• Flüssigkeit und Genauigkeit sind unkorreliert. Der selbstbewusste Ton einer halluzinierten Antwort trägt keinerlei Information über ihre Wahrheit.

So funktioniert es

Ein Sprachmodell generiert Text, indem es vorhersagt, was angesichts seiner Trainingsdaten und des aktuellen Kontexts plausibel als Nächstes kommt, und es hat keinen eingebauten Mechanismus, der Erinnern von Erfinden unterscheidet. Wenn Sie nach einer Funktion aus einer Bibliothek fragen, die es tausendfach gesehen hat, fallen Vorhersage und Fakt meist zusammen. Wenn Sie nach einer Nischenbibliothek, einer aktuellen Version oder Ihrer privaten Codebasis fragen, interpoliert das Modell: Es produziert die Methode, die existieren würde, wenn die Bibliothek so gestaltet wäre wie ähnliche Bibliotheken. Deshalb ist halluzinierter Code so überzeugend. client.messages.list(page_size=50) sieht exakt wie echter SDK-Code aus, ob das SDK diese Methode je ausgeliefert hat oder nicht.

Code-Halluzinationen häufen sich an vorhersagbaren Stellen. Versionsgrenzen, wo die Trainingsdaten des Modells mehrere API-Generationen mischen und es Ihnen selbstbewusst die Signatur von 2023 liefert. Sprachübergreifende Kontamination, wo ein Python-Idiom in das JavaScript-SDK durchsickert. Plausible Vervollständigungen Ihrer eigenen Codebasis, die einen utils.formatCurrency-Helper erfindet, weil die meisten Codebasen wie Ihre einen haben. Und Abhängigkeitsvorschläge, bei denen ein Modell die Installation eines Pakets empfiehlt, dessen Namen es aus Fragmenten echter Pakete zusammengesetzt hat — das Rohmaterial für Supply-Chain-Angriffe. Eine Studie von 2024 mit 576.000 generierten Code-Beispielen fand, dass mindestens 5,2 Prozent der Paketempfehlungen kommerzieller LLMs und 21,7 Prozent bei Open-Source-Modellen auf halluzinierte, nicht existierende Pakete verwiesen [2]. Dieselben Forschenden katalogisierten 205.474 einzigartige halluzinierte Paketnamen über 16 populäre Code-Generierungsmodelle hinweg — eine fertige Angriffsfläche für jeden, der bereit ist, sie zu registrieren [3].

Gegenmaßnahmen schichten sich. Grounding bringt echte Dokumentation, Typdefinitionen und Quelldateien in das Context Window, sodass das Modell liest statt sich erinnert; Retrieval-Augmented Generation automatisiert das. Agentisches Tooling hilft zusätzlich, da ein KI-Coding-Agent, der die Codebasis durchsuchen und den Compiler ausführen kann, seine eigenen Erfindungen in der Schleife abfängt. Dann Verifikation: Typprüfer, Tests und Abhängigkeits-Allowlists verwandeln stille Halluzinationen in laute Fehlschläge. Menschliches Review übernimmt den Rest — den Code, der kompiliert, läuft und trotzdem falsch ist.

Beispiel

Ein Ingenieur bittet einen Coding-Agenten, einer Service-Bibliothek mit einer populären HTTP-Client-Bibliothek Retry-Logik hinzuzufügen. Der Agent schreibt sauberen Code, der client.request(retries=3, backoff="exponential") aufruft. Die Parameter sehen idiomatisch aus, der Code liest sich im Review gut, und keiner der beiden Parameter hat in dieser Bibliothek je existiert; Retries leben in einer separaten Adapterklasse. In einem einfachen Chat-Workflow wird dieser Schnipsel eingefügt, scheitert zur Laufzeit in einem Codepfad, der nur bei Netzwerkausfall durchlaufen wird, und liefert kaputtes Retry-Verhalten aus, das niemand bemerkt, bis es zum Ausfall kommt. In einem agentischen Workflow mit Guardrails markiert der Typprüfer die unbekannten Parameter sofort, der Agent liest den tatsächlichen Quellcode der Bibliothek, findet das Adapter-Muster und schreibt neu. Dieselbe Halluzination in beiden Fällen; der Unterschied ist, ob das System sie innerhalb von Sekunden in einen sichtbaren Fehlschlag verwandelt oder Wochen später in einen Produktionsvorfall.

Häufige Missverständnisse

Das hartnäckige Missverständnis ist, dass Halluzination ein Bug ist, den bessere Modelle beheben werden, sodass Teams den Aufbau von Verteidigungen aufschieben und auf das nächste Release warten. Modellgenerationen haben die Halluzinationsrate erheblich gesenkt, und die verbleibenden Fehler sind gefährlicher, nicht weniger, weil höhere Gesamtgenauigkeit mehr Vertrauen und weniger Prüfung verdient. Ein Tool, das in einem Drittel der Fälle falschliegt, wird geprüft; ein Tool, das in zwei Prozent der Fälle falschliegt, wird geglaubt, und diese zwei Prozent landen in Produktion. Behandeln Sie Halluzination wie Netzwerkausfälle: eine dauerhafte Eigenschaft des Mediums, um die herum Sie architektieren, mit Grounding, Verifikation und Review, statt eines Defekts, den Sie aussitzen.

FAQ

Warum passieren LLM-Halluzinationen, selbst wenn das Modell die korrekte Information gesehen hat? Weil das Modell statistische Muster speichert, keine Nachschlagetabelle. Korrekte und inkorrekte Fortsetzungen konkurrieren zum Zeitpunkt der Generierung, und Kontext, Formulierung oder Mehrdeutigkeit können die Waage zu einer plausiblen Erfindung kippen, selbst wenn die Wahrheit in den Trainingsdaten war. Das ist auch, warum dieselbe Frage, anders formuliert, einmal richtig und einmal falsch beantwortet werden kann.

Werden KI-Halluzinationen schlimmer oder besser? Nach Rate besser, besonders bei Code, wo Modelle der 2026er-Generation mit Tool-Zugriff APIs weit seltener halluzinieren als ihre Vorgänger, weil sie Dokumentation prüfen und Code ausführen können, statt sich zu erinnern. Das Risikoprofil hat sich verschoben statt zu verschwinden: weniger Fehler, jeder einzelne stärker vertraut, plus neue Angriffsflächen wie fabrizierte Tool-Outputs in Agenten-Pipelines.

Ist eine Halluzination dasselbe wie AI Slop? Nein. Eine Halluzination ist eine spezifische falsche Behauptung, eine erfundene Funktion, ein gefälschtes Zitat. KI Slop ist ein Volumen- und Prozessproblem: minderwertiger generierter Inhalt, der ohne Review ausgeliefert wird. Slop enthält häufig Halluzinationen, aber ein sorgfältig überprüftes System kann trotzdem gelegentlich eine Halluzination ausgeben, und Slop kann technisch korrekt und trotzdem wertlos sein.

Quellen

1. Dahl et al., Stanford. "Large Legal Fictions: LLMs halluzinierten bei 58 % (ChatGPT) bis 88 % (Llama 2) überprüfbarer Fragen zu zufälligen Bundesgerichtsfällen." https://arxiv.org/abs/2401.01301. Abgerufen im August 2026.
2. Spracklen et al., USENIX Security. "Studie mit 576.000 Code-Beispielen: mindestens 5,2 % der Paketempfehlungen kommerzieller LLMs und 21,7 % bei Open-Source-Modellen waren halluziniert." https://arxiv.org/abs/2406.10279. Abgerufen im August 2026.
3. Spracklen et al., USENIX Security. "205.474 einzigartige halluzinierte Paketnamen über 16 Code-Generierungsmodelle hinweg katalogisiert." https://arxiv.org/abs/2406.10279. Abgerufen im August 2026.