Hallucination
Wenn ein LLM flüssige, überzeugte Ausgaben erzeugt, die schlicht falsch sind. Eine direkte Folge der Funktionsweise, nicht beseitigbar, nur reduzierbar.
Eine Halluzination ist, wenn ein Modell etwas erzeugt, das richtig klingt und falsch ist: eine erfundene Quelle, eine ausgedachte API, ein plausibler, aber falscher Fakt. Es ist kein Fehler, den man wegpatchen kann. Ein LLM sagt wahrscheinlichen Text voraus, und eine flüssige, überzeugt klingende Antwort ist statistisch wahrscheinlich, egal ob sie zufällig stimmt. Das Modell hat kein inneres Gespür für “das weiß ich nicht”, also füllt es die Lücke mit etwas, das ins Muster passt.
Weil es strukturell ist, lautet die ehrliche Einordnung Risikoreduktion, nicht Beseitigung. Der größte Hebel ist Erdung: Gib dem Modell die tatsächlichen Fakten zur Laufzeit per Retrieval (RAG), damit es aus echtem Quelltext antwortet statt aus seiner Trainings-Vermutung. Schränke Ausgabeformate ein, damit weniger Raum zum Improvisieren bleibt. Lass das Modell Quellen nennen, die du prüfen kannst. Und entscheidend: evaluiere, baue ein Testset echter Fragen, miss wie oft das System falsch liegt, und behandle diese Zahl als Qualitätskennzahl, die du wie jede andere verfolgst.
Hier trifft KI auf QA, und die meisten Teams überspringen das. Ein LLM-Feature ohne Evaluations-Harness auszuliefern heißt, ungetesteten Code auszuliefern und es fertig zu nennen. Du musst deine Fehlerrate kennen, bevor deine Nutzer sie für dich finden. Das behandeln wir als nicht verhandelbar unter Software Quality Assurance .
Praxisbeispiel, warum der Evaluations-Harness nicht verhandelbar ist: Ein Team liefert einen Rechtsdokument-Assistenten aus, nachdem es ihn von Hand an einem Dutzend Fragen getestet hat, die alle großartig aussahen. In Produktion zitiert er überzeugt eine Klausel, die im hochgeladenen Vertrag gar nicht existiert, ein Nutzer handelt danach, und jetzt gibt es ein echtes Haftungsrisiko. Der Harness, der das abgefangen hätte, ist unglamourös: ein paar hundert echte Fragen mit bekannten korrekten Antworten, bei jeder Änderung ausgeführt, die eine einzige Zahl erzeugen, den Prozentsatz, den das System falsch hatte. Ohne ihn kennst du deine Fehlerrate nicht, das heißt deine Nutzer entdecken sie für dich, eine schlechte Antwort nach der anderen. Mit ihm kannst du vor dem Launch entscheiden, ob die Rate für den Einsatz akzeptabel ist.
Der Vertrauensaspekt ist in regulierten oder risikoreichen Domänen das ganze Spiel. Eine Halluzination in einem Chatbot, der einen Film empfiehlt, ist ein Achselzucken. Dieselbe Halluzination in Finanz-, Rechts- oder medizinischer Ausgabe ist ein Risiko. Passe die Leitplanken an die Kosten des Irrtums an, und lass nie eine flüssige Antwort eine geprüfte ersetzen.