Intrinsische Grenzen — Fehlermodi diagnostizieren

Warum eine Landkarte statt einer Toolbox?

Halluzination, Rechenfehler und Überkonfidenz wirken wie einzelne Bugs. In der Praxis entstehen Fehlermodi aber aus mehreren Schichten: Trainingsziel und Datenabdeckung, Post-Training, Decoding sowie Aufgaben- und Systemdesign wirken unterschiedlich zusammen.

Dieses Modul ist bewusst eine Landkarte, kein Heilmittel: Es lehrt, Symptome einer Fehlerklasse zuzuordnen und die passende Kontrollklasse zu benennen. Die Umsetzung — etwa Grounding, Output-Contracts, Tooling oder Judge-Design — gehört in die Nachbartracks.

Fehlermodus — Eine wiederkehrende Klasse beobachtbarer Fehler mit ähnlicher Ursache oder Kontrollstrategie. Ein Fehlermodus ist präziser als das Sammelwort Halluzination.

Die Grenze dieses Moduls ist Diagnose, nicht eine weitere Werkzeugliste. Du beobachtest ein Symptom, veränderst kontrolliert eine Einflussgröße und ordnest den Befund einer Kontrollklasse zu. Die gleiche falsche Antwort kann aus fehlendem Wissen, schlechtem Retrieval, einer widersprüchlichen Anweisung, Decoding-Varianz oder einer ungeeigneten Aufgabe entstehen. Wer alles „Halluzination“ nennt, kann nur unspezifisch „ein besseres Modell“ fordern.

Was Next-Token-Modelle tatsächlich tun

Beim Training lernt ein Sprachmodell eine Verteilung über mögliche nächste Tokens im gegebenen Kontext. Beim Ausführen wählt oder sampelt ein Decoder daraus eine Fortsetzung. Das Ziel ist nicht selbst eine garantierte Wahrheitsprüfung und auch kein automatisch kalibrierter Pfad zum Eingestehen von Nichtwissen.

Das erklärt eine wichtige Gefahr, aber nicht jede Ursache: Datenlücken können plausible Ergänzungen auslösen; Post-Training und accuracy-lastige Evals können Raten und Abstention beeinflussen; Decoding verändert Varianz. Daraus folgt weder, dass ein Modell stets erfindet, wenn ein Fakt fehlt, noch dass ein leistungsfähigeres Modell auf jedem Eval garantiert besser ist.

Das Trainingsziel eines autoregressiven Sprachmodells belohnt wahrscheinliche Fortsetzungen. Es enthält keinen eingebauten Wahrheitsprüfer, keinen Rechner und keine Berechtigungsengine. Post-Training kann nützliches Verhalten verstärken, ändert aber nicht automatisch diese Systemgrenzen. Daraus folgt eine konstruktive Regel: Nutze das Modell für sprachliche Generalisierung und verschiebe beweisbare Eigenschaften an Komponenten, die sie tatsächlich erzwingen können.

Halluzination — Restfehler nach Schaden kontrollieren

Bei fehlender oder schwacher Faktenbasis kann das Modell eine plausible Ergänzung erzeugen. Modellwahl, Temperatur und Instruktion können die beobachtete Fehlerquote verändern, sind aber keine Wahrheitsgarantie. Auch eine niedrige Rate ist keine Zusicherung für den einzelnen kritischen Fall.

Lege Kontrollen deshalb nach Schadenshöhe und Nachweisbarkeit fest: belegte Fakten zur Laufzeit grounden, kritische Behauptungen gegen eine unabhängige Quelle prüfen und den verbleibenden Fehler auf repräsentativen Fällen testen. Ein Abstention-Pfad ist nützlich, wenn er trainiert und evaluiert wird — er entsteht nicht automatisch.

Ein Paketname, eine API-Signatur oder ein RFC-Verweis kann syntaktisch plausibel sein und trotzdem nicht existieren, eine andere Identität meinen oder die falsche Semantik haben. Syntax beweist weder Registry-Eintrag noch API-Vertrag noch den Inhalt eines RFC-Abschnitts. Bekanntheit oder Häufigkeit sind kein Vertrauensschwellenwert.

