LLM-Halluzinationen: 5 Techniken zur Reduktion im Produktionsbetrieb

Ein Modell beantwortet mit Überzeugung eine Frage, die es nicht korrekt beantworten kann. Es erfindet eine Quellenangabe, ergänzt eine fehlende Zahl, bestätigt die Vorannahme in der Frage — und die gesamte Antwort klingt überzeugend. Das nennen wir Halluzination (engl. *hallucination*): die Generierung einer glaubwürdigen, aber faktisch falschen Ausgabe. In experimentellen Deployments ist das lästig. Im Produktionsbetrieb — beim Arbeiten mit Dokumentation, Verträgen, technischen Normen oder Kundenanforderungen — richtet es echten Schaden an.

Die Praxis zeigt, dass die Grundrate an Halluzinationen bei Frontier-Modellen im Bereich von wenigen bis zu einigen Dutzend Prozent liegt, wenn es um Fachfragen geht, bei denen das Modell kein ausreichendes Grounding hat. Das Ziel dieses Artikels ist nicht, ein halluzinationsfreies System zu versprechen — ein solches existiert nicht. Das Ziel ist, fünf Techniken zu zeigen, die dieses Problem im Produktionsbetrieb deutlich reduzieren können, und zu erklären, warum jede einzelne anders wirkt und warum keine für sich allein ausreicht.

Warum Halluzinationen nicht vollständig verschwinden

Bevor wir zu den Techniken kommen, muss die Grundursache verstanden werden. LLMs suchen keine Fakten nach — sie generieren Tokens auf Basis dessen, was im gegebenen Kontext statistisch wahrscheinlich ist. Das Modell unterscheidet nicht zwischen „Ich weiß" und „Ich weiß nicht": Wird es nicht explizit trainiert oder instruiert, Unsicherheit auszudrücken, generiert es standardmäßig eine flüssige und glaubwürdig klingende Antwort.

Die Modellgröße allein löst das Problem nicht — ein größeres Modell kann selbstsicherer halluzinieren, da seine Sprachfähigkeiten besser sind und die Ausgaben überzeugender klingen. Ohne Grounding-Strategie senkt also ein größeres Modell das Risiko nicht, in manchen Fällen erhöht es es sogar.

Konsequenz für Produktions-Deployments: Halluzinationen müssen architektonisch gesteuert werden, nicht durch die Wahl eines besseren Modells.

Technik 1: Grounding über RAG mit zitierbaren Quellen

RAG (*Retrieval-Augmented Generation*) ist heute der verbreitetste Mechanismus zur Reduktion von Halluzinationen bei faktographischen Fragen. Das Prinzip ist einfach: Anstatt dass das Modell aus dem parametrischen Gedächtnis antwortet (aus dem, was es beim Training gelernt hat), bekommt es relevante Passagen aus verifizierten Dokumenten in den Kontext geliefert. Die Antwort muss dann aus diesem Kontext hervorgehen.

Das bloße Einfügen von Dokumenten in den Prompt reicht nicht aus. Ein hochwertiges Grounding-System hat drei Schichten:

• Retrieval — Vektorsuche (z. B. über Qdrant oder pgvector), ergänzt durch hybride Suche (BM25 + Vektoren), damit nicht nur semantisch ähnliche, sondern auch schlüsselwortrelevante Passagen gefunden werden
• Reranking — ein Cross-Encoder-Modell bewertet die Reihenfolge der Ergebnisse neu; ohne Reranking liefert das Retrieval relevante und weniger relevante Chunks gemischt, der Reranker verbessert die Präzision der Auswahl deutlich
• Zitierbarkeit — das Modell erhält die Anweisung: jede Aussage muss durch eine konkrete Quelle mit Verweis auf Dokument und Seite belegt sein; fehlt die Quelle, erfindet es keine

Zitierbarkeit ist nicht nur für die Genauigkeit entscheidend, sondern auch für die Nachvollziehbarkeit: Der Nutzer sieht, woher eine Information stammt, und kann sie überprüfen. In der Praxis erhöht das das Vertrauen erheblich und deckt Fälle auf, in denen das Modell eine Quellenangabe ignoriert oder erfunden hat. Mehr zur Bewertung von RAG-Pipelines lesen Sie im Artikel Wie man RAG evaluiert (RAGAS), in dem wir die Metriken Faithfulness und Answer Relevance beschreiben.

Wichtiger Hinweis: RAG löst nicht alles. Liefert das Retrieval falsche Chunks zurück (Embedding-Mismatch, schlechtes Chunking, veraltete Datenbank), kann das Modell auch mit Kontext halluzinieren — oder, was schlimmer ist, mit einer falschen Quellenangabe halluzinieren. RAG ist eine notwendige, keine hinreichende Bedingung.

