LLM-Halluzinationen evaluieren: eine praktische Checkliste

Der Begriff Halluzination bündelt unterschiedliche Fehlerklassen, deshalb ist eine einzige Hallucination Rate kein belastbarer Vertrag. Closed-book Factuality fragt, ob ein Claim mit einem verifizierten externen Fakt übereinstimmt. Groundedness prüft, ob die bereitgestellte Quelle den Claim stützt. Instruction Faithfulness erkennt Abweichungen vom Input, Self-Consistency dagegen Widersprüche innerhalb derselben Antwort. Eine Antwort kann in einem falschen Dokument grounded sein oder aus dem Modellgedächtnis faktisch korrekt sein, obwohl der bereitgestellte Kontext sie nicht stützt.

Beginnen Sie mit einem Decision Contract: Szenario, Claim-Typen, zulässige Quellen, Wissensstichtag, Fehlerkosten, korrekte Abstention und die Aktion nach einem unsicheren Ergebnis. NIST verwendet für selbstbewusst präsentierten falschen Inhalt den präziseren Begriff Confabulation und betont das Risiko besonders bei langen und domänenkomplexen Antworten. Das Eval sollte den konkreten Failure Mode benennen, statt dem Modell menschliche Absicht zuzuschreiben.

• Factuality → der Claim stimmt zu einem fixierten Datum mit einem autoritativen externen Fakt überein.
• Groundedness → ein konkreter Evidence Span stützt den gesamten Scope des Claims.
• Consistency → die Antwort widerspricht weder sich selbst noch dem Gesprächsverlauf oder strukturiertem Input.
• Calibration → Confidence oder die Entscheidung zu antworten passt zur tatsächlich beobachteten Fehlerhäufigkeit.

Für kurze Fact-seeking-Aufgaben verwenden Sie Fragen mit eindeutiger, stabiler Antwort und einem Evidence Record mit URL oder Document ID, exaktem Span, Revision, verifiedAt und Reviewer. SimpleQA zeigt ein nützliches enges Design: kurze Antwort plus getrennte Verdicts für correct, incorrect und not attempted. Der Benchmark belegt jedoch weder Long-form-Qualität noch RAG-Qualität oder Ihre Domäne; ein öffentlicher Datensatz ist daher Baseline und kein Release-Zertifikat.

Ergänzen Sie eigene Slices: bekannter Fakt, seltener Fakt, mehrdeutige Frage, False Premise, Information nach dem Cutoff, veraltetes Dokument, Quellenkonflikt, No-answer und Fragen mit mehreren gültigen Formen. Für Grounded Workflows gehören supportive, irrelevant, partially supportive und contradictory Context dazu. Generieren Sie nicht alle Fragen ungeprüft aus denselben Chunks: synthetische Sets spiegeln oft die Quellsprache und machen Retrieval und Grading unrealistisch leicht.

Ein einzelner Verdict für einen Absatz verdeckt teilweise korrekte Antworten. Ein Claim Extractor sollte extern überprüfbare Aussagen, Zahlen, Daten, Entities, kausale Beziehungen und Attribution erfassen und dabei Scope und Qualifiers erhalten. Für jeden Claim liefert der Grader supported, contradicted, unverifiable oder not-in-context zusammen mit Evidence IDs. Eine vorhandene Citation ist kein Beweis: Der Span muss genau den Claim entailen und nicht nur thematisch ähnlich sein.

Messen Sie Claim Coverage, Factual Precision, unsupported critical claims und Contradiction Rate getrennt. Auch der Completeness Extractor muss kalibriert werden: übersieht er ein erfundenes Datum, wird der Downstream Score fälschlich hoch. Labeln Sie einen repräsentativen Slice manuell, messen Sie Reviewer Agreement und analysieren Sie die Disagreement Taxonomy. Ein Model Grader skaliert gut, aber Prompt, Version, Reihenfolge der Evidenz und Retry Policy gehören zum versionierten Eval und nicht in unsichtbare Infrastruktur.

