Halluzinationen bei Sprachmodellen: Ursachen und Gegenmaßnahmen

Halluzinationen sind Ausgaben eines Sprachmodells, die sprachlich überzeugend, aber inhaltlich falsch sind: erfundene Rechnungsnummern, nicht existierende Paragrafen, Zitate, die niemand gesagt hat. Das Modell täuscht nicht absichtlich – es erzeugt den wahrscheinlichsten Text, und wo Fakten fehlen, ist der wahrscheinlichste Text eine plausible Erfindung.

Was Halluzinationen sind

Der Begriff umfasst mehrere Fehlerarten, die unterschiedlich behandelt werden müssen:

• Erfundene Fakten: Das Modell nennt eine Zahl, ein Datum, einen Namen, den es nicht gibt.
• Falsche Zuordnung: Die Angaben stimmen, gehören aber zu einem anderen Kunden, Vertrag oder Produkt.
• Übergeneralisierung: Aus einem Einzelfall in den Quellen wird eine allgemeine Regel.
• Erfundene Belege: Eine Aussage wird mit einem Dokument oder Verweis gestützt, den das Modell gerade erfunden hat.
• Ignorierte Anweisung: Das Modell soll nur aus den Quellen antworten, ergänzt aber aus dem Gedächtnis.

Gemeinsam ist allen Formen: Der Text sieht richtig aus. Genau das macht sie gefährlich – ein Tippfehler fällt auf, eine flüssig formulierte falsche Frist nicht.

Warum Sprachmodelle halluzinieren

Ein Large Language Model ist ein Wahrscheinlichkeitsmodell für Text. Es wurde darauf trainiert, Sätze fortzusetzen, nicht darauf, Wahrheit von Unwahrheit zu unterscheiden. Vier Ursachen wirken zusammen:

• Fehlendes Wissen: Über die internen Daten eines Unternehmens weiß das Modell nichts. Gefragt, antwortet es trotzdem – mit dem, was in ähnlichen Zusammenhängen üblich ist.
• Kein „Weiß ich nicht“: Ohne ausdrückliche Erlaubnis, Unsicherheit zu äußern, erzeugt das Modell immer eine Antwort.
• Kontextverlust: Ist die Eingabe lang, gehen Details verloren, und die Lücke wird mit Wahrscheinlichem gefüllt.
• Ausrichtung auf Gefälligkeit: Modelle werden darauf trainiert, hilfreich zu wirken. Eine ausführliche, sichere Antwort wirkt hilfreicher als ein ehrliches „unklar“.

Typische Fälle im Unternehmen

• Im Kundendienst nennt der Antwortentwurf eine Lieferfrist, die in keinem Dokument steht.
• Bei der Belegverarbeitung wird eine unleserliche Rechnungsnummer ergänzt statt als unlesbar markiert.
• Ein Vertragsassistent zitiert eine Klausel, die im hochgeladenen Vertrag nicht vorkommt, in ähnlichen Verträgen aber häufig ist.
• Ein Entwicklungsassistent ruft eine Bibliotheksfunktion auf, die es in dieser Version nicht gibt.
• Ein Zusammenfassungswerkzeug fügt dem Protokoll eine Entscheidung hinzu, die nie getroffen wurde.

Die Fälle haben ein Muster: Das Modell hatte eine Lücke und hat sie gefüllt. Gegenmaßnahmen setzen deshalb an zwei Stellen an – die Lücke schließen und das Füllen verbieten.

Technische Gegenmaßnahmen

• Quellenbindung: Dem Modell werden die relevanten Dokumente mitgegeben, mit der Anweisung, ausschließlich daraus zu antworten und die Fundstelle zu nennen. Wie das aufgebaut wird, steht unter Retrieval-Augmented Generation.
• Erlaubte Unsicherheit: Die Antwort „nicht in den Quellen enthalten“ ist ausdrücklich vorgesehen und gilt als richtig, wenn die Quellen nichts hergeben.
• Strukturierte Ausgabe: Statt Fließtext liefert das Modell Felder mit Wert und Fundstelle. Ein Feld ohne Fundstelle wird automatisch als unsicher markiert.
• Nachgelagerte Prüfung: Extrahierte Werte werden gegen die Datenbank geprüft – gibt es die Bestellnummer, stimmt der Betrag, existiert der Kunde? Das Modell schlägt vor, die Regel bestätigt.
• Zweites Modell als Prüfer: Ein zweiter Aufruf bekommt Antwort und Quellen und prüft, ob jede Aussage belegt ist. Nicht perfekt, aber wirksam gegen die groben Fälle.
• Niedrige Temperatur: Der Zufallsanteil bei der Texterzeugung wird für faktische Aufgaben reduziert. Das macht Antworten reproduzierbarer, ersetzt aber keine der anderen Maßnahmen.

Organisatorische Gegenmaßnahmen

Technik senkt die Zahl der Halluzinationen, der Prozess fängt den Rest. Dazu gehören Freigabestufen: Was das System nach außen gibt – Kundenantworten, Buchungen, Vertragsauskünfte –, bestätigt ein Mensch, bis der Schattenbetrieb gezeigt hat, dass die Fehlerquote für eine Fallgruppe tragbar ist. Dazu gehört ein Rückkanal: Wer einen erfundenen Inhalt entdeckt, meldet ihn mit einem Klick, und der Fall wandert in den Testkatalog. Und dazu gehört die Regel, dass ein Modell nie die letzte Instanz für Angaben mit Rechtsfolge ist – Fristen, Beträge und Zusagen prüft ein Abgleich oder ein Mensch.

In eigenen Systemen hat sich ein weiterer Baustein bewährt: eine regelbasierte Prüfung, die jeden Entwurf vor dem Versand auf klar definierte Fehlerklassen durchsucht, etwa auf Angaben, die dort nichts zu suchen haben. Sie ist deterministisch, dauert Bruchteile einer Millisekunde und schlägt nur bei den beschriebenen Mustern an.

Halluzinationen messen

Was nicht gemessen wird, bleibt ein Gefühl. Die Messung braucht einen Testkatalog aus echten Fällen mit bekannter richtiger Antwort – darunter absichtlich Fälle, bei denen die richtige Antwort „nicht in den Quellen“ lautet. Nach jeder Änderung an Modell, Anweisung oder Wissensbasis läuft der Katalog durch, und drei Zahlen werden verglichen: Anteil korrekter Antworten, Anteil erfundener Aussagen, Anteil korrekt erkannter Wissenslücken. Sinkt die dritte Zahl, hat das System gelernt, Lücken zu füllen – ein Warnsignal, auch wenn die erste Zahl steigt.

Wir legen diesen Katalog vor dem ersten produktiven Einsatz an und lassen ihn beim Auftraggeber; er ist zugleich der Maßstab für die Abnahme, wie der Artikel Werkvertrag: Definition und Abnahme beschreibt. Ehrlich gesagt verschwindet das Problem damit nicht, es wird messbar und bleibt in einem Rahmen, mit dem sich arbeiten lässt. Die Auswahl der Gegenmaßnahmen für einen konkreten Prozess gehört zur KI-Implementierung für den Mittelstand.