Wie viele Antworten Ihr System erfindet — und wie Sie es herausfinden

TL;DR

Halluzination ist im RAG-Kontext messbar: Der Anteil der Aussagen einer Antwort, der sich nicht aus den abgerufenen Abschnitten belegen lässt. Drei Verfahren taugen für den Betrieb — ein Modell als Prüfer, Selbstkonsistenz über mehrere Läufe, und die Auswertung der Token-Wahrscheinlichkeiten. Das letzte ist das billigste und wird am seltensten genutzt.

Die Frage richtig stellen

"Halluziniert unser System?" ist keine beantwortbare Frage. "Wie viel Prozent der Aussagen in den Antworten der letzten Woche lassen sich aus den abgerufenen Abschnitten belegen?" ist eine.

Der Unterschied ist nicht sprachlich. Bei einem RAG-System gibt es einen definierten Bezugspunkt: die abgerufenen Textabschnitte. Eine Aussage ist entweder darin gedeckt oder nicht. Das ist eine mechanisch prüfbare Eigenschaft, anders als "ist die Antwort wahr".

Diese Einschränkung sollte man aussprechen: Sie messen Treue zur Quelle, nicht Wahrheit. Wenn im abgerufenen Dokument etwas Falsches steht und das Modell es korrekt wiedergibt, ist die Antwort treu und falsch. Für ein Unternehmenssystem ist Treue trotzdem die richtige Zielgröße — die Richtigkeit der Dokumente ist ein anderes Problem, und zwar eines des Qualitätsmanagements.

Verfahren 1: ein Modell als Prüfer

Das gängigste Verfahren. Sie zerlegen die Antwort in einzelne Aussagen und lassen für jede prüfen, ob sie aus dem Kontext folgt.

PRUEF_PROMPT = """Du prüfst, ob eine Aussage durch den Kontext gedeckt ist.

Kontext:
{kontext}

Aussage: {aussage}

Antworte mit genau einem Wort:
GEDECKT   — die Aussage folgt direkt aus dem Kontext
TEILWEISE — Teile folgen, andere nicht
UNGEDECKT — die Aussage steht nicht im Kontext oder widerspricht ihm"""


def treue_bewerten(antwort: str, kontext: str, judge) -> float:
    aussagen = in_aussagen_zerlegen(antwort, judge)
    if not aussagen:
        return 1.0
    punkte = {"GEDECKT": 1.0, "TEILWEISE": 0.5, "UNGEDECKT": 0.0}
    ergebnisse = [
        punkte.get(
            judge(PRUEF_PROMPT.format(kontext=kontext, aussage=a),
                  temperature=0).strip().upper(),
            0.0,
        )
        for a in aussagen
    ]
    return sum(ergebnisse) / len(ergebnisse)

Drei Punkte aus der Praxis, die über die Brauchbarkeit entscheiden:

Temperatur auf 0. Sonst schwanken die Bewertungen zwischen Läufen, und Sie können Änderungen nicht mehr von Rauschen unterscheiden.

Die Zerlegung in Aussagen ist der schwierige Teil. Ein Satz kann drei Aussagen enthalten. Wenn die Zerlegung schlecht ist, ist die ganze Messung schlecht. Prüfen Sie an zwanzig Beispielen von Hand, ob die zerlegten Aussagen sinnvoll sind, bevor Sie den Zahlen glauben.

Ein anderes Modell als Prüfer. Ein Modell, das seine eigene Antwort bewertet, ist zu nachsichtig. Nehmen Sie ein anderes — gern ein kleineres, das kostet weniger und urteilt bei dieser eng gestellten Aufgabe kaum schlechter.

Die Kosten sind der Haken: Bei fünf Aussagen pro Antwort und 1.000 Antworten am Tag sind das 5.000 zusätzliche Modellaufrufe. Deshalb messen Sie im Betrieb an einer Stichprobe, nicht an allem — 2 bis 5 Prozent der Anfragen reichen für eine belastbare Rate.

Verfahren 2: Selbstkonsistenz

Die Idee ist unaufwendig: Dieselbe Frage dreimal mit einer Temperatur über null beantworten lassen. Widersprechen sich die Antworten inhaltlich, war das Modell unsicher.

Das funktioniert erstaunlich gut für Zahlenangaben. Wenn ein System auf die Frage nach dem Prüfintervall dreimal "5 Jahre" sagt, ist die Zahl vermutlich im Kontext gefunden. Wenn es "5 Jahre", "alle zwei Jahre" und "je nach Behältergröße" sagt, hat es geraten.

Der Preis ist offensichtlich: dreifache Kosten und dreifache Latenz. Deshalb ist das kein Verfahren für den laufenden Betrieb, sondern eines für gezielte Untersuchungen — etwa vor der Freigabe eines neuen Anwendungsfalls.

Verfahren 3: Token-Wahrscheinlichkeiten — das übersehene

Der billigste Weg, und er wird fast nie genutzt: Die meisten Modell-APIs liefern auf Anforderung die Wahrscheinlichkeiten der erzeugten Token mit. Niedrige Wahrscheinlichkeit bei inhaltstragenden Token — Zahlen, Eigennamen, Fachbegriffe — ist ein brauchbares Signal für Unsicherheit.

antwort = client.chat.completions.create(
    model="standard",
    messages=nachrichten,
    logprobs=True,
    top_logprobs=1,
)

import math

unsichere = [
    (t.token, round(math.exp(t.logprob), 3))
    for t in antwort.choices[0].logprobs.content
    # Zahlen und Großgeschriebenes tragen den Inhalt
    if math.exp(t.logprob) < 0.5 and (t.token.strip()[:1].isdigit()
                                      or t.token.strip()[:1].isupper())
]

