Halluzinationen in LLM-Anwendungen reduzieren und testen

Was eine Halluzination wirklich ist

Eine Halluzination ist keine Fehlfunktion im klassischen Sinn. Ein Sprachmodell erfindet nichts aus Absicht, sondern setzt die statistisch plausibelste Fortsetzung einer Eingabe zusammen. Ob das Ergebnis inhaltlich stimmt, ist aus Sicht des Modells zweitrangig. Was fehlt, ist ein eingebauter Prüfmechanismus für Wahrheit.

Für Unternehmen ist diese Unterscheidung wichtig. Ein halluziniertes Produktdetail in einer Angebotsmail, eine frei erfundene Klausel in einer Vertragszusammenfassung oder eine falsche Zahl in einem Management-Report sind keine Randfälle, sondern das Standardverhalten eines Modells, das ohne ausreichenden Kontext antworten muss. Halluzinationen treten dort auf, wo das Modell raten muss und sich das im Text nicht anmerken lässt.

Warum Modelle halluzinieren

Die Ursachen lassen sich in wenige Gruppen bündeln. Erstens fehlt dem Modell schlicht Wissen zum Thema, weil es nicht im Training enthalten war oder weil interne Unternehmensinformationen gar nicht vorliegen können. Zweitens ist der Prompt unterspezifiziert: Die Frage lässt mehrere Interpretationen zu, und das Modell wählt eine plausible, die mit der Realität des Fragenden wenig zu tun hat.

Drittens liefert das Retrieval bei RAG-Anwendungen die falschen oder unvollständigen Quellen, und das Modell füllt die Lücke mit eigenem Wissen. Viertens erzwingt das System implizit eine Antwort, auch wenn „weiß ich nicht“ die ehrlichere Option wäre. In den meisten produktiven Fällen überlagern sich mehrere dieser Ursachen. Wer nur an einer Stellschraube dreht, wundert sich später, warum das Problem nicht verschwindet.

Typische Fälle im Unternehmensalltag

Halluzinationen zeigen sich selten als offensichtlicher Unsinn. Gefährlicher ist das Gegenteil: eine Antwort, die flüssig klingt, interne Begriffe korrekt benutzt und deshalb erst spät im Prozess auffällt. Beispiele, die in der Praxis immer wiederkehren:

Ein Support-Assistent zitiert eine Richtlinie, die es so nicht gibt. Ein Sales-Tool fasst eine Produktvariante zusammen, die nie gebaut wurde. Ein juristischer Helfer nennt einen Paragrafen, der im zitierten Gesetz fehlt. Ein interner Analyst gibt Zahlen aus, die aus dem Kontext plausibel wirken, aber aus keiner angeschlossenen Quelle stammen. Alle diese Fälle haben gemeinsam, dass der Nutzer das Ergebnis ohne eigene Gegenprüfung kaum erkennen kann.

Architektur: wo Halluzinationen wirklich reduziert werden

Die größte Wirkung entsteht nicht durch einen besseren Prompt, sondern durch das System, in dem das Modell arbeitet. Der wichtigste Hebel ist eine belastbare Wissensanbindung. Wenn das Modell Antworten auf abgegrenzte, aktuelle Inhalte zurückführen kann, sinkt der Spielraum für freies Erfinden. Genau dafür werden RAG-Systeme gebaut. Ein sauberes Retrieval ist dabei wichtiger als ein besonders großes Modell.

Der zweite Hebel ist Tool-Use. Statt einem Modell die Aufgabe zu geben, eine Zahl zu „wissen“, lässt man es gezielt eine Funktion oder eine Datenbank abfragen. Für Kennzahlen, Statusabfragen oder Rechenaufgaben ist ein deterministisches Werkzeug der Halluzinationen immer überlegen. Das gleiche Prinzip steht hinter produktiven KI-Agenten, die kritische Schritte nicht selbst formulieren, sondern delegieren.

Der dritte Hebel ist strukturierte Ausgabe. Wer das Modell zwingt, ein definiertes Schema zu füllen, und leere Felder explizit erlaubt, reduziert die Versuchung, Lücken mit plausiblen Angaben zu schließen. Eine sauber modellierte Antwortstruktur ist oft wirkungsvoller als ein seitenlanger Prompt.

Prompting und System-Design

