Die intrinsischen Grenzen — eine Landkarte der Fehlermodi
Einführung · 9 Abschnitte · ~8 Min Lesezeit · Stand
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.
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.
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.
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.
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.
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.
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.
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.
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