Technik 2: Strukturierte Ausgabe und programmatische Validierung

Freitext ist schwer zu verifizieren. Gibt das Modell eine Antwort in exakt definierter Struktur zurück — JSON-Schema, Pydantic-Modell, Aufzählung erlaubter Werte — kann die Ausgabe maschinell validiert werden, bevor sie den Nutzer oder das nächste System erreicht.

Moderne Modelle und Frameworks unterstützen Structured Outputs (*strukturierte Ausgaben*): Das Modell wird gezwungen, Tokens zu generieren, die dem vorgegebenen Schema entsprechen. Eine Halluzination kann somit kein Feld erfinden, das im Schema nicht vorhanden ist. Ist das erlaubte Feld risk_level mit den Werten ["low", "medium", "high"] definiert, kann das Modell nicht "critical" oder Unsinn zurückgeben.

In der Praxis kombinieren wir drei Schritte:

1. 1.Definition des Ausgabeschemas (z. B. JSON-Schema oder Pydantic-Modell)
2. 2.Verwendung von structured outputs / JSON mode beim API-Aufruf
3. 3.Programmatische Validierung der Ausgabe — entspricht die Ausgabe nicht dem Schema, wird der Aufruf wiederholt oder an einen menschlichen Review eskaliert

Dieser Ansatz funktioniert am besten bei klar abgegrenzten Aufgaben: Entitätsextraktion, Klassifikation, Formularausfüllung, Konvertierung eines Dokuments in eine Struktur. Für Freitext (Zusammenfassung, Interpretation) ist die Anwendbarkeit eingeschränkt, aber auch hier lässt sich zumindest die Anwesenheit Pflichtfelder validieren (z. B. Abschnitt „Quellen" oder „Hinweise").

Technik 3: „Ich weiß es nicht" erlauben — Kalibrierung der Unsicherheit

Einer der einfachsten und wirksamsten Schritte ist, dem Modell explizit zu erlauben, „Ich weiß es nicht" zu antworten — oder: „Auf Basis der verfügbaren Informationen kann ich das nicht beurteilen." Das klingt trivial, aber die meisten Produktions-Prompts vergessen es — und das Modell generiert dann standardmäßig eine Antwort, auch wenn die Informationen fehlen.

Konkret empfehlen wir im System-Prompt (engl. *system prompt*) Formulierungen wie:

• Geht die Antwort nicht aus den bereitgestellten Dokumenten hervor, weise explizit darauf hin, dass die Information nicht verfügbar ist.
• Leite keine Fakten ab und schlussfolgere nichts, das nicht im Kontext steht.
• Bist du unsicher, drücke den Grad der Unsicherheit sprachlich aus („wahrscheinlich", „gemäß den verfügbaren Informationen").

Wichtig: Die Kalibrierung der Unsicherheit muss eine aktive Anweisung sein, nicht nur das Fehlen eines Halluzinier-Verbots. „Halluziniere nicht" reicht nicht — das Modell versteht diese Anweisung zwar, hat aber keinen Mechanismus, sie umzusetzen, ohne einen expliziten Rahmen für das Ausdrücken von Unsicherheit.

In regulierten Bereichen (juristische Dokumente, technische Dokumentation, Sicherheitsnormen) empfehlen wir zusätzlich eine Eskalationsregel zu definieren: Ist das Modell nicht in der Lage, mit ausreichender Sicherheit zu antworten, sollte die Antwort eine Aufforderung zur Überprüfung durch eine fachkundige Person enthalten. Das senkt direkt das Risiko stiller Fehler — Situationen, in denen das System mit Überzeugung antwortet und der Fehler unentdeckt bleibt.

Technik 4: LLM-as-Judge — automatische Verifikation der Ausgaben

LLM-as-Judge (*LLM als Richter*) ist eine Technik, bei der ein zweites Sprachmodell die Ausgabe des ersten bewertet. Im Produktionsbetrieb wird sie zur automatischen Erkennung von Halluzinationen, zur Überprüfung der Konsistenz mit dem Kontext und zur Bewertung der Antwortqualität eingesetzt — ohne dass bei jeder Antwort ein menschlicher Reviewer benötigt wird.

Ein typischer Ablauf sieht so aus:

1. 1.Das primäre Modell generiert eine Antwort
2. 2.Das Verifikationsmodell erhält das Tripel: Frage + Quellkontext + generierte Antwort
3. 3.Das Verifikationsmodell bewertet: Enthält die Antwort Aussagen, die nicht durch den Kontext gestützt werden? Ist die Antwort faktisch konsistent mit den Quellen?
4. 4.Je nach Score wird die Antwort entweder ausgeliefert, zurückgehalten oder an einen menschlichen Review gesendet