Das Eval muss dem Modell einen sicheren Ausweg geben: Rückfrage stellen, unzureichende Evidenz benennen oder an einen Menschen eskalieren. Zählen Sie correct, incorrect und abstained als getrennte Outcomes und bauen Sie daraus eine Risk-Coverage-Kurve: Wie verändert sich der Fehler, wenn das System einen größeren Anteil der Anfragen beantwortet? Hohe Accuracy nach Ablehnung fast aller Fälle ist ohne Coverage wertlos; ein hoher Answer Rate kann dagegen gefährliches Raten verdecken.

Verlassen Sie sich nicht nur auf vom Modell deklarierte Confidence. Kalibrieren Sie sie auf Held-out Cases mit Reliability Bins oder Brier Score und vergleichen Sie mit einfachen Signalen wie ausreichender Evidenz, Disagreement mehrerer Samples und Verifier Verdict. Semantic Entropy untersucht Variation auf Bedeutungsebene und kann Confabulations erkennen, die Autoren grenzen sie aber von systematisch konsistenten Fehlern ab. Ein Uncertainty Detector ergänzt daher Faktprüfung, ersetzt sie aber nicht.

Vergleichen Sie Candidate und Baseline auf denselben Frozen Cases, getrennt nach Sprache, Domäne, Länge, Freshness, Quelle, Retrieval-Verfügbarkeit und Schaden eines Fehlers. Ein Gesamtscore kann durch einfache Trivia steigen, während Finanzdaten oder medizinische Qualifiers schlechter werden. Für High-risk Slices definieren Sie Critical Invariants: Keine erfundene Entity, Zahl oder Citation darf ohne Verifikation oder Human Review ins Endergebnis gelangen.

Testen Sie mehr als das Modell. Pinnen Sie Versionen von Corpus, Retriever, Search API, Prompt, Citation Resolver, Claim Extractor, Verifier und Renderer. Injizieren Sie Empty Retrieval, Stale Cache, Broken Source, Partial Document, widersprüchliche Revisions und Verifier Timeout. Ist Evidenz nicht verfügbar, darf die UI einen unverifiable Claim nicht in eine selbstbewusste Antwort verwandeln. Speichern Sie einen redacted Trace vom Input bis zum Rendering, um Retrieval Miss, Generation Defect, Grader Error und Presentation Bug zu unterscheiden.

• Dataset Health → Label Agreement, Source Freshness, Leakage und Slice Coverage.
• Answer Quality → correct, incorrect, abstained und risikogewichtete Critical Failures.
• Evidence Quality → Claim Coverage, Citation Entailment und Unsupported-claim Rate.
• Operations → Latenz, Grader Disagreement und Kosten pro verifizierter Antwort.

Der Decision Record pinnt Dataset Revision, Quellen, Modell, Prompt, Pipeline-Versionen, Primary Metric, Segment Thresholds, Critical Failures, Owner und Known-good Rollback Bundle. Promotion verlangt eine praktisch relevante paired Non-regression, das Bestehen kritischer Slices und akzeptable Kosten pro verifizierter Antwort. Deklarieren Sie weder einen universellen sicheren Threshold noch einen Modellsieg auf Basis eines Vendor Benchmarks: Quellen, Sprachen, Traffic Mix und Fehlerfolgen unterscheiden sich.

Der Rollout beginnt mit Offline Replay, geht in Shadow Evaluation, einen kleinen Canary und schließlich Risk-bounded Production über. Eine bestätigte User Correction kann nach Privacy Review zum Regression Fixture werden; ein impliziter Klick oder das Ausbleiben einer Beschwerde beweist keine Factuality. Erreicht ein kritischer Unsupported Claim den Nutzer, reduzieren Sie Coverage, deaktivieren das betroffene Modell oder die Retrieval Revision, stellen das Known-good Bundle wieder her und prüfen bereits ausgegebene Antworten, wenn die Domäne es erfordert. Production Monitoring sollte dieselbe Taxonomy wie das Offline Eval verwenden.