Konfidenz-Gating und Eskalation an einen Menschen

Die vorherige Seite argumentierte, dass Code den Schwellenwert besitzen sollte. Diese Seite handelt davon, was der Schwellenwert teilt — die drei Bänder auf beiden Seiten.

Drei Bänder, nicht zwei

Echte Projekte machen selten „automatisch oder nicht” daraus. Drei Bänder sind die übliche Form:

Das dritte Band ist leicht zu übersehen und ist das billigste der drei. „Nicht angeschaut” und „eine Person wirft einen Blick darauf” unterscheiden sich um einen Menschen.

Eine Triage-Implementierung ist typisch: alarmiere nur, wenn P(SEV1) + P(SEV2) ≥ 0.80; verwerfe unterhalb von 0.20 nur, wenn eine Umsetzbarkeitsprüfung ebenfalls widerspricht; schicke das mittlere Band an einen Menschen.

Das mittlere Band ist, wo die eigentlichen Probleme leben

Sobald die drei Bänder existieren, wandert jede schwierige Frage in das mittlere:

Es ist menschliche Kapazität, keine freie Kapazität. Je breiter das Band, desto mehr Eskalationen, desto mehr bearbeitet eine Person. Eine Eskalationsrate von 9% klingt niedrig — bis die Basisrate Tausende pro Tag beträgt.

Es braucht eine Absicherung, sonst bleibt es still hängen. Sobald du eine Entscheidung an einen Menschen übergibst, passiert nichts, bis ein Mensch hinschaut. Auf einem Dashboard sieht das genauso aus wie „alles ist in Ordnung”. Die Antwort des Triage-Tools ist unverblümt: keine Bestätigung innerhalb von 15 Minuten, alarmiere trotzdem. Besser jemanden wecken, als einen P1 in einer Warteschlange liegen zu lassen.

Die Eskalationsbedingung selbst kann fehlschlagen. Ein Autonomie-Gate innerhalb eines Agenten fährt nur fort, wenn ein Choice 0.6 überschreitet und ein Autonomie-Sicherheits-Noul 0.5 überschreitet, andernfalls geht die Runde zurück an den Menschen. Beide Zahlen müssen bestehen — weil „was soll ich tun” und „ist das sicher” getrennte Fragen sind, und eine einzige Konfidenz kann beide nicht ehrlich beantworten.

Den Schwellenwert setzen: erst messen

0.8 aus der Luft zu greifen ist der häufigste Ansatz und der, der drei Monate später am wahrscheinlichsten zu Rauschen wird. Der reproduzierbare Ansatz ist, auf deinen eigenen gelabelten Daten den Schwellenwert zu messen, der nötig ist, um deine Zielgenauigkeit zu erreichen.

Ein öffentliches Beispiel: Mit 0.7 als Niedrigkonfidenz-Gate fing ein Lauf über n=130 3 von 3 Fehlklassifikationen bei einer Eskalationsrate von 9%. Die Stichprobe ist klein. Ihr Wert ist nicht die 0.7 — sondern dass dies die Art ist, wie eine solche Zahl berichtet werden sollte: Stichprobengröße, Eskalationsrate und was abgefangen wurde.

Latenz ist das unterschätzte Risiko

Die gemessenen Zahlen des Triage-Tools verdienen eine eigene Tabelle:

p95 ist 3.5× p50. Das heißt, der Tail ist wichtiger als der Durchschnitt — denn die Timeout-Politik feuert im Tail, und wenn sie feuert, bist du auf dem Fallback-Zweig, nicht auf dem, den du entworfen hast. Der langsamste Aufruf lag 151 ms vor dem Timeout, was heißt: Der Determinismus des Systems hing von einer Münze ab, die zufällig nicht schlecht gefallen ist.

Also scheitern Gating-Systeme meist nicht durch „falsch urteilen”, sondern durch Timeout und Fallback nehmen. Teste den Fallback unabhängig vom Hauptpfad.

Zwei Fallback-Richtungen, beide richtig

Wenn etwas fehlschlägt, teilen sich öffentliche Implementierungen in zwei Lager, und beide haben recht:

• fail-closed: Ein Berechtigungs-Judge verweigert bei Timeout oder Fehler. Ein Sicherheits-Gate muss so funktionieren — ein fail-openes Sicherheits-Gate ist ein stilles Loch.
• fail-open: Ein Claude Code Stop-Hook erlaubt bei jedem Fehler. Ein Effizienz-Gate muss so funktionieren — ein fail-closedes Effizienz-Gate blockiert den ganzen Ablauf.

Das Kriterium ist nicht „welches ist sicherer”, sondern welche Kosten größer sind: eine fälschliche Blockierung oder eine verpasste Blockierung. Und es muss entschieden werden, wenn du den Code schreibst, denn was es bestimmt, ist der Ausnahmepfad, nicht der Hauptpfad.

In einem Satz

In einem Drei-Band-Design steckt die Arbeit im mittleren Band: seine Breite ist Kosten, seine Absicherung ist eine Zuverlässigkeitseigenschaft. Entwirf beide ausdrücklich, statt sie per Default zu lassen.