Eine zweite Aussage desselben oder eines anderen Modells ohne Quellenzugriff ist keine unabhängige Verifikation. Prüfe gegen Registry, offizielle API-Dokumentation und Originaltext. Package Confusion wird zum möglichen Angriffsvektor, wenn ein Angreifer einen unregistrierten, wiederholt halluzinierten Namen registriert — nicht durch jeden erfundenen Namen automatisch.

Bei faktischen Behauptungen trennst du Evidenzverfügbarkeit von Antwortverhalten. Fehlt eine belastbare Quelle, kann Abstention richtig sein. Ist die Quelle vorhanden, kann Retrieval sie verfehlen oder der Generator sie falsch verwenden. Eine Quellenangabe allein ist ebenfalls kein Beweis: Modelle können plausible Titel, Pakete oder URLs erzeugen. Der Verbraucher muss Referenzen gegen einen Katalog, Resolver oder Dokumentbestand prüfen.

Das robuste Ziel ist nicht „keine Halluzination“, sondern ein messbarer Prozess: belegpflichtige Aussagen, validierbare Referenzen, abgelehnte Antworten ohne ausreichende Evidenz und ein definierter Umgang mit Restfehlern. Preis: Die Abdeckungsrate sinkt; Nutzer erhalten häufiger „keine belastbare Antwort“. Diese sichtbare Lücke ist sicherer als erfundene Vollständigkeit.

Unterscheide außerdem falsche Behauptung, unbelegte Behauptung und falsche Referenz. Eine Aussage kann korrekt sein, aber ohne die für den Prozess erforderliche Evidenz trotzdem abgelehnt werden. Eine echte Quelle kann die Aussage nicht stützen. Oder die Referenz existiert gar nicht. Diese Klassen brauchen unterschiedliche Metriken: Faktentreue, Attribution und Referenzauflösung. Ein einzelnes Halluzinationslabel verwischt, welche Kontrolle versagt hat.

Auditierbare Berechnung — Eingabe und Rechnung trennen

LLMs können bei Arithmetik und mehrstufigen Aufgaben hilfreich sein; Dziri et al. untersuchten jedoch bestimmte Kompositionsaufgaben und fanden Verhalten, das mit Subgraph-Matching vereinbar ist. Das ist keine universelle Aussage, dass jedes Modell stets nur Muster abgleicht oder nie rechnet.

Wo eine auditierbare Referenzrechnung nötig ist und ein kleiner Restfehler unakzeptabel bleibt, trenne Interpretation von Berechnung: Werte erfassen, Typen, Vollständigkeit und Grenzen gegen die Quelle validieren, dann in einer deterministischen Engine rechnen und Ergebnis plus Eingaben protokollieren. Fine-Tuning ist kein Korrektheitsvertrag für ungesehene Zahlenkombinationen.

Genau fünf Elemente, Pflichtfelder, Datentypen oder Wertebereiche sind Output-Contracts: binäre, maschinenprüfbare Bedingungen für einen nachgelagerten Import. Prompting und Temperatur können Fehlerraten beeinflussen, erzwingen diese Vertragsregeln aber nicht. Modelloutput bleibt bis zur Maschinenprüfung untrusted.

Der Nachbarcheck prompt-output-format lehrt, ein gewünschtes Format im Prompt klar zu spezifizieren. Hier geht es um eine andere Diagnose: Sobald Downstream-Code binär von Kardinalität, Pflichtfeldern, Typen oder Bereichen abhängt, darf diese Grenze nicht der probabilistischen Format-Treue überlassen werden. Die konkrete Umsetzung ist ein Handoff an die Nachbartracks.

