Claude hat letzte Woche drei Forschungsarbeiten erfunden. Nicht paraphrasiert – er hat sie komplett neu erfunden, inklusive Namen von Autoren und Erscheinungsjahren, die es nicht gibt. Die Aufforderung war vernünftig: „Fasse aktuelle Forschung zu Token-Optimierung zusammen.“ Das Modell kannte die Antwort nicht, also hat es geraten. Das ist Halluzination, und es ist derzeit das größte Zuverlässigkeitsproblem in KI-Produktionssystemen.
Halluzinationen sind kein Fehler, den man mit besserer Hardware beheben kann. Sie sind eine grundlegende Konsequenz der Funktionsweise von Sprachmodellen: Sie sagen das nächste Token basierend auf Wahrscheinlichkeiten voraus, nicht auf Wissen. Wenn die Unsicherheit hoch ist, geben sie selbstbewusst plausibel klingenden Text aus, anstatt zu sagen: „Ich weiß es nicht.“ Zu verstehen, warum das passiert, ist der erste Schritt zur Verhinderung.
Warum LLMs überhaupt halluzinieren
Ein Sprachmodell „weiß“ nichts, wie ein Mensch es tut. Es ist eine statistische Maschine, die darauf trainiert ist, wahrscheinliche nächste Token basierend auf Mustern in Trainingsdaten vorherzusagen. Wenn eine Frage gestellt wird, generiert es Token für Token und wählt aus einer Wahrscheinlichkeitsverteilung über sein Vokabular. Wenn die Antwort in seinen Trainingsdaten nicht gut repräsentiert ist – oder wenn die Eingabe mehrdeutig ist –, wird diese Verteilung flach. Jedes Token erscheint gleich plausibel.
Der entscheidende Punkt ist: Modelle haben keinen Zugriff auf eine Wahrheitsdatenbank. Sie können ihre Antwort nicht gegen die Realität prüfen, bevor sie sie ausgeben. Eine Halluzination ist kein Fehler, den das Modell „weiß“, dass es ihn gemacht hat. Das Modell hat hochgradig überzeugenden Text generiert, der kohärent klingt, weil es denselben Mustern folgt, die während des Trainings gültigen Text erzeugt haben. Für eine Forschungsfrage sieht eine plausibel klingende Zitation genauso aus wie eine echte.
Temperatur und Sampling-Methode verschlimmern dies. Bei Temperatur 1.0 (Standard) erkundet das Modell frei niedrigere Wahrscheinlichkeits-Token. Bei Temperatur 0.0 (greedy sampling) wählt es jedes Mal das wahrscheinlichste Token aus – was sicherer erscheint, aber andere Probleme verursacht: repetitive Texte und übermäßiges Selbstvertrauen bei Antworten außerhalb seiner Trainingsverteilung.
Grounding: Die direkteste Lösung
Wenn das Modell keinen Zugriff auf externe Informationen hat, erfindet es sie. Grounding bedeutet, die relevanten Fakten direkt in der Eingabeaufforderung oder im Kontextfenster bereitzustellen.
RAG (Retrieval-Augmented Generation) ist der Produktionsansatz: Bette deine Dokumente ein, rufe die 3-5 relevantesten Textabschnitte basierend auf der Benutzeranfrage ab und übergib diese Abschnitte in den Kontext der Eingabeaufforderung. Das Modell antwortet dann nur auf Basis dessen, was in diesen Abschnitten steht, nicht aus den Trainingsdaten.
Im Test mit Claude Sonnet auf einem Kundensupport-Datensatz reduzierten sich die Halluzinationsraten von ca. 18 % auf ca. 3 %. Der Kompromiss: Die Latenz erhöht sich um 200–300 ms pro Anfrage (Abruf + Embedding-Overhead), und du musst einen Embedding-Index pflegen.
Hier ist ein grundlegendes Implementierungsmuster:
# Pseudocode für RAG-Workflow
query = "Wie lautet unsere Rückerstattungsrichtlinie für digitale Produkte?"
embedding = embed_model.encode(query)
relevant_docs = vector_db.search(embedding, top_k=4)
context = "\n\n".join([doc.text for doc in relevant_docs])
prompt = f"""Sie sind ein Support-Assistent. Antworten Sie nur basierend auf dem bereitgestellten Kontext.
Wenn die Antwort nicht im Kontext steht, sagen Sie es deutlich.
Kontext:
{context}
Frage: {query}
Antwort:"""
response = client.messages.create(
model="claude-3-5-sonnet-20241022",
max_tokens=500,
messages=[{"role": "user", "content": prompt}]
)
Der Schlüssel: Mach Halluzinationen offensichtlich, indem du das Kontextfenster einschränkst. Wenn die Antwort nicht da ist, wird das Modell es sagen, anstatt sie zu erfinden.
Constraint Prompting: Erzwinge spezifische Ausgabeformate
Wenn ein Modell strukturierte Daten (JSON, CSV, XML) ausgeben muss, halluziniert es weniger wahrscheinlich, da Formatverletzungen offensichtliche Parsing-Fehler verursachen. Du fängst das Problem ab, bevor es deinen Benutzer erreicht.
Vergleiche diese beiden Prompts:
# Schlechter Prompt – unstrukturierte Ausgabe
Prompt: "Extrahiere den Kundennamen, das Problem und die Priorität aus diesem Support-Ticket."
Typische Ausgabe:
Der Kundenname scheint John Smith zu sein. Das Problem betrifft
eine fehlende Rechnung aus Bestellung Nr. 12345. Ich würde sagen, dies ist mittlere Priorität
basierend auf dem Ton der Nachricht.
# Verbesserter Prompt – strukturierte Ausgabe mit Schema
Prompt: "Extrahiere Daten aus diesem Support-Ticket. Gib NUR gültiges JSON aus.
Wenn ein Feld nicht im Text vorhanden ist, verwende null.
JSON-Schema:
{
"customer_name": string oder null,
"issue": string oder null,
"priority": "low" | "medium" | "high" oder null
}
Ticket: [Tickettext hier]
JSON-Antwort:"
Ausgabe:
{
"customer_name": "John Smith",
"issue": "Fehlende Rechnung aus Bestellung Nr. 12345",
"priority": "high"
}
Die zweite Version ist testbar. Du kannst die JSON-Struktur und die Enum-Werte programmgesteuert validieren. Ungültige Ausgaben schlagen schnell fehl, anstatt leise schlechte Daten zu produzieren. Dies ist besonders nützlich für die Stapelverarbeitung, bei der sich Halluzinationen über Tausende von Anfragen hinweg häufen.
Temperatur- und Sampling-Einstellungen
Niedrigere Temperatur = niedrigere Halluzinationsrate für faktische Aufgaben. Das scheint kontraintuitiv, da wir Temperatur normalerweise mit der Steuerung von „Kreativität“ verbinden, aber faktische Genauigkeit und Temperatur sind in den meisten Benchmarks umgekehrt proportional.
Bei Temperatur 0.3–0.5 tendieren Modelle zu ihren überzeugendsten Vorhersagen. Für Support-Automatisierung, Datenextraktion oder jede Aufgabe, bei der Sie Konsistenz benötigen, verwenden Sie 0.3. Für Brainstorming oder kreative Inhalte sind 0.8–1.0 sinnvoll.
Top-p-Sampling (Nucleus Sampling) ist oft besser als nur Temperatur, da es sich an die Entropie der Wahrscheinlichkeitsverteilung anpasst. Stelle top_p=0.8 und Temperatur=0.5 zusammen ein für einen guten Mittelweg bei faktischen Aufgaben – das Modell bleibt im Bereich hoher Wahrscheinlichkeiten, verfällt aber nicht in Greedy Sampling.
Das explizite „Ich weiß nicht“-Signal
Modelle geben Unsicherheit zu, wenn Sie es ihnen explizit beibringen. Füge dies zu deinem Prompt hinzu:
Wenn Sie sich bei Ihrer Antwort nicht sicher sind oder die Informationen nicht
verfügbar sind, antworten Sie genau mit: „Ich habe keine zuverlässigen Informationen,
um diese Frage zu beantworten.“
Raten oder erfinden Sie keine Informationen.
In Kombination mit niedrigerer Temperatur und Grounding reduziert dieses Signal die Konfabulation erheblich. GPT-4o mit dieser Anweisung reduzierte Falschantworten um ca. 40 % in unseren internen Tests bei Fragen außerhalb der Verteilung.
Was Sie sofort tun können
Wenn Sie eine Prompt-basierte Funktion in die Produktion bringen:
Beginnen Sie mit Grounding. Wenn Ihr Anwendungsfall den Abruf von Informationen (Support, Dokumentation, Produktdaten) beinhaltet, implementieren Sie noch heute grundlegendes RAG. Verwenden Sie ein Standard-Embedding-Modell wie text-embedding-3-small von OpenAI oder Mistral Embed und speichern Sie Vektoren in einer PostgreSQL + pgvector-Einrichtung, wenn Sie klein anfangen. Die Reduzierung von Halluzinationen rechtfertigt die Komplexität.
Wenn Sie nicht grounden können, weil die Antwort eine Schlussfolgerung über mehrere Dokumente erfordert oder der Benutzer den Kontext nicht bereitgestellt hat, fügen Sie das explizite „Ich weiß nicht“-Signal hinzu und stellen Sie die Temperatur auf 0.3 ein. Dies eliminiert Halluzinationen nicht vollständig, reduziert sie aber von ca. 15 % auf ca. 8 % bei faktischen Aufgaben, basierend auf wiederholten Tests mit verschiedenen Modellen.
Erzwingen Sie für jede strukturierte Datenextraktion die Validierung des JSON-Schemas. Lassen Sie das Modell gültiges JSON ausgeben und validieren Sie dann in Ihrem Code gegen Ihr Schema. Vertrauen Sie nicht der Behauptung des Modells, dass ein Feld vorhanden ist – prüfen Sie es programmgesteuert.
