# Vom Pilotbetrieb zum Gate
Typ: Checkliste
Herkunft: prompt-engineering / prompt-capstone / capstone-eval-gate
Version: capstone-eval-gate-2026-09-04
Geprüft: 2026-09-04

ACHTUNG: Dieses Dokument ist ein Lernartefakt aus einer Schulungssequenz. Es ist kein produktives Runbook. Vor jeder Anwendung in einer realen Umgebung müssen die Schritte gegen lokale Dokumentation, Runbooks und Freigabestatus geprüft werden.

## Szenario
Der Pilotbetrieb läuft zwei Wochen und erzeugt Fehlantworten, Enthaltungen und Beschwerden. Danach soll ein Gate stehen, das jede Prompt-Änderung vor der Auslieferung bewertet. Zeit ist knapp, und der Pilotbetrieb ist nur einmal verfügbar.

## Schritte
1. Fehlantworten und Beschwerden aus dem Pilotbetrieb einsammeln, solange er läuft.
2. Die gesammelten Fälle nach Fehlerarten benennen und gruppieren.
3. Testfälle mit Sollwerten anlegen — Fehlerfälle, Grundlast, Gegenfälle und Fälle mit Abwesenheit.
4. Das Set mehrfach ohne Änderung laufen lassen, um die normale Schwankung zu messen.
5. Die Gate-Schwelle über die gemessene Schwankung legen und einen Teil der Fälle zurückhalten.

## Begründung
Warum: Ein Gate ruht auf einer Kette: Fälle aus echten Vorfällen, benannte Fehlerarten, Sollwerte in beiden Richtungen und eine gemessene Schwankung — eine Schwelle ohne diese Grundlage erzeugt entweder Fehlalarme oder lässt Regressionen durch.
Folgen: **+** Das Gate ist begründet, bleibt scharf und macht künftige Änderungen und einen Modellwechsel überhaupt erst bewertbar. **−** Die Kette braucht Wochen, bevor sie zum ersten Mal etwas verhindert — und der Pilotbetrieb muss von Anfang an aufs Einsammeln ausgelegt sein, sonst ist die beste Fallquelle nach zwei Wochen vorbei.

## Quellen
1. Miller, Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations, 2024 — https://arxiv.org/abs/2411.00640
2. Röttger et al., XSTest: A Test Suite for Identifying Exaggerated Safety Behaviours in Large Language Models, NAACL 2024 — https://arxiv.org/abs/2308.01263