Rechnen und exakte Struktur sind verwandte, aber getrennte Grenzen. Bei einer Rechnung kann das Modell die Operation falsch ausführen; bei JSON kann die Syntax ungültig oder der Wert fachlich unzulässig sein. Program-Aided Language Models demonstrieren das Muster, sprachliche Zerlegung mit externer Programmausführung zu verbinden. In Produktion bedeutet das: Werte extrahieren, Operation als expliziten Contract darstellen, deterministisch ausführen und Ergebnis gegen Einheiten und Bereiche prüfen.

Constrained Decoding oder ein Grammar-Decoder kann nur zulässige Tokenfolgen erlauben. Das reduziert Syntaxfehler, garantiert aber keine richtige Kundennummer. Preis: Strenge Grammatik kann gültige Sonderfälle abweisen und bindet die Anwendung enger an ein Schema. Deshalb werden Parserfehler, fachliche Validierungsfehler und Autorisierungsfehler getrennt gemessen.

Kalibrierung — ein Signal wird erst mit Labels messbar

Kalibrierung fragt: Treffen Fälle mit einem Signal von etwa 0,8 auch in ungefähr 80 % der Fälle zu? Verbalisierte Selbstkonfidenz ist oft überkonfident und darf nicht roh als Gate dienen. Ton und Detailgrad sind ebenfalls keine hinreichenden Korrektheitssignale.

Ein modellinternes oder modellabgeleitetes Signal kann nützlich sein, wenn es modell- und aufgabenspezifisch gegen repräsentative Labels kalibriert oder überwacht ist. Prüfe Trefferquoten je Bin, setze die Schwelle auf diesen Daten und überwache die Beziehung unter Drift. Die Güte wird extern gemessen, das Signal muss nicht extern entstehen.

Ein ausgegebener Prozentwert ist erst dann ein nutzbares Konfidenzsignal, wenn seine Beziehung zu realen Treffern auf repräsentativen Labels gemessen wurde. Kalibrierung fragt beispielsweise, ob Fälle mit vorhergesagten 80 Prozent tatsächlich ungefähr in acht von zehn Fällen korrekt sind. Ohne diese Messung ist 0.92 nur Text oder ein unkalibrierter Score. Ein Gate braucht zusätzlich die Kosten falscher Annahme und falscher Ablehnung.

Kalibrierung kann nach Modell, Prompt, Sprache, Fallklasse und Zeit variieren. Ein globaler Schwellenwert kann seltene Hochrisikofälle verdecken. Empfehlung: Kalibrierungskurven und Fehler nach Segmenten beobachten. Nachteil: Für kleine Segmente fehlen oft Labels; dann muss das System konservativer eskalieren, statt Scheingenauigkeit aus wenigen Beobachtungen abzuleiten.

Ein Schwellenwert wird gegen konkrete Kosten optimiert. Bei einem lesenden Tipp kann eine falsche Ablehnung bloß lästig sein; bei einer automatischen Sperre ist eine falsche Annahme wesentlich teurer. Deshalb kann dasselbe kalibrierte Signal je Aktion zu verschiedenen Gates führen. Dokumentiere Population und Zeitraum, auf denen die Kurve entstand. Bei Modell-, Prompt- oder Query-Drift wird neu gemessen. Der Preis konservativer Schwellen ist geringere Automatisierungsabdeckung.

Sycophancy — Nutzermeinung als Confound behandeln

Eine signalisierte Nutzermeinung kann die Antwort verfälschen: Zustimmung ist dann kein Beleg für Wahrheit. Forschung zu RLHF-Modellen zeigt, dass menschliche Präferenzen teilweise zu Sycophancy beitragen können; sie belegt keine einzige, universelle Ursache.

Formuliere Fragen prämissen-neutral und teste bedeutungsgleiche Gegenframings. Ein Eval-Prompt ist ein Messinstrument: Robustheit heißt, dass das Urteil bei semantisch gleichem Gegenframing invariant bleibt. Neutralität verbessert die Messung, garantiert aber keine wahre Antwort.

