# Qualität & menschliche Kontrolle > Repräsentative Testsets, Akzeptanzschwellen, Regressionen, Produktionsstichproben und risikobasierte menschliche Aufsicht als gemeinsames Kontrollsystem. Track: [AI-Grundlagen für den IT-Betrieb](https://physar.tech/learn/ai-foundations) Kanonische Fassung: https://physar.tech/learn/ai-foundations/quality-measurement Stand: 2026-09-04 Interaktiver Teil: 9 Checks (nur im Browser) ## Qualität & menschliche Kontrolle ### Das Problem mit dem Bauchgefühl Bei klassischer Software merkst du, ob sie funktioniert: Sie läuft oder wirft einen Fehler. Ein Sprachmodell wirft keinen Fehler. Es liefert immer eine flüssige, überzeugend formulierte Antwort — auch dann, wenn sie falsch ist. Deshalb entsteht bei LLM-Projekten regelmäßig dasselbe Muster: Man probiert ein paar Beispiele, ist beeindruckt, geht in Produktion — und weiß Monate später immer noch nicht, wie gut das System eigentlich ist. Der Ausweg ist unspektakulär: **eine feste Menge von Beispielen mit bekannter richtiger Antwort.** _[Abbildung: Ohne Messpunkt gibt es keine Regelschleife: Ändern, messen, vergleichen, entscheiden — in dieser Reihenfolge.]_ **Evaluation:** Eine vorab definierte Messung von Systemverhalten auf benannten Fällen, mit Referenz, Rubrik oder beobachtbarem Erfolgskriterium. Eine Demo beantwortet „Kann es einmal funktionieren?“. Eine Evaluation beantwortet „Wie oft, bei welchen Fällen und zu welchem Fehlerpreis funktioniert die versionierte Pipeline?“. Gemessen wird das ganze System: Datenaufbereitung, Retrieval, Prompt, Modell, Parser und Fallback. Ein isolierter Modellbenchmark kann eine Vorauswahl stützen, ersetzt aber nicht das betriebliche Ziel. **Preis:** Ein eigenes Eval-Set muss gepflegt werden; ohne dieses Asset bleibt jede Änderung eine unbeobachtete Wette. Jede Metrik braucht einen Entscheider und eine Aktion. Wenn Retrieval-Recall sinkt, wer stoppt den Release? Wenn Reviewzeit steigt, welcher Scope wird reduziert? Dashboards ohne Schwelle und Reaktion sammeln Beobachtungen, aber steuern kein Risiko. Dokumentiere für harte und weiche Signale Verantwortliche, Messfenster und Eskalation. **Nachteil:** Weniger Metriken bleiben übrig; diese sind dafür mit einer realen Betriebsentscheidung verbunden. ### Das Testset — vor der ersten Iteration Ein **Testset** ist eine Sammlung typischer Eingaben mit dem jeweils erwarteten Ergebnis oder zumindest einem klaren Kriterium, wann eine Antwort akzeptabel ist. Es entsteht **vor** dem Prompt-Tuning — sonst optimierst du auf einen wandernden Zielpunkt und weißt nie, ob eine Änderung geholfen hat. Testset anlegen → **Basiswert messen** → Änderung → erneut messen → vergleichen > **Merksatz:** Ohne Basiswert ist jede Verbesserung eine Behauptung. „Fühlt sich besser an“ ist kein Messergebnis. Lege das erste Set vor der Prompt- oder Modelloptimierung fest, sonst wählst du unbewusst nur Fälle, die die aktuelle Lösung gut aussehen lassen. Jeder Fall enthält Eingabe, relevante Umgebung, erwartete Eigenschaft, Fehlerklasse und Herkunft. Für offene Generierung kann eine Rubrik mehrere zulässige Antworten beschreiben. Halte einen Teil der Fälle als unbeeinflusstes Holdout zurück, wenn wiederholt auf dem Entwicklungsset optimiert wird. Das Set ist versioniert wie Code. Eine neue Richtlinie kann die erwartete Antwort ändern; dann wird nicht still das Label überschrieben, sondern Grund und Gültigkeit werden dokumentiert. **Nachteil:** Versionierung erhöht Reviewaufwand. Sie verhindert, dass ein scheinbarer Modellregress in Wahrheit eine unbemerkte Anforderungsänderung ist. ### Woher die Beispiele kommen Selbst ausgedachte Testfälle sind systematisch zu freundlich: Man formuliert sie so, wie man das System gedacht hat. Echte Nutzer schreiben Tippfehler, halbe Sätze, drei Fragen auf einmal, kopieren Fehlermeldungen ohne Kontext hinein und stellen Fragen, die gar nicht in den Anwendungsbereich fallen. - Fälle aus dem echten Verkehr ziehen — auch die unangenehmen, gerade die unangenehmen. - Bekannte Fehlerfälle dauerhaft aufnehmen: Jeder produktiv aufgefallene Fehler wird ein Testfall und darf nie wieder unbemerkt zurückkehren. - Fälle außerhalb des Anwendungsbereichs bewusst aufnehmen — die richtige Antwort ist dort eine Verweigerung oder eine Weiterleitung. - Verteilung grob nachbilden: Wenn 60 Prozent der Anfragen einen Typ haben, darf das Testset nicht zu 90 Prozent aus Sonderfällen bestehen. > **Datenschutz:** Echte Fälle enthalten echte Daten. Ein Testset ist eine Datenhaltung mit Zweck, Zugriff und Löschfrist — das ist vor dem Anlegen zu klären, nicht danach. Produktionsdaten liefern die echte Verteilung, enthalten aber Datenschutz- und Selektionsrisiken. Stichproben werden minimiert, geschützt und nach benannten Segmenten gezogen: Sprache, Länge, Kundengruppe, Toolpfad, Eskalation oder seltene Fehlerklasse. Nutzerfeedback allein reicht nicht, weil nur ein Teil der Nutzer meldet und Zustimmung nicht automatisch fachliche Richtigkeit bedeutet. Ergänze reale Stichproben um gezielte Grenz- und Angriffsfälle. Breck und Kollegen argumentieren für Tests über Daten, Modell und Infrastruktur; NIST trennt Vorabtests von Monitoring im Betrieb. **Preis:** Synthetische Grenzfälle repräsentieren nicht automatisch Häufigkeiten. Sie prüfen bekannte Risiken, während Produktionsstichproben unbekannte Verteilungen sichtbar machen. ### Wann ist gut genug? Ohne Zielgröße endet Tuning nie. Die Akzeptanzschwelle wird **vor** dem Bauen festgelegt und aus dem Prozess abgeleitet, nicht aus dem Machbaren: Wie gut ist der heutige manuelle Weg, und ab welcher Qualität ist der Einsatz ein Gewinn? | | | | --- | --- | | Zielgröße vor dem Bauen definiert | Tuning hat ein Ende, die Einführung ist entscheidbar | | Zielgröße nachträglich aus dem Ergebnis abgeleitet | die Messung bestätigt nur, was ohnehin gebaut wurde | | Keine Zielgröße | endlose Iteration, keine Abnahme, kein Abbruchkriterium | Sinnvoll ist außerdem, den **Vergleichsmaßstab** zu benennen. „85 Prozent korrekt“ ist ohne Bezug bedeutungslos — mit der Angabe, dass der manuelle Prozess bei 92 Prozent liegt oder dass die einfachste Regelheuristik 70 Prozent erreicht, wird daraus eine Entscheidungsgrundlage. **Akzeptanzschwelle:** Ein vor der Entscheidung festgelegter Grenzwert für eine Metrik oder Fehlerklasse, einschließlich Population, Messfenster und Konsequenz bei Verfehlung. Eine Gesamtgenauigkeit verschleiert unterschiedliche Schäden. Definiere harte Invarianten getrennt von statistischen Zielen: null unautorisierte Schreibvorgänge, mindestens ein bestimmter Recall für kritische Runbooks, höchstens eine tolerierte Eskalationsrate für harmlose Fälle. Schwellen werden aus Prozesskosten und Risiko abgeleitet, nicht so gesetzt, dass die aktuelle Version besteht. Jede Schwelle hat zwei Fehlerseiten: Ein strenges Gate blockiert brauchbare Fälle; ein lockeres Gate lässt Schaden durch. Dokumentiere beide. Bei kleinen Stichproben gehört Unsicherheit zur Entscheidung. **Preis:** Mehr Daten verzögern Freigaben; vorschnelle Punktwerte vermitteln dagegen eine Genauigkeit, die die Stichprobe nicht trägt. ### Jede Änderung ist eine Regression In LLM-Systemen ist erschreckend vieles eine Änderung mit Qualitätswirkung: eine Prompt-Zeile, eine neue Modellversion, ein anderes Ausgabeformat, ein zusätzliches Dokument im Bestand, ein geändertes Werkzeug. Anders als bei klassischer Software fällt eine Verschlechterung nicht auf — nichts bricht, es wird nur schlechter. Deshalb gehört der Testlauf an dieselbe Stelle wie ein Unit-Test: vor die Übernahme in Produktion. Und weil Modellausgaben nicht bit-genau reproduzierbar sind, prüft man **Kriterien** statt exakter Zeichenketten — enthält die Antwort die richtige Kategorie, den korrekten Betrag, keinen Verweis auf ein nicht existierendes Dokument. **Kurzcheck:** Der Anbieter kündigt eine neue Version des genutzten Modells an. Ihr habt ein Testset. Was tut ihr? - [x] Vor der Umstellung gegen das Testset messen und mit dem bisherigen Ergebnis vergleichen - [ ] Umstellen und im Betrieb beobachten, ob sich Beschwerden häufen - [ ] Nicht umstellen, weil jede Änderung die Qualität gefährdet > Richtig. Ein Modellwechsel ist eine Änderung mit Qualitätswirkung — genau der Fall, für den das Testset existiert. Ein Release-Gate vergleicht Kandidat und Baseline auf demselben fixierten Set und berichtet nicht nur Mittelwerte, sondern neue Fehler. Prompt, Modell, Retrieval, Tool-Schema und Datenquelle sind gemeinsam versionierte Einflussgrößen. Eine Kostenverbesserung darf eine kritische Sicherheitsklasse nicht verschlechtern. Umgekehrt darf ein einzelner kosmetischer Unterschied nicht jeden Release blockieren; die Rubrik entscheidet vorab, was relevant ist. Artefakte und Eval-Set fixieren → Baseline und Kandidat ausführen → **Metriken plus neue Fehler vergleichen** → Risikogates anwenden → Ergebnis und Entscheidung archivieren Bewahre neben den Scores eine kleine Sammlung konkreter Differenzen auf. Sie zeigt Reviewern, welche Fehler neu entstanden oder verschwunden sind, und verhindert Entscheidungen allein anhand gerundeter Mittelwerte. **Nachteil:** Qualitative Diff-Reviews kosten Zeit; sie erkennen dafür kritische Verschiebungen, die eine Gesamtmetrik verdeckt. > **Benannter Gate-Output:** Ein Release erzeugt einen versionierten `eval_run_id` mit Baseline, Kandidat, Set-Version und Gate-Ergebnis. Ohne diese Referenz ist ein grünes Dashboard nicht reproduzierbar. ### Kontrolle ist ein Regler, kein Schalter „Ein Mensch schaut drüber“ klingt nach einer Lösung und ist in Wahrheit eine unbeantwortete Frage: Wer schaut, wie oft, worauf, und mit welcher Möglichkeit, etwas zu erkennen? Ohne diese Antworten ist die Kontrolle eine Beruhigungsformel. Nützlicher ist eine Skala von Autonomiegraden. Jeder Grad ist für bestimmte Aufgaben richtig — und für andere falsch. | | | | --- | --- | | Vorschlag | Das System schlägt vor, der Mensch entscheidet und löst aus | | Freigabe | Das System bereitet vollständig vor, der Mensch gibt frei | | Autonom mit Stichprobe | Das System handelt, ein Anteil der Fälle wird nachträglich geprüft | | Autonom mit Ausnahmeregel | Das System handelt; nur definierte Auffälligkeiten gehen an Menschen | _[Abbildung: Kontrolle wirkt nur, wenn sie in der Schleife sitzt: mit Beleg, Zeit zum Prüfen und der realen Möglichkeit, Nein zu sagen.]_ Menschliche Kontrolle reicht von nachträglicher Stichprobe bis zur Pflichtfreigabe jeder Aktion. Sie ist kein pauschales Sicherheitsmerkmal. Ein Reviewer braucht Zeit, Fachwissen, relevante Evidenz und die reale Möglichkeit abzulehnen. Wird nur ein grüner Modellvorschlag ohne Quelle gezeigt, erzeugt die UI Zustimmung statt unabhängiger Prüfung. Der Kontrollgrad folgt Fehlerwirkung und Reversibilität. Trenne **Entscheidungsrecht** von **Prüfkapazität**. Ein Prozess kann formell einen Menschen vorsehen und praktisch unkontrolliert sein, wenn 1.000 Vorschläge pro Stunde auf zwei Reviewer treffen. **Preis:** Echte Pflichtfreigabe begrenzt Durchsatz. Wenn dieser Preis nicht akzeptiert wird, muss der automatische Scope kleiner oder risikoärmer werden. ### Was den Grad bestimmt Zwei Größen entscheiden, nicht die Modellqualität: **Umkehrbarkeit** der Handlung und **Entdeckungszeit** des Fehlers. Eine Handlung, die sofort auffällt und sich mit einem Klick zurücknehmen lässt, verträgt hohe Autonomie — selbst bei mäßiger Trefferquote. Eine unumkehrbare Handlung mit später Entdeckung verträgt sie nicht, selbst bei exzellenter Trefferquote. - Umkehrbar und sofort sichtbar — autonom, gelegentliche Stichprobe genügt. - Umkehrbar, aber spät sichtbar — autonom mit systematischer Stichprobe und Rückrollpfad. - Unumkehrbar oder mit Außenwirkung — Freigabe vor Vollzug, ohne Ausnahme. > **Merksatz:** Nicht die Fehlerrate bestimmt den Autonomiegrad, sondern der Erwartungswert des Schadens und die Chance, ihn rechtzeitig zu bemerken. Reversibilität, Schadenshöhe, Erkennbarkeit und Zeitdruck bestimmen die passende Stufe. Eine automatisch erzeugte interne Zusammenfassung kann nachgelagert stichprobenartig geprüft werden. Eine irreversible Kontolöschung braucht eine harte technische Sperre und bewusste Freigabe. Ein Notfall kann schnellere Wirkung verlangen, braucht dann engere erlaubte Aktionen, kurze Gültigkeit und vollständige Nachprüfung. | | | | --- | --- | | Niedriger Schaden, leicht reversibel | Automatik mit Monitoring und Stichprobe | | Mittlerer Schaden, gut prüfbar | Vorschlag mit risikobasierter Freigabe | | Hoher oder irreversibler Schaden | Harte Systemgrenze und unabhängige menschliche Entscheidung | ### Prüfkapazität ist endlich Hundertprozentige Prüfung klingt sicher und ist meist unbezahlbar — und dort, wo sie doch beschlossen wird, hält sie selten. Bei 800 Vorgängen am Tag und zwei Prüfern ist die Frage nicht **ob** gefiltert wird, sondern **ob bewusst oder zufällig**. Die bewusste Variante ist eine **risikobasierte Auswahl**: Alle Fälle über einer Wertgrenze, alle mit auffälligen Merkmalen, alle neuen Fallarten — plus eine kleine zufällige Stichprobe aus dem Rest. Die zufällige Auswahl braucht es, weil sonst genau die Fehlerklassen unsichtbar bleiben, die man nicht auf dem Schirm hatte. alle Vorgänge → Risikofilter → Prüfmenge → **Zufallsstichprobe aus dem Rest** → Rückmeldung ins System Kapazität wird gerechnet: erwartete Fallzahl mal mittlere Prüfzeit plus Spitzenlast und Rückfragen. Liegt die benötigte Zeit über dem verfügbaren Budget, sind drei ehrliche Optionen möglich: Scope reduzieren, mehr Kapazität bereitstellen oder nur eine risikogeschichtete Auswahl prüfen. „Der Mensch schaut kurz drauf“ ist keine vierte Option. Miss Reviewer-Qualität mit Doppelbewertungen und bekannten Ankerfällen. Hohe Abweichung kann auf unklare Rubrik statt auf schlechte Reviewer hinweisen. **Nachteil:** Kalibrierung kostet produktive Zeit und kann Uneinigkeit sichtbar machen. Genau diese Sichtbarkeit ist nötig, bevor menschliche Urteile als Ground Truth oder Release-Gate verwendet werden. ### Der Automatisierungs-Bias Menschen prüfen schlechter, wenn das System meistens recht hat. Dieser Effekt ist gut dokumentiert und verstärkt sich mit der Qualität des Systems: Je zuverlässiger es ist, desto stärker wird Prüfen zum Bestätigen. Eine Kontrolle, die zu 99 Prozent aus Zustimmung besteht, erzeugt genau das Verhalten, das sie verhindern soll. - Dem Prüfer die **Belege** zeigen, nicht nur das Ergebnis — die Passage, den Rohwert, die Herkunft. - Ablehnen genauso leicht machen wie Zustimmen; ein Prozess, in dem Widerspruch teuer ist, erzeugt Zustimmung. - Prüfergebnisse messen: Wie oft wird tatsächlich korrigiert? Eine Ablehnungsquote nahe null ist ein Warnsignal, kein Qualitätsnachweis. - Kontrolle nicht dort ansetzen, wo sie nur formal ist — lieber wenige Fälle gründlich als alle oberflächlich. > **Merksatz:** Eine Freigabestufe, die niemand ablehnt, ist keine Kontrolle. Sie ist eine dokumentierte Zuständigkeit für fremde Fehler. Automatisierungs-Bias bedeutet, dass Menschen Vorschlägen eines Systems unangemessen folgen können. Gegenmittel liegen im Design: eigene Einschätzung vor dem Modellvorschlag, sichtbare Evidenz, keine vorgewählte Zustimmung, gezielte Darstellung von Unsicherheit und regelmäßige Fälle, in denen Ablehnung richtig ist. Eine Warnmeldung, die fast immer ignoriert werden darf, trainiert dagegen nur das Wegklicken. Blinde Reviews können Unabhängigkeit erhöhen, kosten aber Zeit und verlieren den Nutzen guter Modellvorarbeit. Ein abgestuftes Design zeigt zuerst Rohdaten und Pflichtkriterien, danach den Vorschlag. **Preis:** Mehr Klicks und langsamere Entscheidungen. Der Nutzen ist ein Review, das tatsächlich zusätzliche Information in die Kontrollkette bringt. ### Abbrechen dürfen Ein Sprachmodell antwortet immer. Es gibt keine eingebaute Möglichkeit, „das weiß ich nicht“ zu bevorzugen — es sei denn, das System sieht sie ausdrücklich vor. **Kein Ergebnis** muss deshalb ein zulässiges Ergebnis sein: eine Eskalation an den Menschen, eine Weiterleitung, eine Rückfrage. Das braucht drei Dinge: einen definierten Ausgang für den Zweifelsfall, klare Auslöser dafür — fehlender Beleg, widersprüchliche Quellen, Wert über einer Grenze —, und einen Prozess, der diesen Ausgang nicht bestraft. Wo die Kennzahl allein die Automatisierungsquote ist, verschwindet die Eskalation. **Kurzcheck:** Die Freigabestufe für automatisch erstellte Gutschriften läuft seit sechs Monaten; die Ablehnungsquote der Prüfer liegt bei 0,2 Prozent. Wie liest du das? - [x] Als Warnsignal — es ist zu prüfen, ob wirklich noch geprüft wird - [ ] Als Beleg für hohe Systemqualität — die Freigabe kann entfallen - [ ] Als Normalfall, Prüfer lehnen selten ab > Richtig. Eine Ablehnungsquote nahe null kann Qualität bedeuten oder Durchwinken; ohne unabhängige Gegenprobe ist beides gleich wahrscheinlich. Ein System braucht einen sicheren Ausgang, wenn Evidenz fehlt, Tools ausfallen, Budgets erreicht sind oder Reviewer nicht rechtzeitig verfügbar sind. Das kann Abstention, Queue, manueller Prozess oder ein eng begrenzter Fallback sein. „Trotzdem beste Antwort erzeugen“ ist kein neutraler Default. Der Abbruchgrund wird strukturiert protokolliert und fließt in Eval- und Kapazitätsplanung ein. ### Review wird zum Engpass Ein Assistent erzeugt 600 Wartungsvorschläge pro Schicht. Zwei Engineers schaffen zusammen 180 gründliche Reviews. **Anforderungen** - Kritische Vorschläge dürfen nicht ungeprüft wirken. - Der Pilot soll einen messbaren Nettoeffekt haben. **Schritte** - Fälle nach Wirkung und Reversibilität segmentieren. - Nur risikoarme Vorschläge automatisch mit Stichprobe zulassen. - Kritische Fälle auf die vorhandene Reviewkapazität begrenzen. - Queue, Wartezeit, Ablehnungen und Reviewer-Fehler als Systemmetriken messen. **Merksatz:** Ein Human-in-the-loop-Design ist erst real, wenn die Kapazitätsrechnung aufgeht. Nach dem Rollout schließt Monitoring den Kreis. Neue Produktionsfehler werden minimiert reproduziert, fachlich gelabelt und nach Review in das Regressionstestset übernommen. Nicht jeder seltene Fall rechtfertigt eine sofortige Promptänderung; zuerst werden Häufigkeit, Schaden und mögliche Nebenwirkungen bewertet. **Preis:** Ein kontrollierter Lernprozess reagiert langsamer als Hotfix-Tuning, verhindert aber, dass ein einzelner Fall die Qualität für die Mehrheit verschlechtert. ## Quellen - Ribeiro et al. — Beyond Accuracy: Behavioral Testing of NLP Models with CheckList, ACL 2020 - Amershi et al. — Software Engineering for Machine Learning: A Case Study, ICSE-SEIP 2019 - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Measure-Funktion - Beyer et al. (Hrsg.) — Site Reliability Engineering, O'Reilly 2016, Kapitel Service Level Objectives - Parasuraman, Sheridan & Wickens — A Model for Types and Levels of Human Interaction with Automation, IEEE SMC-A 2000 - Parasuraman & Manzey — Complacency and Bias in Human Use of Automation: An Attentional Integration, Human Factors 2010 - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Govern- und Manage-Funktionen - ISO/IEC 42001:2023 — AI management systems - Breck et al. — The ML Test Score, IEEE Big Data 2017 — https://research.google/pubs/the-ml-test-score-a-rubric-for-ml-production-readiness-and-technical-debt-reduction/ - Ribeiro et al. — Beyond Accuracy: Behavioral Testing of NLP Models with CheckList, ACL 2020 — https://aclanthology.org/2020.acl-main.442/ - NIST — Generative AI Profile, NIST AI 600-1 — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf - Parasuraman, Sheridan & Wickens — A Model for Types and Levels of Human Interaction with Automation, 2000 — https://doi.org/10.1109/3468.844354 - Skitka, Mosier & Burdick — Does Automation Bias Decision-Making?, 1999 — https://doi.org/10.1006/ijhc.1999.0252 - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Manage-Funktion - Parasuraman & Manzey — Complacency and Bias in Human Use of Automation, Human Factors 2010 - ISO/IEC 42001:2023 — AI management systems (Kontrollen und Überwachung) - Sculley et al. — Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015 - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Measure- und Manage-Funktionen - Radford et al. — Robust Speech Recognition via Large-Scale Weak Supervision (Whisper), ICML 2023 - Breck et al. — The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction, IEEE Big Data 2017 - Skitka, Mosier & Burdick — Does Automation Bias Decision-Making?, International Journal of Human-Computer Studies 1999