Evals

Evals und Model Risk Management: was ein KI-System einsatzfähig macht.

Eine einzelne Benchmark-Zahl ist kein Deployment-Artefakt - drei Eval-Ebenen plus ein SR-11-7-Lebenszyklus schon.

SR 11-7 · EU AI Act Art. 11 + Anhang IV

5 Min. Lesezeit

Was es tatsächlich ist

Eine Eval-Suite für ein Sprachmodell ist ein stratifizierter Regressions-Test-Apparat, keine Genauigkeits-Schlagzeile. Sie hat drei Ebenen, und jede Ebene beantwortet eine andere Frage, die Ihre Model-Risk-Funktion der Reihe nach stellen wird.

Task-Level-Evals laufen mit deterministischen Assertions auf isolierten Modell-Aufrufen: Regex-Treffer, JSON-Schema-Validität, exakter String-Abgleich gegen einen zurückgehaltenen Datensatz, Klassifikationsmetriken auf gelabelten Fixtures. Sie sagen Ihnen, ob eine einzelne Kombination aus Prompt, Modell und Tool noch das tut, was sie beim letzten Release getan hat.

System-Level-Evals laufen als End-to-End-Traces durch den vollständigen Agent: Retrieval, Tool-Aufrufe, Multi-Turn-Zustand, Zwischenentscheidungen. Die Bewertung erfolgt entweder referenzbasiert (eine bekannte korrekte Trace) oder als LLM-as-Judge mit publizierter Rubrik. Sie sagen Ihnen, ob die Gesamtkonstruktion noch funktioniert, wenn die Bausteine miteinander reden.

Behavioural Evals laufen als adversariale Sondierungen: Jailbreak-Versuche, Refusal-Korrektheit, Kalibrierungstests, Prompt-Injection-Signaturen. Sie sagen Ihnen, was das System tut, wenn die Eingabe nicht die Eingabe ist, für die Sie es entworfen haben.

Jedes Modell-Release, jede Prompt-Änderung, jedes Retriever-Update löst einen erneuten Lauf gegen eine Golden Baseline aus. Überschreitungen der Schwellwerte lassen das CI-Gate scheitern. Dieselbe Suite wird anschließend kontinuierlich gegen Live-Traffic gesampelt, und die Verteilung der Judge-Scores oder Labels wird per Population Stability Index überwacht. PSI unter 0,10 ist stabil, 0,10 bis 0,25 bedeutet beobachten, 0,25 und darüber bedeutet untersuchen. PSI ist die symmetrische Hin-und-Rück-Form der KL-Divergenz und ist für Monitoring-Dashboards bevorzugt, weil er pro Merkmal und Fenster genau eine vorzeichenbehaftete Größe liefert.

Warum das in Ihrem Haus zählt

Ihr Model-Risk-Komitee wird eine sehr konkrete Frage stellen: 'Zeigen Sie uns den Nachweis, dass dieses System innerhalb der Toleranz arbeitet, und zeigen Sie uns, wie Sie merken werden, wenn es das nicht mehr tut.' Eine Benchmark-Folie beantwortet das nicht. Eine dreistufige Eval-Suite mit PSI-Monitor schon.

Konkret heißt das für ein Buy-Side-Haus, das beispielsweise einen KI-gestützten Kommentierungs- oder Klassifizierungs-Workflow betreibt: das einsatzfähige Artefakt ist ein Paket: der Task-Level-Testdatensatz mit versionierten Fixtures, die System-Level-Traces mit Rubrik-Bewertung, das Behavioural-Red-Team-Log, der aktuelle PSI-Wert auf Produktions-Samples und ein SR-11-7-konformer Lebenszyklus-Beleg, der die vier Phasen den verantwortlichen Personen zuordnet. Ohne dieses Paket bleibt der Workflow auf Dauer im Pilotbetrieb stecken, weil keine Second-Line-Funktion ihn ohne einen prüfbaren Regressions-Mechanismus in Produktion freigeben wird.

Der regulatorische Anker

Federal Reserve SR 11-7 (2011) definiert den Model-Risk-Management-Lebenszyklus: Entwicklung mit dokumentierter konzeptioneller Belastbarkeit, unabhängige Validierung durch ein zweites Team, fortlaufende Überwachung über Drift- und Regressions-Dashboards und ein nach Materialität gestuftes Modell-Inventar. SR 11-7 ist älter als Transformer und behandelt stochastische generative Modelle als Auslegungslücke, die die Aufsichten inzwischen aktiv füllen.

