Halluzinationen technisch reduzieren: Engineering-Maßnahmen jenseits des Prompts

Wenn ein Sprachmodell überzeugend klingende, aber falsche Aussagen produziert, greifen die meisten Teams zum selben Werkzeug: Sie schärfen den Prompt nach. Man ergänzt Anweisungen wie die Aufforderung, nur belegte Fakten zu nennen, und hofft auf Besserung. Das hilft ein Stück weit, aber es bleibt ein Appell an ein statistisches System. Wer Halluzinationen reduzieren will, braucht Maßnahmen, die in der Architektur verankert sind und nicht in der Formulierung.

Die gute Nachricht: Solche Maßnahmen existieren, und sie liegen fast alle außerhalb des Prompts. Sie betreffen die Frage, worauf das Modell antwortet, was es tun soll, wenn es nichts Belastbares weiß, was der Code nach der Antwort prüft, wie die Erzeugung parametrisiert ist und wie das Ganze im Betrieb überwacht wird. Jede dieser Stellschrauben wirkt unabhängig von der Prompt-Formulierung, und zusammen verändern sie das Fehlerprofil eines Systems grundlegend.

Grounding: Antworten an eigene Quellen binden

Die wirksamste Einzelmaßnahme ist Grounding: Das Modell beantwortet Fragen nicht aus seinem Trainingswissen, sondern auf Basis mitgelieferter Dokumente, typischerweise über eine Retrieval-Stufe. Damit verschiebt sich die Aufgabe von freiem Erinnern, wo Modelle notorisch unzuverlässig sind, zu gebundenem Zusammenfassen, wo sie deutlich stärker sind.

Grounding entfaltet seine Wirkung aber nur unter zwei Bedingungen. Erstens muss das Retrieval liefern: Wenn die relevante Passage nicht im Kontext landet, füllt das Modell die Lücke aus dem Gedächtnis, und die Halluzination kehrt durch die Hintertür zurück. Die Qualität der Suche ist damit direkt eine Halluzinationsfrage. Zweitens braucht es Belegpflicht: Die Anwendung sollte das Modell anhalten, Aussagen den Quellstellen zuzuordnen, und diese Zuordnung anzeigbar machen. Ein Verweis, den der Nutzer aufklappen und prüfen kann, diszipliniert nicht nur das System, sondern verändert auch den Umgang der Nutzer mit den Antworten: aus Glauben wird Nachprüfen.

Abstain-Design: lieber keine Antwort als eine falsche

Halluzinationen entstehen bevorzugt dort, wo das System eine Antwort erzwingen will, obwohl die Grundlage fehlt. Das Gegenmittel ist ein bewusst gestalteter Enthaltungspfad, das Abstain-Design: Die Anwendung definiert, unter welchen Bedingungen keine inhaltliche Antwort gegeben wird, und gestaltet diesen Fall als vollwertiges, sauberes Ergebnis statt als Versagen.

Technisch heißt das: Wenn das Retrieval keine oder nur schwach passende Treffer liefert, wird das nicht stillschweigend an das Modell durchgereicht, sondern führt zu einer definierten Rückmeldung, etwa dass zu dieser Frage keine belastbare Quelle im Bestand existiert. Das Schema der Antwort sieht den Fall explizit vor, zum Beispiel über ein Statusfeld, das zwischen beantwortet, teilweise beantwortet und nicht beantwortbar unterscheidet. Und die Schwellen dafür werden im Code gesetzt, nicht dem Modell überlassen.

Organisatorisch verlangt Abstain-Design eine Entscheidung, die unbequem ist: Man akzeptiert, dass das System manche Fragen nicht beantwortet, und zwar sichtbar. Die Erfahrung zeigt, dass genau diese Eigenschaft Vertrauen schafft. Ein System, das gelegentlich passt, wird ernster genommen als eines, das immer etwas sagt.

Nachgelagerte Konsistenzprüfungen im Code

Zwischen Modellantwort und Auslieferung an den Nutzer liegt eine oft ungenutzte Chance: deterministische Prüfungen, die falsche Aussagen abfangen, bevor sie jemand liest. Was sich prüfen lässt, hängt von der Domäne ab, aber die Muster ähneln sich:

