Halluzination ist das Prinzip, nicht die Störung

Ein Sprachmodell hat keinen Faktenspeicher, in dem es nachsehen könnte. Es besitzt ein statistisches Modell davon, wie Text weitergeht, gelernt aus enormen Textmengen, und wählt damit das nächste Token, dann das nächste, bis die Antwort fertig aussieht. In dieser Schleife gibt es keinen Schritt, an dem irgendetwas mit irgendetwas abgeglichen wird. Die ehrliche Antwort ist deshalb unbequem: Halluzinationen sind kein Versagen des Modells. Richtige und erfundene Antworten laufen über dasselbe Fließband, nach derselben Methode. Wo die Trainingsdaten eine Fortsetzung klar gestützt haben, kommt ein Fakt heraus. Wo nicht, kommt etwas heraus, das die Form eines Fakts hat.

Diese Unterscheidung ist nicht akademisch, denn sie sagt Ihnen, was Sie nicht kaufen können. Es kommt kein Modell, das aufgehört hat zu halluzinieren — so wenig, wie ein Hammer kommt, der aufgehört hat, hart zu sein. Alle Gegenmaßnahmen in diesem Text wirken entweder, indem sie verengen, was das Modell überhaupt tun soll, oder indem sie das Ergebnis von außen prüfen. Keine davon rührt an den Mechanismus. Wer etwas anderes andeutet, verkauft Ihnen eine niedrigere Fehlerquote und nennt sie eine andere Kategorie.

Die ehrliche Antwort. Das Modell sagt plausiblen Text vorher, es schlägt nichts nach. Wahrheit und Sprachfluss entstehen im selben Vorgang — deshalb sehen Sie einer falschen Antwort nicht an, dass sie falsch ist. Konstruieren Sie dafür, statt auf eine Lösung zu warten.

Warum es so überzeugt klingt

Was Menschen kalt erwischt, ist nicht, dass das Modell falsch liegt. Es ist, dass es in genau demselben Tonfall falsch liegt, in dem es sonst richtig liegt. Kein Zögern, kein Hinweis, keine dünnere Formulierung rund um die erfundene Klausel.

Selbstsicherheit ist bei einem Modell ein Register, in dem es zu schreiben gelernt hat — keine Messung, die es durchführt. Relativierender Text ist im Trainingskorpus vergleichsweise selten, und „das weiß ich nicht“ ist so gut wie nie die wahrscheinlichste Fortsetzung einer Frage, die beantwortbar aussieht. Nichts am Trainingsziel hat je kalibrierten Zweifel belohnt; belohnt wurde der Text, der passt. Flüssige Bestimmtheit ist damit der Normalfall — und sie hat mit dem Wahrheitsgehalt schlicht nichts zu tun.

Daraus folgt der Punkt, den die meisten Teams falsch machen: Die Rückfrage „bist du sicher?“ ist Theater. Die Antwort darauf entsteht im selben Verfahren auf fast demselben Kontext und liefert eine flüssige Neuherleitung desselben Fehlers — oder sie knickt ein und stimmt Ihrem Einwand zu, unabhängig davon, wer recht hatte. Selbst angegebene Konfidenzwerte haben denselben Mangel. Wenn Ihre Prüfung darin besteht, dass das Modell seine eigene Arbeit beurteilt, haben Sie einen Absatz hinzugefügt, keine Kontrolle.

Wann es zählt — und wann nicht

„Wie genau ist das Modell?“ ist die falsche Frage, und es ist genau die, die jeder Anbieter gern beantwortet. Über den tatsächlichen Schaden entscheiden zwei andere Größen: was eine falsche Antwort kostet und wie lange es dauert, bis sie jemand bemerkt. Genauigkeit ist eine Eigenschaft des Modells. Diese beiden sind Eigenschaften des Prozesses, in den Sie es stellen — und sie liegen in Ihrer Hand.

Nehmen Sie einen Maschinenbauer mit einem Ersatzteil-Assistenten im Service. Das Modell erfindet eine Teilenummer, jemand bestellt den falschen Dichtring, er kommt an, er passt nicht, ein Techniker sagt Bescheid. Ärgerlich, ein paar hundert Euro — und vor allem: Der Fehler meldet sich von selbst. Nehmen Sie nun einen Regionalversicherer, dessen Sachbearbeiter sich den Deckungsumfang zusammenfassen lassen, bevor sie an den Kunden schreiben. Das Modell übergeht einen Ausschluss oder erfindet einen. Ein Ablehnungsschreiben geht raus. Auffallen wird das niemandem — bis Monate später eine Ombudsmann-Beschwerde eingeht und jemand das Muster über alle seither versandten Schreiben erklären muss. Gleiches Modell, gleiche Fehlerquote, vollkommen anderes Engineering-Problem.