Sycophancy bezeichnet beobachtetes Zustimmen mit einer im Prompt ausgedrückten Nutzermeinung, obwohl eine neutrale oder gegenteilige Antwort sachlich besser wäre. Sharma und Kollegen fanden dieses Verhalten in mehreren untersuchten Assistenzmodellen und zeigten einen Zusammenhang mit menschlichen Präferenzdaten. Ein Test variiert deshalb die behauptete Meinung bei gleicher Sachfrage. Ändert sich das Urteil systematisch, ist die Nutzerhaltung ein Confound.

Die Kontrolle ist nicht bloß ein härterer Systemprompt. Nutze neutral formulierte Testfälle, verlange Evidenz vor Zustimmung und trenne Datenerhebung von Entscheidung. Preis: Ein Assistent wirkt weniger bestätigend und kann mehr Rückfragen stellen. In fachlichen oder sicherheitsrelevanten Prozessen ist diese Reibung ein gewollter Teil der Unabhängigkeit.

Positions-Bias — Diagnose und Übergabe, nicht Freigabe

Kippt ein LLM-Judge sein Urteil, wenn nur A und B vertauscht werden, ist die Messung nicht invariant gegenüber einer sachlich irrelevanten Variable. Quantifiziere Swap-Konsistenz und Ausmaß auf repräsentativen Fällen. Der Judge ist damit noch nicht freigabefähig.

Aus dem Kipp-Effekt folgt weder eine bewiesene Ursache in Training oder Attention noch eine garantierte Heilung durch ein größeres Judge-Modell. Größere Modelle können einzelne Evals verbessern. Das Kontrolldesign und die Validierung gegen Referenzlabels gehören in den evaluation-Track.

LLM-as-a-Judge spart menschliche Bewertung, kann aber eigene Positions- und Stilpräferenzen einbringen. Wang und Kollegen zeigten, dass bereits das Vertauschen zweier Kandidaten die Bewertung beeinflussen kann. Eine einfache Diagnose bewertet beide Reihenfolgen und behandelt widersprüchliche Urteile als Unsicherheit. Zusätzlich braucht ein Judge eine feste Rubrik und menschlich gelabelte Ankerfälle.

Ein Judge darf nicht zugleich Generator und alleinige Freigabestelle für denselben Fehlermodus sein. Korrelation zwischen beiden Modellen kann Fehler verdecken. Preis: Gegenreihenfolge, mehrere Judges oder menschliche Stichproben erhöhen Kosten. Sie kaufen jedoch ein messbares Urteil statt einer zweiten plausiblen Textausgabe, die nur wie Kontrolle aussieht.

Meta-Triage — kontrolliert variieren, dann zuordnen

Eine Diagnose braucht kontrollierte Vergleiche. Beispiel: Ein Alert-Klassifizierer erhält zwei bedeutungsgleiche Incident-Beschreibungen, bei denen nur Satzbau und Synonyme variieren; Datenquelle, Modell, Decoding und Soll-Label bleiben gleich. Unterschiedliche Labels zeigen Empfindlichkeit gegenüber der Formulierung, beweisen aber noch keine interne Ursache.

Teste andere Hypothesen in getrennten Paaren und ändere wieder nur einen Faktor. Halte Eingabevarianten, Soll-Labels und Reaktion fest; erst eine gezielte Folgeintervention stärkt oder verwirft die Arbeitshypothese. Ändern sich Modell, Kontext und Prompt zugleich, ist der beobachtete Effekt nicht mehr sauber zuordenbar.

Meta-Triage arbeitet mit minimalen Gegenexperimenten. Bleibt ein Fehler bei besserer Quelle bestehen, untersuche Generierung oder Contract. Verschwindet er bei deterministischer Rechnung, lag die Aufgabe außerhalb der verlässlichen Rechenleistung. Kippt ein Judge beim Tausch der Position, liegt Bewertungs-Bias nahe. Ändert sich eine Antwort mit der behaupteten Nutzermeinung, teste Sycophancy. Dieses Vorgehen erzeugt Evidenz für die nächste Maßnahme.

