Warum eine Halluzination nicht mit einem Prompt „behoben» wird
Bevor man an der Konfiguration schraubt, sollte man eine unbequeme Realität akzeptieren: Halluzinationen sind kein Bug, der sich mit einer strengeren Anweisung beseitigen lässt. Sie sind ein emergentes Verhalten der probabilistischen Funktionsweise des Modells. Ein LLM generiert das wahrscheinlichste Token gegeben einer Sequenz, es konsultiert keine Faktenbasis. Wenn der Kontext die Antwort nicht enthält, hält das Modell nicht an: Es vervollständigt mit dem, was statistisch passt. Das bedeutet, dass jede Konfiguration, die dir „null Halluzinationen» verspricht, dir heiße Luft verkauft.
Was du tun kannst, ist die Fläche zu reduzieren, auf der sie auftreten, sie zu erkennen, bevor sie den Nutzer erreichen, und das System kontrolliert zu degradieren, wenn das Vertrauen sinkt. Dieser Artikel ist eine reale Konfigurationssequenz mit konkreten Parametern, Schwellenwerten und Verifikationen für Teams, die bereits ein LLM in Produktion haben oder kurz davor stehen.
Schritt 1: Trenne die Arten von Halluzinationen, bevor du irgendetwas konfigurierst
Nicht alle Halluzinationen werden gleich abgeschwächt. Konfigurieren ohne zu klassifizieren führt dazu, dass man die falsche Stelle flickt. Unterscheide mindestens diese vier, denn jede erfordert eine andere Ebene:
- Faktisch: Das Modell behauptet ein falsches Datum (ein Datum, eine Zahl, ein Gesetz). Bekämpft wird dies mit Kontextabruf und externer Verifikation.
- Der Attribution: Es erfindet eine Quelle, einen Autor oder ein Zitat. Sie ist die gefährlichste in redaktionellen Inhalten, weil sie verifizierbar erscheint.
- Der Anweisung: Es ignoriert eine Systemeinschränkung (antwortet in einer anderen Sprache, bricht das Format). Bekämpft wird dies mit Ausgabevalidierung.
- Der Schlussfolgerung: Die Zwischenschritte sind plausibel, aber die Schlussfolgerung folgt nicht. Bekämpft wird dies mit Zerlegung und Prüfung jedes Schritts.
Ein Fall, den ich bei Content-Teams immer wieder sehe: Sie setzen die Temperatur auf 0 in der Annahme, dass dies die Erfindung von Quellen beendet. Die Variabilität sinkt, ja, aber ein Modell mit Temperatur 0 erfindet weiterhin Referenzen, wenn es die Information nicht hat. Die Temperatur reduziert die Streuung, nicht die Unwissenheit.
Schritt 2: Lege Temperatur und Sampling je nach Aufgabe fest
Die Sampling-Konfiguration ist der erste echte Regler. Es gibt keinen universellen Wert; es gibt einen Wert pro Aufgabentyp. Orientiere dich an dieser Tabelle:
| Aufgabe | Temperatur | top_p | Anmerkung |
|---|---|---|---|
| Datenextraktion aus einem Dokument | 0 – 0,1 | 1 | Du willst Determinismus, keine Kreativität |
| Antworten über interne Dokumentation | 0,1 – 0,3 | 0,9 | Minimaler Spielraum, um Sätze nicht zu wiederholen |
| Assistiertes Schreiben mit menschlicher Verifikation | 0,4 – 0,7 | 0,95 | Die nachträgliche Verifikation ist obligatorisch |
| Brainstorming, Naming | 0,8 – 1,0 | 1 | Hier ist die Halluzination ein Feature, kein Bug |
Expertenwarnung: top_p auf 0,5 zu senken, kürzt den Schwanz unwahrscheinlicher Token, was seltene Erfindungen reduziert, aber auch den Text flacher und repetitiver macht. Bei Aufgaben der strukturierten Extraktion sollte man es mit constrained decoding (Grammatiken oder erzwungene JSON-Schemata) kombinieren, was effektiver ist als jede Temperatureinstellung, um erfundene Felder zu vermeiden.
Schritt 3: Baue Retrieval mit Ablehnungsschwelle auf
Der stärkste Hebel gegen faktische Halluzination ist, das Modell nicht aus dem Gedächtnis antworten zu lassen. Konfiguriere eine RAG-Pipeline (retrieval-augmented generation) mit diesen expliziten Entscheidungen:
- Chunking: Fragmente von 300 bis 600 Token mit 10-15% Überlappung. Zu große Fragmente verwässern das Signal; zu kleine verlieren den Kontext, der Fehlinterpretationen vermeidet.
- Hybride Suche: Kombiniere semantische Suche (Embeddings) mit lexikalischer Suche (BM25). Die Semantik versagt bei Identifikatoren, Codes und Eigennamen; die Lexik versagt bei Paraphrasen. Zusammen decken sie mehr ab.
- Ähnlichkeitsschwelle: Definiere eine Mindestpunktzahl (zum Beispiel 0,75 bei Kosinus-Ähnlichkeit, angepasst nach Messung mit deinem eigenen Korpus), unterhalb derer das System das Modell nicht aufruft und eine Meldung „Ich habe nicht genügend Informationen» zurückgibt.
- Geschlossener Kontext-Prompt: Weise das Modell an, nur mit den abgerufenen Fragmenten zu antworten und explizit anzugeben, wenn der Kontext die Frage nicht abdeckt. Diese Anweisung ist nicht unfehlbar, aber in Kombination mit der Schwelle reduziert sie erfundene Antworten drastisch.
Hier ist der praktische Fehler, den fast alle beim ersten Mal machen: die Retrieval-Schwelle zu hoch setzen. Das System beginnt, legitime Fragen abzulehnen, und das Team senkt sie frustriert auf null. Die richtige Schwelle wird nicht geraten: Sie wird mit einem Satz von 50 bis 100 echten Fragen kalibriert, indem man misst, wie oft eine Frage abgelehnt wird, die tatsächlich eine Antwort hatte, gegenüber wie oft ohne Kontext geantwortet wird. Ohne diesen Kalibrierungssatz ist jede Schwelle eine Vermutung.
Schritt 4: Systemanweisungen, die tatsächlich funktionieren (und die, die es nicht tun)
Sätze wie „Erfinde nichts» haben begrenzte Wirksamkeit. Operative und verifizierbare Anweisungen funktionieren besser:
- Statt „Sei präzise», verwende „Zitiere das Kontextfragment, aus dem jede Aussage stammt; wenn es kein Fragment gibt, antworte ‚nicht belegt’.»
- Statt „Halluziniere nicht», verwende „Wenn die Frage Daten erfordert, die nach deinem Wissen liegen oder nicht im Kontext vorhanden sind, sage es, bevor du antwortest.»
- Füge ein Ausgabeformat mit Pflichtfeldern hinzu: Antwort, Quellen (Liste der verwendeten Fragmente), Konfidenz (hoch/mittel/niedrig). Das Feld für Quellen zwingt das Modell zur Festlegung und erleichtert die automatische Verifikation.
Was nicht funktioniert: zehn negative Einschränkungen im System-Prompt anzuhäufen. Ab einer bestimmten Anzahl beginnt das Modell, die ersten zu ignorieren oder sich übermäßig einzuschränken und gültige Anfragen abzulehnen. Priorisiere drei oder vier kritische Regeln und validiere jede mit Tests.
Schritt 5: Ausgabevalidierung, bevor sie dem Nutzer angezeigt wird
Die Konfiguration endet nicht beim Modell. Füge eine programmatische Validierungsebene zwischen Antwort und Nutzer hinzu:
- Schema-Validierung: Wenn du JSON erwartest, lehne jede Ausgabe ab, die das Schema nicht erfüllt. Versuche nicht, sie mit einem anderen Prompt zu reparieren, ohne den Fehler zu markieren.
- Entitätenprüfung: Extrahiere Namen, Daten und Zahlen aus der Antwort und vergleiche sie mit dem abgerufenen Kontext. Wenn eine Entität in keiner Quelle erscheint, markiere sie.
- Zitatprüfung: Wenn das Modell ein Dokument zitiert, prüfe, ob dieses Dokument in deinem Index existiert und ob das zitierte Fragment darin enthalten ist. Erfundene Zitate lassen sich so mit hoher Zuverlässigkeit erkennen.
- Zweiter Durchlauf mit einem anderen Modell oder Prompt: Ein kleineres Modell als Verifizierer kann nicht gestützte Aussagen kennzeichnen. Es ist nicht unfehlbar und erhöht die Latenz, aber in redaktionellen Content-Flows lohnt es sich.
Wichtige Nuance: Die automatische Verifikation hat falsch-positive Ergebnisse. Ein zu strenger Verifizierer lehnt korrekte Antworten ab, die den Kontext paraphrasieren, statt ihn wörtlich zu zitieren. Konfiguriere den Verifizierer so, dass er Bedeutung vergleicht, nicht exakte Zeichenkettenübereinstimmung, sonst hast du ein System, das alles ablehnt.
Schritt 6: Definiere das Degradationsverhalten
Ein ausgereiftes System weiß, was zu tun ist, wenn es unsicher ist. Konfiguriere diese Zustände explizit:
- Hohe Konfidenz: Direkte Antwort mit Quellen.
- Mittlere Konfidenz: Antwort mit sichtbarem Hinweis und Links zu den Quellen zur menschlichen Verifikation.
- Niedrige Konfidenz: Nicht antworten; anbieten, die Frage umzuformulieren oder an einen Menschen weiterzuleiten.
- Validierungsfehler: Den vollständigen Fall protokollieren (Prompt, abgerufener Kontext, Ausgabe, Ablehnungsgrund) für die spätere Analyse.
Die Protokollierung ist der am meisten vergessene und wertvollste Teil. Ohne ein Fehler-Log kannst du weder Schwellenwerte noch Prompts verbessern; du kannst nur beten. Laut der Dokumentation der wichtigsten Modellanbieter ist die kontinuierliche Evaluierung mit eigenen Testsätzen die einzige zuverlässige Methode, um zu messen, ob deine Änderungen Halluzinationen reduzieren oder nur verschieben.
Schritt 7: Messe mit einem eigenen Testsatz, nicht mit öffentlichen Benchmarks
Generische Benchmarks spiegeln nicht deine Domäne wider. Konfiguriere einen Evaluierungssatz mit drei Arten von Fällen: Fragen, die dein System korrekt beantworten muss, Fragen außerhalb des Geltungsbereichs, die es ablehnen muss, und Fangfragen (falsche Prämissen), die es korrigieren muss. Führe diesen Satz jedes Mal aus, wenn du Temperatur, Prompt, Modell oder Retrieval-Schwelle änderst.
Zwei Mindestmetriken: Erfindungsrate (Antworten mit nicht gestützten Aussagen geteilt durch gegebene Antworten) und korrekte Ablehnungsrate (abgelehnte Fragen außerhalb des Geltungsbereichs geteilt durch Fragen außerhalb des Geltungsbereichs). Wenn du nur die erste optimierst, wird das System am Ende alles ablehnen; wenn du nur die zweite optimierst, wird es erfindend antworten. Sie stehen in Spannung zueinander und müssen gemeinsam überwacht werden.
Was diese Konfiguration nicht löst
Volle Transparenz: Selbst mit allem oben gut aufgesetzt bleiben Rest-Halluzinationen. Die am schlechtesten kontrollierbaren Fälle sind Schlussfolgerungs-Halluzinationen bei Fragen, die mehrere verkettete Schritte erfordern, die aus mehrdeutigem abgerufenem Kontext entstehen (Dokumente, die sich gegenseitig widersprechen) und die auftreten, wenn der Nutzer das Modell mit hartnäckigen falschen Prämissen drängt. In regulierten Domänen (Gesundheit, Recht, Finanzen) ersetzt keine Konfiguration die menschliche Überprüfung; das System kann unterstützen, aber die Verantwortung für die endgültige Aussage ist nicht an das Modell delegierbar.
Die realistische Erwartung ist nicht null Halluzinationen, sondern Halluzinationen, die erkannt werden, bevor sie Schaden anrichten, mit einem System, das weiß, wann es schweigen muss. Das ist die Konfiguration, die du gegenüber einem Kunden oder einem Auditor verteidigen kannst.