Kosten einer Falschaussage Hoch Gering Sofort bemerkt Spät bemerkt Erden und belegen die Prüfung greift noch rechtzeitig Freigabe — oder gar nicht falsch und unsichtbar: hier sitzt die Haftung Einfach ausliefern der Nutzer korrigiert gratis mit Einschränken, Stichprobe einen Ausschnitt prüfen, nicht alles Nicht die Modellgüte entscheidet über den Prüfaufwand, sondern die Zeit bis zum Auffallen.
Dasselbe Modell gehört in vier verschiedene Systeme. Investieren Sie Ihr Prüfbudget oben rechts — hohe Kosten, späte Entdeckung — und hören Sie auf, es unten links auszugeben.

Die meisten Teams verteilen ihren Aufwand gleichmäßig über alle vier Felder. So entsteht ein schwergewichtiger Freigabeprozess für ein internes Brainstorming-Werkzeug — und gar keiner für das Schreiben, das zum Kunden geht. Sortieren Sie Ihre Anwendungsfälle in dieses Raster, bevor Sie irgendetwas beschaffen. Es sagt Ihnen, wohin das Geld gehört.

Was LLM-Halluzinationen wirklich reduziert

Drei Maßnahmen tragen den Großteil der Last. Sie stehen hier in der Reihenfolge, in der Teams sie üblicherweise ausprobieren — das ist nicht die Reihenfolge ihrer Wirksamkeit.

Erdung — und die Falle, die sie stellt

Eigene Dokumente abrufen und das Modell daraus antworten lassen ist der größte einzelne Hebel; wie eine RAG-Pipeline im Detail funktioniert, ist ein Thema für sich. Der Teil, der meist übergangen wird: Erdung senkt nicht nur die Rate der Halluzinationen, sie verändert ihre Gestalt — und die neue Gestalt ist schwerer zu erwischen.

Eine ungeerdete Erfindung sieht oft nach einer aus: vage, ohne Beleg, eine Spur zu glatt. Eine geerdete kommt mit Dokumentnamen, Abschnittsnummer und einem Zitat, das fast passt — eine echte Klausel aus einer echten Police, die nur nicht das aussagt, was der Satz behauptet. Belege übertragen Vertrauen, bevor irgendjemand sie prüft. Wer eine nackte Behauptung skeptisch gelesen hätte, winkt dieselbe Behauptung durch, sobald „[Bedingung 4.2]“ dahintersteht. Die nützliche Ingenieursarbeit sind deshalb nicht hübschere Quellenangaben, sondern Angaben, die einen Klick von der Belegstelle entfernt sind, mit markierter Passage — sodass Prüfen zwei Sekunden kostet statt zwei Minuten. Machen Sie das Prüfen billiger als das Vertrauen, sonst wird vertraut.

Den Antwortraum einschränken

Die meistunterschätzte Maßnahme, und meist die günstigste. Der verlässliche Weg, eine erfundene Teilenummer zu verhindern, ist, erfundene Teilenummern unmöglich zu machen. Wenn die Antwort eine Zeile aus Ihrem ERP sein muss, ist es nicht Aufgabe des Modells, die Nummer zu schreiben — sondern die Zeile auszuwählen. Constrained Decoding (ein JSON-Schema, eine GBNF-Grammatik unter llama.cpp, Outlines) erzwingt eine strukturell gültige Ausgabe; ein Fremdschlüssel-Abgleich gegen die tatsächliche Tabelle erzwingt, dass der Wert überhaupt existiert. Was an einer der beiden Prüfungen scheitert, erreicht nie einen Menschen.

Die Asymmetrie ist der Punkt. Ein halluziniertes Feld, das am Schema scheitert, ist ein abgefangener Fehler und ein neuer Versuch. Ein halluzinierter Satz im Fließtext ist ein Support-Ticket in drei Wochen — wenn Sie Glück haben und überhaupt eines bekommen. Jeder Freiheitsgrad, den Sie der Ausgabe nehmen, ist eine ganze Kategorie von Halluzination, die Sie hinterher nicht mehr entdecken müssen.