EU AI Act Artikel 11 plus Anhang IV verlangen eine Technische Dokumentation, bevor ein Hochrisiko-KI-System eine CE-Kennzeichnung erhalten kann: Systembeschreibung, Entwicklungsprozess, Daten-Governance, Performance-Metriken, Risikomanagement, Lebenszyklus-Änderungen, angewandte Normen, EU-Konformitätserklärung, Post-Market-Monitoring. Das sind neun Abschnitte, von denen jeder eine echte Eval-Pipeline voraussetzt.

Gepaart mit DORA Artikel 28 bis 30 zum ICT-Drittparteienrisiko muss die Eval-Suite in einem System leben, dessen operationelle Resilienz und Datenresidenz selbst auditierbar sind. Deshalb betreiben wir die Suite auf lokaler Inferenz, wo die aufsichtsrechtliche Frage es zulässt, und behalten die gesamte Eval-Trace und den Golden-Dataset innerhalb der Kundenumgebung - die Daten, die belegen, dass das Modell funktioniert, verlassen das Haus nicht.

Wie wir es bauen

Wir instrumentieren die drei Ebenen als separate Scoring-Jobs, die ein gemeinsames Dataset / Solver / Scorer-Schema teilen, modelliert nach dem Primitive-Split von Inspect AI. Task-Level nutzt PR-Diff-Tabellen im promptfoo-Stil für jedes Release; System-Level nutzt getracete Läufe mit rubrik-bewerteten Judge-Aufrufen; Behavioural nutzt einen kuratierten Red-Team-Datensatz unter Zugriffskontrolle, der quartalsweise rotiert wird.

PSI wird pro bewerteter Dimension auf einem gleitenden Fenster von Produktions-Samples berechnet. Das Dashboard zeigt eine einzige schwellenbasierte Zahl pro Dimension pro Fenster sowie die dahinterliegende Histogramm-über-Histogramm-Sicht. Die PSI-Bänder steuern das Ticket-Routing: 0,10 bis 0,25 geht an den Engineering-Owner, 0,25 und darüber an den Vorsitzenden des Model-Risk-Komitees.

Die Kalibrierung wird ehrlich berichtet. LLM-as-Judge-Verwechslungsmatrizen zeigen typischerweise rund 75 Prozent Trefferquote auf 'nicht relevant' und 30 bis 50 Prozent auf 'hochrelevant'. Wir weisen diese Asymmetrie im Validierungsbericht aus, anstatt sie wegzumitteln, denn die Model-Risk-Funktion wird sie später ohnehin finden, wenn wir sie jetzt nicht zeigen.

Die Lebenszyklus-Dokumente werden direkt auf die vier Phasen von SR 11-7 und auf die neun Abschnitte des Anhang IV des EU AI Act abgebildet. Unabhängige Validierung ist ein zweites menschliches Team, kein zweites Sprachmodell - dieser Punkt ist im Standard ausdrücklich, und wir halten ihn in unserem Deliverable ausdrücklich.

All das läuft auf einer Infrastruktur, in der Inferenz, Eval-Daten und Trace-Logs an die Region und Mandantenumgebung des Kunden gebunden sind. Die Einhaltung von DORA Art. 28 bis 30 ist ein Merkmal der Architektur, kein Häkchen am Ende.

Was Sie NICHT tun sollten

Zeigen Sie nicht 'KI-Genauigkeit 99,8 Prozent' als Hero-Zahl. Sie kollabiert drei Eval-Ebenen zu einem irreführenden Balken, verbirgt das Leck von Benchmarks ins Trainings-Set und ignoriert die Verbosity- und Position-Bias-Effekte von LLM-as-Judge, die die Literatur wiederholt dokumentiert hat.

Animieren Sie nicht eine einzelne Sprechblase mit einem Häkchen. Das vermittelt 'ich habe einen Prompt laufen lassen', nicht 'ich betreibe eine Regressions-Suite gegen eine Golden Baseline mit Drift-Überwachung'.

Verkaufen Sie LLM-as-Judge nicht als Ersatz für die unabhängige Validierung nach SR 11-7. Der Standard verlangt ein zweites menschliches Team. Es durch ein zweites Modell zu ersetzen, ist ein künftiger Prüfbefund.

Legen Sie den Golden-Dataset, die Eval-Traces oder die PSI-Dashboards nicht in eine Drittanbieter-SaaS, für die Ihr Haus keinen Eintrag im DORA-Art.-28-Register vorgenommen hat. Der Beleg, dass das Modell sicher ist, ist selbst in Scope.