Für das Verifikationsmodell empfehlen wir, dasselbe oder ein stärkeres Modell als das primäre zu verwenden — ein schwächerer Verifikator kann Fehler eines stärkeren Modells nicht zuverlässig erkennen. In der Praxis sehen wir gute Ergebnisse bei der Kombination eines lokal laufenden primären Modells und eines Frontier-Verifikators (z. B. Claude Sonnet- oder GPT-4o-Klasse) für kritische Antworten.

Frameworks wie Langfuse oder Arize Phoenix ermöglichen es, diesen Flow mit Logging, Alerting und retrospektiver Analyse in die Produktions-Pipeline einzubauen. Mehr zum Gesamtansatz der Qualitätsmessung finden Sie im Artikel Wie man die Qualität einer LLM-Applikation misst (Evals).

Einschränkung: LLM-as-Judge ist nicht unfehlbar — auch das Verifikationsmodell kann einer halluzierten Antwort „zustimmen", wenn beide konsistent sind, aber faktisch falsch. Deshalb kombinieren wir es mit Grounding (Technik 1) und einem regelmäßigen menschlichen Audit einer Stichprobe der Ausgaben.

Technik 5: Temperatur, Sampling und Prompt Engineering

Die letzte Technik ist am günstigsten zu implementieren, hat aber ohne die anderen Schichten den geringsten Effekt. Sie ist dennoch wichtig.

Die Temperatur (*temperature*) beeinflusst die Zufälligkeit der Generierung. Eine niedrige Temperatur (z. B. 0.0–0.2) produziert deterministischere, konsistentere Ausgaben — das Modell wählt den wahrscheinlichsten Token, keinen zufälligen. Für faktographische Aufgaben (Extraktion, Klassifikation, Beantwortung von Fragen aus Dokumenten) empfehlen wir eine niedrige Temperatur. Für kreative oder generative Aufgaben ist eine höhere Temperatur erwünscht, erhöht aber gleichzeitig das Risiko von Abweichungen.

Prompt Engineering zur Reduktion von Halluzinationen hat mehrere bewährte Prinzipien:

• Few-Shot-Beispiele — zeige dem Modell Beispiele für korrektes Verhalten, einschließlich Beispielen, bei denen die Antwort „Ich weiß es nicht" lautet; das Modell übernimmt dieses Verhalten im Kontext
• Explizite Formatvorgabe — „Antworte ausschließlich auf Basis der folgenden Dokumente, beende jede Aussage mit einer nummerierten Quellenangabe"
• Negative Anweisungen — „Leite keine Informationen ab, die nicht explizit im Kontext angegeben sind"
• Chain-of-Thought (*Gedankenkette*) — bei komplexen Fragen das Modell auffordern, die Antwort Schritt für Schritt durchzudenken, bevor es die finale Ausgabe liefert; bei sensiblen Aufgaben reduziert das „Abkürzen" zur halluzierten Antwort deutlich

Hinweis: Prompts sind fragil — sie funktionieren für ein bestimmtes Modell und eine bestimmte Version. Bei einem Modell- oder Versionswechsel müssen Prompts neu evaluiert werden. Prompt Engineering ist daher eine laufende Aktivität, kein einmaliger Output. Mehr zu diesem Thema: Prompt Engineering für den Produktionsbetrieb.

Fünf Techniken im Zusammenspiel

Keine Technik reicht allein. In der Praxis kombinieren wir sie in Schichten:

• Basisschicht — RAG mit Quellenangaben + Erlaubnis „Ich weiß es nicht" im System-Prompt
• Ausgabeschicht — Strukturierte Ausgabe + programmatische Validierung
• Verifikationsschicht — LLM-as-Judge für kritische Antworten
• Kalibrierungsschicht — niedrige Temperatur + Few-Shot-Prompt für Konsistenz

Der Effekt der Kombination ist deutlich größer als die Summe der einzelnen Techniken. Produktionssysteme, in denen wir alle vier Schichten implementiert haben, erreichen eine deutlich niedrigere Rate faktischer Fehler als Systeme mit nur einer Schicht — in der Größenordnung von Zehntelprozent gegenüber einigen Prozent bei Fachfragen. Die genauen Zahlen hängen von der Domäne, der Qualität der Quelldokumente und der Art der Evaluierung ab.

Was den Techniken nicht hilft

Der Vollständigkeit halber: Was Halluzinationen nicht zuverlässig reduziert:

