Kann man den Wahrscheinlichkeiten trauen?

Diese Seite beantwortet eine Frage: kann man diesen Konfidenzwerten trauen?

Das Fazit vorweg: „die Form der Ausgabe ist garantiert” und „die Wahrscheinlichkeit ist genau” sind zwei völlig verschiedene Behauptungen. Die erste wurde aus mehreren Richtungen verifiziert. Die zweite wird öffentlich bestritten. Wer ein Entscheidungsmodell hinter ein Produktions-Gate stellt, sollte die vom Anbieter oder Projekt berichtete Konfidenz als einen zu kalibrierenden Prior behandeln, nicht als Garantie.

Was Kalibrierung ist

Ein Modell sagt „ich bin mir zu 80 % sicher”. Wenn du alles sammelst, was es mit 80 % gesagt hat, und genau 80 % davon richtig sind, ist die Zahl kalibriert. Wenn weniger richtig sind, ist es überkonfident.

Die übliche Metrik ist ECE (Expected Calibration Error): Ordne die Vorhersagen nach Konfidenz in Bins, vergleiche die durchschnittliche Konfidenz jedes Bins mit seiner tatsächlichen Genauigkeit und nimm den nach Bin-Größe gewichteten Durchschnitt. Niedriger ist besser.

Kalibrierung und Genauigkeit sind unabhängige Achsen. Ein sehr genaues Modell kann stark überkonfident sein (besonders auf dem schwierigsten Ausschnitt), und ein mittelmäßiges Modell kann gut kalibriert sein. Beides wirst du unten sehen.

Lösung 1: Temperatur-Skalierung

Die billigste und allgemeinste Lösung. Die Idee: Die Reihenfolge der Optionen des Modells stimmt meistens, aber die Skala ist falsch — Überkonfidenz bedeutet, dass alles zu nah an 0 und 1 liegt. Ein einziger Temperaturparameter, auf einem Holdout angepasst, flacht die Verteilung ab oder schärft sie.

Ein Replikat, das eine ausführbare Offline-Evaluierung mitliefert, berichtet:

Temperatur-Skalierung plus konforme Abstinenz bringt die ECE von 0.170 auf 0.071 (kreuzvalidiert).

Beachte „kreuzvalidiert”: Es wurde nicht auf denselben Daten angepasst und evaluiert. Das ist der Unterschied zwischen einer Zahl, der man trauen kann, und einer, der man nicht trauen kann.

Lösung 2: konforme Abstinenz

Temperatur-Skalierung behebt die Skala. Konforme Methoden entscheiden, wann nicht geantwortet wird.

Statt jede Wahrscheinlichkeit korrekt zu machen, erzeugen sie ein Abstinenz-Set und garantieren, dass die wahre Antwort mindestens in einem angegebenen Bruchteil der Fälle darin liegt (eine Abdeckungsgarantie). Fälle, die die Hürde nicht schaffen, werden eskaliert statt automatisch verarbeitet.

In echten Projekten:

• Eine offene 118M-Alternative nutzt Temperatur-Skalierung plus ein Split-Conformal-Abstain-Set und meldet ECE 0.01–0.03 auf öffentlichen Suiten — während sie unumwunden erklärt, dass sie bei Benchmarks für typisierte Entscheidungen gegen Laya verliert (0.71 vs. 0.77). Ein Projekt, das seine Niederlagen veröffentlicht, ist aussagekräftiger als eines, das nur Siege veröffentlicht.
• Eine medizinische Implementierung nutzt zwei eingefrorene lokale Reader plus einen anpassungsfreien Router und ein Split-Conformal-Kandidatenset, um den Fehler zu begrenzen, und landet bei drei nationalen Lizenzprüfungen mit je 600 Aufgaben innerhalb von 2 Punkten des gehosteten Dienstes, ohne Fine-Tuning und ohne Destillation.

Was beide gemeinsam haben: Keines behauptet, die Wahrscheinlichkeiten seien genau geworden. Sie behaupten zu wissen, wann sie es nicht sind. In einem echten System ist Letzteres das, worauf man ein Gate stützen kann.

Ein kontraintuitives unabhängiges Ergebnis: die Verzerrung hat entgegengesetzte Vorzeichen

Ein unabhängiger Kalibrierungstest nutzte 900 regelgenerierte Tickets (die das Modell unmöglich gesehen haben kann) plus drei öffentliche Benchmarks, veröffentlichte jede Rohantwort und eine ECE gegen einen simulierten Rauschboden und kam zu einem Schluss über das Vorzeichen:

Der Wert liegt im Vorzeichen. Wäre die Verzerrung zufällig, würde eine globale Temperatur sie beheben. Entgegengesetzte Richtungen bedeuten, dass eine einzige globale Korrektur das nicht kann — du musst mindestens pro Primitiv kalibrieren.

Es erklärt auch einen konkreten Designfehler: Wenn ein System Noul- und Choice-Konfidenzen gegen denselben Schwellenwert vergleicht, misst es dasselbe mit einem Lineal, das zu kurz ist, und einem anderen, das zu lang ist.

Die Eingabesprache beeinflusst die Kalibrierung ebenfalls

Eine weitere Messung, auf einem spanischen Korpus mit 3.200 menschlich gelabelten Elementen:

Den Zustand auf Spanisch zu schreiben kostete 3.0–6.4 Genauigkeitspunkte und verdoppelte ungefähr die ECE bei XNLI / PAWS-X, während das Schreiben der Anweisungen auf Spanisch keinen Effekt hatte.

Der Zustand/Anweisung-Unterschied ist der Punkt: Der Zustand ist Inhalt, die Anweisungen sind Metadaten. Das ist besonders für chinesische und japanische Leser wichtig — ihre Zustände werden sehr wahrscheinlich einen ähnlichen Weg nehmen, und niemand hat eine Messung davon veröffentlicht. Es gibt keinen Grund anzunehmen, dass es in deiner Sprache nicht passiert.

Wie wird der Schwellenwert also gewählt?

Alles oben läuft auf dieselbe Frage hinaus: Woher kam diese 0.8?

Die reproduzierbare Antwort ist messen, nicht raten: Nimm deine eigenen gelabelten Daten, passe den Schwellenwert pro Frage an, der deine Zielgenauigkeit erreicht, und validiere ihn auf einem Holdout.

Ein Werkzeug macht genau das und fügt den Schritt hinzu, der am wichtigsten ist: es lässt die CI fehlschlagen, wenn ein Modell-Update einen festgeschriebenen Schwellenwert bricht. Schwellenwerte laufen ab wie Preise — außer dass ein falscher Preis auffällt und ein falscher Schwellenwert nicht.

In einem Satz

Behandle Konfidenz als Prior, nicht als Garantie. Miss zuerst das vertrauenswürdige Band auf deinen eigenen Daten, und schreibe dieses Band dann in Code.