Gegen etwas prüfen, das nicht das Modell ist

Echte Prüfung heißt: die Aussage gegen eine externe Wahrheit halten. Die Abfrage ausführen, die Rechnung im Code machen, prüfen, ob die ID auflöst, die Zusammenfassung gegen die Passage diffen, aus der sie stammt. Genau hier verdient ein werkzeugnutzender KI-Agent sein Geld — nicht weil er klug ist, sondern weil er gezwungen wird nachzuschlagen statt sich zu erinnern. Ein zweites Modell als Prüfer ist besser als nichts und fängt einige Fehlerklassen tatsächlich ab, ist aber nur schwach unabhängig: Es teilt Trainingsdaten und damit blinde Flecken mit dem Modell, das es bewertet.

Und die ehrliche Grenze: Prüfung erwischt Erfindung deutlich besser als Auslassung. Eine Zusammenfassung, die stillschweigend den einen entscheidenden Ausschluss weglässt, ist vollständig durch die Quelle gedeckt, widerspricht nichts und besteht jede Entailment-Prüfung, die Sie bauen können. Mir ist dafür keine saubere technische Lösung bekannt. Das ist der Hauptgrund, warum oben rechts weiterhin ein Mensch sitzen muss.

Der kontraintuitive Teil. Erdung macht Halluzinationen seltener und besser getarnt. Eine falsche Antwort mit echtem Beleg wird weniger geprüft als eine ohne — der Gewinn ist also nur echt, wenn das Prüfen des Belegs wirklich mühelos ist. Sonst haben Sie einen überzeugenderen Fehler gekauft.

Was ich nicht tun würde

Ich würde die „Halluzinationsrate“ nicht zur Kennzahl machen. Sie schrumpft auf eine einzelne Zahl über einem synthetischen Testsatz zusammen, sie bewegt sich, sobald jemand die Evaluation anfasst, und sie sagt nichts darüber, ob die verbleibenden Fehler die teuren sind. Ein kostengewichteter Wert über einem Goldsatz aus echten Anfragen — den tatsächlichen Tickets, den Klauseln, nach denen Ihre Sachbearbeiter wirklich fragen — ist aufwendiger und mehr wert.

Ich würde kein Halluzinations-Erkennungsmodell kaufen und es als Sicherheitskonzept ausgeben. Solche Detektoren markieren einen Teil eines Problems, das nicht vollständig detektierbar ist — und die Fälle, die sie übersehen, sind genau die, die wehtun. Sie sind ein Filter, keine Kontrolle.

Und ich würde kein Modell auf einen Pfad stellen, der zugleich teuer und spät sichtbar ist, ohne einen Menschen, der die Befugnis und die Zeit hat, Nein zu sagen. Fällt Ihr System als Hochrisiko unter die EU-KI-Verordnung — Risikobewertung und Preisbildung in der Lebens- und Krankenversicherung stehen in Anhang III —, verlangt Artikel 14 wirksame menschliche Aufsicht. Ein Sachbearbeiter, der hunderte Zusammenfassungen pro Stunde freigeben soll, ist keine Aufsicht, sondern ein Stempel mit Stellenbezeichnung. Aufsicht, die Sie nicht besetzt haben, haben Sie nicht. Und Halluzination ist nicht immer ein Unfall: Wer Text in Ihr Kontextfenster bekommt, kann steuern, was das Modell überzeugt behauptet — an dieser Stelle hört Prompt Injection und LLM-Sicherheit auf, ein separates Thema zu sein.

Wo Tippel ins Spiel kommt

Der größte Teil der Arbeit an einem vertrauenswürdigen LLM-System ist kein Prompt Engineering. Er besteht darin, jeden Anwendungsfall dem richtigen Quadranten zuzuordnen und dann im passenden Maß einzuschränken, zu erden und zu prüfen — und bereit zu sein zu sagen, dass auf einem bestimmten Pfad gar kein Modell stehen sollte. Genau dieses Urteil liefert der KI-Readiness-Check: Ihre echten Daten, ein Anwendungsfall, ein festes Zeitfenster und eine ehrliche Einschätzung, ob Ihr Prozess die Fehlerarten verträgt, die bleiben.

Wenn Sie eine Idee haben, bei der eine selbstbewusste Falschaussage teuer würde, ist das eine Stunde Gespräch wert, bevor es ein Budget wert ist. Nehmen Sie Kontakt auf — dann sortieren wir gemeinsam, in welchem Quadranten Sie stehen.