• Ein größeres Modell — kann selbstsicherer halluzinieren; ohne Grounding-Strategie hilft es nicht
• Längerer Kontext — mehr Daten im Kontext bedeutet nicht weniger Halluzinationen; das Modell kann den relevanten Kontext ignorieren oder falsch interpretieren
• Ein einfaches Halluzinierverbot im Prompt — das Modell versteht den Begriff „Halluzination" nicht so, dass es ihn aktiv verhindern könnte; es braucht positive Anweisungen zur Formulierung von Unsicherheit
• Benchmark-Score des Modells — MMLU und ähnliche Benchmarks sind saturiert und messen kein Produktionsverhalten in Fachdomänen; ein Leaderboard-Ergebnis korreliert nicht zuverlässig mit der Halluzinationsrate in Ihrer konkreten Anwendung

Häufige Fragen

Ist es möglich, ein System zu entwickeln, das niemals halluziniert?

Nein. LLMs sind stochastische generative Modelle — es gibt immer eine Wahrscheinlichkeit ungleich null für eine halluzinierte Ausgabe. Das Ziel ist nicht null Fehlerquote, sondern die Reduktion auf ein für den jeweiligen Use Case akzeptables Maß und die Einführung von Mechanismen zur Erkennung und zum Abfangen von Fehlern, bevor sie Schaden anrichten. Für kritische Entscheidungen (rechtliche, medizinische, sicherheitsrelevante) bleibt ein menschlicher Review unerlässlich.

Hilft Fine-Tuning auf Unternehmensdaten dabei, Halluzinationen zu reduzieren?

Nur teilweise und nicht direkt. Fine-Tuning (*Feinabstimmung des Modells* auf eigenen Daten) verbessert den Antwortstil, die Terminologie und das Format — verbessert aber nicht die faktische Genauigkeit, wenn das Modell bei der Inference keinen entsprechenden Kontext erhält. Zur Reduktion von Halluzinationen ist RAG typischerweise der effektivere und günstigere Ansatz. Fine-Tuning und RAG schließen sich nicht gegenseitig aus — ihre Kombination ergibt in fortgeschritteneren Deployments Sinn. Die Entscheidungsfindung zwischen beiden beschreiben wir im Artikel RAG vs. Fine-Tuning — welcher Ansatz.

Wie stellt man fest, wie viel eine LLM-Applikation halluziniert?

Eine systematische Evaluierung erfordert einen Eval-Datensatz — eine Sammlung von Fragen mit korrekten Antworten oder Quelldokumenten — sowie ein Evaluierungsframework wie RAGAS (für RAG-Pipelines) oder Langfuse (für allgemeine LLM-Applikationen). Automatisierte Evaluierung mittels LLM-as-Judge kann große Volumina abdecken, muss aber zumindest an einer Stichprobe gegen menschliche Bewertung kalibriert werden. Ein regelmäßiges menschliches Audit der Produktionsausgaben empfehlen wir immer — nicht nur beim erstmaligen Deployment.

Erhöht eine niedrige Temperatur das Risiko stereotyper oder unvollständiger Antworten?

Ja, das ist ein realer Trade-off. Eine niedrige Temperatur reduziert die Variabilität — das Modell wählt konsistent die wahrscheinlichsten Tokens, was in Extremfällen zu sich wiederholenden Phrasen oder dem Weglassen weniger wahrscheinlicher, aber relevanter Informationen führen kann. In der Praxis empfehlen wir für faktographische Aufgaben eine Temperatur von 0.1–0.3 — nicht absolut null — und kombinieren sie mit expliziten Anweisungen zur Vollständigkeit der Antwort.

Welche Kosten entstehen durch die Einführung dieser Techniken?

Die Kosten sind primär implementierungs- und betriebsbedingt. Eine RAG-Pipeline benötigt eine Vektordatenbank, ein Embedding-Modell und Retrieval-Logik — bei einer Self-Hosted-Lösung (z. B. Qdrant + Open-Weight-Embedding-Modell) belaufen sich die Infrastrukturkosten auf wenige Euro pro Monat. LLM-as-Judge verdoppelt die Anzahl der LLM-Aufrufe für kritische Ausgaben, was die API-Kosten erhöht. Structured Outputs verursachen praktisch keine Mehrkosten. Die Gesamtinvestition hängt vom Volumen ab, aber bei typischen Unternehmensanwendungen (Dutzende bis Hunderte Anfragen pro Tag) ist der Kostenanstieg im Vergleich zum Risiko eines stillen Fehlers im Produktionsbetrieb vernachlässigbar.

*Wenn Sie planen, LLMs in einem Umfeld einzusetzen, in dem faktische Genauigkeit Entscheidungen direkt beeinflusst — von technischer Dokumentation über Kundensupport bis hin zu Compliance — helfen wir Ihnen gerne dabei zu bewerten, welche Kombination von Techniken für Ihren konkreten Fall sinnvoll ist. MP Industrial Solutions hat Erfahrung mit Produktions-Deployments in industriellen und regulierten Umgebungen.*