Was das kostet: nichts. Die Wahrscheinlichkeiten fallen bei der Erzeugung ohnehin an, Sie lassen sie sich nur mitgeben.

Was es leistet: kein Ersatz für Verfahren 1, aber ein hervorragender Auslöser. Antworten mit auffällig unsicheren Zahlen schicken Sie in die teure Prüfung, alle anderen nicht. Damit messen Sie dort genau, wo es sich lohnt.

Die Grenze ehrlich benannt: Ein Modell kann sehr sicher etwas Falsches sagen. Niedrige Wahrscheinlichkeit ist ein Hinweis auf Unsicherheit, hohe Wahrscheinlichkeit kein Beleg für Richtigkeit. Und nicht jeder Anbieter liefert die Werte — bei manchen Modellen ist die Option nicht verfügbar.

Der Aufbau, den wir empfehlen

Gestuft, damit die Kosten tragbar bleiben:

1. Alle Antworten: Token-Wahrscheinlichkeiten mitschreiben, Antworten mit unsicheren Zahlen markieren. Kostet nichts.
2. Markierte plus 3 Prozent Zufallsstichprobe: Prüfung durch ein Modell auf Treue. Kostet überschaubar.
3. Wöchentlich 20 Antworten von Hand: Eine Person aus der Fachabteilung schaut sie an. Das ist der Kalibrierungspunkt — ohne ihn wissen Sie nicht, ob Ihre automatische Bewertung überhaupt misst, was Sie meinen.

Punkt 3 wird gern gestrichen, und dann driften die automatischen Werte ab, ohne dass es jemand merkt. Zwanzig Antworten sind eine halbe Stunde pro Woche.

Wie die Bewertung im Zusammenspiel mit den Abrufkennzahlen aussieht, steht im Beitrag zur Messung der RAG-Qualität.

Was Sie tun, wenn die Rate zu hoch ist

Eine Treue unter 0,85 ist ein Handlungssignal. Die Ursachen liegen fast nie beim Modell:

Der Abruf liefert nichts Passendes, und das Modell antwortet trotzdem. Der häufigste Fall. Die Lösung ist eine Systemanweisung, die "weiß ich nicht" ausdrücklich erlaubt, plus ein Schwellenwert für die Ähnlichkeit: Liegen alle Treffer darunter, gar nicht erst das Modell fragen.

Der Kontext ist zu groß. Bei 30 abgerufenen Abschnitten verliert das Modell den Bezug und mischt Informationen aus verschiedenen Dokumenten. Weniger, dafür bessere Treffer — das ist die Aufgabe eines Rerankers.

Die Frage ist mehrteilig. "Welches Intervall gilt und wer gibt die Änderung frei" — wenn nur eine Hälfte im Kontext steht, erfindet das Modell die andere, statt sie offen zu lassen.

Häufig gestellte Fragen

Was genau misst man, wenn man Halluzinationen misst?

Bei einem RAG-System die Treue zur Quelle: den Anteil der Aussagen einer Antwort, der sich aus den abgerufenen Abschnitten belegen lässt. Nicht gemessen wird die Wahrheit der Aussage — steht im Dokument etwas Falsches und das Modell gibt es korrekt wieder, ist die Antwort treu und trotzdem inhaltlich falsch. Die Richtigkeit der Quellen ist ein Thema des Qualitätsmanagements.

Kann ein Modell seine eigenen Antworten bewerten?

Technisch ja, mit systematischer Verzerrung. Modelle beurteilen eigene Ausgaben nachsichtiger als fremde. Verwenden Sie deshalb ein anderes Modell als Prüfer — ein kleineres reicht, weil die Prüfaufgabe eng gestellt ist und deutlich weniger Fähigkeiten verlangt als die ursprüngliche Beantwortung.

Was ist eine akzeptable Halluzinationsrate?

Das hängt vom Anwendungsfall ab. Für eine interne Wissenssuche, bei der Quellen mitangezeigt werden und Nutzer nachschlagen können, sind Treuewerte um 0,90 üblich und tragbar. Für Antworten, die ungeprüft nach außen gehen oder Grundlage einer Entscheidung sind, reicht das nicht — dort brauchen Sie zusätzlich eine menschliche Freigabe, keine bessere Kennzahl.

Sind Token-Wahrscheinlichkeiten ein verlässliches Signal für Halluzination?

Als Hinweis ja, als Beleg nein. Eine niedrige Wahrscheinlichkeit bei einer Zahl oder einem Eigennamen deutet auf Unsicherheit hin und eignet sich gut, um Antworten für eine genauere Prüfung auszuwählen. Umgekehrt gilt es nicht: Ein Modell kann eine erfundene Angabe mit hoher Wahrscheinlichkeit erzeugen. Nutzen Sie es als Auslöser, nicht als Bewertung.

Wie oft sollte man die Antwortqualität überprüfen?

Automatisch fortlaufend an einer Stichprobe von wenigen Prozent, manuell wöchentlich an etwa zwanzig Antworten. Die manuelle Prüfung ist der Kalibrierungspunkt: Sie zeigt, ob die automatische Bewertung noch misst, was fachlich gemeint ist. Ohne sie driften die Werte ab, ohne dass es auffällt.

Der nächste Schritt

Schalten Sie die Token-Wahrscheinlichkeiten in Ihren Modellaufrufen ein und schreiben Sie sie mit. Das kostet nichts, ist in einer Stunde erledigt und gibt Ihnen die Grundlage, um gezielt dort genauer zu messen, wo es sich lohnt. Beim Aufbau der Bewertungskette unterstützen wir gern.