Ein Gegenexperiment darf die Aufgabe nicht unbeabsichtigt verändern. Beim Positionstausch bleiben Kandidatentexte identisch; beim Sycophancy-Test wechselt nur die behauptete Nutzermeinung; beim Retrieval-Test bleibt die Generatoranweisung gleich. Sonst ist der Befund mehrdeutig. Diese Disziplin ähnelt klassischem Incident-Debugging: Hypothese, minimale Intervention, beobachtetes Ergebnis und nächster Test werden dokumentiert. Sie kostet zusätzliche Runs, spart aber zufällige Produktionsänderungen.

Kontrollklassen statt Universal-Guardrail

Fehlende oder erfundene Evidenz

Grounding, Referenzauflösung, Abstention

Rechnung oder harte Invariante

Externe deterministische Ausführung

Ungültige Struktur

Constrained Decoding plus Schema- und Fachvalidierung

Unkalibrierte Sicherheit

Gelabeltes Kalibrierungsset und risikobasierter Schwellenwert

Sycophancy oder Judge-Bias

Gegenvarianten, Positionswechsel und unabhängige Anker

Die Tabelle ist keine Garantie. Jede Kontrolle hat einen eigenen Fehlermodus: Retrieval kann falsche Dokumente liefern, Code kann mit falschen Einheiten rechnen, ein Schema kann fachlich falsche Werte akzeptieren und ein Kalibrierungsset kann veralten. Darum bleibt die Kontrollkette beobachtbar und versioniert. Defense in Depth bedeutet hier nicht viele zufällige Filter, sondern unabhängige Kontrollen für benannte Fehlerklassen.

Die Kontrollmatrix gehört in Runbook und Telemetrie. Für jede Fehlerklasse stehen Erkennungssignal, unmittelbare sichere Reaktion, zuständiger Owner und Regressionstest fest. So wird aus einem bekannten Modelllimit ein behandelbarer Betriebszustand. Nachteil: Manche Fehler bleiben erst durch menschliche Stichproben sichtbar. Das ist kein Grund, sie nicht zu messen, sondern eine Kapazitätsanforderung an das Kontrollsystem.

Worked Example: erfundene Paketabhängigkeit

Gleich im Check diagnostizierst du acht solcher Situationen. Beginne jeweils beim beobachtbaren Symptom, nicht beim Lieblingswerkzeug. Die richtige Maßnahme nennt neben ihrem Gewinn auch ihren Preis: weniger Abdeckung, zusätzliche Laufzeit, mehr Labels oder mehr menschliche Prüfung.

Gleich entscheidest du diese Achsen selbst

In den nächsten acht Entscheidungen ordnest du Symptome einer Fehlerklasse und einer Kontrollklasse zu: Restfehler nach Schaden absichern, Referenzen belegen, Rechen- und Output-Grenzen validieren, Signale kalibrieren sowie Bias und Fehl-Diagnosen sichtbar machen.

• Halluzination: Modellwahl ergänzen, Referenzen gegen Primärquellen prüfen
• Auditierbarkeit: validierte Inputs, deterministische Rechnung, Output-Contract fail-closed
• Kalibrierung und Bias: Signale gegen Labels messen, Confounds und Swap-Instabilität diagnostizieren
• Meta-Triage: Kontrollvarianten und Labels vor einem gruppenweiten Eingriff

Der wichtigste Transfer besteht darin, Selbstsicherheit nicht mit Evidenz zu verwechseln. Eine flüssige Erklärung, ein Prozentwert oder ein zweiter Modellkommentar bleiben Modelloutputs. Belastbar werden sie erst durch externe Quelle, deterministische Prüfung oder gelabelte Messung. Der Preis unabhängiger Evidenz ist zusätzliche Infrastruktur; ohne sie besitzt das System nur mehrere korrelierte Meinungen.

Im Check zählt daher die Zuordnung von Symptom, Evidenz und Kontrolle — nicht die Zahl aufgezählter Guardrails.

Jede Kontrolle wird danach gegen denselben reproduzierten Fehlerfall und benachbarte Regressionen geprüft.