• Referenzprüfung: Zitiert die Antwort nur Quellen, die im Kontext tatsächlich vorhanden waren? Verweise auf nicht mitgelieferte Dokumente sind ein starkes Halluzinationssignal.
• Faktenabgleich: Zahlen, Daten und Namen in der Antwort lassen sich gegen die Quellpassagen oder gegen Stammdaten abgleichen. Ein Betrag, der in keiner Quelle vorkommt, fällt auf.
• Widerspruchsprüfung: Bei strukturierten Ausgaben lassen sich fachliche Invarianten prüfen, etwa dass ein Enddatum nach dem Startdatum liegt oder eine Summe zu ihren Positionen passt.
• Zweitmeinung: Für kritische Ausgaben kann ein zweiter, unabhängiger Modellaufruf die Antwort gegen die Quellen prüfen. Das ist keine deterministische Garantie, senkt aber die Durchlassrate falscher Aussagen spürbar, zu zusätzlichen Kosten, die man bewusst abwägt.

Schlägt eine Prüfung an, gibt es drei definierte Reaktionen: Antwort verwerfen und neu erzeugen, Antwort mit Warnhinweis ausliefern oder an einen Menschen eskalieren. Welche Reaktion passt, ist eine Frage des Risikos des jeweiligen Anwendungsfalls.

Decoding-Einstellungen: unterschätzt, aber begrenzt

Die Parameter der Texterzeugung, allen voran die Temperatur, beeinflussen die Streuung der Ausgaben. Eine niedrige Temperatur macht die Erzeugung konservativer und reproduzierbarer, was für extraktive und faktenorientierte Aufgaben fast immer die richtige Wahl ist. Kreative Streuung ist dort kein Nutzen, sondern ein Risiko.

Wichtig ist aber, die Wirkung realistisch einzuordnen. Eine niedrige Temperatur verhindert keine Halluzination, die im Modell fest verankert ist: Wenn das Modell eine falsche Aussage für die wahrscheinlichste hält, kommt sie auch bei konservativer Erzeugung. Decoding-Einstellungen reduzieren die zufälligen Ausreißer, nicht die systematischen Fehler. Sie sind eine sinnvolle Grundeinstellung, kein Sicherheitsnetz. Ein Nebeneffekt ist trotzdem wertvoll: Reproduzierbarere Ausgaben machen Tests und Evals aussagekräftiger, weil sich Änderungen klarer zuordnen lassen.

Die Halluzinationsrate im Betrieb messen

Alle genannten Maßnahmen haben einen gemeinsamen Haken: Ohne Messung weiß niemand, ob sie wirken. Deshalb gehört zur Halluzinationsbekämpfung eine laufende Messung im Betrieb. Praktikabel ist eine Kombination aus drei Quellen. Erstens ein fester Prüffall-Katalog mit Fragen, deren korrekte Antworten bekannt sind, der regelmäßig und bei jeder Änderung durchlaufen wird. Zweitens Stichproben aus dem echten Verkehr, die periodisch von Menschen bewertet werden, mit klaren Kriterien, was als Halluzination zählt. Drittens die Signale aus den nachgelagerten Prüfungen selbst: Wie oft schlägt die Referenzprüfung an, wie oft wird enthalten, wie oft eskaliert. Diese Kennzahlen über die Zeit beobachtet zeigen Drift an, lange bevor sich Nutzer beschweren.

Erst mit dieser Messung werden die Stellschrauben steuerbar: Man sieht, ob eine bessere Retrieval-Stufe die Rate senkt, ob eine strengere Abstain-Schwelle mehr nützt als sie kostet, und ob ein Modellwechsel das Fehlerprofil verändert hat.

Fazit

Halluzinationen sind kein Prompt-Problem, sondern ein Systemproblem, und sie werden auf Systemebene gelöst: Grounding bindet Antworten an eigene Quellen, Abstain-Design macht die Enthaltung zum sauberen Ergebnis, Konsistenzprüfungen im Code fangen falsche Aussagen vor der Auslieferung ab, konservative Decoding-Einstellungen nehmen die zufällige Streuung heraus, und die laufende Messung zeigt, ob das alles wirkt. Keine dieser Maßnahmen drückt die Rate auf null. Zusammen verwandeln sie ein unberechenbares Risiko in eine überwachte, steuerbare Größe, und genau das ist der Unterschied zwischen einem Experiment und einem System, das man verantworten kann.