Prompts sind nicht die Lösung des Problems, aber sie entscheiden, wie sich ein gut gebautes System im Grenzfall verhält. Drei Punkte tragen in der Praxis am deutlichsten. Erstens: die Erlaubnis, nicht zu antworten. Wenn ein System-Prompt ausdrücklich zulässt, „dazu liegen keine Informationen vor“ auszugeben, nutzt das Modell diese Option tatsächlich häufiger. Ohne diese Erlaubnis fühlt sich jedes Modell verpflichtet, etwas zu liefern.

Zweitens: die Pflicht zur Quelle. Wenn eine Antwort sich auf konkrete Textstellen beziehen muss und fehlende Treffer sichtbar bleiben, fällt das Raten auf. Drittens: die Trennung von Interpretation und Fakt. Ein Assistent, der erst zusammenfasst und anschließend eine Empfehlung ausspricht, ist leichter prüfbar als einer, der beides vermischt.

Messbar machen: Halluzinationen testen

Ohne Messung bleibt jede Optimierung ein Bauchgefühl. Wer ernsthaft mit KI arbeitet, braucht einen festen Datensatz aus typischen Fragen, erwarteten Antwortbausteinen und klar markierten Fallen, bei denen das Modell eigentlich „weiß ich nicht“ sagen müsste. Dieser Datensatz ist kein Forschungsprojekt, sondern ein lebendes Artefakt des Betriebs.

Auf dieser Basis lassen sich mehrere Dimensionen bewerten: faktische Richtigkeit gegen eine Referenz, die Abdeckung der relevanten Quellen, die Rate der falsch zurückhaltenden und falsch antwortenden Fälle sowie die Konsistenz bei wiederholten Anfragen. In der Praxis hat sich eine Kombination aus regelbasierten Checks, Vergleich gegen Referenzantworten und gezielten LLM-as-Judge-Bewertungen bewährt, flankiert von menschlichem Review auf einem kleinen, aber stabilen Sample.

Entscheidend ist, dass diese Messung Teil des Entwicklungs- und Betriebsprozesses wird. Jede Änderung an Prompt, Modell, Daten oder Retrieval muss gegen den Testdatensatz laufen, bevor sie in Produktion geht. Genau an dieser Stelle setzt LLM-Qualitätssicherung an: nicht als einmaliges Audit, sondern als wiederholbare Prüfung mit klaren Metriken.

Typische Fehler beim Reduzieren von Halluzinationen

Viele Teams beginnen bei den falschen Stellen. Der häufigste Fehler ist, das Modell zu tauschen und zu hoffen, dass ein stärkeres Modell das Problem löst. Ein besseres Modell reduziert Halluzinationen in der Regel nur marginal, wenn die eigentliche Ursache in Daten, Retrieval oder Aufgabenschnitt liegt.

Der zweite typische Fehler ist, den Prompt immer länger zu machen. Lange Verhaltensregeln, die sich gegenseitig widersprechen, erhöhen das Risiko, dass das Modell unvorhersehbar reagiert. Kürzere, klar priorisierte Anweisungen sind robuster. Der dritte Fehler ist, ohne Testdatensatz zu iterieren. Ein Team, das nur Einzelbeispiele anschaut, verbessert einen Teil und verschlechtert unbemerkt einen anderen. Der vierte Fehler ist, Halluzinationen als reines Modellthema zu sehen. Oft sind die Inhalte unklar oder unvollständig, und das Modell macht genau das sichtbar, was in den Quelldaten fehlt. Dann gehört die Aufräumarbeit vor das Prompt-Tuning.

Wann professionelle Unterstützung sinnvoll ist

Für einen Prototyp, der intern unverbindlich genutzt wird, reicht oft ein gutes Modell mit einem sauberen Prompt. Sobald eine Anwendung aber gegenüber Kunden, Fachbereichen oder Revision standhalten soll, ändert sich die Anforderung grundlegend. Dann geht es um reproduzierbare Qualität, Risikobewertung, Regressionstests und belastbare Betriebsprozesse.

Spätestens an diesem Punkt lohnt es sich, Architektur, Datenfluss und Testsetup von außen bewerten zu lassen. Wir arbeiten mit Unternehmen, die KI-Anwendungen nicht nur bauen, sondern verantworten wollen. Unser Fokus liegt auf AI Engineering und strukturiertem Testing, damit Halluzinationen nicht zufällig entdeckt, sondern systematisch eingegrenzt werden.